Главная » UML » Определение архитектуры

0

Архитектуру можно определить по-разному. В Rational Unified Process используется

следующее определение .

Архитектура объединяет значимые решения относительно

•       организации программной системы;

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

•       объединения этих элементов в постепенно укрупняющиеся подсистемы;

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

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

определение развилось из определения, предложенного несколько лет назад Мери Шо (Mary Shaw) и Девидом Гарланом (David Garlan) из Carnegie-Mellon University. См. их работу Software Architecture - Perspectives on an Emerging Discipline. Upper Saddle River, NJ: Prentice-Hall, 1996.

 

Приведенное определение несколько громоздко, но в нем мы попытались отобразить сложность и многомерность определяемого понятия. Остановимся подробнее на нескольких моментах.

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

Архитектура связана со структурой и организацией, но этим она не ограничивается. Кроме того, она имеет отношение к поведению: что произойдет на стыках, соединениях и границах интерфейсов.

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

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

Представление архитектуры

Тем или иным образом архитектура представляет интерес для многих.

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

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

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

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

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

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

•       Архитекторов,   которые   используют   ее   для   размышления   над   вопросами
развития или повторного использования.

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

Различные заинтересованные стороны беспокоят и интересуют разные аспекты архитектуры. Поэтому архитектура является не плоской, а многомерной.

 

Множественные представления

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

•       Планы этажей

•       Вертикальные проекции

•       Планы электромонтажа кабельной проводки

•       Чертежи водопроводов, систем центрального отопления и вентиляции

•       Вид здания на фоне пейзажа (эскизы)

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

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

•       Отображению логической организации системы

•       Упорядочению функциональных возможностей системы

•       Отображению аспектов параллельной работы

•       Описанию физического размещения программного обеспечения на базовой
платформе

Существует множество других целей, и все они находят свое отражение в архитектурных представлениях.

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

•       Точку зрения, а именно: какие аспекты затронуты и какой заинтересованной
стороне адресуется представление

•       Какие элементы будут фиксироваться и представляться и какие между ними
существуют взаимоотношения

•       Какие   организационные   принципы   используются   для   структурирования
представления

•       Каким образом элементы данного представления связаны с элементами других
представлений

•       Каким способом лучше всего создать представление

4 Данный многомерный подход соответствует будущему стандарту IEEE Recommended Practice for Architectural Description, См. проект стандарта Draft 5.2 IEEE P1471, November 1999.

 

Модель представления архитектуры "4 + 1"

Как показано на рис. 5.1, Rational Unified Process предлагает использовать пятимерный подход5. Эти пять измерений (или представлений) кратко описываются ниже.

Рис. 5,1. Модель "4 +Г

Логическое представление

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

Примеры: рейс, схема рейса, авиалиния, аэропорт и воздушное пространство.

Реализационное представление

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

Примеры: исходный код для класса рейса и библиотека кодов для базы данных воздушного пространства.

Процедурное представление

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

s Philippe Kruchten, The 4 + 1 View of Architecture. IEEE Software, 12(6) Nov. 1995, pp. 45-50.

 

Таблица 5.1. Соотношения между моделями и представлениями

Модель                                                            Архитектурное представление

Модель проектирования             Логическое представление

Модель проектирования*           Процедурное представление

Модель реализации                     Реализационное представление

Модель распространения            Представление распространения

Модель прецедентов                   Прецедентное представление

*или модель процесса для сложной системы

Архитектура — это не только чертеж

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

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

По теме:

  • Комментарии