Rational UML Profile для моделирования бизнес-систем

Краткий обзор

Этот UML-профиль (профиль - это механизм расширения для добавления новых семантических элементов в UML; механизм определен как часть самого языка UML) является компонентом Rational Unified Process (RUP). Он предоставляет UML-язык для описания бизнес-моделей (Business Model) и поддерживается Business Modeling Discipline в RUP. Предназначение этого профиля - разрешить использование UML-средств для разработки бизнес-систем. К ним относятся различные дисциплины, такие как моделирование бизнес-информации, моделирование бизнес-организации и моделирование бизнес-процессов, а также высокоуровневое общее представление и моделирование цели, которые выступают как требования для активности бизнес-системы. Профиль формирует как фундамент для нового класса UML-средств, так и семантику взаимодействия между UML-средствами и другими средствами моделирования бизнес-систем.

Профиль RUP Business Modeling недавно был расширен и обновлен для возможности описания большего количества информации, относящейся к бизнес-контексту и бизнес-процессам. Ранние версии RUP Business Modeling Discipline предназначались для очень общего описания бизнес-информации, достаточной только для понимания требований к разработке приложений, поддерживающих бизнес. Целью этого обновления является расширение концепций и функциональных возможностей профиля для описания большего объема информации и более высокой точности модели.

Профиль Business Modeling основан на предшествующей работе Rational Software and Objectory и используется также как пример профиля, документированного в спецификациях языков OMG UML 1.2, 1.3 и 1.4.

Обзор UML-профиля для бизнес-моделирования

Этот раздел охватывает следующие темы:

• Концептуальная модель
• Структура профиля
• Идентифицированное подмножество UML

Концептуальная модель

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

Рисунок 1: Взаимосвязи концептуальной модели

Структура профиля

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

Рисунок 2: Структура пакетов профиля

Набор пакетов организован вокруг трех моделей, которые составляют артефакты для RUP Business Modeling Workflow. Однако обратите внимание, что в UML профиль является однородным пространством имен, когда используется пользователем; поэтому пакеты служат для организации профиля во время его разработки и не имеют влияния или какого-либо значения для конечного пользователя, который использует инструментальное средство, реализующее этот профиль.

Идентифицированное подмножество UML

Виртуальная метамодель

Модель бизнес-прецедента

Рисунок 3: Model Management (менеджмент модели)

Рисунок 4: Assess and Adjust Goals (цели оценки и настройки)

Рисунок 5: Find Business Use Cases (поиск бизнес-прецедентов)

"стереотип" Business Actor

Расширяет

"metaClass" Actor

Семантика

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

Помеченные значения

Нотация

Правила форматирования

---------
-- Может быть ассоциирован только с "Business Use Case"
context Business Actor inv CommunicatesWith:
  self.associations->forAll(a / 
    a.allConnections->forAll(r / 
      r.type.oclIsKindOf(UseCase) implies 
        r.stereotype = "Business Use Case")) 

"стереотип" Business Goal

Расширяет

"metaClass" Class

Семантика

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

Бизнес поддерживает много целей непосредственно, используя бизнес-прецеденты, которые выполняют одну или несколько целей. Однако не является неправильным иметь цели, не поддерживаемые прецедентами, поскольку это часто указывает на то, что на цели воздействуют окружающие факторы.

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

Бизнес-менеджеры и акционеры используют бизнес-цели для трансляции бизнес-стратегии в конкретные измерения. Аналитики бизнес-процессов и бизнес-дизайнеры используют бизнес-цели для проверки соответствия бизнес-процессов бизнес-стратегии.

Помеченные значения

Нотация

Правила форматирования

---------
-- Разрешены зависимости только между целями или
-- поддержка из прецедентов
context Business Goal inv Dependencies:
  self.allDependencies->forAll(d / 
    d.client->forAll(c / 
      (c.oclIsKindOf (Class) and c.stereotype = "Business Goal") or
      (c.oclIsKindOf (UseCase) and c.stereotype = "Business Use Case")) and
    d.supplier->forAll(s /
      (s.oclIsKindOf (Class) and s.stereotype = "Business Goal")))

-- нет структурных или поведенческих функций
context Business Goal inv NoFeatures:
  self.attributes->isEmpty() and
    self.operations->isEmpty() and
      self.associationEnds->isEmpty()

"стереотип" Business Use Case

Расширяет

"metaClass" UseCase

Семантика

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

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

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

Помеченные значения

Нотация

Правила форматирования

----------
-- Только <<Business Actor>> могут взаимодействовать с <<Business Use Case>>
context Business Use Case inv CommunicatesWith:
  self.associations->forAll(a / 
    a.allConnections->forAll(r / 
      (r.type.oclIsKindOf(UseCase) implies r.stereotype = "Business Use Case") and
      (r.type.oclIsKindOf(Actor) implies r.stereotype = "Business Actor")))

-- Должен иметь по крайней мере одну <<trace>> зависимость от <<Business Goal>>
context Business Use Case inv Traceability:
  self.allDependencies->forAll(d /
    d.supplier->exists(s /
      s.oclIsKindOf (Class) and s.stereotype = "Business Goal"))

"стереотип" Business Use Case Model

Расширяет

"metaClass" Model

Семантика

Business Use Case Model (модель бизнес-прецедента) - это модель бизнес-целей и предполагаемых функций. Она используется как важная входная информация для идентификации ролей и результатов деятельности в организации.

Business Use Case Model описывает направление и намерение бизнес-системы. Направление предоставляется в форме бизнес-целей, наследованных от бизнес-стратегии, тогда как намерение выражается как добавленная ценность и средства взаимодействия с акционерами бизнес-системы.

BusinessUse Case Model используется акционерами, аналитиками бизнес-процессов и бизнес-дизайнерами для осмысления и улучшения способа взаимодействия бизнеса с его средой, а также системными аналитиками и проектировщиками программного обеспечения для предоставления контекста для разработки программного обеспечения. Менеджер проекта использует Business Use Case Model для планирования содержимого итераций во время моделирования бизнеса и для отслеживания прогресса.

Помеченные значения

Нотация

Правила форматирования

----------
-- Может содержать только не стереотипные Packages и элементы из этого сегмента профиля
context Business Use Case Model inv Contents:
  self.contents->forAll(c /
    (c.oclIsKindOf(Actor) and c.stereotype = "Business Actor") or
    (c.oclIsKindOf(Class) and c.stereotype = "Business Goal") or
    c.oclIsKindOf(Package) or
    (c.oclIsKindOf(UseCase) and c.stereotype = "Business Use Case"))

"enumeration" Process Category

Расширяет

Нет.

Семантика

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

Помеченные значения

Нет.

Нотация

Нет.

Правила форматирования

Нет дополнительных правил форматирования.

"стереотип" supports

Расширяет

"metaClass" Dependency

Семантика

Отмечает бизнес-цель (цели), поддержку которой обеспечивает бизнес-прецедент. Бизнес-цель должна поддерживать одну или более таких целей.

Помеченные значения

Нет.

Нотация

Нет.

Правила форматирования

-- клиент - это Business Use Case, поставщик - это Business Goal.
-- OCL TBD.

Business Analysis Model

Рисунок 6: Описание реализаций Business Use Case

Рисунок 7: Поиск бизнес-ролей

Рисунок 8: Поиск Domain Entities

"стереотип" Business Analysis

Расширяет

"metaClass" Model

Семантика

Business Analysis Model (модель бизнес-анализа) описывает реализацию бизнес-прецедентов, моделируя взаимодействие между исполнителями и сущностями. Она служит в качестве абстракции того, как исполнители и бизнес-сущности должны быть связаны и как они должны кооперироваться для формирования бизнес-прецедентов.

Назначением Business Analysis Model является описание того, как выполняются бизнес-прецеденты. Business Use Case Model описывает, что происходит между бизнес-актерами и бизнес-системой, и не делает предположений о структуре бизнес-системы или о способах реализации бизнес-прецедентов. Business Analysis Model, с другой стороны, определяет внутренних исполнителей и используемую ними информацию (бизнес-сущности), описывает их структурную организацию в независимых модулях (бизнес-системах) и определяет, как они взаимодействуют для реализации поведения, описанного в бизнес-прецедентах.

Акционеры и аналитики бизнес-процессов используют Business Analysis Model для освоения того, как работает бизнес-система в настоящее время, а также для анализа эффекта от изменений в бизнес-системе. Аналитики бизнес-процесса ответственны за структуру и целостность модели, в то время как бизнес-дизайнеры отвечают за детализацию элементов модели. Модель используется также системными аналитиками для наследования требований к программному обеспечения, основываясь на том, как программная система будет использоваться в качестве части бизнес-процессов. Проектировщики программного обеспечения используют модель для определения архитектуры программы, которая наилучшим образом вписывается в организацию, и для идентификации классов в моделях анализа и проектирования программного обеспечения.

Помеченные значения

Нет.

Нотация

Правила форматирования

----------
-- Может содержать только не стереотипные Packages и элементы из этого сегмента профиля
context Business Analysis inv Contents:
  self.contents->forAll(c /
    c.oclIsKindOf(Package) or
    (c.oclIsKindOf(Collaboration) and 
      c.stereotype = "Business Use Case Realization") or
    (c.oclIsKindOf(Class) and c.stereotype = "Business Entity") or
    (c.oclIsKindOf(Constraint) and c.stereotype = "Business Rule") or
    (c.oclIsKindOf(Package) and c.stereotype = "Business System") or
    (c.oclIsKindOf(Actor) and c.stereotype = "Business Worker") or
    (c.oclIsKindOf(Actor) and c.stereotype = "Case Worker") or
    (c.oclIsKindOf(Dependency) and c.stereotype = "owner") or
    (c.oclIsKindOf(Signal) and c.stereotype = "Business Event"))

"стереотип" Business Entity

Расширяет

Abstract Entity

Семантика

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

Бизнес-сущности представляют абстракцию важной постоянной информации в бизнес-системе. Любая часть информации, являющаяся свойством чего-нибудь еще, вероятно не является бизнес-сущностью в действительности. Например, CommunicationMode (полнодуплексное или полудуплексное) является свойством Connection и, следовательно, не является бизнес-сущностью. Информация, которая не сохраняется, но создается или определяется по требованию (когда необходимо), тоже, вероятно, не является бизнес-сущностью. Например, список продуктов - это определенно важная информация, но это - не устойчивая информация. Каждый раз, когда кто-нибудь хочет знать количество экземпляров конкретного штрих-кода, находящееся в настоящее время на полке (или на складе), эта информация будет вычислена и затем сброшена.

Акционеры используют бизнес-сущности для проверки того, что информация созданная и требуемая организацией присутствует в Business Analysis Model. Бизнес-дизайнер отвечает за идентификацию и описание бизнес-сущностей, а также за определение влияния организационных изменений на информацию, созданную и требуемую бизнес-системой. Бизнес-сущности также используются системными аналитиками и дизайнерами при описании системных прецедентов и идентификации программных сущностей соответственно.

Помеченные значения

Нет.

Нотация

Правила форматирования

Нет дополнительных правил форматирования.

"стереотип" Business Event

Расширяет

"metaClass" Signal

Семантика

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

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

Акционеры и аналитики бизнес-процессов используют бизнес-события для лучшего понимания и описания бизнес-операций. Бизнес-дизайнеры отвечают за детализацию бизнес-событий и используют их для разъединения пространства и времени внутри бизнес-процессов. Бизнес-события используются также системными аналитиками при идентификации актеров программной системы и прецедентов, а также проектировщиками программного обеспечения для того, чтобы сделать программные системы более гибкими и ремонтопригодными.

EventType будет, наиболее вероятно, иметь ассоциацию с "Business Entity".

Помеченные значения

Нет.

Нотация

Правила форматирования

Нет дополнительных правил форматирования.

"стереотип" Business Rule

Расширяет

"metaClass" Constraint

Семантика

Бизнес-правило представляет собой объявление политики или условия, которое должно быть удовлетворено, и выражается в виде ограничения или инварианта в Business Analysis Model. Бизнес-правила должны использоваться в тех ситуациях, когда существуют многочисленные или сложные условия, управляющие бизнес-операциями. Такие правила могут быть выражены на естественном языке, например, "заказ должен иметь назначенного заказчика" или, возможно на формальном языке, например OCL.

Назначением этого артефакта является определение конкретного ограничения или инварианта, которые должны быть удовлетворены бизнес-системой. Бизнес-правила можно применять всегда (тогда они называются инвариантами) или при определенном условии. Если возникает это условие, правило становится действительным и, следовательно, должно быть выполнено.

Акционеры и аналитики бизнес-процессов просматривают бизнес-правила для проверки того, что описания бизнес-системы соответствуют способу ведения бизнеса. Аналитики бизнес-процессов отвечают за Business Analysis Model в целом, а бизнес-дизайнеры отвечают за фиксирование бизнес-правил в модели и проверку завершенности и непротиворечивости бизнес-правил. Бизнес-правила используются также системными аналитиками и проектировщиками программного обеспечения при определении и проектировании программного обеспечения, поддерживающего бизнес-систему.

Помеченные значения

Нотация

Нет.

Правила форматирования

---------
-- Есть какая-либо из ассоциаций с <<Business Entity>>, <<Business Worker>> 
-- <<Resource>>, <<Business Activity>> или <<Physical Worker>>
context Business Rule inv ConstrainedElements:
  self.constrainedElement->forAll(e /
    (c.oclIsKindOf(Actor) and c.stereotype = "Business Worker") or
    (c.oclIsKindOf(Actor) and c.stereotype = "Case Worker") or
    (c.oclIsKindOf(Class) and c.stereotype = "Business Entity") or
    (c.oclIsKindOf(Class) and c.stereotype = "Business Event") or
    (c.oclIsKindOf(Activity))

"enumeration" Business Rule Kind

Расширяет

Нет.

Семантика

Кодирует типичные отраслевые категории для бизнес-правил.

Помеченные значения

Нет.

Нотация

Нет.

Правила форматирования

Нет дополнительных правил форматирования.

"стереотип" Business System

Расширяет

"metaClass" Package.

Семантика

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

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

Бизнес-системы используются аналитиками бизнес-процессов для определения того, присутствуют ли внутри организации необходимые возможности, а также для проверки того, что бизнес-модель допускает изменение. Бизнес-дизайнеры используют бизнес-системы для формирования наборов связанных исполнителей и бизнес-сущностей, а также явного определения и управления зависимостями внутри организации. Менеджеры проекта также используют бизнес-системы для параллельного планирования работы.

В предыдущих версиях RUP использовался стереотип "Organizational Unit". Это вызывало замешательство у некоторых пользователей, так как организационная единица является в основном физической концепцией и заставляет вас думать в терминах целевой организации в фазе абстракции от таких решений. Концепция бизнес-системы наиболее близка к концепции Objectory "единицы компетенции ", документирующей абстрактную организацию, в которой исполнители организованы в терминах сходства их компетентностей или участия в реализациях прецедентов.

Помеченные значения

Нет.

Нотация

Правила форматирования

-- Должна содержать только членов профиля
-- OCL TBD.

"стереотип" Business Use Case Realization

Расширяет

"metaClass" Collaboration

Семантика

Реализация бизнес-прецедентов описывает, как исполнители, бизнес-сущности и бизнес-события кооперируются для выполнения конкретного бизнес-прецедента. Там, где бизнес-прецедент документирует внешне видимое поведение бизнес-системы, - предоставляется "what"; говоря о том, какие участники и сущности обеспечивают поведение прецедента, - реализация документирует "how".

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

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

Помеченные значения

Нет.

Нотация

Правила форматирования

----------
-- Требует обязательной реализации взаимосвязи с <<Business Use Case>>
-- Экземпляры внутри кооперации могут иметь только следующие типы:
--   <<Business Actor>>, ClassifierRole stereotyped <<Role>>
--   <<Business Entity>>
--   <<Business Worker>>, ClassifierRole stereotyped <<Role>>
context Business Use Case Realization inv OwnedElements:
  self.contents->select(c / 
    c.oclIsKindOf(ClassifierRole))->forAll(cr /
      if not cr.representedFeature->isEmpty() then
        (cr.oclIsKindOf(Actor) and cr.stereotype = "Business Actor" and
          c.stereotype = "Role") or
        (cr.oclIsKindOf(Class) and cr.stereotype = "Business Entity") or
        (cr.oclIsKindOf(Class) and cr.stereotype = "Business Worker") or
        (cr.oclIsKindOf(Class) and cr.stereotype = "Case Worker")))
      end if

"стереотип" Business Worker

Расширяет

"metaClass" Class

Семантика

Исполнитель (business worker) представляет собой абстракцию человека или программной системы, которая представляет роль, выполняемую внутри реализаций бизнес-прецедентов. Исполнитель кооперируется с другими исполнителями, получает уведомления о бизнес-событиях и управляет бизнес-сущностями для реализации их ответственностей.

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

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

Помеченные значения

Нотация

Правила форматирования

Нет дополнительных правил форматирования.

"стереотип" Case Worker

Расширяет

Business Worker

Семантика

Ситуативный исполнитель (Case Worker) - это специальный исполнитель (Business Worker), непосредственно взаимодействующий с актерами вне системы на протяжении транзакции. Например, во время подачи заявления на страховку клиенту назначается работник по имени для обеспечения непрерывности обработки заявления.

Помеченные значения

Нет.

Нотация

Правила форматирования

Нет дополнительных правил форматирования.

"стереотип" owner

Расширяет

"metaClass" Dependency

Семантика

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

Помеченные значения

Нет.

Нотация

Нет.

Правила форматирования

---------
-- Существует от <<Business Use Case Realization>> до <<Business Worker>>
context owner inv Between:
  (self.client->size() = 1 and 
    self.client.oclIsKindOf(Collaboration) and
    self.client.stereotype = "Business Use Case Realization") and
  (self.supplier->size() = 1 and 
    self.supplier.oclIsKindOf(Actor) and
self.supplier.stereotype = "Business Worker"))

Пример бизнес-модели UML

Этот пример не является руководством, передовым опытом или полным и исчерпывающим примером, однако он демонстрирует, как соединяются описанные выше элементы. За дополнительной информацией обращайтесь к "Rational Unified Process", в которую входит руководство и дополнительные примеры.

В примере показан простой поток через бизнес-модель провайдера интерактивных услуг печати.

Рисунок 9: Взаимоотношения между моделями Business Use Case и Business Analysis

Модель Business Use Case

Мы начинаем с определения целей бизнес-системы. Она смоделирована как множество классов "Business Goal" с информацией о зависимости, показывающей, как одна цель зависит от завершения одной или более подцелей.

Рисунок 10: Одна цель разделяется на подцели

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

Рисунок 11: Как бизнес-прецедент "Службы заказов" поддерживает цель "Первоклассные сервисы".

Модель Business Analysis

После завершения установки бизнес-прецедентов в предыдущей модели мы создаем одну или более реализаций прецедентов в Business Analysis Model. Такая реализация является стереотипной кооперацией и должна указывать, используя взаимоотношения UML Realization, прецедент, реализацией которого является.

Рисунок 12: Реализации прецедентов в Business Analysis Model

В приведенной выше диаграмме мы просто создали реализацию пока для одного прецедента в нашей модели. В поддержку реализации в Business Analysis Model мы разрабатываем множество исполнителей, сущностей, событий и правил. Это статическое подмножество Business Analysis Model часто называется "Domain Model".

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

Рисунок 13: Разделенное множество исполнителей

Теперь мы укажем бизнес-сущности и несущие информацию элементы Domain Model, что показано на диаграмме ниже. Обратите внимание, что в модели имеется бизнес-событие, запускаемое сущностью "Service" при изменении своих деталей, разрешая, таким образом, уведомление других сущностей, исполнителей и актеров об этих изменениях. Мы также видим указанное в сущности "Catalog" бизнес-правило. В данном случае мы используем стандартную нотацию UML для ограничений, а не стереотипную нотацию в профиле.

Рисунок 14: Поведенческая модель

Поведенческая модель может быть указана при помощи UML Collaborations (коопераций), Message Sequence Charts (диаграмм последовательностей сообщений), State Machines (конечных автоматов) или Activity Diagrams (диаграмм активности). В приведенном ниже примере мы видим начало диаграммы активности, показывающее, как актер покупателя взаимодействует с бизнесом. Нет необходимости завершать статическую (доменную) часть модели перед моделированием поведения; фактически, эскиз модели поведения может быть полезен для обнаружения необходимых доменных сущностей. Это итеративный процесс.

Рисунок 15: Диаграмма активности