Пять технологических процессов

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

№№	Технологический процесс	Наименование по Бучу
	управление требованиями	требования
	анализ	анализ
	проектирование	разработка
	реализация	реализация
	тестирование	тестирование

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

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

Рис. Шесть основных моделей унифицированного процесса

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

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

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

Реализация. Целью этого технологического процесса является построение модели реализации, которая описывает, как элементы модели проектирования формируют такие компоненты как файлы исходного кода и библиотеки динамической компоновки (DLL и Enterprise Java Beans).

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

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

Артефакты и исполнители.

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

- модели,

- прототипы пользовательского интерфейса,

- план проекта.

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

Назначение UML

Унифицированный язык моделирования UML (Unified Modeling Languagе) был создан для того, чтобы участники процесса создания ПО могли строить модели для

1) визуализации системы;

2) определения ее структуры и поведения;

3) сборки системы;

4) документирования решений, принимаемых в процессе разработки.

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

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

Конструкции, создаваемые UML, имеют много общего с объектно-ориентированными языками программирования С++ или Java или языками программирования баз данных.

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

Язык UML явился логическим продолжением разработок способов объектно-ориентированного моделирования, моделирования объектов OMT, и написания кода. Язык UML был разработан тремя ведущими специалистами в области моделирования и разработки ПО Гради Бучем (Grady Booch), Джимом Румбахом (Jim Rumbaugh), Айваром Якобсоном (Ivar Jacobson) в компании Rational и ноябре 1997 г. стал стандартным языком объектно-ориентированного моделирования UML версии 1.0. Затем появились версии 1.2, 1.3, а сейчас, есть версия 2.0.

Общие сведения об UML

Словарь UML образует три разновидности строительных блоков:

1) предметы (сущности);

2) отношения;

3) диаграммы.

Предметы (сущности) – это абстракции, которые являются основными элементами в модели.

Отношения связывают эти элементы.

Диаграммы группируют коллекции предметов.

Предметы

В UML имеется четыре разновидности предметов (см. рис. ниже)

Рис. Разновидности предметов UML.

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

Структурные предметы (статические части) модели являются понятийными или физическими элементами.

Примеры структурных предметов: класс, интерфейс, актер, прецедент, компонент, узел.

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

Рис. Класс

Интерфейс – видимый извне набор операций, которые предоставляются классом или компонентом. Интерфейс определяет набор спецификаций, а не набор реализаций операций. Графически интерфейс изображается в виде круга с именем (см. рис. ниже). Имя интерфейс обычно начинается с буквы I.

Рис. Интерфейс.

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

Рис. Актер

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

Рис. Кооперация

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

Рис. Вариант использования

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

Рис. Компонент.

Узел – ресурс, размещающий набор компонентов и имеющий память и возможности обработки. В узле размещается набор компонентов, который может перемещаться от узла к узлу. Узел изображается как куб с именем (см. рис. ниже).

Рис. Узел

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

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

- сообщения,

- последовательность действий (поведение, связанное с сообщением),

- связи (соединения между объектами).

Сообщение изображается в виде направленной линии с именем его операции (см. рис. ниже).

Рис. Сообщение.

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

- состояния,

- переходы (от состояния к состоянию),

- события (предметы, вызывающие переходы),

- действия (реакции на переходы).

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

Рис. Состояние.

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

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

- структурные предметы,

- предметы поведения,

- другие группировки предметов.

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

Рис. Пакет

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

Рис. Примечание.

Отношения в UML

Отношения в UML представлены в виде:

- зависимости,

- ассоциации,

- обобщения,

- реализации.

Зависимость – это отношение между двумя предметами, при котором изменение смысла в одном (независимом) предмете может влиять на семантику другого (зависимого) предмета. Изображается в виде пунктирной линии, возможно направленной на независимый предмет и иногда имеющей метку (см. рис. ниже).

Рис Зависимость.

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

1 *

Клиент Заказ

Рис. Ассоциация.

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

Рис. Обобщение.

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

Замечание.

К классификаторам относятся классы, интерфейсы, компоненты, варианты использования, кооперации.

Отношения реализации применимы в двух случаях:

- между интерфейсами и классами (или компонентами), реализующими их,

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

Диаграммы в UML

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

UML включает девять видов диаграмм:

- диаграммы классов,

- диаграммы объектов,

- диаграммы вариантов использования (прецедентов),

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

- диаграммы сотрудничества (кооперации),

- диаграммы состояний,

- диаграммы деятельности,

- диаграммы компонентов,

- диаграммы развертывания (размещения).

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

2. Диаграмма объектов состоит из набора объектов и их отношения и представляет статический «моментальный снимок» с экземпляров предметов, находящихся в диаграмме классов.

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

4. Диаграмма последовательности распределяет упорядочение сообщений по времени.

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

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

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

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

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

Ниже подробнее рассмотрены диаграммы вариантов использования, диаграммы классов и диаграммы взаимодействия по материалам книг:

Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000. – 352 с.;

Боггс У., Боггс М. UML и Rational Rose.: Пер. с англ. – М.: Издательство «ЛОРИ», 2000. – 581с.;

Ларман К. Применение UML и шаблонов проектирования. 2- изд. – М.: Издательский дом «Вильямс», 2002. – 624 с.

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

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

Напомним, что варианты использования – это функции, выполняемые системой, а актеры – это заинтересованные лица по отношению к создаваемой системе.

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

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

В приведенном примере клиент банка инициирует различные варианты использования;

- снять деньги со счета;

- перевести деньги и т.д.

Банковский служащий может инициировать вариант использования “Изменить идентификационный номер”.

От варианта использования “Произвести оплату” идет стрелка к Кредитной системе.

Из диаграммы вариантов использования можно получить довольно много информации о системе.

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

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

Составление плана закупок.

Приведем фрагмент диаграммы вариантов использования для приложения розничной торговли через POST-терминал.

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

- покупку товара;

- возврат купленных товаров.

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

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

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

Замечание.

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

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

Поэтому в качестве примера приведем описание варианта использования “Покупка товара” в расширенной форме.

Главный раздел.

Вариант использования	Покупка товара
Исполнители.	Покупатель (инициатор), кассир.
Цель.	Оформление покупки и платежа.
Описание.	Покупатель подходит к кассе с выбранными товарами. Кассир вводит информацию о товаре и оформляет платеж. После этого покупатель уходит.
Ссылки.	Запись информации о текущей покупке – количество единиц товара. Вычисление общей стоимости покупки, включая налоги. Считывание информации о товаре со штрих кода с помощью сканера или ввод кода товара вручную. Поддержка базы данных. Отображение цены и описания выбранного товара. И функции обработки платежей наличными. Варианты использования. Кассир сначала должен реализовать вариант использования “Регистрация”.