ЛР №6 - Построение моделей проектирования и реализации в инструментальной среде и автоматическая генерация кода

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

в инструментальной среде и автоматическая генерация кода

Учебно-методические материалы «Построение моделей проектирования и реализации в инструментальной среде и автоматическая генерация кода» представляют собой методические указания к лабораторной работе по дисциплинам «Технологии разработки программного обеспечения» (по направлению магистерской подготовки) и «Технологии проектирования» (по направлению инженерной подготовки).

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

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

Оглавление

Теоретическая часть 2

Преобразования UML- C++ (или Java) в IBM Rational Systems Developer и Rational Software Architect 2

Тэг @generated 17

Построение схемы базы данных в IBM Rational Systems Developer и Rational Software Architect 19

Документирование UML-моделей в IBM Rational Systems Developer и Rational Software Architect 21

Задание 23

Контрольные вопросы 23

Литература 23

Теоретическая часть

Этапы и итерации разработки в Унифицированном процессе

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

2. Итерация состоит из пяти рабочих процессов: определение требований, анализ, проектирование, реализация и тестирование.

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

• область применения будущей системы;

• основные требования к архитектуре системы (на основе главных функций программы);

• основные (критические) риски;

• примерную стоимость и план проекта.

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

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

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

Архитектура системы – это описание основных проектных решений, в том числе компонентов и связей между ними, используемых технологий и аппаратно-программных средств. Архитектура составляется на основе наиболее важных для заказчика функций системы, а также базового функционала, необходимого для работы всей системы. При разработке архитектуры строятся модели для анализа, проектирования и реализации архитектурно-значимых компонентов системы, составляющих ее «скелет». Также реализуются прецеденты (прикладные функции системы), обеспечивающие и демонстрирующие работу архитектурно-значимых компонентов системы.

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

В общем, на данном этапе выполняют следующие задачи:

• создают базовый уровень архитектуры системы;

• определяют существенные риски, методы их отслеживания и устранения или снижения;

• формируют требования к качеству ПО и процесса его разработки, например, используемые стандарты;

• составляют финансовый план проекта;

• проводят анализ большинства прецедентов (до 80%);

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

В результате проектирования будут созданы основные проектные модели, реализован «скелет» проекта, устранены основные риски, подготовлены ресурсы и среда для дальнейшей разработки. Организация разработчика будет готова перейти к следующему этапу и приступить к реализации ПО.

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

В ходе построения выполняют следующие действия:

• управление ресурсами;

• оптимизация процессов разработки;

• отслеживание существенных и критических рисков;

• оценка качества создаваемого ПО.

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

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

На данном этапе выполняют следующие задачи:

• завершение реализации ПО;

• формирование рекомендаций по установке и эксплуатации ПО;

• подготовка программно-аппаратного обеспечения для работы с ПО (конечными пользователями);

• применение ПО в среде конечного пользователя;

• составление документации и руководств (в соответствии с требованиями заказчика);

• проведение бета-тестов, выявление и устранение ошибок ПО,

• создание версии ПО для приемно-сдаточных испытаний.

Стоит напомнить, что альфа-тестирование проводится заказчиком в среде разработчика, а бета-тестирование – конечным пользователем в среде заказчика.

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

Каждый этап разработки состоит из нескольких итераций.

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

Выполнение каждой итерации состоит из последовательно выполнения рабочих процессов:

• сбор требований – определение исходных требований к создаваемой системе (или ее фрагментам);

• анализ – преобразование требований в классы и объекты (построение моделей анализа);

• проектирование – создание статического и динамического представлений системы для выполнения исходных требований (построение проектных моделей);

• реализация – процесс генерации программного кода (включая тестирование и отладку модулей);

• тестирование – проверка работоспособности системы в целом.

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

• на начальном этапе основное внимание уделяют сбору требований;

• на этапе проектирования – анализу и проектированию;

• на этапе построения – реализации;

• на этапе тестирования – тестированию.

Рабочий процесс «Проектирование»

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

• модель проектирования - содержит систему проектирования, содержащую множество подсистем проектирования, классов проектирования, проектов коопераций и интерфейсов;

• классы проектирования – описания классов в терминах языка реализации;

• проекты коопераций – описания проектных представлений прецедентов, содержащих диаграммы классов, диаграммы взаимодействия и проекты потоков событий для выполнения прецедента;

• подсистемы проектирования и сервисные подсистемы – описывают проекты будущих компонентов системы;

• интерфейсы – содержат перечень доступных извне функций подсистем;

• описание архитектуры – содержит наиболее важные проектные решения, определяет компоненты и технологии, используемые при разработке и функционировании системы;

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

Процесс проектирования состоит из выполнения следующих действий:

• проектирование архитектуры;

• проектирование прецедентов;

• проектирование классов;

• проектирование подсистем.

Рассмотрим эти действия более подробно.

Проектирование Архитектуры

4.1.1 Определение узлов и сетевых конфигураций

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

Рис. 1 Диаграмма развертывания для АСУ Таксопарк.

4.1.2 Определение подсистем и их интерфейсов

Следующим шагом проектирования архитектуры является определение подсистем и их интерфейсов. Подсистема проектирования – это прообраз будущего программного компонента системы. Она предоставляет способ группировки элементов системы на этапе проектирования в более крупные блоки.

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

Подсистемы прикладного уровня определяются на основе пакетов анализа. Далее проводят уточнение и декомпозицию полученных подсистем по следующим правилам:

• часть пакета анализа, совместно используемую несколькими подсистемами, выделяют в отдельную подсистему;

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

4.1.4 Определение подсистем среднего уровня и системного ПО

К подсистемам среднего уровня и уровня системного ПО относят следующие компоненты:

• ОС;

• СУБД;

• средства коммуникации;

• средства распределенной обработки;

• средства выполнения транзакций;

• средства разработки интерфейсов.

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

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

Зависимости подсистем соответствуют зависимостям классов подсистемы или пакетами анализа. Зависимости между подсистемами проектирования, как и зависимости между пакетами анализа соответствуют вызовам при работе системы. Подсистемы верхних уровней зависят от подсистем нижних уровней, но не наоборот.

Рис.2. Уровни подсистем проектирования для АСУ Таксопарк.

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

4.1.6 Определение интерфейсов подсистем

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

4.1.7 Определение архитектурно-значимых классов проектирования

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

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