Инструментарий построения диаграмм

 

Для работы с диаграммами UML в настоящее время имеется целый ряд инструментов, от примитивных "рисовалок" уровня чуть ли не Paintbrush до серьезных сложных пакетов сквозного проектирования программных комплексов с поддержкой моделей COM и CORBA.

Лично я использовал в работе два продукта: Microsoft Visio for Enterprise Architect и AllFusion Component Modeler от Computer Associates. Первый продукт достаточно прост в использовании, однако его функциональность довольно ограничена. К его достоинствам можно отнести неплохую интеграцию с Microsoft Visual Studio .NET, в частности, возможность reverse engineering — построение диаграмм UML по тексту программы, а также ограниченную возможность генерации кода по диаграммам.

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

Имеются и другие продукты, заслуживающие упоминания, в частности, Rose фирмы Rational. Однако отсутствие адекватных средств системного анализа, а также поддержки языка C# на момент начала моей работы с UML предопределило выбор в пользу AllFusion. Возможно, ситуация с тех пор изменилась.

 

Заключение

 

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

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

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

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

 

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

· Базовыми элементами диаграммы вариантов использования являются эктор и вариант использования.

· Эктор(актер)(Actor) – согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними.

· Вариант использования (Use Case), или прецедент, – внешняя спецификация последовательности действий, которые система или другая сущность могут выполнять в процессе взаимодействия с экторами.

· Таким образом, диаграмма прецедентов – это графическое представление экторов и прецедентов и их взаимодействия в системе.

·

· Экторы. Экторы (актеры) – это роли, исполняемыми сущностями, непосредственно взаимодействующими с системой.

· В литературе очень часто вместо термина «эктор» используется термин «актер», который мы и будем использовать в дальнейшем изложении.

· В языке UML актеры изображаются в виде пиктограммы «анимационный человечек» или в виде пиктограммы класса (рис. 5.6). Актеры представляют собой роли, а не конкретных людей или наименования работ. Актерами могут быть как люди (пользователи данной системы), так и внешние системы, которым необходима некоторая информация от данной системы. Большинство разработчиков моделей предпочитают использовать пиктограммы «человечек» для тех ролей, которые будут исполняться людьми, а пиктограммы класса – для тех ролей, которые будут играть другие системы.

·

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

·

·

·

· Рис. 5.6. Варианты изображения актера

· на диаграмме прецедентов

·

· Можно выделить три основных типа актеров:

· – пользователи системы;

· – другие системы, взаимодействующие с данной;

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

·

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

· Актера «время» отображают на диаграмме прецедентов, если необходимо смоделировать событие, происходящее с системой в определенный момент времени, но не инициируемое ни одним из других актеров. Примерами событий, которые могут инициироваться актером «время», являются автоматическое сохранение документа каждые 10 мин, создание резервной копии системы, выполняемое ежедневно вечером, закрытие окна-заставки через 5 с, смена изображения рекламного баннера на сайте.

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

· Прецеденты.В книге «UML 2 и унифицированный процесс. Практический объектно-ориентированный анализ и проектирование» Дж. Арлоу и А. Нейштадт определяют прецедент как описание последовательности действий, которые выполняют система, подсистема или класс.

· Варианты использования в контексте процесса управления требованиями к системе согласно А. Коберну (Коберн А. Современные методы описания функциональных требований к системам : пер. с англ. М. : Лори, 2002. 263 c.) трактуются следующим образом:

· – вариант использования фиксирует соглашение между участниками проекта относительно поведения системы;

· – вариант использования описывает поведение системы при различных условиях, когда система отвечает на запрос одного из участников, называемого основным действующим лицом;

· – основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвечает, соблюдая интересы всех участников.

· Пиктограмма прецедента представляет собой овал (рис. 5.7). Имя прецедента, как правило, записывается внутри овала, хотя может указываться и под ним.

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

·

 

·

· Рис. 5.7. Пиктограмма прецедента

· ОтношенияОтношения – семантические (значимые) связи между элементами модели.

· На диаграмме прецедентов могут использоваться следующие типы отношений:

· – ассоциация (Аassociation) – для отношений между актерами и прецедентами;

· – включение (Include) и расширение (Еxtend) – для отношений между прецедентами и прецедентами;

· – обобщение (Generalization) – для отношений между актерами и актерами и прецедентами и прецедентами.

· Отношение ассоциации служит для обозначения специфической роли актера при его взаимодействии с отдельным вариантом использования, отражая связь актера и варианта использования. Ассоциация может быть простой или направленной.

· Простая ассоциация отражается линией без стрелки, проведенной между актером и вариантом использования (рис. 5.8).

·

· Рис. 5.8. Отношение простой ассоциации

·

· Направленная ассоциация обозначается линией со стрелкой. Связь может быть как от актера к прецеденту, так и наоборот. Направление связи показывает, кто является ее инициатором: актер или прецедент (рис. 5.9).

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

· Пример отношения включения. Пусть при решении вопроса о предоставлении кредита клиенту в поведение базового прецедента «Предоставление кредита в банке» включается обязательный прецедент «Проверка платежеспособности клиента» (рис. 5.10). Отношение включения отображается пунктирной стрелкой, направленной от основного прецедента к включаемому прецеденту.

·

·

· Рис. 5.9 Отношения направленной ассоциации на диаграмме прецедентов банкомата

·

·

· Рис. 5.10. Отношение включения

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

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

	Отношение расширения следует использовать для отражения дополнительных режимов, которые запускаются при наступлении кого-либо условия, а также альтернативных потоков, которые запускаются по выбору актера.

·

 

·

· Рис. 5.11. Отношение расширения

·

· Отношение обобщения между вариантами использования служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В. При этом вариант В называется предком, или родителем по отношению к варианту А, а вариант А – потомком по отношению к варианту В. Следует подчеркнуть, что потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения.

· Графически отношение обобщения обозначается сплошной линией со стрелкой в виде незакрашенного треугольника, которая указывает на родительский вариант использования (рис. 5.12). Эта линия имеет специальное название – стрелка «обобщение».

·

·

· Рис. 5.12. Отношение обобщения между прецедентами

·

· Отношениеобобщения между актерами используется, когда несколько актеров могут обладать общими свойствами и поведением, т. е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщенияс другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей (рис. 5.13).

Служащий с почасовой оплатой

·

Служащий

·

Временный служащий

·

Служащий на окладе

·

· Рис. 5.13. Отношение обобщения между актерами

⇐ Предыдущая12345678Следующая ⇒

Поделиться: