Локальная сеть предприятия UML - Unified Modeling Language

UML - Unified Modeling Language

Unified Modeling Language
, сокращённо UML
, применяется на различных этапах разработки программного обеспечения (ПО). UML переводится как унифицированный язык моделирования
.

Если посмотреть спецификацию UML, то можно заметить некоторую её избыточность. Сама спецификация занимает около 900 страниц формата А4. К счастью, для чтения UML-диаграмм нужно знать только условные обозначения, применяемые в UML.

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

Unified Modeling Language может использоваться на различных этапах разработки ПО: как во время проектирования ПО, так и во время кодирования на конкретном языке. Так как UML представлен диаграммами, то этот язык используется не только программистами, но и, например, менеджерами в компаниях, разрабатывающих ПО (но при этом нужно знать некоторые концепции ООП).

Теперь давайте уйдём от скучных определений и подумаем, а для чего нам, простым программистам, нужен этот самый UML? Представим такую ситуацию: у нас есть три класса, каждый по 300 строк кода. Между классами определены сложные связи. Уследить за кодом в данной ситуации довольно сложно. А вот если эти классы представить UML-диаграммой, то все классы и связи между ними будут видны на одной небольшой картинке (диаграмме).

Если посмотреть на спецификацию Unified Modeling Language, то может показаться, что язык очень сложный. На самом деле читать UML-диаграммы довольно легко. Главное разобраться с условными обозначениями.

И последнее замечание прежде чем мы начнём: uml довольно новый язык, был создан в середине 90-х годов (1994-1996). На данный момент есть спецификация uml 2.2. Именно версию 2 мы будем рассматривать. Отличия между uml 1 и uml 2 нам не важны.

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

В UML можно создавать несколько типов диаграмм. В большинстве случаев мы будем пользоваться диаграммами классов (Class diagram). В данном типе диаграмм показывается взаимодействие классов программы.

Элементы диаграмм UML

Диаграммы UML состоят из элементов. Элементы представляются прямоугольниками, в которых пишется имя элемента. Например, изобразим в UML-диаграмме какой-нибудь класс (для примера я взял, написанный нами ранее, класс Camera):

Комментарии в UML

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

Атрибуты (attribute) и операции (operation) в UML-диаграммах

Если в C++ переменная, принадлежащая классу, называется полем класса или переменной-членом, то в UML такая переменная называется атрибутом. Также и с функцией/методом класса - в UML это операция.

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

Тип атрибута (как и тип аргумента операции) задаётся через двоеточие:

Здесь можно увидеть все достоинства UML. В Unified Modeling Language необязательно расписывать все
детали классов. Это будет сделано при написании кода на конкретном языке (в нашем случае - C++). В UML-диаграмме можно опускать ненужные детали. Например, в диаграмму элемента можно добавить только те операции/атрибуты, которые важны для данной диаграммы, неважные особенности класса в UML можно опускать.

Видимость атрибутов и операций в UML: +, -, # (спецификаторы доступа)

Спецификатора доступа языка C++ (public, private, protected) в UML отображаются символами + (public), - (private), # (protected), которые ставятся перед именем атрибута/операции. Также возможен вариант с ключевыми словами public, private, protected. На картинке ниже показаны оба варианта:

Напомню значение спецификаторов доступа: public - поля/методы класса видны снаружи класса. Т.е. к ним могут получать доступ объекты класса. private - поля/методы класса видны только внутри определения класса. protected - поля/методы класса видны в определении самого класса и в определениях производных классов.

Отношения между классами в ООП (UML, С++)

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

Ассоциация/объединение/связь (association)

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

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

На диаграммах ассоциация обозначается сплошной линией.

Для примера напишем простой класс:

class MonstAr

{

private:

attack(int damage) // damage - урон

{}

};

Напоминаю, что стандартные типы C++ являются классами. Вот как будет выглядеть взаимодействие классов MonstAr и int на диаграмме UML:

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

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

Заметьте, что стрелочка указывает на int. В данном случае направленность ассоциации говорит нам, что в методе MonstAr::Attack используется объект типа int.

Обобщение (generalization)

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

MonstAr

{

private:

attack(int damage) // damage - урон

{}

};

BigMonstAr : public MonstAr // большой (big) MonstAr

{

// определениекласса

};

SmallMonstAr : public MonstAr // маленький (small) MonstAr

{

// определение класса

};

При обобщении рисуется сплошная линия. Обратите внимание как рисуется стрелочка - пустой треугольник.

Теперь насчёт слова обобщение
(generalization). В UML используется именно оно, а не наследование
, так как в данном виде связи один из классов (базовый) является общим, а остальные классы (производные) - более специализированными.

Aggregation - агрегация, агрегирование, включение в UML

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

Итак, в UML агрегация отражает связь классов, когда объект одного класса является атрибутом другого. Пример:

class MonstAr

{

public:

int a;

};

На диаграммах агрегация показывается незакрашенным ромбом.

Композиция классов - composition в UML

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

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

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

class Claws; // claws - когти

class MonstAr

{

public:

Claws MonstArClaws;

};

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

На диаграммах композиция показывается закрашенным ромбом.

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

Реализация - realization в UML

Последнее отношение, которое мы рассмотрим, будет realization - реализация. Данная связь показывает отношение: класс - объект.

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

Заключение

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