15 почему не рекомендуется подробная детализация диаграмм прецедентов

Отчет 3 работы. Практическая работа 3 Разработка перечная артефактов

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

Открываем MS Visio и строим физическую диаграмму по образцу (Рис. 1) используя форму «Сценарий выполнение UML»

Рис. 1 Физическая диаграмма ЗАО «МЕД»

Далее строим диаграмму процентов (Рис. 2), отображающую прецеденты компании «Мед» и внутренних исполнителей, обеспечивающих реализацию этих прецедентов внутри системы

Рис. 2. Диаграмма прецедентов (вариантов использования) компании «МЕД»

1. Что называется артефактами проекта? Их виды?

Артефакты делятся на формальные и неформальные.

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

Неформальные артефакты — вся остальная информация: итоги переписок, сообщения в мессенджерах, записи с флипчарта, на котором команда фиксирует ход проекта, стикеры с канбан-доски и даже матрица RACI.

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

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

Разработка диаграммы прецедентов преследует цели:

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

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

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

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

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

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

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

так, как определит сам разработчик (рис. 1.3).

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

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

1.3.1. Особенности построения диаграмм прецедентов

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

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

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

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

1.3.2. Рекомендации по разработке диаграмм прецедентов

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

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

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

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

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

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

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

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

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

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

Диаграммы прецедентов: крупным планом

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

Итак, подводя итоги, мы можем сформулировать три причины использования прецедентов. Или, вернее, три способа использования прецедентов (не случайно в русском переводе частенько можно встретить словосочетание » вариант использования «!) в ходе работы над системой:

• Прецеденты дают возможность аналитикам, пользователям и разработчикам говорить на одном языке: используя прецеденты, аналитики (эксперты в предметной области) могут на основе пожеланий заказчика описать поведение системы с точки зрения пользователя с такой степенью детализации, что разработчики смогут без труда сконструировать «внутренности» системы. В то же время, нотация диаграмм прецедентов настолько проста, что даже неподготовленный пользователь (заказчик) способен понять их смысл и помочь в их уточнении — ведь картинки (а тем более комиксы, каковыми, по сути, являются диаграммы UML) воспринимаются намного легче, чем текст!
• Прецеденты позволяют разработчикам понять назначение элемента: система, подсистема или даже класс могут быть сложными образованиями, состоящими из большого числа составных частей и имеющими большое число атрибутов и операций. Моделирование прецедентов позволяет лучше представить себе поведение системы, понять, какие элементы модели играют какие роли в реализации этого поведения, в какие кооперации входят, и какой именно прецедент (функционал системы) реализуют.
• Прецеденты являются основой для тестирования элемента в течение всей разработки: модель прецедентов описывает желаемое поведение системы (ее функционал) с точки зрения пользователя. Так что, постоянно сопоставляя предоставляемый элементом (фактический) функционал с имеющимися прецедентами, можно надежно контролировать корректность реализации элемента. Вот вам и надежный источник регрессионных тестов. Кроме этого, появление нового прецедента зачастую заставляет пересмотреть реализацию элемента, дабы убедиться, что она обладает достаточной гибкостью, изменяемостью и масштабируемостью.

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

• С целью поиска ошибок и чтобы убедиться в адекватности дизайна:

отличная идея после первого перевода с UML на язык программирования сделать обратный перевод и сравнить исходные и восстановленные UML-модели (желательно, чтобы эти переводы выполнялись разными командами). Это позволит убедиться в том, что дизайн системы соответствует модели, никакая информация в ходе перевода не была утеряна, да и попросту выловить некоторые «баги». Такой подход называется обратной семантической трассировкой (или RST — Reverse Semantic Traceability ) и разрабатывается компанией INTSPEI (http://www.intspei.com) как одна из базовых техник методологии INTSPEI P-Modeling Framework, краткие сведения о которой вы можете найти в приложении к этому курсу.

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

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

Следующие три примера уже по традиции мы позаимствовали с сайта шуток на UML (http://www.umljokes.com), продолжая доказывать, что на UML можно шутить — это полноценный язык общения, который можно применять так же, как и любой другой. Первый из примеров — это часть всем известной сказки о «Курочке Рябе», которую автор очень красочно оформил (рис. 6.16).

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

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

И наконец, третья картинка, которая не является хорошим примером диаграммы прецедентов , но просто забавна. Это рассказ о способах поведения, позволяющих гарантированно (!) провалить любой экзамен (рис. 6.18):

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

«Данная статья посвящена диаграмме прецедентов, чаще называемой диаграммой use-кейсов, или диаграммой вариантов использования. Это одно из важных понятий, которые необходимо освоить при изучении объектно-ориентированного программирования (ООП). В схемах (собственно, диаграммах) в данном случае использовался Astah UML, инструмент проектирования, поддерживающий UML. Чтобы освоить данный туториал, желательно скачать Astah здесь и ознакомиться (платный, но есть 20-дневный триал, чего должно быть достаточно), а также научиться им пользоваться, посмотрев документацию.

Что такое use case диаграмма

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

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

• Просмотр книг
• Покупка книг
• Добавление книг в корзину

Можно еще добавить много возможных взаимодействий, но основные будут эти.

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

Из чего составляется диаграмма use-кейсов?

Из следующих компонентов:

• Актер (Actor)
• Собственно use-кейсы
• Ассоциации между ними
• Границысистемы (Boundaries), и
• Отношения (Relationships или связи)

Актор в UML

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

Чтобы идентифицировать актора, необходимо ответить на простой вопрос: «Кто будет взаимодействовать с приложением?»

Допустим, нужно создать сайт магазина. Кто будет актором?

• Пользователь, и
• Администратор

В диаграммах use-кейсов актор обычно изображается в виде человечка, но может быть изображен и как на рисунке:

Актор на юзкейс-диаграмме

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

О use-кейсах, ассоциациях и границах системы

Эти понятия довольно просты, поэтому можно просто привести эти понятия и их обозначения на диаграмме:

• Use кейсы: широкие овалы, изображающие различные варианты использования, по которым может «проходить» пользователь.
• Ассоциация: линия, соединяющая («ассоциирующая») акторов и их use-кейсы. В сложных диаграммах важно четко знать, какие акторы связаны с какими use-кейсами.
• Границы системы: граница, задающая пределы системы для use кейсов. Все use кейсы, выходящие за пределы этой границы, будут считаться выходящими за пределы данной системы.

Например: клиент банка может видеть только свои транзакции, а не все проведенные транзакции в системе, поскольку такой use кейс выходит за границы системы.

В целом, несмотря на кажущуюся сложность для новичков, на практике работать с UML-диаграммами довольно просто. Единственная сложная вещь в UML-диаграммах — это отношения между элементами (Relationships). О них и поговорим.

Отношения в UML-диаграммах

Итак, Relationships, называемые еще связями. Существует 3 типа отношений:

• Включение (Include)
• Расширение (Extend)
• Обобщение (Generalization)

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

Отношение включения — обязательная, неотъемлемая связь (отношение) между use кейсами.

Представим это так: например вы голодны и хотите зайти куда-то перекусить. Вы заходите во Вкусно и Точка и говорите: «Я хочу заказать еду». Но что нужно сделать перед этим? Конечно, сначала нужно выбрать еду. Пример диаграммы:

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

Это и есть отношение включения. Только когда вы сделаете выбор, можно переходить к оплате. Поэтому в диаграмму выше уже был добавлен еще один use кейс с включением — «Оплатить еду».

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

Как уже сказано, include — обязательная связь между use-кейсами. А расширение (extend) является необязательным. Это означает, что если use кейс не является обязательным, то актор может выбирать; если у актора есть выбор, то это уже отношение extend.

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

Расширение

Просто запомним: Отношение “Include” — обязательное, а “Extend” — опциональное.

Отношение обобщения

Обобщение (генерализация, generalization) — это, по сути, демонстрация отношений типа «порождающая сущность / порожденная сущность» (parent/child), между use кейсами или акторами.

Например, обобщение use кейсов:

• Логин (parent) -> Вход с помощью телефона/электропочты (child)
• Оплата (parent) -> Оплатить с помощью Сбербанка / Наличкой (child)

Отношения обобщения акторов:

• Менеджер -> Персонал
• Оптовики -> Ритейлеры

Отношение обобщения в ИТ-системе заведения быстрого питания:

Обобщение

Обобщение помогает более четко изобразить диаграмму use кейсов.

При изучении объектно-ориентированного программирования (ООП), легко понять, что обобщение наследуется (наследование в объектно-ориентированной парадигме), то есть дочерняя структура «наследует» свойства и отношения родительской структуры других use кейсов.

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

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

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