ЧАСТЬ 2. Модель Rational Rose
«Rational это не только ценный программный продукт, это еще и 3-4 килограмма легкоусвояемой документации»
Я.
Контекстную диаграмму здесь нам заменит диаграмма прецедентов или Use Case – диаграмма (рис.1). Она определяет, - что система будет делать (а не как она будет это делать).
Что на ней отражается? Отражаются на ней основные прецеденты. Еще их называют сценарии, варианты использования.
Прецеденты определяют функциональные возможности системы. Каждый из них представляет определенный способ использования системы. Таким образом, каждый прецедент соответствует последовательности действий, выполняемых системой для того, чтобы клиент мог получить определенный результат. Здесь прецедентами являются: Проконсультировать, Заключить договор страхования, Выплата страхового возмещения.
Это означает, что клиент является инициатором некоего процесса, а страховое агентство, - его исполнителем.
Клиент и Страховое агентство, - это классы. UML, в целях удобства группировки классов по их назначению позволяет присваивать им стереотип, а Rose дает возможность отображать их графически. Так, клиент имеет стереотип Business Actor (бизнес – актер). Между актером и прецедентом устанавливается связь, которая называется ассоциацией.
Диаграмма прецедентов это, по-сути, модель функций предметной области. Она отражает внешние связи системы. Это взгляд на систему извне, с точки зрения заказчика.
Эта диаграмма уже наталкивает на мысль о том, что надо провести определение и классификацию основных объектов. Сделаем это с помощью диаграммы классов, на которой отобразим Деловых работников(Business Worker). Они связаны между собой ассоциациями и генерализациями.
Ассоциация отображается простой стрелкой и означает, что Сотрудник агентства - работает в Страховом агентстве. Генерализация отображается треугольной стрелкой и означает, что Консультант, Страховщик, Кассир и т.д., являются сотрудником агентства. Это очень полезно, т.к. позволяет в некоторых случаях описывать конкретную роль, а когда этого не требуется, использовать обобщенное понятие (вместо того, чтобы рисовать их всех). Так как все они являются сотрудниками агентства, они имеют некоторые общие свойства. Но каждый из них имеет и свои особенности. Можно еще было бы отразить, что Сотрудник агентства может быть мужчиной или женщиной, а они, в свою очередь, являются людьми. Но это было бы лишним, т.к. выходит за рамки нашей модели. (Если, конечно, мы не будем рассматривать автоматизацию туалетов :).
Клиент, в свою очередь, может быть юридическим или физическим лицом (Рис. 3).
Пока мы отразили только одну сторону бизнес-процессов на основе Use Case. Для дальнейшего уточнения процессов могут использоваться и другие диаграммы.
Прецедент может описывать несколько Сценариев (последовательностей).
Сценарий – это некоторая последовательность действий, иллюстрирующая поведение системы. Он описывается диаграммами действий (Activity). Диаграмма действий в модели деловых прецедентов иллюстрирует поток работ делового прецедента.
Так диаграмма действий, описывающая прецедент «Проконсультировать», будет выглядеть следующим образом (рис. 4).
Здесь все, примерно, как и в модели BPWin. Диаграмма действий по-сути соответствует IDEF3.
При обращении клиента (точка инициации) консультант выполняет поиск информации и сообщает ответ клиенту. Ну мы не будем рассматривать случай, когда ответа нет. Хотя надо бы!
Данная диаграмма, для обозначения ответственных за шаг процесса использует разделительные линии (Swim Lines). Такое, кстати, есть и в BPWin.
При построении диаграммы сразу возникает вопрос: что необходимо для поиска информации? По нашей модели - это законодательство и инструкции. Значит необходимо создать соответствующие классы и объекты. Сделаем это на диаграмме, которую назовем «Документы».
Общее описание документов можно представить в следующем виде.
Документы агентства можно разделить на внешние, которые поступают от других организаций, и внутренние, которые изготавливаются в самом агентстве. Внутренние документы закрашены желтым.
Аналогичным образом построим диаграмму документов клиента (Рис.7).
Можно, конечно продолжать детализацию: инструкции поделить на внутренние и от головной организации. Далее перечислить конкретные инструкции с номерами. Так, кстати, и надо делать в реальной модели. При дальнейшей проработке в свойствах каждого документа можно указать атрибуты и операции. Атрибуты класса – отражают состояние объекта или его данные. Операции класса, это реализация услуги, которую можно запросить у любого объекта класса. Это то, что позволено делать с объектом.
Еще в Rose имеется хорошая возможность связать объект с конкретным файлом документа. Войдя в свойства объекта можно вызвать этот документ.
Теперь настало время подумать над организационной структурой агентства. Отобразим ее на диаграмме прецедентов (Рис. 8).
Она читается следующим образом. Страховое агентство включает в свой состав: начальника, договорный отдел, отдел страховых выплат, кассу. Страховщик и консультант являются сотрудниками договорного отдела. Инспектор является сотрудником отдела страховых выплат.
Теперь продолжим и опишем реализацию прецедента «Заключить договор страхования».
В этом процессе участвуют; клиент, страховщик, кассир и начальник. Входными данными являются документы клиента. Выходными – страховой полис. Хочу обратить внимание, что на диаграмме деятельности присутствуют не классы, а объекты. Объект инкапсулирует данные и поведение класса. Данные объекта представляются атрибутами, а его поведение - операциями. Объект определяется в классе. Ну это очень научно я загнул. Проще говоря, объект, - это конкретная реализация класса. Например, в данном случае, это конкретный страховой полис, выданный конкретному клиенту.
В принципе клиента можно исключить. Зеленым отмечен выходной документ. Сюда можно поместить документы, предварительно создав объект и потом перетащив на него нужный класс.
Диаграмма реализации прецедента «Выплата страхового возмещения» будет иметь следующий вид (Рис. 10).
Здесь она выполнена без Swim line, что не запрещается. Пунктирными стрелками обозначены потоки объектов (данных).
Итак, какие же можно отметить недостатки продукта Rational Rose:
- нельзя показать и удалить неиспользуемые объекты в отличие от BPWin;
- недостаточно функциональная графика (нельзя менять толщину линий, надписи не центрируются, текст не всегда можно поместить целиком, иногда он обрезается);
Но это все мелочи! Чего нет в Rose принципиально? А нет в ней возможности отобразить потоки данных между объектами или процессами. UML – другая методология, использующая объектно–ориентированный подход, и такие диаграммы в ней не предусмотрены. А очень их не хватает на начальном уровне проектирования!
Зато там много других достоинств:
- современный интерфейс;
- гораздо легче делать классификацию объектов, Rose нацелена на это;
- возможность добавлять новые уровни в виде пакетов (папок);
- легко перетаскивать объекты из одного пакета в другой;
- есть возможность присоединения к объектам документов.
Итак, в данной работе мы выполнили моделирование предметной области, которое включает:
1. Модель функций предметной области (Business Use case model) – рис.1, 4, 9, 10;
2. Модель объектов предметной области (Business object model) – рис.2, 3, 5-8;
3. Спецификации, описывающие производственный процесс – вот этого мы не делали;
4. Словарь терминов предметной области – ну это в принципе ясно.
Мы сделали только первый шаг, - начало построения модели системы. Дальнейшими шагами должны быть:
- Моделирование реализации системы (Use case model). Цель – определить функции создаваемой автоматизированной системы.
- Определение требований (Requirements). Цель - определить, что система должна делать, согласовать это с заказчиком и задокументировать. Основным результатом этапа определения требований к системе является:
1. Модель функций системы (Use case model), т.е., фактически описание автоматизируемых функций.
2. Прототип пользовательского интерфейса (User-Interface Prototype).
3. Спецификации функций системы (Supplementary Specifications).
- Анализ и проектирование. Цель - преобразовать требования к системе в проект системы. Основным результатом здесь является модель стадии проектирования (Design Model). Она показывает каким образом функции системы будут реализовываться посредством объектов и классов.
Ну и далее: разработка, тестирование, внедрение. Когда-нибудь, в другой статье, мы на этом остановимся подробнее. Просто Rational, - это очень большая система. И предназначена она не только, даже, не столько для описания бизнес – процессов, сколько для поэтапного создания больших автоматизированных систем, большими коллективами, их тестирования, внедрения и поддержки.
