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