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

В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения ) Тон или стиль этой статьи может не отражать энциклопедический тон , используемый в Википедии .Рекомендации см. в руководстве Википедии по написанию лучших статей . ( Ноябрь 2011 ) (Learn how and when to remove this message) This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. Please help improve this article by introducing more precise citations. (April 2009) (Learn how and when to remove this message) This article does not cite any sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Software architectural model" – news · newspapers · books · scholar · JSTOR (June 2022) (Learn how and when to remove this message) (Learn how and when to remove this message)

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

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

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

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

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

Эта статья по программной инженерии — заглушка . Вы можете помочь Википедии, расширив ее.

• v
• t
• e