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