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

Моделирование при помощи диаграмм прецедентов

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

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

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

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

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

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

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

Рис. 6.14.

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

Рис. 6.15.

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

Рис. 6.16.

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

Рис. 6.17.

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

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

Рис. 6.18.

Выводы

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

Контрольные вопросы

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