Лекция
Привет, сегодня поговорим про типовые ошибки в use case диаграммах, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое типовые ошибки в use case диаграммах, разница между include и extend , настоятельно рекомендую прочитать все из категории Моделирование и Моделирование систем.
В языке моделирования UML существует множество диаграмм. Сами по себе они не являются чем-то сложным, и построить их достаточно легко, даже не обладая большим опытом разработки программных систем, а лишь имея начальное представление об объектно-ориентированном подходе.
Однако, на мой взгляд, Use Case диаграмма – это наиболее сложная в понимании диаграмма, а именно, для чего она нужна и как ее правильно строить. Опыт тренингов, которые я провел, это доказывает. Поэтому в этой статье мне бы хотелось еще раз сфокусировать внимание читателей, кто пользуется этой диаграммой или так или иначе не равнодушен к UML, на типовых ошибках, которые совершают начинающие разработчики этой диаграммы.
Сначала я сформулирую задачу, на примере которой будут показаны типовые ошибки. Итак, во всем мире являются популярными соревнования по спортивному ориентированию. Лыжник должен за определенное время, имея у себя карту местности, пройти все контрольные точки, которые отмечены на этой карте. В настоящее время в этих контрольных точках стоят судьи, которые и отмечают факт прохождения спортсменом точек на карте. Однако в лесу прохладно , и поэтому лучше заменить судей бездушными автоматическими контрольными станциями, которые бы сообщали о факте прохождения контрольной точки на судейский пункт в момент, когда спортсмен прикасается к этой станции браслетом с чипом. Вся информация о ходе соревнования выводится на большое табло. Кроме того, за соревнованиями можно наблюдать через Интернет при условии создания аккаунта на сайте и подтверждения этого аккаунта администратором.
Вот такая задача. Теперь рассмотрим, для чего мы здесь будем использовать Use Case диаграмму. Когда мы разрабатываем программную систему важно понимать, для кого мы ее делаем. Да, программная система призвана решать проблемы заинтересованных лиц, однако все же с программой будет работать конкретный пользователь, и именно для пользователя мы разрабатываем ее, именно с точки зрения пользователя мы будем формировать список функций нашей системы. Отсюда следует, что Use Case диаграмма как раз и создается с точки зрения пользователей системы. При этом нужно иметь в виду, что пользователь не является частью системы, а лишь с ней взаимодействует – он активно «давит» на кнопки панели инструментов, всячески инициирует работу тех или иных функций программы. Он является первичным (активным) актором, который на диаграмме принято изображать слева. С другой стороны, наша система взаимодействует по принципу «клиент-сервер» с другими системами – серверами баз данных, различными веб-сервисами и т.д. Такие системы являются вторичными (пассивными) акторами и взаимодействуют с нашей системой, только если от нее придет запрос. Давайте посмотрим, что показано на вот этой диаграмме.
Здесь мы видим, что часть пользователей нашей системы обозначены как вторичные акторы (те, что справа). Об этом говорит сайт https://intellect.icu . Фактически данная диаграмма читается как то, что пользователей подключили проводами к компьютеру и переодически бъют током, чтобы вызвать у него ответную реакцию на это событие 
. Это первая ошибка.
Вторая ошибка состоит в том, что здесь мы видим Use Case «Носить браслет». Это функция пользователя, которая вообще не имеет отношение к нашей системе, а как мы уже договорились, пользователь не является частью создаваемой нами системы. Поэтому данный Use Case из этой диаграммы следует удалить.
Третья ошибка на данной диаграмме состоит в наличии так называемых «подвисших Use Case». Ранее мы обсуждали, что функции системы инициируются пользователем. На этой диаграмме мы видим Use Case «Фиксировать прохождение КС» и «Отображение карты местности». Кто иницирует эти функции? Вторичный актор не может этого делать, исходя из того что он сам работает по запросу из нашей системы.
Теперь я хочу обратить ваше внимание на другую интересную ошибку. Посмотрим диаграмму Use Case другого автора этой же задачи:
Здесь мы видим довольно странного актора «System». Очень сложно понять, что он будет делать. Судя по всему, разработчик этой диаграммы имел в виду ту самую систему, которую мы же и разрабатываем. Но рекурсия здесь не работает – система не может являться актором самому себе, исходя из определения актора, а все Use Case, которые мы указываем на диаграмме, имеют отношение именно к нашей системе. Таким образом, когда мы указываем актора, мы должны четко понимать, для чего он здесь, зачем он взаимодействует с нашей системой или зачем мы взаимодействуем с ним. Кстати, здесь же мы опять видим ранее рассмотренную ошибку о «подвисшем Use Case».
Диаграмма Use Case призвана показать, какие функции она предоставляет пользователю, но она не призвана показать, как эти функции выполняет система. В связи с этим весьма распространенной ошибкой является попытка показать на диаграмме Use Case, как будут выполняться те или иные функции. Для показа «как система будет выполнять функции» существуют другие UML диаграммы. Посмотрим пример такой диаграммы:
Use Case «Input data about spertsman» (сохранено оригинальное название, данное автором этой диаграммы) говорит о том, что здесь мы будем вводить данные о спортсмене. Здесь этой информации, что мы просто вводим данные, достаточно. А какие это данные, мы узнаем из модели предметной области, где уже на диаграмме классов отражаются атрибуты спортсмена. Но здесь это просто не нужно делать. Кроме того, заказчик изменит требования, внесет еще какие-то характеристики спортсмена, которые ему важны, и из-за этого нам перестраивать диаграмму? Поэтому на диаграмме Use Case мы показываем лишь «что система будет делать для пользователя», а не «как она это будет делать».
И в конце самая «вкусная» ошибка этой задачи. Является ли браслет актором? Проанализируем вот эту диаграмму:
Обратите внимание на Use Case «Pass the chekpoint». Мы видим, что его инициируют два первичных актора «Runner» (т.е. спортсмен) и «Bracelet». Если с первым все понятно и логично, то почему браслет, который надет на спортсмене, выступает в качестве самостоятельного актора? Чтобы понять, кем здесь является браслет, достаточно сказать, что на диаграммах Use Case связь между актором и Use Case (в миру UML называемая ассоциацией) по сути означает интерфейс пользователя, когда мы говорим о первичном акторе, и интерфейс к внешней системе, когда мы говорим о вторичном акторе. Мы все привыкли, что интерфейс пользователя – это исключительно UI. А в этой задаче для спортсмена UI нет – для него есть контрольная станция, интерфейсом для которой и является его браслет. Таким образом, если мы убираем с этой диаграммы актора «Bracelet», то все встает на свои места.
Мы рассмотрели часто встречающиеся ошибки. Готов обсудить ваше решение этой задачи в комментариях.
Расширение (англ. Extend) — разновидность отношения зависимости между базовым вариантом использования и его специальным случаем.
Включение (англ. Include) — определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого всегда задействуется базовым вариантом использования.
То есть include (стрелки идут от базового варианта) иллюстрирует что именно использует базовый вариант для выполнения операции
Так например - Include - хорошо исллюстрирует ту ситуацию, что восстановление работоспособности компьютера неизбежно связано с одним из трех действий (предположим, что иных вариантов нет):
Таким образом от вариант использования "восстановить работоспособность ПК" можно уточнить именно с помощью таких вот "включений" - Include . В данном случае вариант использования не выполним без одного из перечисленных выше действий.
В то время как extend указывает на возможность особенного использования базового варианта (стрелки идут к базовому варианту от специальных)
Так , например - если вернуться к ситуации с компьютером - то с помощью extend - можно было бы расширить уже вариант использвоания "обнаружение и удаление вируса " - с помощью опции"обнаружение и удаление с последующей установкой системы защиты" - которая, впрочем, не обязательно привлекается -если поставлена задача удаления вируса.
Эта необязательность как раз и есть важнейшее различие между extend и include
Надеюсь, эта статья про типовые ошибки в use case диаграммах, была вам полезна, счастья и удачи в ваших начинаниях! Надеюсь, что теперь ты понял что такое типовые ошибки в use case диаграммах, разница между include и extend и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Моделирование и Моделирование систем
Комментарии
Оставить комментарий
Моделирование и Моделирование систем
Термины: Моделирование и Моделирование систем