method_gener_lab4-1 (1035361), страница 2

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

Текст из файла (страница 2)

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

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

• не менее одного на каждый узел;

• один на обмен между узлами;

• не менее одного для запуска, остановки, конфигурирования, снятия блокировки, восстановление и т.д.

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

4.1.8 Определение обобщенных механизмов проектирования

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

• длительное хранение данных;

• распределенная обработка;

• средства безопасности;

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

• управление транзакциями.

При проектировании архитектуры необходимо сформулировать конкретные требования к системе, а также выбрать используемые технологии и средства для их обеспечения. Например, для длительного хранения можно использовать реляционные или объектные БД или файлы; для распределенной обработки - технологии java.rmi, corba или com.

4.2 Проектирование прецедентов

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

4.2.1 Определение участвующих классов

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

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

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

Рис. 3. Диаграмма классов участников для кооперации «Отслеживание статуса заказа».

4.2.2 Описание взаимодействия объектов проектирования

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

Рис.4. Диаграмма последовательностей кооперации «Отслеживание статуса заказа»

4.2.3 Определение участвующих подсистем и интерфейсов

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

4.2.4 Описание взаимодействия подсистем

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

4.2.5 Определение требований к кооперации

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

4.3 Проектирование класса

Следующим шагом, выполняемым при проектировании, является проектирование класса. Составляется подробное описание класса в терминах выбранного языка программирования.

В результате проектирования класса будут определены следующие его параметры:

• операции (внешний интерфейс);

• атрибуты;

• отношения;

• методы (внутренняя реализация);

• состояния;

• зависимость от обобщенных механизмов проектирования;

• требования к реализации;

• правила реализации всех его интерфейсов.

4.3.1 Описание класса проектирования

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

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

• классы для создания интерфейса взаимодействия с внешним устройством или системой;

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

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

Классы сущности в зависимости от выбранной СУБД и технологии работы с БД транслируются в реляционные таблицы или объектные и объектно-реляционные сущности. Возможно применение объектно-реляционного отображения. Часто такая трансляция выполняется автоматически.

Рис. 5. Схема БД для АСУ Таксопарка.

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

После проектирования отдельных классов выполняют итоговое (уточняющее) проектирование подсистем. Классы распределяют или перераспределяют по подсистемам.

Рабочий процесс «Реализация»

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

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

• сервисная подсистема - в сервисную подсистему;

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

• активный класс - в исполняемый компонент;

• один или более проектов кооперации - в билд (сборку);

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

Процесс реализации достаточно тривиален и существенная его часть успешно автоматизирована.

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

• реализация архитектуры;

• сборка системы;

• реализация подсистем;

• реализация классов;

• тестирование модулей.

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

5.1 Реализация архитектуры

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

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

<<process>> - исполняемый файл;

<<message>> - исходные или выходные данные;

<<service>> - сервис;

<<entity>> - таблица БД;

<<specification>> - данные для обработки в определенном формате.

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

Исполняемые компоненты выявляют на основе моделей проектирования, прежде всего активных классов. Каждый активный класс транслируется в исполняемый компонент (утилиту, приложение или сервис) и располагается в соответствующем узле.

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

5.2 Сборка системы

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

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

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

5.3 Реализация подсистемы

Подсистема реализации - это контейнер физических компонентов ПО, конкретная структура которого зависит от языка и технологии разработки. Например, подсистема – это проект при разработке на Visual C++ или пакет при разработке на Java.

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

5.4 Реализация класса

Реализация класса – это перевод проекта класса в исходный код программы. Реализация класса состоит из выполнения следующих действий:

• описание файловых компонентов;

• генерация кода;

• реализация операций;

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

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

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

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

5.5 Тестирование модулей

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

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

(По материалам Сандип Кохли, Шрирупа Сен - IBM)

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

1. Начинаем с создания UML-модели в IBM Rational Systems Developer;

2. Применяем к этой модели профиль C++(или Java), чтобы можно было использовать при моделировании структуры данных, специфичные для C++ (или Java);

3. Импортируем в модель библиотеку типов C++(или Java), чтобы можно было использовать примитивные типы C++(или Java);

4. Генерируем код и бегло просматриваем его;

5. Затем добавляем тело в метод в каком-нибудь классе;

6. Добавляем в модель несколько незначительных деталей, чтобы понаблюдать за тем, как при повторном применении преобразования UML - C++(или Java) сохраняются сделанные вами изменения в коде и модели.

Создание простой UML-модели

Добавить в проект простую UML-модель типа Desing -Design. Для этого в окне проводника проекта выбрать Model, в контекстном меню выбрать Create Model,

далее нажать Next, выбрать тип, указать имя модели и нажать Finish.

Будет создана новая модель и добавлена в окно проводника.

Скопировать в новую модель пакеты с классами из модели анализа.

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

Характеристики

Список файлов лабораторной работы