Анализ и моделирование на UML Направление подготовки “ Информационные системы и

Валерьевич Хлопотов,
старший преподаватель кафедры ИС

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

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

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

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

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

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

классов применяются два отношения:
классификатор (в частности, класс) использует интерфейс —

это показывается с помощью зависимости со стереотипом «call»;
классификатор (в частности, класс) реализует интерфейс — это показывается с помощью отношения реализации.

классов применяются два отношения:
классификатор (в частности, класс) использует интерфейс —

это показывается с помощью зависимости со стереотипом «call»;
классификатор (в частности, класс) реализует интерфейс — это показывается с помощью отношения реализации.

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

— другие операции класса Position классу Department не нужны. Для этого можно определить соответствующий интерфейс IPosition и связать его отношениями с данными классами.

очень большого или даже потенциально бесконечного) и конечного множества операций,

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

в качестве указания типа?

могут быть:
атрибуты классов, в том числе классов ассоциаций;
параметры операций, в

том числе тип возвращаемого значения;
роли полюсов ассоциаций;
параметры шаблонов (см. ниже).

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

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

как минимум, три: строка, целое число и значение даты/времени. Инструменты

вправе расширять этот набор и использовать подходящие названия.
Типы данных, которые определены в языке программирования, поддерживаемым инструментом. Это могут быть как названия встроенных типов, так и сколь угодно сложные выражения, доставляющие тип, если таковые допускаются языком.
Типы данных, которые определены в модели. В стандарте UML предусмотрен только один конструктор типов данных: перечислимый тип, который определяется с помощью стереотипа «enumeration». Наряду со стандартным стереотипом «enumeration» многие инструменты допускают использование стереотипа «datatype», который означает построение типа данных с помощью не специфицированного конструктора типов.

это класс с параметрами. Параметром может быть любой элемент описания

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

параметрическую конструкцию класса один раз, и затем использовать ее многократно,

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

Для того, чтобы на основе шаблона получить конкретный класс, который

может использоваться в модели, нужно указать явные значения аргументов. Такое указание называется связыванием. В UML применяются два способа связывания:
явное связывание — зависимость со стереотипом «bind», в которой указаны значения аргументов;
неявное связывание — определение класса, имя которого имеет формат имя_шаблона < аргументы >
Явное связывание более наглядно, неявное связывание менее наглядно, зато записывается короче.

Этот шаблон применяется для создания массивов определенной длины, содержащих элементы

определенного типа. В данном случае с помощью явного связывания определен класс Triangle как массив из трех элементов типа Point.
На следующем занятии будет тест, на котором я задам вопрос: «Показать то же самое с помощью неявного связывания».

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

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

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

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

на основе анализа предметной области, взаимного согласования элементов модели и

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

и диаграмм размещения. Название объясняется тем, что данные диаграммы приобретают

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

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

компонентов в приложении;
• структуры используемых вычислительных ресурсов.

моделируемой системы.
На диаграмме компонентов применяются следующие основные типы сущностей:
компоненты;
интерфейсы;
классы;
объекты.
На диаграмме

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

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

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

более сложное и объемное, чем фрагмент кода или одиночный класс.
Компонент

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

нужна — она оказывается тривиальной и никакой полезной информации не

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

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

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

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

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

гипертекста Home .html и файл помощи Search .hlp, а исходный

текст этого исполнимого компонентa хранится в файле Control .cpp.

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

При этом для второго компонентa этот

интерфейс является экспортируемым. 

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

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

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

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

системы.
Компоненты системы во время ее работы размещаются на узлах. В

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

(а) - имя типа узла, (б) – имя экземпляра узла

.

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

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

компонента внутрь фигуры узла.

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

образцов проектирования
3. Используя методы идентификации классов, выделить классы.
4. Указать

связи между классами.
5. Указать атрибуты классов.
6*. Указать операции классов.
7. Создать диаграммы реализации.

области
2. Перечень классов (с указанием атрибутов и операций)
3. Диаграммы классов

(3 штуки)*
4. Диаграмма компонентов
5. Диаграмма развертывания

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