Локальная сеть предприятия 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. В ближайшее время я доработаю урок по конечным автоматам, где мы воспользуемся новыми знаниями.