Ассоциация классов.
Ассоциация обозначает семантическое объединение классов.
Пример:
В системе обслуживания читателей есть 2 основные абстракции – книга и библиотека. Класс «книга» играет роль элемента, который хранится в библиотеке. Класс «библиотека» играет роль хранилища для книг.
Лекция 4-6 ксерокс.
Л
*
екция 7Интерфейсы и абстрактные классы, параметризированный класс.
Производные ассоциации и атрибуты.
Производные ассоциации и атрибуты могут быть получены в соответствии с другими ассоциациями и атрибутами, расположенным на диаграмме классов. Напр., значение атрибута Возраста личности можно вычислить, если известна дата рождения. Каждая точка зрения допускает свою собственную интерпретацию производных ассоциации и атрибутов. Самые тонкие нюансы, связаны с точкой зрения «спецификация». При этом важно понимать, что смысл производных ассоциаций и атрибутов заключается в определении связей между значениями, а не в определении того, что вычисляется и сохраняется постоянно. На диаграмме реализации, производные значения являются важными для специально отмеченных полей, который используются как кэш-память для повышения продуктивности. Обозначая эти поля, можно явно показать на диаграмме использование кэш-памяти. На концептуальной диаграмме обозначаются производные атрибуты, чтобы не забыть где производится вычисление и согласовывать этот факт с экспертами предметной области. Это описание позже переходит на соответствующие диаграммы спецификации.
В нотациях ОЛТ и ОДЕЛЛА, производные ассоциации обозначаются с помощью косой черты на линии ассоциации, такое обозначение не является частью UML.
Интерфейсы и абстрактные классы
Одна из отличных возможностей объектно-ориентированной разработки заключается в том, что я могу менять интерфейсы классов вне зависимости от их реализации.
Объектная разработка является таким мощным методом, благодаря этому свойству. Но, очень малое количество разработчиков используется это свойство должным образом. В языках программирования единственная конструкция – это класс, который включает как интерфейсы, так и реализацию. Если я определяю подкласс, то он наследует и то, и другое. К сожалению, разработчики очень редко определяют интерфейс, как отдельную конструкцию.
Интерфейс в чистом виде (как, например, в Java) является классом без каких-нибудь деталей реализации и поэтому содержит определение только операций, но не тела методов и поля. Интерфейсы часто определяются с помощью абстрактных классов, такие классы могут иметь ввиду некоторую реализацию, но они чаще всего используются для определения интерфейса. Дело в том, что механизм подклассов может обеспечивать реализацию, но пользователь никогда не увидит её, а увидит интерфейс.
Типичным примером такой ситуации является текстовый редактор. Чтобы сделать редактор независимым, мы определяем независимый абстрактный класс «окно» - этот класс не содержит операций, он определяет только интерфейс для текстового редактора. Платформо-зависимые подклассы могут использоваться на мое усмотрение.
