Высокая степень связывания сама по себе не является проблемой. Проблемой является жесткое связывание с неустойчивыми в некотором отношении элементами.

20. Шаблон High Cohesion.

Шаблон решает общую проблему управления сложностью за счет регулирования степени зацепления классов. Разница между связностью и зацеплением очень тонка, и понять ее необходимо на более глубоком интуитивном уровне. Зацепление (cohesion) (или более точно, функциональное зацепление) - это мера связанности и сфокусированности обязанностей класса. Считается, что элемент обладает высокой степенью зацепления, если его обязанности тесно связаны между собой и он не выполняет огромных объемов работы. Класс с низкой степенью зацепления выполняет много разнородных функций или несвязанных между собой обязанностей.

High Cohesion твердит, что класс должен стараться выполнять как можно меньше не специфичных для него задач, и иметь вполне определенную область применения. Только с опытом приходит понимание балансировки между High Cohesion и Low Coupling. считается что связывание и зацепление это инь и янь проектирования ПО. Некорректное связывание порождает неправильное зацепление и наоборот.

21. Шаблон Controller.

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

Иногда класс-контроллер представляет всю систему в целом, корневой объект, устройство или важную подсистему (внешний контроллер).

22. Шаблон Polymorphism.

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

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

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

Проблема. Как обрабатывать альтернативные варианты поведения на основе типа? Как создавать подключаемые программные компоненты?

Альтернативные варианты поведения на основе типа. Условная передача управления - это основная отличительная особенность любой программы. Если программа разработана с использованием if-then-else или условных операторов по ключу, то при добавлении новых вариантов поведения приходится модифицировать логику условных операторов. Такой подход затрудняет процесс модификации программ в соответствии с новыми вариантами поведения, поскольку изменения приходится вносить сразу в нескольких местах программного кода - там, где используются условные операторы.

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

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

Предостережение.

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

Преимущества.

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

• Новые вариации можно вводить без модификации клиентской части приложения.

23. Диаграмма классов (что отображает, когда разрабатывается, процесс создания).

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

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

·         — — private (частный)

·         # — protected (защищенный)

·         + — public (общий)

·         + — package

Процесс создания:

1. Идентификация классов, которые должны участвовать системе.

2. Добавление атрибутов:     +имя:тип={значение}.

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

4. Добавление. Отношение зависимости. Существует много возможных вариантов зависимости, наиболее распространенные следующие:

24. Дополнительные обозначения диаграммы классов (обобщение, агрегация, квалификатор ассоциации, класс ассоциации).

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

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

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

Графически агрегация представляется пустым ромбом на блоке класса, и линией, идущей от этого ромба к содержащемуся классу.

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

• Квалификатор

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

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

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

Рисунок 2.7 "Квалификатор"

4) Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому. Является общим случаем композиции и агрегации.

Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в».

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

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

25. Использование пакетов для организации элементов модели.

Пакет (англ. package) в языке моделирования UML — основная группирующая сущность с помощью которой организуются конкретные проектные решения в рамках используемой UML-модели. UML-пакет предназначен для группировки большого количества структурных, поведенческих и других сущностей в единое целое; изображается в виде стилизованной папки с закладкой, которая может иметь своё собственное имя.

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

Введение UML пакетов позволяет распределять разнообразные отдельные элементы создаваемого проекта по удобным для масштабирования блокам, которыми можно будет позже манипулировать как некими самостоятельными единицами. Как правило, пакеты служат для хранения элементов модели верхнего уровня: классов и их отношений, графов Use Case, конечных автоматов и т. п. Элементы пакета могут иметь различную видимость снаружи, то есть — некоторый функционал пакета может быть инкапсулирован с точки зрения внешнего пользователя. В этом отношении пакет выполняет функцию отдельного пространства имён, элементы которого могут быть как публичными, так и приватными. Грамотно структурированный пакет должен объединять семантически и функционально родственные элементы, которые имеют тенденцию совместно эволюционировать в процессе разработки.

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

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

26. Архитектура программной системы (логическая архитектура).

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

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

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

1)Уровень объекта предметной области.

2)Уровень логики приложения.

3)Уровень технических служб.

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

Основные принципы шаблона:

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