Архитектура — различия между версиями
Admin (обсуждение | вклад) м |
Admin (обсуждение | вклад) |
||
Строка 5: | Строка 5: | ||
# Ralf Johnson: “Архитектура — это обо всём важном. Что бы это ни было”. Если представить архитектуру как набор инженерных решений, принимаемых для определения структуры системы, то “важные решения” — это при изменении которых приходится в существенной мере изменять множество других решений, в существенной мере перепроектировать систему. | # Ralf Johnson: “Архитектура — это обо всём важном. Что бы это ни было”. Если представить архитектуру как набор инженерных решений, принимаемых для определения структуры системы, то “важные решения” — это при изменении которых приходится в существенной мере изменять множество других решений, в существенной мере перепроектировать систему. | ||
− | '''Архитектура''' — это основные описания “прозрачного ящика”, которые показывают, из каких основных частей (компонент, модулей, размещений и т.д.) состоит система, и как эти описания “прозрачного ящика” обеспечивают функцию “чёрного ящика”. | + | == Архитектурные описания == |
+ | '''Архитектура''' — это основные описания (представления, 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), | ||
+ | ** стандарты. | ||
− | Архитектура должна чётко показывать: '''как увязанные между собой все эти три вида описаний “прозрачного ящика” дают на выходе основные функции системы'''. Тем самым архитектура неразрывно связана с требованиями. Те требования, которые максимально влияют на архитектуру, называют архитектурными требованиями. | + | Архитектура должна чётко показывать: '''как увязанные между собой все эти три вида описаний “прозрачного ящика” дают на выходе основные функции системы'''. Тем самым архитектура неразрывно связана с [[Требования|требованиями]]. Те требования, которые максимально влияют на архитектуру, называют архитектурными требованиями. |
Системная архитектура разрабатывается '''системными архитекторами''', специализация на системной архитектуре одна из основных специализаций для системных инженеров. Ещё одно название для архитектурного проектирования — '''системное проектирование''', ибо само понятие архитектуры с его множественностью структур системы и зависимости определения этих структур от нужд и интересов стейкхолдеров опирается на системный подход. | Системная архитектура разрабатывается '''системными архитекторами''', специализация на системной архитектуре одна из основных специализаций для системных инженеров. Ещё одно название для архитектурного проектирования — '''системное проектирование''', ибо само понятие архитектуры с его множественностью структур системы и зависимости определения этих структур от нужд и интересов стейкхолдеров опирается на системный подход. | ||
== Архитектурные инженерные решения == | == Архитектурные инженерные решения == | ||
− | + | * ясно выражают ограничения для для проектантов/конструкторов (команды проекта), поэтому они стабилизируют разработку. | |
− | + | * помогают разъяснять принимаемые по поводу целевой системы инженерные решения для стейкхолдеров. | |
== Практики архитектурного проектирования == | == Практики архитектурного проектирования == | ||
Строка 59: | Строка 72: | ||
# повторяют пп.2-4 до тех пор, пока логическая и физическая архитектуры не окажутся согласованы между собой. | # повторяют пп.2-4 до тех пор, пока логическая и физическая архитектуры не окажутся согласованы между собой. | ||
− | == Субъективность | + | == Субъективность архитектуры == |
'''Субъективность архитектуры''' - необходимость выбора одного из альтернативных вариантов архитектуры. | '''Субъективность архитектуры''' - необходимость выбора одного из альтернативных вариантов архитектуры. | ||
* Если попросить для уже готовой системы разных инженеров сделать архитектурные описания, то они будут разными — как по предложенным структурам системы, так и по той границе, которую проводят разные инженеры между “важным” и “неважным”, исходя из своего опыта. | * Если попросить для уже готовой системы разных инженеров сделать архитектурные описания, то они будут разными — как по предложенным структурам системы, так и по той границе, которую проводят разные инженеры между “важным” и “неважным”, исходя из своего опыта. | ||
Строка 66: | Строка 79: | ||
Системный архитектор (или команда системных архитекторов) должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры/модулей для реализации компонент/разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как trade-off studies ("прохождение развилок”) — готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора. | Системный архитектор (или команда системных архитекторов) должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры/модулей для реализации компонент/разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как trade-off studies ("прохождение развилок”) — готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора. | ||
+ | == Относительность архитектуры == | ||
'''Относительность архитектуры''' - необходимость разделения архитектурной и неархитектурной частей. | '''Относительность архитектуры''' - необходимость разделения архитектурной и неархитектурной частей. | ||
Строка 71: | Строка 85: | ||
* дошли до того уровня деления системы на элементы, на котором вам кажется, что уже нет важных ваших решений; | * дошли до того уровня деления системы на элементы, на котором вам кажется, что уже нет важных ваших решений; | ||
* уже поделили работу между отдельными исполнителями-разработчиками модулей и дальше будут их важные решения. | * уже поделили работу между отдельными исполнителями-разработчиками модулей и дальше будут их важные решения. | ||
+ | |||
+ | Границу между архитектурным проектированием (architecting) и непосредственно проектированием системы (designing) можно провести исходя из целей (применения) архитектуры и проекта: | ||
+ | * '''Архитектура системы''' используется для следующих целей: | ||
+ | ** выявление и уточнение [[Требования#Виды требований|требований назначения]] и [[Требования#Виды требований|функциональных требований]]; | ||
+ | ** достижение системой определенной цели или [[Сценарий использования|варианта использования]]; | ||
+ | ** проведение различий между вариантами; | ||
+ | ** принятие решений о производстве или закупке. | ||
+ | * '''Проект системы''' используется для следующих целей: | ||
+ | ** разработка компонентов системы; | ||
+ | ** производство и комплексирование компонентов системы; | ||
+ | ** осмысление изменений конфигурации при модификации системы. | ||
== Рабочие продукты описания архитектуры == | == Рабочие продукты описания архитектуры == | ||
− | '''Архитектурные описания''' - рабочие продукты для описания архитектуры. | + | '''Архитектурные описания''' (представления, views) - рабочие продукты для описания архитектуры. |
Современный тренд в архитектурных описаниях — это использование формальных (понимаемых компьютером) моделей и задание формализмов в качестве метода описания. В архитектурные описания обязательно входят ещё и [[Обоснование архитектуры|архитектурные обоснования]] (резоны, по которым были приняты те или иные архитектурные решения — '''architecture rationale'''). | Современный тренд в архитектурных описаниях — это использование формальных (понимаемых компьютером) моделей и задание формализмов в качестве метода описания. В архитектурные описания обязательно входят ещё и [[Обоснование архитектуры|архитектурные обоснования]] (резоны, по которым были приняты те или иные архитектурные решения — '''architecture rationale'''). | ||
Строка 93: | Строка 118: | ||
== Архитектурные языки == | == Архитектурные языки == | ||
− | * | + | * [[ArchiMate]] |
− | * | + | * [[Modelica]] - акаузальный язык мультифизического моделирования |
* [[SysML]] | * [[SysML]] | ||
* [[AADL]] | * [[AADL]] |
Версия 17:26, 25 июля 2016
Системная архитектура — эта альфа, пожалуй, важнейшая среди подальф определения системы. Она имеет множество определений:
- Из 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)
- другое...
- ТРИЗ (АРИЗ-85В, типовые приёмы разрешения противоречий, стандартные решения изобретательских задач) как метод совмещения логической и физической архитектур;
- огромное число методов, практикующихся в рамках одного-двух университетских или промышленных исследовательских центров/лабораторий (реже – центров разработки);
- архитектурные расчёты, в которых принципиальная схема “живая” и по ней можно вести мультифизические расчёты. Например акаузальный язык мультифизического моделирования 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 на принципиальной схеме реализуется модулем “наклонный жёлоб” на чертеже”).
- Прожекторный (проекторный) подход — когда вся необходимая информация разных моделей содержится в общей базе данных (иногда говорят “интеллектуальной информационной модели”, “цифровом макете”, “цифровой модели” и т.д.), а отдельные модели получаются отфильтровыванием нужной информации из общего хранилища — примерно так, как из белого цвета в проекторах и прожекторах получают нужные цвета, используя цветные фильтры-плёнки.
Эти два подхода логически эквивалентны.