Главная » UML » Уровни прецедентов UML

0

 

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

 

ным обеспечением, тогда как прецедент бизнес-процесса (business use case) представляет собой реакцию бизнес-процесса на действие клиента или некоторое событие.

В книге Кокборна [10] предлагается схема уровней прецедентов. Базовый прецедент находится на «уровне моря». Прецеденты уровня моря (sea level) обычно представляют отдельное взаимодействие ведущего актера и системы. Такие прецеденты предоставляют ведущему актеру какой-либо полезный результат и обычно занимают от пары минут до получаса. Прецеденты, которые существуют в системе, только если они включены в прецеденты уровня моря, называются прецедентами уровня рыб (fish level). Прецеденты высшего уровня, уровня воздушного змея (kite-level), показывают, как прецеденты уровня моря настраиваются на более широкое взаимодействие с бизнес-процессами. Обычно прецеденты уровня воздушного змея являются прецедентами бизнес-процессов, а на уровне моря и на уровне рыб находятся прецеденты системы. Большинство ваших прецедентов должно принадлежать уровню моря. Я предпочитаю указывать уровень в начале прецедента, как показано на рис. 9.1.

 

Прецеденты и возможности (или пожелания)

 

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

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

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

 

Когда применяются прецеденты

 

Прецеденты представляют собой ценный инструмент для понимания функциональных требований к системе. Первый вариант прецедентов должен составляться на ранней стадии выполнения проекта. Более

 

подробные версии прецедентов должны появляться непосредственно перед реализацией данного прецедента.

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

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

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

 

Где найти дополнительную информацию

 

Впервые прецеденты были изложены в доступной форме Айваром Джекобсоном в [24].

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

Однако за последние несколько лет книга Кокборна [10] стала стандартом по этому предмету. Я следовал терминологии и советам этой книги по той веской причине, что когда в прошлом мы расходились во мнениях, в конце концов я соглашался с Алистером Кокборном. Он поддерживает веб-сайт по адресу http://usecases.org. В книге [11] предлагается убедительный процесс получения пользовательских интерфейсов из прецедентов; посетите также сайт по адресу http://foruse.com

 

Источник: Фаулер М.UML. Основы, 3-е издание. – Пер. с англ. – СПб: Символ-Плюс, 2006. – 192 с.,ил.

По теме:

  • Комментарии