Моделирование предметной области на UML

Основные вопросы:

- объектно-ориентированный анализ и проектирование АИС;

- характеристика языка UML;

- бизнес-расширение языка UML;

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

- элементы и диаграммы UML для моделирования предметной области;

- построение UML-модели предметной области.

 

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

Основные принципы объектной модели – абстракция, инкапсуляция, модульность, иерархия, контроль типов, параллелизм и персистентность.

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

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

Для создания АИС разрабатываются две модели:

- объектная модель предметной области (UML-ПрО);

- объектная модель системы (UML-АИС).

Для моделирования ПрО и создаваемой системы в рамках OOAD широко используется язык UML.

Унифицированный язык моделирования (Unified Modeling Language, UML) – это универсальный язык визуального моделирования систем.

Будущее UML, по предложению OMG, ориентация на архитектуру системы, управляемую моделью (Model Driven Architecture, MDA).

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

В UML-модели отражаются два аспекта:

- статическая структура – описывает, какие типы объектов важны для моделирования системы и как они взаимосвязаны.

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

UML позволяет моделировать мир как систему взаимодействующих объектов. Объект – это целостный блок, состоящий из данных и функциональности.

Структура UML включает:

- строительные блоки – основные элементы, отношения и диаграммы UML-модели;

- общие механизмы – общие UML-пути достижения определенных целей;

- архитектура – UML представление архитектуры системы.

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

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

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

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

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

Типы диаграмм UML

№ п / п	Диаграмма	Цель

Структурные диаграммы

1 Классов Class diagram Классы, свойства и отношения 2 Объектов Object diagram Вариант конфигурации экземпляров 3 Компонентов Component diagram Структура и взаимосвязи между компонентами 4 Составных структур Composite structure diagram Декомпозиция класса во время выполнения 5 Развертывания Deployment diagram Развертывание артефактов в узлы 6 Пакетов Package diagram Иерархическая структура времени компиляции  

Диаграммы поведения

7 Вариантов использования (прецедентов) Use case diagram Как пользователи взаимодействуют с системой 8 Деятельности Activity diagram Процедурное и параллельное поведение 9 Конечных автоматов State Machine diagram Как события изменяют объект в течение его жизни  

Диаграммы взаимодействия

10 Коммуникации Communication diagram Взаимодействие между объектами; акцент на связях 11 Обзора взаимодействий Interaction overview diagram Комбинация диаграммы последовательности и диаграммы деятельности 12 Последовательности Sequence diagram Взаимодействие между объектами; акцент на последовательности 13 Временная Timing diagram Взаимодействие между объектами; акцент на синхронизации

 

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

Основными задачами при моделировании предметной области являются описание:

- бизнес-процессов предприятия;

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

- бизнес-сущностей;

- сценариев выполнения бизнес-функций, подлежащих автоматизации;

- состояний бизнес-сущностей;

- бизнес-правил.

Основные аспекты предметной области отображаются в следующих UML-диаграммах.

Аспект моделирования	UML-диаграмма
Предметно-структурный аспект	Package-диаграммы
Функциональный аспект	Use-Case-диаграммы
Организационный аспект	Package-диаграммы, Class-диаграммы
Методический аспект	Activity-диаграммы
Поведенческий аспект	State Machine diagram-, Communication-, Sequence-диаграммы
Сущностно-элементный аспект	Class-диаграммы
Технологический аспект	Deployment-диаграммы (развертывания)

В целом UML-модель предметной области имеет следующий вид:

При моделировании бизнес-процессов в UML-диаграммах используют следующие элементы.

UML-диаграмма	Расширение	Обозначение
Package	Пакеты предметных областей управления или видов деятельности. Стереотип – "Business System"
Package	Пакеты организационных единиц (структурных подразделений). Стереотип – "Organization Unit"
Class	Бизнес-сущности, обозначающие владельцев бизнес-процессов. Стереотип – "Business Actor"
Class	Бизнес-сущности, обозначающие деловых работников (исполнителей). Стереотип – "Business Worker"
Class	Бизнес-сущности, обозначающие объект учёта. Стереотип – "Business Object"
Class	Бизнес-сущности, обозначающие субъекты учёта. Стереотип - "Business Subject"
Class	Бизнес-сущности, обозначающие первичные документы. Стереотип – "Document" (розовый)
Class	Бизнес-сущности, обозначающие учётные регистры. Стереотип – "Registration" (желтый)
Class	Бизнес-сущности, обозначающие отчёты. Стереотип – "Report" (голубой)
Use-Case	Бизнес-процесс (функция). Стереотип – "Business Precess"
Activity	Бизнес-транзакция (операция). Стереотип – "Business Transaction"

 

Основной диаграммной в UML-модели ПрО являются Activity-диаграмм (деятельности), раскрывающие методический аспект бизнес-процессов. Каждая бизнес-операция есть полная или частичная реализация некоторой управленческой функции, результатом выполнения которой есть значимый на том или ином уровне управления результат. Для достижения данного результата при выполнении бизнес-операций используются некоторые материальные, информационные и иные объекты (бизнес-сущности), идентифицированные на Class-диаграммах (классов); выполнение той или иной бизнес-оператции закрепляется за определенным исполнителем, также идентифицированном на Class-диаграмме (классов) из пакета со стереотипом "Organization Unit" (структурное подразделение). Бизнес-сущности в ходе выполнения той или иной бизнес-операции могут менять своё внутреннее состояние, что также находит своё отражение на Activity-диаграммах (деятельности), а полная карта состояний и переходов между ними – на соответствующих той или иной бизнес-сущности State Machine diagram-диаграммах (конечного автомата). Кроме того каждая бизнес-операция или состояние могут быть детализованы, т.е. отражены на вложенных Activity- (деятельности) и State Machine diagram-диаграммах (конечного автомата) соответственно.

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

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

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

 

 

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

При описании бизнес-процессов должны быть выявлены связи между различными подразделениями предприятия при решении конкретных производственных задач (горизонтальные связи). И только в этом случае описание бизнес-процессов может считаться корректным.

Рассмотрим задачу, подлежащую автоматизации: “Оприходование товара на складе предприятия от продавца”.

На рис. 1 представлен пример описания бизнес-процессов с использованием диаграммы деятельности (activity diagram).

Рис. 1. Описание работы склада при оприходовании товара от продавца

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

При этом целесообразно выделить виды деятельности, подлежащие автоматизации. На рис. 1 автоматизируемые виды деятельности выделены цветом:

1. Выписывает доверенность;

2. Выписывает приемный акт в двух экземплярах;

3. Регистрирует товар в картотеке;

4. Передает экземпляр акта в бухгалтерию;

5. Получает приходный акт.

Моделирование бизнес-процессов с помощью диаграмм деятельности имеет следующие преимущества перед другими видами моделирования:

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

2. Четкое ролевое выражение ответственностей за ту или иную деятельность.

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

4. Развитая нотация описания состояний бизнес-сущностей (при использовании объектов).

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

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

На основе этой модели строится модель функций системы.

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

На рис. 2-7 представлены модель структуры предприятия, построенная с использованием диаграммы функций UML (use case diagram).

Рис. 2. Автоматизируемое предприятие

Рис. 3. Автоматизируемые отделы предприятия

Рис. 4. Сотрудники склада и документы склада

Рис. 5. Роли на складе

рис. 6. Задачи кладовщика

Рис. 7. Функции кладовщика по задаче “Оприходование товара на складе от продавца” (цветом помечены выходные документы)

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

Следующей задачей при описании предметной области является моделирование документов.

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

1. Проектирования пользовательского интерфейса системы.

2. Проектирования базы данных системы.

3. Формирования альбома выходных форм системы.

 

Рис. 8. Пример модели документа “Приемный акт” разработанный с использованием диаграммы классов (class diagram) языка UML

 

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

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

На рис. 9 представлен пример сценария работы кладовщика с карточкой товара и накладной, описанного с использованием диаграммы последовательности действий UML (sequence diagram), а на рис. 10 пример диаграммы состояний приемного акта, описанного с использование диаграммы (State Machine diagram).

Рис. 9. Сценарий работы кладовщика с карточкой товара и накладной

Рис. 10. Пример диаграммы состояний (state diagramm) с описанием состояний приемного акта

При описании предметной области не следует забывать о моделировании бизнес-правил. Модели бизнес-правил предметной области будут являться основой для моделирования правил программной системы. Для моделирования бизнес-правил могут использоваться диаграммы деятельностей (activity diagram) и диаграммы классов (class diagram). Диаграммы деятельностей (activity diagram) могут использоваться для моделирования например, алгоритмически описываемых правил, диаграммы классов (class diagram) – для моделирования структурных правил.

Итак, подводя итог выше сказанному об описании предметной области при разработке программных систем, отметим следующее:

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

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

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

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

- Модели сценариев реализации бизнес-функций используются при проектировании сценариев пользовательского интерфейса;

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

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

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

3. Полное и детальное описание предметной области крайне удобно производить в CASE-средстве, поддерживающем язык моделирования UML.

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

3.3. Анализ предметной области и
построение модели “как должно быть”

Основные вопросы:

- анализ модели ПрО и реинжиниринг бизнес-процессов;

- назначение, задачи и методы анализа ПрО;

- назначение, задачи и методы реинжиниринга бизнес-процессов;

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

Построение UML-модели ПрО “как есть” (AS-IS) позволяет понять, что собой представляет реально существующий объект (предприятие, определенная деятельность отдельного человека или некоторого коллектива людей), как он функционирует и как он связан с внешним миром. Однако для создания АС, реализующей определенную функциональность и встраиваемой в объект (ПрО), этого недостаточно.

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

Анализ ПрО производится в два этапа:

- анализ модели ПрО “как есть”;

- построение модели ПрО “как должно быть”.

На основании модели ПрО “как должно быть” разрабатывается ТЗ на создание АС.