Архитектура

Версия от 22:09, 23 декабря 2016; Admin (обсуждение | вклад) (→‎Анализ альтернатив)

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

  1. Из ISO 42010 (2011): Архитектура (системы) – фундаментальная организация системы, реализованная в ее компонентах, их взаимосвязях друг с другом и с окружающей средой, и руководящие правила проектирования и развития системы;
  2. Из книги Garlan et al. (1996): Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений;
  3. Набор из более чем 150 других определений архитектуры, которые предлагались профессионалами системной и программной инженерии;
  4. Ralf Johnson в статье 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) — система с точки зрения руководителя или заказчика. Сюда включаются артефакты, определяющие границу между системой и ее окружением, функциональные интерфейсы с внешними системами, основные функции и виды поведения системы, потоки данных, внутренние и внешние наборы данных, внутренние и внешние пользователи и внутренние функциональные интерфейсы:
  • Физическое описание (Physical View) — система с точки зрения специалистов по проектированию. Сюда включаются артефакты, которые определяют физическую границу системы, компоненты, их взаимодействие и интерфейсы между ними, внутренние базы данных и структуры данных , информационно-технологическую инфраструктуру системы, стандарты, применяемые при ее разработке:
    • детализированные физические блок-схемы (physical block diagram),
    • топологии баз данных,
    • документы по контролю сопряжений (interface control document, ICD),
    • стандарты.

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

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

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

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

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

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

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

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

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

Анализ альтернатив

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандарты

Литература

См. также

Примечания

  1. ↑ Общепринятый русский перевод "анализ компромиссов" намекает о взаимных уступках, здесь же выбирается один из вариантов в ущерб других, поэтому более удачные переводы - "выбор альтернативы" или "прохождение развилок”.
Источник — «http://sewiki.ru/index.php?title=Архитектура&oldid=2400»