Содержание курса

ВВЕДЕНИЕ
Введение в процесс формирования требований
Инфраструктура (ландшафт) для организации проектной деятельности
Управление целями заинтересованных лиц
Формализация потребностей заказчика
Выявление функции системы. 1.Теория систем
Выявление функции системы. 2. Моделирование сервисов
Инжиниринг бизнес-процессов заказчика. 1. Применение UML Activity
Инжиниринг бизнес-процессов заказчика. 2. Применение BPMN. Предварительный расчет ресурсоемкости проекта.
Разработка логической структуры данных. 1. Применение UML Class diagram. Приемы и подходы проектирования
Разработка логической структуры данных. 2. Паттерны проектирования применительно к структуре данных.
Моделирование поведения целевой системы. Моделирование процессов управления
Формирование спецификаций требований на создание целевой ИС
Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта
Организация процессов проектирования в производстве ИТ-продукта

6. Паттерны проектирования применительно к сущностям

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10¹²⁰. Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10⁷⁸ до 10⁸² атомов.

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

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

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

Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов.

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

Предполагает обычно использование двух таблиц:

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

Если нам необходимо использовать множество небольших Справочников, например, «Приоритет», «Тип Бронирования», «Вид заявки», «Тип читателя», "Пол" и прочие, то добавление класса для каждого такого справочника приведет к созданию большого количества объектов, которые придется поддерживать. Какие же есть альтернативы?

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

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

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

Удобно применять если необходимо:

Организовать иерархию объектов (например, папки и файлы).
Иметь возможность работать единообразно как с одним файлом, так и с целой папкой.
Проводить операции рекурсивно: считать размер папки, удалить всё внутри, найти что-то и т.д.

В качестве примера, можно рассмотреть универсальный Классификатор, который представляет из себя класс группы и класс «значений», входящих в группу (соответствует паттерну Приспособленец). Для присваивания значения классификатора некому объекту, используется класс «Классификация объекта», который сопоставляет в себе ссылки на: 1)Группу классификатора, 2)Значение классификатора и на 3)Объект системы, к которому применяется классификация с указанием содержания(значения). Да, структура денормализованая, но в этом решении есть свои нюансы. При этом таблица Классификатор содержит рекурсивную ссылку на себя и позволяет строить древовидную структуру. Так же для управления правилами выбора можно использовать дополнительные характеристики. Например, "Один из", указывающую на возможность выбрать только одно или множество значений из группы и характеристика "Можно выбрать", указывающая на возможность /невозможность выбрать элемент на текущем уровне иерархии.

Как можно привести рассмотренную модель к Нормальным формам (NF)? Какие преимущества в данном контексте дает денормализованная форма?

Заместитель (Proxy) - это структурный паттерн, который ставит объект-посредник между клиентом и реальным объектом.

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

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

Примеры применения паттерна Заместитель:

Virtual Proxy - Лениво загружает файлы или каталоги только при обращении
Protection Proxy - Проверяет права пользователя перед доступом к данным
Remote Proxy - Делает вид, что работает с локальным хранилищем, но на самом деле — через сеть (например, через API)
Caching Proxy - Кэширует файлы, метаданные или результаты запросов
Logging Proxy - Логирует все обращения к данным

Фасад (Facade) - структурный паттерн проектирования, который предоставляет упрощённый интерфейс к сложной подсистеме.

То есть, вместо того чтобы клиент "разрывался" между разными сервисами, классами, модулями, он работает через одно общее «окно доступа».

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

Состояние - Используется в тех случаях, когда во время выполнения программы объект должен менять своё поведение в зависимости от своего состояния.

Например, в зависимости от текущего статуса книги, для нее доступна одна из операций «Выдача» или «Возврат».

Преимущества паттерна Состояние для хранилищ:

Поведение хранилища чётко связано с текущим состоянием, без нагромождения условных переходов.
Легко добавлять новые состояния без переписывания всей логики.
Повышается читаемость и расширяемость кода.
Удобно покрывать тестами каждое состояние отдельно.

Паттерн Состояние очень удобно использовать совместно с диаграммами BPMN, для "умного" выбора действия над объектом, из доступного ассортимента в текущем состоянии . В следующей части мы будем разбирать поведенческие модели и в том числе диаграмму Состояний.

Коллаборация паттернов Фасад (Facade) / Состояние (State)

1) Фасад (StorageFacade) — это единая точка входа для клиента. Клиенту не нужно знать о состоянии, он просто вызывает метод.

2) Состояние (StorageState) — определяет, как именно работают методы в зависимости от текущего состояния хранилища:

инициализация,
рабочее состояние,
ошибка,
миграция и т.д.

3) Фасад внутри себя держит ссылку на состояние и перекидывает вызовы методам состояния.

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

Иными словами, можно копировать существующий объект в новый, вместо его создания с "0". Это быстро, удобно, без необходимости всё настраивать заново.

При этом используется инструмент - "Реестр прототипов", представляющий хранилище (словарь), где мы:

1) регистрируем прототипы (например, LocalStorage, S3Storage, InMemoryStorage);

2) по запросу клонируем нужный прототип;

3) при необходимости — донастраиваем клоны.

7. Адаптивные модели данных

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

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

Шаблонный метод (Template method) - паттерн проектирования (поведенческий), который: определяет скелет алгоритма в методе базового класса, а отдельные шаги этого алгоритма делегирует на переопределение в подклассы.

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

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

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

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

В следующей части мы рассмотрим моделирование поведения.

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.2. Шаблонный подход