Пример описания предметной области с использованием Unified Modeling Language (uml) при разработке программных систем

Е.Б. Золотухина, Р.В. Алфимов (c) Interface Ltd., 2001

Моделирование предметной области является одним из наиболее важных этапов работ при проектировании программных систем масштаба предприятия.

В настоящее время для целей моделирования предметной области на рынке программных продуктов представлен широкий спектр CASE-средств. Наиболее популярными в нашей стране CASE-средствами являются Rational Rose, BPwin, Silverrun, Process Analyst. Моделирование предметной области в этих средствах имеет скорее много общего, чем различий. Однако немаловажным, с нашей точки зрения, является комплексность подхода и использование единой унифицированной нотации, не только на этапе моделирования предметной области, но и на последующих этапах разработки программной системы, как это имеет место в CASE Rational Rose.

В настоящей статье на конкретном примере демонстрируется возможный подход к моделированию предметной области с использованием унифицированной нотации, основанный на применении Унифицированного Языка Моделирования (Unified Modeling Language) (UML), и гармонично сочетающий в себе достоинства структурных и объектных методов проектирования в CASE Rational Rose.

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

1. Бизнес-процессов предприятия;

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

3. Бизнес-сущностей;

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

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

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

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

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

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

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

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

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

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

Из примера на рис. 1 видно, что таковыми являются (функции отмечены цветом) следующие виды деятельности:

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

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

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

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

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

Следует отметить: наш значительный опыт при описании бизнес-процессов с использованием различных CASE-средств, например, BPwin, Silverrun, Process Analyst и Rational Rose показал, что наиболее понятным описанием бизнес-процессов для обсуждения его с экспертами предметной области и получения от них конструктивных замечаний является представленная выше нотация в CASE Rational Rose.

На наш взгляд, причинами этого являются:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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