Архитектура

Версия от 14:02, 26 октября 2016; Admin (обсуждение | вклад) (Архитектурные инженерные решения)

Системная архитектура (Architecture) — имеет множество определений:

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

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

Архитектурные описания

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

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

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

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

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

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

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

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

  1. Общие подходы
    • иерархическое проектирование систем и декомпозиционные подходы
    • модульное проектирование
    • проектирование на основе матрицы проектной структуры (DSM, Design Structure Matrix) - метод разбиения системы на модули;
    • проектирование на основе многокритериального принятия решений (см. СППР)
    • морфологический анализ
    • объектно-ориентированное проектирование
    • проектирование на основе компонентов
  2. Формальные подходы к системному проектированию
    • аксиоматическое проектирование
    • формальные методы проектирования
  3. Оптимизация
    • многодисциплинарная оптимизация
    • методы смешанного целочисленного нелинейного программирования
    • различные методы глобальной оптимизации
    • нелинейная многоцелевая оптимизация
    • многоцелевая эволюционная оптимизация, включающая генетические алгоритмы
  4. Подходы на основе методов искусственного интеллекта
    • специальные экспертные системы и системы на основе баз знаний
    • проектирование на основе грамматических описаний систем, включая подходы к проектированию составных систем
    • методы проектирования на основе многоагентных подходов
    • методы проектирования на основе задач выполнимости (constraint satisfaction problems)
  5. другое...

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

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

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

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

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

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

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

Относительность архитектуры

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

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

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

Границу между архитектурным проектированием (architecting) и непосредственно проектированием системы (designing) можно провести исходя из целей (применения) архитектуры и проекта:

  • Архитектура системы используется для следующих целей:
  • Проект системы используется для следующих целей:
    • разработка компонентов системы;
    • производство и комплексирование компонентов системы;
    • осмысление изменений конфигурации при модификации системы.

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

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

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

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

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

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

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

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

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

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

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

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

Стандарты

Литература

См. также