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

В настоящее время для целей моделирования предметной области на рынке программных продуктов представлен широкий спектр 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. Функции кладовщика по задаче "Оприходование товара на складе от продавца" (цветом помечены выходные документы)

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

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

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

1. Проектирования пользовательского интерфейса системы;
2. Проектирования Базы данных системы;
3. Формирования альбома выходных форм системы;

На рис. 8. представлен пример модели документа "Приемный акт" разработанный с использованием диаграммы классов (class diagram) языка UML в CASE Rational Rose:

Дополнительным преимуществом при моделировании документов в Rational Rose является возможность присоединение к модели документа или бизнес-сущности описание его внешнего вида с примером, например, подготовленного в редакторе Word или в средствах визуального проектирования интерфейсов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

P.S. Авторы выражают глубокую благодарность слушателям курса "Объектный анализ и проектирование программных систем с использованием CASE Rational Rose", регулярно читаемого в Учебно-консалтинговом центре Interface Ltd, за участие в разработке примера по описанию предметной области для целей проектирования программной системы в качестве экспертов предметной области.