Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Л10. ДИАГРАММЫ КЛАССОВ и КООПЕРАЦИИ
1. Подходы к выделению
классов и объектов
Объектно-ориентированные модели разрабатывают с исполь зованием следующих абстракций:
Отношения устанавливают роли каждого объекта проекта во взаимодействии, их отличия и сходство. Отношения между объектами можно определить, сформулировав ответы на следующие вопросы:
Выработаны следующие подходы к выделению классов и объектов (см. рис.):
Классический подход опирается на классическую категоризацию. Этот подход связан с именами таких ученых как Шлаер, Меллор, Росс, Коуд, Йордон.
Источниками классов и объектов являются:
Рис. Основные подходы к выделению классов и объектов
Кандидатами в классы и объекты могут быть:
Анализ поведения представляет такой подход к объектно-ориентированному анализу, при котором классы и объекты выделяют не на основе осязаемых предметов, а на основе анализа динамики поведения проектируемой системы.
Этот подход в большей степени опирается на концептуальную кластеризацию: в классы объединяются группы объектов, демонстрирующих сходное поведение.
Анализ предметной области представляет такой способ выделения классов и объектов (операции и связей), при котором используют мнение экспертов предметной области об их важности и учитывают имеющийся опыт (результаты) практической разработки подобных систем.
Кандидатами в классы и объекты проектируемой системы выбирают наиболее важные объекты предметной области с точки зрения экспертов.
По мнению Мура и Байлини в анализе предметной области должны присутствовать следующие этапы:
В роли эксперта может выступать обычный пользователь, хорошо представляющий требования к системе.
Анализ вариантов (сценариев) - это подход, который впервые сформулировал Джекобсон, определивший вариант как частный пример или образец использования, то есть сценарий, начинающийся с того, что пользователь системы инициирует операцию или последовательность взаимосвязанных событий.
В этом виде анализа пользователи, эксперты и разработчики перечисляют сценарии, наиболее существенные для работы системы, не углубляясь в детали.
Затем сценарии подвергаются детальной проработке. Здесь выделяют объекты, которые участвуют в сценарии, устанавливают обязанности каждого объекта и их взаимодействие.
Набор сценариев может быть расширен для проработки исключительных ситуаций и побочных эффектов.
Неформальное описание. Согласно этому подходу надо описать часть или всю задачу, для автоматизации решения которой разрабатывается программа, на естественном для человека языке, а потом подчеркнуть существительные и глаголы. При таком неформальном описании имена существительные будут кандидатами на роль классов, а глаголы могут стать именами операций (связей).
Структурный анализ более согласуется с процедурно-ориентированными методологиями разработки.
После проведения структурного анализа получают модель программного комплекса, описанную диаграммами потоков данных и другими средствами структурного анализа (диаграммы "сущность - связь", диаграммы переходов состояний, словари данных). Исходя из этой модели, можно приступить к определению осмысленных классов и объектов.
В UML после выделения классов и их связей можно приступить к построению диаграммы классов.
2. Диаграммы классов
Диаграмма классов – основной способ отображения статической структуры разрабатываемой системы в терминологии классов объектно-ориентированного программирования.
Диаграмма классов может содержать:
Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, т. е. графическое представление таких структурных взаимосвязей логической модели системы, которые не зависят от времени.
Рис. Пример диаграммы классов книжного Интернет-магазина
ДК связаны с дисциплиной анализа и используются в дисциплине проектирования.
ДК является основным логическим представлением (Logical View) модели.
Классы
Класс (class) — абстрактное описание множества однородных объектов (экземпляров), имеющих одинаковые атрибуты, операции и отношения с объектами других классов.
Рис. Варианты графического изображения класса на диаграмме классов
В секциях могут указываться имя класса, атрибуты и операции класса.
Если секции атрибутов и операций пусты, в обозначении класса они должны быть выделены горизонтальной линией, с тем чтобы отличить класс от других элементов языка UML (рекомендуется).
Имена классов образуют словарь предметной области при ООАП.
Класс может иметь или не иметь экземпляров (объектов). В зависимости от этого в языке UML различают конкретные и абстрактные классы.
В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом.
В VS.NET статические классы изображаются прямоугольником с пунктирным контуром.
Общий формат записи отдельного атрибута класса следующий:
<квантор видимости> <имя атрибута> [кратность] :
<тип атрибута> = <исходное значение>
{строка-свойств}
Видимость (visibility) — качественная характеристика описания элементов класса, характеризующая потенциальную возможность других объектов модели оказывать влияние на отдельные аспекты поведения данного класса.
Видимость:
символ "+" – public
символ "#" – protected
символ "-" – private
символ "~" – package (C#: internal) виден только в пакете, в котором определен.
Кратность атрибута:
[ нижняя граница .. верхняя граница, ...]
[ нижняя граница .. * ]
[ * ] - от 0 до неопределенное число
[число]
По умолчанию – 1.
Тип: string, int и т.д.
Подчеркивание строки атрибута означает static.
Знак «/» перед именем атрибута указывает на то, что данный атрибут является производным от некоторого другого атрибута этого же класса.
Строка-свойств:
1. Если в строке имеется знак равенства, то вся запись Строка-свойств служит для обозначения фиксированного значения соответствующего атрибута для класса в целом, которое должны принимать все вновь создаваемые экземпляры класса без исключения. Это значение принимается за исходное значение атрибута, которое не может быть переопределено в последующем.
2. changeable – изменяемый, addOnly – только добавление, frozen – заморожен (значения нельзя изменять).
Общий формат записи отдельной операции:
<квантор видимости> <имя операции>(список параметров):
<выражение типа возвращаемого значения>
{строка-свойство}
Список параметров является перечнем разделенных запятой формальных параметров, каждый из которых, в свою очередь, может быть представлен в следующем виде:
<направление параметра> <имя параметра>: <выражение типа> =
<значение параметра по умолчанию>
Направление параметра : in, out или inout.
in - по умолчанию.
Имена операций, так же как атрибутов и параметров, записываются со строчной (малой) буквы, а их типы параметров — с заглавной (большой) буквы.
При этом обязательной частью строки записи операции является наличие имени операции и круглых скобок.
Расширение языка UML
Язык UML содержит два специальных расширения:
- профиль для процесса разработки программного обеспечения (The UML Profile for Software Development Processes) и
- профиль для бизнес-моделирования (The UML Profile for Busi ness Modeling).
Рис. Графическое изображение классов для моделирования программного обеспечения
У каждой диаграммы классов должен быть хотя бы один управляющий класс, контролирующий последовательность выполнения действий этого варианта использования.
Как правило, данный класс является активным и инициирует рассылку множества сообщений другим классам модели.
Класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы.
Пример: отдельная таблица базы данных.
Граничный класс (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы.
Пример: Элементы управления в окне.
Рис. Графическое изображение классов для моделирования бизнес-систем
Сотрудник (business worker) — класс, служащий на диаграмме классов для представления любого сотрудника, который является элементом бизнес-системы и взаимодействует с другими сотрудниками (классами) при реализации бизнес-процесса.
Сотрудник для связи с окружением (caseworker) – класс, служащий для представления в бизнес-системе такого сотрудника, который, являясь элементом бизнес-системы, непосредственно взаимодействует с актерами (бизнес-актерами) при реализации бизнес-процесса.
Бизнес-сущность (business entity) — специальный случай класса-сущности, который также не инициирует никаких сообщений. Этот класс служит для сохранения информации о результатах выполнения бизнес-процесса в моделируемой бизнес-системе или организации.
Интерфейс
Интерфейс (interface) — именованное множество операций, которые характеризуют поведение отдельного элемента модели.
Интерфейс в контексте языка UML является специальным случаем класса, у которого имеются операции, но отсутствуют атрибуты.
Для обозначения интерфейса используется специальный графический символ окружность или стандартный способ – прямоугольник класса со стереотипом <<interface>>.
Рис. Примеры графического изображения интерфейсов на диаграммах классов
Формально интерфейс не только отделяет спецификацию операций системы от их реализации, но и определяет общие границы проектируемой системы.
В последующем интерфейс может быть уточнен явным указанием тех операций, которые специфицируют отдельный аспект поведения системы.
Графическое изображение интерфейсов в форме окружности могут использоваться и на других типах канонических диаграмм, например, диаграммах компонентов и развертывания.
Отношения между классами
Базовые отношения:
• ассоциация (association relationship)
• обобщение (generalization relationship)
• агрегация (aggregation relationship)
• композиция (composition relationship)
Ассоциация соответствует наличию взаимосвязи между классами.
Ассоциации рассматривались при изучении элементов диаграммы вариантов использования.
Применительно к диаграммам классов семантика этого типа отношений значительно шире. В качестве дополнительных специальных символов могут использоваться:
• имя ассоциации,
• символ навигации,
• имя ассоциации,
• кратность ассоциации.
Рис. Графическое изображение ненаправленной бинарной ассоциации между классами
Рис. Роли в ассоциации
Направление стрелки указывает на то, какой класс является первым, а какой - вторым.
Рис. Графическое изображение направленной бинарной ассоциации между классами
Частный случай отношения ассоциации - так называемая исключающая ассоциация (Xor-association). В каждый момент времени может использоваться только один класс.
На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации, рядом с которой записывается ограничение {xor}.
Рис. Графическое изображение исключающей ассоциации между тремя классами
Тернарная ассоциация связывает отношением три класса. Ассоциация более высокой арности называется n-арной ассоциацией.
Рис. Графическое изображение тернарной ассоциации между тремя классами
Класс может быть присоединен к линии ассоциации пунктирной линией.
Это означает, что такая ассоциация является классом ассоциации (Association Class).
Рис. Класс ассоциации.
Все другие типы рассматриваемых отношений можно считать частным случаем данного отношения.
Это отношение между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком). В языках реализуется в виде наследования.
Данное отношение используется для представления иерархических взаимосвязей между различными элементами языка UML, такими как пакеты, классы, варианты использования.
Рис. Графическое изображение отношения обобщения в языке UML
Например, класс Транспортное средство (курсив обозначает абстрактный класс) может выступать в качестве суперкласса для подклассов, соответствующих конкретным транспортным средствам, таким как: Автомобиль, Автобус, Трактор и другим.
Рис. Пример графического изображения отношения обобщения для нескольких классов-потомков
В дополнение к простой стрелке обобщения может быть присоединена строка текста, указывающая на специальные свойства этого отношения в форме ограничения.
В качестве ограничений могут быть использованы следующие ключевые слова языка UML:
{complete} - означает, что в данном отношении обобщения определены все классы-потомки, и других классов-потомков у данного класса-предка быть не может.
{incomplete} - означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы-потомки. В последующем возможно разработчик восполнит их перечень, не изменяя уже построенную диаграмму.
{disjoint} - означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов.
{overlapping} - случай, противоположный предыдущему. А именно, предполагается, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.
Рис. Использование строки-ограничения
Агрегация применяется для представления системных взаимосвязей типа "часть-целое".
Агрегация показывает, из каких элементов состоит класс (система), и как они связаны между собой.
Таким образом, данное отношение по своей сути описывает декомпозицию или разбиение сложной системы на более простые составные части, которые также могут быть подвергнуты декомпозиции, если в этом возникнет необходимость.
Рис. Графическое изображение отношения агрегации в языке UML
Отличие от обобщения заключается в том, что части системы никак не обязаны наследовать ее свойства и поведение, поскольку являются самостоятельными сущностями.
Рис. Диаграмма классов для иллюстрации отношения агрегации на примере системного блока ПК
Отношение композиции - частный случай отношения агрегации: части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются и все его составные части.
Класс, который связан отношением композиции с одним или большим числом классов называется классом-композитом.
Рис. Графическое изображение отношения композиции в языке UML
Пример: окно графического интерфейса программы, которое может состоять из строки заголовка, полос прокрутки, главного меню, рабочей области и строки состояния.
Подобное окно представляет собой класс-композит, а его составные элементы также являются отдельными классами.
Рис. Класс-композит Окно программы
Построение диаграмм классов
Процесс разработки диаграммы классов занимает центральное место при разработке проектов сложных систем. От умения правильно выбрать классы и установить между ними взаимосвязи зависит успех процесса проектирования.
Рис. Пример диаграммы классов книжного Интернет-магазина
(Review – отзыв, Order – заказ, Reviewer – критик, Customer – покупатель, Account – счет, Book – книга, Publisher – издатель, Author – автор, Shipper – поставщик (курьер), Shipping – доставка, Bill – счет, Editorial Review – редакционный отзыв)
После разработки диаграммы классов процесс ООАП может быть продолжен в двух направлениях.
С одной стороны, если поведение системы тривиально, то можно приступить к разработке диаграмм кооперации и последовательности.
Однако для сложных динамических систем, в частности для параллельных систем и систем реального времени, важнейшим аспектом их функционирования является поведение. Специфика поведения таких систем может быть представлена на диаграммах состояний и деятельности, разработка которых в общем случае не обязательна, а определяется конкретным проектом.
3. Диаграммы кооперации (объектов)
Рис. Пример диаграммы кооперации для Интернет-магазина
Диаграммы кооперации предназначены для описания поведения системы на уровне отдельных объектов, которые обмениваются между собой сообщениями, чтобы реализовать некоторые варианты использования.
Как и диаграммы последовательности, связаны с дисциплиной проектирования.
Они отражают одну и ту же информацию и используются на одном и том же этапе разработки. Однако на диаграммах кооперации отсутствуют линии жизни и фокусы управления. В этом плане диаграммы кооперации являются частным случаем (но и более простым) диаграмм последовательности.
Одна диаграмма кооперации используется для спецификации динамики поведения, как правило, одного варианта использования системы.
Диаграммы кооперации обеспечивают представление структуры модели как совокупности взаимодействующих объектов.
На диаграмме кооперации размещаются:
• объекты, представляющие собой экземпляры классов,
• связи между ними, которые являются экземп ля рами ассоциа ций, и
• сообщения.
Как и на диаграмме классов, структурные отношения между объектами показываются в виде различных соединительных линий.
Связи могут дополняться именами ролей, которые играют объекты в данной взаимосвязи.
И, наконец, изображаются динамические взаимосвязи — потоки сообщений в форме стрелок с указанием направления рядом с соединительными линиями между объектами, при этом задаются имена сообщений и их порядковые номера в общей последовательности сообщений.
Одна и та же совокупность объектов может участвовать в реализации различных коопераций.
В зависимости от рассматриваемой кооперации, могут изменяться как связи между отдельными объектами, так и поток сообщений между ними. Именно это отличает диаграмму кооперации от диаграммы классов, на которой должны быть указаны все без исключения классы, их атрибуты и операции, а также все ассоциации и другие структурные отношения между элементами модели.
Объекты и их графическое изображение
Полное имя объекта:
<собственное имя объекта > / <Имя роли класса>:<Имя класса >
Имя класса – это имя одного из классов, представленного на диаграмме классов.
Вся запись имени объекта подчеркивается, что является визуальным признаком объектов на различных диаграммах языка UML.
Варианты возможных записей полного имени объекта:
о : C – объект с собственным именем о, экземпляр класса С.
: C – анонимный объект, экземпляр класса С.
о : – объект-сирота с собственным именем о (или просто о).
о / R : C – объект с собственным именем о, экземпляр класса С,
играющий роль R.
/ R : C – анонимный объект, экземпляр класса С,
играющий роль R.
о / R – объект-сирота с собственным именем о,
играющий роль R.
/ R – анонимный объект и одновременно объект-сирота,
играющий роль R.
Рис. Примеры графических изображений объектов на диаграммах кооперации уровня примеров
В контексте языка UML все объекты делятся на две категории: пассивные и активные.
Пассивный объект оперирует только данными и не может инициировать деятельность по управлению другими объектами. Однако пассивные объекты могут посылать сигналы (event в C#) в процессе выполнения запросов, которые они обрабатывают.
На диаграмме кооперации пассивные объекты изображаются обычным образом без дополнительных стереотипов.
Активный объект (active object) имеет собственный процесс управления и может инициировать деятельность по управлению другими объектами. (Пример: объект с методом Main.)
Активный объект на диаграмме кооперации обозначаются прямоугольником с утолщенными границами. Каждый активный объект является владельцем определенного процесса управления.
Рис. Графическое изображение активного объекта (слева) на диаграмме кооперации
Мультиобъект (multiobject) представляет собой множество анонимных объектов, которые могут быть образованы на основе одного класса.
На диаграмме кооперации мультиобъект используется для того, чтобы показать операции и сигналы, которые адресованы всему множеству анонимных объектов.
Рис. Графическое изображение мультиобъектов на диаграмме кооперации
В следующем примере рассматривается ситуация с отправкой почтового сообщений клиенту из редактора электронной почты.
Рис. Фрагмент диаграммы кооперации для выбора адреса клиента для отправки электронного письма
Анонимный активный объект класса РедакторEmail вначале посылает сообщение анонимному мультиобъекту класса Клиент. Это сообщение инициирует выбор единственного объекта класса Клиент, удовлетворяющего дополнительным условиям. После этого выбранному объекту посылается сообщение о необходимости отправить электронное письмо.
Составной объект (composite object) или объект-композит предназначен для представления объекта, имеющего собственную структуру и внутренние потоки (нити) управления.
Составной объект является экземпляром класса-композита, который связан отношением композиции со своими частями. Аналогичные отношения связывают между собой и соответствующие объекты.
На диаграммах кооперации такой составной объект изображается как обычный объект, состоящий из двух секций: верхней и нижней.
В верхней секции записывается имя составного объекта,
а в нижней – его объекты-части вместо списка атрибутов.
При этом допускается иметь в качестве частей другие составные объекты.
Рис. Графическое изображение составного объекта на диаграмме кооперации
Связи на диаграмме кооперации
Связь является примером произвольной ассоциации (или экземпляром) и может иметь место между двумя и более объектами.
Рис. Графическое изображение связей с различными стереотипами
Связи не имеют собственных имен.
Для связей не указывается также и кратность концевых точек.
Однако другие обозначения специальных случаев отношений, такие как агрегация и композиция, могут присутствовать на отдельных концах связей.
Каждое взаимодействие описывается совокупностью сообщений, которыми участвующие в нем объекты обмениваются между собой.
Сообщение (message) — это связь между объектами, означающая какой-либо вид деятельности, например, передачу информации от одного элемента модели к другому с ожиданием выполнения определенных действий со стороны принимающего элемента.
Связь обеспечивает канал для направленной передачи сообщений между объектами от объекта-источника к объекту-получателю.
Иногда отправителя сообщения называют клиентом, а получателя – сервером.
На диаграммах кооперации может использоваться один из трех типов стрелок для обозначения сообщений :
Рис. Графическое изображение различных типов сообщений на диаграмме кооперации
Вызов процедуры (метода) - сплошная линия с треугольной стрелкой. Обычно все такие сообщения синхронны.
Асинхронное сообщение в простом потоке управления - сплошная линия с V-образной стрелкой обозначает. В этом случае клиент передает асинхронное сообщение и продолжает выполнять свою деятельность, не ожидая ответа от клиента.
Возврат из вызова процедуры - пунктирная линия с V-образной стрелкой обозначает возврат из вызова процедуры.
Стрелки этого типа зачастую отсутствуют на диаграммах кооперации, поскольку неявно предполагается их существование после окончания процесса выполнения операции или деятельности.
Каждое сообщение может быть помечено строкой текста, которая имеет следующий формат:
<Предшествующие сообщения> <Выражение последовательности> <Возвращаемое значение := имя сообщения> <(Список аргументов)>
Предшествующие сообщения — это разделенные запятыми номера сообщений, записанные перед наклонной чертой.
Смысл указания предшествующих сообщений заключается в том, что данное сообщение не может быть передано, пока не будут переданы своим адресатам все сообщения, номера которых записаны в данном списке.
Выражение последовательности — это разделенный точками список отдельных термов последовательностей, после которого записывается двоеточие.
В языке UML предусмотрены стандартные действия (сообщения), выполняемые в ответ на получение соответствующего сообщения (записываются перед сообщением или выше его):
<<call>> - вызвать;
<<return>> - возвратить результат;
<<create>> - создать – сообщение, требующее создания дру го го объекта;.
<<destroy>> - уничтожить – сообщение с явным требованием уничтожить соответствующий объект;
<<send>> - послать – обозначает посылку другому объекту сигнала (event), который асинхронно инициируется одним объектом и принимается (перехватывается) другим. Отличие сигнала от сообщения заключается в том, что сигнал должен быть явно описан в том классе, объект которого инициирует его передачу.
Рис. Пример диаграммы кооперации для Интернет-магазина
Рекомендации по построению диаграмм кооперации
Построение диаграммы кооперации можно начинать сразу после построения диаграммы классов. При разработке диаграмм кооперации вначале изображаются объекты и связи между ними.
Далее на диаграмму кооперации необходимо нанести все сообщения, указав их порядок и другие семантические особенности.
Диаграмма кооперации может содержать только те объекты и связи, которые принадлежат классам уже построенной ранее диаграмме классов. В противном случае, если возникает необходимость включения в диаграмму кооперации объектов, которые создаются на основе отсутствующих классов, то диаграмма классов должна быть модифицирована посредством включения в нее явного описания этих классов.
Процесс построения диаграммы кооперации должен быть согласован с процессами построения диаграммы классов и диаграммы последовательности. В первом случае, как уже отмечалось, необходимо следить за использованием только тех объектов, для которых определены порождающие их классы. Во втором случае необходимо согласовывать последовательности передаваемых сообщений. Речь идет о том, что не допускается различный порядок следования сообщений для моделирования одного и того же взаимодействия на диаграмме кооперации и диаграмме последовательности.
Необходимо помнить, что диаграмма кооперации, с одной стороны, обеспечивает концептуально согласованный переход от статической модели диаграммы классов к динамическим моделям поведения, представляемым диаграммами последовательности, состояний и деятельности. С другой стороны, диаграмма этого типа предопределяет особенности реализации модели на диаграммах компонентов и развертывания.
Отдел кадров
Компания
Сотрудник
работает
дает работу
Компания
Сотрудник