АРХИТЕКТУРА С ТЕХНИЧЕСКОЙ ТОЧКИ ЗРЕНИЯ

АРХИТЕКТУРА С ТЕХНИЧЕСКОЙ ТОЧКИ ЗРЕНИЯ

Архитектура ПО обсуждается на протяжении всего последнего десятилетия, однако прийти к единым определениям, терминологии и принципам пока не удалось. Следующее ниже обсуждение развивает общие основы архитектуры, разработанные в корпорации Rational Software, и, в частности, концепции архитектуры ПО Филиппа Кручтена [Kruchten, 1995].
Архитектура ПО заключает в себе структуру программных систем (выбор элементов и их объединение в более крупные подсистемы), их поведение (взаимодействие между элементами) и образцы, которые управляют этими элементами, их взаимодействиями и их сочетанием. Контекст структуры, поведения и образцов ПО должен включать в себя функциональные возможности, производительность, устойчивость к внешним воздействиям, понятность, экономические соглашения, технологические ограничения и вопросы эстетики.
Архитектурная схема описывается в терминах представлений (views), которые являются абстракциями проектных UML-моделей. Проектная модель (design model) включает в себя всю полноту и глубину информации. Архитектурное представление — это абстракция проектной модели; в нем содержится только информация, значимая для архитектуры. Для большинства реальных систем требуются четыре различных представления: с точки зрения проекта, процессов, компонентов и внедрения. Их задачи могут быть описаны следующим образом:.
■ Проект: описывает архитектурно значимые структуры и функции, отраженные в проектной модели.
■ Процесс: описывает взаимосвязь между параллелизмом и потоками управления, с одной стороны, и остальными представлениями, с другой стороны.
■ Компоненты: описывает структуру рабочих продуктов, касающихся реализации.
■ Внедрение: описывает структуру рабочих продуктов, касающихся внедрения.
Представление с точки зрения проекта, вероятно, необходимо для каждой системы; остальные три представления могут добавляться в случае сложных систем. Например, для каждой распределенной системы.
потребуется представление с точки зрения процессов и представление с точки зрения внедрения. Большим системам, а также смешанным системам, состоящим из компонентов, изготовленных на заказ, и коммерческих компонентов, потребуется отдельное представление с точки зрения компонентов.
На рис. 7.1 показаны все рабочие продукты, входящие в проектный комплект, включая архитектурные представления и описание архитектуры. Описание архитектуры обычно хранится в электронном виде, но всегда поддерживается таким образом, что может быть распечатано в виде отдельного связного документа. Рабочие модели и архитектурные представления определяются как наборы UML-диаграмм.
Модель требований представляет поведение системы так, как это видится ее конечным пользователям, аналитикам и тестировщикам. Это представление моделируется статически с применением диаграмм вариантов использования и классов, а также динамически с применением диаграмм последовательности, состояния, деятельности и кооперативных диаграмм.
■ Представление вариантов использования описывает, каким образом критичные для системы (архитектурно значимые) варианты использования реализуются с помощью элементов проектной модели. Оно моделируется как статически — с применением диаграмм вариантов использования, так и динамически — с помощью любых UML-диграмм поведения.
Проектная модель описывает архитектуру системы и разработку ее компонентов в рамках данной архитектуры, включая функциональную структуру, структуру параллельных процессов, структуру реализации и функционирования для области решения, так, как это видится ее разработчикам. Статические описания снабжаются структурными диаграммами (диаграммами классов, объектов, компонентов, размещения). Динамические описания снабжаются любыми UML-диаграммами поведения (кооперативными диаграммами, диаграммами последовательности, состояния и деятельности).
■ Проектное представление описывает архитектурно значимые элементы проектной модели. Это представление является абстракцией проектной модели и касается основной структуры и функциональности системы. Оно моделируется статически с использованием диаграмм объектов и классов, а также динамически с применением любых UML-диаграмм поведения.
■ Представление процессов связано с проблемами взаимодействия в период выполнения, касающимися реализации архитектуры с помощью распределенной модели среды эксплуатации, включая логическую топологию сети ПО (распределение процессов и потоков (threads) управления), межпроцессное взаимодействие и управление состоянием. Это представление моделируется как статически — с использованием диаграмм размещения, так и динамически — с применением любых UML-диаграмм поведения.
Рис. 7.1. Архитектура: организованное и абстрактное представление проектных моделей.
■ Представление компонентов описывает архитектурно значимые элементы комплекта реализации. Это представление является абстракцией проектной модели и касается реализации исходного кода ПО с точки зрения системных интеграторов и разработчиков, особенно с учетом версий и управления конфигурацией. Оно моделируется как статически — с использованием диаграмм компонентов, так и динамически — с применением любых UML-диаграмм поведения.
■ Представление внедрения имеет отношение к исполняемой реализации системы, включая распределение логических процессов (логическая топология ПО) по физическим ресурсам сети в среде эксплуатации (физическая топология системы). Это представление моделируется как статически — с использованием диаграмм размещения, так и динамически — с применением любых UML-диаграмм поведения.
Описания архитектуры принимают различные формы и виды в разных организациях и областях знаний. В любой конкретный момент времени архитектуре требуются подмножества рабочих продуктов из всех комплектов, касающихся разработки. Реальный уровень содержимого в каждом комплекте зависит от конкретной ситуации, и существует очень немного хороших эвристических подходов для объективного описания того, что является архитектурно значимым, а что — нет.
Вообще говоря, базовая архитектура должна включать в себя следующее:.
■ Требования: критичные варианты использования, требуемое качество на уровне системы в целом и приоритетные связи между возможностями и качествами системы.
■ Проект: наименования, атрибуты, структуры, поведение, группирование и связи значимых классов и компонентов.
■ Реализация: исходное описание компонентов и спецификация (номер, название, цель, стоимость) всех составляющих компонентов.
■ Внедрение: исполняемые компоненты, необходимые для демонстрации критичных вариантов использования, и риск, сопутствующий достижению качеств системы.
Хотя технические детали описания архитектуры не являются главными при управлении созданием ПО, дух, лежащий в основе упреждающей разработки архитектуры, крайне важен для достижения успеха. Проведение черты (отделяющей то, что имеет отношение к архитектуре, от того, что не имеет) является вызовом менеджерам проекта, поскольку такая черта определяет баланс, который оказывает значительное влияние на успех всего проекта.
Базовая архитектура описывается как сбалансированное подмножество информации из всех комплектов, в то время как описание архитектуры полностью содержится внутри проектного комплекта. Это является небольшим, но важным отличием между традиционными подходами и современными итерационными процессами разработки. При традиционных подходах базовая архитектура приравнивается к описанию архитектуры (выполняемому в виде документа, который не имеет строгой нотации) без какого бы то ни было представления в других комплектах рабочих продуктов, касающихся разработки, для подтверждения целостности описания. При итерационном подходе базовая архитектура является частичной реализацией описания архитектуры, которое оказывается ощутимым свидетельством того, что данная архитектура является допустимой в контексте текущих требований и планов.
Описание архитектуры может принимать самые разнообразные формы, начиная от простого, непосредственного подмножества UML-диаграмм и заканчивая сложным набором моделей с широким диапазоном различных представлений, которые содержат в себе отдельные аспекты сложных систем. Первое может подойти для небольшой высокопрофессиональной команды, создающей некий инструмент для разработки, второе — для распределенной крупномасштабной системы управления и контроля, сбой которой способен привести к катастрофическим последствиям.
Комплекты рабочих продуктов развиваются на протяжении всего жизненного цикла: от стадии разработки (когда основное внимание уделяется требованиям и проекту) до стадии производства (когда центр внимания перемещается на реализацию и внедрение). Точка перехода от стадии разработки к стадии производства представляет собой состояние, при котором проект достигает стабильной базовой архитектуры. С точки зрения управления это состояние достигается тогда, когда соответствующие заинтересованные стороны соглашаются с тем, что общая концепция системы (определяемая требованиями и архитектурой, представленной в проектном комплекте и частично осуществленной в комплектах реализации и внедрения) может быть реализована с хорошо предсказуемыми затратами и сроками (так, как это подтверждается в комплекте управления). Доказательство этого утверждения обычно требует не только документов и проведения брифингов, но и наличия работающих прототипов, которые демонстрируют развивающиеся возможности системы. Обратная связь от таких демонстраций оказывает осязаемое влияние на обоснованность принимаемого решения. Чем больше используется стандартных компонентов, тем проще достигается это состояние. Чем больше применяется компонентов, изготовленных на заказ, тем сложнее достигается это состояние, и тем сложнее оценить затраты на создание.