Архитектурная модель программного обеспечения

Не путать с компьютерной моделью .

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

Некоторые ключевые элементы модели архитектуры программного обеспечения включают в себя:

• Рич : Для рассматриваемой точки зрения должно быть достаточно информации для подробного описания местности. Информация не должна быть отсутствующей или расплывчатой. Цель состоит в том, чтобы свести к минимуму недоразумения, а не увековечить их. См. примечания ниже по поводу «основной проблемы».
• Строгий : архитектор применил определенную методологию для создания этой конкретной модели, и полученная модель «выглядит» определенным образом. Тест на строгость может утверждать, что если бы два архитектора в разных городах описывали одно и то же, полученные диаграммы были бы почти идентичными (за исключением, возможно, визуального макета, до определенной степени).
• Диаграмма . В общем, модель может относиться к любой абстракции, которая что-то упрощает ради рассмотрения конкретной точки зрения. Это определение конкретно подразделяет «архитектурные модели» на подмножество описаний моделей, которые представлены в виде диаграмм.
• Стандарты . Стандарты работают, когда все их знают и все их используют. Это обеспечивает уровень взаимодействия, которого невозможно достичь, когда каждая диаграмма существенно отличается от другой. Унифицированный язык моделирования (UML) — наиболее часто цитируемый стандарт.
• Основная проблема : легко оказаться слишком детализированным, включив множество различных потребностей в одну диаграмму. Этого следует избегать. Лучше нарисовать несколько диаграмм, по одной для каждой точки зрения, чем рисовать «мегадиаграмму», чрезвычайно богатую содержанием. Помните: строя дома, архитектор представляет множество различных схем. Каждый используется по-разному. Часто окончательный пакет планов часто включает схемы с планом этажа: план каркаса, план электрооборудования, план отопления, сантехники и т. д. Они гарантируют, что предоставленная информация - это только то, что необходимо. Например, субподрядчику сантехнических работ не нужны детали, которые необходимо знать электрику.
• Иллюстрируйте : Идея создания модели заключается в общении и получении ценной обратной связи. Целью диаграммы должен быть ответ на конкретный вопрос и поделиться этим ответом с другими, чтобы:
  1. посмотрим, согласятся ли они
  2. руководить их работой.
• Эмпирическое правило: знайте, что вы хотите сказать и на чью работу вы намерены повлиять с помощью этого.
• Конкретный набор компромиссов : методология анализа компромиссов архитектуры (ATAM) описывает процесс, посредством которого архитектура программного обеспечения может быть проверена экспертами на предмет соответствия. ATAM делает это, начиная с базовой идеи: не существует дизайна на все случаи жизни. Люди могут создать общий дизайн, но затем им придется изменить его для конкретных ситуаций, исходя из требований бизнеса. По сути, люди идут на компромиссы. Диаграмма должна сделать эти конкретные компромиссы видимыми. Поэтому, прежде чем архитектор создаст диаграмму, он должен быть готов описать словами, какие компромиссы он пытается проиллюстрировать в этой модели.
• Компромиссы, присущие структуре и дизайну . Компонент не является компромиссом. Компромиссы редко воплощаются в изображение на диаграмме. Компромиссы — это основные принципы, на основе которых создаются модели проектирования. Когда архитектор хочет описать или защитить конкретный компромисс, диаграмма может использоваться для защиты этой позиции.
• Система или экосистема : моделирование в целом может осуществляться на разных уровнях абстракции. Полезно смоделировать архитектуру конкретного приложения с компонентами и взаимодействиями. Также разумно смоделировать системы приложений, необходимые для реализации полного бизнес-процесса (например, от заказа до оплаты). Однако обычно нецелесообразно рассматривать модель отдельного компонента и его классов как архитектуру программного обеспечения. На этом уровне модель, хотя и ценна сама по себе, в гораздо большей степени иллюстрирует дизайн, чем архитектуру.

См. также

• сервис-ориентированного моделирования (SOMF) Структура

Внешние ссылки

• Опубликованные SEI «Определения архитектуры программного обеспечения» содержат список определений архитектуры, используемых классическими и современными авторами.
• Архитектурная модель содержит определение архитектурной модели из базы данных объектно-ориентированной разработки программного обеспечения Университета Оттавы.
• Метод архитектурного компромиссного анализа (ATAM) — это метод, с помощью которого можно оценить архитектуру на предмет ее пригодности и соответствия требованиям.