Граница системы – прямоугольник, очерчивающий прецеденты для обозначения края, или границы, моделируемой системы. В UML 2 эту границу называют контекстом системы (subject).
Актеры – роли, выполняемые людьми или сущностями, использующими систему.
Прецеденты – то, что актеры могут делать с системой.
Отношения – значимые отношения между актерами и прецедентами.
• Модель требований – создаётся разработчиками по результатам сбора информации.
Эти требования являются хорошим исходным материалом для процесса моделирования прецедентов. В частности, функциональные требования предложат прецеденты и актеров. Нефункциональные требования – то, о чем надо помнить при создании модели прецедентов.
• Список возможностей – это набор потенциальных требований, которые могут быть представлены в форме общего описания (vision) проекта или чего либо подобного.
• Кто или что использует систему?
• Какие роли они играют во взаимодействии?
• Кто устанавливает систему?
• Кто или что запускает и выключает систему?
• Кто обслуживает систему?
• Какие системы взаимодействуют с данной системой?
• Кто или что получает и предоставляет информацию системе?
• Происходит ли что нибудь в точно установленное время?
При моделировании актеров необходимо помнить следующие моменты.
• Актеры всегда являются внешними по отношению к системе, следовательно, находятся вне вашего контроля.
• Актеры взаимодействуют непосредственно с системой – так они помогают в определении контекста системы.
• Актеры представляют роли, исполняемые людьми или сущностями по отношению к системе, а не конкретных людей или сущностей.
• Один человек или сущность может играть по отношению к системе множество ролей одновременно или последовательно во времени. Например, вы составляете и ведете учебные курсы. С точки зрения системы планирования курсов вы играете две роли: Trainer (инструктор) и CourseAuthor (автор курса).
• У каждого актера должно быть короткое, осмысленное с прикладной точки зрения имя.
• Каждого актера должно сопровождать краткое описание (одна или две строчки), объясняющее, что данный актер из себя представляет с прикладной точки зрения.
• Как и в классах, в обозначении актеров могут быть представлены атрибуты актера и события, которые он может получать. Такие обозначения не часто используются и редко отображаются на диаграммах прецедентов. Далее в этой книге они не упоминаются.
• Если необходимо смоделировать что-то, происходящее с системой в определенный момент времени, но неинициируемое ни одним из актеров, можно ввести актера под названием Time (время). В качестве примера приведем автоматическое сохранение резервной копии системы, выполняемое ежедневно вечером.
• прецеденты всегда описываются с точки зрения актеров.
Ниже приводится полезный список вопросов, которые можно задавать при идентификации прецедентов.
• Какие функциональные возможности понадобятся конкретному актеру от системы?
• Система сохраняет и извлекает информацию? Если да, какой из актеров инициирует это поведение?
• Что происходит, когда система изменяет состояние (например, при запуске и выключении системы)? Кто нибудь из актеров получает при этом уведомление?
• Какие либо внешние события оказывают влияние на систему? Как система узнает об этих событиях?
• Система взаимодействует с какой либо внешней системой?
• Система генерирует какие либо отчеты?
Кроме определения ключевых терминов глоссарий проекта должен включать синонимы и омонимы.
• Синонимы – это разные слова, обозначающие одно и то же. ОО-аналитик должен выбрать и придерживаться одного из этих слов (того, которое имеет наиболее широкое применение). Остальные варианты должны быть полностью исключены из моделей. Это обусловлено тем, что разрешение на применение синонимов может привести к возникновению двух более или менее одинаковых классов с разными именами. Кроме того, если позволить эпизодическое употребление всех синонимов, можно с уверенностью ожидать, что семантика терминов со временем будет отличаться.
• Омонимы – это слова, одинаковые по звучанию, но разные по значению. В этом случае всегда возникают проблемы общения, поскольку разные стороны говорят на разных языках, но при этом уверены, что говорят об одном и том же. Способ решения – выбрать одно значение для определенного термина, а для других омонимов, возможно, ввести новые термины.
В глоссарии проекта должен быть указан предпочтительный термин и под его определением перечислены все синонимы. При этом, вероятно, некоторым деловым партнерам придется привыкать к другой терминологии. Обычно тяжело заставить заинтересованные стороны изменить используемый ими язык, но при некоторой настойчивости этого удается добиться.
Актеры – роли, выполняемые людьми или сущностями, использующими систему.
Прецеденты – то, что актеры могут делать с системой.
Отношения – значимые отношения между актерами и прецедентами.
Исходные данные для деятельности Выявление актеров и прецедентов
• Бизнес модель – может быть предоставлена в распоряжение разработчиков модели системы, но это не всегда выполняется. Если она есть, это превосходный источник для сбора требований.• Модель требований – создаётся разработчиками по результатам сбора информации.
Эти требования являются хорошим исходным материалом для процесса моделирования прецедентов. В частности, функциональные требования предложат прецеденты и актеров. Нефункциональные требования – то, о чем надо помнить при создании модели прецедентов.
• Список возможностей – это набор потенциальных требований, которые могут быть представлены в форме общего описания (vision) проекта или чего либо подобного.
Выявление актеров
Следующие вопросы помогут идентифицировать актеров.• Кто или что использует систему?
• Какие роли они играют во взаимодействии?
• Кто устанавливает систему?
• Кто или что запускает и выключает систему?
• Кто обслуживает систему?
• Какие системы взаимодействуют с данной системой?
• Кто или что получает и предоставляет информацию системе?
• Происходит ли что нибудь в точно установленное время?
При моделировании актеров необходимо помнить следующие моменты.
• Актеры всегда являются внешними по отношению к системе, следовательно, находятся вне вашего контроля.
• Актеры взаимодействуют непосредственно с системой – так они помогают в определении контекста системы.
• Актеры представляют роли, исполняемые людьми или сущностями по отношению к системе, а не конкретных людей или сущностей.
• Один человек или сущность может играть по отношению к системе множество ролей одновременно или последовательно во времени. Например, вы составляете и ведете учебные курсы. С точки зрения системы планирования курсов вы играете две роли: Trainer (инструктор) и CourseAuthor (автор курса).
• У каждого актера должно быть короткое, осмысленное с прикладной точки зрения имя.
• Каждого актера должно сопровождать краткое описание (одна или две строчки), объясняющее, что данный актер из себя представляет с прикладной точки зрения.
• Как и в классах, в обозначении актеров могут быть представлены атрибуты актера и события, которые он может получать. Такие обозначения не часто используются и редко отображаются на диаграммах прецедентов. Далее в этой книге они не упоминаются.
• Если необходимо смоделировать что-то, происходящее с системой в определенный момент времени, но неинициируемое ни одним из актеров, можно ввести актера под названием Time (время). В качестве примера приведем автоматическое сохранение резервной копии системы, выполняемое ежедневно вечером.
Выявление прецедентов
• прецеденты всегда инициируются актером;• прецеденты всегда описываются с точки зрения актеров.
Ниже приводится полезный список вопросов, которые можно задавать при идентификации прецедентов.
• Какие функциональные возможности понадобятся конкретному актеру от системы?
• Система сохраняет и извлекает информацию? Если да, какой из актеров инициирует это поведение?
• Что происходит, когда система изменяет состояние (например, при запуске и выключении системы)? Кто нибудь из актеров получает при этом уведомление?
• Какие либо внешние события оказывают влияние на систему? Как система узнает об этих событиях?
• Система взаимодействует с какой либо внешней системой?
• Система генерирует какие либо отчеты?
Глоссарий проекта
Глоссарий обеспечивает словарь ключевых деловых терминов и определений. Он должен быть понятен всем участникам проекта, включая все заинтересованные стороны.Кроме определения ключевых терминов глоссарий проекта должен включать синонимы и омонимы.
• Синонимы – это разные слова, обозначающие одно и то же. ОО-аналитик должен выбрать и придерживаться одного из этих слов (того, которое имеет наиболее широкое применение). Остальные варианты должны быть полностью исключены из моделей. Это обусловлено тем, что разрешение на применение синонимов может привести к возникновению двух более или менее одинаковых классов с разными именами. Кроме того, если позволить эпизодическое употребление всех синонимов, можно с уверенностью ожидать, что семантика терминов со временем будет отличаться.
• Омонимы – это слова, одинаковые по звучанию, но разные по значению. В этом случае всегда возникают проблемы общения, поскольку разные стороны говорят на разных языках, но при этом уверены, что говорят об одном и том же. Способ решения – выбрать одно значение для определенного термина, а для других омонимов, возможно, ввести новые термины.
В глоссарии проекта должен быть указан предпочтительный термин и под его определением перечислены все синонимы. При этом, вероятно, некоторым деловым партнерам придется привыкать к другой терминологии. Обычно тяжело заставить заинтересованные стороны изменить используемый ими язык, но при некоторой настойчивости этого удается добиться.
Спецификация прецедента
Матрица отображаемости требований
Когда применять моделирование прецедентов
Прецеденты являются лучшим выбором для фиксирования требований в тех случаях, когда:• в системе преобладают функциональные требования;
• в системе много типов пользователей, которым она предоставляет разные функциональные возможности (много актеров);
• в системе много интерфейсов (много актеров).
Прецеденты не стоит применять в тех случаях, когда:
• в системе преобладают нефункциональные требования;
• в системе мало пользователей;
• в системе мало интерфейсов.
Отношения прецедентов
Отношение «include» выносит шаги, общие для нескольких прецедентов, в отдельный прецедент, который потом включается в остальные.Отношение «extend» – способ введения нового поведения в существующий прецедент.
Комментариев нет:
Отправить комментарий