Unified Modeling Language как унифицированный язык моделирования

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация. Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

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

Задание

С помощью UML диаграмм описать бизнес-процессы «Химчистки», в визуальной среде Visual Paradigm UML 2.0.

Use Case (Варианты использования)

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

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

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

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

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

Состав диаграммы Use Case

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

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

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

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

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

Виды взаимодействий

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

• Простая ассоциация — отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования. На рисунке между актером администратор и вариантом использования просматривать заказ.

• Направленная ассоциация — то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.

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

• Расширение (extend) — показывает, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность. При этом в отличие от типа отношений «включение» расширенная последовательность может осуществляться в зависимости от определенных условий.

Включение — показывает, что вариант использования включается в базовую последовательность и выполняется всегда (на рисунке не показан).

На данном этапе курсового проектирования мы добавили 5 актеров: «клиент», «администратор», «бухгалтерия», «рабочий» и «директор». Также добавили 8 действий Use Case: «подача заявки на чистку», «оформление заявки на чистку», «изменение заявки», «выполнить работу», «выдача квитанций об оплате услуг», «добавить заявку к отчету», «обновить отчет за день»,"отклонить заявку на чистку", последнее является как раз расширение. На данном рисунке видно, что актеры взаимодействуют с действиями (вариантами использования). Каждый Актер порождает взаимодействия. Все взаимодействия представлены на рисунке.

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

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

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

Рассмотрим диаграмму взаимодействия для «Подачи заявки на чистку белья»:

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

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

Клиент, придя в химчистку, прежде чем отдать бельё, он заполняет заявку. На рисунке видно, что клиент генерирует сообщение: «Составление текста заявки». Далее объект «Заявка» будет генерировать сообщения и для объекта «Расчет заявки» класса «Бухгалтерия». И так далее для всего процесса подачи заявки. Нужно заметить, что каждый объект является элементом определенного класса, как уже и говорилось, класс обозначается через двоеточие. На ClassDiagramm в соответствующих классах автоматически при генерации сообщения создаются операции и атрибуты, которые в последствии будут созданы при кодогенерации.

Communication diagram (диаграмма коммуникаций)

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

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

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

На диаграмме представлена структура взаимодействий объектов (LifeLine), так же как и на диаграмме последовательности, но только без учета временного фактора. Каждый объект является экземпляром соответствующего класса. Например, объект «Управляющий» является экземпляром класса «Управляющий заказами». Инициатором взаимодействия объектов является Actor — «Документовед». Наша диаграмма коммуникаций описывает процесс «Оформление заявки». Каждый объект генерирует связь/сообщение (link/massage) другому объекту. Таким образом, они взаимодействуют друг с другом. Все сообщения будут автоматически добавлены в диаграмму классов в качестве операций и атрибутов соответствующему классу как показано ниже на рисунке:

State Machine (диаграмма состояний)

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

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

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

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

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

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

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

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

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

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

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

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

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

В данной работе начало действия обозначает элемент Initial Node, а окончаний может быть несколько в нашем случае их будет три, и обозначаются они элементом Activity Final Node. На рисунке, видно, что когда механик получает заказ, он проверяет наличие автомобиля на СТО, а в это же время (параллельно) бухгалтерия выдает квитанцию на оплату. Если операция не оплачена, то механик не производит ремонт, если же деньги поступили, механику поступает заявка на ремонт. Он в свою очередь, если свободен, то приступает к работе немедленно, либо, если занят, то ставит данную заявку в очередь. Смысл диаграммы сводится к тому, чтобы показать какие процессы происходят параллельно друг другу, и показать какие варианты исхода могут быть.

Interaction overview diagram (Диаграмма обзора взаимодействия)

Interaction overview diagram — диаграмма, которая предназначена для представления взаимодействия только в контексте потока управления в некоторой агрегированной форме. Диаграммы обзора взаимодействия, вместо узлов действий и объектов диаграмм деятельности, имеют фреймы, каждый из которых может соответствовать взаимодействию или использованию взаимодействия. Альтернативные комбинированные фрагменты представляются узлом решения и соответствующим узлом слияния. Параллельные комбинированные фрагменты представляются узлом разделения и соответствующим узлом соединения. Комбинированные фрагменты типа Цикл представляются простыми циклами. Ветвление и слияния ветвлений на диаграммах обзора взаимодействия должны быть должным образом вложенными. Диаграммы обзора взаимодействия заключаются во фрейм, аналогично другим видам диаграмм взаимодействия с тегом sd и ref.

Для создания диаграммы взаимодействия были использованы теги (ref и sd), созданные в Sequence diagram. Если при проверке наличия деталей выясняется, что у нас есть детали, то переходим к конечному этапу — «произвести ремонт». А если деталей нет, тогда переходим к этапу заказа и получения деталей.

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

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

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:

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

• точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

• точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

Каждый класс имеет свое название и свои атрибуты и операции, которые впоследствии будут реализованы в программном коде. Если операция имеет какой-либо тип, например, +Записать информацию в БД (Num: int: Zakaz: stirng; Zakazchik: string; Status: boolean): boolean, то в таком случае в программном коде данная операция будет представлена в виде функции указанного типа с параметрами, которые находятся в круглых скобках. Класс «Номер заказа» имеет стереотип «entity» (сущность).

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

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

На данном этапе мы разделил классы на три пакета: «Сущность», «Управление», «Реализация». Каждый пакет непосредственно взаимодействует с другим, так пакет «Сущность» порождает связь с пакетом «Управление», а пакет «Управление в свою очередь» порождает связь с пакетом «Реализация». Классы, находящиеся в пакетах, могут так же между собой взаимодействовать, это наглядно показано на рисунке. Деление на пакеты было произведено по функциональному принципу. В пакет «Сущность» мы поместили 2 класса: «Заявка», «Номер заявки» — так как именно эти классы порождают наш бизнес-процесс и отражают его сущность. В пакет «Управление» мы поместили 3 класса: «Управляющий заказами», «Финансовый директор», «Бухгалтерия», так как эти классы осуществляют управление бизнес-процессом. И, наконец, пакет «Реализация», в него вошли 3 класса: «БД», «Механик», «Поставщик», так как именно в этих классах происходит реализация бизнес-процесса.

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

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

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

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

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

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

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

unified language диаграмма кодогенерация

Кодогенерация на Delphi

Unit СТО_Бизнес;

Interface

Type

Заявка = Class;

Class = Class;

Бухгалтерия = Class;

БД = Class;

Заявка = Class (TObject)

Public Procedure Составление_текста_заявки ();

End;

Class = Class (TObject)

Public Procedure Произвести_осмотр_согласно_заявке ();

End;

Бухгалтерия = Class (TObject)

Public Procedure Произвестит_расчет ();

Public Procedure Получение_квитанции_об_оказанеии_услуг ();

End;

БД = Class (TObject)

Public Procedure Ввод_данных_в_БД ();

Public Procedure Сохранение_данных ();

Public Procedure Создать_новую_запись_в_БД ();

End;

Implementation

Procedure Заявка. Составление_текста_заявки ();

Begin

Raise Exception. Create ('Not yet implemented');

End;

Procedure Class. Произвести_осмотр_согласно_заявке ();

Begin

Raise Exception. Create ('Not yet implemented');

End;

Procedure Бухгалтерия. Произвестит_расчет ();

Begin

Raise Exception. Create ('Not yet implemented');

End;

Procedure Бухгалтерия. Получение_квитанции_об_оказанеии_услуг ();

Begin

Raise Exception. Create ('Not yet implemented');

End;

Procedure БД. Ввод_данных_в_БД ();

Begin

Raise Exception. Create ('Not yet implemented');

End;

Procedure БД. Сохранение_данных ();

Begin

Raise Exception. Create ('Not yet implemented');

End;

Procedure БД. Создать_новую_запись_в_БД ();

Begin

Raise Exception. Create ('Not yet implemented');

End;

End.

Кодогенерация на C#

using System;

public class Class {

public void Произвести_осмотр_согласно_заявке () {

throw new System. Exception («Not implemented»);

}

}

using System;

public class БД {

public void Ввод_данных_в_БД () {

throw new System. Exception («Not implemented»);

}

public void Сохранение_данных () {

throw new System. Exception («Not implemented»);

}

public void Создать_новую_запись_в_БД () {

throw new System. Exception («Not implemented»);

}

}

using System;

public class Бухгалтерия {

public void Произвестит_расчет () {

throw new System. Exception («Not implemented»);

}

public void Получение_квитанции_об_оказанеии_услуг () {

throw new System. Exception («Not implemented»);

}

}

using System;

public class Заявка {

public void Составление_текста_заявки () {

throw new System. Exception («Not implemented»);

}

}