Мелихов А.Ю. Проектирование автоматизированных систем обработки информации и управления
Подождите немного. Документ загружается.
91
Т.о., если свойство (параметр) объекта модели предметной области можно
представить простым типом, то его включают в модель в качестве атрибута, если нет, то
рассматривают вопрос о добавлении дополнительного концептуального класса.
Объединение концептуальных классов, атрибутов и ассоциаций приводит к
получению итоговой версии модели предметной области.
Рисунок 54 – Модель предметной области, дополненная атрибутами сущностей
На всем протяжении проектирования необходимо особое внимание уделять
прослеживанию требований.
92
Рисунок 55 – Взаимосвязь описания операций с другими артефактами
6.1.5. Шаблоны (паттерны) проектирования
После построения и проработки модели предметной области, представляющей собой
совокупность концептуальных классов, наделенных атрибутами и соединенных
ассоциациями, встает вопрос об анализе и грамотном распределении операций между этими
классами.
C этого момента разработчик начинает активно использовать паттерны
проектирования. Под паттернами понимают устойчивые структурные единицы,
представляющие собой объединенные с целью выполнения некоторой задачи классы, а в
более общем смысле – правила проектирования, стандартные решения, применение которых
позволяет быстро получить качественный результат при решении большинства аналогичных
рассматриваемой проектных задач.
С середины 90-х сообщество программистов стало замечать, что какими бы
проектами они не занимались, какие бы подходы или языки программирования бы они не
использовали разные группы программистов с течением времени начали фиксировать
(название+описание) свои проектные решения, которые они с небольшими модификациями
и самое главное с успехом использовали во вновь реализуемых проектах. Оказалось, что
стандартные решения независимых друг от друга команд были весь схожи между собой. Эти
решения назвали шаблонами (паттернами patterns) и 23 наиболее распространенных из них
были опубликованы в 1994 году издательством Addison Wesley в книге «Design Patterns.
Elements of Reusable Object-Oriented Software» авторами которой стали 4 профессионала:
93
Э.Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Ходившая в то время шутка, связанная с
политикой Китая, привела к тому, что эти паттерны были сокращенно названы GoF (Gang-of-
Four – союз четырех).
В 2001 в издательстве Willey вышел первый том Pattern-Oriented Software Architecture.
A System of Patterns V.1. В 2007 году вышел 5 том энциклопедии On Patterns and Pattern
Languages. {В интете новые тома?}
Кроме того, вы можете зайти на домашнюю страничку шаблонов:
http://www.hillside.net/patterns.
Каждый паттерн включает в свой состав: имя, формулировку решаемых проблем,
описание способа решения, достоинства и недостатки, связь с другими паттернами и проч.
В ряде литературных источников шаблоны разделяются на уровня:
1. Архитектурные шаблоны связаны с крупномасштабными проектными решениями.
Примером является шаблон Layers одной из реализаций которого является MVC. В
литературе, посвященной архитектурным шаблонам, как правило, описываются
предметно-ориентированные решения для целого приложения. Например,
существуют архитектурные шаблоны, предназначенные для реализации не только
корпоративного приложения с толстым или тонким клиентом, но и для реализации
приложений специфического назначения, например, ОС, систем поддержки-
принятия решений, САПР, СУБД и т.д. Eric Evans Domain-Driven Design: Tackling
Complexity in the Heart of Software, сюда же могут
быть условно отнесены шаблоны
интеграции приложений (Грегор Хоп, Бобби Вульф «Шаблоны интеграции
корпоративных приложений»).
2. Шаблоны проектирования – шаблоны среднего уровня описывают правила
проектирования на уровне пакета (подсистемы). К этой группе относятся
большинство шаблонов GRASP и GoF.
Первой и по-прежнему наиболее часто цитируемой работой, посвященной
шаблонам проектирования остается книга Гамма Э., Хелм Р., Джонсона Р.,
Влисседес Дж. «Приемы объектно-ориентированного проектирования: паттерны
проектирования», в которой описаны 23 базовых паттерна проектирования.
получивших в последствии общее название GoF-паттернов. Этиже паттерны с
немного другими примерами описаны в работе Стивена Стелтинга и Олава
Маасена «Применение шаблонов Java. Библиотека профессионала».
Переходной работой между вторым и первым уровнем является известная
книга Мартина Фаулера «Архитектура корпоративных программных приложений»,
в которой рассмотрены 40 паттернов, получивших наибольшее распространение
при проектировании корпоративных приложений с web-интерфейсом.
3. Идиомы – низкоуровневые проектные решения, связанные с языком
программирования или стилем реализации. Пример – паттерн Singleton,
описывающий правила создания строго одного экземпляра того или иного класса.
Паттерны этой группы были систематизированы и описаны в работе Кента Бека
«Шаблоны реализации корпоративных приложений», в которой автор выделил 77
паттернов. разделив их на 5 групп: класс, состояние, поведение методы, коллекции.
Использование паттернов позволяет решить несколько фундаментальных задач
проектирования информационных систем – обеспечить удовлетворение принципов «слабой вешней
связанности и сильного внутреннего сцепления», а также обеспечить возможность повторного
использования компонентов. Ниже перечислены ошибки проектирования, затрудняющие повторное
использование компонентов, а также наращивание функциональности системы и GoF-паттерны,
позволяющие исправить такие ошибки [62]:
• поскольку сильно связанные
между собой классы образуют монолитные подсистемы, в
которых нельзя ни изменить, ни удалить класс без модификации других классов. Для
снижения внешней связности используются слои (см. ниже), абстрактные связи, а также
следующие паттерны: абстрактная фабрика (abstract factory), мост (bridge), цепочка
94
обязанностей (chain of responsibility), команда (command), фасад (facade), посредник
(mediator), наблюдатель (observer). Для повышения независимости отдельных классов
подсистемы друг от друга используются паттерны: адаптер (adapter), декоратор (decorator),
посетитель (visitor).
• использование имени класса при создании объекта привязывает проектировщика к
конкретной реализации, а не к интерфейсу, что может осложнить изменение объектов в
будущем. Решение этой проблемы состоит
в косвенном создании объектов с помощью
паттернов абстрактная фабрика, фабричный метод (factory method), прототип
(prototype);
• использование конкретной операции ограничивает выполнение запроса одним единственным
способом. Паттерны цепочка обязанностей и команда позволяют, не включая запросы в код,
изменить способ удовлетворения запроса, как на этапе компиляции, так и на этапе
выполнения;
• ограничить зависимость
от конкретной платформы (операционной системы с
предоставляемой ее API) позволяют паттерны абстрактная фабрика и мост;
• если при построении клиента использовалась информация о том, как тот или иной объект
представлен, храниться или реализован, то при изменении объекта может потребоваться
изменить клиент. Инкапсуляцию перечисленной информации обеспечивают паттерны
абстрактная фабрика, мост, хранитель (memento), заместитель (proxy)
;
• объекты, зависящие от изменяющихся алгоритмов (в случае необходимости расширения,
оптимизации и т.д.), приходится перепроектировать. Паттерны мост, итератор (iterator),
стратегия (strategy), шаблонный метод (template method) и посетитель позволяют
изолировать алгоритмы с высокой вероятностью изменения;
• композиция объектов и делегирование – гибкие альтернативы наследования для
комбинирования поведения, поскольку в этом случае новая функциональность
добавляется в
систему посредством изменения способа композиции объектов, а не за счет определения
новых подклассов через наследование. Однако использование только композиции объектов
может существенно усложнить структуру проекта. В этой связи используют прием, при
котором вначале определяется подкласс, а затем для обеспечения требуемой специализации
выполняется комбинирование его объектов с существующими. Такой прием
нашел отражение
в следующих паттернах: мост, цепочка обязанностей, компоновщик (composite),
декоратор (decorator), наблюдатель, стратегия.
Определив обязанности классов, введя системные класса, а также, рассмотрев интерфейсы
классов в соответствии с паттернами GRASP и GoF, переходят к описанию более высокоуровневых
абстракций – архитектурных слоев ИС.
Первая группа паттернов с которыми мы познакомимся предназначена для
распределения операций, а в более общем понимании обязанностей между классами.
Обязанности и операции относятся друг к другу как целое к частному. Обязанности
включают в себя один или несколько методов, реализация которых в объекте или в
совокупности взаимосвязанных объектов позволяет достичь определенную цель.
В первом приближении можно выделить два типа обязанностей: действие (doing)
(инициирование некоторых операций, их выполнение и управление этим выполнением),
знание (knowing) (хранение информации о инкапсулированных данных, о связанных
объектах, о значениях вычисляемых величин и т.д.).
Паттерны, относящиеся к группе, предназначенной для распределения обязанностей
между классами, получили название GRASP-паттернов (General Responsibility Assignment
Software Patterns). Из числа
GRASP-паттернов наибольшее распространение получили [80]:
(i) информационный эксперт (Information Expert) – правило, позволяющее выбрать
класс (из нескольких кандидатур) для назначения тех или иных функциональных
обязанностей;
(ii) создатель (Creator) – правило, позволяющее назначить классу В обязанность
создавать экземпляры класса А при выполнении определенных условий;
(iii) контроллер (Controller) – создание специального (служебного) класса–
обработчика системных сообщений.
95
Используются также дополнительные шаблоны GRASP, предназначенные для
обеспечения универсальности ИС и/или расширяемости ее в будущем: (i) полиморфизм
(Polymorphism), чистая синтетика (Pure Fabrication), перенаправление (Indirection),
защищенные вариации (Protect Variation).
6.1.5.1. Шаблон Information Expert
Позволяет назначить обязанности информационному эксперту – классу, у которого
имеется информация, требуемая для выполнения обязанностей. Pattern Information Expert
закрепляет известное правило объектно-ориентированного программирования, в
соответствии с которым каждый объект осуществляет действия, связанные с имеющейся у
него информацией.
При правильном распределении обязанностей система становится проще для
понимания, поддержки и расширения, а также повторного
использования ее отдельных
компонентов.
Начните распределение обязанностей с их четкой формулировки.
Затем анализируется модель проектирования (если она уже есть) или модель предметной
области для выявления концептуального класса, подходящего на роль информационного
эксперта.
Например, для расчета общей стоимости продаж необходимо просуммировать
стоимость всех проданных товаров (SalesLineItem – не просто экземпляр, а объект коллекции
типа
list). При этом для вычисления суммы продаж по каждому товару необходимо его цену
умножить на количество проданных товаров.
Рисунок 56 – Сопоставление диаграммы сотрудничества и диаграммы классов
Информация, необходимая для вычисления общей стоимости продаж доступна
объекту Sale, в состав которого и был введен метод getTotal. Для вычисления общей
стоимости потребуется определение промежуточной суммы продаж данного конкретного
товара. Информацией о количестве проданных товаров обладает класс SalesLineItem,
поэтому в соответствии с шаблоном Expert в состав данного класса был введен метод
getSubTotal, который в свою
очередь обращается к объекту ProductSpecification для
получения цены. Таким образом, три метода getTotal, getSubTotal и getPrice были
распределены между тремя классами в соответствии с паттерном Information Expert.
Методы классов определяют путем анализа диаграмм взаимодействия. Так, если
сообщение getPrice() передается экземпляру класса ProductSpecification, то в классе
ProductSpecification должен быть определен метод getPrice.
Как правило, распределение обязанностей выполняется в процессе создания диаграмм
взаимодействия, а затем полученные результаты в виде новых методов отражаются на
диаграмме классов.
96
Рисунок 57 – Уточненная диаграмма сотрудничества
6.1.5.2. Шаблон Creator
Позволяет назначить классу В обязанности по созданию экземпляров класса А, если
выполняется одно из следующих условий:
класс В агрегирует объекты А
класс В содержит объекты А
класс В записывает экземпляры объектов класса А;
класс В интенсивно использует объекты А;
класс В обладает данными инициализации, которые будут передаваться объектам А при их
создании.
Класс Sale содержит несколько экземпляров объектов SalesLineItem, поэтому согласно
шаблона Creator класс Sale должен обладать возможностями создания экземпляров объектов
SalesLineItem. Для решения такой задачи в объекте Sale необходимо определить метод
makeLineItem().
Рисунок 58 – Диаграммы классов и последовательностей электронной системы продаж
Класс «Файл УММ» должен появляться в системе, когда пользователь намеревается
загрузить новый файл на сервер. И спецификация загрузок создается (дополняется) при
успешной загрузки файла на сервер. Для этого необходимо предусмотреть соответствующие
97
методы: create() в объекте «Файл УММ» и createLineItem() в объекте «Спецификация
загрузок»
Рисунок 59 – Фрагменты диаграмм классов и последовательностей системы «Электронная
библиотека»
В случае, когда создание экземпляра представляет собой сложную операцию,
выполняемую при реализации некоторых условий, зависящих от внешних свойств, для
создания экземпляров используют шаблон Factory.
6.1.5.3. Шаблоны Low Coupling и High Cohesion
Ключевая задача проектирования архитектуры системы состоит в соблюдении двух
принципов:
принцип «слабой вешней связанности» (Low Coupling) – количество связей между
отдельными подсистемами (классами) должно быть минимальным;
принцип «сильного внутреннего сцепления» (High Cohesion) – связность отдельных частей
(классов) внутри каждой подсистемы должна быть максимальной.
Если класс имеет высокую степень связности – это означает, что он зависит от
большего числа других классов и, следовательно:
• изменения в связанных классах приводят к локальным изменениям в данном классе;
• затрудняется понимание каждого класса в отдельности, что усложняет повторное
использование;
• усложняется расширение функциональных возможностей системы.
Для измерения внутреннего сцепления используют понятие силы связности (СС).
Существует 7 типов связности:
1. Связность по совпадению (СС=0). В операциях класса отсутствуют явно выраженные
внутренние связи.
2. Логическая связность (СС=1). Операции класса объединены по принципу
функционального подобия. Например, класс отвечает за обработку разных ошибок.
3. Временная связность (СС=3). Операции класса не связаны, но необходимы в один и
тот же период работы системы.
4. Процедурная связность (СС=5). Операции класса связаны порядком выполняемых
ими действий, реализующих некоторый сценарий (алгоритм) поведения.
5. Коммуникативная связность (СС=7). Операции связаны по данным (работают с одной
и той же структурой данных).
6. Информационная (последовательная
) связность (СС=9). Результаты, возвращаемые
одним методом, используются как аргументы других методов экземпляра.
98
7. Функциональная связность (СС=10). Атрибуты и операции класса взаимодействуют
между собой с целью обеспечения заданного поведения или реализации конкретной
обязанности.
Отметим, что типы связности 1,2,3 являются результатом неправильного
распределения обязанности между классами (4 тип связности является нежелательным).
Обеспечение слабой внешней связности и сильного внутреннего сцепления – это
фундаментальные принципы проектирования информационных систем, которые лежат в
основе структурно-функциональной методологии и были сформулированы для понятия
модуля и его функций.
При размещении классов по пакетам (модулях) необходимо соблюдать указанные
выше принципы.
Необходимо отметить существование исключений, позволяющих в некоторых
случаях нарушать принцип сильного внутреннего сцепления. Например,
1. «человеческий фактор». Если в проекте многочисленные классы обращаются
посредством внедренных SQL операторов к крупной БД, то для удобства поддержки
специалистом по SQL этих внедренных операторов архитектор может объединить их
в одном классе;
2. при распределенных систем интенсивный обмен между узлами сети короткими
сообщениями (setName, readFIO и т.д.) может привести к потере производительности.
Решить эту проблему можно посредством использования интерфейса уделанного
доступа (remote facade), который позволяет реализовать одну укрупненную операцию
(setData).
6.1.5.4. Шаблон Controller
Позволяет делегировать обязанности по обработке системных сообщений служебному
классу, который может представлять всю систему (подсистему) в целом или сценарий того
или иного прецедента для которого необходимо обеспечить обработку системных событий
(<Прецедент>Handler, <Прецедент>Coordinator, <Прецедент>Session).
Системное событие (сообщение) – это событие высокого уровня, генерируемое
внешним по отношению к рассматриваемой системе или подсистеме источником.
Контроллер определяет
методы для выполнения системных операций. Он дилегирует
функции другим объектам и координирует их деятельность, но не выполняет функции
самостоятельно. Контроллер не является объектом предметной области – это служебный
класс, поддерживающий жизнедеятельность системы.
Например, если пользователь нажимает на форме кнопку «Найти» – он обращается ко
всей системе в целом, т.е. инициирует системную
операцию. Затем некий класс слоя
взаимодействия с пользователем лишь передает сообщение объекту контроллера: ID кнопки
и текст запроса, а контроллер позволит передать эти параметры классу исполнителю.
99
Рисунок 60 – Пример взаимодействия слоя представления и предметной области
В данном случае, когда из интерфейса пользователя запрос направляется локальному
классу-контроллеру, относящемуся к клиентской части программы, а класс-контроллер
перенаправляет весь запрос или его часть удаленным службам тем самым снижается степень
связывания между интерфейсом пользователя и удаленными службами.
Если класс интерфейса будет обрабатывать системную операцию, то часть логики
домена окажется заложенной в интерфейсе, что существенно снизит повторное
использование компонентов.
Системные операции, идентифицированные в процессе анализа поведения системы,
на этапе проектирования включаются в состав одного или нескольких классов контроллеров.
В этой связи контроллер может интерпретироваться как интерфейс между слоем домена и
слоем, например, пользовательского интерфейса.
Типичной ошибкой при создании контроллеров является возложение на них слишком
большого числа обязанностей.
Применение контроллеров позволяет упростить повторное использование
компонентов, а также обеспечить требуемую для того или иного прецедента
последовательность обработки системных событий.
Например, при добавлении новой книги пользователь на форме заполняет целый
набор полей: автор, название, аннотация, указывает расположение файла с обложкой,
расположение файла книги и т.д. Для каждого из этих полей может существовать отдельный
метод, отвечающий за добавление информации в БД, но порядок вызова методов и передача
им параметров должны осуществляться контроллером, которому в высокоуровневом
системном вызове передаются необходимые аргументы.
100
Рисунок 61 – Использование синтетического класса «Application Controller»
Таким образом, контроллер может использоваться, например, как средство
централизованного управления порядком отображения интерфейсных экранов или потока
функций приложения.
Если количество системных операций невелико, то ограничиваются применением
одного контроллера – «Контроллера Приложения». Если операций много, создают
отдельный контроллер для каждого прецедента.
Дальнейшим развитием шаблона Controller являются шаблон Facade, который
рекомендует создание единственной точки входа для всех служб подсистемы таким образом,
что все внешние объекты взаимодействуют с подсистемой через фасадный объект.
Одновременно с распределением обязанностей между классами с использованием
перечисленных выше паттернов, проводят уточнение (детализацию) диаграммы классов.
Классы дополняют атрибутами, при необходимости указывают их тип. Линии ассоциации
снабжают стрелкой навигации, которая указывает направление передачи информации от
объекта-источника к целевому классу. Сплошная линия ассоциативной связи используется,
когда один из атрибутов класса-источника является ссылкой на экземпляр целевого класса.
Кроме того, направленная ассоциация может означать создание объекта.
Пунктирные линии между классами обозначают отношение зависимости (dependency
relationship). Используется когда между классами существует локальная, глобальная или
видимость, обеспечиваемая с
помощью параметров.
Глобальная видимость используется редко. Она означает, что один объект является
глобальным по отношению к другому.
Локальная видимость между объектами (locally declared visibility) А и В существует в
том случае, если объект В объявлен в качестве локальной переменной в методе объекта А.
Видимость посредством параметров (parameter visibility) существует в том случае,
если
объект В передается в качестве параметра методу объекта А.