Приведенные критерии используются для распределения по итерациям. Кроме того, прецеденты или их отдельные сценарии ранжируются с целью определения приоритетов при реализации. На начальных итерациях реализуются прецеденты с высоким рейтингом. В среднем фаза развития состоит из 2-4 итераций длительностью от двух до шести недель каждая. Время каждой итерации жестко фиксируются. Время жестко фиксируется так, чтобы к ее завершению был получен устойчивый протестированный код. Если некоторые требования не укладываются в сроки итерации, то они могут быть перенесены на следующую итерацию. То есть делается акцент на быструю реализацию небольшого функционала, а не на построение всей системы.

26. Моделирование предметной области и основные понятия модели предметной области

Модель предметной области. (МПО)

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

Каждой итерации соответствует своя модель предметной области, отражающая реализуемый на данном этапе сценарий прецедентов. Таким образом МПО эволюционирует в процессе разработки системы.

Модель предметной области связана с моделью проектирования. Особенно программными объектами, относящимися к уровню предметной области.

Основные понятия МПО отображаются в словаре терминов.

Модель предметной области отображает классы понятий реального ​мира, а не программные компоненты. На языке UML

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

1.Объекты предметной области или концептуальные классы.

2.Ассоциации между концептуальными классами

3.Атрибуты концептуальных классов.

В модели предметной области не используются:

1.артефакты программирования (окна, БД) (если не программное средство)

2.Обязанности, методы

Концептуальный класс – представление идей или объекта. Его можно рассматривать в терминах символов, содержания и расширения.

1.Символы – слова или образы, представляющие концептуальный

класс.

2.Содержание – определение концептуального класса.

3.Расширение – набор примеров, к которым применим этот концептуальный класс.

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

Если некоторый объект Х в реальном мире не является числом или текстом, значит это скорее концептуальный класс, чем атрибут.

27. Использование классов описаний и производных атрибутов в процессе моделирования предметной области

Класс описания – содержит информацию о свойствах некоторого объекта.

Класс описания вводится в следующих случаях:

1.Существует необходимость описания элементов или служб, независимо от существования конкретных экземпляров этих объектов.

2.Если удаление экземпляров, описываемых им понятий, приводит к потере важной информации в связи с некорректной ассоциацией этой информации с удаляемым экземпляром.

3.Если при наличии понятия устраняется дублирование информации.

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

28. Понятие системного события и идентификация системных событий

Системное событие (system event) — это событие высокого уровня, генерируемое внешним исполнителем (событие с внешним

входом). Системные события связаны с системными операциями (system operation), т.е. операциями, выполняемыми системой в ответ на события.

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

Контроллер (controller) — это объект, не относящийся к интерфейсу пользователя и отвечающий за обработку системных событий. Контроллер определяет методы для выполнения системных операций.

Системные события не обрабатываются на уровне представления

Типы событий:

●​ Внешние (пользователь, другая система) ●​ Временные (таймер, расписание)

●​ Сигнальные (ошибки, прерывания)

29. Открытый системный интерфейс и описание операций в рамках унифицированного процесса проектирования

Открытый системный интерфейс — это совокупность системных операций, которые доступны извне и вызываются в ответ на внешние (входные) события. Система обрабатывает такие события как «чёрный ящик», то есть без раскрытия внутренней логики — только по описанным входам и выходам.

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

Описание операций показывает, как система меняет состояние объектов предметной области после выполнения операций. Это важно для проектирования логики приложения и баз данных.

Описание операций содержит разделы:

Вразделе постусловия декларируется изменение состояния объектов

вмодели предметной области. К таким изменениям относятся:

1.​ Создание или удаление экземпляра 2.​ Формирование или разрыв ассоциации 3.​ Изменение атрибута

Постусловия — это не действия, а результат:

●​ Создан/удалён объект ●​ Связь между объектами установлена или разорвана

●​ Значение атрибута изменено

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