Нотации оформления требований

Семейство IDEF• IDEF0 : Function modeling (выросла из SADT, методология функционального моделирования)• IDEF1 : Information Modeling (эквивалент реляционной модели в третьей НФ)• IDEF1X : Data Modeling (развитие IDEF1)• IDEF2 : Simulation Model Design (методология динамического моделирования развития

систем)• IDEF3 : Process Description Capture (методология документирования технологических

процессов)• IDEF4 : Object-Oriented Design (методология построения объектно-ориентированных систем –

позволяет отобразить структуру объектов)• IDEF5 : Ontology Description Capture (исследование онтологических систем)• IDEF6 : Design Rationale Capture (обоснование проектных действий – почему модель

получилась так, как получилась?)• IDEF7 : Information System Auditing (аудит информационных систем)• IDEF8 : User Interface Modeling (разработка пользовательских интерфейсов)• IDEF9 : Business Constraint Discovery (исследование бизнес-ограничений)• IDEF10 : Implementation Architecture Modeling (не полностью разработан)• IDEF11 : Information Artifact Modeling (не полностью разработан)• IDEF12 : Organization Modeling (не полностью разработан)• IDEF13 : Three Schema Mapping Design (не полностью разработан)• IDEF14 : Network Design (проектирование компьютерных сетей)

Преимущества и недостатки IDEF• Возможность декомпозиции, в связи с этим

зачастую затруднен охват полной картины• Общий взгляд на систему, в связи с этим

упускаются детали• Излишняя подробность, в связи с этим

затрудненность чтения• Легко читаемая, однако непонятная

«неподготовленному» человеку• Лаконичность, однако возможность описания

только линейного процесса (для IDEF0)

Уровень использования нотаций: BPMN + UML

BPMN

• Версии: 1.2 и 2.0• Ориентация на бизнес-пользователей и

технических специалистов• Может быть трансформирован в

исполняемые модели на BPEL (язык на основе XML)

• Не используется для:– Моделей данных– Организационной структуры

История возникновения BMPN• Нотации и методологии

• UML Activity Diagram• UML EDOC Business

Processes• IDEF• ebXML BPSS• LOVeM• Activity-Decision Flow

Diagram (ADF) • RosettaNet

…

BPMN

Категории элементов BPMN

• Объекты потока управления: события, действия и логические операторы

• Соединяющие объекты: поток управления, поток сообщений и ассоциации

• Роли: пулы и дорожки• Артефакты: данные, группы и текстовые

аннотации.

События в BPMNизображаются окружностью и означают какое-либо происшествие в мире. События инициируют действия или

являются их результатами. Согласно расположению в процессе события могут быть классифицированы на начальные (start), промежуточные (intermediate) и завершающие (end).

• События-сообщения (message events) показывают получение и отправку сообщений в ходе выполнения процесса.

• События-таймеры (timer events) моделируют события, регулярно происходящие во времени. Также позволяют моделировать моменты времени, периоды и таймауты.

• События-ошибки (error events) позволяют смоделировать генерацию и обработку ошибок в процессе. Ошибки могут иметь различные типы.

• События-отмены (cancel events) инициируют или реагируют на отмену транзакции.• События-компенсации (compensation events) инициируют компенсацию или выполняют действия по

компенсации.• События-условия (conditional events) позволяют интегрировать бизнес правила в процесс.• События-сигналы (signal events) рассылают и принимают сигналы между несколькими процессами. Один

сигнал может обрабатываться несколькими получателями. Таким образом, события-сигналы позволяют реализовать широковещательную рассылку сообщений.

• Составные события (multiple events) моделирует генерацию и моделирование одного события из множества.

• События-ссылки (link events) используются как межстраничные соединения. Пара соответствующих ссылок эквивалентна потоку управления.

• События-остановки (terminate events) приводят к немедленному завершению всего бизнес процесса (во всей диаграмме).

События в BPMN

Действия в BPMNизображаются прямоугольниками со скругленными углами. Среди действий

различают задания и подпроцессы. Графическое изображение свёрнутого подпроцесса снабжено знаком плюс у нижней границы прямоугольника.

• Задание — это единица работы, элементарное действие в процессе.• Множественные экземпляры действия — показывают, что одно действие

выполняется многократно, по одному разу для каждого объекта. Например, для каждого объекта в заказе клиента выполняется один экземпляр действия. Экземпляры действия могут выполняться параллельно или последовательно.

• Циклическое действие — выполняется, пока условие цикла верно. Условие цикла может проверяться до или после выполнения действия.

• Свёрнутый подпроцесс — является сложным действием и содержит внутри себя правильную диаграмму бизнес-процессов.

• Развёрнутый подпроцесс — также является составным действием, но скрывает детали реализации процесса.

• Ad-hoc-подпроцесс — содержит задания. Задания выполняются до тех пор, пока не выполнено условие завершения подпроцесса.

Действия в BPMN

Логические операторы в BPMNизображаются ромбами и представляют точки принятия решений в процессе. С помощью логических операторов

организуется ветвление и синхронизация потоков управления в модели процесса.

• Оператор исключающего «или», управляемый данными (англ. data-based exclusive gateway). Если оператор используется для ветвления, то поток управления направляется лишь по одной исходящей ветви. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.

• Оператор исключающего «или», управляемый событиями (англ. event-based exclusive gateway) направляет поток управления лишь по той исходящей ветви, на которой первой произошло событие. После оператора данного типа могут следовать только события или действия-обработчики сообщений.

• Оператор включающего «или» (англ. inclusive gateway) активирует одну или более исходящих ветвей, в случае, когда осуществляется ветвление. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.

• Оператор «и» (англ. parallel gateway), использующийся для ветвления, разделяет один поток управления на несколько параллельных. При этом все исходящие ветви активируются одновременно. Если оператор используется для синхронизации, то он ожидает завершения выполнения всех входящих ветвей и лишь затем активирует выходной поток.

• Сложный оператор (англ. complex gateway) имеет несколько условий, в зависимости от выполнения которых активируются исходящие ветви. Оператор затрудняет понимание диаграммы, так как условия, определяющие семантику оператора, графически не выражены на диаграмме. Вследствие этого использование оператора нежелательно.

Логические операторы в BPMN

Соединяющие объекты в BPMN

Поток управления

(задаёт порядок выполнения действий)

Поток сообщений

(показывает, какими сообщениями

обмениваются участники)

Ассоциации

(используются для ассоциирования

данных, текстовых аннотаций с

объектами потока управления)

Роли в BPMN

Роли - визуальный механизм организации различных действий в категории со сходной функциональностью

Пул (область) олицетворяет участника процесса. Содержит

несколько объектов потока управления, соединяющих объектов и артефактов

Дорожки - часть пула. Дорожки организовывают и классифицируют действия

Артефакты в BPMN

Артефакты позволяют разработчикам отображать дополнительную информацию в диаграмме

Данные

(показывают читателю, какие

действия требуют выполнения и/или что

они производят)

Группа (группировка)

(позволяет объединять различные действия, но

не влияет на поток управления в диаграмме)

Текстовая аннотация

(способ предоставления дополнительной информации для

изучающего схему BPMN)

Типы бизнес-процессовМожно выделить три типа подмоделей:• Частные (внутренние) бизнес-процессы– Внутренняя деятельность организации– Все процессы в рамках одного пула и не

пересекают его• Абстрактные (открытые) бизнес-процессы– Взаимодействие между двумя частными бизнес-

процессами– Только коммуникации

• Процессы взаимодействия (глобальные)– Взаимодействие между двумя и более сущностями

UML• UML (англ. Unified Modeling Language —

унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения.

• UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью.

• UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем.

• UML не является языком программирования, но на основании UML-моделей возможна генерация кода.

Структура UML

Типы диаграмм• Структурные диаграммы:

– Диаграмма классов– Диаграмма компонентов– Композитной/составной структуры

• Диаграмма кооперации (UML2.0)– Диаграмма развёртывания– Диаграмма объектов– Диаграмма пакетов– Диаграмма профилей (UML2.2)

• Диаграммы поведения:– Диаграмма деятельности– Диаграмма состояний– Диаграмма прецедентов– Диаграммы взаимодействия:

• Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)• Диаграмма обзора взаимодействия (UML2.0)• Диаграмма последовательности• Диаграмма синхронизации (UML2.0)

Use case (диаграмма прецедентов)

• Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.

• Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).

• Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые.

Deployment diagram(диаграмма топологии)

• Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ.

• Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения.

• Обычно этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых она будет эксплуатироваться.

State Maсhine diagram(диаграмма состояний)

• Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначениеActivity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.

• Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.

• Диаграмма состояний (Statechart) предназначена для отображения состояний объектов системы, имеющих сложную модель поведения.

• Это одна из двух диаграмм State Machine, доступ к которой осуществляется из одного пункта меню.

Activity diagram(диаграмма активности)

• Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначениеActivity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.

• Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.

Sequence diagram (диаграммы последовательностей действий)

• Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов.

• Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами.

• Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений.

Collaboration diagram (диаграммы сотрудничества)

• Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.

• По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграммуCollaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

Class diagram (диаграммы классов)

• Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов.

• Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration.

Component diagram (диаграммы компонентов)

• Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

• При проектировании больших систем может оказаться, что система должна быть разложена на несколько сотен или даже тысяч компонентов, и этот тип диаграмм позволяет не потеряться в обилии модулей и их связей.