Концепции связи и ассоциации

Методы класса

Атрибуты класса

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

Концепции объекта и класса

Содержание

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

Цель моделирования классов состоит в описании объектов. В качестве примеров объектов можно привести следующие: Джо Смит, компания Симплекс, процесс № 3688 и активное окно.

Объект (object) — это концепция, абстракция или сущность, обладающая индивидуальностью и имеющая смысл в рамках приложения. Объекты часто бывают именами собственными или конкретными ссылками, которые используются в описании задач или при общении с пользователями. Некоторые объекты существуют или существовали в реальном мире (например, Альберт Эйнштейн или компания General Electric), тогда как другие являются сугубо концептуальными сущностями (например, тестовый прогон № 1234 или формула корней квадратного уравнения). Объекты третьего типа {бинарное дерево 238 и массив, связанный с переменной а) добавляются в модель в процессе реализации и не имеют никакого отношения к физической реальности. Выбор объектов зависит от природы задачи и от предпочтений разработчика. Корректное решение в данном случае не является единственным.

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

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

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

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

Каждый объект «знает» свой собственный класс. Большинство объектно-ориентированных языков программирования позволяют определять класс объекта во время выполнения программы. Класс объекта — это его неявное свойство.

Если предметом моделирования являются объекты, то почему вообще заходит речь о классах? Все дело в необходимости абстрагирования. Группируя объекты в классы, мы производим абстрагирование в рамках задачи. Именно благодаря абстракциям моделирование оказывается столь мощным инструментом, позволяющим проводить обобщения от нескольких конкретных случаев к множеству подобных альтернатив. Общие определения (такие как название класса и названия атрибутов) хранятся отдельно для каждого класса, а не для каждого экземпляра.

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

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

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

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

На рис. 1 показан класс (слева) и его экземпляры (справа). Объекты JoeSmith (ДжоСмит), MarySharp (МэриШарп) и безымянная личность являются экземплярами класса Person (Человек). В языке UML для обозначения объекта используется прямоугольник, внутри которого ставится имя объекта, двоеточие и имя класса, к которому относится этот объект. И имя объекта, и имя класса подчеркиваются. Будем использовать дополнительное соглашение, которое состоит в том, что имена объектов и классов выделяются полужирным шрифтом.

Рисунок 1 – Объекты и классы – предмет модели классов

Для обозначения класса в UML тоже используется прямоугольник. Имя класса указывается полужирным шрифтом, располагая его посередине прямоугольника. Имя класса мы всегда будем начинать с заглавной буквы. Эти соглашения используются для ссылок на объекты, классы и другие конструкции. Могут быть приняты альтернативные соглашения, например, о допустимости пробелов или знаков подчеркивания в названиях классов или объектов { Joe Smith, Joe_Smith). Соглашение об использовании заглавных букв между строчных популярно в литературе, посвященной объектно-ориентированным технологиям, но не является требованием языка UML.

Значение (value) — это элемент данных. Значения можно определить, изучив примеры, приведенные в документации по поставленной задаче. Атрибут (attribute) — это именованное свойство класса, описывающее значение, которое может имеет каждый объект класса. Атрибуты — это прилагательные. Они получаются абстрагированием типичных значений. Можно провести следующую аналогию: объект относится к классу так, как значение относится к атрибуту. В моделях классов преобладают структурные конструкции (то есть классы и отношения между ними, о которых речь пойдет дальше). Атрибуты имеют не столь важное значение и служат для уточнения характеристик классов и отношений.

Атрибутами объектов класса Person (Человек) являются пате (имя), birthdate (датарождения) и weight (вес). Атрибутами объектов класса Саг (Машина) являются color (цвет), modelYear (годвыпуска) и weight (вес). У каждого конкретного объекта атрибут принимает свое конкретное значение. Например, у объекта JoeSmith атрибут birthdate может иметь значение «21 октября 1983». Другими словами, Джо Смит родился 23 октября 1983 года. У разных объектов один и тот же атрибут может иметь как разные, так и одинаковые значения. Имя атрибута уникально в рамках класса (но не обязательно уникально во множестве всех классов). Поэтому у классов Person и Саг может быть атрибут с одним и тем же названием — weight.

Не следует путать значения с объектами. Атрибут должен описывать значения, а не объекты. В отличие от объектов значения не обладают индивидуальностью. Например, все экземпляры числа 17 неразличимы между собой. Точно так же неразличимы экземпляры строкового значения «Канада». С другой стороны, страна, которая называется Канада, является объектом, у которого атрибут «название» имеет значение «Канада».

На рис. 2 показана система обозначений атрибутов. Класс Person (Человек) имеет атрибуты name (имя) и birthdate (датарождения). Name — это строка, a birthdate — дата. У одного из объектов класса Person атрибут пате имеет значение «Джо Смит», a birthdate имеет значение «21 октября 1983». У другого объекта того же класса атрибут name имеет значение «Мэри Шарп», а атрибут birthdate имеет значение «16 марта 1914».

Рисунок 2 – Система обозначений атрибутов

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

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

Иногда среда реализации может требовать наличия у объекта уникального идентификатора. Идентификаторы всегда неявным образом присутствуют в модели классов. Их не следует указывать явно (рис. 3). Большинство объектно-ориентированных языков генерируют идентификаторы для ссылок на объекты автоматически. Так же легко определить идентификаторы и для баз данных. Идентификаторы являются артефактом вычислительной системы и не имеют внутреннего смысла.

Рисунок 3 – Указание идентификаторов

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

Операция — это функция или процедура, которая может быть применена к объектам класса. Операциями класса Company (Компания) могут быть hire (нанять), fire (уволить) и pay Dividend (выплатитьДивиденды). Операциями класса Window (Окно) могут быть open (открыть), close (закрыть), hide (скрыть) и redisplay (перерисовать). Все объекты одного класса имеют общий список операций.

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

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

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

Если операция реализована несколькими методами в разных классах, очень важно, чтобы у всех методов была одна и та же сигнатура (signature) — количество и типы аргументов, а также тип возвращаемого значения. Например, у операции print не может быть аргумента fileName (имяФайла) в одном методе и filePointer (указательФайла) в другом методе. Поведение всех методов операции должно быть согласованно. Лучше всего избегать использования одинаковых названий для операций, отличающихся друг от друга с семантической точки зрения, даже если они применяются к разным множествам классов. Например, неправильно было бы использовать название «инверсия» для операций инвертирования матрицы и переворота геометрической фигуры. В большом проекте может потребоваться использование пространств имен для предотвращения конфликтов, но лучше всего заранее принимать меры для предотвращения возможных проблем.

На рис. 4 изображен класс Person (Человек) с атрибутами name (имя) и birthdate (датарождения) и операциями changejob (сменитьРаботу) и changeAddress (сменитьАдрес). Атрибуты и операции называются составляющими класса. У класса File (Файл) есть операция print (печать). У класса GeometricObject (Геометрический Объект) есть операции move (перемещение), select (выделение) и rotate (поворот). Операция move имеет один аргумент delta (смещение) типа Vector (Вектор), операция select имеет аргумент р типа Point (Точка) и возвращает значение типа Boolean (логическое значение). Операция rotate имеет аргумент angle (угол), который относится к типу чисел с плавающей точкой и имеет значение по умолчанию 0.0.

Рисунок 4 – Операции

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

Связи и ассоциации позволяют устанавливать отношения между объектами и классами.

Связь (link) — это физическое или концептуальное соединение между объектами. Например, Джо Смит работает на компанию Симплекс. В большинстве случаев связь соединяет ровно два объекта, но бывают связи, соединяющие большее количество объектов. В этой главе мы будем рассказывать только о бинарных ассоциациях, а в главе 4 займемся n-арными. С математической точки зрения связь является кортежем (tuple), то есть списком объектов. Связь — это экземпляр ассоциации.

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

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

Рисунок 5 – Связи и ассоциации

Диаграмма классов показывает, что человек может быть владельцем акций неопределенного количества компаний (от нуля и более). С другой стороны, владельцами акций одной компании могут быть несколько человек. На диаграмме объектов показаны примеры. Джон, Мэри и Сью являются владельцами акций General Electric. Сью и Элис являются владельцами акций компании IBM. Джефф не купил никаких акций, а потому и связи для него нет. Звездочка на нашем рисунке — это символ кратности. Кратность (multiplicity) определяет количество экземпляров одного класса, которые могут быть связаны с одним экземпляром другого класса. Эта концепция обсуждается в следующем разделе.

Система обозначений UML предписывает изображать связь как линию между двумя объектами. Линия может состоять из нескольких прямолинейных сегментов. Если у связи есть имя, оно подчеркивается. В нашем примере Джон является владельцем акций General Electric. Ассоциация соединяет между собой классы и тоже обозначается линией (которая тоже может иметь несколько прямолинейных сегментов). В нашем примере люди являются владельцами акций компаний. По нашему соглашению названия связей и ассоциаций выделяются курсивом, а сегменты линий привязываются к прямоугольной сетке. Удобно по возможности расставлять классы так, чтобы ассоциация читалась слева направо.

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

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

Разработчики часто реализуют ассоциации в виде ссылок из одного объекта на другой. Ссылка (reference) — это атрибут объекта, ссылающийся на другой объект. Например, структура данных класса Person (Человек) может содержать атрибут employer (работодатель), ссылающийся на объект класса Company (Компания), а объект класса Company может содержать атрибут employees (сотрудники), ссылающийся на множество объектов класса Person. Реализация ассоциаций в виде ссылок вполне приемлема, но моделировать ассоциации таким образом не следует.

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

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

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

Дата добавления: 2013-12-13