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

1) технология визуального моделирования, позволяет работать со сложными системами и проектами. Сложность программных систем возрастает по мере создания новых версий. И в какой-то момент дальнейшее развитие системы становиться невозможным, поскольку уже никто не представляет в целом "что и почему происходит". Происходит потеря управлением проектом.

2) визуальные модели позволяют содержательно организовать общение между заказчиками и разработчиками. Шутка о том, что "заказчик что-то хочет, но точно не знает, чего именно", с завидным постоянством часто оказывается былью

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

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

· сокращение стоимости проекта,

· поставка системы в запланированные сроки.

КлассификацияUML-диаграмм:

1) Структурные диаграммы:

· Диаграмма классов

· Диаграмма развертывания

· Диаграмма объектов

· Диаграмма компонентов

2) Диаграммы поведения:

· Диаграмма деятельности

· Диаграмма состояний

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

3) Диаграммы взаимодействия:

· Диаграмма кооперации

· Диаграмма последовательности

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

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

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

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

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

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

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

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

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

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

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

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

Классом называется описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Например, класс “Стена” описывает объекты с общими свойствами: высотой, длиной, толщиной, и т.д. При этом конкретные стены будут рассматриваться как отдельные экземпляры класса «стена». На диаграмме UML класс отображается в виде прямоугольника.

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

Операция – это некоторый сервис, который предоставляет экземпляр или объект класса по требованию своих клиентов

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

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

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

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

1. Определите все классы, задействованные в программном решении. Для этого проанализируйте диаграммы взаимодействий.

2. Отобразите их на диаграмме классов.

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

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

5. Добавьте информацию о типах атрибутов и методов.

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

7. Добавьте стрелки, определяющие направление навигации для ассоциаций.

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

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

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

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

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

11. Порядок построения диаграммы композитной/составной структуры. Порядок построения диаграммы объектов

Диаграмма композитной/составной структуры (Compositestructurediagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

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

Рисунок 1. Шаблон "Декоратор" на структурной диаграмме

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

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

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

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

Моделирование объектной структуры осуществляется так:

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

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

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

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

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

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

Как видно из рисунка, один из объектов соответствует самому роботу (r, экземпляр класса Robot); в настоящий момент он находится в состоянии moving(движется). Этот объект связан с экземпляром w класса World(Мир), являющегося абстракцией модели мира робота. В свою очередь объект w связан с мультиобъектом, который состоит из экземпляров класса Element, описывающего сущности, опознанные роботом, но еще не включенные в его модель мира. Эти элементы помечены как части глобального состояния робота.

В текущий момент времени экземпляр w связан с двумя экземплярами класса Area. У одного из них (а2) показаны его собственные связи с тремя объектами класса Wall (Стена) и одним – класса Door (Дверь). Указана ширина каждой из трех стен и обозначено, что каждая связана с соседними. Как видно из диаграммы, робот распознал, что замкнутое помещение, в котором он находится, имеет с трех сторон стены, а с четвертой - дверь.

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

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

Состояние действия (actionstate) является специальным случаем состояния с некоторым входным действием и по крайней мере одним выходящим из состояния переходом. Графически состояние действия изображается фигурой, напоминающей прямоугольник, боковые стороны которого заменены выпуклыми дугами (рис. 1). Внутри этой фигуры записывается выражение действия (action-expression), которое должно быть уникальным в пределах одной диаграммы деятельности

Рис.1-Графическое изображение состояния действия

Действие может быть записано на естественном языке, некотором псевдокоде или языке программирования. Никаких дополнительных или неявных ограничений при записи действий не накладывается. При построении диаграммы деятельности используются только те переходы, которые переводят деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии (нетриггерные). На диаграмме такой переход изображается сплошной линией со стрелкой. Ветвление на диаграмме деятельности обозначается небольшим ромбом, внутри которого нет никакого текста (рис. 2). В качестве примера рассмотрим фрагмент алгоритма нахождения корней квадратного уравнения. В общем случае после приведения уравнения второй степени к каноническому виду: а*х*х + b*х + с = 0 необходимо вычислить его дискриминант. Причем, в случае отрицательного дискриминанта уравнение не имеет решения на множестве действительных чисел, и дальнейшие вычисления должны быть прекращены. При неотрицательном дискриминанте уравнение имеет решение, корни которого могут быть получены на основе конкретной расчетной формулы. Процедуру вычисления корней квадратного уравнения можно представить в виде диаграммы деятельности с тремя состояниями действия и ветвлением (рис. 2). Каждый из переходов, выходящих из состояния "Вычислить дискриминант", имеет сторожевое условие, определяющее единственную ветвь, по которой может быть продолжен процесс вычисления корней в зависимости от знака дискриминанта.

Рис. 2-Фрагмент диаграммы деятельности

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

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

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

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

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

Рис 3.-Графическое изображение состояний на диаграмме состояний

Состояние на диаграмме изображается прямоугольником со скругленными вершинами. Этот прямоугольник, в свою очередь, может быть разделен на две секции горизонтальной линией. Если указана лишь одна секция, то в ней записывается только имя состояния. В противном случае в первой из них записывается имя состояния, а во второй – список некоторых внутренних действий или переходов в данном состоянии. Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий. В этом состоянии находится объект по умолчанию в начальный момент времени. Графически начальное состояние в языке UML обозначается в виде закрашенного кружка из которого может только выходить стрелка, соответствующая переходу. Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий. В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени. Графически конечное состояние в языке UML обозначается в виде закрашенного кружка, помещенного в окружность в которую может только входить стрелка, соответствующая переходу. Простой переход (simpletransition) представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. На диаграмме состояний переход изображается сплошной линией со стрелкой, которая направлена в целевое состояние.

Рис. 5-Диаграмма состояний для моделирования почтовой программы-клиента

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

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

· определить общие границы и контекст моделируемой предметной области;

· сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

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

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

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

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

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

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

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

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

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