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

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

1. Дважды щёлкнуть на значке представления развертывания в браузере.

2. Выполнить операцию меню Browse > Deployment Diagram (Обзор > Диаграмма развёртывания).

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

Таблица 7.1

Значок	Подсказка	Назначение кнопки
	Selection Tool	Переключает в режим выделения элементов на диаграмме
	Text Box	Добавляет на диаграмму текстовую область
	Note	Добавляет на диаграмму примечание
	Anchor Note to Item	Добавляет связь примечания с элементом диаграммы
	Processor	Добавляет на диаграмму процессор
	Connection	Добавляет на диаграмму отношение соединения
	Device	Добавляет на диаграмму устройство

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

Добавить процессор можно также с помощью операции меню Tools > Create > Processor или с помощью операции контекстного меню New > Processor для представления развёртывания браузера. Аналогично добавить устройство можно также с помощью операции меню Tools > Create > Device или с помощью операции контекстного меню New > Device. В среде RR под процессором понимается ресурсоёмкий узел, а под устройством - нересурсоёмкий узел.

Для каждого процессора можно специфицировать свойства с помощью окна спецификации свойств процессора. На вкладке General можно изменить имя процессора, ввести текст стереотипа и текст документации с особенностями физического размещения компонента. На вкладке Detail окна спецификации свойств процессора можно определить его характеристики, выбрать процессы и вариант планирования его работы. Характеристики процессора (быстродействие и объем оперативной памяти) могут быть записаны в форме текста в многостраничное поле Characteristics. В поле Processes (Процессы) можно задать некоторый процесс, который предполагается реализовать на этом процессоре. С этой целью необходимо выполнить операцию контекстного меню Insert и ввести текст имени процесса. Далее можно задать приоритет процесса в соответствующем поле ввода.

При наличии у процессора нескольких процессов может быть определена процедура планирования их выполнения в группе Scheduling:

- Preemptive (вытесняющий) - процесс с большим приоритетом будет иметь преимущество при использовании ресурсов процессора по сравнению с менее приоритетными процессами;

- Non preemptive (не вытесняющий) - все приоритеты процессов игнорируются; текущий процесс выполняется до своего завершения, после чего может быть начато выполнение следующего процесса;

- Cyclic (Циклический) - приоритеты процессов также игнорируются; все процессы выполняются циклически по кругу, каждому из них выделяется фиксированное время на выполнение, по прошествии которого управление передаётся следующему процессу;

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

- Manual (Вручную) - планирование осуществляется пользователем.

Показать планирование на диаграмме можно так: щёлкнуть правой кнопкой мыши на процессоре и в меню выбрать Show Scheduling (Показать планирование).

Для устройства набор редактируемых свойств меньше: имя, стереотип, документация и характеристика.

Процессом называется поток обработки информации (execution), выполняющийся на процессоре, например, исполняемый файл. Для добавления процесса щелкните правой кнопкой мыши на процессоре в браузере, в меню выберите New > Process (Создать > Процесс) и введите имя нового процесса. Процессы можно показать на диаграмме: щёлкните правой кнопкой мыши на процессоре и в меню выберите Show Processes (Показать процессы). Процессам можно присваивать приоритеты в окне спецификации процесса на вкладке General в поле Priority (Приоритет). Если тип планирования процессора позволяет это, то приоритет процесса определяет, когда он может выполняться.

Соединением (connection) называется физическая связь между двумя узлами. Для добавления соединения между двумя узлами нужно с помощью левой кнопки мыши нажать кнопку с изображением соединения на специальной панели инструментов, отпустить левую кнопку мыши, щелкнуть левой кнопкой мыши на изображении одного из узлов на диаграмме и отпустить её на изображении другого узла либо с помощью операции меню Tools > Create > Connection. Для соединения набор редактируемых свойств аналогичен набору свойств устройства: имя, стереотип, документация и характеристика.

Типовой пример

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

1) процессор 'Банкомат №1': в форме примечания помеченное значение - {адрес=ул. Садовая, д.5}; на вкладке Detail процесс - MainATM;

2) процессор 'Банкомат №2': значение - {адрес=ул. Парковая, д.7}, процесс - MainATM;

3) процессор 'Банкомат №3': значение - {адрес=ул. Лесная, д.9}, процесс - MainATM;

4) процессор 'Сервер банка': процесс - 'MainBank';

5) устройство 'Сеть': стереотип - <<закрытая сеть>>;

6) соединения для узлов 'Банкомат №1' и 'Сеть', 'Банкомат №2' и 'Сеть', 'Банкомат №3' и 'Сеть', 'Сервер банка и 'Сеть'.

После построения диаграммы развёртывания разработка визуальной модели системы управления банкоматом в нотации UML может считаться завершённой.

Рис.7.1. Диаграмма развёртывания модели управления банкоматом

RR не поддерживает возможности графического размещения внутри узлов развёртываемых на них компонентов. Указать размещение компонентов модели в узлах диаграммы развёртывания можно с помощью документации этих узлов.

7.3. Порядок выполнения

1. Изучить назначение элементов интерфейса RR для построения диаграммы развёртывания. Рассмотреть типовой пример построения диаграммы.

2. Продолжить моделирование системы в соответствии с индивидуальным заданием в виде построения диаграммы развёртывания:

2.1. Активизировать окно диаграммы развёртывания.

2.2. Определить состав и добавить на диаграмму развёртывания необходимые узлы (процессоры и устройства) и соединения.

2.3. Добавить процессы и показать их на диаграмме развёртывания. Показать процедуры планирования процессов.

3. Сгенерировать с помощью RR отчёт о разрабатываемой модели.

4. Оформить отчёт по результатам выполнения лабораторной работы.

7.4. Содержание отчёта

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

1. Постановка задачи.

2. Краткое описание составляющих диаграммы развёртывания.

3. Окончательный вид диаграммы развёртывания проектируемой системы.

Дополнить отчёт результатами генерации отчёта о модели с помощью RR.

7.5. Варианты заданий

Вариант индивидуального задания соответствует варианту, полученному при выполнении лабораторной работы №2.

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

1. Для чего предназначена диаграмма развертывания?

2. Что отображает диаграмма развертывания модели?

3. Сколько диаграмм развертывания может быть построено для разрабатываемой модели в RR?

4. Какое представление используется в браузере проекта для разработки и размещения диаграммы развертывания?

5. Каким образом на диаграмму развертывания добавляется узел?

6. Какие свойства можно специфицировать для процессора?

7. В чем спецификация процедуры планирования процессов процессора в RR?

8. Как отобразить планирование процессов на диаграмме развертывания в RR?

9. Как добавляется процесс для процессора в диаграмме развёртывания?

8. Дальнейшая работа с моделью

8.1. Цель работы

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

8.2. Общие сведения

Дальнейшая работа с моделью зависит от целей выполнения проекта.

Отчёт о модели

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

С этой целью следует выполнить операцию меню Report > SoDA Report (Отчёт > Отчет с помощью SoDA), в результате чего будет открыто окно свойств для выбора шаблонов генерации отчёта. После выбора шаблонов будет автоматически сгенерирован отчёт о модели в формате MS Word с использованием специального средства IBM Rational SoDA, если оно доступно в системе после инсталляции RR.

Генерация кода

Если проект предполагает программную реализацию, то целесообразно воспользоваться возможностями генерации кода в среде RR.

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

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

1. Проверка модели на отсутствие ошибок.

2. Создание компонентов для реализации классов и отображение классов на компоненты (может выполняться при создании диаграммы компонентов).

3. Выбор ЯП для генерации программного кода.

4. Установка свойств генерации программного кода.

5. Выбор класса, компонента или пакета.

6. Собственно генерация программного кода.

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

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

Проверка модели независимо от выбора языка генерации кода

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

Для проверки модели следует выполнить операцию меню Tools > Check Model (Инструменты > Проверить модель). Результаты проверки модели на наличие ошибок отображаются в окне журнала.

Для обнаружения нарушений правил доступа, возникающих когда существует связь между двумя классами разных пакетов, но связи между самими пакетами отсутствуют, необходимо выбрать в меню Report > Show Access Violations.

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

Создание компонентов для реализации классов и отображение классов на компоненты

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

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

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

Выбор языка программирования

и редактирование свойств генерации кода

Для выбора ЯП в качестве языка реализации модели следует выполнить операцию меню Tools > Options (Инструменты > Параметры), в результате чего будет вызвано окно настройки параметров модели. На вкладке Notation (Нотация) в строке Default Language (Язык по умолчанию) из вложенного списка следует выбрать требуемый язык.

Если по какой-то причине необходимого языка не оказалось во вложенном списке, то следует убедиться в том, что этот ЯП установлен в качестве расширения RR. Для этого следует открыть окно установленных расширений, выполнив операцию меню Add-Ins > Add-In Manager (Расширения > Менеджер расширений), и убедиться в том, что выставлена отметка в строке с именем необходимого языка. Если языка нет, то следует её добавить, после чего появится группа доступных операций этого языка в меню Tools.

После выбора ЯП по умолчанию следует изменить язык реализации каждого из компонентов модели. С этой целью следует изменить язык в строке Language (Язык) на вкладке General (Общие) окна спецификации свойств компонента, для чего из вложенного списка следует выбрать необходимый язык. После выбора ЯП нужно привести в соответствие типы атрибутов, типы аргументов и результатов операций. С этой целью нужно просмотреть все классы диаграммы классов и изменить те типы данных, которые не являются синтаксически допустимыми в выбранном ЯП. Иначе соответствующие исправления придётся выполнять вручную после генерации программного кода.

Для каждого языка в RR предусмотрен ряд свойств генерации кода. Перед генерацией рекомендуется их анализировать и вносить необходимые изменения. Для анализа свойств генерации кода выберите Tools > Options, а затем вкладку соответствующего языка. В окне списка можно выбрать класс, атрибут, операцию и другие элементы модели. Для каждого языка в этом списке указаны свои собственные элементы модели. При выборе разных значений на экране появляются разные наборы свойств. Любые изменения, вносимые в набор свойств в этом окне, воздействуют на все элементы модели, для которых используется данный набор.

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

Выбор класса или компонента

и генерация для него программного кода

Генерация кода возможна для отдельного класса / компонента: необходимо выделить нужный элемент модели в браузере и выполнить операцию контекстного меню <Требуемый ЯП> > Generate Code (<Требуемый ЯП> > Генерировать код).

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

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

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

Краткое описание кодогенератора Rose Delphi Link

Для совместного использования Delphi и RR необходимо использовать кодогенератор Rose Delphi Link (RDL). После установки RDL в среде RR появляется новый пункт меню в разделе Tools (рис.8.1).

Интерфейс основного окна RDL включает в себя (рис.8.2): меню с командами для работы с проектом, настройки опций и вызова помощи; панели, на которых в виде деревьев отображаются иерархические структуры моделей RR и Delphi; кнопки обновления объектных деревьев, прямого и обратного проектирования.

Рис.8.1. Пункты меню кодогенератора Delphi

Рис.8.2. Основное окно Rose Delphi Link

Пункт меню File > Open Project - служит для открытия в RDL созданного проекта Delphi. При открытии проекта в окне RDL отображаются объектные деревья открываемого проекта. При выборе пункта меню File > New Project RDL предлагает создать пустой Delphi-проект. Новый проект стоит создавать в случае, если программа не содержит графического пользовательского интерфейса (например, динамическая библиотека). Пункты меню View и Help стандартны.

Для отображения элементов модели в код RDL использует Code Generation Properties (CGP) - набор специальных таблиц, которые связываются с каждым элементом модели RR и содержат специфическую для Delphi информацию, используемую для кодогенерации. Набор этих таблиц (рис.8.3) доступен из главного меню (пункт Tools > Options, вкладка Delphi).

Рис.8.3. Таблица свойств CGP для операций в кодогенераторе Delphi

Чтобы CGP для Delphi были доступны из спецификации, необходимо установить значение поля Default Language = Delphi во вкладке Notation меню Tools > Options. Для упрощения работы в меню Tools > Ensemble Tools есть вкладка Delphi Property Editor, где можно настроить свойства элемента модели. При его использовании можно без кодогенерации просмотреть код элемента модели.

В целом RDL охватывает все перечисленные возможности кодогенератора:

- возможность преобразовывать классы RR в код определения классов на целевом языке (в данном случае Delphi). При этом описание, связанное с конкретным классом, должно помещаться в соответствующее место кода;

- поддерживать для диаграммы классов стереотипы, связанные со специфическими особенностями языка (например, стереотип unit, interface или property с соответствующими определениями: модуль Delphi, интерфейс Delphi, свойство компонента Delphi);

- иметь описанный, очевидный и однозначный способ отображения диаграммы классов в код Delphi. При этом отображение должно быть настраиваемым;

- иметь возможность импорта актуальной объектной модели Delphi (желательно для различных версий библиотеки VCL);

- поддерживать генерацию кода для создания классов Delphi;

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

- уметь отображать в программный код кардинальность связи;

- исходя из диаграммы компонентов RR, создавать проект Delphi, содержащий требуемые программные модули (forward engineering);

- на основе готового проекта Delphi строить диаграмму компонентов RR, содержащую в виде компонентов все модули проекта Delphi и связанные с ними классы, полученные из Delphi в результате обратного проектирования (reverse engineering), диаграммы должны быть компактными и очевидными;

- обеспечивать автоматическое согласование модели RR и Delphi после внесения изменений в код модулей Delphi (round trip engineering);

- после внесения изменений в модель RR и повторной генерации кода не уничтожать фрагменты, написанные в среде Delphi;

- работать на реальных проектах (сотни классов и модулей) с приемлемой производительностью.

Основным недостатком RDL является то, что он не позволяет создавать формы. Для решения этой проблемы компания Ensemble Systems предлагает следующую методологию проектирования, представленную на рис.8.4.



Рис.8.4. Методология проектирования с использованием RDL

Основная идея такого подхода состоит в использовании обратного проектирования: все изменения, сделанные на уровне кода в Delphi, отображаются в объектной модели RR, и, наоборот, при изменении классов, методов и т.п. в объектной модели RR, соответственно, корректируется программный код.

Код, создаваемый RDL, не содержит реализации (для объектной модели обычно это тело метода). Когда модель обновляется из кода, модель не подгружает код, написанный в среде Delphi, для тел методов. Изменения в модели касаются только декларативных элементов: определений классов, интерфейсов, типов, записей и т.п. Но при повторной генерации кода из RR тела методов в Delphi также остаются неизменными, а меняются лишь декларативные элементы.

Дистрибутив Rose Delphi Link можно скачать с сайта Ensemble Systems (URL: http://www.ensemblesystems.com/downloads.html).

8.3. Порядок выполнения

1. Изучить особенности генерации программного кода с помощью RR.

2. Сгенерировать программный код на основе построенной модели системы.

3. Оформить отчёт по результатам выполнения лабораторной работы.

8.4. Содержание отчёта

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

1. Постановка задачи.

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

8.5. Варианты заданий

Вариант индивидуального задания соответствует варианту, полученному при выполнении лабораторной работы №2.

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

1. Что необходимо выполнить для генерации отчёта о модели в RR?

2. Какое ПО необходимо для осуществления генерации отчёта о модели в RR?

3. Почему нужно строить разные диаграммы при моделировании системы?

4. Какие диаграммы модели необходимы для генерации программного кода?

5. На каких ЯП могут быть сгенерированы коды программ в RR?

6. Какие основные действия необходимо выполнить для генерации кода в RR?

7. Каким образом осуществляется проверка модели на отсутствие ошибок?

8. Что должно выполняться для классов и компонентов для генерации кода?

9. Как выбирается в RR ЯП? Что нужно проверить с точки зрения синтаксиса выбранного ЯП?

10. Как осуществляется редактирование свойств генерации кода?

11. В чём состоят особенности генерации кода модели в среде RR?

12. Для чего предназначена программа Rose Delphi Link?

13. Какие особенности имеет программа Rose Delphi Link?

6.2 Курсовая работа

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

Задача курсовой работы состоит в анализе и проектировании предметной области (ПрО) реальной организационно-технической системы с использованием объектно-ориентированного анализа и проектирования на основе языка UML в CASE-системе Rational Rose.

Задание по курсовой работе заключается в анализе выбранной (или заданной руководителем) ПрО и построении моделей UML (в том числе диаграмм). Эти модели должны в полной мере раскрывать этап формализации выбранных объектов и процессов для дальнейшей реализации программной системы.

Для построения моделей UML необходимо использовать CASE-систему Rational Rose от IBM Rational. Для генерации кода на Delphi Pascal необходимо использовать средство Rose Delphi Link от фирмы Ensemble Systems, представляющее плагин к системе Rational Rose. Основы работы с системой и плагином рассматриваются в методических указаниях к лабораторным работам.

Содержание курсовой работы ориентировано на проработку студентами умений, полученных во время лабораторных работ, и знаний, приобретённых в течение курса лекций по дисциплине «Технологии разработки программных систем».

Так как RUP является слишком сложным подходом для разработки системы в рамках курсовой работы, в качестве основы выбран подход ICONIX Process.

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

7. Общие сведения

Для выполнения курсовой работы необходимо знать некоторые аспекты языка UML и Процесса ICONIX.

Обзор языка UML

UML - это общецелевой объектно-ориентированный язык для визуализации, специфицирования, анализа, проектирования, конструирования и документирования артефактов программной системы. Использование UML основано на понимании общих принципов моделирования сложных систем, в частности особенностей процесса объектно-ориентированного анализа и проектирования (ООАП).

Принципы моделирования

Рассмотрим кратко принципы моделирования - принципы построения моделей сложных систем.

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

Рис.5. Модели и представления сложной системы



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

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

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

Формальное описание

UML состоит из хорошо определённых взаимодействующих частей: семантики и синтаксиса. Семантика представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на UML. Синтаксис представляет собой графическую нотацию для визуального представления семантики UML.

Семантика определяется для двух видов моделей: моделей структур и моделей поведения. Модели структуры, или статические модели, описывают структуру сущностей или частей системы. Модели поведения, или динамические модели, описывают поведение сущностей системы.

Формальное описание самого UML основывается на некоторой общей иерархической структуре модельных представлений, состоящей из четырех уровней: мета-метамодель, метамодель, модель и объекты пользователя.

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

Метамодель является экземпляром или конкретизацией мета-метамодели. Главная задача этого уровня - определить язык для спецификации моделей. Данный уровень является более конструктивным, чем предыдущий, поскольку обладает более развитой семантикой базовых понятий. Все основные понятия UML - это понятия уровня метамодели.

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

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

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

Представления модели

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

В UML определены следующие виды диаграмм:

- Диаграммы структуры (Structure diagram):

Диаграмма пакетов (Package diagram).

Диаграмма классов (Class diagram).

Диаграмма композитной структуры (Composite structure diagram):

¦ Диаграмма кооперации (Collaboration diagram, UML 2.0).

Диаграмма объектов (Object diagram).

Диаграмма реализации (Implementation diagram).

¦ Диаграмма компонентов (Component diagram).

¦ Диаграмма развёртывания (Class diagram).

- Диаграммы поведения (Behavior diagram):

Диаграмма прецедентов (Use case diagram).

Диаграмма переходов состояний (State machine diagram):

¦ Диаграмма состояний (Statechart diagram).

¦ Диаграмма деятельности (Activity diagram).

Диаграмма взаимодействия (Interaction diagram).

¦ Диаграмма последовательности (Sequence diagram).

¦ Диаграмма синхронизации (Timing diagram, UML 2.0).

¦ Диаграмма коммуникации (Communication diagram, UML 2.0) / Диаграмма кооперации (Collaboration diagram, UML 1.x).

¦ Диаграмма обзора взаимодействия (Interaction overview diagram, UML 2.0).

В данных указаниях будет использовать UML версии 1.x.

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

Диаграмма робастности

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

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

- Актёр (actor) - внешний (к системе) субъект/объект, участвующий в сценарии; отображает соответствующего актёра из диаграммы прецедентов.

- Граничный объект (boundary object) - объект на границе системы с внешней средой; обычно является объектом, используемым актёром при взаимодействии с системой; часто отображает связь из диаграммы прецедентов.

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

- Объект-управление (control object) - управляющий объект системы; является «соединителем» граничного объекта и объекта-сущности; обычно отображает некоторую функцию, необходимую (только) для выполнения прецедента.

Граничный объект Объект-сущность Объект-управление

Рис.6. Элементы диаграммы робастности

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

Объекты-управления реализуют прикладную логику системы, отделяя её одновременно от граничных объектов и от объектов-сущностей. На практике объекты-управления редко реализуются именно как объекты, они обычно программируются в виде методов классов. Поэтому объект-управление называют также контроллером (controller).

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

Построение выполняется в соответствии с простыми правилами:

1. Актёры связаны только с граничными объектами.

2. Граничные объекты связаны только с актёрами и контроллерами.

3. Объекты-сущности связаны только с контроллерами.

4. Контроллеры (объекты-управления) связаны с граничными объектами, объектами-сущностями и другими контроллерами, но не с актёрами.

Допустимые связи Недопустимые связи

Рис.7. Правила диаграммы робастности



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

Процесс ICONIX

Процесс ICONIX (ICONIX Process) - каркасный подход, предлагаемый фирмой ICONIX Software Engineering, Inc.

Обзор подхода

В 1992 г. Д. Розенберг разработал собственный подход - Процесс ICONIX. В него были включены отобранные автором приемлемые методы из объектно-ориентированных методик Г. Буча, Дж. Рамбо и А. Якобсона. Следует отметить, что эти три методики составили основу языка UML.

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

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

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

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

Особенности подхода

Основными особенностями подхода являются:

1. Упрощённое использование UML (Streamlined usage of the UML).

2. Высокая степень отслеживаемости (High degree of traceability).

3. Итеративность и инкрементность моделей (Iterative and incremental models).

Упрощённое использование UML означает использование минимального подмножества диаграмм UML для объектно-ориентированной разработки. Основные диаграммы позволяют в полной мере охватить анализ и проектирование. Остальные диаграммы могут использоваться по необходимости, что обеспечивает возможность настройки подхода для конкретного проекта.

Высокая степень отслеживаемости позволяет на всём протяжении ЖЦ обеспечить обратную связь с требованиями. Это гарантирует сохранение направления разработки в рамках предъявляемых требований и правильность перехода от анализа к проектированию.

Итеративность и инкрементность моделей связана с итеративностью и инкрементностью построения необходимых моделей во время разработки системы:

1. Итерационное построение моделей ПрО и прецедентов.

2. Итерационное повторение ЖЦ для инкрементной разработки системы.

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

Ключевые принципы

Сутью Процесса ICONIX является понимание того, что построение хороших моделей объектов является простым, если:

- сосредоточиться непосредственно на нахождении ответа на фундаментально важные вопросы о разрабатываемой системе,

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

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

Разработка в рамках подхода выражается в виде трёх ключевых принципов:

1. Снаружи внутрь (outside-in).

2. Изнутри наружу (outside-in).

3. Сверху вниз (outside-in).

Принцип «снаружи внутрь» определяет движение внутрь, исходя из требований пользователя, формализуемых в виде сценариев и прецедентов.

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

Принцип «сверху вниз» обозначает движение вниз - от высокоуровневых моделей к детализированному дизайну.

Модель ЖЦ иллюстрирует эти принципы (рис.10).

Жизненный цикл проекта

Модель ЖЦ для Процесса ICONIX отражает построение моделей во всех этапах ЖЦ, связанных с анализом и проектированием (рис.10).

В подходе выделено 4 этапа:

1. Анализ требований (Requirements Analysis).

2. Предварительное проектирование (Preliminary Design).

3. Детализированное проектирование (Detailed Design).

4. Реализация (Implementation).

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

1. Обзор требований (Requirements Review).

2. Обзор предварительного дизайна (PDR - Preliminary Design Review).

3. Обзор критического дизайна (CDR - Critical Design Review).

4. Поставка (Delivery).

Рис.6.8. Модель ЖЦ для Процесса ICONIX

На этапе 1 «Анализ требований» выполняются следующие действия:

- Определяются объекты ПрО и выясняются связи обобщения и агрегации между ними. На основе этого начинается создание высокоуровневых диаграмм классов - модели (сущностей) ПрО.

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

- Определяются прецеденты в виде диаграмм прецедентов.

- Организуется группировка прецедентов в виде диаграммы пакетов.

- Размещаются функциональные требования к системе - в прецеденты и объекты ПрО.

Веха 1 «Обзор требований» позволяет установить, что:

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

- заказчик понимает идею системы и понятно отражает её в требованиях;

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

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

На этапе 2 «Предварительное проектирование» выполняются следующие действия:

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

- Выполняется анализ робастности. Для каждого прецедента:

определяется набор объектов, которые участвуют в выбранном сценарии,

строится диаграмма робастности с использованием стереотипов из UML Objectory (применяемых в подходе А. Якобсона),

обновляются диаграммы классов (добавляются новые объекты, а также новые атрибуты и ассоциации).

- Завершается обновление диаграмм классов. Это действие свидетельствует о завершении стадии анализа для проекта.

- Выбирается техническая архитектура (technical architecture) - технологические инструментарий и платформа (в частности, язык программирования и средство построения распределённых программных компонентов).

Веха 2 «Обзор предварительного дизайна» позволяет установить, что:

- описание прецедентов и диаграммы робастности соответствуют друг другу и оба представляют правильно и полностью поведение создаваемой системы;

- модель ПрО соответствует диаграммам робастности (в частности, все объекты-сущности, показанные на диаграммах робастности, представлены и в модели ПрО);

- классы-сущности включают в себя необходимые атрибуты;

- можно проследить потоки данных между именованными экранными формами системы через классы-сущности и, возможно, к лежащему в основе системы хранилищу данных.

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

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

На этапе 3 «Детализированное проектирование» выполняются следующие действия:

- «Размещается» поведение системы. Для каждого прецедента:

определяются сообщения, передаваемые объектами, сами объекты и соответствующие вызываемые методы,

строится диаграмма последовательности: слева указывается текст выполняемого сценария, справа - соответствующий дизайн (сама диаграмма),

обновляется диаграмма классов (добавляются новые атрибуты и операции).

- Если необходимо, строятся дополнительные диаграммы:

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

диаграмма состояний для поведения системы реального времени.

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

- Командой осуществляется проверка дизайна на соответствие все предъявляемым к системе требованиям. Это действие свидетельствует о завершении стадии проектирования для проекта.

Веха 3 «Обзор критического дизайна» позволяет установить, что:

- детальный дизайн в виде диаграмм последовательности и связанных с ними диаграмм классов соответствует прецедентам;

- детальный дизайн обладает достаточной глубиной (т.е. достаточно подробен), чтобы облегчить относительно небольшой и плавный переход к коду;

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

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

- стабилизированы и утверждены все требования и техническая архитектура;

- решены все оставшиеся проблемы дизайна.

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

На этапе 4 «Реализация» выполняются следующие действия:

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

- Пишется или генерируется программный код.

- Осуществляется модульное и интеграционное тестирование.

- Совершается системное тестирование и тестирование приемлемости для пользователей. Это действие свидетельствует о завершении стадий реализации и тестирования для проекта.

Веха 4 «Поставка» позволяет установить, что:

- модульные тесты соответствуют описанию прецедентов и диаграммам последовательности;

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

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

Одним из преимуществ Процесса ICONIX является то, что для каждого этапа указано 10 наиболее распространённых ошибок (Top 10 Errors) разработки и их разбор с целью исправления.

8. Порядок выполнения

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

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

Определение задания

Постановка индивидуального задания включает в себя следующие части:

1. Тема задания - описание предметной области (ПрО) системы.

2. Функциональные требования к системе - требования заинтересованных лиц, предъявляемые к разрабатываемой системе.

3. Нефункциональные требования к системе - требования, предъявляемые к возможностям системы и/или задающие для неё ограничения.

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

Этапы выполнения

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

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

Этап 1 «Анализ требований» включает шаги:

- Специфицирование требований. Представление функциональных требований в виде прецедентов. Построение общих диаграмм прецедентов.

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

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

Этап 2 «Начальное проектирование» включает шаги:

- Детализация прецедентов. Формирование текстовых описаний прецедентов в виде основного и альтернативных потоков сценариев работы системы.

- Определение с технической архитектурой. Выбор инструментария и платформы с учётом нефункциональных требований.

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

Этап 3 «Проектирование архитектуры» включает шаги:

- Анализ робастности. Построение диаграммы робастности (как диаграммы классов с использованием стереотипов) для каждого сценария прецедента.

- Логическое моделирование структуры. Обновление диаграммы классов с учётом диаграммы робастности. Получение обновлённой модели ПрО в виде диаграммы классов логического уровня.

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

Этап 4 «Проектирование взаимодействия» включает шаги:

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

- Логическое моделирование поведения. Обновление диаграммы классов с учётом диаграмм взаимодействия. Получение обновлённой модели ПрО в виде диаграммы классов логического уровня.

Веха 4 «Обзор дизайна взаимодействия» эквивалентна предыдущей вехе.

Этап 5 «Проектирование компонентов» включает шаги:

- Детализация особенностей. Выявление недостаточности построенных моделей при реализации некоторых особенностей системы. Построение диаграмм переходов состояний (диаграмм состояний и/или деятельности).

- Физическое моделирование. Обновление диаграммы классов с учётом диаграмм переходов состояний. Получение детальной модели ПрО в виде диаграммы классов физического уровня.

Веха 5 «Обзор дизайна компонентов» эквивалентна предыдущей вехе.

Этап 6 «Проектирование реализации» включает шаги:

- Детализация модели. Построение диаграмм реализации (диаграмм компонентов и/или развёртывания).

- Моделирование реализации. Получение окончательной модели ПрО в виде диаграммы классов реализационного уровня.

Веха 6 «Обзор дизайна компонентов» эквивалентна предыдущей вехе.

Этап 7 «Реализация» включает шаги:

- Генерирование кода. Получение программного кода системы путём автоматической генерации из построенных диаграмм UML с учётом выбранного инструментария и платформы.

- Программирование. Написание оставшегося программного кода системы.

- Верификация. Проверка полученного программного кода системы.

Веха 7 «Обзор дизайна компонентов» служит для проверки того, что программный код соответствует построенным диаграммам, рассматриваемым как руководство к написанию кода.

Содержание отчёта

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

1. Постановка задания.

2. Содержание работы.

3. Введение: описание ПрО.

4. Результаты этапа 1.

- Спецификация требований: общие диаграммы прецедентов.

- Общая модель ПрО: диаграмма классов концептуального уровня.

5. Результаты этапа 2.

- Результаты детализации прецедентов: описания прецедентов.

- Техническая архитектура: инструментарий и платформа.

6. Результаты этапа 3.

- Результаты анализа робастности: диаграммы робастности.

- Логическая модель структуры: диаграмма классов логического уровня.

7. Результаты этапа 4.

- Результаты детализации сценариев: диаграммы взаимодействия.

- Логическая модель поведения: диаграмма классов логического уровня.

8. Результаты этапа 5.

- Результаты детализации особенностей: диаграммы переходов состояний.

- Физическая модель: диаграмма классов физического уровня.

9. Результаты этапа 6.

- Результаты детализации модели: диаграммы реализации.

- Модель реализации: диаграмма классов реализационного уровня.

10. Результаты этапа 7.

- Результаты генерирования кода: сгенерированный программный код.

- Результаты программирования: полученный программный код.

- Результаты верификации (тестирования / инспектирования): исходные данные и результаты проверки, а также программный код системы.

11. Заключение: вывод по результатам выполнения курсовой работы.

9. Типовые задания

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

Предметные области

1. Производственное предприятие (завод, комбинат, фабрика).

2. Торговая фирма (магазин, киоск, аптека, сеть магазинов).

3. Учебное заведение (школа, колледж, вуз, специальные курсы).

4. Организация по перевозкам (вокзал, порт, депо, такси, АТП).

5. Общественно-политическая организация (партия, объединение).

6. Фирма «экономического» профиля (банк, ломбард).

7. «Информационное» хранилище (библиотека, музей, НИИ).

8. Средства массовой информации (радио, телевидение, редакция).

9. Отделы предприятия (управление кадров, бухгалтерия, канцелярия).

10. Общественная организация (поликлиника, больница, санаторий).

11. Обслуживающее предприятие (ателье, АТС, АЗС, стоянка).

12. Другие темы по выбору (коллекция объектов, БТИ, бюджет).

Примеры автоматизации

1. Система управления проектами предприятия.

2. Система управления ресурсами предприятия.

3. Система управления документооборотом предприятия.

4. Система управления кадрами предприятия.

5. Система управления взаимодействиями с поставщиками.

6. Система управления взаимодействиями с покупателями.

7. Система предоставления услуг через Интернет.

8. Система автоматизации обслуживания и ремонта.

9. Система сбора и обработки информации предприятия.

10. Система управления продажей и бронированием билетов для мероприятий.

Варианты заданий

1. Система учёта резюме и собеседований для отдела кадров.

2. Система управления распределёнными складами предприятия.