А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 15

Стереотипы связей явно показывают роль действующих лицпо отношению к вариантам использования.Описание Business Use Case представляет собой спецификацию,которая, подобно обычному варианту использования, состоит изследующих пунктов:• наименование;• краткое описание;• цели и результаты (с точки зрения действующего лица);• описание сценариев (основного и альтернативных);• специальные требования (ограничения по времени выполнения илидругим ресурсам);• расширения (исключительные ситуации);• связи с другими Business Use Case;• диаграммы деятельности (для наглядного описания сценариев - принеобходимости).••••••73Рис. 2.1∗. Диаграмма вариантов использования для процесса регистрациипассажиров в аэропортуПример спецификации Business Use Case:Наименование - пройти регистрацию.Краткое описание - данный Business Use Case реализует процессрегистрации пассажира на рейс.Цели - получить посадочный талон и сдать багаж.Основной сценарий:1.

Пассажир встает в очередь к стойке регистратора.2. Пассажир предъявляет билет регистратору.3. Регистратор подтверждает правильность билета.4. Регистратор оформляет багаж.5. Регистратор резервирует место для пассажира.6. Регистратор печатает посадочный талон.7. Регистратор выдает пассажиру посадочный талон и квитанцию набагаж.8. Пассажир уходит от стойки регистратора.Альтернативные сценарии:3а. Билет неправильно оформлен - регистратор отсылает пассажира кагенту по перевозкам.Примеры моделей, связанных с применением технологии Rational Unified Process,здесь и далее приводятся в среде CASE-средства Rational Rose.∗744а. Багаж превышает установленный вес - регистратор оформляетдоплату.Специальные требования - время регистрации не должно превышатьодной минуты.Описание Business Use Case может сопровождаться целью процесса,которая моделируется с помощью класса со стереотипом "goal", а деревоцелей изображается в виде диаграммы классов.Для каждого Business Use Case строится модель бизнес-анализа объектная модель, описывающая реализацию бизнес-процесса в терминахвзаимодействующих объектов (бизнес-объектов - Business Object),принадлежащих к двум классам - Business Worker и Business Entity.Business Worker (исполнитель) - активный класс, представляющийсобой абстракцию исполнителя, выполняющего некоторые действия врамках бизнес-процесса.

Исполнители взаимодействуют между собой иманипулируют различными сущностями, участвуя в реализацияхсценариев Business Use Case. На диаграмме классов UML исполнительпредставляется в виде класса со стереотипом "business worker". Например,если рассмотреть Business Use Case "Пройти регистрацию", можноопределить в нем двух исполнителей - Регистратора и Координаторабагажа.Business Entity (сущность) - пассивный класс, не инициирующийникаких взаимодействий.

Объект такого класса может участвовать вреализациях различных Business Use Case. Сущность является объектомразличных действий со стороны исполнителей.Понятие Business Entity аналогично понятию сущности в модели«сущность-связь» (ERM), за исключением того, что в ERM неопределяется поведение сущности, а в объектной модели сущность можетиметь набор обязанностей. На диаграмме классов UML сущностьпредставляется в виде класса со стереотипом "business entity". Например, вBusiness Use Case "Пройти регистрацию" можно определить следующиесущности: Билет, Рейс, Авиалиния, Багаж, Багажная бирка.Модель бизнес-анализа может состоять из диаграмм разных типов.

Всостав модели обязательно должна входить диаграмма классов,содержащая исполнителей и сущности. Пример такой диаграммы дляBusiness Use Case "Пройти регистрацию" приведен на рис. 2.2.На данной диаграмме ассоциации между классами-исполнителямиотражают наличие взаимодействия между реальными исполнителями(Регистратором и Координатором багажа). Ассоциации между классамиисполнителями и классами-сущностями показывают, какими именнообъектами манипулируют конкретные исполнители (Регистратор имеетдело с Багажом и Багажной биркой, а Координатор багажа - только сБагажом). Ассоциации между классами-сущностями отражают различные75структурные связи (к одному месту багажа прикрепляется одна багажнаябирка).Рис.

2.2. Диаграмма классов модели бизнес-анализаКроме диаграммы классов, модель бизнес-анализа может включать:• Диаграммы последовательности (и кооперативные диаграммы),описывающиесценарииBusinessUseCaseввидепоследовательности обмена сообщениями между объектамидействующими лицами и объектами-исполнителями. Такиедиаграммы помогают явно определить в модели обязанностикаждого исполнителя в виде набора его операций. Примердиаграммы последовательности, описывающей основной сценарийBusiness Use Case "Пройти регистрацию", приведен на рис.

2.3.Модифицированная диаграмма классов модели бизнес-анализа соперациями приведена на рис. 2.4.• Диаграммы деятельности с потоками объектов и "плавательнымидорожками", описывающие взаимосвязи между сценариями одного76или различных Business Use Case. Пример такой диаграммы дляпроцесса заказа товаров в торговой компании приведен на рис. 2.5.• Диаграммы состояний, описывающие поведение отдельных бизнесобъектов (например, для сущности "Багаж" можно описатьпереходы между состояниями "Определен вес", "Зарегистрирован","Находится на транспортере" и т.д.).Рис. 2.3.

Диаграмма последовательности для основного сценария BusinessUse Case "Пройти регистрацию"Методика моделирования Rational Unified Process предусматриваетспециальное соглашение, связанное с группировкой структурныхэлементов и диаграмм бизнес-модели. Это соглашение включаетследующие правила:• Все действующие лица, варианты использования и диаграммывариантов использования для бизнес-процессов помещаются впакет с именем Business Use Case Model.77Рис. 2.4.

Модифицированная диаграмма классов модели бизнес-анализа соперациями• Все классы и диаграммы моделей бизнес-анализа помещаются впакет с именем Business Analysis Model.• Если моделируется деятельность более чем одного подразделенияорганизации, то совокупность всех классов-исполнителей иклассов-сущностей из моделей бизнес-анализа для различныхBusiness Use Case разделяется на пакеты, соответствующие этимподразделениям. Этим пакетам присваиваются наименованияподразделений (например, Бухгалтерия, Отдел доставки и т.п.) истереотип "organization unit" (организационная единица).• Диаграммы модели бизнес-анализа, относящиеся к конкретномуBusiness Use Case (диаграммы классов, последовательности,деятельности и состояний) помещаются в кооперацию с именемданного Business Use Case и стереотипом "business use-caserealization" (реализация бизнес-процесса). Все кооперациипомещаются в пакет с именем Business Use Case Realizations.78Рис.

2.5. Диаграмма деятельности для процесса заказа товаровПример структуры бизнес-модели для процесса регистрациипассажиров в аэропорту приведен на рис. 2.6.Методика моделирования Rational Unified Process обладаетследующими достоинствами:• модель бизнес-процессов строится вокруг участников процессов(заинтересованных лиц) и их целей, помогая выявить всепотребности клиентов организации. Нетрудно заметить, что такойподход в наибольшей степени применим для организаций,работающих в сфере оказания услуг (торговые организации, банки,страховые компании и т.д.);• моделирование на основе вариантов использования способствуетхорошему пониманию бизнес-модели со стороны заказчиков.• Однако следует отметить, что при моделировании деятельностикрупной организации, занимающейся как производствомпродукции, так и оказанием услуг, необходимо применятьразличные методики моделирования, поскольку для моделирования79производственных процессов более предпочтительным являетсяпроцессный подход (например, метод Eriksson-Penker).Рис.

2.6. Пример структуры бизнес-модели.2.2.2. Метод Ericsson-PenkerМетод Ericsson-Penker∗ представляет интерес прежде всего в связи спопыткой применения языка UML (изначально предназначенного длямоделирования архитектуры систем ПО) в рамках процессного подхода кмоделированию бизнес-процессов. Это стало возможным благодаряналичию в UML механизмов расширения (в первую очередь –стереотипов). Авторы метода создали свой профиль UML длямоделирования бизнес-процессов, введя набор стереотипов, описывающихпроцессы, ресурсы, правила и цели деятельности организации.∗Eriksson, Hans-Erik and Penker, Magnus "Business Modeling with UML: Business Patternsat work".

Wiley Computer Publishing, 2000.80Метод использует четыре основные категории бизнес-модели:• Ресурсы - различные объекты, используемые или участвующие вбизнес-процессах (люди, материалы, информация или продукты).Ресурсы структурированы, взаимосвязаны и подразделяются нафизические, абстрактные, информационные и человеческие.• Процессы - виды деятельности, изменяющие состояние ресурсов всоответствии с бизнес-правилами.• Цели - назначение бизнес-процессов Цели могут быть разбиты наподцели и соотнесены с отдельными процессами. Целидостигаются в процессах и выражают требуемое состояниересурсов. Цели могут быть выражены в виде одного или болееправил.• Бизнес-правила - условия или ограничения выполнения процессов(функциональные, поведенческие или структурные).

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

Метод Eriksson-Penker представляетобразец процесса на диаграмме деятельности (рис. 2.7) в видедеятельности со стереотипом "process" (в качестве основы данного образцаиспользовано представление процесса в методе IDEF0, расширенное засчет введения цели процесса). Процесс использует входные ресурсы иформирует выходные ресурсы, показанные в видеобъектов состереотипом "resourse", соединенных с процессом связями зависимости.Ресурсы, играющие в методе IDEF0 роли "управления" и "механизма",также соединены с процессом связями зависимости со стереотипами"supply" и "control". Цель процесса показана как объект со стереотипом"goal".Полная бизнес-модель включает множество представлений, подобныхпредставлениям архитектуры ПО.