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

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

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

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

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

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

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

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

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

Рис. 8.14.

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

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

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

Рис. 8.16.

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

Рис. 8.17.

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

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

Рис. 8.18.

Дата добавления: 2014-02-26; просмотров: 963; Нарушение авторских прав

Мы поможем в написании ваших работ!