Р.В. Алфимов, Е.Б.Золотухина
Моделирование предметной области является одним из наиболее важных этапов работ при проектировании программных систем масштаба предприятия.
В настоящее время для целей моделирования предметной области на рынке программных продуктов представлен широкий спектр CASE-средств. Наиболее популярными в нашей стране CASE-средствами являются Rational Rose, CA BPwin, Silverrun, Sybase PowerDesigner. Моделирование предметной области в этих средствах имеет больше сходств, чем различий. Однако немаловажным, с нашей точки зрения, является комплексность подхода и использование единой унифицированной нотации не только на этапе моделирования предметной области, но и на последующих этапах разработки программной системы, как это имеет место в Rational Rose.
В настоящей статье на конкретном примере демонстрируется возможный подход к моделированию предметной области с использованием унифицированной нотации, основанный на применении унифицированного языка моделирования (Unified Modeling Language, UML) и гармонично сочетающий в себе достоинства структурных и объектных методов проектирования в Rational Rose.
Итак, основными задачами при моделировании предметной области являются описания [1, 2]:
бизнес-процессов предприятия;
действующих лиц бизнес-процессов и их функций, подлежащих автоматизации в привязке к структуре автоматизируемого предприятия;
бизнес сущностей;
сценариев выполнения бизнес-функций, подлежащих автоматизации.
состояний бизнес-сущностей;
бизнес-правил.
Описание бизнес-процессов используется для описания технологии выполнения производственной задачи, подлежащей автоматизации [1]. На основе описанной технологии определяются виды деятельности, которые следует автоматизировать (бизнес-требования к будущей программной системе).
При описании бизнес-процессов должны быть выявлены связи между различными подразделениями предприятия при решении конкретных производственных задач (горизонтальные связи). И только в этом случае описание бизнес-процессов может считаться корректным.
На рис. 1 представлен пример описания бизнес-процессов с использованием диаграммы деятельности (Activity Diagram) UML и Case Rational Rose.
Рассмотрена задача, которую следует автоматизировать: «Оприходование товара на складе предприятия от продавца».
На диаграмме обозначены виды деятельности, связанные с решением задачи, подлежащей автоматизации, входные и выходные документы или данные, связанные с конкретной деятельностью, исполнители различных видов деятельности, а также подразделения, в которых данный вид деятельности выполняется.
На основе описания бизнес-процессов с использованием диаграммы деятельности (Activity Diagram) определяются виды деятельности, которые следует автоматизировать.
Из примера на рис. 1 видно, что таковыми являются (отмечены цветом) следующие виды деятельности:
выписывает доверенность;
выписывает приемный акт в двух экземплярах;
регистрирует товар в картотеке;
передает экземпляр акта в бухгалтерию;
получает приходный акт.
Следует отметить, что накопленный авторам опыт при описании бизнес-процессов с использованием различных CASE-средств, например BPwin, Silverrun, Power Designer и Rational Rose, показал, что наиболее понятным описанием бизнес-процессов для обсуждения его с экспертами предметной области и получения от них конструктивных замечаний является представленная выше нотация в Rational Rose.
На наш взгляд, это объясняется следующими причинами:
соответствие парадигмы диаграммы деятельности представлению пользователей о бизнес-процессе;
четкое ролевое выражение ответственностей за ту или иную деятельность;
возможность совмещения в диаграммах описания документов, связанных с деятельностью и их состояний;
развитая нотация описания состояний бизнес-сущностей (при использовании объектов).
четко отслеживаемые горизонтальные связи между подразделениями, что позволяет структурировать процессы предметной области (абсолютно необходимо для последующих этапов проектирования).
Следующим шагом при описании предметной области является разработка модели структуры предприятия, на которой отражены только действующие лица и их функции, подлежащие автоматизации. Модель отражает иерархическую структуру предприятия (вертикальные связи) [1].
На основе этой модели строится модель функций системы.
Модель структуры предприятия строится на основе описания бизнес-процессов. В модели отражаются только те отделы, те действующие лица и их функции, которые будут автоматизированы. Построение модели можно производить поэтапно, по мере описания бизнес-процессов. Диаграмм с бизнес-процессами может быть очень много, но модель со структурой предприятия должна быть одна.
На рис. 2-7 представлена модель структуры предприятия, построенная с использованием диаграммы функций UML (Use CASE Diagram).
Особенностью модели структуры предприятия является наличие связей по управлению, что в дальнейшем позволит произвести декомпозицию системы на подсистемы последующих уровней и на стадиях анализа и проектирования эффективно применить объектные модели и методы для разработки структуры программных компонентов и данных.
Следующей задачей при описании предметной области является моделирование документов [2].
Цель моделирования документов — описать атрибуты документов, их типы, значения, правила формирования для проектирования пользовательского интерфейса системы, проектирования базы данных системы; формирования альбома выходных форм системы.
На рис. 8 представлен пример модели документа «Приемный акт», разработанный с использованием диаграммы классов (Class Diagram) языка UML в CASE Rational Rose.
Дополнительным преимуществом при моделировании документов в Rational Rose является возможность присоединение к модели документа или бизнес-сущности описания его внешнего вида с примером, подготовленным, например, в редакторе Microsoft Word.
В некоторых случаях при моделировании предметной области следует описать сценарий работы действующего лица с бизнес-сущностями и состояние бизнес-сущностей.
Сценарии функций предметной области могут использоваться при проектировании сценариев работы пользователя с будущей системой, описание состояний бизнес-сущностей — для проектирования пользовательского интерфейса (справочника состояний бизнес-сущностей) и базы данных программной системы. К тому же наличие сценариев бизнес-функций в дальнейшем позволит уточнить функциональные требования к системе.
На рис. 9 представлен пример описанного с использованием диаграммы последовательности действий UML (Sequence Diagram) сценария работы кладовщика с карточкой товара и накладной а на рис. 10 — пример диаграммы состояний приемного акта, описанного с использованием диаграммы состояний (State Diagram).
При описании предметной области не следует забывать о моделировании бизнес-правил [2]. Модели бизнес-правил предметной области будут являться основой для моделирования правил программной системы. Для моделирования бизнес-правил могут использоваться диаграммы деятельностей (Activity Diagram) и диаграммы классов (Class Diagram). Диаграммы деятельностей могут использоваться для моделирования, например, алгоритмически описываемых правил, диаграммы классов — для моделирования структурных правил.
Итак, подводя итог вышесказанному об описании предметной области при разработке программных систем, отметим следующее:
Описание предметной области должно включать не только описание бизнес-процессов но и описание структуры автоматизируемого предприятия, его действующих лиц, их автоматизируемых функций, документов, связанных с автоматизированными функциями, прочих бизнес-сущностей, сценариев реализации бизнес-функций и состояний бизнес-сущностей:
модель бизнес-процессов используется для определения бизнес-требований к разрабатываемой системе и выявления всех связей между подразделениями, принимающими участие в решении конкретной задачи;
модель структуры предприятия используется для отражения действующих лиц предприятия, их автоматизируемых функций в привязке к подразделениям, в которых эти функции выполняются. На основе модели структуры предприятия разрабатывается модель функций системы;
модели документов, бизнес-сущностей используются при проектировании пользовательского интерфейса, базы данных, формирования альбома выходных форм системы;
модели сценариев реализации бизнес-функций используются при проектировании сценариев пользовательского интерфейса;
модели состояний бизнес-сущностей используются при проектировании пользовательского интерфейса и базы данных системы;
модели бизнес-правил используются при моделировании правил программной системы.
Результаты бизнес-моделирования в CASE-средстве Rational Rose могут быть легко преобразованы в документацию, соответствующую промышленным стандартам разработки программных систем.
Полное и детальное описание предметной области очень удобно производить в CASE-средстве, поддерживающем универсальный язык моделирования UML.
В отличие от CASE Rational Rose популярные в нашей стране BPwin, Silverrun, Process Analist не имеют пока полноценной поддержки всех перечисленных выше этапов бизнес-моделирования, что ограничивает сферу их применения.
Описание предметной области с использованием UML хорошо воспринимается экспертами предметной области и для понимания представленных им на рассмотрение моделей не требует никакой специальной подготовки.
К примеру, как показывает опыт авторов, модели процессов, построенные в BPwin, вызывают трудности при понимании их экспертами предметной области. Это приводит к тому, что эксперты становятся пассивными слушателями при обсуждении описания бизнес-процессов и им, по существу, навязывается понимание бизнес-процессов аналитиками. Ошибки неправильного описания бизнес-процессов затем выявляются, но к сожалению, на более поздних этапах разработки программной системы.
В заключение хотелось бы отметить, что мы не навязываем своего мнения относительно достоинств или недостатков того или иного CASE-средства, но, на наш взгляд UML использование Rational Rose и других CASE-средств, поддерживающих для целей, обозначенных в статье, является предпочтительным.
Литература:
КомпьютерПресс 4'2001