Лабораторная работа №3. Моделирование прецедентов (методика ICONIX) (стр. 1 )

Лабораторная работа №3

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

(методика ICONIX)

Моделирование прецедентов в теории. 1

Основные элементы моделирования прецедентов. 2

Зачем необходимы прецеденты в дополнение к функциональным требованиям?. 3

Не забудьте написать сценарии обработки исключительных ситуаций (Rainy-Day Scenarios). 4

Создайте предварительный вариант модели предметной области прежде чем писать сценарий прецедента 4

Правила составления прецедентов. 4

10 самых распространенных ошибок при моделировании прецедентов. 8

Работа с вариантами использования. 10

Организация вариантов использования в пакеты.. 10

Написание текстов вариантов использования. 15

Пример. 15

Основные отличия варианта использования от алгоритма. 18

Варианты использования и аспектно-ориентированное проектирование. 20

Моделирование прецедентов на практике. 22

Упражнения. 22

Задания. 25

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

Основной вопрос, который необходимо задать в начале разработки любой информационной системы: «Что хотят сделать ее пользователи?». Попытаемся как можно подробнее представить действия пользовате­лей и реакцию системы, поскольку ее поведение обусловлено их требова­ниями. Другими словами, работа системы зависит от того, как к ней обра­щаются и чего хотят добиться. Часто эти вопросы связаны с графическим интерфейсом пользователя.

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

Из рисунке 1 также видно, что мы постоянно уточняем статическую мо­дель на основе анализа прецедентов. То же самое касается диаграмм при­годности и последовательности. Статическая модель развивается по мере рассмотрения все новых сценариев. Именно так происходит эволюция от грубой модели предметной области к детальной статической модели уровня проектирования. Этот подход целиком и полностью основывается на прецедентах - они определяют и архитектуру, и проект программной системы.

Наш подход к построению динамической модели можно описать как «снаружи внутрь». Мы начинаем с обследования пользователей, которые находятся вне системы, и по пути раскрываем детали поведения програм­мы. На этой основе создается структура программы, которая поддерживает требуемое поведение. Продвижение направлено внутрь, его шагом являет­ся рассмотрение одного конкретного сценария. Поскольку прецеденты - это фундаментальные единицы декомпозиции, то все остальное жестко подчинено этому движению. В результате можно быть уверенным, что спро­ектированная система будет отвечать требованиям пользователей, а это со­всем не мало.

Рисунок 1 – Место моделирования прецедентов в общей картине процесса ICONIX

С помощью прецедентов можно описать функциональные требования к системе. Прецеденты помогают ответить на вопросы: что пользователи пытаются сделать с помощью системы? Чем система может быть им полезна? То, что у них получится на самом деле, зависит от способа, которым пользователь взаимодействует с системой.

Основные элементы моделирования прецедентов

Чтобы решить задачу построения прецедентов для новой системы, необ­ходимо с самого начала идентифицировать как можно больше прецеден­тов, а затем составить и постоянно уточнять их словесное описание. По ходу дела будут обнаруживаться новые прецеденты и общие для них фраг­менты.

При выявлении прецедентов необходимо всегда помнить главный прин­цип: их следует тесно связывать с будущим руководством пользователя. Связь между каждым прецедентом и разделом руководства должна быть очевидной. Это подкрепляет основную идею, состоящую в том, что проект системы базируется на восприятии ее пользователями. Можно сказать, что «основа на прецедентах» означает: «Сначала напишите руководство поль­зователя, а потом код». Если вы перерабатываете унаследованную систе­му, то можете просто отталкиваться от руководства пользователя и вносить необходимые изменения.

Написав какой-то текст прецедента, отшлифуйте его, сформулировав предложения в ясной и краткой форме. Постарайтесь, чтобы каждое пред­ложение имело структуру существительное-глагол-существительное, а актеры и потенциальные доменные объекты были сразу видны. Как толь­ко обнаруживаются новые объекты или уточняется поведение ранее най­денных, сразу обновите модель предметной области (предыдущая лабораторная работа). И еще очень важно иметь в виду все возможные альтернативные последователь­ности действий для каждого прецедента, хотя на их учет уходит большая часть времени. Отметим, что анализ пригодности, который мы обсудим в лабораторной работе 5, способству­ет выполнению последовательных уточнений.

Некоторые авторы призывают использовать развернутые шаблоны пре­цедентов. Но наши рекомендации всем ученикам таковы:

1. Создайте шаблон прецедента, в котором есть разделы «Главная по­следовательность» и «Альтернативные последовательности». Другие разделы не нужны, они будут только отвлекать внимание.

2. Задайте себе вопрос: «Что происходит?». С ответа на него начинает­ся главная последовательность.

3. Спросите себя: «А что дальше?». Продолжайте в том же духе, пока все детали главной последовательности не будут записаны на бумаге.

А. Спросите себя: «А что еще может происходить?». Будьте упорны. Хоть что-нибудь еще может происходить? Вы уверены? Задавайте себе эти вопросы, пока не появится достаточно обширный набор аль­тернатив. Поверьте, проблемы на этом этапе - ничто по сравнению с бедами, возникающими, скажем, во время тестирования сопряжений.

Цель состоит не в том, чтобы построить красивую модель прецедентов; важно учесть все, что может сделать пользователь.

Вы еще будете анализировать этот материал при рецензировании тре­бований (лабораторная работа 4), и еще раз во время рецензирования предварительного проекта (лабораторная работа 6), и снова при рецензировании окончательного проекта (лабораторная работа 8). Если вам кажется, что это чересчур, вспомните: чем четче опре­делено поведение системы, тем легче ее построить.

В вашем распоряжении есть несколько механизмов для вычленения фрагментов (к примеру, обработки ошибок), общих для некоторого набо­ра прецедентов. Обычно это разумно, так как разбиение на атомарные блоки упрощает анализ и экономит время при рисовании диаграмм. Бу­дете ли вы применять механизм обобщения прецедентов и отношения включения (include) и расширения (extend), имеющийся в UML, или от­ношения вызова (invoke) и предшествования (precede) из языка Open Modeling Language (OML), цель состоит в том, чтобы получить на­бор небольших, четко очерченных и допускающих повторное использо­вание прецедентов.

Мы рекомендуем объединять прецеденты в пакеты главным образом потому, что последние определяют логические участки работы, которые можно распределить между различными группами сотрудников. Стоит придерживаться правила: каждый пакет должен соответствовать главе или, по крайней мере, большому разделу руководства пользователя.

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

·  созданные прецеденты описывают всю требуемую функциональ­ность системы;

·  для каждого прецедента четко и кратко описана главная последова­тельность действий, а также все альтернативные последовательности;

·  выделены (с помощью того или иного удобного для вас механизма) сценарии, общие для нескольких прецедентов.

·   

Зачем необходимы прецеденты в дополнение к функциональным требованиям?

Прецеденты дают источник информации, с помощью которой можно начать проектирование и приблизительно оценить будущие временные затраты на реализацию.

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

Функциональные требования – не единственный источник для составления прецедентов. Весьма важно взаимодействие с заказчиком и конечными пользователями, а также составление прототипов интерфейсов.

Не забудьте написать сценарии обработки исключительных ситуаций (Rainy-Day Scenarios).

В прецедентах нужно отражать действия пользователя и реакцию на них системы. Эти действия можно разделить на относящиеся к основному сценарию взаимодействия с системой (Sunny-Day Scenarios) и к альтернативному сценарию (Rainy-Day Scenarios) взаимодействия с системой. Альтернативный сценарий включает в себя действия, которые пользователь вынужден совершать, когда что-то пошло не так (возникли ошибки).

Создайте предварительный вариант модели предметной области прежде чем писать сценарий прецедента

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

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

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