Документ «Видения». Модель и словарь предметной области.
Видение (Vision) – это представление программного продукта со стороны пользователя или заказчика на уровне ключевых потребностей заинтересованных лиц и свойств системы.
Свойства системы (feature) – это эксплуатационная возможность системы, которая удовлетворяет потребность потребителя.
Пример. Потребность1: повышение оперативности доступа к изменению материала. Свойство ПП1: хранение учебного материала в единой БД, доступной преподавателям и студентам.
Потребность2: общение преподавателей и студентов в неурочное время. Свойство ПП2: реализация электронной почты или электронной доски объявлений.
Модель и словарь предметной области.
Контекстом для разрабатываемой системы является модель предметной области:
1. модель бизнес-процессов, которые протекают в системе;
2. модель предметной области в виде диаграмм.
Модель предметной области определяет наиболее важные классы объектов(уточнение требований - цель ее создания).
Понятия (классы), которые могут выявляться при построении бизнес - модели:
1. физические и материальные объекты (облако, ветер – физические, стул, стол – материальные);
2. спецификация (описание объекта: полета, товара)
3. место расположения (магазин, аэропорт);
4. транзакция (продажа, платеж);
5. роли людей (студент, продавец);
6. контейнеры объектов (склад, касса);
7. содержимое контейнеров;
8. внешние системы;
9. организации (деканат);
|
|
|
10. событие (кража, продажа);
11. правила и политики (правило возврата товара);
12. перечень (каталоги) – каталог товаров.
Ассоциация - отображение взаимосвязи (глаголы).
Роль - является содержанием (для дисциплины - учебный материал).
Цель модели - выявить требования к системе.
Словарь предметной области (глоссарий) – все, что есть в предметной области д.б. в глоссарии, но могут быть и дополнения.
Функциональные и нефункциональные требования к системе. Варианты использования системы.
В процесс определения требований к системе входят определение функциональных и нефункциональных требований.
Функциональные требования (модель прецедентов или вариантов использования) описывают желаемое поведение системы.
Вариант использования (Use Case) – это последовательность действий актанта и реакций системы, приводящая к полезному для актанта результату.
Актант (внесистемный агент, Actor) – внешняя система, взаимодействующая с заданной системой. Актант может быть пользователем, либо технической системой.
Модель вариантов использования – совокупность функциональных требований к системе, описанных в форме вариантов использования. Она содержит описание актантов, спецификации вариантов использования и ассоциаций между ними. Модель вариантов использования является соглашением между заказчиком и разработчиком ПО.
|
|
|
Нефункциональные требования - любые требования, не являющиеся функциональными, например: надежность, производительность, ограничения среды; ограничение реализации; зависимость от платформы; рентабельность; расширяемость. Некоторые нефункциональные требования являются слишком обобщенными и не могут быть привязаны к конкретному варианту использования или конкретному реальному классу. Они должны быть вынесены в отдельный список дополнительных требований
Спецификация вариантов использования включает в себя:
- Название варианта использования
- Актанты
- Краткое описание
- Основной поток событий – типовая и, может быть, самая короткая последовательность действий, дающая актанту желаемый результат
- Альтернативные потоки событий – вспомогательный вариант получения желаемого результата, который используется, если выполнение основного потока не возможно.
- Предусловия
- Постусловия
- Точки расширения
- Особые требования
Прецеденты и отношения между вариантами использования (прецедентами).
Прецедент- описание поведения системы, которым она отвечает на внешние запросы.
|
|
|
Прецеденты различаются по детализации: идеальный прецедент (нет подробного описания); идеальный развернутый прецедент (содержит последовательность действий актанта и откликов системы без указания проектных решений); реальный прецедент (последовательность действий актанта с указанием реакции системы в терминах проектных решений); развернутыйпрецедент - в описании прецедента м.б. базовый поток действий и альтернативный поток.
Классификация прецедентов:
1. по степени использования проектных решений - от идеального до реального;
2. детальность описания – от краткого до развернутого;
3. степень законченности прецедентов: варьирование от конкретного прецедента к абстрактному.
Конкретный прецедент – известно кем и когда он инициируется и всегда полностью выполняется. Абстрактный прецедент, как правило, часть конкретного прецедента.
Отношения между прецедентами:
Для организации прецедентов их группируют в пакеты, так же как и классы. Кроме того, прецеденты можно организовать, определив между ними отношения обобщения, включения и расширения. Эти отношения применяют, чтобы выделить некоторое общее поведение, извлекая его из других прецедентов, которые его включают, или, наоборот, вариации, поместив такое поведение в другие прецеденты, которые его расширяют.
|
|
|
Обобщение (generalization) между прецедентами аналогично отношению обобщения между классами. Это означает, что прецедент-потомок наследует поведение и семантику своего родителя, может замещать его или дополнять его поведение, а кроме того, может быть подставлен всюду, где появляется его родитель, кроме того, как родитель, так и потомок могут иметь конкретные экземпляры. В абстрактном варианте использования обобщаются одинаковые потоки событий других вариантов использования. Отношение обобщения между прецедентами изображаются точно так же, как и обобщения между классами - в виде линии с незакрашенной стрелкой.
Включение (include) – это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем. При этом отношением зависимости (dependency) является такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) приводит к изменению другого элемента (зависимого).
Отношение включения устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве составного фрагмента в последовательность поведения другого варианта использования. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров вариантов использования всегда упорядочена в отношении включения.
Благодаря наличию отношения включения удается избежать многократного описания одного и того же потока событий, поскольку общее поведение можно описать в виде самостоятельного поведения, включаемого в базовые. Отношение включения является примером делегирования, при котором ряд обязанностей системы описывается в одном месте - во включаемом прецеденте, а остальные прецеденты, когда необходимо включают эти обязанности в свой набор.
Расширение (extend) определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий.
В языке UML отношение расширения является зависимостью, направленной к базовому варианту использования и соединенной с ним в так называемой точке расширения. Отношение расширения между вариантами использования обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от того варианта использования, который является расширением для базового варианта использования. Данная линия со стрелкой должна быть помечена стереотипом <<extend>>.
Организация прецедентов путем выделения общего поведения (отношение включения) и различных вариаций (отношение расширения) является важной составной частью процесса разработки простого сбалансированного и понятного набора прецедентов системы.
Дата добавления: 2018-06-01; просмотров: 277; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!