Как составить диаграмму объектов

Диаграммы объектов являются производными от диаграмм классов, поэтому диаграммы объектов зависят от диаграмм классов.

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

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

Назначение объектных диаграмм

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

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

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

Назначение диаграммы объекта можно обобщить как –

• Прямая и обратная инженерия.

• Объектные отношения системы

• Статический вид взаимодействия.

• Понять поведение объектов и их взаимосвязь с практической точки зрения.

Прямая и обратная инженерия.

Объектные отношения системы

Статический вид взаимодействия.

Понять поведение объектов и их взаимосвязь с практической точки зрения.

Как нарисовать диаграмму объекта?

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

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

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

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

• Сначала проанализируйте систему и решите, какие экземпляры имеют важные данные и связь.

• Во-вторых, рассмотрим только те экземпляры, которые будут охватывать функциональность.

• В-третьих, проведите некоторую оптимизацию, поскольку количество экземпляров не ограничено.

Сначала проанализируйте систему и решите, какие экземпляры имеют важные данные и связь.

Во-вторых, рассмотрим только те экземпляры, которые будут охватывать функциональность.

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

Перед тем, как нарисовать диаграмму объекта, необходимо запомнить и понять следующие вещи:

• Диаграммы объектов состоят из объектов.

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

• Объекты и ссылки – это два элемента, используемые для построения диаграммы объекта.

Диаграммы объектов состоят из объектов.

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

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

После этого перед началом построения диаграммы необходимо решить следующие вопросы:

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

• Наиболее важные элементы должны быть определены.

• Связь между объектами должна быть уточнена.

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

• Добавьте правильные примечания в точках, где требуется больше ясности.

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

Наиболее важные элементы должны быть определены.

Связь между объектами должна быть уточнена.

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

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

Следующая диаграмма является примером диаграммы объекта. Он представляет собой систему управления заказами, которую мы обсудили в главе «Диаграмма классов». Следующая диаграмма представляет собой экземпляр системы в конкретный момент покупки. Он имеет следующие объекты.

• Покупатель

• порядок

• Особое распоряжение

• NormalOrder

Покупатель

порядок

Особое распоряжение

NormalOrder

Теперь объект клиента (C) связан с тремя объектами заказа (O1, O2 и O3). Эти объекты порядка связаны с объектами особого порядка и нормального порядка (S1, S2 и N1). У покупателя есть три следующих заказа с разными номерами (12, 32 и 40) на определенное время.

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

Для заказов значения 12, 32 и 40, что означает, что объекты имеют эти значения для определенного момента (здесь конкретное время, когда совершается покупка, рассматривается как момент), когда экземпляр захвачен

То же самое верно для объектов специального заказа и обычного заказа, у которых количество заказов равно 20, 30 и 60. Если рассматривается другое время покупки, то эти значения будут соответственно изменены.

Следующая диаграмма объекта была составлена ​​с учетом всех точек, упомянутых выше

Где использовать объектные диаграммы?

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

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

• Определенное состояние, которое работает.

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

Определенное состояние, которое работает.

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

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

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

Создание прототипа системы.

Обратный инжиниринг.

Моделирование сложных структур данных.

Понимание системы с практической точки зрения.

Для чего используется техника креативности

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

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

План действий

В разделе «Описание» изучите основной набор символов диаграммы последовательности, необходимый для того, чтобы уметь читать диаграммы.

После ознакомления с другими разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм последовательности.

Как применять технику креативности

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

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

Как научиться

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

Мы рекомендуем перед тем как приступать к изучению диаграммы объектов сначала изучить диаграмму классов. Затем можете перейти в раздел «Пример диграммы объектов», чтобы попробовать свои силы в чтении разных диаграмм этого типа. Затем стоит изучить раздел «Применение», так как, хотя и количество типов диаграмм в UML невелико, максимум преимуществ от их использования вы сможете получить только если будете применять соответствующие диаграммы по назначению.

Пример использования

Диаграмма объектов (object diagram) UML – это снимок объектов системы в какой то момент времени. Поскольку она показывает экземпляры, а не классы, то диаграмму объектов часто азывают диаграммой экземпляров.

Диаграмму объектов можно использовать для отображения одного из вариантов конфигурации объектов. (На рис. 6.1 показано множество классов, а на рис. 6.2 представлено множество связанных объектов.)

Последний вариант очень полезен, когда допустимые связи между объектами могут быть сложными.
Можно определить, что элементы, показанные на рис. 6.2, являются экземплярами, поскольку их имена подчеркнуты. Каждое имя представляется в виде: имя экземпляра : имя класса. Обе части имени не являются обязательными, поэтому имена John, :Person и aPerson являются допустимыми. Если указано только имя класса, то необходимо поставить двоеточие. Можно также задать значения и атрибуты, как показано на рис. 6.2.

Строго говоря, элементы диаграммы объектов – это спецификации экземпляров, а не сами экземпляры. Причина в том, что разрешается оставлять обязательные атрибуты пустыми или показывать спецификации экземпляров абстрактных классов. Можно рассматривать спецификации экземпляров (instance specifications) как частично определенные экземпляры.

С другой стороны, диаграмму объектов UML (ЮМЛ) можно считать коммуникационной диаграммой без сообщений.

Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.

Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс «Как зарабатывать на фрилансе».

Перейти на страницу курса

Время на прочтение
7 мин

Количество просмотров 511

Хабр, привет!
Меня зовут Витя, я работаю системным аналитиком, а также пишу про системный анализ у себя в Telegram канале, сегодня хочу рассказать про такой обязательный навык аналитиков, как проектирование процессов. Думаю, что каждый, кто будет работать на позиции системного/бизнес аналитика, рано или поздно столкнется с такой задачей.

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

• Что такое UML и зачем его нужно использовать

• Какие типы диаграмм существуют в UML

• Подробно узнаете как моделировать процессы с помощью диаграммы классов

Что такое UML ?

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

А зачем нам UML ? Может придумаем свой язык моделирования ?

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

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

А что, если у нас не один разработчик, а 10 ? Или 100 ?

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

Плюсы UML:

• Упрощает сложности при разработке ПО

• Автоматизирует производство программного обеспечения и процессов  

• Помогает решить постоянные проблемы с архитектурой 

• Улучшает качество работы 

• Сокращает затраты и время выхода на рынок 

Минусы UML:

• трата времени на составление диаграмм

• необходимо знать различные диаграммы и их нотации

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

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

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

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

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

• Диаграмма составной структуры

• Диаграмма развертывания

• Диаграмма пакетов

• Диаграмма профилей

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

• Диаграмма объектов

• Диаграмма компонентов

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

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

• Диаграмма прецедентов

• Диаграмма состояний

• Диаграмма последовательности

• Диаграмма коммуникаций

• Диаграмма обзора взаимодействия

• Временная диаграмма

Ниже на рисунке приведена иллюстрация структуры языка UML:

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

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

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

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

Свойства

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

Атрибуты

Атрибут описывает свойство в виде строки текста внутри прямоугольника класса.
Полная форма атрибута:
видимость имя: тип кратность = значение по умолчанию {строка свойств}

Например:
имя: String [1] = "Без имени" {readOnly}

Обязательно указывать только имя.

Рассмотрим основные сущности атрибута :

• Метка видимость обозначает, относится ли атрибут к открытым (+) (public) или к закрытым ( ) (private).

• Имя атрибута – способ ссылки класса на атрибут – приблизительно соответствует имени поля в языке программирования.

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

• Кратность — данное понятие будет рассмотрено ниже.

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

• Элемент {строка свойств} позволяет указывать дополнительные свойства атрибута. В примере он равен {readOnly}, то есть клиенты не могут изменять атрибут. Если он пропущен, то, как правило, атрибут можно модифицировать.

Ассоциации

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

Ассоциация – это непрерывная линия между двумя классами, направленная от исходного класса к целевому классу. Имя свойства (вместес кратностью) располагается на целевом конце ассоциации. Целевой конец ассоциации указывает на класс, который является типом свойства.

Естественно, возникает вопрос: «Когда следует выбирать то или иное представление?». Как правило, при помощи атрибутов обозначают небольшие элементы, такие как даты или логические значения, а ассоциации для более значимых классов, таких как клиенты или заказы.

Двунаправленные ассоциации

Двунаправленная ассоциация – это пара свойств, связанных в противоположных направлениях. Класс Car (Автомобиль) имеет свойство owner:Person[1], а класс Person (Личность) имеет свойство cars:Car[*].

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

Кратность

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

• 1 (Заказ может представить только один клиент)

• 0..1 (Корпоративный клиент может иметь, а может и не иметь единственного торгового представителя.)

• * (Клиент не обязан размещать заказ, и количество заказов не ограничено. Он может разместить ноль или более заказов.)

Операции

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

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

видимость имя (список параметров) : возвращаемый тип {строка свойств}

Рассмотрим основные сущности операции:

• Метка видимости, как и в атрибутах, обозначает, относится ли операция к открытым (+)(public) или к закрытым ( ) (private)

• Имя – это название операции.

• Список параметров – список параметров операции.

• Возвращаемый тип – тип возвращаемого значения, если таковое есть.

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

Например, в счете операция может выглядеть так:

+ balanceOn (date: Date) : Money

Обобщение

Обобщение объединяет несколько подклассов в один класс. Так, в нашем примере обобщение объединяет индивидуального и корпоративного клиентов некоторой бизнес системы. Несмотря на определенные различия, у них много общего. Одинаковые свойства можно поместить в базовый класс Customer (Клиент), при этом класс Personal Customer (Индивидуальный клиент) и класс Corporate Customer (Корпоративный клиент) будут выступать как подтипы.

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

Примечания и комментарии

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

Советы применения диаграммы классов

Итак, мы рассмотрели основные диаграммы UML и подробно диаграмму классов. Хочу закончить мою первую статью цитатами из книги Мартина Фаулера «Основы UML». В главе про моделировании процессов с помощью диаграммы классов Мартин даёт следующие советы:

1. Не пытайтесь задействовать сразу все доступные понятия. Начните с самых простых, описанных в этой главе: классов, ассоциаций, атрибутов, обобщений и ограничений.

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

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

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

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

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

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

Класс (class) — категория вещей, которые имеют общие атрибуты и операции.

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

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

Диаграмма классов — это набор статических, декларативных элементов модели. Диаграммы классов могут применяться и при прямом проектировании, то есть в процессе разработки новой системы, и при обратном проектировании — описании существующих и используемых систем. Информация с диаграммы классов напрямую отображается в исходный код приложения — в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++). Таким образом, диаграмма классов — конечный результат проектирования и отправная точка процесса разработки.

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

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

Рассмотрим еще пример (рис. 2.6):

И опять-таки смысл этой диаграммы ясен без особых пояснений. Даже бегло рассмотрев ее, можно легко догадаться, что она описывает предметную область задачи об автоматизации работы некоего вуза или учебного центра. Обратите внимание на обозначения кратности на концах связей. А теперь немного усложним задачу (рис. 2.7):

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

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

Диаграмма объектов (object diagram)

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

Объект (object) — экземпляр класса.

Zicom Mentor «говорит» об объектах более обстоятельно:

Объект (object) —

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

«Второе» определение, по сути, просто расширяет «Бучевское». Да, действительно, объект — это экземпляр класса. Скажем, объектом класса «Микроволновая печь» из примера, приведенного выше, может быть и простейший прибор фирмы «Saturn» небольшой емкости и с механическим управлением, и навороченный агрегат с грилем, сенсорным управлением и системой трехмерного распределения энергии от Samsung или LG.

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

Как же обозначается объект в UML? А очень просто — объект, как и класс, обозначается прямоугольником, но его имя подчеркивается. Под словом имя здесь мы понимаем название объекта и наименование его класса, разделенные двоеточием. Для указания значений атрибутов объекта в его обозначении может быть предусмотрена специальная секция. Еще один нюанс состоит в том, что объект может быть анонимным: это нужно в том случае, если в данный момент не важно, какой именно объект данного класса принимает участие во взаимодействии. Примеры — на рис. 2.8.

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

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

Приведем простейший пример такой диаграммы (рис. 2.9).

О чем здесь идет речь, в принципе, понятно: некоторая фирма «раскручивает» новый товар или услугу. В этом процессе участвуют вице-президент по маркетингу, вице-президент по продажам, менеджер по продажам, торговый агент, специалист по рекламе, некое печатное издание и покупатель. Причем даже без указания сообщений, которыми обмениваются эти объекты, отлично видно, кто с кем взаимодействует. Кстати, обратите внимание, что на этой диаграмме все объекты анонимные!

Другой пример (рис. 2.10).

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

И наконец, последний пример (рис. 2.11): диаграмма объектов учебной среды «Робот» для Turbo Pascal, в которой наше поколение школьников училось основам алгоритмизации.

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

An Object Diagram can be referred to as a screenshot of the instances in a system and the relationship that exists between them. Since object diagrams depict behaviour when objects have been instantiated, we are able to study the behavior of the system at a particular instant. Object diagrams are vital to portray and understand functional requirements of a system.
In other words, “An object diagram in the Unified Modeling Language (UML), is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time.”

Difference between an Object and a Class Diagram –
An object diagram is similar to a class diagram except it shows the instances of classes in the system. We depict actual classifiers and their relationships making the use of class diagrams. On the other hand, an Object Diagram represents specific instances of classes and relationships between them at a point of time.

What is a classifier?

In UML a classifier refers to a group of elements that have some common features like methods, attributes and operations. A classifier can be thought of as an abstract metaclass which draws a boundary for a group of instances having common static and dynamic features. For example, we refer a class, an object, a component, or a deployment node as classifiers in UML since they define a common set of properties.

An Object Diagram is a structural diagram which uses notation similar to that of class diagrams. We are able to design object diagrams by instantiating classifiers.

Object Diagrams use real world examples to depict the nature and structure of the system at a particular point in time. Since we are able to use data available within objects, Object diagrams provide a clearer view of the relationships that exist between objects.

Figure – a class and its corresponding object

Notations Used in Object Diagrams –

1. Objects or Instance specifications – When we instantiate a classifier in a system, the object we create represents an entity which exists in the system.We can represent the changes in object over time by creating multiple instance specifications. We use a rectangle to represent an object in an Object Diagram. An object is generally linked to other objects in an object diagram.

   
   Figure – notation for an Object

   For example – In the figure below, two objects of class Student are linked to an object of class College.

   
   Figure – an object diagram using a link and 3 objects

2. Links – We use a link to represent a relationship between two objects.

   
   Figure – notation for a link

   We represent the number of participants on the link for each end of the link. We use the term association for a relationship between two classifiers. The term link is used to specify a relationship between two instance specifications or objects. We use a solid line to represent a link between two objects.

   Notation	Meaning
   0..1	Zero or one
   1	One only
   0..*	Zero or more
   *	Zero or more
   1..*	One or more
   7	Seven only
   0..2	Zero or two
   4..7	Four to seven

3. Dependency Relationships – We use a dependency relationship to show when one element depends on another element.

   
   Figure – notation for dependency relationship

   Class diagrams, component diagrams, deployment and object diagrams use dependency relationships. A dependency is used to depict the relationship between dependent and independent entities in the system.Any change in the definition or structure of one element may cause changes to the other. This is a unidirectional kind of relationship between two objects.
   Dependency relationships are of various types specified with keywords (sometimes within angular brackets”).

   Abstraction,Binding, Realization, Substitution and Usage are the types of dependency relationships used in UML.
   For example – In the figure below, an object of Player class is dependent (or uses) an object of Bat class.

   
   Figure – an object diagram using a dependency relationship

4. Association – Association is a reference relationship between two objects (or classes).

   
   Figure – notation for association

   Whenever an object uses another it is called an association.We use association when one object references members of the other object. Association can be uni-directional or bi-directional. We use an arrow to represent association.
   For example – The object of Order class is associated with an object of Customer class.

   
   Figure – an object diagram using association

5. Aggregation – Aggregation represents a “has a” relationship.

   
   Figure – notation for aggregation

   Aggregation is a specific form of association.on relationship; aggregation is more specific than ordinary association. It is an association that represents a part-whole or part-of relationship. It is a kind of parent -child relationship however it isn’t inheritance. Aggregation occurs when the lifecycle of the contained objects does not strongly depend on the lifecycle of container objects.

   
   Figure – an object diagram using aggregation

   For example – A library has an aggregation relationship with books. Library has books or books are a part of library. The existence of books is independent of the existence of the library.While implementing, there isn’t a lot of difference between aggregation and association. We use a hollow diamond on the containing object with a line which joins it to the contained object.

6. Composition – Composition is a type of association where the child cannot exist independent of the other.

   
   Figure – notation for composition

   Composition is also a special type of association. It is also a kind of parent child relationship but it is not inheritance. Consider the example of a boy Gurkaran: Gurkaran is composed of legs and arms. Here Gurkaran has a composition relationship with his legs and arms. Here legs and arms cant exist without the existence of their parent object. So whenever independent existence of the child is not possible we use a composition relationship. We use a filled diamond on the containing object with a line which joins it to the contained object.

   
   Figure – an object diagram using composition

   For Example – In the figure below, consider the object Bank1. Here an account cannot exist without the existence of a bank.

   
   Figure – a bank is composed of accounts

Difference between Association and Dependency –

Association and dependency are often confused in their usage. A source of confusion was the use of transient links in UML 1. Meta-models are now handled differently in UML 2 and the issue has been resolved.

There are a large number of dependencies in a system. We only represent the ones which are essential to convey for understanding the system. We need to understand that every association implies a dependency itself. We , however, prefer not to draw it separately. An association implies a dependency similar to a way in which generalization does.

How to draw an Object Diagram?

1. Draw all the necessary class diagrams for the system.
2. Identify the crucial points in time where a system snapshot is needed.
3. Identify the objects which cover crucial functionality of the system.
4. Identify the relationship between objects drawn.

Uses of an Object Diagram –

• Model the static design(similar to class diagrams ) or structure of a system using prototypical instances and real data.
• Helps us to understand the functionalities that the system should deliver to the users.
• Understand relationships between objects.
• Visualise, document, construct and design a static frame showing instances of objects and their relationships in the dynamic story of life of a system.
• Verify the class diagrams for completeness and accuracy by using Object Diagrams as specific test cases.
• Discover facts and dependencies between specific instances and depicting specific examples of classifiers.

This article is contributed by Ankit Jain . If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.

Last Updated :
13 Feb, 2018

Like Article

Save Article