Пример описания диаграммы прецедентов

Диаграммы прецедентов (Use case diagrams) - применяются для моделирования поведения системы, подсистемы или класса с точки зрения прецедентов (или вариантов использования).

Диаграммы прецедентов включают следующие элементы:

Прецеденты;

Участников (актеров);

Отношения зависимости, обобщения и ассоциации.

Прецедент , это описание множества последовательностей действий, выполняемых системой для того, чтобы актер (участник, исполнитель) смог получить опреде­ленный результат. Графическое отображение примера прецедентов приведено на рис. 3.5.6.1.

Рис. 3.5.6.1. Графическое отображение примера прецедентов в UML.

Участник (субъект, актер) - множество ролей, которые пользователи прецедентов исполняют при взаимодействии с ними. В качестве участника может выступать человек, устройство, другая программная система. Графическое отображение примера участников приведено на рис. 3.5.6.2.

Рис. 3.5.6.2. Графическое отображение примера участников в UML

Диаграммы прецедентов обычно применяются для решения сле­дующих задач:

Моделирование контекста системы, подразумевающего иденти­фикацию участников, взаимодействующих с системой, а также их ролей;

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

Сущности, находящиеся вне моделируемой системы и взаимодей­ствующие с ней, составляют ее контекст. Важной задачей при модели­ровании контекста является идентификация сущностей, взаимодейст­вующих с системой, и их описание.

Моделирование системы необходимо проводить, следуя следую­щим этапам:

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

Рассмотреть и описать потоки событий для прецедентов отраженных на главной диаграмме прецедентов, а именно: предусловия, главный поток, подпотоки, альтернативные потоки, постусловия;

Организовать похожих участников с помощью отношений обобщения/специализа-ции;

Разместить участников на диаграмме прецедентов и определить их связи с прецедентами системы.

Моделирование требований - это описание свойств и поведения системы, необходимых для осуществления проекта, не рассматриваю­щее механизмы реализации. Рабочая система должна выполнять все требования, изложенные в модели.

Моделирование требований к системе необходимо проводить, сле­дуя следующим этапам:

Установление контекста системы, идентификация окружающих систему участников;

Для каждого участника - рассмотрение поведения, которое он ожидает и требует от системы;

Именование выделенных вариантов поведения как прецедентов;

Выделение общего поведения в новые прецеденты, которые бу­дут использоваться другими;

Выделение вариации поведения в новые прецеденты, расширяющие основные потоки событий;

Моделирование выделенных прецедентов, участников, отноше­ний между ними на диаграмме прецедентов;

Дополнение прецедентов примечаниями, описывающими не­функциональные специфические требования к системе.

Моделирования диаграмм прецедентов на конкретных примерах приведены на рис. 3.5.6.3. и рис. 3.5.6.4.

Рис. 3.5.6.3. Графическое отображение прецедентов на примере обслуживания

абонентов сотовой телефонной связи.

Следует отметить дополнение прецедентов примечаниями, описывающими не­функциональные специфические требования, т.е.комментариями, которыми могут сопровождаться некоторые отношения между вариантами использования. Так, смысл отношения "include" состоит в том, что в данном примере «Подключение» включает в себя «Выбор оператора связи». Смысл же связи <> в том, что прецедент, например, «Рассмотрение анкеты» "расширяется" вариантом использования «Заключение договора». Это можно в данном случае объяснить тем, что «Заключить договор» можно только после проверки оператором анкеты. «Рассмотрение заявления» "расширяет" прецедент «Блокировка номера», «Замена sim-карты», «Детализация счета», «Замена абонентского номера». Таким образом, связь <> говорит о выполнении того или иного прецедента в зависимости от определенных условий.

Рис. 3.5.6.4. Графическое отображение прецедентов

на примере производственного участка.

Данные диаграммы прецедентов описывают участников при их взаи­модействии с системой на предприятиях.

Диаграмма прецедентов разрабатывается на этапе анализа основных процессов, которые под­держиваются средствами информационной системы.

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

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

ЛАБОРАТОРНАЯ РАБОТА № 17-18

Тема: Построение диаграмм прецедентов

Цель: Ознакомиться с методологией моделирования прецедентов на основе языка UML

Оборудование и/или программное обеспечение: ПК, методические рекомендации

Теоретическая часть

UML (Universal Modeling Language) - универсальный язык моделирования, который был разработан компанией Rational Software с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели системы к логической, а затем и к физической модели соответствующей системы. Любая задача, таким образом, моделируется при помо помощи некоторого набора иерархических диаграмм, каждая из которых представляет собой некоторую проекцию системы.

Диаграмма (Diagram) - это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями).

В UML определено восемь видов диаграмм :

· диаграмма прецедентов (Use case diagram) - диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношения между ними;

· диаграмма деятельности (Activity diagram) - диаграмма поведения, на которой показан автомат и подчеркнуты переходы потока управления от одной деятельности к другой;

· диаграмма классов (Class diagram) - структурная диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношения между ними;

· диаграмма состояний (Statechart diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий;

· диаграмма последовательностей (Sequence diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута временная последовательность событий;

· диаграмма кооперации (Collaboration diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения;

· диаграмма компонентов (Component diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий

· диаграмма развертывания (Deployment diagram) - структурная диаграмма, на которой показаны узлы и отношения между ними.

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

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

Рассмотрим основные элементы диаграммы прецедентов.

Субъект (actor) - любая сущность, взаимодействующая с системой извне или множество логически связанных ролей, исполняемых при взаимодействии с прецедентами . Стандартным графическим обозначением субъекта на диаграммах является фигурка "человечка", под которой записывается конкретное имя субъекта, однако субъектом может быть не только человек, но и техническое устройств о, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик (рис.9).

Рисунок 9

Прецеденты (use case) - это описание множества последовательностей действий (включая их варианты), которые выполняются системой для того, чтобы актер получил результат, имеющий для него определенное значение. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие субъектов с системой, это одна из важнейших особенностей разработки прецедентов. Стандартным графическим обозначением прецедента на диаграммах является эллипс (рис.10), внутри которого содержится краткое название прецедента или имя в форме глагола с пояснительными словами.

Рисунок 10

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

Фрагмент внешне наблюдаемых функций (отличных от внутренних функций).

Ортогональный фрагмент функциональных возможностей (прецеденты могут при выполнении совместно использовать объекты, но выполнение каждого прецедента независимо от других прецедентов).

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

Фрагмент функциональных возможностей, который предоставляет субъекту ощутимый полезный результа т (и этот результат достигается в пределах одного прецедента).

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

Отношение ассоциации (association) - определяет наличие канала связи между экземплярами субъекта и прецедента (или между экземплярами двумх субъектов). Обозначается сплошной линией, возможно наличие стрелки и указание мощности связи.

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

Отношение включения (include) - указывает, что некоторое заданное поведение для одного прецедента включает в качестве составного компонента поведение другого прецедента. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров прецедентов всегда упорядочена в отношении включения. Обозначается пунктирной линией со стрелкой, направленной от базового прецедента к включаемому, и помечается ключевым словом "include" ("включает").

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

Ход выполнения работы

1. Изучить теоретические сведения.

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

3. Разработать диаграмму прецедентов использования и выполнить описание прецедентов.

4. Выполнить расчет затрат на создание программного продукта.

5. Выполнить планирование работ по созданию программного продукта.

6. Разработать техническое задание на создание программного продукта.

7. Сделать выводы о выборе модели создания программного продукта.

Требования к содержанию работы

1. Название работы.

2. Цель работы.

3. Формулировка индивидуального задания.

4. Диаграмма прецедентов использования с их описанием.

5. Расчет затрат на создание программного продукта.

6. Техническое задание на создание программного продукта.

7. Выводы о выборе модели создания программного продукта.

Требования к оформлению работ

Работы оформляются на отдельных листах формата А4 в соответствии с методическим указаниям “Структура и правила оформление текстовых документов” на основе ДСТУ 3008.95 “Документация, отчеты в сфере науки и техники. Структура и правила оформление”.

Теоретические сведения

UML. ДИАГРАММА ПРЕЦЕДЕНТОВ (ВАРИАНТОВ) ИСПОЛЬЗОВАНИЯ[*]

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

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

В классическом UML определено девять видов диаграмм, одним из которых является диаграмма прецедентов (Use case diagram) - диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношений между ними.

Конструкция или стандартный элемент языка UML «вариант использования» применяется для спецификации общих особенностей поведения системы или любой другой сущности предметной области без рассмотрения внутренней структуры этой сущности. Каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актером. Диаграмма вариантов может дополняться пояснительным текстом, который раскрывает смысл или семантику составляющих ее компонентов. Такой пояснительный текст получил название примечания или сценария.

Вариант использования

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

Рисунок 3.1 - Графическое обозначение варианта использования

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

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

Актеры

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

Рисунок 3.2 - Графическое обозначение актера

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

Интерфейсы

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

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

На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя (рис. 3.3, а). В качестве имени может быть существительное, которое характеризует соответствующую информацию или сервис (например, "датчик", "сирена", "видеокамера"), но чаще строка текста (например, "запрос к базе данных", "форма ввода", "устройство подачи звукового сигнала"). Если имя записывается на английском, то оно должно начинаться с заглавной буквы I, например, ISecurelnformation, ISensor (рис. 3.3, б).

Рисунок 3.3 - Графическое изображение интерфейсов на диаграммах вариантов использования

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

Рисунок 3.4 - Графическое изображение взаимосвязей интерфейсов с вариантами использования

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

Отношения на диаграмме вариантов использования

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

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования, наиболее распространенными из которых являются отношение расширения (extend relationship) и отношение включения (include relationship).

Отношение расширения

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

Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой, направленной от того варианта использования, который является расширением для исходного варианта использования. Данная линия со стрелкой помечается ключевым словом "extend" ("расширяет"), как показано на рис. 3.5.

Рисунок 3.5 - Пример графического изображения отношения расширения между вариантами использования

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

Отношение включения

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

Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В. Эти свойства специализируют поведение соответствующего варианта А на данной диаграмме. Графически данное отношение обозначается пунктирной линией со стрелкой, направленной от базового варианта использования к включаемому. При этом данная линия со стрелкой помечается ключевым словом "include" ("включает"), как показано на рис. 3.6.

Рисунок 3.6 - Пример графического изображения отношения включения

Пример описания диаграммы прецедентов

Рисунок 3.7 - Диаграмма прецедентов использования для системы продажи товаров по каталогу

Описание прецедента «Заказать товар со склада»

[*] - Леоненков А. Самоучитель UML. – Санкт-Петербург: BHV-СПб

Аннотация: Предметом этого курса является The UML - унифицированный язык моделирования. В предыдущей лекции было рассказано о том, что же такое UML, о его истории, назначении, способах использования языка, структуре его определения, терминологии и нотации. Было отмечено, что модель UML - это набор диаграмм. В этой лекции мы рассмотрим такие вопросы: почему нужно несколько видов диаграмм; виды диаграмм; ООП и последовательность построения диаграмм

Прежде чем перейти к обсуждению основного материала этой лекции, давайте поговорим о том, зачем вообще строить какие-то диаграммы. Разработка модели любой системы (не только программной) всегда предшествует ее созданию или обновлению. Это необходимо хотя бы для того, чтобы яснее представить себе решаемую задачу. Продуманные модели очень важны и для взаимодействия внутри команды разработчиков, и для взаимопонимания с заказчиком. В конце концов, это позволяет убедиться в "архитектурной согласованности" проекта до того, как он будет реализован в коде.

Мы строим модели сложных систем, потому что не можем описать их полностью, "окинуть одним взглядом". Поэтому мы выделяем лишь существенные для конкретной задачи свойства системы и строим ее модель, отображающую эти свойства. Метод объектно-ориентированного анализа позволяет описывать реальные сложные системы наиболее адекватным образом. Но с увеличением сложности систем возникает потребность в хорошей технологии моделирования. Как мы уже говорили в предыдущей лекции, в качестве такой "стандартной" технологии используется унифицированный язык моделирования ( Unified Modeling Language , UML ), который является графическим языком для спецификации, визуализации, проектирования и документирования систем. С помощью UML можно разработать подробную модель создаваемой системы, отображающую не только ее концепцию, но и конкретные особенности реализации. В рамках UML -модели все представления о системе фиксируются в виде специальных графических конструкций, получивших название диаграмм.

Примечание . Мы рассмотрим не все, а лишь некоторые из видов диаграмм. Например, диаграмма компонентов не рассматривается в этой лекции, которая является лишь кратким обзором видов диаграмм. Количество типов диаграмм для конкретной модели приложения никак не ограничивается. Для простых приложений нет необходимости строить диаграммы всех без исключения типов. Некоторые из них могут просто отсутствовать, и этот факт не будет считаться ошибкой. Важно понимать, что наличие диаграмм определенного вида зависит от специфики конкретного проекта. Информацию о других (не рассмотренных здесь) видах диаграмм можно найти в стандарте UML.

Почему нужно несколько видов диаграмм

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

Система - совокупность взаимосвязанных управляемых подсистем, объединенных общей целью функционирования.

Да, не слишком информативно. А что же такое тогда подсистема? Чтобы прояснить ситуацию, обратимся к классикам:

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

Что ж, ничего не попишешь, придется искать определение подсистемы. Там же сказано, что подсистема - это совокупность элементов, часть из которых задает спецификацию поведения других элементов. Ян Соммервилл объясняет это понятие таким образом:

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

Тоже не слишком понятно, но уже лучше. Говоря "человеческим" языком, система представляется в виде набора более простых сущностей, которые относительно самодостаточны. Это можно сравнить с тем, как в процессе разработки программы мы строим графический интерфейс из стандартных "кубиков" - визуальных компонентов, или как сам текст программы тоже разбивается на модули, которые содержат подпрограммы, объединенные по функциональному признаку, и их можно использовать повторно, в следующих программах.

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

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

Приведем несколько примеров. Знакомые всем нам пластмассовые игрушечные автомобильчики, которыми мы с таким азартом играли в детстве, это не что иное, как материальная искусственная декоративная модель реального автомобиля. Конечно, в таком "авто" нет двигателя, мы не заполняем его бак бензином, в нем не работает (более того, вообще отсутствует) коробка передач, но как модель эта игрушка свои функции вполне выполняет: она дает ребенку представление об автомобиле, поскольку отображает его характерные черты - наличие четырех колес, кузова, дверей, окон, способность ехать и т. д.

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

Уравнение, изображенное выше - тоже модель, но это модель математическая, и описывает она движение материальной точки под действием силы тяжести.

Осталось лишь сказать, что такое диаграмма . Диаграмма - это графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Примеров диаграмм можно привести множество. Это и знакомая нам всем со школьных лет блок-схема , и схемы монтажа различного оборудования, которые мы можем видеть в руководствах пользователя, и дерево файлов и каталогов на диске, которое мы можем увидеть, выполнив в консоли Windows команду tree , и многое-многое другое. В повседневной жизни диаграммы окружают нас со всех сторон, ведь рисунок воспринимается нами легче, чем текст...

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

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

Впрочем, точное число канонических диаграмм для нас абсолютно неважно, так как мы рассмотрим не все из них, а лишь некоторые - по той причине, что количество типов диаграмм для конкретной модели конкретного приложения не является строго фиксированным. Для простых приложений нет необходимости строить все без исключения диаграммы. Например, для локального приложения не обязательно строить диаграмму развертывания. Важно понимать, что перечень диаграмм зависит от специфики разрабатываемого проекта и определяется самим разработчиком. Если же любопытный читатель все-таки пожелает узнать обо всех диаграммах UML , мы отошлем его к стандарту UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Напомним, что цель этого курса - не описать абсолютно все возможности представление о назначении основных видов диаграмм. Итак, начнем.

Диаграмма прецедентов (use case diagram)

Любые (в том числе и программные) системы проектируются с учетом того, что в процессе своей работы они будут использоваться людьми и/или взаимодействовать с другими системами. Сущности, с которыми взаимодействует система в процессе своей работы, называются экторами , причем каждый эктор ожидает, что система будет вести себя строго определенным, предсказуемым образом. Попробуем дать более строгое определение эктора. Для этого воспользуемся замечательным визуальным словарем по UML Zicom Mentor :

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

Графически эктор изображается либо " человечком ", подобным тем, которые мы рисовали в детстве, изображая членов своей семьи, либо символом класса с соответствующим стереотипом , как показано на рисунке. Обе формы представления имеют один и тот же смысл и могут использоваться в диаграммах. "Стереотипированная" форма чаще применяется для представления системных экторов или в случаях, когда эктор имеет свойства и их нужно отобразить (рис. 2.1).

Внимательный читатель сразу же может задать вопрос: а почему эктор, а не актер ? Согласны, слово "эктор" немного режет слух русского человека. Причина же, почему мы говорим именно так, проста - эктор образовано от слова action , что в переводе означает действие . Дословный же перевод слова "эктор" - действующее лицо - слишком длинный и неудобный для употребления. Поэтому мы будем и далее говорить именно так.

Название системы

Подводя итоги, можно выделить такие цели создания диаграмм прецедентов :

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

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

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

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

Структура прецедента - это прекрасный инструмент, чтобы искать альтернативу главному сценарию, который ведет к успеху. На каждом шагу задавайте себе вопросы снова и снова: «Что может еще произойти?» И в частности: «Что может пойти не так?» Здесь лучше всего с самого начала выяснить все условия расширения, которые возможны. Это поможет в будущем не запутаться при работе над последствиями.

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

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

На диаграмме прецедентов четко отображены актеры, прецеденты, а также отношения между ними:

- выполнение актерами того или иного прецедента;

Прецеденты, включающие другие прецеденты.

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

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