В какой программе сделать диаграмму вариантов использования

Это первая статья из цикла про методологию ICONIX, посвящена UML-диаграммам вариантов использования. В публикациях и книгах по ICONIX, use-case диаграммы обычно описываются очень бегло, а в книгах по UML — слишком подробно. Я постараюсь сделать это настолько подробно, чтобы можно было приступить к использованию диаграмм, но при этом не было скучно. Важно, что до тех пор, до знакомства с ICONIX я не считал use-case диаграммы хоть сколько-нибудь полезными, поэтому в статье я попробую сконцентрироваться на том, что они могут принести проекту.

Вне зависимости от методологии разработки, которую вы применяете, первым этапом разработки будет являться формулировка требований к продукту (Градди Буч описывает Rational Unified Process [1], а Розенберг — ICONIX [2]). Набор требований к продукту представляет собой техническое задание, при этом требования делятся на функциональные (то, что система позволяет сделать, желаемая функциональность) и нефункциональные (требования к оборудованию, операционной системе и т.п.). В языке UML для формализации функциональных требований применяются диаграммы использования.

Диаграмма Use Case

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

На диаграмме использования изображаются:

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

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

1. выделить группы действующих лиц (работающих с системой по-разному, часто из-за различных прав доступа);
2. идентифицировать как можно больше вариантов использования (процессов, которые могут выполнять пользователи). При этом не следует делить процессы слишком мелко, нужно выбирать лишь те, которые дадут пользователю значимый результат. Например, кассир может «продать товар» (это будет являться прецедентом), однако «ввод штрих-кода товара для получения цены» самостоятельным прецедентом не является;
3. дополнить прецеденты словесным описанием (сценарием):
4. для каждого прецедента создать разделы: «главная последовательность» и «альтернативные последовательности»;
5. при составлении сценария нужно упорно задавать заказчику вопросы «что происходит?», «что дальше?», «что еще может происходить?» и записывать ответы на них.

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

UML Диаграмма Прецедентов (UML Use Case Diagrams)

Рассмотрим разработку диаграмм вариантов использования на примере — пусть заказчик дал нам следующее техническое задание:

• для учеников:

• выбор подготовленного учителем блока заданий;
• выполнение заданий;

• подготовка для учеников блоков заданий;
• добавление в систему ученика;
• просмотр отчетов.

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

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

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
4. система добавляет ученика;
5. учителю открывается главное меню и в течении 5 секунд выводится уведомление о том, что ученик был добавлен успешно.

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель нажимает кнопку «назад»;
4. учителю открывается главное меню (при этом данные, введенные в формы окна добавления ученика не сохраняются).

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
4. учителю в течении 5 секунд отображается уведомление о том, что запрашиваемый логин занят.

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

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

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

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

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

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

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

Наиболее типичными ошибками при построении этого вида диаграмм являются:

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

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

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

Стоит отметить, что нет единого мнения по поводу использования в текстах сценария условных операторов или циклов. Ряд аналитиков считают, что наличие слов типа «если» в сценарии является ошибкой, которая исправляется добавлением альтернативной последовательности. Другие — допускают использование 1-2 ветвлений в сценарии, при этом отмечают, что такой подход улучшает читабельность сценариев.

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

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

Источник: pro-prof.com

Online Use Case Diagram Maker

You wouldn’t build a house without a blueprint, right? The same goes for making software. Use Lucidchart to create UML diagrams that will serve as efficient blueprints.

99% of the Fortune 500 trust Lucidchart to keep teams on the same page.

Get started with free use case diagram templates

Whether you’re working by yourself, with a client, or on a design team, you’ll find an option that’s right for you. Start out with Lucidchart’s free use case templates or test the premium features through a free trial. Because of our thriving community of software developers, Lucidchart’s Community Library has many UML use case diagram examples. Check them out to spark an idea or answer questions.

Flexible and free

Lucidchart isn’t limited to use case diagrams. With an extensive shape and connector library, you’ll find everything you need to draw activity diagrams, sequence diagrams, class diagrams and more.

Draw together

Lucidchart’s collaborative UML use case diagram tool enables teams to come together online and work in real-time without a single download or system update.

Publish and share

Share your UML use case diagram by embedding it in a blog, wiki, or website. You can even export your diagram as an image and include it in a document or presentation.

Pause slideshow

Use case diagrams with Lucidchart

Make your own professional UML use case diagrams. We make flow charts simple, intuitive, and even fun.

Diagrams made easy

With our intuitive interface, you can easily arrange diagram elements however you like. Connect shapes with a click, then add an image or video for extra flair. Our editor is designed to make it easy to diagram.

Visio import/export

Even free users can view Visio files in Lucidchart. With a premium account, you can also edit Visio files and export your diagrams as Visio files so that you colleagues don’t get left behind. You won’t need to duplicate any work you’ve already done in Visio.

Fully integrated

Lucidchart integrates with the Google Apps productivity suite, allowing you to use your existing Google login to sync with Google Drive. Lucidchart also makes content from YouTube, Dropbox, and Facebook available at the click of a button.

Instant publishing

We’ll help you make a jaw-dropping flowchart that you’ll want everyone to see, and then we’ll help you send it off. Publish your flowchart as a PDF or image, then include it in a presentation or report. You can also embed it right into your web page!

Create any diagram in Lucidchart

Источник: www.lucidchart.com

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

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

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

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

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

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

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

Таблица 10.1. Описание кнопок панели инструментов диаграмм вариантов использования Rational Rose

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

Упражнение 1. Создание действующих лиц в среде Rational Rose

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

1. Щелкните правой кнопкой мыши по пакету представления вариантов использования в браузере.
2. Выберите пункт New/Actor в открывшемся меню.
3. В браузере появится новое действующее лицо под названием NewClass. Слева от его имени вы увидите пиктограмму действующего лица UML.
4. Выделив новое действующее лицо, введите его имя.
5. После создания действующих лиц сохраните модель под именем coursereg(analysis) с помощью пункта меню File / Save.

Результат выполнения упражнения показан на рис 10.2.

Рис. 10.2. Представление действующих лиц в браузере

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

Исходя из потребностей действующих лиц выделяются следующие варианты использования:

• Login (Войти в систему).
• Register for Courses (Зарегистрироваться на курсы).
• View Report Card (Просмотреть табель успеваемости).
• Select Courses to Teach (Выбрать курсы для преподавания).
• Submit Grades (Проставить оценки).
• Maintain Professor Information (Вести информацию о профессорах).
• Maintain Student Information (Вести информацию о студентах).
• Close Registration (Закрыть регистрацию).

Упражнение 2. Создание вариантов использования в среде Rational Rose

Для того чтобы поместить вариант использования в браузер:

1. Щелкните правой кнопкой мыши по пакету представления вариантов использования в браузере.
2. Выберите в появившемся меню пункт New / Use Case.
3. Новый вариант использования под названием NewUseCase появится в браузере. Слева от него будет видна пиктограмма варианта использования UML.
4. Выделив новый вариант использования, введите его название.

Результат выполнения упражнения показан на рис. 10.3

Рис. 10.3. Представление вариантов использования в браузере

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

Создайте диаграмму вариантов использования для системы регистрации. Требуемые для этого действия подробно перечислены далее. Готовая диаграмма вариантов использования изображена на рис. 5.

В среде Rose диаграммы вариантов использования создаются в представлении вариантов использования. Главная диаграмма (Main) предлагается по умолчанию. Для моделирования системы можно затем разработать необходимое количество дополнительных диаграмм.

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

1. Откройте данное представление, щелкнув по значку «+» рядом с представлением вариантов использования в браузере.
2. Откройте главную диаграмму, дважды щелкнув мышью. Строка заголовка изменится, включив фразу [Use Case Diagram: Use Case view / Main].

Для создания новой диаграммы вариантов использования:

1. Щелкните правой кнопкой мыши по пакету представления вариантов использования в браузере.
2. Выберите пункт New / Use Case Diagram из всплывающего меню.
3. Выделив новую диаграмму, введите ее имя.
4. Дважды щелкните по названию этой диаграммы в браузере, чтобы открыть ее.

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

1. Откройте диаграмму вариантов использования Main.
2. Перетащите действующее лицо или вариант использования мышью из браузера на диаграмму вариантов использования.
3. С помощью кнопки Unidirectional Association (Однонаправ-* ленная ассоциация) панели инструментов нарисуйте ассоциации между действующими лицами и вариантами использования как показано на рис.10.4.
4. Сохраните диаграмму.
5. Наличие общего варианта использования Login для трех действующих лиц позволяет обобщить их поведение и ввести новое действующее лицо Any User. Модифицируйте диаграмму вариантов использования как показано на рис. 10.5.
6. Ассоциации между действующими лицами необходимо нарисовать с помощью кнопки Generalisation на панели инструментов.

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

Рис. 10.5. Модифицированная диаграмма вариантов использования для системы регистрации

Упражнение 4. Добавление описаний к вариантам использования

1. Выделите в браузере вариант использования Register for Courses.
2. В окне документации (пункт Open Specification) введите следующее описание к этому варианту использования: «This use case allows a student to register for courses in the current semester» («Этот вариант использования дает студенту возможность зарегистрироваться на курсы в текущем семестре»).
3. Создайте с помощью MS Word три текстовых файла с описаниями вариантов использования Login (Войти в систему), Register for Courses (Зарегистрироваться на курсы) и Close Registration (Закрыть регистрацию).

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

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

Основной поток событий