
- •5. Архитектурные особенности проектирования и разработки Веб-приложений
- •5.1. Архитектура информационных систем
- •5.1.1. Общие сведения
- •5.1.2. Централизованная архитектура
- •5.1.3. Архитектура "файл-сервер"
- •5.1.4. Архитектура "клиент-сервер"
- •5.1.5. Многоуровневый "клиент-сервер"
- •5.1.6. Архитектура распределенных систем
- •5.1.7. Архитектура Веб-приложений
- •5.1.8. Сервис-ориентированная архитектура
- •5.1.9. Ключевые термины
- •5.2. Шаблоны проектирования
- •5.2.1. Общие сведения
- •5.2.2. Обзор паттернов
- •5.2.2.1. Паттерны проектирования классов/объектов
- •5.2.2.1.1. Структурные паттерны (Structural)
- •5.2.2.1.2. Паттерны проектирования поведения (Behavioral)
- •5.2.2.1.3. Порождающие паттерны проектирования
- •5.2.2.2. Архитектурные системные паттерны
- •5.2.2.2.1. Структурные паттерны
- •5.2.2.2.2. Паттерны управления
- •5.2.2.2.3. Паттерны, предназначенные для представления данных в Web
- •5.2.2.3. Паттерны интеграции корпоративных информационных систем
- •5.3.2. Ключевые термины
- •5.4. Краткие итоги
5.1.9. Ключевые термины
Архитектура, Централизованная архитектура, Архитектура "файл-сервер", Двухзвенная архитектура "клиент-сервер", , Терминал, Сервер приложений, Сервер базы данных, Архитектура распределенных систем, Архитектура Веб-приложений, Сервис-ориентированная архитектура.
5.2. Шаблоны проектирования
5.2.1. Общие сведения
В качестве основы проектирования информационных систем применяются "типовые решения" или "шаблоны проектирования" (Patterns).
Шаблоны проектирования (паттерн, design pattern) – это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения [22].
Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код, скорее это описание или образец для того, как решить задачу, таким образом, чтобы это можно было использовать в различных ситуациях. Объектно-ориентированные шаблоны зачастую показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться. Алгоритмы не рассматриваются как шаблоны, так как они решают задачи вычисления, а не проектирования.
В 1970-е годы архитектор Кристофер Александр составил набор шаблонов проектирования [23]. В области архитектуры эта идея не получила такого развития, как позже в области программной разработки. Согласно определению Кристофера Александера: "Каждое типовое решение описывает некую повторяющуюся проблему и ключ к ее разгадке, причем таким образом, что вы можете пользоваться этим ключом многократно, ни разу не придя к одному и тому же результату" [18].
В 1987 году Кент Бэк и Вард Каннигем взяли идеи Александра и разработали шаблоны применительно к разработке программного обеспечения для разработки графических оболочек на языке Smalltalk.
В 1988 году Эрих Гамма начал писать докторскую диссертацию при Цюрихском университете об общей переносимости этой методики на разработку программ.
В 1989-1991 годах Джеймс Коплин трудился над разработкой идиом для программирования на C++ и опубликовал в 1991 году книгу Advanced C++ Idioms. В этом же году Эрих Гамма заканчивает свою докторскую диссертацию и переезжает в США, где в сотрудничестве с Ричардом Хелмом, Ральфом Джонсоном и Джоном Влиссидсом публикует книгу Design Patterns – Elements of Reusable Object-Oriented Software [24]. В этой книге описаны 23 шаблона проектирования. Также команда авторов этой книги известна общественности под названием Банда четырех (Gang of Four, часто сокращается до GoF). Именно эта книга стала причиной роста популярности шаблонов проектирования.
Другим видным деятелем в области проектирования программных систем, который поддержал использование паттернов, является Мартин Фаулер, написавший книгу "Архитектура корпоративных программных приложений" (Patterns of Enterprise Application Architecture). Как отметил Мартин Фаулер в своей книге "собираясь воспользоваться типовыми решениями, не забывайте, что они только отправная точка, а не пункт назначения" [18].
В книге Крейга Лармана "Применение UML и шаблонов проектирования" описано 9 шаблонов GRASP (General Responsibility Assignment Software Patterns, общие образцы распределения обязанностей) – паттернов, используемых в объектно-ориентированном проектировании для решения общих задач по назначению обязанностей классам и объектам. Каждый из них помогает решить некоторую проблему, возникающую при объектно-ориентированном анализе, и которая возникает практически в любом проекте по разработке программного обеспечения.
Главная польза каждого отдельного шаблона состоит в том, что он описывает решение целого класса абстрактных проблем. Также тот факт, что каждый шаблон имеет свое имя, облегчает дискуссию об абстрактных структурах данных (ADT) между разработчиками, так как они могут ссылаться на известные шаблоны. Таким образом, за счет шаблонов производится унификация терминологии, названий модулей и элементов проекта.
Правильно сформулированный шаблон проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова.
Однако иногда шаблоны консервируют громоздкую и малоэффективную систему понятий, разработанную узкой группой. Когда количество шаблонов возрастает, превышая критическую сложность, исполнители начинают игнорировать шаблоны и всю систему, с ними связанную. Нередко шаблонами заменяется отсутствие или недостаточность документации в сложной программной среде.
Есть мнение, что слепое применение шаблонов из справочника, без осмысления причин и предпосылок выделения каждого отдельного шаблона, замедляет профессиональный рост программиста, так как подменяет творческую работу механическим подставлением шаблонов. Люди, придерживающиеся данного мнения, считают, что знакомиться со списками шаблонов надо тогда, когда "дорос" до них в профессиональном плане – и не раньше. Хороший критерий нужной степени профессионализма – выделение шаблонов самостоятельно, на основании собственного опыта. При этом, разумеется, знакомство с теорией, связанной с шаблонами, полезно на любом уровне профессионализма и направляет развитие программиста в правильную сторону. Сомнению подвергается только использование шаблонов "по справочнику".
Шаблоны могут пропагандировать плохие стили разработки приложений, и зачастую слепо применяются.
Шаблоны проектирования классифицируют следующим образом [18, 25]:
Паттерны проектирования классов/объектов
Структурные паттерны проектирования классов/объектов
Адаптер (Adapter) – GoF
Декоратор (Decorator) или Оболочка (Wrapper) – GoF
Заместитель (Proxy) или Суррогат (Surrogate) – GoF
Информационный эксперт (Information Expert)- GRASP
Компоновщик (Composite) – GoF
Мост (Bridge), Handle (описатель) или Тело (Body) – GoF
Низкая связанность (Low Coupling) – GRASP
Приспособленец (Flyweight) – GoF
Устойчивый к изменениям (Protected Variations) – GRASP
Фасад (Facade) – GoF
Паттерны проектирования поведения классов/объектов
Интерпретатор (Interpreter ) – GoF
Итератор (Iterator) или Курсор (Cursor) – GoF
Команда (Command), Действие (Action) или Транзакция (Транзакция) – GoF
Наблюдатель (Observer), Опубликовать – подписаться (Publish – Subscribe) или Delegation Event Model – GoF
Не разговаривайте с неизвестными (Don't talk to strangers) – GRASP
Посетитель (Visitor) – GoF
Посредник (Mediator) – GoF
Состояние (State) – GoF
Стратегия (Strategy) – GoF
Хранитель (Memento) – GoF
Цепочка обязанностей (Chain of Responsibility) – GoF
Шаблонный метод (Template Method) – GoF
Высокое зацепление (High Cohesion) – GRASP
Контроллер (Controller) – GRASP
Полиморфизм (Polymorphism) – GRASP
Искусственный (Pure Fabrication) – GRASP
Перенаправление (Indirection) – GRASP
Порождающие паттерны проектирования
Абстрактная фабрика (Abstract Factory, Factory), др. название Инструментарий (Kit) – GoF
Одиночка (Singleton) – GoF
Прототип (Prototype) – GoF
Создатель экземпляров класса (Creator) – GRASP
Строитель (Builder) – GoF
Фабричный метод (Factory Method) или Виртуальный конструктор (Virtual Constructor) – GoF
Архитектурные системные паттерны
Структурные паттерны
Репозиторий
Клиент/сервер
Обьектно – ориентированный, Модель предметной области (Domain Model), модуль таблицы (Data Mapper)
Многоуровневая система (Layers) или абстрактная машина
Потоки данных (конвейер или фильтр)
Паттерны управления
Паттерны централизованного управления
Вызов – возврат (сценарий транзакции – частный случай)
Диспетчер
Паттерны управления, основанные на событиях
Передача сообщений
Управляемый прерываниями
Паттерны, обеспечивающие взаимодействие с базой данных
Активная запись (Active Record)
Единица работы (Unit Of Work)
Загрузка по требованию (Lazy Load)
Коллекция объектов (Identity Map)
Множество записей (Record Set)
Наследование с одной таблицей (Single Table Inheritance)
Наследование с таблицами для каждого класса (Class Table Inheritance)
Оптимистическая автономная блокировка (Optimistic Offline Lock)
Отображение с помощью внешних ключей
Отображение с помощью таблицы ассоциаций (Association Table Mapping)
Пессимистическая автономная блокировка (Pessimistic Offline Lock)
Поле идентификации (Identity Field)
Преобразователь данных (Data Mapper)
Cохранение сеанса на стороне клиента (Client Session State)
Cохранение сеанса на стороне сервера (Server Session State)
Шлюз записи данных (Row Data Gateway)
Шлюз таблицы данных (Table Data Gateway)
Паттерны, предназначенные для представления данных в Web
Модель-представление-контроллер (Model View Controller)
Контроллер страниц (Page Controller)
Контроллер запросов (Front Controller)
Представление по шаблону (Template View)
Представление с преобразованием (Transform View)
Двухэтапное представление (Two Step View)
Контроллер приложения (Application Controller)
Паттерны интеграции корпоративных информационных систем
Структурные паттерныны интеграции
Взаимодействие "точка – точка"
Взаимодействие "звезда" (интегрирующая среда)
Смешанный способ взаимодействия
Паттерны по методу интеграции
Интеграция систем по данным (data-centric)
Функционально-центрический (function-centric) подход
Объектно-центрический (object-centric)
Интеграция на основе единой понятийной модели предметной области (concept-centric)
Паттерны интеграции по типу обмена данными
Файловый обмен
Общая база данных
Удаленный вызов процедур
Обмен сообщениями
Также на сегодняшний день существует ряд других шаблонов [22]:
Carrier Rider Mapper, предоставление доступа к хранимой информации;
аналитические шаблоны, описывают основной подход для составления требований для программного обеспечения (requirement analysis) до начала самого процесса программной разработки;
коммуникационные шаблоны, описывают процесс общения между отдельными участниками/сотрудниками организации;
организационные шаблоны, описывают организационную иерархию предприятия/фирмы;
Анти-паттерны (Anti-Design-Patterns) описывают как не следует поступать при разработке программ, показывая характерные ошибки в дизайне и в реализации;
и др.
Рассмотрим подробнее некоторые из паттернов проектирования.