Файл: ТРПО-лекции.pdf

Скачано с сайта http://ivc.clan.su

Рис. 7-1.

Связь базовых понятий унифицированного процесса

7.2. Модели унифицированного процесса

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

Модели отображают работу проектируемой системы на различных уровнях:

−На уровне взаимодействия между пользователями и системой.

−На уровне взаимодействия объектов внутри системы.

−На уровне взаимодействия между различными системами.

Основной набор моделей RUP включает следующие модели:

−Бизнес-модель. Описывает предметную область и контекст системы.

−Модель прецедентов. Показывает связи между пользователями и вариантами использования.

−Модель анализа. Уточняет детали прецедентов и создаѐт первичное распределение поведения системы по набору объектов.

−Модель проектирования. Определяет статическую структуру системы и кооперации классов для реализации прецедентов.

−Модель реализации. Показывает представленные исходным кодом компоненты и распределение классов по компонентам.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

−Модель развѐртывания. Определяет расположение оборудования и связи107 между отдельными устройствами, а также местонахождение хранилищ данных и компонентов в соответствии с топологией сети.

−Модель тестирования. Описывает варианты тестов для проверки прецедентов.

7.3.Принципы методологии RUP

Основными положениями методологии являются:

1.Планирование и управление проектом на основе функциональных требований к системе (use case driven).

2.Построение системы на базе архитектуры (architecture centric).

3.Итеративный и инкрементный подход к разработке системы (controlled iterative development).

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

7.3.1. Управляемая прецедентами разработка

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

Концепция прецедентов применяется в RUP на всех стадиях разработки – от формулировки требований до поставки готовой системы. Варианты использования, определѐнные для системы, составляют основу всего процесса. Производство программного продукта является управляемым функциями предметной области, что обеспечивает согласованность стадий разработки.

Прецеденты связывают воедино все входящие в разработку виды деятельности, позволяют оценить объѐм и сложность предстоящей работы, а также определить содержание итераций. Наиболее важное преимущество использования прецедентов заключается в том, что они управляют проектом.

На рис. 7-2 показано использование прецедентов в разных системных моделях.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Рис. 7-2. Пре-

цеденты и системные модели

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

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

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

В реализации согласно модели проектирования создаѐтся исполняемое приложение, в котором прецеденты реализуются через классы среды программирования.

Для тестирования прецеденты являются источником при составлении контрольных задач и методик испытаний. Каждый прецедент тестируется для проверки системы.

7.3.2. Ориентированная на архитектуру разработка

Унифицированный процесс предлагает системный подход к созданию архитектуры. Он предусматривает установление архитектурного стиля, правил проектирования и ограничений. Архитектура системы используется в качестве базы для построения концепции, создания, управления и развития системы в ходе еѐ разработки. Важное внимание уделяется раннему определению архитектуры и формулированию основных еѐ особенностей. Архитектура складывается из подсистем, классов, компонентов и узлов, а также из их кооперации посредством интерфейсов. Распределение обязанностей и организация взаимодействия этих элементов должны обеспечить выполнение функциональных требований.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 109

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

Описание архитектуры заключается в представлении моделей системы и разбито на следующие части:

1.Архитектурное представление модели прецедентов включает полное описание самых существенных вариантов использования без учѐта остальных. Представление обеспечивает базу для создания остальных архитектурных представлений.

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

3.Архитектурное представление модели проектирования содержит большинство значимых подсистем, классов, интерфейсов и реализованных прецедентов проектирования, которые формируют словарь системных решений. С точки зрения проектирования рассматриваются механизмы параллелизма и синхронизации. Это представление ориентировано на принятие решений относительно нефункциональных требований к системе, включая требования к производительности, масштабируемости и пропускной способности.

4.Архитектурное представление модели реализации описывает компоненты, ис-

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

5.Архитектурное представление модели развѐртывания определяет физическую архитектуру системы в понятиях связанных аппаратных устройств, на которых выполняются компоненты приложения. Часто сетевая топология известна ещѐ во время определения требований, поэтому физическая архитектура процессоров и устройств может быть сформирована до начала проектирования. Это представление предназначено для распространения, поставки и установки системы.

7.3.3. Итеративная и инкрементная разработка

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

Каждая итерация выполняется согласно обычным этапам водопадной модели жизненного цикла и создаѐт версию, включающую в себя частично завершѐнную версию целевой системы и документацию. В ходе последовательных итераций версии развиваются до тех пор, пока не будет получен окончательный вариант системы.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 110

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

7.3.3.1. Цели итеративной и инкрементной разработки

RUP использует такую разработку для достижения следующих целей:

−Получить на ранних итерациях описание критических и опасных рисков.

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

−Вносить и контролировать неизбежно появляющиеся в ходе разработки дополнительные требования и изменения в уже имеющиеся требования.

−Улучшить систему и снизить риски в ходе последующих итераций.

−Снизить организационные риски и повысить эффективность работы участников проектной группы.

7.3.3.2. Преимущества итеративной и инкрементной разработки

Преимущества, которые обуславливают эффективность управления:

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

−Регулярная поставка работающего приложения улучшает возможность получения обратной связи в процессе компиляции, интеграции, использования различных инструментов тестирования, а также от основных заинтересованных лиц, что помогает выявить проблемы тогда, когда их можно исправить с наименьшими затратами. Исправление ошибок на ранних этапах разработки повышает экономическую эффективность проекта.

−Автоматизированный сбор показателей от инструментов разработки и управления предоставляет в распоряжение точную информацию о состоянии итерации, что способствует объективной оценке хода процесса разработки и положительно сказывается на качестве.

−Итерации повышают шанс создать систему, которая удовлетворяет реальным потребностям заказчиков, потому что на протяжении всей разработки вносятся небольшие корректировки и тестирование проходит быстрее.

7.3.4. Другие важные принципы разработки

Постоянный контроль качества, раннее и частое тестирование в реальных условиях эксплуатации.

Оценка рисков на ранних стадиях проекта. Визуальное моделирование с помощью языка UML.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

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

7.4.1. Итерация

Итерация (iteration) представляет собой определѐнный набор деятельностей, производимый в соответствии с планом и оценочными критериями, и приводящий к выпуску или версии программного обеспечения, или целевой системы.

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

Каждая успешная итерация строится с учѐтом результатов предшествующих итераций, что способствует развитию и уточнению кода вплоть до завершения работы.

Количество итераций и их длительность зависят от масштабов проекта. В рамках каждой итерации проводится свои собственные анализ требований, проектирование, реализация, тестирование, интеграция, которые завершаются созданием ПС.

Каждая итерация имеет ясно очерченный набор задач и формирует частично рабочую реализацию ПС. Любая итерация должна обеспечивать что-то одно: повышение потребительской ценности, улучшение взаимодействия с пользователем, расширение функциональности, повышение эффективности, повышение надѐжности.

Отдельные версии системы демонстрируются заказчику, вследствие чего становится возможным регулярно контролировать успешность выполнения проекта.

7.4.2. Фазы итерации RUP

Каждая итерация делится на четыре фазы, показанные на рис. 7-3.

Рис. 7-3. Фазы

итерации RUP

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011