Построение модели прецедентов

Что определяют прецеденты?

· Поиск и описание классов

· Поиск и описание подсистем и интерфейсов

· Поиск и описание прецедентов тестирования

· Планирование итераций разработки

· Системную интеграцию

Цели сбора требований к системе:

· Определение существенных требований

o Существенные те, которые принесут пользователю ощутимый и значимый результат

· Представление в форме удобной для:

o пользователей

o заказчиков

o разработчиков

с использованием понятного для всех языка

Построение модели прецедентов

· Выявление категорий пользователей

· Представление категорий с помощью актеров языка UML

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

· Модель прецедентов – полный набор актеров и прецедентов

Построение модели анализа

· Модель анализа – описание структуры системы с использованием концептуальных классификаторов

· Отдельная модель сопровождаемая для больших систем

· Первая модель в понятиях привычных разработчику системы (классификаторы, пакеты, …)

· Используется также и для сбора требований

· Нет привязки к особенностям реализации

o к ЯП

o к ОС

o к СУБД

o к библиотекам, используемым для построения интерфейса пользователя

· Составляет 20% от объема модели проектирования (Design Model)

Построение модели проектирования

· Для модели проектирования (design model) строится иерархия классов и интерфейсов

· Описываются детально отношения ассоциации

· Описываются отношения зависимости

· Детально с использованием классификаторов и с помощью диаграмм поведения языка UML описываются реализации прецедентов

· Затем модель проектирования отображается в модель реализации (Implementation Model)

· Выполняется привязка к конкретным инструментам разработки:

o ЯП

o ОС

o СУБД

o библиотекам построения интерфейса пользователя

· Классы группируются в подсистемы, между которыми определяются интерфейсы

· Строится модель внедрения (deployment model) описывающая распределения системы по вычислительным узлам

Построение модели реализации

· Разбиение системы на компоненты

o файлы исходных текстов

o jar-файлы

o war-файлы

o exe-файлы

o DLL-файлы

· Распределение компонент по вычислительных узлам и директориям файловой системы

· Определение отношений зависимости между компонентами

Построение модели тестирования (Testing Model) - Тестирование вариантов использования системы

· Модель тестирования (Testing Model)

o для проверки реализации функциональности определенной в модели прецедентов

o для проверки нефункциональных требований к системе

· Модель тестирования содержит прецеденты тестирования (Test Cases). Из прецедентов получаются:

o Входные данные

o Условия выполнения прецедентов

o Результаты

· Прецеденты тестирования (Test Cases) получаются сразу после получения прецедентов использования (Use Cases). Следовательно возможно планирование «черного ящика»

· После получения модели проектирования возможно тестирование «белого ящика». Каждая ветвь в реализации прецедента использования определяет отдельный прецедент тестирования белого ящика.

2. Процесс ориентированный на разработку архитектуры системы. Понятие архитектуры системы. Необходимость архитектуры системы. Связь вариантов использования системы и ее архитектуры. Этапы в разработке архитектуры системы. Описание архитектуры системы.

Описание архитектуры

Сложность создания описания архитектуры – извлечение только самого важного без добавления в описание нового

Первая версия описания архитектуры появляется в конце фазы Elaboration

Сложно сохранить описание системы небольшим

Зачем нужна архитектура?

· Для понимания системы

· Для организации разработки системы

· Для стимулирования повторного использования уже написанного кода и компонент системы

· Для развития системы в дальнейшем

Понимание системы

· Сложное поведение системы

· Работа в сложном окружении – сложно интегрировать во множество компонент, разработанных сторонними разработчиками

· Используются сложные технологии (EJB или COM)

· Используют и индивидуальные пользователи, и группы пользователей

· Разрабатываются распределено (географически) и поэтому необходимо координировать работу

Организация разработки

· Организация разработки существенно упрощается, если может выполняться распределенно и параллельно

· Назначение групп ответственных за подсистемы дает возможность распределённости и независимости

· Стабильные интерфейсы – позволяют независимо развивать программу по обе стороны интерфейса

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

Шаблоны архитектуры

· Façade – предназначен для создания упрощенного интерфейса для группы подсистем или сложной подсистемы

o Область применения:

§ Необходимо предоставить более простой вариант стандартного интерфейса

§ Уменьшить зависимость клиента от подсистемы

§ Нужно создать слои подсистемы

· Decorator – представление механизма для добавления или удаления функциональности компонентов без изменения их внешнего представления или функции

o Назначение:

§ Необходимо динамически менять свойства классов

· незаметно для пользователя класса

· не испытывая ограничения механизма наследования классов

§ Свойства компонента динамически включаются и отключаются

§ Есть несколько независимых функций, применяемых:

· динамически

· в разной комбинации

· Layers – способ организации модели проектирования на уровни

o Компоненты одного уровня могут ссылаться только на компоненты нижнего уровня:

=> Упрощение: Компоненты нижнего уровня не зависят от:

· интерфейсов верхнего уровня

· реализации верхнего уровня

Развитие системы

· Развитие стимулируется изменением окружения системы

· Может потребоваться новая функциональность системы

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

Принципы разработки системы

1. Функциональная модульность. Классы группируются в optional сервисные подсистемы SSS. SSS имеют только внутреннее сцепление (cohesion) => SSS независимы.

2. Отделение проектирования интерфейсов от проектирования SSS

a. => несколько SSS могут поддерживать тот же интерфейс

b. => возможна замена подсистем, поскольку зависимость клиента только от интерфейса

3. SSS – на этапе проектирования помещается в отдельную компоненту

a. => компоненты могут быть размещены на разные вычислительные узлы

4. Необходимо уменьшение сцепления между SSS.

a. => единственный способ общения между подсистемами через асинхронные сигналы

b. => поощряется не только инкапсуляция, но и распределенность

Шаги к архитектуре

· Результат фазы Elaboration – фундамент архитектуры (скелет системы).

· Выбор прецедентов для построения архитектуры

o те которые позволяют оценить наиболее серьезные риски

o наиболее важная функциональность для пользователя

· Реализация, интеграция и тестирование фундамента архитектуры приводит к демонстрационной версии системы от которой идет обратная связь

· Фундамент архитектуры – небольшая тощая система, которая имеет все модели, которые имеет полная система в конце конструирования

· Фундамент имеет скелет для:

o Подсистем

o Компонент

o Вычислительных узлов

o Поведение

o Исполняемый код

· После стабилизации фундамента архитектуры заканчивается фаза уточнения.

Модель прецедентов

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

В нашей модели (условно) наиболее важным будем считать прецедент WithdrawMoney.

Модель проектирования

· Наиболее важные подсистемы

· Интерфейсы

· Несколько особенно важных классов

· Активные классы

· Реализация наиболее важных прецедентов с помощью описанных в архитектуре классификаторов

· Распределение активных классов по вычислительных узлам

Модель проектирования архитектуры:

· Активные классы

Все активные классы включаются в описание модели проектирования архитектуры.

Классы необходимые для понимания реализации прецедента WithdrawMoney.

 

· Подсистемы и их интерфейсы

Подсистемы и интерфейсы необходимые для понимания реализации прецедента WithdrawMoney.

· Реализация прецедента WithdrawMoney

Взаимодействие подсистем для реализации прецедента WithdrawMoney

Итеративность и инкрементальность процесса. Почему необходима итеративная и инкрементальная разработка. Управление рисками при итеративном подходе в разработке системы. Типовая итерация. Инкремент как результат итерации. Итерации в жизненном цикле системы. Развитие моделей в результате итераций.

Фазы итеративного процесса

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

Внутри каждой фазы процесс проходит через итерации и приращения (increment).

Фаза анализа и планирования требований (inception)

На этой фазе критерий – определение жизнеспособности проекта:

· Определение и уменьшение рисков критичных для жизнеспособности системы

· Выделение ключевых требований -> моделирование прецедентов -> получение архитектуры-кандидата

· Получение оценки: стоимости, сроков разработки, качества разрабатываемого продукта

· Составление бизнес-плана подтверждающего возможность выполнимость проекта

Примеры рисков представления системы

· Скорость работы

· Память, используемая системой

· Точность вычислений

· Надежность

· Доступность

Работа с рисками

После идентификации рисков и задания их приоритетов

· Уход от риска, перепроектировав проект или изменив требования к системе

· Ограничить риск, чтобы при этом затрагивалась по возможности меньшая часть системы или проекта

· Материализация риска, проверив оправдались ли опасения. Затем уход от риска или ограничение риска

· Риск оправдался. Если исправить невозможно, то возможен отказ от проекта с минимальными затратами времени и денег, до вовлечения в проект большого числа людей.

Типовая итерация

Итерация – мини-проект при полном проходе по всем потокам работ (workflows).

Поток работ – кооперация между исполнителями (workers) производящими и использующими артефакты.

Пять основных потоков работ:

· Определение требований

· Анализ

· Проектирование

· Реализация

· Тестирования

Типовая итерация

· Исполнители и артефакты могут участвовать более чем в одном потоке работ.

Например, разработчик компонент (component engineer) участвует в потоках работ по анализу, проектированию и реализации.

· После завершения итерации

o Регрессионное тестирование

o Оценка изменений требований

o Оценка появления новых требований

 

4. Поток работ для получения требований к системе. Получение требований к разрабатываемой системе. Проблемы, возникающие при получении требований к системе. Цели потока работ на этапе получения требований. Роль требований в жизненном цикле программного обеспечения. Понимание контекста системы с использованием модели предметной области. Понимание контекста системы с использованием бизнес - модели. Дополнительные требования.

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

Основная задача потока работ по определению требований – построение модели прецедентов использования системы.

Функциональные требования структурируются на прецеденты использования.

Нефункциональные требования привязываются к конкретным прецедентам использования системы.

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

Деятельности: Поиск актеров и сценариев использования; Определение приоритетов для сценариев использования; Детализация сценариев использования; создание прототипа интерфейса пользователя; Структурирование модели сценариев использования;

Схема описания потока работ

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

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

· Описание деятельности (activity) – часть работы за выполнение которой отвечает исполнитель в потоке работ и имеет результат в виде набора артефактов.

Исполнители и артефакты

Модель прецедентов

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

Позволяет заключить соглашение (контракт) на разработку системы.

Структурировать требования на пакеты содержащие прецеденты и диаграммы прецедентов.

Модель прецедентов – исходная модель для построения моделей анализа, проектирования, реализации, тестирования.

Актер

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

Актером может быть внешняя программная система.

Актером может быть внешнее устройство: часы, телефонная карта, …

Актерами могут быть сотрудники или клиенты фирмы, для которой разрабатывается система. И сотрудники, и клиенты могут быть взяты из бизнес-модели.

Примеры артефактов – актеров

Примеры артефактов – актеров и прецедентов

Примеры отношений прецедентов

Прецедент

· Прецедент – способ использования системы.

· Описывает последовательность действий с альтернативами, которые система может выполнить взаимодействуя с актерами.

· Прецедент – классификатор для описания поведения => имеет атрибуты и операции.

· Прецедент может включать:

o диаграммы переходов и состояний

o диаграммы деятельности

o диаграммы взаимодействия

o диаграммы последовательности взаимодействия

Прецедент

· State Transition Diagram – описывает жизненный цикл прецедентов в терминах состояний и переходов

· Activity Diagram – более подробное описание, описывая деятельности выполняемые при переходе на диаграмму состояний и переходов

· Collaboration Diagram и Sequence Diagram – используются для описания взаимодействия между типовым экземпляром актера и типовым экземпляром прецедента.

Типовой жизненный цикл прецедента

· Инициализация прецедента и установка прецедента в начальное состояние

· Активизация прецедента внешним сообщением

· Переход в другое состояние, с выполнением некоторой последовательности действий. Эта последовательность может содержать вычисления, выбор пути на диаграмме и посылку сообщения актеру.

· Ждет в новом состоянии прихода нового сообщения от актера.

· Активизация новым сообщением и повторение цикла.

Особенности прецедента

· Атрибут прецедента локальны для экземпляра прецедента (не могут быть использованы другими экземплярами прецедентов). Взаимодействие прецедента только с актерами.

· Нет конфликта между прецедентами из-за данных.

· Не требуется синхронизация с другими прецедентами.

· Прецедент выполняется полностью или не выполняется совсем.

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

Описание архитектуры (модель прецедентов)

· Важная и критичная функциональность

· Важные требования, которые должны быть реализованы в начале жизненного цикла разработки системы

· Описание архитектуры используется для задания приоритетов в реализации прецедентов

· Использование будет описано при рассмотрении деятельностей потока работ по построению модели прецедентов

Глоссарий

· Определение важных или общих для всего проекта понятий

· Важен для получения согласованных определений приемлемых пользователями, заказчиками, аналитиками и разработчиками системы

· Может возникать из бизнес-модели

Прототип интерфейса пользователя

· Прототип интерфейса пользователя помогает сбору требований к системе

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

· Способствует лучшему пониманию взаимодействия актеров и прецедентов при построении модели прецедентов

· При построении прототипа интерфейса могут использоваться артефакты: модели интерфейса пользователя и скриншоты

 

Артефакты: Модель проектирования; Проект класса; Проект реализации сценария использования; Проект подсистемы; Проект интерфейса. Описание архитектуры (вид модели распределения); Модель внедрения системы.

Артефакты: Модель реализации; Компонента; Подсистема реализации; Интерфейс; Описание архитектуры; План интеграции для реализации.

Что определяют прецеденты?

· Поиск и описание классов

· Поиск и описание подсистем и интерфейсов

· Поиск и описание прецедентов тестирования

· Планирование итераций разработки

· Системную интеграцию

Цели сбора требований к системе:

· Определение существенных требований

o Существенные те, которые принесут пользователю ощутимый и значимый результат

· Представление в форме удобной для:

o пользователей

o заказчиков

o разработчиков

с использованием понятного для всех языка

Построение модели прецедентов

· Выявление категорий пользователей

· Представление категорий с помощью актеров языка UML

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

· Модель прецедентов – полный набор актеров и прецедентов

Построение модели анализа

· Модель анализа – описание структуры системы с использованием концептуальных классификаторов

· Отдельная модель сопровождаемая для больших систем

· Первая модель в понятиях привычных разработчику системы (классификаторы, пакеты, …)

· Используется также и для сбора требований

· Нет привязки к особенностям реализации

o к ЯП

o к ОС

o к СУБД

o к библиотекам, используемым для построения интерфейса пользователя

· Составляет 20% от объема модели проектирования (Design Model)