Как изображается бизнес сущность business entity на диаграмме классов

Одним из несомненных достоинств языка UML является наличие механизмов расширения, которые позволяют ввести в рассмотрение дополнительные графические обозначения, ориентированные для решения задач из определенной предметной области . Язык UML содержит два специальных расширения: профиль для процесса разработки программного обеспечения (The UML Profile for Software Development Processes) и профиль для бизнес-моделирования (The UML Profile for Business Modeling ).

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

• Управляющий класс (control class) — класс , отвечающий за координацию действий других классов . На каждой диаграмме классов должен быть хотя бы один управляющий класс , причем количество посылаемых объектам управляющего класса сообщений мало, по сравнению с числом рассылаемых ими. Управляющий класс отвечает за координацию действий других классов . У каждой диаграммы классов должен быть хотя бы один управляющий класс , контролирующий последовательность выполнения действий этого варианта использования. Как правило, данный класс является активным и инициирует рассылку множества сообщений другим классам модели. Кроме специального обозначения управляющий класс может быть изображен в форме прямоугольника класса со стереотипом > (рис. 5.3, а).
• Класс -сущность (entity class) — пассивный класс , информация о котором должна храниться постоянно и не уничтожаться с выключением системы. Класс -сущность содержит информацию, которая должна храниться постоянно и не уничтожается с уничтожением объектов данного класса или прекращением работы моделируемой системы, связанные с выключением системы или завершением программы. Как правило, этот класс соответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции – присоединенными или хранимыми процедурами. Этот класс пассивный и лишь принимает сообщения от других классов модели. Класс -сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом > (рис. 5.3, б).
• Граничный класс (boundary class) — класс , который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы. Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом > (рис. 5.3, в).

ER диаграммы

Рис. 5.3. Графическое изображение классов для моделирования программного обеспечения

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

• Сотрудник (business worker) — класс , служащий на диаграмме классов для представления любого сотрудника, который является элементом бизнес-системы и взаимодействует с другими сотрудниками при реализации бизнес-процесса. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом > или > (рис. 5.4, а).
• Сотрудник для связи с окружением (caseworker) – класс , служащий для представления в бизнес-системе такого сотрудника, который, являясь элементом бизнес-системы, непосредственно взаимодействует с актерами (бизнес-актерами) при реализации бизнес-процесса. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом > (рис. 5.4, б).
• Бизнес-сущность (business entity) — специальный случай класса -сущности, который также не инициирует никаких сообщений. Этот класс служит для сохранения информации о результатах выполнения бизнес-процесса в моделируемой бизнес-системе или организации. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом > (рис. 5.4, в).

Лабораторная работа №5 создание ER-диаграммы в Drow.io (https://app.diagrams.net)

Рис. 5.4. Графическое изображение классов для моделирования бизнес-систем

Интерфейс

Интерфейс (interface) — именованное множество операций , которые характеризуют поведение отдельного элемента модели.

Интерфейс в контексте языка UML является специальным случаем класса , у которого имеются операции , но отсутствуют атрибуты . Для обозначения интерфейса используется специальный графический символ окружность или стандартный способ – прямоугольник класса со стереотипом > ( рис. 5.5).

На диаграмме классов интерфейс изображается в виде маленького круга, рядом с которым записывается его имя (рис. 5.5, а). В качестве имени может использоваться существительное, которое характеризует соответствующую информацию или сервис, например, » Датчик температуры «, » Форма ввода «, » Сирена «, » Видеокамера » (рис. 5.5, б).

С учетом языка реализации модели имя интерфейса , как и имена других классов , рекомендуется записывать на английском и начинать с заглавной буквы I , например, ITemperatureSensor , IsecureInformation (рис. 5.5, в).

Рис. 5.5. Примеры графического изображения интерфейсов на диаграммах классов

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

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

Источник: intuit.ru

RATIONAL UNIFIED PROCESS

Объектно-ориентированный подход к моделированию биз­нес-процессов с использованием языка UML реализован в техно­логии Rational Unified Process. Методика моделирования, являю­щаяся составной частью данной технологии, предусматривает построение двух моделей:

· модели бизнес-процессов (Business Use Case Model);

· модели бизнес-анализа (Business Analysis Model).

Модель бизнес-процессов — модель, описывающая бизнес-про­цессы организации в терминах ролей и их потребностей. Она представляет собой расширение модели вариантов использова­ния UML за счет введения набора стереотипов Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования).

Business Actor (действующее лицо бизнес-процессов) — это не­которая роль, внешняя по отношению к бизнес-процессам орга­низации. Потенциальными кандидатами в действующие лица, бизнес-процессов являются:

· местные органы власти;

· сотрудники подразделений организации, деятельность которых не охвачена моделью;

Список действующих лиц составляется путем ответа на следу­ющие вопросы:

Кто извлекает пользу из существования организации?

Кто помогает организации осуществлять свою деятельность?

Кому организация передает информацию и от кого получает?

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

Это определение подобно общему определению бизнес-процесса, по имеет более точный смысл. В терминах объектной мо­дели Business Use Case представляет собой класс, объектами кото­рою являются конкретные потоки событий в рамках описывае­мою бизнес-процесса.

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

Каждый Business Use Case отражает цель или потребность некоторого действующего лица. Например, если рассмотреть процесс регистрации пассажиров в аэропорту (рис. 3.11[22]), то его основным действующим лицом будет сам Пассажир, главная цель которого в данном процессе — пройти регистрацию. Эта цель моделируется в виде Business Use Case с наименованием «Пройти регистрацию».

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

Рис. 3.11. Диаграмма вариантов использования для процесса регистрации

пассажиров в аэропорту

Описание Business Use Case представляет собой специфика­цию, которая, подобно обычному варианту использования, сос­тоит из следующих пунктов:

· цели и результаты (с точки зрения действующего лица);

· описание сценариев (основного и альтернативных);

· специальные требования (ограничения по времени выпол­нения или другим ресурсам);

· расширения (исключительные ситуации);

· связи с другими Business Use Case;

· диаграммы деятельности (для наглядного описания сцена­риев при необходимости).

Пример спецификации Business Use Case:

Наименование — пройти регистрацию.

Краткое описание — данный Business Use Case реализует процесс регистрации пассажира на рейс.

Цели — получить посадочный талон и сдать багаж.

Основной сценарий.

1. Пассажир встает в очередь к стойке регистратора.

2. Пассажир предъявляет билет регистратору.

3. Регистратор подтверждает правильность билета.

4. Регистратор оформляет багаж.

5. Регистратор резервирует место для пассажира.

6. Регистратор печатает посадочный талон.

7. Регистратор выдает пассажиру посадочный талон и квитанцию на багаж.

8. Пассажир уходит от стойки регистратора.

Альтернативные сценарии.

За. Билет неправильно оформлен — регистратор отсылает пассажи­ра к агенту по перевозкам.

4а. Багаж превышает установленный вес — регистратор оформляет доплату.

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

Описание Business Use Case может сопровождаться целью процесса, которая, так же, как и в методе Eriksson-Penker, моделируется с помощью класса со стереотипом «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 «Пройти регистрацию» приве­ден на рис. 3.12.

Рис. 3.12. Диаграмма классов модели бизнес-анализа

Рис. 3.13. Диаграмма последовательности для основного сценария

Business Use Case «Пройти регистрацию»

На данной диаграмме ассоциации между классами-исполнителями отражают наличие взаимодействия между реальными испол­ин гелями (Регистратором и Координатором багажа). Ассоциации между классами-исполнителями и классами-сущностями показывают, какими именно объектами манипулируют конкретные ис­полнители (Регистратор имеет дело с Багажом и Багажной биркой, а Координатор багажа — только с Багажом). Ассоциации между классами-сущностями отражают различные структурные связи (к одному месту багажа прикрепляется одна багажная бирка).

Кроме диаграммы классов, модель бизнес-анализа может включать:

· Диаграммы последовательности (и кооперативные диаграм­мы), описывающие сценарии Business Use Case в виде после­довательности обмена сообщениями между объектами действующими лицами и объектами-исполнителями. Такие диаграммы помогают явно определить в модели обязанности каждого исполнителя в виде набора его операций.

Пример диаграммы последовательности, описывающей основной сценарий Business Use Case «Пройти регистрацию», приве­ден на рис. 3.13. Модифицированная диаграмма классов мо­дели бизнес-анализа с операциями приведена на рис. 3.14.

· Диаграммы деятельности с потоками объектов и «плава­тельными дорожками», описывающие взаимосвязи между сценариями одного или различных Business Use Case. При­мер такой диаграммы для процесса заказа товаров в торго­вой компании приведен на рис. 3.15.

· Диаграммы состояний, описывающие поведение отдельных бизнес-объектов (например, для сущности «Багаж» можно описать переходы между состояниями «Определен вес», «Зарегистрирован», «Находится на транспортере» и т.д.).

Рис. 3.14. Модифицированная диаграмма классов модели

бизнес-ана­лиза с операциями

Рис. 3.15. Диаграмма деятельности для процесса заказа товаров

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

· Все действующие лица, варианты использования и диаграм­мы вариантов использования для бизнес-процессов поме­щаются в пакет с именем Business Use Case Model.

· Все классы и диаграммы моделей бизнес-анализа помеща­ются в пакет с именем Business Analysis Model.

· Если моделируется деятельность более чем одного подраз­деления организации, то совокупность всех классов-испол­нителей и классов-сущностей из моделей бизнес-анализа для различных Business Use Case разделяется на пакеты, со­ответствующие этим подразделениям. Этим пакетам прис­ваиваются наименования подразделений (например, Бухгалтерия, Отдел доставки и т.п.) и стереотип «organization unit» (организационная единица).

· Диаграммы модели бизнес-анализа, относящиеся к конк­ретному Business Use Case (диаграммы классов, последова­тельности, деятельности и состояний) помещаются в коопе­рацию (см. подразд. 2.6) с именем данного Business Use Case и стереотипом «business use-case realization» (реализация биз­нес-процесса). Все кооперации помещаются в пакет с име­нем Business Use Case Realizations.

Пример структуры бизнес-модели для процесса регистрации пассажиров в аэропорту приведен на рис. 3.16.

Рис. 3.16. Пример структуры бизнес-модели

Методика моделирования Rational Unified Process обладает следующими достоинствами:

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

· моделирование на основе вариантов использования способ­ствует хорошему пониманию бизнес-модели со стороны за­казчиков.

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

3.3.2.

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

5. Разработка моделей бизнес сущностей и их состояний

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

5.1. Цель моделирование бизнес сущностей и их состояний

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

5.2. Использование диаграммы классов или функций для разработки модели бизнес сущностей

Для разработки модели с описанием документа или бизнес сущности в Rational Rose следует использовать диаграмму классов (class diagram) или диаграмму функций (use case diagram). Бизнес сущность (business entity), представляет абстракцию сущности реального мира. Примерами бизнес сущности могут являться заявка на кредитование, договор, сделка и т.д.

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

Для создания описания документов/бизнес сущностей используется компоненты диаграммы классов/функций:

бизнес сущность (business entity);

ассоциативная связь (association);

связь агрегация (aggregation);

связь композиция (composition);

связь наследование или родитель потомок (generalization).

Пакет (рис. 5.1) используется для группировки бизнес сущностей.

Рис. 5.1. Пример пакета для группировки бизнес сущностей

Элемент бизнес сущность представлен на рис. 5.2.

Рис. 5.2. Примеры элементов диаграммы классов/функций для изображения бизнес сущностей

Бизнес сущности имеют атрибуты. При описании атрибутов бизнес сущности в Rational Rose должны указываться:

начальное значение атрибута (опционально);

правила формирования атрибута;

примеры значений атрибута.

Пример бизнес сущности с атрибутами представлен на рис. 5.3.

Рис. 5.3. Пример модели документа Заявка клиента

Для задания типов атрибутов могут использоваться типы данных, зарезервированные в Rational Rose или другие типы, например:

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

Тип данных символ можно использовать для описания строк символов, например, «символ (100)».

Тип данных «дата» можно использовать для атрибутов, которые являются датами.

Тип данных «время» можно использовать для атрибутов, которые являются временем.

Тип данных «логическое значение» можно использовать для атрибутов, которые могут принимать два значения, например «истина», «ложь».

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

Для задания стереотипов атрибутов можно использовать два значения обязательный «О» и необязательный «Н».

Начальное значение атрибута не является обязательным полем.

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

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

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

Если атрибут задается типом данных объект, то начальное значение может задается как имя файла, в котором храниться объект, например, фотография или чертеж.

Ассоциативная связь (association) между бизнес сущностями (business entity) есть смысловая связь. Связь не объясняет, как сущности общаются друг с другом, отмечается только смысловая зависимость между ними. Ассоциативная связь (association) изображается на диаграмме классов сплошной прямой линией.

Пример ассоциативной связи между бизнес сущностями представлен на рис. 5.4.

Рис. 5.4. Пример ассоциативных связей между бизнес сущностями

Ассоциативная связь может быть поименована. Имя ассоциации указывается, исходя из контекста. Рекомендуется указывать имя ассоциации так, чтобы оно читалось корректно слева направо или сверху вниз.

Связь композиция обозначает связь часть целого (part of), где часть не может существовать без целого. Например, журнал включает заголовок журнала и строки журнала.

Композиция (composition) изображается сплошной прямой линией с добавлением на конце закрашенного ромба как представлено на рис. 5.5. Закрашенный ромб указывает на целое.

Рис. 5.5. Пример связей композиции между бизнес сущностями

Связь агрегация обозначает связь часть целого (part of), где часть может существовать без целого (контейнер). Пример связи агрегация представлен на рис. 5.6.

Рис. 5.6. Примеры связей агрегация между бизнес сущностями

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

Мощность связи может обозначаться следующим образом:

1 – ровно одна бизнес сущность;

0. * — ноль или больше бизнес сущностей;

1..*- одна или больше бизнес сущностей;

0..1 — ноль или одна бизнес сущность;

5..8 — специфический диапазон 5,6,7,8;

4..7, 9 — комбинация 4,5,6,7, или 9 бизнес сущностей.

Примеры мощностей связи композиции и агрегации между бизнес сущностями представлены на рис. 5.4, 5.5.

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

Мощность связи со стороны закрашенного ромба не следует указывать, так как она всегда равна 1 по нотации языка UML.

Наследование или связь родитель потомок (generalization) между бизнес сущностями это такое отношение между ними, когда одна бизнес сущность повторяет структуру другой производственной сущности (одиночное наследование) или других сущностей (множественное наследование).

Связь наследование (generalization) не именуется, на ней также не указывается мощность.

На диаграммах классов наследование (generalization) изображается стрелкой с не закрашенным треугольником, обращенным к сущности, от которой наследуются свойства. Пример изображения связи наследования (generalization) представлен на рис. 5.7.

Рис. 5.7. Примеры связи наследование

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

Рис. 5.8. Пример организационной единицы

Источник: studfile.net