Просмотр исходного текста страницы Архитектура

'''Системная архитектура''' (Architecture) — имеет множество определений:
# Из [[ISO 42010]] (2011): Архитектура (системы) – фундаментальная организация системы, реализованная в ее компонентах, их взаимосвязях друг с другом и с окружающей средой, и руководящие правила проектирования и развития системы;
# Из книги [https://www.amazon.com/Software-Architecture-Perspectives-Emerging-Discipline/dp/0131829572 Garlan et al.] (1996): Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений;
# [http://www.sei.cmu.edu/architecture/start/glossary/community.cfm Набор из более чем 150 других определений архитектуры], которые предлагались профессионалами системной и программной инженерии;
# Ralf Johnson в статье [http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf Who Needs Architect?] (2003): “Архитектура — это обо всём важном. Что бы это ни было” ''(Architecture is about the important stuff. Whatever that is)''. Если представить архитектуру как набор инженерных решений, принимаемых для определения структуры системы, то “важные решения” — это при изменении которых приходится в существенной мере изменять множество других решений, в существенной мере перепроектировать систему.

Системная архитектура - эта [[альфа]], пожалуй, важнейшая среди подальф [[Определение системы|определения системы]].

== Архитектурные описания ==
'''Архитектура''' — это основные описания (представления, views) “прозрачного ящика”, которые показывают, из каких основных частей ([[Компонента|компонент]], [[Модуль|модулей]], [[Размещение|размещений]] и т.д.) состоит система, и как эти описания “прозрачного ящика” обеспечивают функцию “чёрного ящика”.

Минимальная архитектура состоит из трёх определений (и, соответственно, трёх тематических описаний — наборов рабочих продуктов/моделей):
* '''Операционное (практическое) описание''' (Operational View) - система с точки зрения пользователя или "оператора". Сюда включаются артефакты, относящиеся к этапам практического применения системы, сценариям и потокам работ:
** описание операций в графическом или числовом виде,
** описание сценариев и вариантов использования ([[Сценарий использования|use cases]]),
** диаграммы потоков задач (task flow diagrams),
** схемы организационной структуры (organization charts),
** диаграммы информационных потоков (information flow diagrams).
* '''Логическое описание''' (Logical View) — система с точки зрения руководителя или заказчика. Сюда включаются артефакты, определяющие границу между системой и ее окружением, функциональные интерфейсы с внешними системами, основные функции и виды поведения системы, потоки данных, внутренние и внешние наборы данных, внутренние и внешние пользователи и внутренние функциональные интерфейсы:
** принципиальные схемы, а иногда просто [[функциональная декомпозиция]] (data flow chart),
** диаграммы [[IDEF0]],
** схемы функциональных потоков (FFBD).
* '''Физическое описание''' (Physical View) — система с точки зрения специалистов по проектированию. Сюда включаются артефакты, которые определяют физическую границу системы, компоненты, их взаимодействие и интерфейсы между ними, внутренние базы данных и структуры данных , информационно-технологическую инфраструктуру системы, стандарты, применяемые при ее разработке:
** детализированные физические блок-схемы (physical block diagram),
** топологии баз данных,
** документы по контролю сопряжений (interface control document, ICD),
** стандарты.

Архитектура должна чётко показывать: '''как увязанные между собой все эти три вида описаний “прозрачного ящика” дают на выходе основные функции системы'''. Тем самым архитектура неразрывно связана с [[Требования|требованиями]]. Те требования, которые максимально влияют на архитектуру, называют архитектурными требованиями.

Системная архитектура разрабатывается '''системными архитекторами''', специализация на системной архитектуре одна из основных специализаций для системных инженеров. Ещё одно название для архитектурного проектирования — '''системное проектирование''', ибо само понятие архитектуры с его множественностью структур системы и зависимости определения этих структур от нужд и интересов стейкхолдеров опирается на системный подход.

== Архитектурные инженерные решения ==
* ясно выражают [[Ограничение|ограничения]] для проектантов/конструкторов (команды проекта), поэтому они стабилизируют разработку.
* помогают разъяснять принимаемые по поводу целевой системы инженерные решения для [[стейкхолдер|стейкхолдеров]].

== Практики архитектурного проектирования ==
# '''Общие подходы'''
#* иерархическое проектирование систем и декомпозиционные подходы;
#* модульное проектирование;
#* проектирование на основе матрицы проектной структуры ([[DSM]], Design Structure Matrix) - метод разбиения системы на модули;
#* проектирование на основе многокритериального принятия решений (см. [[СППР]]);
#* морфологический анализ;
#* объектно-ориентированное проектирование;
#* проектирование на основе компонентов.
# '''Формальные подходы к системному проектированию'''
#* аксиоматическое проектирование;
#* формальные методы проектирования.
# '''Оптимизация'''
#* многодисциплинарная оптимизация;
#* методы смешанного целочисленного нелинейного программирования;
#* различные методы глобальной оптимизации;
#* нелинейная многоцелевая оптимизация;
#* многоцелевая [[Эволюционные алгоритмы|эволюционная оптимизация]], включающая генетические алгоритмы.
# '''Подходы на основе методов [[AI|искусственного интеллекта]]'''
#* специальные [[Экспертная система|экспертные системы]] и системы на основе [[База знаний|баз знаний]];
#* проектирование на основе грамматических описаний систем, включая подходы к проектированию составных систем;
#* методы проектирования на основе многоагентных подходов;
#* методы проектирования на основе задач выполнимости (constraint satisfaction problems).
# '''другое...'''
#* [[ТРИЗ]] как метод совмещения логической и физической архитектур;
#* огромное число методов, практикующихся в рамках одного-двух университетских или промышленных исследовательских центров/лабораторий (реже – центров разработки);
#* архитектурные расчёты, в которых принципиальная схема “живая” и по ней можно вести мультифизические расчёты. Например акаузальный язык мультифизического моделирования [[Modelica]];
#* product lines (например, [http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm подход для software product line practice, версия 5]);
#* [[Системная инженерия на основе поиска]];
#* http://www.cfin.ru/management/controlling/sys_project.shtml

== Стадии разработки архитектуры ==
Чаще всего разработка архитектуры проходит в такой последовательности:

[[Файл:architecture-design-process.png|800px|center]]

# предложение принципиальной схемы, или функциональной декомпозиции (“логической” схемы);
# проведения необходимых мультифизических расчётов;
# попытка определить то, как компоненты будут реализованы теми или иными модулями — которые можно купить, или которые придётся разработать;
# если предполагаемые принципиальной схемой модули трудно реализовать (их нет на рынке, их трудно спроектировать и изготовить и т.д.), то принципиальная схема меняется и переходят к п.2.
# повторяют пп.2-4 до тех пор, пока логическая и физическая архитектуры не окажутся согласованы между собой.

== Анализ альтернатив ==
'''Субъективность архитектуры''' - необходимость выбора одного из альтернативных вариантов архитектуры.
* Если попросить для уже готовой системы разных инженеров сделать архитектурные описания, то они будут разными — как по предложенным структурам системы, так и по той границе, которую проводят разные инженеры между “важным” и “неважным”, исходя из своего опыта.
* Если предложить разным системным архитекторам спроектировать какую-то систему, то разные системные архитекторы также предложат разные архитектуры — но в данном случае они их “придумают”, а не “выявят”.

Системный архитектор или команда системных архитекторов должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры/модулей для реализации компонент/разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как [[Анализ компромиссов|trade-off studies]]<ref>Общепринятый русский перевод "''анализ компромиссов''" намекает на взаимные уступки, здесь же выбирается один из вариантов в ущерб других, поэтому более удачные переводы - "''выбор альтернативы''" или "''прохождение развилок''”.</ref>. По этой процедуре готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора.

== Границы архитектуры ==
'''Относительность архитектуры''' - необходимость разделения архитектурной и неархитектурной частей.

Где кончаются архитектурные (важные) решения, а где начинается конструкторская и проектировочная рутина, не затрагивающая систему в целом знает только системный архитектор — никаких на этот счёт рекомендаций, стандартов, учебников нет. Так что критерий, где остановиться системному инженеру, спускаясь по отношениям часть-целое в структуре системы прост: останавливайтесь там, где вы
* дошли до того уровня деления системы на элементы, на котором вам кажется, что уже нет важных ваших решений;
* уже поделили работу между отдельными исполнителями-разработчиками модулей и дальше будут их важные решения.

Границу между архитектурным проектированием (architecting) и непосредственно проектированием системы (designing) можно провести исходя из целей (применения) архитектуры и проекта:
* '''Архитектура системы''' используется для следующих целей:
** выявление и уточнение [[Требования#Виды требований|требований назначения]] и [[Требования#Виды требований|функциональных требований]];
** достижение системой определенной цели или [[Сценарий использования|варианта использования]];
** проведение различий между вариантами;
** принятие решений о производстве или закупке.
* '''Проект системы''' используется для следующих целей:
** разработка компонентов системы;
** [[производство]] и [[комплексирование]] компонентов системы;
** осмысление изменений конфигурации при модификации системы.

== Состояния альфы ==
[[OMG Essence]] определяет следующие состояния для альфы "Архитектуры" и контрольные вопросы для проверки каждого состояния:

{| class="wikitable" style="font-size: 9pt;"
! style="text-align: center; font-weight: bold;" | №
! style="text-align: center; font-weight: bold;" | Состояние
! style="text-align: center; font-weight: bold;" | State
! style="text-align: center; font-weight: bold;" | Описание
! style="text-align: center; font-weight: bold; width: 35%;" | Контрольные вопросы
|-
| 1
| style="font-weight: bold;" | Архитектурные сценарии определены
| Architectural Scenarios Identified
| Architectural scenarios are identified to understand and pinpoint the requirements on the architecture
| ❑ The goals of the architecture have been identified and described with clear evaluation criteria.

❑ Any constraints that apply to the architecture have been identified and described.

❑ A set of scenarios which demonstrate that the architecture meets its goals has been identified and described.
|-
| 2
| style="font-weight: bold;" | Варианты решения определены
| Candidate Solution Identified
| There are many possible architectures that could be selected to support the development of the software system. The various options will need to be explored and assessed against the architectural goals and constraints. Trade-offs will have to be made between the different architectural characteristics to produce an architecture that is fit for purpose. In addition, some of the architectural requirements may have to be negotiated to keep development costs under control
| ❑One or more candidate architectures have been investigated and a suitable one has been identified.

❑Decisions have been made regarding the implementation platform and the major technologies to employ.
|-
| 3
| style="font-weight: bold;" | Решение структурировано
| Solution Structured
| The selected architecture is elaborated and structured by architectural designs and blueprints that can be used as input to subsequent implementation steps. The application of these designs and blueprints lays the foundation for the software system and sets the scene for a well-structured solution that will be capable of supporting the demands made on it by the architecturally significant requirements.
| ❑Architectural designs and blueprints for the software system are available.

❑A structure for the software system has been established that will support its development and maintenance.

❑Buy or build decisions have been made and any third-party products to be used are positioned within the architecture.
|-
| 4
| style="font-weight: bold;" | Обоснована
| Established
| The architecture is established by building and demonstrating a software system which creates confidence that the most appropriate solution has been chosen. The best way to do this is implement a ‘skinny’ (aka. skeleton) system and execute those architectural scenarios considered the most difficult or risky; successful execution provides evidence that the selected architecture is a suitable choice.
| ❑ Key features and unknown characteristics of the architecture have been identified for exploration.

❑ Just enough of the architecture has been implemented to address these areas of concern.

❑ An executable skinny system has been built.

❑ The most difficult or risky architectural scenarios have been demonstrated.

❑ Demonstration results have been gathered to justify selection of the architecture.
|-
| 5
| Прошла валидацию
| Validated
| The architecture is validated by architectural tests being executed and evaluated; the corresponding test results have been captured, analyzed and approved. Architectural tests need to be run against for every release of the software system, not just the initial architectural prototypes
| ❑ The software system, starting with the initial 'skinny' system and continuing as the system evolves, has been proven to meet the architectural requirements.
|}

== Рабочие продукты==
* [[Описание архитектуры]]
* [[Вариант тестирования]]

== Подходы к конструированию описаний ==
'''Correspondence rule''' — это правила соответствия элементов в разных моделях, они определяют конкретные соответствия (например, правила соответствия компонент и модулей в инженерной группе описаний. Эти правила определяют набор конкретных соответствий компонент и модулей в данном проекте). Всё, что говорится про архитектуру и архитектурные описания, верно для двух подходов к конструированию групп описаний из отдельных моделей (диаграмм, наборов формул и т.д.):
* '''Синтетический подход''' — когда отдельные модели (например, диаграммы) являются именно отдельными моделями, но к ним добавляется список соответствующих друг другу элементов (”насос-1 на принципиальной схеме реализуется модулем “наклонный жёлоб” на чертеже”).
* '''Прожекторный (проекторный) подход''' — когда вся необходимая информация разных моделей содержится в общей базе данных (иногда говорят “интеллектуальной информационной модели”, “цифровом макете”, “цифровой модели” и т.д.), а отдельные модели получаются отфильтровыванием нужной информации из общего хранилища — примерно так, как из белого цвета в проекторах и прожекторах получают нужные цвета, используя цветные фильтры-плёнки.

Эти два подхода логически эквивалентны.  

== Архитектурные языки ==
* [[ArchiMate]]
* [[Modelica]] - акаузальный язык мультифизического моделирования
* [[SysML]]
* [[AADL]]

== Стандарты ==
* [[ISO 42010]]

== Литература ==
* М. Левин [http://www.mslevin.iitp.ru/Levin-bk-Nov2013-071.pdf «Технология поддержки решений для модульных систем»].

== См. также ==
* [[Инженерия системной архитектуры]]

== Примечания ==
<references>

[[Категория:Концепции]]
[[Категория:Альфы]]