Условие ДЗ

Технологии проектирования, 2013г.

Домашнее задание

«Проектирование СОИУ по технологии унифицированного процесса»

по курсу Технологии проектирования

Цель работы:

Изучить теоретические принципы итерационно-инкрементного (унифицированного) процесса разработки СОИУ и составляющих его этапов. Получить практические навыки проектирования и оценки качества проекта в соответствии с унифицированным процессом. Освоить применение CASE средств для проектирования.

Исходные данные для выполнения ДЗ:

• Описание исходных требований к создаваемой СОИУ (выдается преподавателем, соответствует теме для 3-й лабораторной работы) .

• Пример проектирования СОИУ при унифицированном процессе [1].

• Описание унифицированного процесса и его этапов [1].

• Пример использования CASE -средств для проектирования [1, стр. 266-280 ].

Порядок и время проведения работы:

Работа выполняется самостоятельно в часы внеаудиторных занятий. Выполняется группой студентов от 1 до 3 человек. Состав группы и тема ДЗ совпадают с ими же при выполнении 3-й лабораторной работы. По итогам выполнения ДЗ составляется и защищается отчет в бумажном виде, а также проводится демонстрация работающей программы.

Задание:

Выполнить проектирование СОИУ в соответствии с описанием ее функциональности (определяется вариантом). Для проектирования использовать этапы и модели унифицированного процесса. По результатам проектирования получить программу, реализующую фрагмент СОИУ. Для построения диаграмм использовать среду STARUml, или Software Ideas Modeller, или их аналог. Ниже перечислены этапы проектирования и их задачи, выполняемые в ДЗ:

1. Этап анализа и планирования требований (Начало):

• Определить область применения СОИУ (предназначение, границы, интерфейсы с внешней средой, критерии сдачи-приемки).

• Определить прецеденты, критические для системы (основные функции и главные решения).

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

• Определить и оценить самые опасные риски (угрожающие успеху разработки).

В отчет:

• Постановка задачи (задание по варианту).

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

• Выявленные актеры.

• Выявленные прецеденты.

• Диаграмма (ы) прецедентов (20%).

• Описание (словесное) прецедентов.

• Перечень критических рисков (и рекомендации по управлению).

• Список приоритетов прецедентов.

• Описание возможной архитектуры (перечень архитектурно-значимых прецедентов, обобщенные механизмы проектирования, системное ПО, используемые компоненты и/или каркасы).

1. Этап проектирования (Развитие):

• Определить и уточнить большинство требований.

• Определить функциональные требования в виде прецедентов (выделить актеров и прецеденты; создать прототип пользовательского интерфейса; определить приоритеты, детализировать и структурировать прецеденты).

• Выполнить анализ (анализ архитектуры - выделить пакеты анализа и сервисные пакеты, определить классы сущностей и общие специальные требования; анализ прецедентов — определить классы анализа и их взаимодействие; анализ классов — определить ответственности, атрибуты и связи; анализ пакетов).

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

• Выбрать и обосновать используемые шаблоны проектирования, в том числе:

• структурный шаблон (MVC, PCMEF и т.д.),

• шаблон(ы) организации бизнес-логики (сценарий транзакций, модуль таблицы и т.д.),

• шаблон(ы) работы с БД (шлюз записи данных, активная запись и т.д.),

• шаблон(ы) организации пользовательского интерфейса (Gof и др.),

• дополнительные шаблон(ы) поведения и структур данных.

• Реализовать базовый уровень архитектуры.

• Оценить качество проекта.

• Отслеживать риски, устранить наиболее серьезные.

• Составить план итераций следующего этапа.

Программная реализация:

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

• Программа должна содержать реализацию выбранных ранее паттернов проектирования.

В отчет:

• Описание контекста системы (глоссарий понятий, диаграмма классов предметной области и/или бизнес-модель).

• Диаграмма (ы) прецедентов — 80%.

• Расширенные описания прецедентов (предусловие, запуск и инициатор, порядок выполнения и поток событий, постусловия, запрещенные и альтернативные пути, атрибуты и ресурсы).

• Прототип пользовательского интерфейса.

• Классы анализа (ответственности, атрибуты, специальные требования).

• Диаграмма(ы) классов анализа.

• Диаграмма(ы) взаимодействия для прецедентов.

• Пакеты анализа и сервисные пакеты (и их зависимости).

• Архитектура: Диаграмма развертывания (узлы и линии связи, подсистемы и интерфейсы, активные классы).

• Архитектура: Подсистемы, их уровни и интерфейсы.

• Архитектура: Архитектурно-значимые и активные классы.

• Архитектура: Обобщенные механизмы проектирования.

• Архитектура: Диаграмма(ы) взаимодействия для архитектурно-значимых прецедентов (их фрагменты) — 10%.

• Начальная оценка качества проекта (WMC, NOC — для каждого класса и по всей системе, DIT, NOM, NC (количество классов) — по всей системе).

• Архитектурно-значимые компоненты.

• Диаграммы компонентов и развертывания для реализации архитектуры.

• Исходный код и исполняемая программа, реализующая фрагмент архитектурно-значимых прецедентов.

• Переработанный список рисков.

• Перечень и состав итераций следующего этапа.

1. Этап построения (Конструирование):

• Полностью определить и реализовать прецеденты.

• Завершить анализ, проектирование, реализацию и тестирование.

• Полностью разработать компоненты.

• Оценить качество проекта.

Этап построения содержит несколько итераций. В ДЗ достаточно выполнить 2 итерации. Каждая итерация реализует определенный ранее набор прецедентов (сценариев):

• Определить классы и отношения между ними (для сценариев, реализуемых в итерации).

• Определить типы атрибутов и сигнатуры операций для классов.

• Добавить сервисные операции и сервисные классы. Реализовать отношения между классами.

• Оценить качество проекта.

В отчет по каждой итерации:

• Сценарии/прецеденты итерации (краткое описание для существующих или полное для новых/ уточненных).

• Диаграммы взаимодействия.

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

• Оценка качества проекта (метрики WMC, NOC, CBO, RFC, LCOM, CS, NOO, NOA, SI, OSavg, Npavg - для каждого класса и средние по системе, DIT, NOM, NC, LOCsum — по всей системе)

В отчет по этапу:

• Уточненные подсистемы, их интерфейсы, содержимое и зависимости.

• Уточненная диаграмма компонентов.

• Уточненная диаграмма развертывания.

• Оценка качества проекта (метрики Абреу).

1. Этап внедрения (Переход):

• Применить ПО в среде заказчика.

• Завершить реализацию продукта.

В отчет:

• Перечень программ и рекомендации по установке.

• Перечень документации для пользователей и заказчиков.

• Рекомендации по внедрению (консультации, обучение и т.д.).

Литература:

1. Конспект лекций.

2. Орлов С.А. Технологии разработки программного обеспечения. - СПб: Питер, - 2002 г.

3. Материалы сервера http://wmate.ru

Дополнительная:

1. Якобсон А, Дуч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. - Спб.: Питер. - 2002 г.

2. Материалы сервера http://staruml.sourceforge.net

3. Материалы сервера http://www.softwareideas.net/

4. Гамма Э. и др. Приемы объектно-ориентированного проектирования. Паттерны проектирования. - Спб.:Питер. - 2009 г.

5. Фаулер М. Архитектура корпоративных приложений. - М.:Изд.дом Вильямс. - 2008 г.