Введение
UML(сокр. от англ. Unified Modeling Language — унифицированный языкмоделирования) — язык графического описания для объектного моделирования вобласти разработки программного обеспечения. UML является языком широкогопрофиля, это открытый стандарт, использующий графические обозначения длясоздания абстрактной модели системы, называемой UML моделью. UML былсоздан для определения, визуализации, проектирования и документирования восновном программных систем. UML не является языком программирования, но всредствах выполнения UML-моделей как интерпретируемого кода возможнакодогенерация. Использование UML не ограничивается моделированием программногообеспечения. Его также используют для моделирования бизнес-процессов, системногопроектирования и отображения организационных структур.
UML позволяет такжеразработчикам программного обеспечения достигнуть соглашения в графическихобозначениях для представления общих понятий (таких как класс, компонент,обобщение (generalization), объединение (aggregation) и поведение) и большесконцентрироваться на проектировании и архитектуре.
Задание
С помощью UML диаграммописать бизнес-процессы «Химчистки», в визуальной среде Visual Paradigm UML2.0.
UseCase (Варианты использования)
Основная цель созданиялюбой программной системы — создание такого программного продукта, которыйпомогает пользователю выполнять свои повседневные задачи. Для создания такихпрограмм первым делом определяются требования, которым должна удовлетворятьсистема. Однако если дать пользователям написать эти требования на бумаге, точасто можно получить список функций, по которому трудно судить будет ли будущаясистема выполнять свое назначение и сможет ли она облегчить пользователювыполнение его работы вообще. Непонятно какие из выполняемых функций болееважны и для кого.
Для того, чтобы болееточно понять как должна работать система, все чаще используется описаниефункциональности системы через варианты использования (Use Case илипрецеденты). Варианты использования это — описаниепоследовательности действий, которые может осуществлять система в ответ навнешние воздействия пользователей или других программных систем. Вариантыиспользования отражают функциональность системы с точки зрения получениязначимого результата для пользователя, поэтому они точнее позволяют ранжироватьфункции по значимости получаемого результата.
Варианты использованияпредназначены в первую очередь для определения функциональных требований ксистеме и управляют всем процессом разработки. Все основные виды деятельноститакие как анализ, проектирование, тестирование выполняются на основе вариантовиспользования. Во время анализа и проектирования варианты использования позволяютпонять как результаты, которые хочет получить пользователь влияют наархитектуру системы и как должны себя вести компоненты системы, для того чтобыреализовать нужную для пользователя функциональность.
В процессетестирования, описанные ранее варианты использования позволяют проще оценитьточность реализации требований пользователей и позволяют провести пошаговуюпроверку этих требований.
Стратегияиспользования прецедентов при определении требований определяет необходимостьдополнительно к вопросу «что пользователи ждут от системы?» задаватьвопрос «что система должна сделать для конкретного пользователя?».Такой подход позволяет искать функции, которые нужны многим пользователям иисключать те возможности, которые не могут помочь пользователям выполнять своиповседневные задачи.
Составдиаграммы Use Case
Диаграмма вариантовиспользования состоит из актеров, для которых система производитдействие и собственно действия Use Case, которое описывает то,что актер хочет получить от системы. Актер обозначается значком человечка, аUse Case — овалом. Дополнительно в диаграммы могут быть добавлены комментарии.
Отдельный вариантиспользования обозначается на диаграмме эллипсом, внутрикоторого содержится его краткое название или имя в форме глагола с пояснительнымисловами.
Цель вариантаиспользования заключается в том, чтобы определить законченный аспект илифрагмент поведения некоторой сущности без раскрытия её внутренней структуры. Вкачестве такой сущности может выступать система или любой элемент модели,который обладает собственным поведением.
Каждый вариантиспользования соответствует отдельному сервису, который предоставляетмоделируемая сущность по запросу актера, то есть определяет способ примененияэтой сущности. Сервис, который инициализируется по запросу актера, представляетсобой законченную неделимую последовательность действий. Это означает, чтопосле того как система закончит обработку запроса, она должна возвратиться висходное состояние, чтобы быть готовой к выполнению следующих запросов.
Актеры взаимодействуютс системой посредством обмена сообщениями с вариантами использования. Сообщениепредставляет собой запрос актером определенного сервиса системы и получениеэтого сервиса. Это взаимодействие может быть выражено посредством ассоциаций междуотдельными актерами и вариантами использования или классами. Кроме этого, сактерами могут быть связаны интерфейсы, которые определяют, каким образомдругие элементы модели взаимодействуют с этими актерами.
Видывзаимодействий
Между актерами ивариантами использования могут быть различные виды взаимодействия. Основныевиды взаимодействия следующие:
• Простая ассоциация — отражается линией между актером и вариантом использования (без стрелки).Отражает связь актера и варианта использования. На рисунке между актером администратори вариантом использования просматривать заказ.
• Направленная ассоциация — то же что и простая ассоциация, но показывает, что вариант использованияинициализируется актером. Обозначается стрелкой.
• Наследование — показывает,что потомок наследует атрибуты и поведение своего прямого предка. Можетприменяться как для актеров, так для вариантов использования.
• Расширение (extend) — показывает, что вариант использования расширяет базовую последовательностьдействий и вставляет собственную последовательность. При этом в отличие от типаотношений «включение» расширенная последовательность можетосуществляться в зависимости от определенных условий.
Включение — показывает, что вариант использования включается в базовую последовательность ивыполняется всегда (на рисунке не показан).
/>
На данном этапекурсового проектирования мы добавили 5 актеров: «клиент», «администратор»,«бухгалтерия», «рабочий» и «директор». Также добавили 8 действий Use Case:«подача заявки на чистку», «оформление заявки на чистку», «изменение заявки»,«выполнить работу», «выдача квитанций об оплате услуг», «добавить заявку котчету», «обновить отчет за день»,«отклонить заявку на чистку», последнееявляется как раз расширение. На данном рисунке видно, что актерывзаимодействуют с действиями (вариантами использования). Каждый Актер порождаетвзаимодействия. Все взаимодействия представлены на рисунке.
Sequencediagram (диаграмма последовательности)
Диаграммапоследовательности, Sequence diagram — диаграмма, накоторой изображено упорядоченное во времени взаимодействие объектов. Вчастности, на ней изображаются участвующие во взаимодействии объекты ипоследовательность сообщений, которыми они обмениваются.
На диаграммепоследовательности изображаются исключительно те объекты, которыенепосредственно участвуют во взаимодействии и не показываются возможныестатические ассоциации с другими объектами. Для диаграммы последовательностиключевым моментом является именно динамика взаимодействия объектов во времени.При этом диаграмма последовательности имеет как бы два измерения. Одно — слеванаправо в виде вертикальных линий, каждая из которых изображает линию жизниотдельного объекта, участвующего во взаимодействии. Графически каждый объектизображается прямоугольником и располагается в верхней части своей линии жизни.Внутри прямоугольника записываются имя объекта и имя класса, разделенныедвоеточием. При этом вся запись подчеркивается, что является признаком объекта,который, как известно, представляет собой экземпляр класса.
Рассмотрим диаграммувзаимодействия для «Подачи заявки на чистку белья»:
/>
Крайним слева надиаграмме изображен объект (актер) – в нашем проекте это клиент, которыйприносит белье для чистки, он же и является инициатором взаимодействия. Правееизображается следующий объект, который непосредственно взаимодействует с инициатором.Таким образом, все объекты на диаграмме последовательности образуют некоторыйпорядок, определяемый степенью активности этих объектов при взаимодействии другс другом.
Второе измерениедиаграммы последовательности — вертикальная временная ось, направленная сверхувниз (LifeLine). Начальному моменту времени соответствует самая верхняя частьдиаграммы. При этом взаимодействия объектов реализуются посредством сообщений,которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальныхстрелок с именем сообщения и также образуют порядок по времени своеговозникновения. Другими словами, сообщения, расположенные на диаграммепоследовательности выше, инициируются раньше тех, которые расположены ниже. Приэтом масштаб на оси времени не указывается, поскольку диаграммапоследовательности моделирует лишь временную упорядоченность взаимодействийтипа «раньше-позже».
Клиент, придя вхимчистку, прежде чем отдать бельё, он заполняет заявку. На рисунке видно, чтоклиент генерирует сообщение: «Составление текста заявки». Далее объект «Заявка»будет генерировать сообщения и для объекта «Расчет заявки» класса«Бухгалтерия». И так далее для всего процесса подачи заявки. Нужно заметить,что каждый объект является элементом определенного класса, как уже иговорилось, класс обозначается через двоеточие. На ClassDiagramm всоответствующих классах автоматически при генерации сообщения создаютсяоперации и атрибуты, которые в последствии будут созданы при кодогенерации.
Communicationdiagram (диаграмма коммуникаций)
Диаграмма коммуникаций — разновидность диаграммы взаимодействия, показывающая структурную организациюобъектов или ролей, отправляющих и принимающих сообщения. На диаграммеизображаются взаимодействия между частями композитной структуры или ролямикооперации. И диаграммы последовательности, и диаграммы коммуникациипредставляют похожие базовые концепции, но с разных точек зрения. Диаграммыпоследовательности описывают временную последовательность, а коммуникационныедиаграммы — структуры данных, через которые проходит поток сообщений.
Диаграмма коммуникацийпредназначена для представления взаимодействия в контексте внутреннейархитектуры системы и передаваемых сообщений.
Диаграмма коммуникацииимеет вид графа, вершинами которого являются части композитного класса или роливзаимодействия, изображенные в виде прямоугольников. Эти вершины соответствуютлиниям жизни и изображаются в своем структурном контексте. Ребрами графаявляются связи, по которым проходят маршруты коммуникации. Линии жизни могутобмениваться сообщениями, которые изображаются в виде небольших стрелок снекоторым именем, расположенных возле линий связей.
/>
На диаграммепредставлена структура взаимодействий объектов (LifeLine), так же как и надиаграмме последовательности, но только без учета временного фактора. Каждыйобъект является экземпляром соответствующего класса. Например, объект«Управляющий» является экземпляром класса «Управляющий заказами». Инициаторомвзаимодействия объектов является Actor – «Документовед». Наша диаграммакоммуникаций описывает процесс «Оформление заявки». Каждый объект генерирует связь/сообщение(link/massage) другому объекту. Таким образом, они взаимодействуют друг сдругом. Все сообщения будут автоматически добавлены в диаграмму классов вкачестве операций и атрибутов соответствующему классу как показано ниже нарисунке:
/>
StateMachine (диаграмма состояний)
State Machine (автомат)в языке UML представляет собой некоторый формализм для моделирования поведенияэлементов модели и системы в целом. В метамодели UML автомат является пакетом,в котором определено множество понятий, необходимых для представления поведениямоделируемой сущности в виде дискретного пространства с конечным числомсостояний и переходов. С другой стороны, автомат описывает поведение отдельногообъекта в форме последовательности состояний, которые охватывают все этапы егожизненного цикла, начиная от создания объекта и заканчивая его уничтожением. Каждаядиаграмма состояний представляет некоторый автомат.
Основными понятиями,входящими в формализм автомата, являются со стояние и переход. Главное различиемежду ними заключается в том, что длительность нахождения системы в отдельномсостоянии существенно превышает время, которое затрачивается на переход изодного состояния в другое. Предполагается, что в пределе время перехода изодного состояния в другое равно нулю (если дополнительно ничего не сказано).Другими словами, переход объекта из состояния в состояние происходит мгновенно.
/>
На данной диаграммепредставлена модель жизненного цикла состояния «Машина исправная». Модельсостоит из состояний. Состояния связаны между собой переходами. Причемдлительность нахождения системы в определенном состоянии значительно превышаетвремя, которое затрачивается на переход из одного состояния в другое.
ActivityDiagram (Диаграмма деятельности)
В контексте языка UML деятельность(activity) представляет собой совокупность отдельных вычислений, выполняемыхавтоматом, приводящих к некоторому результату или действию (action). Надиаграмме деятельности отображается логика и последовательность переходов отодной деятельности к другой, а внимание аналитика фокусируется на результатах.Результат деятельности может привести к изменению состояния системы иливозвращению некоторого значения.
Состояние действия(action state) является специальным случаем состояния с некоторым входнымдействием и, по крайней мере, одним выходящим из состояния переходом. Этотпереход неявно предполагает, что входное действие уже завершилось. Состояниедействия не может иметь внутренних переходов, поскольку оно являетсяэлементарным. Обычное использование состояния действия заключается вмоделировании одного шага выполнения алгоритма (процедуры) или потокауправления.
Графически состояниедействия изображается прямоугольником с закругленными углами. Внутри этогоизображения записывается выражение действия (action-expression), которое должнобыть уникальным в пределах одной диаграммы деятельности.
Каждая диаграммадеятельности должна иметь единственное начальное и единственное конечноесостояния. Они имеют такие же обозначения, как и на диаграмме состояний. Приэтом каждая деятельность начинается в начальном состоянии и заканчивается вконечном состоянии. Саму диаграмму деятельности принято располагать такимобразом, чтобы действия следовали сверху вниз. В этом случае начальноесостояние будет изображаться в верхней части диаграммы, а конечное в нижней.
Графически ветвление надиаграмме деятельности обозначается небольшим ромбом, внутри которого нетникакого текста. В этот ромб может входить только одна стрелка от тогосостояния действия, после выполнения которого поток управления должен бытьпродолжен по одной из взаимно исключающих ветвей. Принято входящую стрелкуприсоединять к верхней или левой вершине символа ветвления. Выходящих стрелокможет быть две или более, но для каждой из них явно указывается соответствующеесторожевое условие в форме булевского выражения.
В общем случае действияна диаграмме деятельности выполняются над теми или иными объектами.Эти объекты либо инициируют выполнение действий, либо определяют некоторый ихрезультат. Действия специфицируют вызовы, которые передаются от одного объектаграфа деятельности к другому. Поскольку в таком ракурсе объекты играютопределенную роль в понимании процесса деятельности, иногда возникаетнеобходимость явно указать их на диаграмме.
Для графическогопредставления объектов используется прямоугольник класса, с тем отличием, чтоимя объекта подчеркивается. Далее после имени может указываться характеристикасостояния объекта в прямых скобках. Такие прямоугольники объектовприсоединяются к состояниям действия отношением зависимости пунктирной линиейсо стрелкой. Соответствующая зависимость определяет состояние конкретногообъекта после выполнения предшествующего действия.
На диаграммедеятельности с дорожками расположение объекта может иметь некоторыйдополнительный смысл. А именно, если объект расположен на границе двух дорожек,то это может означать, что переход к следующему состоянию действия в соседнейдорожке ассоциирован с готовностью некоторого документа (объект в некоторомсостоянии). Если же объект целиком расположен внутри дорожки, то и состояниеэтого объекта целиком определяется действиями данной дорожки.
Для синхронизацииотдельных действий на диаграмме деятельности никаких дополнительных обозначенийне используется, поскольку синхронизация параллельных процессов может бытьреализована с помощью переходов «разделение-слияние».
В данной работе началодействия обозначает элемент Initial Node, а окончаний может бытьнесколько в нашем случае их будет три, и обозначаются они элементом ActivityFinal Node. На рисунке, видно, что когда механик получает заказ, онпроверяет наличие автомобиля на СТО, а в это же время (параллельно) бухгалтериявыдает квитанцию на оплату. Если операция не оплачена, то механик не производитремонт, если же деньги поступили, механику поступает заявка на ремонт. Он всвою очередь, если свободен, то приступает к работе немедленно, либо, еслизанят, то ставит данную заявку в очередь. Смысл диаграммы сводится к тому,чтобы показать какие процессы происходят параллельно друг другу, и показатькакие варианты исхода могут быть.
Interactionoverview diagram (Диаграмма обзора взаимодействия)
Interaction overviewdiagram – диаграмма, которая предназначена для представлениявзаимодействия только в контексте потока управления в некоторой агрегированнойформе. Диаграммы обзора взаимодействия, вместо узлов действий и объектовдиаграмм деятельности, имеют фреймы, каждый из которых может соответствоватьвзаимодействию или использованию взаимодействия. Альтернативные комбинированныефрагменты представляются узлом решения и соответствующим узлом слияния.Параллельные комбинированные фрагменты представляются узлом разделения исоответствующим узлом соединения. Комбинированные фрагменты типа Циклпредставляются простыми циклами. Ветвление и слияния ветвлений на диаграммахобзора взаимодействия должны быть должным образом вложенными. Диаграммы обзоравзаимодействия заключаются во фрейм, аналогично другим видам диаграмм взаимодействияс тегом sd и ref.
/>
Для создания диаграммывзаимодействия были использованы теги (ref и sd), созданные в Sequence diagram.Если при проверке наличия деталей выясняется, что у нас есть детали, топереходим к конечному этапу – «произвести ремонт». А если деталей нет, тогдапереходим к этапу заказа и получения деталей.
Диаграммаклассов
Диаграмма классов,Class diagram — статическая структурная диаграмма, описывающая структурусистемы, она демонстрирует классы системы, их атрибуты, методы и зависимостимежду классами.
Существуют разные точкизрения на построение диаграмм классов в зависимости от целей их применения:
• концептуальнаяточка зрения — диаграмма классов описывает модель предметной области, в нейприсутствуют только классы прикладных объектов;
• точказрения спецификации — диаграмма классов применяется при проектированииинформационных систем;
• точказрения реализации — диаграмма классов содержит классы, используемыенепосредственно в программном коде (при использовании объектно-ориентированныхязыков программирования).
Каждый класс имеет своеназвание и свои атрибуты и операции, которые впоследствии будут реализованы впрограммном коде. Если операция имеет какой-либо тип, например, +Записатьинформацию в БД(Num: int:Zakaz: stirng; Zakazchik: string; Status: boolean):boolean, то в таком случае в программном коде данная операция будетпредставлена в виде функции указанного типа с параметрами, которые находятся вкруглых скобках. Класс «Номер заказа» имеет стереотип «entity» (сущность).
На рисунке видны связимежду классами. Данные связи были выявлены после просмотра и анализа диаграммпоследовательности, а также на данной диаграмме добавлены множественности. Наоснове диаграммы классов, будет построен фрагмент кода программы, будут проанализированыи выявлены алгоритмы наследия классов. Эти классы непосредственно будутфигурировать в программном коде.
Для более наглядного ипонятного взаимодействия классов между собой, нужно объединить классы в пакеты.Таким образом, мы сгруппируем все наши классы в модули. И при кодогенерациикаждый пакет выведется в отдельный модуль, согласно той группировке, которую мыпроизвели. Диаграммы пакетов служат, в первую очередь, для организацииэлементов в группы по какому-либо признаку с целью упрощения структуры иорганизации работы с моделью нашей системы.
На данном этапе мыразделил классы на три пакета: «Сущность», «Управление», «Реализация». Каждыйпакет непосредственно взаимодействует с другим, так пакет «Сущность» порождаетсвязь с пакетом «Управление», а пакет «Управление в свою очередь» порождаетсвязь с пакетом «Реализация». Классы, находящиеся в пакетах, могут так же междусобой взаимодействовать, это наглядно показано на рисунке. Деление на пакетыбыло произведено по функциональному принципу. В пакет «Сущность» мы поместили 2класса: «Заявка», «Номер заявки» — так как именно эти классы порождают нашбизнес-процесс и отражают его сущность. В пакет «Управление» мы поместили 3класса: «Управляющий заказами», «Финансовый директор», «Бухгалтерия», так какэти классы осуществляют управление бизнес-процессом. И, наконец, пакет«Реализация», в него вошли 3 класса: «БД», «Механик», «Поставщик», так какименно в этих классах происходит реализация бизнес-процесса.
DeploymentDiagram (Диаграмма развертывания)
Диаграмма развертыванияпредназначена для визуализации элементов и компонентов программы, существующихлишь на этапе ее исполнения (runtime). При этом представляются толькокомпонентыэкземпляры программы, являющиеся исполнимыми файлами илидинамическими библиотеками. Те компоненты, которые не используются на этапеисполнения, на диаграмме развертывания не показываются. Так, компоненты сисходными текстами программ могут присутствовать только на диаграммекомпонентов. На диаграмме развертывания они не указываются.
Диаграмма развертываниясодержит графические изображения процессоров, устройств, процессов и связеймежду ними. В отличие от диаграмм логического представления, диаграммаразвертывания является единой для системы в целом, поскольку должна всецело отражатьособенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП дляконкретной программной системы и ее разработка, как правило, является последнимэтапом спецификации модели.
Узел (node)представляет собой некоторый физически существующий элемент системы, обладающийнекоторым вычислительным ресурсом. В качестве вычислительного ресурса узламожет рассматриваться наличие по меньшей мере некоторого объема электронной илимагнитооптической памяти и/или процессора.
Кроме собственноизображений узлов на диаграмме развертывания указываются отношения между ними.В качестве отношений выступают физические соединения между узлами и зависимостимежду узлами и компонентами, изображения которых тоже могут присутствовать надиаграммах развертывания.
Соединения являютсяразновидностью ассоциации и изображаются отрезками линий без стрелок. Наличиетакой линии указывает на необходимость организации физического канала дляобмена информацией между соответствующими узлами.
На нашей диаграммеразвертывания указана зависимость компонента реализации сервера приложения отрабочих станций.
unified language диаграмма кодогенерация
Кодогенерацияна Delphi
UnitСТО_Бизнес;
Interface
Type
Заявка= Class;
Class= Class;
Бухгалтерия= Class;
БД= Class;
Заявка= Class(TObject)
PublicProcedure Составление_текста_заявки();
End;
Class= Class(TObject)
PublicProcedure Произвести_осмотр_согласно_заявке();
End;
Бухгалтерия= Class(TObject)
PublicProcedure Произвестит_расчет();
Public ProcedureПолучение_квитанции_об_оказанеии_услуг();
End;
БД= Class(TObject)
PublicProcedure Ввод_данных_в_БД();
Public ProcedureСохранение_данных();
Public ProcedureСоздать_новую_запись_в_БД();
End;
Implementation
ProcedureЗаявка.Составление_текста_заявки();
Begin
RaiseException.Create('Not yet implemented');
End;
ProcedureClass.Произвести_осмотр_согласно_заявке();
Begin
RaiseException.Create('Not yet implemented');
End;
ProcedureБухгалтерия.Произвестит_расчет();
Begin
RaiseException.Create('Not yet implemented');
End;
ProcedureБухгалтерия.Получение_квитанции_об_оказанеии_услуг();
Begin
RaiseException.Create('Not yet implemented');
End;
ProcedureБД.Ввод_данных_в_БД();
Begin
RaiseException.Create('Not yet implemented');
End;
ProcedureБД.Сохранение_данных();
Begin
RaiseException.Create('Not yet implemented');
End;
ProcedureБД.Создать_новую_запись_в_БД();
Begin
RaiseException.Create('Not yet implemented');
End;
End.
Кодогенерацияна C#
usingSystem;
publicclass Class {
public voidПроизвести_осмотр_согласно_заявке() {
thrownew System.Exception(«Not implemented»);
}
}
usingSystem;
publicclass БД{
public voidВвод_данных_в_БД() {
thrownew System.Exception(«Not implemented»);
}
publicvoid Сохранение_данных(){
thrownew System.Exception(«Not implemented»);
}
public voidСоздать_новую_запись_в_БД() {
thrownew System.Exception(«Not implemented»);
}
}
usingSystem;
publicclass Бухгалтерия{
publicvoid Произвестит_расчет(){
thrownew System.Exception(«Not implemented»);
}
public voidПолучение_квитанции_об_оказанеии_услуг() {
thrownew System.Exception(«Not implemented»);
}
}
usingSystem;
publicclass Заявка{
public voidСоставление_текста_заявки() {
thrownew System.Exception(«Not implemented»);
}
}