10669

Моделирование структуры системы (Диаграмма классов)

Практическая работа

Информатика, кибернетика и программирование

Практическая работа №2 Моделирование структуры системы Диаграмма классов Цель работы: изучение диаграммы классов ее основных элементов классов атрибутов операций обязанностей. Изучение отношений между элементами углубленное изучение отношения ассоциации имя...

Русский

2013-03-30

776.5 KB

41 чел.

Практическая работа №2

Моделирование структуры системы (Диаграмма классов)

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

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

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

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

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

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

Рисунок 3.1 - Графическое изображение класса в UML

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

Операцией называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на поведение. Иными словами, операция - это абстракция того, что позволено делать с объектом. У всех объектов класса имеется общий набор операций. Класс может содержать любое число операций или не содержать их вовсе. Часто (хотя не всегда) обращение к операции объекта изменяет его состояние или его данные. Операции класса изображаются в разделе, расположенном ниже раздела с атрибутами.

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

Организация атрибутов и операций

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

Обязанности (Responsibilities) класса - это своего рода контракт, которому он должен подчиняться. Определяя класс, вы постулируете, что все его объекты имеют однотипное состояние и ведут себя одинаково. Выражаясь абстрактно, соответствующие атрибуты и операции как раз и являются теми свойствами, посредством которых выполняются обязанности класса. Например, класс FraudAgent (Агент ПоПредотвращению Мошенничества), который встречается в приложениях по обработке кредитных карточек, отвечает за оценку платежных требований - законные ли они, подозрительные или подложные. Класс TemperatureSensor (ДатчикТемпературы) отвечает за измерение температуры и подачу сигнала тревоги в случае превышения заданного уровня.

Графически обязанности изображают в особом разделе в нижней части пиктограммы класса (рисунок 3.2). Их можно указать также в примечании.


Рисунок 3.2 - Графическое изображение обязанностей

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

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

Словарь системы

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

Моделирование словаря системы включает в себя следующие этапы:

  1.  Определите, какие элементы пользователи и разработчики применяют для описания задачи или ее решения. Для отыскания правильных абстракций используйте CRC-карточки и анализ прецедентов.
  2.  Выявите для каждой абстракции соответствующее ей множество обязанностей. Проследите, чтобы каждый класс был четко определен, а распределение обязанностей между ними хорошо сбалансировано.
  3.  Разработайте атрибуты и операции, необходимые для выполнения класса ми своих обязанностей.

На рисунке 3.3 показан набор классов для системы розничной торговли: Customer (Клиент), Order (Заказ) и Product (Товар). Представлено несколько соотнесенных с ними абстракций, взятых из словаря проблемной области: Shipment (Отгрузка), Invoice (Накладная) и Warehouse (Склад). Одна абстракция, а именно Transaction (Транзакция), применяемая к заказам и отгрузкам, связана с технологией решения задачи.


Рисунок 3.3 - Моделирование словаря системы

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

Распределение обязанностей в системе

Если в ваш проект входит нечто большее, нежели пара несложных классов, предстоит позаботиться о сбалансированном распределении обязанностей. Это значит, что надо избегать слишком больших или, наоборот, чересчур маленьких классов. Каждый класс должен хорошо делать что-то одно. Если ваши абстрактные классы слишком велики, то модель будет трудно модифицировать и повторно использовать. Если же они слишком малы, то придется иметь дело с таким большим количеством абстракций, что ни понять, ни управлять ими будет невозможно. Язык UML способен помочь в визуализации и специфицировании баланса обязанностей.

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

  1.  Идентифицируйте совокупность классов, совместно отвечающих за некоторое поведение.
  2.  Определите обязанности каждого класса.
  3.  Взгляните на полученные классы как на единое целое и разбейте те из них, у которых слишком много обязанностей, на меньшие - и наоборот, крошечные классы с элементарными обязанностями объедините в более крупные.
  4.  Перераспределите обязанности так, чтобы каждая абстракция стала в разумной степени автономной.
  5.  Рассмотрите, как классы кооперируются друг с другом, и перераспределите обязанности с таким расчетом, чтобы ни один класс в рамках кооперации не делал слишком много или слишком мало.

В качестве примера на рисунке 3.4 показано распределение обязанностей между классами Model (Модель), View (Вид) и Controller (Контроллер) из совокупности классов языка Smalltalk. Как видите, их совместная работа организована так, что ни одному из классов не приходится делать слишком мало или слишком много.


Рисунок 3.4 - Моделирование распределения обязанностей в системе

Непрограммные сущности

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

Моделирование непрограммных сущностей производится следующим образом:

  1.  Смоделируйте сущности, абстрагируемые в виде классов.
  2.  Если вы хотите отличить эти сущности от предопределенных строительных блоков UML, создайте с помощью стереотипов (см. главу 6) новый строи тельный блок, опишите его семантику и сопоставьте с ним ясный визуальный образ.
  3.  Если моделируемый элемент является аппаратным средством с собственным программным обеспечением, рассмотрите возможность смоделировать его в виде узла, которая позволила бы в дальнейшем рас ширить его структуру.

Как видно из рисунка 3.5, абстрагирование людей (Accounts Receivable Agent –Агент По Дебиторской Задолженности) и аппаратуры (Robot) в виде классов вполне естественно, поскольку они представляют собой множества объектов с общей структурой и поведением. Сущности, внешние по отношению к системе, часто моделируются как актеры.


Рисунок 3.5 - Моделирование непрограммных сущностей

Примитивные типы

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

Советы

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

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

Изображая класс в UML, придерживайтесь следующих правил:

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

Моделируя систему, необходимо  не только идентифицировать сущности, составляющие ее словарь, но и описать, как они соотносятся друг с другом.

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

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


Рисунок 3.6-
 Графическое изображение имен ассоциаций

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

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


Рисунок 3.7 – Изображение ролей и кратности ассоциации

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

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

Примечание: С помощью списка можно задать и более сложные кратности, например 0 . . 1, 3..4, 6..*, что означает "любое число объектов, кроме 2 и 5". 

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


Рисунок 3.8
- Графическое изображение агрегирования

Примечание: Незакрашенный ромб отличает "целое" от "части" - и только. Эта простая форма агрегирования является чисто концептуальной; она не влияет на результат навигации по ассоциации между целым и его частями и не подразумевает наличия между ними какой-либо зависимости по времени жизни. 

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

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


Рисунок 3.9
- Графическое изображение навигации

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

Видимость. При наличии ассоциации между классами объекты одного класса могут "видеть" объекты другого и осуществлять навигацию к ним, если это не запрещено явным указанием односторонней навигации. Но иногда бывает необходимо ограничить видимость объектов, связанных ассоциацией, для объектов, внешних по отношению к ней. Например, как показано на рисунке 3.10, между объектами UserGroup (группа пользователей) и User существует одна ассоциация, а другая - между объектами User и Password. Зная пользователя, можно найти его пароль, но эта информация принадлежит пользователю и не должна быть доступна извне (если, конечно, объект User явно не даст доступ к объекту Password, возможно посредством открытой операции). Поэтому, как явствует из рисунка, можно осуществлять навигацию от объекта UserGroup к входящим в нее объектам User и обратно, но из объекта UserGroup нельзя видеть объекты Password, принадлежащие отдельным объектам User.


Рисунок 3.10
- Графическое изображение видимости ассоциаций

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

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

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

Это означает, что в случае композитного агрегирования объект в любой момент времени может быть частью только одного композита. Например, в оконной системе класс Frame (Рама) принадлежит только одному классу Window (Окно), тогда как при простом агрегировании "часть" может принадлежать одновременно нескольким "целым". Скажем, в модели дома объект Стена может принадлежать нескольким объектам Комната.

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

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


Рисунок 3.11
- Графическое изображение композиции

Другие свойства

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

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

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

Например, на рисунке 3.12 показано несколько классов, взятых из системы, управляющей распределением студентов и преподавателей на университетских курсах. Зависимость направлена от класса РасписаниеЗанятий к классу Курс, поскольку последний используется в операциях add и remove класса РасписаниеЗанятий.


Рисунок 3.12
- Графическое изображение отношения зависимости

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

Одиночное наследование

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

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

На рис. 3.13 вы видите несколько классов, взятых из приложения по организации работы трейдеров. Здесь показано отношение обобщения, которое от четырех классов - РасчетныйСчет, Акция, Облигация и Собственность - направлено к более общему классу ЦенныеБумаги. Он является родителем, а остальные -его потомками. Каждый специализированный класс - это частный случай класса ЦенныеБумаги. Обратите внимание, что в классе ЦенныеБумаги есть две операции - presentValue (текущаяСтоимость) и history (история). Это значит, что все его потомки наследуют данные операции, а заодно и все остальные атрибуты и операции родителя, которые могут не изображаться на рисунке.


Рисунок 3.13 - Графическое изображение отношения наследования

Имена ЦенныеБумаги и presentValue на рисунке намеренно выделены курсивом. Дело в том, что, создавая иерархию подобного рода, часто приходится сталкиваться с нелистовыми классами, которые неполны или для которых не может существовать объектов. Такие классы называются абстрактными, и на языке UML их названия пишутся курсивом, как в приведенном примере. Данное соглашение применимо и к операциям (например, presentValue); оно означает, что у операции есть сигнатура, но в других отношениях она неполна и требует реализации на более низком уровне абстракции. В нашем примере все четыре непосредственных потомка класса ЦенныеВумаги конкретны (то есть не абстрактны) и реализуют операцию presentValue.

Иерархия "обобщение/специализация" не обязательно ограничивается двумя уровнями. Как видно из рисунка, вполне допустимо существование более двух уровней наследования. АкцияСМалымКапиталом и АкцияСБолышимКапиталом - потомки класса Акция, который, в свою очередь, является потомком класса ЦенныеБумаги. Последний является базовым классом, поскольку не имеет родителей. Классы же АкцияСМалымКапиталом и АкцияСБольшимКапиталом - листовые, поскольку не имеют потомков. Наконец, класс Акция имеет как родителей, так и потомков, а следовательно, не является ни листовым, ни базовым.

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

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

Структурные отношения

Отношения зависимости и обобщения применяются при моделировании классов, которые находятся на разных уровнях абстракции или имеют различную значимость. Что касается отношения зависимости, один класс зависит от другого, но тот может ничего не "знать" о наличии первого. Когда речь идет об отношении обобщения, класс-потомок наследует своему родителю, но сам родитель о нем не осведомлен. Другими словами, отношения зависимости и обобщения являются односторонними.

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

Моделирование структурных отношений производится следующим образом:

  1.  Определите ассоциацию для каждой пары классов, между объектами которых надо будет осуществлять навигацию. Это взгляд на ассоциации с точки зрения данных.
  2.  Если объекты одного класса должны будут взаимодействовать с объектами другого иначе, чем в качестве параметров операции, следует определить между этими классами ассоциацию. Это взгляд на ассоциации с точки зрения поведения.
  3.  Для каждой из определенных ассоциаций задайте кратность (особенно если она не равна *, то есть значению по умолчанию) и имена ролей (особенно если это помогает объяснить модель).
  4.  Если один из классов ассоциации структурно или организационно представляет собой целое в отношении классов на другом конце ассоциации, выглядящих как его части, пометьте такую ассоциацию как агрегирование.

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


Рисунок 3.14
- Структурные отношения

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

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

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

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

Советы

При моделировании отношений в UML соблюдайте следующие правила:

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

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

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

Диаграммой классов (Class diagram) называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Ее изображают в виде множества вершин и дуг.

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

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

Типичные примеры применения

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

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

  •  для моделирования словаря системы. Моделирование словаря системы предполагает принятие решения о том, какие абстракции являются частью системы, а какие - нет. С помощью диаграмм классов вы можете определить эти абстракции и их обязанности;
  •  для моделирования простых коопераций. Кооперация - это сообщество классов, интерфейсов и других элементов, работающих совместно для обеспечения некоторого кооперативного поведения, более значимого, чем сумма составляющих его элементов. Например, моделируя семантику транзакций в распределенной системе, вы не сможете понять происходящие процессы, глядя на один-единственный класс, поскольку соответствующая семантика обеспечивается несколькими совместно работающими классами. С помощью диаграмм классов удается визуализировать и специфицировать эти классы и отношения между ними;
  •  для моделирования логической схемы базы данных. Логическую схему можно представлять себе как чертеж концептуального проекта базы данных. Во многих сферах деятельности требуется хранить устойчивую (persistent) информацию в реляционной или объектно-ориентированной базе данных. Моделировать схемы также можно с помощью диаграмм классов.

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

На рисунке 3.15 показана совокупность классов, взятых из информационной системы вуза. Этот рисунок является расширением приведенной ранее диаграммы классов и содержит достаточное количество деталей для конструирования физической базы данных. В левой нижней части диаграммы расположены классы Студент, Курс и Преподаватель. Между классами Студент и Курс есть ассоциация, показывающая, что студенты могут посещать курсы. Более того, каждый студент может посещать любое количество курсов и на каждый курс может записаться любое число студентов.


Рисунок 3.15
- Моделирование схемы

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

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

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

Советы

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

Хорошо структурированная диаграмма классов обладает следующими свойствами:

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

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

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

Упражнение Создание диаграмм классов

Постановка задачи

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

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

В этот момент Боб решил изменить требования:

"Нам надо отслеживать дату заказа и дату его выполнения. Кроме того, так как у нас появились новые поставщики, слегка изменилась процедура инвентаризации."

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

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

Создание диаграммы Классов для прецедента "Ввести новый заказ".

  1.  В окне Model Explorer откройте правой кнопкой мыши меню Add diagram для модели Система обработки заказов (рисунок 3.16) и выберете Use Case Diagram 

  1.  Назовите новую диаграмму Классов Add New Order (Введение нового заказа).
  2.  С помощью кнопки Class (Класс) Панели инструментов Tool Box (рисунок 3.17) поместите на диаграмму новый Класс
  3.  Назовите этот класс Выбор заказа.
  4.  Повторяя пункты 3 и 4 введите классы: Менеджер Заказа, Менеджер Транзакций, Детали Заказа, Заказ и Позиция Заказа.

Добавление атрибутов и операций

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

  1.  Щелкните правой кнопкой мыши на классе Заказ.
  2.  В открывшемся меню(рисунок 3.18) выберите пункт Attribute (Создать атрибут).

Рисунок 3.18 – Добавление атрибутов и операций

  1.  Введите новый атрибут OrderNumber : Integer (НомерЗаказа)
  2.  Нажмите клавишу Enter.
  3.  Введите следующий атрибут CustomerName : String (НаименованиеЗаказчика).
  4.  Повторите этапы 4 и 5, добавив атрибуты OrderDate : Date (ДатаЗаказа) и OrderFillDate : Date (ДатаЗаполненияЗаказа).
  5.  Щелкните правой кнопкой мыши на классе OrderItem.
  6.  В открывшемся меню выберите пункт New Attribute (Создать атрибут).
  7.  Введите новый атрибут ItemID : Integer (ИдентификаторПредмета).
  8.  Нажмите клавишу Enter.
  9.  Введите следующий атрибут ItemDescription : String (ОписаниеПредмета).

Добавление операций к классу Позиция заказа

  1.  Щелкните правой кнопкой мыши на классе Позиция заказа.
  2.  В открывшемся меню выберите пункт Operation (Создать операцию).
  3.  Введите новую операцию Create.
  4.  Нажмите клавишу Enter.
  5.  Введите следующую операцию SetInfo
  6.  Нажмите клавишу Enter.
  7.  Введите следующую операцию GetInfo.

Введите операции для остальных классов в соответствии с рисунком

Добавление связей между классами

  1.  Нажмите кнопку панели инструментов Association.
  2.  Нарисуйте ассоциацию от класса Выбор Заказа к классу Детали Заказа.
  3.  Повторите этапы 1 и 2, создав еще ассоциации:

# От класса Детали Заказа к классу Менеджер Заказов

# От класса Менеджер Заказов к классу Заказ

# От класса Менеджер Заказов к классу Менеджер Транзакций

# От класса Менеджер Транзакций к классу Заказ

# От класса Менеджер Транзакций к классу Позиция Заказа

# От класса Заказ к классу Позиция Заказа

  1.  Сделайте Двойной щелчок мыши на однонаправленной ассоциации между классами Выбор Заказа и Детали Заказа, со стороны класса Выбор Заказа.
  2.  В открывшемся ниспадающем меню (рисунок 3.19)справа выберите необходимую кратность ассоциации 0..1.

Рисунок 3.19 – Добавление кратности ассоциации

  1.  Сделайте Двойной щелчок мыши на другом конце однонаправленной ассоциации.
  2.  В открывшемся меню выберите пункт1..0.
  3.  Повторите этапы 4 - 7, добавив на диаграмму значения множественности для остальных ассоциаций, как показано на рисунке 3.20.

Рисунок 3.20 – Диаграмма классов для прецедента "Ввести новый заказ".


 

А также другие работы, которые могут Вас заинтересовать

29992. Свято Першого дзвоника – посвята першокурсників 66.5 KB
  У них мрії й недоспані ночі І тривога про завтрашній день Ведучий Знову двері до мудрості храму Де незгасне довічна хмарина Відчиня золотими ключами Рідна ненькомоя Україна. Пісня про Україну Ведучий Шановне товариство дорогі наші викладачі батьки та гості Щиро вітаємо всіх вас із . Ведучий Зустрічаймо їх теплими посмішками і радісними оплесками. ♬ Вихід першокурсників Ведуча Групу 1ф91керівник групи Олена Григорівна Лобур Ведучий Група 1 ф92 керівник групи _______________________Шатуніна Ведуча Групу 1ф93керівник групи...
29993. ПРАЗДНИК ПЕРВОГО СЕНТЯБРЯ 2013 г. 63.5 KB
  1ВЕДУШИЙ : Здравствуйте любимые учителя 2ВЕДУЩИЙ : Здравствуйте уважаемые родители и дорогие гости 1ВЕДУШИЙ: Сентябрь наступил закончилось лето Пришел праздник знаний учебы отметок 2ВЕДУШИЙ Дети родителиучителя С праздником вас поздравляем друзья 1 Школьник: СОСКУЧИЛСЯ ПО ШКОЛЕ Перегрелся на солнце я что ли Заскучал вдруг по собственной школе. Ну а сегодня – праздничный час Вместе: С праздником мы поздравляем всех вас 2 ВЕДУЩИЙ: Пришло время пригласить на нашу праздничную линейку...
29994. Возможности использования современных информационных технологий при изучении разделов «Атомная физика и Физика Атомного ядра» в школьном курсе физики 806.1 KB
  Влияние информационных технологий на выбор форм методов и средств обучения физике 26 1. Глава 1 Современные технологии обучения в преподавании физики 1. Практика воспитания и обучения все чаще сталкивается с необходимостью доступного подчеркивающих взаимосвязь явлений мира на уровне макросистем также требует определенного наглядного объяснения объектов и явлений особенно если они принадлежать к микромиру или являются абстрактными обобщениями.
29995. Разработка технологического процесса изготовления оконных и дверных блоков из ПВХ 460.34 KB
  Пластиковые окна изобрели в Германии, в 30-ые года. Первые пластиковые окна производитель установил бесплатно в качестве рекламы, но первоначально их производство не увенчалось успехом. И популярными стали они намного позже, в года 60-ые и их популярность растет до сих пор, прежде всего, из-за их устойчивости к внешним воздействиям. И это обоснованно.
29996. Увеличение выпуска продукции Деталь Валик 8ТС. 200.195 411.53 KB
  Определяем число запусков в году: 2.6 13 293 Определяем массу проектируемой заготовки: m3= Р V 106 кг. где Р = 785 кг дм3 плотность материала; V объем заготовки; Определяем коэффициент использования металла проектируемой заготовки по формуле: Определяем стоимость проектируемой заготовки: где Ц1=9540 руб. Значения и определяем по таблицам 2 и 8 [9] заготовка = 240 мкм.
29997. Гіпсова скульптура у вигляді жінки «Каріатиди» стилю Українського бароко 386.36 KB
  Використана література Вступ Вступ Скульптура лат. За змістом і функціям скульптура ділиться на монументальнодекоративну станкову і так звану скульптуру малих форм. Монументальнодекоративна Скульптура розрахована на конкретне архітектурнопросторове або природне оточення. Монументальнодекоративна скульптура покликана конкретизувати архітектурний образ доповнювати виразність архітектурних форм новими відтінками.
29998. Туристично-рекреаційний потенціал Мальти 742.06 KB
  Туристичнорекреаційний потенціал Мальти Мальта країна з історією що іде коренями в глибоке минуле. Мальта – маленька острівна країна в центральній частині Середземного моря з дуже вигідним стратегічним положенням. Мальта входить до числа найгустіше заселених країн світу. Мальта – найбільшому з островів – і має дві великі глибоководні бухти.
29999. Разработка автоматизированного электропривода шлифовального станка 127.05 KB
  В некоторых тяжелых станках применяется автоматическое регулирование скорости вращения двигателя в диапазоне примерно 2:1 с целью поддержания постоянства скорости резания. Поэтому при сравнительно больших диаметрах шлифовальных кругов до 1000 мм скорость вращения шлифовального шпинделя ниже или равна скорости вращения приводного двигателя около 950 об мин. Скорости вращения этих двигателей 24000 : 48000 об мин а при малых диаметрах шлифовальных кругов доходят до 150000 : 200000 об мин. При скоростях вращения до 48000 об мин ротор...