Различия между композицией и агрегацией

Вариант использования (use case)

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

· каждый вариант использования относится как минимум к одному действующему лицу,

· каждый вариант использования имеет инициатора,

· каждый вариант использования приводит к соответствующему результату (результату с «бизнес-значением»).

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

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

В данном примере вариант использования Part включается в вариант использования Base.

· Добавление указывает, что в определённых ситуациях или в некоторой точке (называемой точкой расширения) вариант использования будет расширен другим.

В данном примере вариант использования Base расширяется вариантом использования Another.

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

В данном примере вариант использования Child обобщает вариант использования Base.

Действующее лицо (actor)

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

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

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

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

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

Описание варианта использования

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

Диагра́мма де́ятельности (англ. activity diagram) — UML-диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. Action), соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.

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

Диаграммы деятельности состоят из ограниченного количества фигур, соединённых стрелками. Основные фигуры:

1. Прямоугольники с закруглениями — действия

2. Ромбы — решения

3. Широкие полосы — начало (разветвление) и окончание (схождение) ветвления действий

4. Чёрный круг — начало процесса (начальное состояние)

5. Чёрный круг с обводкой — окончание процесса (конечное состояние)

Стрелки идут от начала к концу процесса и показывают последовательность переходов.

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

Удобное средство для обозначения очередности следования друг за другом различных стимулов (сообщений), с помощью которых объекты взаимодействуют между собой.
Например, когда нужно проработать буквально по шагам какой-то очень важный участок выполнения программы.
Главный акцент - порядокидинамика поведения, т.е. как и в каком порядке происходят события.
Отличие от диаграммы классов:
Диаграмма классов дает статическую картинку, т.е. описание которое не меняется во время выполнения программы.
Отличие от диаграммы коммуникаций (или как она раньше называлась colaboration):
Диаграмма последовательности фокусирует наше внимание на очередности выполнения по времени, а диаграмма коммуникаций - на составляющих элементах.
Обычно нормальные люди стараются описывать одной диаграммой только один определенный кейс (UseCase, вариант использования), например: "оставить коммент к сообщению в блоге", "стать постоянным читателем" и т.д...
Диаграммы последовательности, которые описывают всю системусразу, представляют из себя монстра,пожирающего внимание, сознание, силы, время и мозг разработчика.

Итак, предлагаю рассмотреть простенькую диаграмму последовательности.
Возьмем банальный пример:

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

1. Объект, Участник (Object, Participant)
Обозначается прямоугольником, в котором указывается информация об участнике действий. Это, как правило, название объекта и его класс, разделенные двоеточием.
Например: saveButton или saveButton:JButtonили:JButton
Т.е. по большому счету, название класса можно опустить или наоборот не указывать название объекта, но что-то одно из двух (объект или класс) следует указать, а то останется нечто совсем анонимное.

В старой нотации (до UML 2.0) требовалось еще и подчеркивать.
Приблизительно вот так: oldButton:JButton
Располагаются объекты (как правило) вдоль верхнего края диаграммы. От прямоугольника вниз спускается Линия Жизни.

2. Линия жизни (Life Line)
Линия, идущая вниз от участника, обозначающая отведенное объекту время жизни. Обозначается пунктирной линией.

3. Активация, фрагмент выполнения (Activation Bar, Execution Occurances)
Обозначается узким прямоугольником (серого или белого цвета), расположенным на линии жизни. Указывает начало и завершение действия, в котором участвует объект. Поскольку линия жизни - это метафора времени, то прямоугольник на линии жизни указывает на активизацию объекта во времени.

4. Сообщение, Стимул (Message, Stimulus)
Стрелка от одной жизни к другой. Показывает взаимодействие объектов.
Очень легко запомнить так: Стимул - это латинское слово, древние римляне так называли заостренную палку, которой гнали скот. Так вот, стимул в UML обозначается такой острой палкой.
Стимулы бывают разные, отличаются наконечником.
Синхронное сообщение обозначается закрашенной стрелкой, асинхронное - незакрашенной.
В нотации до 2.0, асинхронные сообщения обозначались "спиленным" снизу наконечником стрелки.
Возврат показывается пунктирной стрелкой, в обратном направлении.

5.Уничтожение объекта
Обозначается диагональным крестом на линии жизни. Обозначает конец жизни объекта.

Диаграмма классов (англ. Static Structure diagram) — диаграмма, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи между ними. Входит в UML.

Существует два вида:

· Статический вид диаграммы рассматривает логические взаимосвязи классов между собой;

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

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

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

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

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

Взаимосвязи

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

Ассоциации

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

Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. Вполне допустимы случаи, когда оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса позволительно связать другие объекты из того же класса. Ассоциация, связывающая два класса, называется бинарной. Можно, хотя это редко бывает необходимым, создавать ассоциации, связывающие сразу несколько классов; они называются n-арными. Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами.

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

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

Часто при моделировании бывает важно указать, сколько объектов может быть связано посредством одного экземпляра ассоциации. Это число называется кратностью (Multiplicity) роли ассоциации и записывается либо как выражение, значением которого является диапазон значений, либо в явном виде. Указывая кратность на одном конце ассоциации, вы тем самым говорите, что на этом конце именно столько объектов должно соответствовать каждому объекту на противоположном конце. Кратность можно задать равной единице (1), можно указать диапазон: "ноль или единица" (0..1), "много" (0..*), "единица или больше" (1..*). Разрешается также указывать определенное число (например, 3). С помощью списка можно задать и более сложные кратности, например 0 . . 1, 3..4, 6..*, что означает "любое число объектов, кроме 2 и 5".

Агрегация

Диаграмма классов, показывающая Агрегацию между двумя классами

Агрегация. Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием; оно причислено к отношениям типа "имеет" (с учетом того, что объект-целое имеет несколько объектов-частей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с незакрашенным ромбом со стороны "целого".

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

Композиция

Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.

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

Графически представляется как и агрегация, но с закрашенным ромбиком.

Различия между композицией и агрегацией

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

Обобщение (наследование)

Диаграмма классов, показывающая наследование двух подклассов от одного суперкласса

Обобщение (Generalization) показывает, что один из двух связанных классов (подтип) является частной формой другого (надтипа), который называется обобщением первого. На практике это означает, что любой экземпляр подтипа является также экземпляром надтипа. Например: животные — супертип млекопитающих, которые, в свою очередь, — супертип приматов, и так далее. Эта взаимосвязь легче всего описывается фразой «А — это Б» (приматы — это млекопитающие, млекопитающие — это животные).

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

Обобщение также известно как наследование или «is a» взаимосвязь (или отношение "является").

Реализация

Реализация — отношение между двумя элементами модели, в котором один элемент (клиент) реализует поведение, заданное другим (поставщиком). Реализация — отношение целое-часть. Графически реализация представляется так же, как и наследование, но с пунктирной линией.

Зависимость

Зависимость (dependency) — это слабая форма отношения использования, при котором изменение в спецификации одного влечёт за собой изменение другого, причём обратное не обязательно. Возникает, когда объект выступает, например, в форме параметра или локальной переменной.

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

Существует несколько именованных вариантов.

Зависимость может быть между экземплярами, классами или экземпляром и классом.

Уточнения отношений

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

Мощность отношений (Кратность)!

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

Dfd

Не нашли, что искали? Воспользуйтесь поиском по сайту: