Построение UML-диаграмм

 

СОДЕРЖАНИЕ:

 

1. ЛАБОРАТОРНАЯ РАБОТА №1. Построение UML-диаграмм……….
2. Диаграммы вариантов использования (Usecase Diagram)………………..
3. Диаграммы классов (Class Diagram)……………………………………….
4. Диаграмм взаимодействия (Interaction diagram)…………………………..
5. Диаграммы сотрудничества (Collaboration diagram)………………………
6. Диаграмм состояний (Statechart Diagram)…………………………………
7. Диаграмма развёртывания (Deployment diagram)…………………………
8. Диаграммы видов деятельности(Activity Diagram)………………………

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ЛАБОРАТОРНАЯ  РАБОТА №1. Построение UML-диаграмм

Цель  работы: получить навыки построения UML-диаграмм в среде CASEBERRY.

 

 UML - Uniform (Унифицированный) Modeling (Язык) Language (Моделирования)

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

Терминология:

• Диаграмма - графическое  изображение элементов и связи между ними.

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

• Разработка системы представляет собой процесс её создания для  клиента, т.е челолвека которому необходимо решить какую-то проблему.

Язык UML включает набор графических элементов, используемых на диаграммах. Будучи языком, UML содержит правила для объединения этих элементов.

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

Краткое описание CASEBERRY

Большинство современных  методов объектно-ориентированного проектирования основаны на использовании языка UML.

Унифицированный язык моделирования (UML, Unified Model Language) является приемником языков и методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х. Язык моделирования UML прошел процесс стандартизации в рамках консорциума OMG (Object Management Group) и в настоящее время является стандартом OMG. UML представляет собой универсальный язык для анализа предметных областей, существующих систем, моделирования систем документирования объектных моделей, проектирования программного обеспечения. На UML можно содержательно описывать классы, объекты и компоненты в различных предметных областях, часто сильно отличающихся друг от друга. В процессе разработки система представляется в виде объединения нескольких проекций, каждая из которых описывает определенный аспект разрабатываемой системы, а вместе они определяют систему во всей ее полноте.

Ключевой идеей  технологии CASEBERRY, является поддержка всего жизненного цикла разработки программного обеспечения через единую, от анализа до кода, модель информационной системы, связанную на всех этапах. Непосредственно с моделей в нотации UML автоматизировано создаются заготовки исходных кодов, проработанные до вполне завершённых, включая и пользовательский интерфейс, приложений, которые компилируются и запускаются непосредственно из среды комплекса, что выгодно отличает его от большинства аналогичных CASE - средств.

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

• Инструмент объектно-ориентированного проектирования (средство создания диаграмм);
• Инструменты автоматизированного создания исходного кода систем и баз данных, а также библиотеки для программистов.
• Репозитарий моделей, который имеет чёткую структуру, не ограничивающую, вместе с тем, проектировщика какой-либо одной, предопределённой, методикой. Например, можно создать любое количество систем, конфигураций, стадий и поддерживать жизненный цикл проекта. Репозитарий может быть расширен с целью добавления другой функциональности, а также для генерации исходного кода при помощи механизма надстроек (PlugIn). Разработчикам ПО комплекс помогает решать и автоматизировать множество практических задач, таких, как:
• Создание на уровне кода классов и объектов, соответствующих предметным сущностям и их отношениям;
• ORM (Object-Relational Mapping) - объектно-реляционное отображение, хранение объектных данных в реляционных БД, в том числе объектов наследующихся классов;
• Поддержка различных реляционных СУБД и поддержка источников данных любой другой«природы»;
• Создание пользовательского интерфейса;
• Реализация системной архитектуры: от монолитной до распределённой многоуровневой;

 

 

 

 

 

 

Диаграммы вариантов использования (Usecase Diagram)

Диаграмма прецедентов (англ. use case diagram, диаграмма вариантов использования) в UML — это диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне.

Диаграмма вариантов  использования является самым общим  представлением функциональных требований к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом «сценарием варианта использования» или «потоком событий» (flow of events). Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.

Достоинства модели вариантов использования заключаются в том, что она:

• определяет пользователей  и границы системы;

• определяет системный  интерфейс;

• удобна для  общения пользователей с разработчиками;

• используется для написания тестов;

• является основой  для написания пользовательской документации;

• хорошо вписывается  в любые методы проектирования (как объектно-ориентированные, так и структурные).

 

 

 

 

Основные  элементы диаграмм вариантов использования

 

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

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

Между активным субъектом и вариантом использования устанавливаются связь ассоциация (association relationship), которая выполняет коммуникативную функцию, сообщая о взаимодействии субъекта с системой в рамках определенного варианта использования. Направление связи указывает, кто (субъект или система) является инициатором взаимодействия. Помимо связей между субъектом и вариантом использования, связи могут устанавливаться и между вариантами использования. Связи бывают двух типов - включающими (inclusive) и расширяющими (extensive).

 

 

 

 

 

 

 

 

Порядок построения диаграммы вариантов использования (Usecase Diagram)

 

1. Создаем диаграмму вариантов использования с именем «Основная функциональность»

2. Анализируем какие активные субъекты должны взаимодействовать с будущей системой.

3. Рисуем actor’ов. (Менеджер, Бухгалтер и Кладовщик.)

4. Добавляем следующие прецеденты:

a. Оформление  заказа

b. Оформление  счёта

c. Оформление  накладной

d. Выдача товара

5. Для пояснения используем комментарии.

6. Расставляем стрелки, обозначающие зависимость.

7. Диаграмма имеет следующий вид:

Для отражения  модели прецедентов на диаграмме  используются:

• рамки системы (англ. system boundary) — прямоугольник с названием в верхней части и эллипсами (прецедентами) внутри. Часто может быть опущен без потери полезной информации,
• актёр («эктор») — стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующего с некоторой сущностью (системой, подсистемой, классом). Актёры не могут быть связаны друг с другом (за исключением отношений генерализации/наследования),
• прецедент — эллипс с надписью, обозначающий выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам. Надпись может быть именем или описанием (с точки зрения актёров) того, «что» делает система (а не «как»). Имя прецедента связано с непрерываемым (атомарным) сценарием — конкретной последовательностью действий, иллюстрирующей поведение. В ходе сценария актёры обмениваются с системой сообщениями. Сценарий может быть приведён на диаграмме прецедентов в виде UML-комментария. С одним прецедентом может быть связано несколько различных сценариев.

 

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

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

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

 

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

Основные  элементы диаграммы классов

 

 

 

 

 

 

 

 

 

 

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

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

Операция есть функция или преобразование. Операция может параметризоваться и возвращать значения.

 

 

 Виды связей: ассоциация, агрегация и наследование.

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

 Агрегация (aggregation) – это ассоциация типа «целое-часть». Агрегация в UML представляется виде прямой с ромбом на конце. Ромб на связи указывает, какой класс является агрегирующим (т.е. «состоящим из»), — класс с противоположного конца — агрегированным (т.е. те самые «части»).

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