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

——————————————————————————

8 Вопрос. Унифицированная концепция (rup) разработки по: фазы, операции. Определение требований в uml-формате.

9 Вопрос. Унифицированная концепция (rup) разработки по: анализ и проектирование. Понятие класса, типы и примеры классов, uml-диаграммы.

——————————————————————————

Стратегия rup Rational Unified Process

— для многоуровневого детального описания всех аспектов и этапов разработки ПО.

Конечная цель: максимальная локализация постановки задачи для программистов.

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

Функциональные требования выражаются в виде сценариев использования (Use Case), который отображает необходимость взаимосвязи программы с пользователями или сторонними объектами.

КЛИЕНТ –––> СЕРВЕР

4 фазы жизненного цикла RUP:

1. Inception (начальная фаза: определение требований).

2. Elaboration (фаза уточнения: анализ и проектирование).

3. Construction (фаза реализации: построение).

4. Transition (фаза внедрения).

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

Базовые операции в каждой итерации RUP:

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

Детализируется спецификация проекта (ТЗ) с той особенностью, что требования к функциональным возможностям ПО описываются в виде сценариев использования на диаграмме сценариев (Use Case Diagram).

Пример.

Интернет магазин по продаже деталей машин.

(Ссылка на сайт: exist.ru)

Необходимые функции:

1. Поиск деталей.

2. Помещение деталей в корзину для покупок.

3. Редактирование корзины (удаление деталей, изменение их количества).

4. Оформление заказа с выбором способа оплаты.

Последний сценарий можно разделить на два:

1) Оформление заказа.

2) Выбор способа оплаты.

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

Условный механизм подключения функций называется связью расширения (extends). extends ↓ оформление заказа <——— выбор способа оплаты

Если подключаемый сценарий (функция) должен вызываться в любом случае, то связь называется «includes».

Пример.

My Use Case:: Я еду в город.

includes —> Водить машину (необходимое условие).

extends —> Заполнить бак бензином (необязательное условие, так как бак может уже быть заполнен полностью).

Необязательность является главным различием между includes и extends.

UML-нотация.

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

1) Каждому сценарию использования (Use Case) сопоставляется диаграмма последовательности действий сценария (Sequence Diagram), которая отображает все действия в рамках данного сценария в виде обмена сообщениями между структурными компонентами (объектами), причем этот обмен на диаграмме упорядочен по времени передачи сообщений, т. е. выполнения соответствующих им действий.

2) С выделенными объектами связываются классы с определением их атрибутов и операций.

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

Пример.

Класс — студент (student).

Параметры класса:

— Имя (тип string).

— Фамилия (тип string).

— Оценка за коллоквиум 1 (тип int).

— Оценка за коллоквиум 2 (тип int).

— Рейтинг (тип float).

Объекты класса (или экземпляры класса) отличаются конкретными значениями общих атрибутов.

Классы отображаются на диаграмме классов (Class Diagram).

Классы подразделяются на:

1. Информационные (Entity) (группировка обрабатываемых данных; роль контейнеров).

2. Интерфейсные (Boundary) (механизмы передачи данных).

3. Управленческие (Control) (преобразование данных и управление ими).

Для рассмотренной выше части интернет-магазина можно выделить:

1) Информационный класс данных по деталям, одна часть из которых предоставляется клиенту, а другая часть имеет внутрисистемный характер.

2) Информационный класс данных по корзине.

3) Информационный класс данных по заказу.

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

5) Интерфейсный класс, который передает клиенту информацию о найденной детали и предоставляет возможность помещения детали в корзину.

6) Интерфейсный класс, позволяющий изменить содержимое корзины и перейти из нее к оформлению заказа.

7) Интерфейсный класс выбора способа оплаты.

8) Интерфейсный класс оформления заказа.

9) Управленческий класс поиска детали с формированием входных данных по ней.

10) Управленческий класс преобразования данных из корзины в данные по заказу.