Процесс ICONIX. Диаграммы пригодности

После построения диаграмм вариантов использования и их согласования с заказчиком, процесс ICONIX предлагает приступить к разработке диаграмм пригодности (робастности, rubustness diagrams) [1, 2]. Гради Буч не использует этот вид диаграмм, однако он все равно просматривает каждый вариант использования и пытается выделить объекты, после чего переходит сразу к построению диаграмм взаимодействия [3]. Назначение диаграмм робастности:

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

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

robustness_use_case_1

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

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

  1. акторы (действующие лица) – клиенты системы, участвующие в прецеденте;
  2. граничные объекты – интерфейс, через который система взаимодействует с клиентами (обычно экраны и отчеты);
  3. сущностные объекты – объекты, представляющие данные, обрабатываемые прецедентом. Обычно их время жизни больше периода сеанса работы программ (базы данных, файлы, и т.п.), но могут быть и временные объекты (отчеты и результаты поиска удаляемые после просмотра);
  4. контроллеры отражают логику функционирования системы, соединяя граничные и сущностные объекты;
  5. комментарии, обычно используются лишь для размещения текста прецедента;
  6. отношения ассоциации изображаются стрелками (или линиями, если направление очевидно). Их нельзя понимать как посылку сообщений  – при построении диаграммы надо фокусироваться на логических отношениях. Есть ряд правил ассоциации на диаграмме:
    • актор может взаимодействовать только с граничными объектами;
    • граничный объект может взаимодействовать только с контроллерами и акторами;
    • контроллеры могут взаимодействовать с кем угодно (включая другие контроллеры) кроме акторов;
    • сущностные объекты взаимодействуют только с контроллерами;
  7. другие варианты использования (обозначается овалом, как и на use-case диаграммах). Используются в случаях, если текущий моделируемый прецедент обращается к другим прецедентам.

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

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

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

На приведенной диаграмме контроллер add student выполняет фактическое добавление только в случае успешной проверки логина, поэтому при добавлении альтернативных последовательностей этот контроллер целесообразно разделить на add student и check student. Цвет объектов, относящихся только к альтернативным сценариям может отличаться от объектов главного сценария – это улучшает восприятие диаграммы. Добавим на диаграмму последовательность действий “возврат в главное меню без добавления ученика”:

robustness_use_case_2

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

На последующих этапах проектирования граничные объекты превратятся в классы, обеспечивающие взаимодействие системы с клиентами, сущностные объекты – в классы управления базами данных, а контроллеры – в функции какого-либо класса. Отталкиваясь от диаграммы можно попробовать различные варианты распределения обязанностей, но делать это нужно при построении диаграмм последовательностей. Например, из нашей диаграммы видно, что контроллеры add student и check student скорее всего должны быть функциями базы данных учеников, а clear forms – приватной функцией add student screen. Однако не понятно к чему должны относиться уведомления (они могут быть как частью главного окна программы, так и самостоятельными визуальными элементами), кроме того, возможно, контроллер display notification … successful должен быть логически связан не с проверкой студента, а с его фактическим добавлением (после добавления записи, база данных может инициировать показ уведомлений – паттерн Publish-Subscriber [5]).

При добавлении сценария добавления в систему студента, логин которого занят на диаграмме появится контроллер отображения сообщения об ошибке:

robustness_use_case_3

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

В настоящий момент на диаграмме изображено семь контроллеров – это уже достаточно трудно для восприятия (ряд исследователей рекомендует, чтобы на диаграмме было не более пяти контроллеров). Часто увеличение числа контроллеров связано с попыткой детального анализа системы (этого нужно избегать) – возможно в нашем примере лишним является второй сценарий (обработки back button), однако его наличие позволяет проследить возможную последовательность смены экранов (Фаулер предлагает использовать для этого отдельный вид диаграмм – диаграмму потока экранов [6]). С другой стороны, мы могли бы разделить наш прецедент на несколько – сделать это можно разными способами:

  • в сценариях хорошо видно дублирование первых двух пунктов, возможно стоит писать сценарий для случая, когда учитель уже находится на экране добавления пользователя). Сделав это, мы улучшим тексты прецедентов и уберем с диаграммы контроллер display add student screen;
  • наиболее сложная для восприятия часть диаграммы связана с проверкой студента, возможно стоит вынести фактическое добавление студента в отдельный прецедент.
robustness_use_case_4

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

Действия пользователя должны показываться через связи граничных объектов с контроллерами (действия подписываются над стрелками), а не между пользователем и граничным объектом (т.к. в этом случае диаграмма будет не однозначной) – посмотрите на примере взаимодействия пользователя с add student screen.

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

  1. использование большого числа контроллеров резко осложняет восприятие диаграммы. Если на диаграмме размещается более 10 контроллеров, вероятно прецедент нужно разделить на несколько;
  2. нет смысла использовать анализ пригодности только для главной последовательности – обязательно рассматривайте альтернативные последовательности;
  3. при использовании диаграмм в процессе ICONIX на них не нужно тратить много времени, т.к. процесс итеративный. На дальнейших шагах вы сможете выявить ошибки и их исправление не будет очень дорого стоить;
  4. выполняйте визуальную сверку для каждого варианта использования – просто пройдитесь еще раз по каждому предложению прецедента и проследите этот путь на диаграмме. Это не занимает много времени, но часто позволяет найти ошибки;
  5. диаграмма пригодности позволяет не только дополнить прецеденты, но и дополнить модель предметной области – не забудьте обновить ее.

Из рассмотренных в статье примеров видны следующие сильные стороны диаграмм пригодности:

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

Для построения диаграмм из статьи использовался PlantUML [7], позволяющий делать это через браузер. Большая часть инструментов UML-моделирования не позволяет строить такой вид диаграмм (за исключением наиболее продвинутых и платных). Особенность PlantUML заключается в том, что вы не строите диаграмму мышкой, а набираете в виде текста, который загружаете на их сервер. Диаграмма первой статьи была создана на основе этого описания:

@startuml

actor teacher

entity student_database

boundary "main menu screen" as main_menu_screen
boundary "add student screen" as add_student_screen 

control "display add student screen" as display_add_student_screen
control "display main menu" as display_main_menu

control "display notification student added successful" as display_notification_student_added_successful
control "add student" as add_student

teacher -- main_menu_screen 
teacher -- add_student_screen

main_menu_screen --> display_add_student_screen : "add button pressed"
display_add_student_screen --> add_student_screen
display_main_menu --> main_menu_screen

add_student_screen -- add_student : "next button pressed"

add_student --> student_database : "successful"
add_student --> display_main_menu : "successful"
add_student --> display_notification_student_added_successful : "successful"

note right of teacher : This is actor
note right of main_menu_screen : This is boundary object 
note right of student_database : This is entity object 
note right of add_student : This is control object 

note as scenario
Главная последовательность:
    1) учитель выбирает в главном меню пункт “добавить ученика“;
    2) система показывает учителю окно добавления ученика, 
         содержащее поля для ввода логина и пароля, 
         а также кнопки “далее” и “назад”;
    3) учитель вводит желаемый логин и пароль 
         ученика, нажимает кнопку “далее”;
    4) система добавляет ученика;
    5) учителю открывается главное меню и в течении 5 секунд
        выводится уведомление о том, что ученик был добавлен успешно.
end note


@enduml

 

Литература по UML и ICONIX:

  1. Основы UML – диаграммы использования (use-case).- URL: https://pro-prof.com/archives/2594
  2. Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
  3. Буч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. – М.: ООО “И.Д. Вильямс”, 2010. – 720 с.
  4. Robustness Diagrams: An Agile Introduction.- URL: http://www.agilemodeling.com/artifacts/robustnessDiagram.htm
  5. Паттерны MVC и Publish-Subscriber.- URL: https://pro-prof.com/archives/2400
  6. Фаулер М., Скотт К UML. Основы СПб.: Символ, 2006, 184 с.
  7. Инструмент построения UML-диаграмм.- URL: http://plantuml.com/

Добавить комментарий