Распределение обязанностей с использованием UML

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

Обязанности

Обязанности
Операция => Обязанность
Обязанность ≠> Операция

Обязанности
на диаграммах взаимодействия

GRASP
Шаблоны GRAS или GRASP – General Responsibility Assignment Software Patterns
Информационный эксперт (Information Expert)
Создатель (Creator)
Высокое зацепление (High Cohesion)
Слабое связывание (Low Coupling)
Контроллер (Controller)
Полиморфизм (Polymorphism)
Чистая выдумка (Pure Fabrication)
Посредник (Indirection)
Сокрытие реализации (Protected Variations)

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

Информационный эксперт
GetTotalPrice()
?
!

Информационный эксперт

Информационный эксперт
Требуемая обязанность:
Знать и предоставлять общую сумму продажи.
Итоговое распределение обязанностей:

Информационный эксперт
Выводы
Самый часто используемый шаблон распределения обязанностей.
Аналогия с реальным миром.
Существование «частичных» экспертов.

Информационный эксперт
Преимущества
Поддерживает инкапсуляцию
Поведение обеспечивается несколькими классами, содержащими требуемую информацию => простота понимания и поддержки.

Информационный эксперт
не следует применять
В тех случаях, когда это нарушает связывание и сцепление.
SQL

Создатель
Проблема:
Кто должен отвечать за создание нового экземпляра некоторого класса?
Решение:
Назначить классу B обязанность создавать экземпляры класса A, если выполняется одно из следующих условий:
Класс B агрегирует объекты A.

Создатель
Класс B содержит объекты A.
Класс B записывает экземпляры объектов A.

Создатель
Класс B активно использует объекты A.
Класс B обладает данными инициализации объектов A.
Класс B – создатель объектов A.

Создатель
AddLineItem()
?
!

Создатель

Создатель
Выводы
Самый распространенный способ распределения обязанностей, связанных с созданием объектов – простота выявления объекта-создателя, при сохранении низкой степени связанности.
Создатель, содержащий данные инициализации – шаблон Информационный эксперт.

Создатель
не следует применять
Когда создание – сложная операция, выполняемая при реализации некоторого условия на основе каких-либо внешних свойств.
В этом случае предпочтительнее использовать шаблон Фабрика (Factory).

Создатель
Преимущества
Не повышает степень связанности, так как созданный объект обычно оказывается видимым для объекта-создателя.

Слабое связывание(Low Coupling)
Проблема:
Как обеспечить минимальную зависимость, минимальный риск изменений и повышенное повторное использование?
Связывание – мера того, насколько сильно элементы связаны, зависят друг от друга.
Сильное связывание приводит к проблемам:
Изменения в одном классе влекут необходимость в изменении другого
Сложность понимания элемента в изоляции от других
Сложность повторного использования

Слабое связывание(Low Coupling)
Паттерн «Создатель» нам диктует:
Но можно поразмыслить:

Слабое связывание(Low Coupling)
Классы ClassX и ClassY могут быть связаны:
ClassX имеет атрибут, который ссылается на ClassY
ClassX содержит операцию, которая ссылается на ClassY (использует экземпляр класса в качестве параметра, переменной или возвращаемого значения)
ClassX – непосредственный потомок ClassY
ClassY – интерфейс, а ClassX его реализует

Слабое связывание(Low Coupling)
Применение
Применяется вместе с другими паттернами (такими как Высокое зацепление и Эксперт)
Применяется в случае «нестабильности» в эволюционном смысле слова. Не применяется в отношении к классам статических библиотек.
Применяется в разумных пределах

Слабое связывание(Low Coupling)
Результаты
Решение проблемы
Классы не зависят от изменений в других классах
Классы легко понимаемы вне контекста
Классы удобны для повторного использования

Высокое зацепление (High cohesion)
Проблема
Как управлять необъятным?
Зацепление – мера того, насколько взаимосвязаны и целенаправленны обязанности, возложенные на элемент.
Элемент с взаимосвязанными обязанностями обладает высоким зацеплением.
Слабое зацепление приводит к проблемам:
Класс трудно «познать»
Класс трудно использовать повторно
Класс трудно поддерживать
Класс «нежен»

Высокое зацепление (High cohesion)
Мы снова доверяемся паттерну «Создатель»

Высокое зацепление (High cohesion)
Но тогда Register может разбухнуть!
Попробуем все же вот так:

Высокое зацепление (High cohesion)
Классификация зацеплений (by Grady Booch)
Очень низкое зацепление (RDB-RPC-Interface)
Низкое зацепление (RDB-Interface)
Высокое зацепление
Умеренное зацепление (Company)

Высокое зацепление (High cohesion)
Зацепление и связывание
Инь и Янь программной инженерии
Исключения
Упрощение обслуживания одним человеком (ICQ Expert)
Удаленные операции

Высокое зацепление (High cohesion)
Результаты
Ясность и простота понимания дизайна
Упрощение поддержки и эволюции
Слабое связывание в подарок
Повторное использование

Контроллер
Проблема
Кто должен быть ответственен за обработку системных событий ввода?
Системное сообщение ввода– сообщение, сгенерированное внешним актером. Они ассоциированы с операциями системы в ответ на событие.

Контроллер

Контроллер
Варианты контроллера
Фасадный контроллер - представляет всю систему(или подсистему) в совокупности
Register
Название, соответствующее системе (ChessGame)
Контроллер варианта использования представляет ВИ, в пределах которого возникают сообщения.
Handler

Контроллер
Выбор контроллера
Фасадный контроллер
Малое количество событий
UI не может перенаправить системные сообщения на переменные контроллеры (как в системах обработки сообщений)
Контроллер ВИ
Большое количество событий
Необходимо поддерживать логику ВИ
UI не должны быть ответственны за события ввода!

Контроллер

Не контроллер

Контроллер
Результаты
Логика приложения отделена от интерфейса
Повторное использование
Учет состояния варианта использования

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

Благодарность
Creig Larman, за его интереснейшую книгу “Applying UML and patterns”.

Благодарность
Гради Бучу, за то, что учил Крэга Лармана. И за то, что научил.

Благодарность
А.Ю. Шелестову, за перевод замечательной книги Крэга Лармана на русский язык («Применение UML и шаблонов проектирования»).

Благодарность
Google Search, за его релевантную выдачу.

Благодарность
Ru.wikipedia.org, за понимание темы в целом.

Благодарность
Пакету Microsoft Office 2007, за прекрасные инструменты создания презентаций.

Благодарность
И, конечно, отдельное спасибо компании Blizzard, за ее бессмертные игры.