Архитектура — различия между версиями

Строка 30: Строка 30:
 
* см. обзор в первой главе книги М.Левина [http://www.mslevin.iitp.ru/Levin-bk-Nov2013-%20071.pdf «Технология поддержки решений для модульных систем»]. У всех них один «недостаток»: хорошему инженеру эти методы помогают, плохому инженеру они помочь не могут;
 
* см. обзор в первой главе книги М.Левина [http://www.mslevin.iitp.ru/Levin-bk-Nov2013-%20071.pdf «Технология поддержки решений для модульных систем»]. У всех них один «недостаток»: хорошему инженеру эти методы помогают, плохому инженеру они помочь не могут;
 
* [http://ru.wikibooks.org/wiki/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B%20_%D0%A2%D0%A0%D0%98%D0%97 ТРИЗ] ([http://www.triz-ri.ru/triz/triz02.asp АРИЗ-85В], [http://www.triz-ri.ru/triz/triz04.asp типовые приёмы разрешения противоречий], стандартные решения изобретательских задач) как метод совмещения логической и физической архитектур;
 
* [http://ru.wikibooks.org/wiki/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B%20_%D0%A2%D0%A0%D0%98%D0%97 ТРИЗ] ([http://www.triz-ri.ru/triz/triz02.asp АРИЗ-85В], [http://www.triz-ri.ru/triz/triz04.asp типовые приёмы разрешения противоречий], стандартные решения изобретательских задач) как метод совмещения логической и физической архитектур;
* [http://www.dsmweb.org/ DSM] (Design Structure Matrix) чаще всего используется как метод разбиения системы на модули;
+
* [[DSM]] (Design Structure Matrix) чаще всего используется как метод разбиения системы на модули;
 
* огромное число методов, практикующихся в рамках одного-двух университетских или промышленных исследовательских центров/лабораторий (реже – центров разработки);
 
* огромное число методов, практикующихся в рамках одного-двух университетских или промышленных исследовательских центров/лабораторий (реже – центров разработки);
 
* архитектурные расчёты, в которых принципиальная схема “живая” и по ней можно вести мультифизические расчёты. Например акаузальный язык мультифизического моделирования [[Modelica]];
 
* архитектурные расчёты, в которых принципиальная схема “живая” и по ней можно вести мультифизические расчёты. Например акаузальный язык мультифизического моделирования [[Modelica]];

Версия 16:31, 18 декабря 2015

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

  1. Из ISO 42010: Архитектура (системы) – основные понятия или свойства системы в её среде, заключающиеся в её элементах, их отношениях и принципах её проектирования и развития;
  2. Из книги Garlan et al.: Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений;
  3. Набор из более чем 150 других определений архитектуры, которые предлагались профессионалами системной и программной инженерии;
  4. Ralf Johnson: “Архитектура — это обо всём важном. Что бы это ни было”. Если представить архитектуру как набор инженерных решений, принимаемых для определения структуры системы, то “важные решения” — это при изменении которых приходится в существенной мере изменять множество других решений, в существенной мере перепроектировать систему.


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


Минимальная архитектура состоит из трёх определений (и, соответственно, трёх тематических описаний — наборов рабочих продуктов/моделей):

  • “логическая архитектура” — структура компонент и соединений (чаще всего — принципиальная схема, иногда просто функциональная декомпозиция).
  • “физическая архитектура” — структура модулей (определяемых их интерфейсами, а часто и физической декомпозицией).
  • указания на размещение частей системы в пространстве.


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


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


Архитектурные инженерные решения

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


Практики архитектурного проектирования


Стадии разработки архитектуры

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

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


Субъективность и относительность архитектуры

Субъективность архитектуры - необходимость выбора одного из альтернативных вариантов архитектуры.

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

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


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

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

  • дошли до того уровня деления системы на элементы, на котором вам кажется, что уже нет важных ваших решений;
  • уже поделили работу между отдельными исполнителями-разработчиками модулей и дальше будут их важные решения.


Рабочие продукты описания архитектуры

Архитектурные описания - рабочие продукты для описания архитектуры.

Современный тренд в архитектурных описаниях — это использование формальных (понимаемых компьютером) моделей и задание формализмов в качестве метода описания. В архитектурные описания обязательно входят ещё и архитектурные обоснования (резоны, по которым были приняты те или иные архитектурные решения — architecture rationale).

В архитектурных описаниях могут присутствовать и не-модели, например:

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


Знания — это повторноиспользуемая в разных ситуациях информация, т.е. можно говорить об архитектурных знаниях.


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


Подходы к конструированию описаний

Correspondence rule — это правила соответствия элементов в разных моделях, они определяют конкретные соответствия (например, правила соответствия компонент и модулей в инженерной группе описаний. Эти правила определяют набор конкретных соответствий компонент и модулей в данном проекте). Всё, что говорится про архитектуру и архитектурные описания, верно для двух подходов к конструированию групп описаний из отдельных моделей (диаграмм, наборов формул и т.д.):

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

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


Архитектурные языки

  • из языков архитектуры предприятия рекомендуется ArchiMate 2.0;
  • акаузальный язык мультифизического моделирования Modelica;
  • SysML
  • AADL


Стандарты


См. также