Бусыгин Б.С., Коротенко Г.М., Коротенко Л.М. Введение в современную информатику

Подождите немного. Документ загружается.

180

В рамках языка и концепции использования UML, создатели этого

унифицированного средства моделирования и их партнеры объявили

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

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

моделирования.

 Подготовлены необходимые средства моделирования, а также

языковые механизмы расширения и специализации для разных предметных

областей, так как при дальнейшем развитии UML нежелательно

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

допускают его расширение для нестандартных ситуаций, а также содержат

средства учёта специализации задач в конкретных предметных областях (к

примеру, в системах реального времни, Web–технологях, Web–сервисах,

геоинформационных системах и т.д.).

 Обеспечена независимость процесса разработки информационных

систем от языков программирования и моделей этого процесса, так как UML

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

разработки ПО, которые приняты при разработке программного обеспечения на

конкретных предприятиях.

 Создание формального обоснования языка моделирования. Авторы

UML выдвинули тезис о том, что формализация языка должна присутствовать в

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

использования коллективами разработчиков. Для этого, правила и ограничения

на конструирование валидных (то есть адекватных исходным системам)

моделей информационных процессов, определены в UML английской прозой, а

также в Языке Объектных Оограничений (OCL). Семантика (то есть

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

прозой. Следует чётко представлять, что английская проза при изложении

спецификации и основ применения UML была использована только для того,

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

чрезвычайной сложности созданной системы моделирования. Ибо,

одновременно с этим, для всех описываемых в UML подходов и моделей

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

соответствующие математические представления.

 С разработкой UML внесён важный вклад в расширение рынка

производимых объектно-ориентированных инструменто. Кроме того, UML

должен обеспечить интероперабельность для всех существующих и новых

объектно-ориентированных средств, которые появляются вновь и вновь.

Основным практическим выходом разработанного языка UML является то, что

он предназначен для спецификации, визуализации, конструирования и

документирования артефактов, которые отчуждаются от разработчиков, а также

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

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

отличительными признаками. С точки зрения содержания UML наследует

принципы и механизмы техники Booch и методов OMT и OOSE. Во-вторых, он

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

181

не стандарт процессов анализа, проектирования и разработки. UML является

квинтэссенцией концепций моделирования, в соответствии с которыми был

достигнут консенсус в среде ведущих компаний-производителей ОО

програмного обеспечения, а конкретно в вопросах:

 Соглашений о семантике и нотации для разнообразных аспектов

современного моделирования в лаконичной форме.

 Определения достаточной глубины семантики для будущих технологий,

таких как: компонентное программирование, распределённые вычисления,

геоинформационные и беспроводные технологии и т.д.

Необходимо также понимать, что несмотря на широкие возможности UML,

это только язык моделирования, то есть средство моделирования, которым

необходимо уметь пользоваться, знать, когда и где использовать ту или

другую технику, чётко представлять себе порядок этапов проектирования и

структуру модели, которая разрабатывается.

В инфраструктуре UML важное место занимают средства проектирования

и реализации. К ним относятся:

 языки программирования. UML - язык визуального моделирования и не

предназначен для визуального программирования, хотя инструментальное

средство, поддерживающее нотации UML, может реализовывать

кодогенерацию в конкретный язык программирования (C++, Delphi, Java и др.)

на основе построенных моделей.

 инструментальные средства. UML не является спецификацией для

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

семантики, но не определены модели интерфейса, хранения и поддержки

времени выполнения. В настоящее время имеется несколько CASE– средств,

производители которых поддерживают моделирование средствами UML. Среди

них можно выделить: Rational Rose, Select Enterprise, Platinum и Visual Modeler

(рис. 7.17).

Рисунок 7.17. Применение моделей UML при разработке бизнес

приложений с помощью CASE-средств фирмы Select Enterprise

182

 модели процесса. Предприятия используют UML как единый язык при

разработке всех компонентов проекта, хотя кокретные этапы и сам процесс

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

сходимость моделей процессов для разных организаций, но общего соглашения

по данному вопросу пока не найдено. UML не навязывает свою модель

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

свойствами управления прецедентами, итеративный и инкрементный.

7.3 Структура и состав языка UML

Рассмотрим структуру языка с точки зрения компонент, составляющих его

описание. Определение UML, является самодостаточным и включает в себя

(в версии 1.3 , выпущенной в 1999 г.) следующие документы.

 Семантика UML;

 Нотация UML;

 Стандартные шаблоны;

 Определение средств CORBA-интерфейсов;

 Спецификации UML XMI DTD (для обмена моделями с помощью языка

XML);

 Спецификации языка OCL (Object Constraint Language).

Описание семантики UML производится на уровне метамодели и

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

 Абстрактный синтаксис включает метамодель UML, разбитую на 9

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

классов UML (рис. 7.18). Метамодель включает в себя около 50 классов, более

100 ассоциаций и 1000 ограничений.

 На каждом етапе моделирования можно использовать правила

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

ограничений OCL, являющегося объектно-ориентированым языком с

ограниченными кванторами.

Рис. 7.18. Классы 9-ти типов диаграмм языка UML,

представленные в терминах самого языка

183

 Присутствует описание элементов нотации моделирования (семантики),

которое также выполнено в английской прозе.

Рассмотренные три описания в совокупности и образуют формальное

определение UML. Более формальное определение потребовало бы применения

сложного математического аппарата, что в конечном итоге затруднило бы

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

определениям.

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

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

 Стереотипы позволяют определить подклассы существующих

элементов моделирования, сохраняя форму, но вкладывая новое содержание и

добавляя новые свойства.

 Тэгированные значения позволяют определять новые свойства

элементов моделирования, что дает возможность привязать к модели

совершенно произвольную информацию.

 Ограничения позволяют определить подмножество элементов

моделирования, наделенное определенными свойствами (например,

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

OCL.

7.4. Типы диаграмм UML и их использование

Моделирование сложной системы средствами UML сводится к ее

описанию в нескольких различных проекциях (рис. 7.19). Каждая проекция

описывает определенный аспект разрабатываемой системы, а все вместе они

определяют систему с должной степенью полноты, правильности и

адекватности. В UML для описания системы при анализе и проектировании

предусмотрены следующие графические диаграммы.

Диаграммы, которые описывают

статическое состояние системы:

 Диаграммы прецедентов

(вариантов использования) (Use case

diagrams).

 Диаграммы классов (Class

diagrams).

 Диаграммы объектов (Object

diagrams).

Диаграммы, описывающие поведение

системы:

 Диаграммы состояний (State

diagrams).

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

(Activity diagrams).

Рис. 7.19.

Представление

разных проекций

(аспектов) системы

184

 Диаграммы последовательностей (Sequence diagrams).

 Диаграммы сотрудничества (кооперации, взаимодействия)

(Collaboration diagrams).

Диаграммы, описывающие физическую реализацию системы:

 Диаграммы компонентов (Component diagrams).

 Диаграммы развёртывания (Deployment diagrams) (рис. 7.20).

Таким образом, язык UML позволяет:

 формализовать функциональные требования к системе с помощью

аппарата use case диаграмм;

 детализировать требования к системе путём построения диаграмм

технологичных сценариев;

 разбить сложную систему на составные части с минимумом взаимных

сявзей путём выделения пакетов;

 выделить классы данных, построив концептуальную модель данных в

виде диаграммы классов;

 выделить классы, описывающие интерфейс пользователя и создать

схему навигации экранов для взаимодействия ИС с ним;

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

системных функций;

 описать поведение объектов в виде диаграмм состояний;

 показать программные компоненты и их взаимодействие через

интерфейсы;

 представить физическую архитектуру системы.

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

системы, с точки зрения разработчика (рис. 7.21).

Диаграммы видов

деятельности

Диаграммы

прецедентов

(вариантов

использования)

Диаграммы

классов

Диаграммы

объектов

Диаграммы

последовательностей

Диаграммы

состояний

Диаграммы

компонентов

Диаграммы

развёртывания

Диаграммы сотрудничества

(кооперации, взаимодействия)

Рис. 7.20. Комплекс диаграмм, описывающих полную модель системы

185

И так как UML обширный и сложный в плане терминологии и нотации

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

типов.

Техника Прецедентов (Вариантов Использования –

UseCase) - была впервые предложена Айваром Якобсоном в

1992 и быстро завоевала всеобщее признание за счет

простоты и легкости восприятия и применения. Суть ее

состоит в следующем. Проектируемая система

представляется в виде наборов актантов (акторов),

взаимодействующих с системой с помощью так называемых

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

сущность, взаимодействующая с системой извне.

Им может быть человек, оборудование, другая система,

то есть таким образом разработчик определяет, что именно взаимодействует с

системой. В свою очередь прецедент описывает, что система предоставляет

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

актантом при диалоге с системой, при этом ничего не говориться о том, каким

образом будет реализовано взаимодействие. Детальное описание всех этих

процессов - удел других техник моделирования UML.

Диаграмма же прецедентов несет в себе высокий

уровень абстракции, что позволяет еще на ранних этапах

проекта определить и зафиксировать функциональные

требования к системе, её будущие интерфейсы и таким

образом обеспечить гибкий и эффективный механизм

взаимодействия между разработчиком и заказчиком

проекта на этапе анализа.

Диаграмма классов показывает статическую структуру

части системы (рис. 7.23). Таким образом, составляющими

(элементами) данного типа диаграмм являются классы,

объекты и отношения между ними. Нотация классов и объектов проста и

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

CASE-инструментариями (рис. 7.22, 7.23). Класс представлен прямоугольником

Рис. 7.22.

Диаграммы

прецедентов

(Use case)

Рис. 7.23.

Диаграммы

классов

(classes)

Проектное

представление

системы

Представление

реализации

системы

Представление

разворачивания

системы

Представление

процессов

в системе

Представление

системы

прецедентами

(вариантами

использования системы)

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

девяти диаграмм UML.

186

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

атрибуты и операции. Схожая нотация применяется и для

объектов - экземпляров класса, с тем различием, что к

имени класса добавляется имя объекта и вся надпись

подчеркивается.

Нотация UML предоставляет широкие возможности

для отображения дополнительной (и зачастую очень

важной) информации, к которой можно отнести

абстрактные операции и классы, стереотипы, общие и

частные методы, интерфейсы, параметризованные классы и

т.д. Важнейшими элементами диаграмм классов и объектов

являются ассоциации, то есть статические связии между классами,

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

может указываться мощность ассоциации, её направление, название, и

возможное ограничение, реализующее механизм расширения UML (рис. 7.24).

Существует возможность отразить специфические свойства ассоциации -

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

выступать другие классы.

Такое отношение изображается в виде ромба,

расположенного рядом с агрегирующим классом.

Отношение обобщения также имеет собственную

графическую нотацию в виде треугольника и связующей

линии, позволяя представить иерархию наследования – от

суперкласса к подклассам (рис.7.24).

Диаграммы кооперации (взаимодействия) описывают

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

получения некоторого результата (рис.7.25). Под

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

законченного действия, например, описание в терминах взаимодействующих

Этот класс ассоциируется с

Этот класс зависит от

Этот класс наследник

Этот класс имеет

Этот класс является реализацией

Вы можете управлять из этого класса

Эти классы фор

мируют без принадлежности

Эти классы формируют и являются частью

Этот объект посылает синхронное сообщение

Этот объект посылает асинхронное сообщение

этим классом.

эт

ого класса.

эт

ого класса.

этот

интерфейс.

эт

ого класса.

им класом.

этот

класс.

эт

ого класса.

эт

ому объекту.

эт

ому объекту.

Рис. 7.24. Ассоциации диаграмм языка UML.

Рис. 7.25.

Диаграммы

кооперации

(collaboration)

Рис. 7.23.

Диаграммы

объектов

(objects)

187

объектов смоделированного ранее прецедента Использования системы или

некоторого сервиса системы, объявленного как операция класса на

соответствующей диаграмме. Диаграммы взаимодействия представляются в

двух формах - Диаграмма следования и Диаграмма кооперации. И та, и другая

описывают потоки сообщений (вызов методов или сигналы) между объектами,

участвующими во взаимодействии. Служа, в целом, одной цели, диаграммы, по

сути своей, имеют существенные различия.

Диаграмма следования (рис.7.26), делает упор на временнŷю

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

сообщения, на диаграмме изображаются исключительно те объекты, которые

непосредственно участвуют во взаимодействии, и не показываются возможные

статические ассоциации с другими объектами. Таким образом, для Диаграмм

следования ключевым моментом в моделируемой системе является динамика

взаимодействия её элементов.

Следует иметь в виду, что Диаграмма следования

(последовательности) представляет (отображает) два

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

линий, изображающих объекты, участвующие во

взаимодействии. Верхняя часть линий дополняется

прямоугольником, содержащим имя класса объекта или

имя экземпляра объекта. Второе измерение - вертикальная

временная ось. Сообщения, посылаемые одним объектом

другому, изображаются в виде стрелок с именем

сообщения и упорядочены по времени возникновения.

Для Диаграммы кооперации главным является

возможность отобразить не столько последовательность

взаимодействия, сколько всё окружение объектов,

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

принимаемые сообщения, но и косвенные связи между ассоциированными

объектами. Говорят, что Диаграммы кооперации описывают полный контекст

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

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

определенной бизнес-цели программной системы.

Диаграмма кооперации изображает объекты,

принимающие участие во взаимодействии, в виде

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

класс и, возможно, значения атрибутов. Ассоциации

между объектами, как и на диаграммах классов,

изображаются в виде соединительных линий. Возможно

указание имени ассоциации и ролей, которые играют

объекты в данной ассоциации. Динамические связи -

потоки сообщений, представляются также в виде

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

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

Рис. 7.26.

Диаграммы

следования

(sequence)

Рис. 7.27.

Диаграммы

состояний

(state)

188

Диаграммы состояний описывают поведение объекта во времени, то есть

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

внешними воздействиями со стороны других объектов или извне (рис. 7.27).

Диаграммы состояний применяются для описания поведения объектов и для

описания операций классов.

В отличие от диаграмм взаимодействия, данный тип

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

или объекта. Каждое состояние объекта представляется на

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

закруглёнными углами, содержит имя состояния и,

возможно, значения атрибутов объекта в данный момент

времени. Переход из одного состояния в другое

осуществляется при наступлении некоторого события –

получения объектом сообщения или приёма сигнала, и

изображается в виде стрелки, которая объединяет два

соседних состояния. Имя события указывает на переход.

Кроме того, на переходе могут указываться действия,

вырабатываемые объектом в ответ на внешние события (при переходе из

одного состояния в другое или при нахождении в некотором определенном

состоянии). Следует отметить, що Диаграмма состояний описывает, как

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

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

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

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

условием. Объект переходит из одного состояния в другое, только если

произошло указанное событие и пусковое условие приняло значение "истина".

Диаграммы активности – частный случай Диаграмм состояний (7.28).

Каждое состояние – это сущность выполнения некоторой операции. А переход

в следуюющее состояние срабатывает только при завершении операции в

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

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

Описываемое состояние не имеет внутренних переходов и

переходов по внешним событиям.

Их графическая нотация практически не отличается от

нотации Диаграмм состояний, с той лишь разницей, что на

переходах отсутствует сигнатура действия и добавляется

символ "синхронизации" переходов для реализации

параллельных алгоритмов.

Основным направлением использования Диаграммы

активности является описание операций классов, когда

необходимо представить алгоритм её реализации, при этом

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

Диаграммы компонентов и развёртывания, в отличие от ранее

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

Рис. 7.28.

Диаграммы

активности

(activity)

Рис. 7.29.

Диаграмма

компонентов

(component)

189

которые являются логическим представлением системы в процессе её

разработки, описывают физическое представление системы (рис. 7.29, 7.30).

Диаграмма компонентов позволяет определить

архитектуру системы, которая разрабатывается, установив

зависимость между программными компонентами, в роли

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

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

представление о модуле (или компоненте) соответствует

(или совпадает) с представлением о файле. Пунктирные

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

взаимозависимости (аналогичные тем, которые имеют место

при компиляции).

Диаграммы развёртывания используется для представления конфигурации

компонентов, процессов и объектов, присутствующих в системе на етапе

исполнения. Кроме того, Диаграммы развёртывания показывают (отображают)

физическую зависимость аппаратных устройств, спроектированной

информационной системы, задействованных в её реализации, а также

соединений между ними – маршрутов передачи информации.

Понятно, что язык UML является ещё одним, очередным этапом в

совершенствовании инструментов проектирования и разработки

продолжающих усложняться информационно-компьютерных систем. При этом

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

частей и элементов взаимодействия.

Вопросы

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

программных систем?

Какие и почему существуют 5 уровней сложности программирования?

Какие существуют 5 уровней в развитии языков программирования?

Чем вызвано появление объектно-ориентированного подхода в

программировании?

Какой комплекс целей был воплощён и реализован в языке

моделирования процесса разработки программ UML?

Какие существуют средства проектирования и реализаци в

инфраструктуре UML?

Что образует структуру языка UML и какие компоненты входят в его

состав?

Для чего предназначены диаграммы UML и как они называются?

Какие основные процессы разработки программных систем упрощает

язык UML?

Рис. 7.30.

Диаграмма

развёрты-

вания

(deployment)