РАЦИОНАЛЬНЫЙ ПРОЦЕСС АРХИТЕКТУРНОГО МОДЕЛИРОВАНИЯ

Архитектурные парадигмы

В публикациях по архитектуре ПО поднимаются вопросы о парадигмах (совокупности фундаментальных установок, представлений и терминов) ПО как «модели постановки проблемы и ее решения», определяющей основные подходы к проблемам архитектуры [28, 29, 30].

Особую известность в этом получили следующие парадигмы [2].

• 1. Объектно-ориентированная парадигма, в рамках которой используется объектно-ориентированный подход (ООП) к структуризации ПО на всех этапах ее жизненного цикла.
• 2. Компонентно-ориентированная парадигма, исходящая из принципов сборочного проектирования, конструирования и производства ПО, в основе которых лежат программные «компоненты» как единицы сборки.
• 3. Сервисно-ориентированная парадигма, применение которой базируется на идее массового сервисного обслуживания пользователей ПО по их запросам.

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

Объектно-ориентированная парадигма

В основе этой парадигмы лежат идеи, методы и средства объектно-ориентированного анализа и проектирования (ООАП). Наиболее последовательно эта парадигма раскрыта в методологии унифицированного процесса разработки и комплексе инструментально-технологических средств Rational Unified Process (RUP) [31J. Если ПО разработана в такой среде, то говорят, что она имеет объектно-ориентированную архитектуру (ООА, Object-Oriented Architecture).

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

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

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

• • интерфейс — совокупность доступных извне элементов реализации абстракции (основные характеристики состояния и поведения);
• • реализация — совокупность недоступных извне элементов реализации абстракции (внутренняя организация абстракции и механизмы реализации ее поведения).

Ограничение доступа в ООП позволяет разработчику:

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

Сочетание объединения всех свойств предмета (составляющих его состояния и поведения) в единую абстракцию и ограничения доступа к реализации этих свойств получило название инкапсуляции.

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

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

В ООП используются два вида иерархии.

Иерархия «целое/часть» показывает, что некоторые абстракции включены в рассматриваемую абстракцию как ее части, например, лампа состоит из цоколя, нити накаливания и колбы. Этот вариант иерархии используется в процессе разбиения системы на разных этапах проектирования (на логическом уровне — при декомпозиции предметной области на объекты, на физическом уровне — при декомпозиции системы на модули и при выделении отдельных процессов в мультипроцессной системе).

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

Один из важнейших механизмов ООП — наследование свойств, в иерархии «общее/частное». Наследование — такое соотношение между абстракциями, когда одна из них использует структурную или функциональную часть другой или нескольких других абстракций (соответственно простое и множественное наследование).

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

Использование принципа типизации обеспечивает:

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

Тип может связываться с программным объектом статически (тип объекта определен на этапе компиляции — раннее связывание) и динамически (тип объекта определяется только во время выполнения программы — позднее связывание). Реализация позднего связывания в языке программирования позволяет создавать переменные — указатели на объекты, принадлежащие различным классам (полиморфные объекты), что существенно расширяет возможности языка.

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

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

Различают:

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

Наиболее хорошим примером ООА является Common Object Request Broker Architecture (CORBA) [32], разработанная группой OMG. CORBA определяет объектную модель, в соответствии с которой распределенные объекты должны создаваться, использоваться и управляться. CORBA также определяет Reference Architecture (как систему образцов и инструкций), раскрывающую, «как достигается взаимодействие между распределенными объектами». Для этих целей предлагается язык определения интерфейсов (Interface Definition Language, IDL). Объект клиента получает связь с объектом сервера, после чего он в состоянии активизировать его методы тем же самым образом, как и методы локальных объектов.

ООА может быть представлена различными совокупностями видов. Одной из наиболее распространенных таких совокупностей является система видов Ф. Кратчена «4+1 views» [33]. Для описания видов обычно используются средства языка UML.

Компонентно-ориентированная парадигма

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

Промышленное производство компонентов, а также платформы, подобные J2EE, CORBA Component Model и Microsoft.Net, перевели компонентно-ориентированную парадигму (и основанную на этой парадигме версию разработки Component-base software development (CBSD)) в практическое русло. Говорят, что системы, разработанные на основе CBSD, имеют компонентно-ориентированную архитектуру (КОА, Component-Based Architecture, СВА).

К числу основных характеристик КОА (СВА) относятся:

• • опора на компонентные модели (подобные CORBA Component Model);
• • компоненты являются основными единицами моделирования, проектирования и реализации;
• • интерфейсы и взаимодействие находятся в центре интересов разработки архитектуры ПО;
• • интерфейсы могут обслуживать различные компоненты (интерфейсы поддерживают их расширение и специализацию, в том числе и в формах наследования);
• • компонентные модели требуют от компонентов поддержки «действий по самоанализу» так, чтобы их функциональности или свойства могли быть открыты и использованы «во время сборки» или в реальном времени;
• • особое внимание уделяется образцам проектирования и принципам разделения интересов для определения роли компонента и его ответственности.

Компонентная модель также включает программную модель, поясняющую, как распределенные компоненты должны быть разработаны, собраны и размешены на физическом оборудовании. Кроме CORBA Component Model (ССМ) на практике широко используются JavaBeans и Enterprise JavaBeans в рамках Java 2 Enterprise Edition (J2EE) [34J.

Для представления СВА могут быть использованы различные совокупности видов, например совокупность, использованная в стандарте для RM-ODP. Для описания видов часто используют средства UML 135, 36J.

Сервисно-ориентированная парадигма

Большой класс ПО, особенно реализованных в виде WEB-прило-жений, разрабатывают как системы сервисов, к которым открыт оперативный доступ клиентов. Про систему такого рода говорят, что для ее разработки использовалась сервисно-ориентированная архитектура (СОА, Service-Based Architecture, SBA).

К числу основных характеристик СОА (SBA) относятся [2]:

• • свободное соединение, заключающееся в том, что любой сервис может быть получен как ответ на запрос из любого (разрешенного) источника;
• • для сервиса не требуется ничего запоминать от одного вызова до другого (состояния загружаются как часть данных сервиса из базы данных или поступают от запросчика сервиса);
• • сервисы являются основными единицами моделирования, проектирования и реализации;
• • определение, описание, открытие сервиса, протоколы доступа и аспекты качества являются центральными интересами в архитектурном проектировании ПО;
• • сервис «выставляет напоказ» свои возможности, включая функциональность, данные и характеристики качества сервисов через описание на специальных языках, таких как язык описания WEB-сервисов (Web Service Description Language, WSDL);
• • сервис может быть независимо и динамически обнаружен (открыт) и использован;
• • так как сервис не имеет состояний, то обмен данными между распределенными пользователями и провайдерами может привести к существенным накладным расходам.

Сервис может быть реализован с использованием компонентно-ориентированных технологий или объектно-ориентированных технологий. Описание сервиса обычно регистрируется в базе сервисов в определенном формате, например в таком, как Universal Description, Discovery and Integration (UDDI). С одной стороны, SBA может быть представлена с помощью средств RM-ODP и UML, однако необходимо помнить, что эти средства не совсем адекватны задаче моделирования сервисов.

Для описания сервисов более подходят специализированные языковые средства, такие как WSDL.

К месту отметить, что ООА, СВА и SBA предоставляют различные возможности и выгоды и могут быть использованы взаимодополнительно. С точки зрения функциональности сервис может быть реализован с помощью совокупности компонентов с учетом необходимых характеристик качества. В то же время функциональность компонента может быть структурирована в объектно-ориентированном виде и реализована с помощью объектно-ориентированного алгоритмического языка. Однако каждая из пара-дигм имеет специфику в представлении архитектуры ПО.

Как результат сопоставления парадигм, предлагаются следующие практические принципы для разработки архитектуры ПО [2, 37, 38, 39J.

Первый принцип нацеливает разработчиков на то, чтобы понять приложение и очертить его границы.

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

Третий принцип указывает на необходимость первоочередного построения Use Case сценариев для интерфейсов, которые являются ключевыми понятиями в каждой из представленных парадигм. Сценарии помогут прояснить роли, ответственность, характеристики взаимодействия и ожидаемые свойства базовых единиц разработки, а также помогут идентифицировать, какой из трех типов единиц (объекты, компоненты, сервисы) является наиболее подходящим для разрабатываемой ПО.

Применяя принципы в рамках определенной стратегии, необходимо помнить, что совокупность парадигм, используемых в конкретной разработке, не исчерпывается вариантами ООА, СВА и SBA и открыта для модификаций и дополнений.