Объектное моделирование систем

 

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

- объектная методология моделирования систем;

- универсальный язык моделирования систем (UML);

- моделирование структурной и функциональной частей системы;

- примеры построения объектных моделей для реальных объектов.

 

Существуют два подхода к моделированию систем: структурный и объектный. Каждый подход базируется на собственных моделях и на собственном подходе к декомпозиции системы.

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

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

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

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

- абстрагирование;

- инкапсуляция;

- наследование;

- полиморфизм.

Кроме этих принципов также используются: модульность, иерархичность, типизация, параллелизм и сохраняемость (персистентность).

Объектное моделирование систем мы рассмотрим на примере моделирования предметной области (ПрО).

Для представления модели системы в объектной методологии моделирования широко используется язык 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-модели ПрО являются 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 хорошо воспринимается экспертами предметной области и не требует от них никакой специальной подготовки для понимания представленных им на рассмотрение моделей.

 

Проектирование систем