Введение в аналитические шаблоны и стили проектирования

Построение оптимальной архитектуры и последующая разработка информационных систем

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

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

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

Шаблон – это общее решение некоторой повторяющейся проблемы в определенном контексте.

Как мы определились ранее, важный аспект, связанный с шаблонами,–это то, они сопровождаются обоснованным бизнес-контекстом.

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

Ряд современных методик построения архитектуры выделяет шаблоны в качестве отдельного "слоя" архитектуры.

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

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

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

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

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

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

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

Организационное развитие и архитектура корпоративных информационных систем

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

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

Как сервис-ориентированная архитектура связана с вопросами организации и шаблонов проектирования программных продуктов?

Концепция сервис-ориентированной архитектуры была сформулирована в области ИТ, но в действительности это был ответ на актуальные потребности сегодняшнего дня, когда границы между бизнес-функциями организации и информационными технологиями размываются и они взаимопроникают. Лидеры отрасли информационных технологий, такие как Microsoft, IBM и другие, развивают SOA в рекомендациях по проектированию информационных систем на своих программных платформах. А такие гиганты консалтинга, как Gartner, полагают, что сервис-ориентированная архитектура –это ведущий принцип проектирования основных и прикладных систем для обеспечения бизнес-процессов.

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

• Явное отделение бизнес-логики от логики презентации информации.
• Реализация бизнес-логики прикладной системы в виде некоторого количества компонентов или сервисов, которые доступны извне пользователям или другим компонентам.
• Потребитель результатов, предоставляемых сервисом, может быть прикладной системой или другим сервисом и имеет возможность вызвать оригинальный сервис самостоятельно.

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

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

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

Дополнительным атрибутом, который подчеркивает значимость сервис-ориентированной архитектуры, является специализированный язык BPEL (Business Process Executable Language for Web Services) для описания аспектов взаимодействия различных сервисов с точки зрения реализации бизнес-логики. Внедрение SOA как архитектуры подразумевает конкретный подход к разработке приложений (SODA – Service-Oriented Development Architecture).

В этом подходе функциональность SOA реализуется на уровне ее компонентов –web-сервисов.

Под web-сервисами понимаются программные системы, которые используют:

• определенные технологии (XML) для формата данных;
• стандарты Web Services Description Language (WSDL) для описания своих интерфейсов;
• Simple Object Access Protocol (SOAP) для описания формата принимаемых и посылаемых сообщений.

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

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

• Хореография. Определяет взаимодействие различных участников с использованием сервисов.
• Оркестровка. Описывает взаимодействие сервисов в рамках одного бизнес-процесса, в частности, с использованием языка типа BPEL.

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

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

В сервис-ориентированной архитектуре следует выделить следующие уровни, обеспечивающие ее функционирование:

• Презентационный уровень. Описывает сервисы, используемые для взаимодействия пользователей с информационной системой. Включает в себя корпоративные и публичные порталы, доступ с мобильных устройств, а также различные преобразования информации при взаимодействии с внешними системами и устройствами.
• Уровень бизнес-сервисов. Формирует модели и осуществляет управление выполнением бизнес-процессов предприятия с использованием специализированных средств, а также "хореографию" и "оркестровку" операций.
• Уровень интеграции. Сервисы данного уровня обеспечивают взаимодействие между приложениями, которое может быть реализовано с использованием средств обмена сообщениями или в рамках единой среды исполнения.
• Уровень данных. Реализуют средства извлечения и повторного использования данных из СУБД и приложений. Выделение этого уровня позволяет изолировать вышестоящие компоненты архитектуры от изменений в технологиях, а также обеспечить единый унифицированный подход к выполнению операций с данными.
• Уровень инфраструктуры, приложений и СУБД. Является основой для всей структуры. Здесь концентрируются основные инвестиции в ИТ.

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

Данная модель выделяет дополнительную компоненту архитектуры, которая описывает аспекты, связанные с жизненным циклом сервисов. MDA (Model Driven Architecture) является еще одной важной архитектурной концепцией создания информационных систем.

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

MDA по определению является открытой и "нейтральной" по отношению к используемым технологиям интеграции. Она основана на следующих принципах:

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

В рамках MDA сначала создается архитектура, которая описывает модель бизнес-функциональности и поведения прикладной системы независимо от технических деталей реализации. Эта разработка должна вестись в контексте всей организации. Метамодель, не зависящая от платформы реализации, может быть разработана в одном или нескольких специфических вариантах для конкретной платформы. Это зависит от важности уже используемых платформ. На основе этих моделей разрабатывается код конкретной прикладной системы.

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

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