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

Что такое унифицированный язык моделирования

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

Говоря простыми словами, UML – это графическое отображение процессов

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

Также это облегчает работу, если составитель схемы вышел из проекта.

Минусы использования UML крайне незначительны:

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

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

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

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

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

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

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

Предисловие

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

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

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

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

Использование ООП может существенно упросить жизнь программисту. Это достигается за счёт сокрытия особенностей внутренней реализации классов. Программисту остаётся лишь пользоваться её удобствами. Кажется, что ООП – панацея от всех проблем. Однако на практике, если не иметь чёткого представления о том, какие классы нужно реализовать и как ими потом пользоваться, в результате может получиться очень запутанная система, которая начнёт порождать спагетти-коду (от англ. “spaghetti code”), который будет лишь мешаться, когда вы захотите добавить что-то новое в систему.

Чтобы избежать большинства проблем, возникающих при использовании ООП, нужно:

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

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

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

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

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

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

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

Обратите внимание на расположение активностей на этой диаграмме: они как бы разбросаны по трем колонкам, каждая из которых соответствует поведению одного из трех объектов — клиента, веб-сервера и сервера баз данных. Благодаря этому легко определить, каким из объектов выполняется каждая из деятельностей

Подробнее о диаграмме деятельности можно прочитать здесь.

Отношение расширения

Нужно сказать, что в диаграммах вариантов использования применяется ещё один вид связи – отношение расширения. На мой взгляд, применение отношение расширения несколько специфично, поскольку неправильное его использование может запутать читателя диаграммы. Тем не менее, для полноты картины мы всё равно рассмотрим применение этого отношения на практике. В последний раз модифицируем нашу диаграмму!

Во время дистанционного обучения школьникам необходимо выполнять домашние задания и присылать их в виде архива или фотографий учителям. Получается, нужно добавить возможность прикреплять файл к сообщению в нашей системе. Чтобы отобразить это на диаграмме мы будем использовать отношение расширения. Отношение расширения обозначается пунктирной линией с V-образной стрелкой на конце (похоже на отношение включения), над стрелкой добавляется надпись “extend ”.

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

На диаграмме предполагается, что к заказу МОЖЕТ БЫТЬ
добавлена картошка фри или соус (необязательно)

Два нижних варианта использования описывают возможные «расширения» для базового варианта использования

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

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

Расширяем функционал отправки сообщений
с помощью функции прикрепления файлов к сообщению
(Необязательно прикреплять файл к каждому сообщению)

Как итог, получим такую диаграмму:

Четвёртая версия диаграммы

Вот и всё. Я постарался рассказать вам про все моменты построения диаграммы вариантов использования при проектировании программных систем. В следующем вашем проекте обязательно попробуйте построить данную диаграмму на стадии проектирования. Ваши усилия обязательно окупятся!

Общие рекомендации:

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

Плюсы и минусы методологии

Среди ключевых преимуществ модели выделим следующие характеристики:

UML — это объектно-ориентированный язык, поэтому методы, с помощью которых описываются результаты анализа и проектирования являются семантически идентичными к методам программирования на ключевых ОО-языках, используемых в современных технологиях.
С помощью UML можно описать ситуацию или ключевую задачу с различных точек зрения и аспектов поведения системы.
UML диаграммы простые в восприятии: прочитать схему и ознакомится с ее синтаксисом сможет даже работник, не имеющих специальных знаний в области программирования и постройки бизнес-моделей (речь идет о стандартных схемах с 20-40 условными обозначениями).
UML минимизирует процент возможных ошибок при создании бизнес-процесса. Например, она исключает несогласованность параметров дополнительных программ или изменение основных атрибутов.
Любой этап бизнес-процеса может быть использован повторно в уже существующем или новом проекте организации.
UML можно применять не только для решения вопросов программной инженерии, но и для введения собственных текстовых и графических стереотипов.
В отличие от аналогичных нотаций, UML стремительно развивается и получает широкое распространение в построении моделей различных сферах бизнеса.

Как и другие нотации, UML имеет недостатки:

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

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

Программа получает данные с датчика температуры (вводятся с консоли) — по 5 измерений для каждого из двух объектов класса TemperatureMeasure и усредняет их. Также предусмотрен класс ShowMeasure для вывода измеренных значений.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778

#include <iostream>using namespace std;class Sensor { int value;public: Sensor() { value = 0; } void setValue(int value) { this->value += value; } int getValue() { return value; }};class MeasureCount{ int number; static int total;public: MeasureCount() { number = 0; } void increment() { number++; total++; } int getNumber() { return number; } static int getTotal() { return total; }};int MeasureCount::total = 0;class ITemperatureMeasure{public: virtual void setValue() = 0; virtual double getValue() = 0;};class TemperatureMeasure : public virtual ITemperatureMeasure{private: Sensor *h; // агрегация MeasureCount *measure; // композицияpublic: TemperatureMeasure(Sensor *h); int getNumber() { return measure->getNumber(); } double getValue() { return (double)h->getValue() / measure->getNumber(); } void setValue() { int value; measure->increment(); cout << «t= «; cin >> value; h->setValue(value); } static int getTotal() { return MeasureCount::getTotal(); }};TemperatureMeasure::TemperatureMeasure(Sensor *h){ measure = new MeasureCount(); this->h = h;}class ShowTemperature // зависимость{public: static void Show(TemperatureMeasure t) { cout << t.getNumber() << «: «; cout << t.getValue() << » oC» << endl; }};int main(){ Sensor *h1 = new Sensor(); TemperatureMeasure tc1(h1); for(int i=0; i<5; i++) tc1.setValue(); ShowTemperature::Show(tc1); cout << endl; Sensor *h2 = new Sensor(); TemperatureMeasure tc2(h2); for (int i = 0; i<5; i++) tc2.setValue(); ShowTemperature::Show(tc2); cout << endl; cout << «Total: » << TemperatureMeasure::getTotal() << endl; cin.get(); cin.get(); return 0;}

TemperatureMeasureSensorTemperatureMeasureSensorTemperatureMeasureMeasureCounttotalcountTemperatureMeasureMeasureCountTemperatureMeasureMeasureCountTemperatureMeasureITemperatureMeasureTemperatureMeasureпоставщикомShowTemperatureTemperatureMeasureShowShowTemperatureTemperatureMeasureАлгоритмизация

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

В верхней части диаграммы – активные объекты (и акторы) в виде прямоугольника («человечка»), от которого вниз проведена «линия жизни».
Сообщение (message) – отрезок горизонтальной линии со стрелкой, проведенный от линии жизни объекта (актора), посылающего сообщение, до линии жизни объекта (актора), получающего сообщение.

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

Сообщения упорядочены по времени: первое сообщение изображается вверху диаграммы, следующее – ниже, следующее – еще ниже и т.д.
Однако диаграмма не содержит метрики времени (расстояния между сообщениями – это не интервал времени)

Сущности

Диаграммы классов оперируют тремя видами сущностей UML:

Структурные.
Поведенческие.
Аннотирующие.

Структурные сущности – это «имена существительные» в модели UML. В основном, статические части модели, представляющие либо концептуальные, либо физические элементы. Основным видом структурной сущности в диаграммах классов является класс. Поведенческие сущности – динамические части моделей UML. Это «глаголы» моделей, представляющие поведение модели во времени и пространстве. Основной из них является взаимодействие – поведение, которое заключается в обмене сообщениями между наборами объектов или ролей в определенном контексте для достижения некоторой цели. Сообщение изображается в виде линии со стрелкой, почти всегда сопровождаемой именем операции. Аннотирующие сущности – это поясняющие части UML-моделей, иными словами, комментарии, которые можно применить для описания, выделения и пояснения любого элемента модели. Главная из аннотирующих сущностей – примечание. Это символ, служащий для описания ограничений и комментариев, относящихся к элементу либо набору элементов. Графически представлен прямоугольником с загнутым углом; внутри помещается текстовый или графический комментарий.

Понятие модели

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

Модель — упрощенный, приближенный образ, который отражает наиболее существенные (с точки зрения цели моделирования) свойства оригинала.
Соответствие модели оригиналу называется адекватностью модели.
Адекватность включает требования полноты и точности (правильности). Требования должны выполняться в той мере, которая достаточна для достижения цели.

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

Модель внешнего вида часовСтруктурная схема часов

Виды подобия: прямое (макет, фотография), косвенное (подобие по аналогии), условное (на основе соглашений).

Процесс моделирования имеет свойство динамичности: модели развиваются, уточняются, переходят одна в другую.

Упрощение моделирования с помощью программного обеспечения

Для упрощения моделирования доступны разнообразные инструменты моделирования UML, а также разработанные ПО. Среди всех доступных возможностей, следует выделить IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner и Dia. Они обладают хорошим функционалом и широким спектром инструментов для построения диаграмм и рациональным распределением задач между исполнителями.

Вне зависимости от выбранного ПО, необходимо учитывать, что язык UML основывается на общих принципах моделирования, которыми не следует пренебрегать:

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

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

Где еще используется UML

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

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

Виды UML-диаграмм

Существует два вида UML-диаграмм — структурные диаграммы и диаграммы поведения.

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

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

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

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

Диаграммы поведения подразделяются на подтипы:

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

Можно выделить несколько основных и наиболее доступных типов UML-диаграмм:

Диаграмма прецедентов (Use-case diagram);
Диаграмма классов (Class diagram);
Диаграмма деятельности (Activity diagram);
Диаграмма последовательности (Sequence diagram);
Диаграмма развертывания (Deployment diagram);

Диаграмма прецедентов (Use-case diagram)

Диаграмма прецедентов описывает функциональные требования системы с точки зрения прецедентов и включает в себя два компонента — участника (Actor) и прецедент (Use case).

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

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

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

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

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

UML-диаграммы классов отображают как классы внутри системы, так и разные виды отношений между классами.

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

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

Диаграмма деятельности (Activity diagram)

Диаграмма деятельности или активностей (Activity diagram) использует блок-схему для графического изображения динамических аспектов поведения системы.

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

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

Диаграмма последовательности (Sequence Diagram)

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

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

Диаграмма развертывания (Deployment Diagram)

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

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

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

Методология IDEF0

Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований.IDEF0-модель состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения).

Основные элементы модели:

Функциональный блок (Activity) – преобразование (активность);
Выходы (Output) – результат преобразования;
Входы (Input) — объекты, которые преобразуются в Выходы;
Управление (Control) — информация, как происходит преобразование;
Механизм (Mechanism) – объекты, осуществляющие преобразование.

Функциональный блок может быть декомпозирован — представлен в виде совокупности других взаимосвязанных блоков, которые детально описывают исходный блок.
Таким образом, IDEF0-модель состоит из набора иерархически связанных диаграмм
На диаграмме блоки соединяются дугами: выходные дуги одних блоков могут являться входами (управлением, механизмом) других.
Дуги с одним свободным концом имеют источник или получатель вне диаграммы. Для обозначения внешних дуг используются буквы:

I (Input),
C (Control),
O (Output) и
M (Mechanism).

Типы связей между блоками:Выход-входВыход-управлениеВыход-механизмОбратная связь по управлениюОбратная связь по входу

Класс

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

Имя класса
Список полей класса
Список методов класса

Обязательным элементом класса является только его название.Пример класса «Покупатель». У покупателя есть баланс (balance) денег и список желаемого (wishList). Пользователь может пополнять баланс на некоторую сумму денег (topUpBalance()), может совершать покупки (makePurchase()) и может добавлять товары в список желаемого (appendToWishList()). Также мы можем проверить, подтверждена ли электронная почта пользователя.

Обычно в качестве имени класса выбирается существительное в единственном числе. Разумеется, это имя должно быть уникальным в пределах диаграммы. Если имя класса состоит из нескольких слов, мы ,по практическим соображениям, будем записывать их слитно в верблюжьем стиле (от англ. «CamelCase»).

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

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

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

Статический класс

Класс, в котором есть только статические поля и методы и на основе которого не создаются объекты, называется статическим классом. Чтобы показать на диаграмме, что наш класс статический, нужно добавить к имени модификатор «utility».

В нашей системе классы MathParser, MathFormConverter, MathConstantManager являются статическими, потому что они представляют собой «сборник» полезных функций, которые мы объединили в класс. Давайте изобразим это на нашей диаграмме.

2 версия диаграммы

Абстрактный класс

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