Архитектура
Системная архитектура (Architecture) — имеет множество определений:
- Из ISO 42010: Архитектура (системы) – фундаментальная организация системы, реализованная в ее компонентах, их взаимосвязях друг с другом и с окружающей средой, и руководящие правила проектирования и развития системы;
- Из книги Garlan et al.: Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений;
- Набор из более чем 150 других определений архитектуры, которые предлагались профессионалами системной и программной инженерии;
- Ralf Johnson: “Архитектура — это обо всём важном. Что бы это ни было”. Если представить архитектуру как набор инженерных решений, принимаемых для определения структуры системы, то “важные решения” — это при изменении которых приходится в существенной мере изменять множество других решений, в существенной мере перепроектировать систему.
Системная архитектура - эта альфа, пожалуй, важнейшая среди подальф определения системы.
Содержание
- 1 Архитектурные описания
- 2 Архитектурные инженерные решения
- 3 Практики архитектурного проектирования
- 4 Стадии разработки архитектуры
- 5 Субъективность архитектуры
- 6 Относительность архитектуры
- 7 Рабочие продукты описания архитектуры
- 8 Подходы к конструированию описаний
- 9 Архитектурные языки
- 10 Стандарты
- 11 Литература
- 12 См. также
Архитектурные описания
Архитектура — это основные описания (представления, 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) - метод разбиения системы на модули;
- проектирование на основе многокритериального принятия решений (см. СППР)
- морфологический анализ
- объектно-ориентированное проектирование
- проектирование на основе компонентов
- Формальные подходы к системному проектированию
- аксиоматическое проектирование
- формальные методы проектирования
- Оптимизация
- многодисциплинарная оптимизация
- методы смешанного целочисленного нелинейного программирования
- различные методы глобальной оптимизации
- нелинейная многоцелевая оптимизация
- многоцелевая эволюционная оптимизация, включающая генетические алгоритмы
- Подходы на основе методов искусственного интеллекта
- специальные экспертные системы и системы на основе баз знаний
- проектирование на основе грамматических описаний систем, включая подходы к проектированию составных систем
- методы проектирования на основе многоагентных подходов
- методы проектирования на основе задач выполнимости (constraint satisfaction problems)
- другое...
- ТРИЗ как метод совмещения логической и физической архитектур;
- огромное число методов, практикующихся в рамках одного-двух университетских или промышленных исследовательских центров/лабораторий (реже – центров разработки);
- архитектурные расчёты, в которых принципиальная схема “живая” и по ней можно вести мультифизические расчёты. Например акаузальный язык мультифизического моделирования Modelica;
- product lines (например, подход для software product line practice, версия 5);
- поиск-ориентированная инженерия;
- http://www.cfin.ru/management/controlling/sys_project.shtml
Стадии разработки архитектуры
Чаще всего разработка проходит в такой последовательности:
- предложение принципиальной схемы, или функциональной декомпозиции (“логической” схемы);
- проведения необходимых мультифизических расчётов;
- попытка определить то, как компоненты будут реализованы теми или иными модулями — которые можно купить, или которые придётся разработать;
- если предполагаемые принципиальной схемой модули трудно реализовать (их нет на рынке, их трудно спроектировать и изготовить и т.д.), то переходим принципиальная схема меняется и переходят к п.2.
- повторяют пп.2-4 до тех пор, пока логическая и физическая архитектуры не окажутся согласованы между собой.
Субъективность архитектуры
Субъективность архитектуры - необходимость выбора одного из альтернативных вариантов архитектуры.
- Если попросить для уже готовой системы разных инженеров сделать архитектурные описания, то они будут разными — как по предложенным структурам системы, так и по той границе, которую проводят разные инженеры между “важным” и “неважным”, исходя из своего опыта.
- Если предложить разным системным архитекторам спроектировать какую-то систему, то разные системные архитекторы также предложат разные архитектуры — но в данном случае они их “придумают”, а не “выявят”.
Системный архитектор (или команда системных архитекторов) должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры/модулей для реализации компонент/разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как trade-off studies ("прохождение развилок”) — готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора.
Относительность архитектуры
Относительность архитектуры - необходимость разделения архитектурной и неархитектурной частей.
Где кончаются архитектурные (важные) решения, а где начинается конструкторская и проектировочная рутина, не затрагивающая систему в целом знает только системный архитектор — никаких на этот счёт рекомендаций, стандартов, учебников нет. Так что критерий, где остановиться системному инженеру, спускаясь по отношениям часть-целое в структуре системы прост: останавливайтесь там, где вы
- дошли до того уровня деления системы на элементы, на котором вам кажется, что уже нет важных ваших решений;
- уже поделили работу между отдельными исполнителями-разработчиками модулей и дальше будут их важные решения.
Границу между архитектурным проектированием (architecting) и непосредственно проектированием системы (designing) можно провести исходя из целей (применения) архитектуры и проекта:
- Архитектура системы используется для следующих целей:
- выявление и уточнение требований назначения и функциональных требований;
- достижение системой определенной цели или варианта использования;
- проведение различий между вариантами;
- принятие решений о производстве или закупке.
- Проект системы используется для следующих целей:
- разработка компонентов системы;
- производство и комплексирование компонентов системы;
- осмысление изменений конфигурации при модификации системы.
Рабочие продукты описания архитектуры
Архитектурные описания (представления, views) - рабочие продукты для описания архитектуры.
Современный тренд в архитектурных описаниях — это использование формальных (понимаемых компьютером) моделей и задание формализмов в качестве метода описания. В архитектурные описания обязательно входят ещё и архитектурные обоснования (резоны, по которым были приняты те или иные архитектурные решения — architecture rationale).
В архитектурных описаниях могут присутствовать и не-модели, например:
- Архитектурные текстовые эссе оказываются очень полезными для краткого описания того, что было положено в основу моделей архитектурных описаний (выбор метода моделирования), краткого обзора архитектуры в целом как совокупности моделей. Эти же эссе могут быть использованы для пояснений того, как именно были связаны архитектурные модели, а также особенностей моделирования.
- Инфографика (а хоть и слайды в PowerPoint) может показать основные архитектурные идеи для не-инженеров (менеджеров, заказчиков, пользователей) — ибо формальные модели могут быть для них непонятны.
Знания — это повторноиспользуемая в разных ситуациях информация, т.е. можно говорить об архитектурных знаниях.
Архитектурные решения – это чаще всего накопленные человечеством, отраслью, организацией, конструктором/проектировщиком знания. Тем не менее лидерство в инженерии обычно определяется предложением новых архитектур — новых инженерных решений, т.е. связано с развитием инженерного знания.
Подходы к конструированию описаний
Correspondence rule — это правила соответствия элементов в разных моделях, они определяют конкретные соответствия (например, правила соответствия компонент и модулей в инженерной группе описаний. Эти правила определяют набор конкретных соответствий компонент и модулей в данном проекте). Всё, что говорится про архитектуру и архитектурные описания, верно для двух подходов к конструированию групп описаний из отдельных моделей (диаграмм, наборов формул и т.д.):
- Синтетический подход — когда отдельные модели (например, диаграммы) являются именно отдельными моделями, но к ним добавляется список соответствующих друг другу элементов (”насос-1 на принципиальной схеме реализуется модулем “наклонный жёлоб” на чертеже”).
- Прожекторный (проекторный) подход — когда вся необходимая информация разных моделей содержится в общей базе данных (иногда говорят “интеллектуальной информационной модели”, “цифровом макете”, “цифровой модели” и т.д.), а отдельные модели получаются отфильтровыванием нужной информации из общего хранилища — примерно так, как из белого цвета в проекторах и прожекторах получают нужные цвета, используя цветные фильтры-плёнки.
Эти два подхода логически эквивалентны.