Унифицированный язык моделирования ПО UML

 

ОсновыUML

 

История

До UML 1.x

В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании RationalSoftware, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования Object-ModelingTechnique и Booch. OMT был ориентирован на анализ, а Booch — на проектирование программных систем. В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (англ. UnifiedMethod). Осенью 1995 года к компании Rational присоединился Ивар Якобсон, автор метода Object-OrientedSoftwareEngineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод. На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (ObjectManagementGroup). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон, выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года.

UML 1.x

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UMLPartners присоединились такие компании, как DigitalEquipmentCorporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICONComputing, MCISystemhouse, Microsoft, OracleCorporation, RationalSoftware, TexasInstruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики. Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно, в июне 1999, сентябре 2001 и марте 2003 года. UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005[11].

UML 2.x

Формальная спецификация версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии ModelDrivenDevelopment — MDD. Последняя версия UML 2.5 опубликована в июне 2015 года. UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2[11].

Преимущества UML

· UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам ООП;

· UML позволяет описать систему практически со всех возможных точек зрения;

· Диаграммы UML сравнительно просты для чтения;

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

· UML получил широкое распространение и динамично развивается.

Критика

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

· Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и английского (подробная семантика), то он лишен скованности, присущей языкам, точно определённым техниками формального описания. В некоторых случаях они противоречат друг другу или неполные. Одно и тоже допускается отобразить по-разному.

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

· Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.

· Кумулятивная нагрузка/Рассогласование нагрузки. Если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП), то воспринимать UMLстановиться сложно.

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

Диаграммы

В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):

Структурные диаграммы (Structure Diagrams):

· Диаграмма классов (Class diagram)

· Диаграмма компонентов (Component diagram)

· Диаграмма развёртывания (Deployment diagram)

· Диаграмма объектов (Object diagram)

· Диаграмма пакетов (Package diagram)

· Диаграмма профилей (Profile diagram UML2.2)

Диаграммы поведения (Behavior Diagrams):

· Диаграмма деятельности (Activity diagram)

· Диаграммасостояний (State Machine diagram)

· Диаграмма вариантов использования (Usecasediagram)

· Диаграммы взаимодействия (Interaction Diagrams):

o Диаграммакооперации (Collaboration diagramUML2.0)

o Диаграммаобзоравзаимодействия (InteractionoverviewdiagramUML2.0)

o Диаграмма последовательности (Sequence diagram)

o Диаграмма синхронизации (TimingdiagramUML2.0)

 

Структуру диаграмм UML 2.3 можно представить на диаграмме классов UML:

 

Малоиспользуемыми или новыми являются:

Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

Диаграмма пакетов (Package diagram) — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

Диаграмма обзора взаимодействия (Interaction overview diagram) — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления. Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

 

Диаграмма прецедентов, вариантов или сценариев использования (use case diagram)

 

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

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

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

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

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

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

Рис. 2.1.

 

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

 

Прецедент (вариант использования или use-case) - описание отдельного аспекта поведения системы с точки зрения пользователя (Буч). Прецедент представляет поведение сущности, описывая взаимодействие между экторами и системой. Прецедент не показывает, "как" достигается некоторый результат, а только "что" именно выполняется.

Прецеденты обозначаются очень простым образом - в виде эллипса, внутри которого указано его название. Прецеденты и экторы соединяются с помощью линий, которые называются отношениями. Часто на одном из концов линии изображают стрелку, причем направлена она к тому, у кого запрашивают сервис, другими словами, чьими услугами пользуются. Это простое объяснение иллюстрирует понимание прецедентов как сервисов, пропагандируемое компанией IBM.

Рис. 2.2.

 

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

 

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

 

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

 

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

 

Рис. 21. Графическое изображение взаимосвязей интерфейсов с вариантами использования: а) реализация всех операций, б) реализация только необходимого сервиса

 

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

 

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

 

Рис. 22. Примеры примечаний в языке UML

 

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

 

Артефакт

Элемент явно не оговорённый в UML, но встречающийся в некоторых Case-средствах, например MicrosoftVisualStudio 2015 professional, и в зависимости от этого обладающий немного разными возможностями. Его назначение – уточнять назначение или принцип работы того или иного элемента, например эктора или прецедента. Производиться это за счёт размещения гиперссылки в диаграмме на внешний документ с описанием. Чаще всего используются Word документы и изображения. Графически на схеме изображается в виде прямоугольника, соединённого с поясняемым элементом. Внутри он может быть пустым, содержать пояснительный текст или изображение.

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

 

Подсистема

Элемент явно не оговорённый в UML, но встречающийся в некоторых Case-средствах, например Delphi и MicrosoftVisualStudio 2015 professional. Позволяет группировать на диаграмме прецеденты. Графически изображается прямоугольником с названием. Может иметь дополнительно тень или более заливку цвета отличного от общего фона.

 

Пакет

Элемент явно не оговорённый в UML, но встречающийся в некоторых Case-средствах, например Delphi и RationalRose. Это структурный элемент, который позволяет хранить части диаграммы отдельно, если они не помещаются на общей схеме. Внутри могут содержаться варианты использования, подсистемы и даже диаграммы другого вида. Могут использоваться для задания пространства имён. Графически изображается в виде папки.

 

 

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

Для выражения отношений между актерами и вариантами использования применяются стандартные виды отношений.

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

Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в».

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

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

При моделировании возникает необходимость в указании количества объектов, связанных посредством одного экземпляра ассоциации. Это число называется кратностью (Multiplicity) роли ассоциации и записывается либо как выражение, значением которого является диапазон значений, либо в явном виде (рис. 27). Кратность указывает на то, столько объектов должно соответствовать каждому объекту на противоположном конце. Кратность можно задать равной единице (1), указать диапазон: “ноль или единица” (0..1), “много” (0..*), “единица или больше” (1..*). Разрешается также указывать определенное число.

Различают следующие типичные случаи:

Нотация	Объяснение	Пример
0..1	ноль или один экземпляр	кошка имеет или не имеет хозяина
	обязательно один экземпляр	у кошки одна мать
0..* или *	ноль или более экземпляров	у кошки могут быть, а может и не быть котят
1..*	один или более экземпляров	у кошки есть хотя бы одно место, где она спит

 

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

 

 

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

 

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

 

 

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

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

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

 

Реализация(implementation) — отношение между двумя элементами модели, в котором один элемент (клиент) реализует поведение, заданное другим (поставщиком). Реализация — отношение целое-часть. Графически реализация представляется так же, как и наследование, но с пунктирной линией.

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

 

 

Зависимость (dependency) — это слабая форма отношения использования, при котором изменение в спецификации одного элемента-поставщика (например, класса) влечёт за собой изменение другого - зависимого, причём обратное не обязательно. Возникает, когда объект выступает, например, в форме параметра или локальной переменной.

На диаграмме классов графически представляется штриховой линией со стрелкой возле элемента-поставщика.

Для диаграммы вариантов использования доступно уточнение в виде расширения (extend) или включения (include) функционала.

Расширяющий вариант использования отмечает тот факт, что вариант использования может присоединять к своему поведению некоторое дополнительное поведение, определенное другим вариантом использования. Расширения обычно включаются при определенных условиях, т.е. подразумевается, что расширяемый вариант может не всё время обладать дополнительной функциональностью. Элемент-поставщик (расширяемый вариант использования) находится на конце стрелки с наконечником. Данная линия со стрелкой помечается ключевым словом “extend” (“расширяет”).

Включение используется для демонстрации того, как вариант использования разбивается на более мелкие части. Зависимый (включаемый) объект находится на конце стрелки с наконечником. При этом данная линия со стрелкой помечается ключевым словом “include” (“включает”).

 

 

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

Как вы думаете, что означает эта диаграмма (рис. 2.3)?

Рис. 2.3.

 

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

1 – эктор

2 – прецедент (вариант использования)

3 – отношение (ассоциация)

4 – подсистема Система или приложение, к которых вы работаете, или их часть. Это может быть что угодно — от крупной сети до одного класса в приложении.

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

 

Ещё пример.

5 – зависимость включения

6 – зависимость расширения

7 – наследование

8 – зависимость

9 – примечание с условием срабатывания зависимости расширения 6

10 – Артефакт предоставляет связь с другой схемой или другим документом. Его можно создать, перетащив файл из обозревателя решений. С помощью зависимости его можно связать с любым другим элементом на схеме. Артефакт обычно используется, чтобы связать вариант использования со схемой последовательностей, страницей OneNote, документом Word или презентацией PowerPoint с подробным описанием. Документ может представлять собой либо элемент в решении Visual Studio, либо документ в общей папке, например на сайте SharePoint. Дважды щелкните артефакт, чтобы открыть файл или веб-страницы, с которыми он связан.

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

Рассмотрим диаграмму вариантов использования отражающую систему работы банковского автомата (Automated Teller Machine, ATM) (рис. 28).

Рис. 28. Диаграмма вариантов использования для ATM

 

Клиент банка инициирует различные варианты использования: снять деньги со счета, перевести деньги, положить деньги на счет, Показать баланс, изменить идентификационный номер, произвести оплату. Банковский служащий может инициировать вариант использования "Изменить идентификационный номер". Действующими лицами могут быть и внешние системы, в данном случае кредитная система показана именно как действующее лицо – она является внешней для системы ATM. Стрелка, направленная от варианта использования к действующему лицу, показывает, что вариант использования предоставляет некоторую информацию действующему лицу. В данном случае вариант использования "Произвести оплату" предоставляет кредитной системе информацию об оплате по кредитной карточке.

Еще один пример диаграммы использования приведен на рисунке 29.

Рис. 29. Диаграмма вариантов использования для стиральной машины

 

РАЗРАБОТКА СТРУКТУРЫ СИСТЕМЫ АВТОМАТИЗИРОВАННОГО ПОИСКА ОТДЕЛЕНИЙ И ТЕРМИНАЛОВ БАНКОВ

Итак, перечислим сервисы которые будет предоставлять система:

- Поиск банкоматов с отображением их на карте с учётом вашего текущего местоположения. Ваше текущее местоположение с помощью HTML5 Geolocation. Если Ваш браузер этого не поддерживает или Ваше местоположение не удалось точно определить, достаточно кликнуть на карте, что бы указать, где Вы находитесь и начать поиск;

- Поиск магазинов, где Вы можете расплатиться с помощью банковских карт;

- Поиск кафе, баров, ресторанов, где вы можете провести время, расплатившись без использования наличных средств;

- Информация и статьи о банковских картах, их особенностях и способах оплаты.

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

Для разграничения прав в системе было выделено классы пользователей представленные в таблице 1.1.

 

Таблица 1.1 – Классы пользователей

Класс	Описание
Администратор	- Бан юзера (забанить, разбанить) - Удалять пользователей, изменять данные - Создавать резервные копии БД - Редактировать информационные блоки - Восстанавливать БД (при необходимости) - Создавать опрос, голосование - Добавлять, удалять баннеры
Пользователь	- Регистрироваться - Просматривать информацию (новости, данные) - Голосовать, участвовать в опросах - Авторизоваться - Воспользоваться системой поиска
Гость	- Регистрироваться - Просматривать информацию (новости, данные)

 

3.2 Определение функциональной модели системы

 

На рисунке 3.1 представлена диаграмма вариантов использования разработанной системы. Модель вариантов использования представляет собой модель того, как разные классы пользователи взаимодействуют с системой для решения своих проблем или задач [11]. Модель вариантов использования описывает цели пользователей, взаимодействие между пользователями и системой и требуемое поведение системы для удовлетворения этих целей.

 

Рисунок 1.1 – Use Case диаграмма системы

 

Рисунок 1 – Диаграмма для сайта простого интернет-магазина в RationalRose

 

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

В окне project manager переключаемся на вкладку Model View.

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

Дальше в окне менеджера нажимаем ПКМ на имени проекта и в контекстном меню выбираем ADD/Otherdiagram.

Выбираем UseCaseDiagram. В этом же окне указываем имя диаграммы, по умолчанию будет UseCaseDiagram1. После нажатия на ОК в менеджере появиться новая диаграмма. По двойному щелчку на ней открывается рабочая область справа в виде размеченного на клетки поля.

 

Добавляются новые элементы на диаграмму через контекстное меню.

В Delphiотсутствует такой элемент как интерфейс, но есть границы системы Systemboundery, которые позволяют группировать прецеденты. Включать внутрь экторов нельзя. Новый элемент внутрь включается так же через контекстное меню. Можно менять цвет эктора. Некоторые средства позволяют менять саму иконку.

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

После этого можно изменить тип соединения. Для связи прецедента и эктора по умолчанию association, дальше тип можно изменить:

Изменить тип связи между прецедентами нельзя. При необходимости линию нужно будет удалить и создать заново. Для связи между прецедентами (по умолчанию generalization):

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

На схеме допускается помещение условных пакетов, которые позволяют связать между собой несколько диаграмм с использованием гиперссылок. Добавляется пакет так: вызываем контекстное меню из любого свободного участка рабочей области, выбираем пункт Hyperlinks, затем «Tonewdiagram»если нет других диаграмм или выбираем из списка существующую. На экране появиться значок папки, по двойному щелчку на которую мы перейдём на соответствующую диаграмму.

На схему можно помещать пояснительные изображения. Для этого используется элемент Image. Картинка устанавливается в инспекторе объектов в свойстве ImagePath.

К каждому элементу диаграммы можно прикрепить несколько документов с пояснением принципа работы или других аспектов. Они размещаются как гиперссылки, поэтому хранятся отдельно от проекта и для их просмотра запускается стороннее ПО. Сделать это можно так: выбираем нужный элемент схемы, вызываем его контентное меню, пункт hyperlinks, затем Edit, и переходим на вкладку externaldocuments. Далее или выбираем из списка уже ранее использованный документ или кнопкой URL добавляем новый. Это может быть, как файл на компьютере, так и в интернете.

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

· определение границы и контекста моделируемой предметной области на ранних этапах проектирования;

· формирование общих требований к поведению проектируемой системы;

· разработка концептуальной модели системы для ее последующей детализации;

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