18. Модель бизнес-процессов uml. Стереотипы модели.

Метод Ericsson-Penker представляет интерес прежде всего в связи с попыткой применения языка объектного моделирования UML (изначально предназначенного для моделирования архитектуры систем ПО) для моделирования бизнес-процессов. Это стало возможным благодаря наличию в UML механизмов расширения.

UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком. К его механизмам расширения относятся:

-стереотипы;

-тегированные (именованные) значения;

-ограничения.

Стереотип - это новый тип элемента модели, который определяется на основе уже существующего элемента. Стереотипы расширяют нотацию модели и могут применяться к любым элементам модели. Стереотипы классов - это механизм, позволяющий разделять классы на категории. Разработчики ПО могут создавать свои собственные наборы стереотипов, формируя тем самым специализированные подмножества UML (например, для описания бизнес-процессов, Web-приложений, баз данных и т.д.). Такие подмножества (наборы стереотипов) в стандарте языка UML носят название профилей языка.

Именованное значение - это пара строк "тег = значение", или "имя = содержимое", в которых хранится дополнительная информация о каком-либо элементе системы, например, время создания, статус разработки или тестирования, время окончания работы над ним и т.п.

Ограничение - это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL - Object Constraint Language), которое невозможно выразить с помощью нотации UML.

19. Спецификация требований к по.

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) — законченное описание поведения программы, которую требуется разработать.

Включает ряд пользовательских сценариев (англ. use cases), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.

Пользовательские сценарии являются средством представления функциональных требований. В дополнение к пользовательским сценариям, спецификация также содержит нефункциональные требования, которые налагают ограничения на дизайн или реализацию (такие как требования производительности, стандарты качества, или проектные ограничения).

В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications».

Рекомендуемая стандартом IEEE 830[1] структура SRS

Введение

Цели

Соглашения о терминах

Предполагаемая аудитория и последовательность восприятия

Масштаб проекта

Ссылки на источники

Общее описание

Видение продукта

Функциональность продукта

Классы и характеристики пользователей

Среда функционирования продукта (операционная среда)

Рамки, ограничения, правила и стандарты

Документация для пользователей

Допущения и зависимости

Функциональность системы

Функциональный блок X (таких блоков может быть несколько)

-Описание и приоритет

-Причинно-следственные связи, алгоритмы (движение процессов, workflows)

-Функциональные требования

Требования к внешним интерфейсам

Интерфейсы пользователя (UX)

Программные интерфейсы

Интерфейсы оборудования

Интерфейсы связи и коммуникации

Нефункциональные требования

Требования к производительности

Требования к сохранности (данных)

Критерии качества программного обеспечения

Требования к безопасности системы

Прочие требования

Приложение А: Глоссарий

Приложение Б: Модели процессов и предметной области и другие диаграммы

Приложение В: Список ключевых задач

Программные требования устанавливают основные соглашения между пользователями (заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чего от нее не стоит ожидать. Документ может включать процедуры проверки получаемого программного обеспечения на соответствие предъявляемым ему требованиям (вплоть до содержания планов тестирования), характеристики, определяющие качество и методы его оценки, вопросы безопасности и многое другое. Часто программные требования описываются на обычном языке. В то же время, существуют полуформальные и формальные методы и подходы, используемые для спецификации программных требований. В любом случае, задача состоит в том, чтобы программные требования были ясны, связи между ними прозрачны, а содержание данной спецификации не допускало разночтений и интерпретаций, способных привести к созданию программного продукта, не отвечающего потребностям заинтересованных лиц. Стандарт IEEE 830 является классическим примером стандарта на содержание структурирование и методы описания программных требований

Cценарии использования Use Case часто включают в спецификацию требований наравне с трассировкой (traces) к соответствующим моделям в форме диаграмм, например, к UML Use Case, UML Activity, BPMN и т.п.

20.Использование DFD диаграммы потоков данных для описания структуры проектируемой системы.

Диаграммы потоков данных (Data flow diagramming, DFD):

• являются основным средством моделирования функциональных требований к проектируемой системе;

• создаются для моделирования существующего процесса движения информации;

используются для описания документооборота, обработки информации;

применяются как дополнение к модели IDEFO для более наглядного отображения текущих операций документооборота (обмена информацией);

• обеспечивают проведение анализа и определения основных направлений реинжиниринга ИС

Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF0, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией как внутри системы между бизнес-функциями, так и системы в целом с внешней информационной средой

В случае наличия в моделируемой системе программной/программируемой части (практически всегда) предпочтение, как правило, отдается DFD по следующим соображениям.

DFD-диаграммы создавались как средство проектирования программных систем, тогда как IDEF0 - как средство проектирования систем вообще, поэтому DFD имеют более богатый набор элементов, адекватно отражающих их специфику (например, хранилища данных яв-ляются прообразами файлов или баз данных).

Наличие мини-спецификаций DFD-процессов нижнего уровня позволяет преодолеть логиче-скую незавершенность IDEF0, а именно обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной, и построить полную функциональную спецификацию разрабатываемой системы.

Существуют и поддерживаются рядом CASE-инструментов алгоритмы автоматического пре-образования иерархии DFD в структурные карты, демонстрирующие межсистемные и внут-рисистемные связи, а также иерархию систем, что в совокупности с мини-спецификациями является завершенным заданием для программиста.

С помощью DFD-диаграмм требования к проектируемой ИС разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель декомпозиции DFD-функций - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. На схемах бизнес-процесса отображаются:

• функции процесса

• входящая и исходящая информация, при описании документов

• внешние бизнес-процессы, описанные на других диаграммах

• точки разрыва при переходе процесса на другие страницы

Если при моделировании по методологии IDEF0 система рассматривается как сеть взаи-мосвязанных функций, то при создании DFD-диаграммы система рассматривается как сеть связанных между собой функций, т.е. как совокупность сущностей (предметов).

21. Объектно-ориентированный анализ

Объектно-ориентированный анализ - методология анализа сущности реального мира на основе понятий класса и объекта, составляющих словарь предметной области, для понимания и объяснения того, как они (сущности) взаимодействуют между собой. Модели объектно-ориентированного анализа в дальнейшем превращаются в объектно-ориентированный проект.

Объектно-ориентированный анализ - средство описания предметной области.