Концепция: Архитектура системы

Введение

Термин архитектура все чаще используется вне традиционного строительного контекста, и уже сейчас можно встретить много определений архитектуры (в контексте систем) и архитектуры систем, например:

"Архитектура системы: единая фундаментальная структура системы, описанная в терминах поведения, ограничений, процессов, интерфейсов и элементов системы".
[базовое определение, одобренное INCOSE Systems Architecture Working Group на конференции INCOSE 1996 в Бостоне (Массачусетс) 8 июля 1996 года]

"Архитектура системы описывает основные физические свойства, стиль, структуру, взаимодействия и предназначение системы".
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]

"Архитектура - это набор концепций и правил, характеризующих структуру, семантическое поведение и взаимосвязь между компонентами системы; план конструирования чего-либо. В состав архитектуры входят элементы, образующие конструкцию, отношения между ними, ограничения на эти отношения, описание отдельных компонентов конструкции, а также описание конструкции в целом".
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, which references ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations, as the source]

"Архитектура - это структура компонентов программы (системы), взаимосвязей между ними и принципов их разработки и эволюции во времени".
[DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995]

Архитектура - это "структура компонентов, взаимосвязей между ними и принципов их разработки и эволюции о времени".
[IEEE STD 610.12, extended slightly by the Integrated Architectures Panel (IAP) of the C4ISR Integration Task Force (ITF) in DoD Architecture Framework, Version 1.0]

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

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

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

Точки наблюдения

Точка наблюдения (в контексты системы) - это "форма абстракции, которая достигается с помощью определенного набора архитектурных концепций и правил структурирования для того, чтобы сфокусироваться на определенных аспектах системы" [ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations]. В следующей таблице приведены примеры точек наблюдения для различных аспектов системы. Эти точки наблюдения соответствуют стандарту ISO/IEC 10746-1: Information technology - Open Distributed Processing - Reference Model: Overview.

Точка наблюдения	Аспект	Сфера
Исполнитель	Исполнителя интересуют роли и сферы ответственности организации и сотрудников (и установленные для них правила).	Деятельность исполнителей, взаимодействие пользователей с системой. Человеческий фактор и производительность труда.
Информация	Виды информации, обрабатываемой системой, и ограничения на использование и интерпретацию этой информации.	Целостность информации, ограничения на объем. Доступность и актуальность информации.
Логика	Декомпозиция системы на набор подсистем, взаимодействующих через интерфейсы и обеспечивающих выполнение функций системы.	Поведение системы отвечает требованиям. Система поддерживает расширение, адаптацию, обслуживание. Активы допускают повторное использование.
Комплектация и физические характеристики	Инфраструктура, необходимая для обеспечения нормальной работоспособности системы.	Соответствие физических характеристик системы предъявляемым к ней функциональным и нефункциональным требованиям.
Процесс	Параллелизм, расширяемость, производительность, пропускная способность, надежность.	Соответствие системы требованиям к времени отклика, пропускной способности и отказоустойчивости.

Общие точки наблюдения.

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

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

Уровни абстракции

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

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

Архитектурные уровни RUP

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

Модели и диаграммы

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

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

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

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

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

Уровень модели	Точки наблюдения
Уровень модели	Исполнитель	Логика	Информация	Комплектация и физические характеристики	Процесс
Контекст	Организационное представление UML	Диаграмма контекста системы	Представление данных организации	Представление локальности организации	Представление бизнес-процессов
Анализ	Общее представление исполнителей	Представление подсистем	Представление данных системы	Представление локальности системы	Представление процессов системы
Эскиз	Представление исполнителей	Представления классов подсистем Представления компонентов программного обеспечения	Схема данных системы	Представление узлов дескрипторов	Подробное представление процессов
Реализация	Инструкции и спецификации ролей исполнителей	Конфигурации: диаграммы развертывания с компонентами программного и аппаратного обеспечения системы.

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