Ключевые принципы

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

Архитектурный стиль

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

Архитектурный стиль отвечает за —

Предоставьте лексикон компонентов и соединителей с правилами их объединения.
Улучшение разбиения и возможность повторного использования дизайна, предоставляя решения для часто возникающих проблем.
Опишите конкретный способ настройки набора компонентов (модуль с четко определенными интерфейсами, многоразового использования и замены) и разъемов (канал связи между модулями).

Предоставьте лексикон компонентов и соединителей с правилами их объединения.

Улучшение разбиения и возможность повторного использования дизайна, предоставляя решения для часто возникающих проблем.

Опишите конкретный способ настройки набора компонентов (модуль с четко определенными интерфейсами, многоразового использования и замены) и разъемов (канал связи между модулями).

Программное обеспечение, созданное для компьютерных систем, демонстрирует один из многих архитектурных стилей. Каждый стиль описывает системную категорию, которая включает в себя —

Набор типов компонентов, которые выполняют требуемую функцию системой.
Набор соединителей (вызов подпрограммы, удаленный вызов процедуры, поток данных и сокет), которые обеспечивают связь, координацию и взаимодействие между различными компонентами.
Семантические ограничения, которые определяют, как компоненты могут быть интегрированы в систему.
Топологическая компоновка компонентов, указывающая их взаимосвязи во время выполнения.

Набор типов компонентов, которые выполняют требуемую функцию системой.

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

Семантические ограничения, которые определяют, как компоненты могут быть интегрированы в систему.

Топологическая компоновка компонентов, указывающая их взаимосвязи во время выполнения.

Общий архитектурный дизайн

В следующей таблице перечислены архитектурные стили, которые можно упорядочить по их основной области фокусировки.

категория	Архитектурный дизайн	Описание
связь	Шина сообщений	Предписывает использование программной системы, которая может получать и отправлять сообщения, используя один или несколько каналов связи.
связь	Сервис-ориентированная архитектура (SOA)	Определяет приложения, которые предоставляют и используют функциональность как сервис, используя контракты и сообщения.
развертывание	Клиент / сервер	Разделите систему на два приложения, где клиент отправляет запросы на сервер.
развертывание	3-х уровневый или N-ярусный	Разделяет функциональность на отдельные сегменты, причем каждый сегмент представляет собой уровень, расположенный на физически отдельном компьютере.
Домен	Домен Управляемый Дизайн	Сосредоточена на моделировании бизнес-домена и определении бизнес-объектов на основе сущностей в бизнес-области.
Состав	На основе компонентов	Разбейте дизайн приложения на функциональные или логические компоненты многократного использования, которые предоставляют четко определенные интерфейсы связи.
	Многослойные	Разделите задачи приложения на сложенные группы (слои).
	Объектно-ориентированный	Основан на разделении обязанностей приложения или системы на объекты, каждый из которых содержит данные и поведение, относящееся к объекту.

Типы Архитектуры

Существует четыре типа архитектуры с точки зрения предприятия, и в совокупности эти архитектуры называются архитектурой предприятия .

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

Бизнес-архитектура. Определяет стратегию бизнеса, управления, организации и ключевые бизнес-процессы на предприятии и фокусируется на анализе и проектировании бизнес-процессов.

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

Информационная архитектура — Определяет логические и физические активы данных и ресурсы управления данными.

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

Процесс проектирования архитектуры

Процесс проектирования архитектуры фокусируется на декомпозиции системы на различные компоненты и их взаимодействия для удовлетворения функциональных и нефункциональных требований. Ключевые входные данные для проектирования архитектуры программного обеспечения —

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

Требования, предъявляемые к анализу задач.

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

Результатом или результатом процесса проектирования архитектуры является описание архитектуры . Базовый процесс проектирования архитектуры состоит из следующих этапов:

Понять проблему

Это самый важный шаг, потому что он влияет на качество дизайна, который следует.
Без четкого понимания проблемы невозможно создать эффективное решение.
Многие программные проекты и продукты считаются неудачными, потому что они на самом деле не решают существующую бизнес-проблему или не имеют заметного возврата инвестиций (ROI).

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

Без четкого понимания проблемы невозможно создать эффективное решение.

Многие программные проекты и продукты считаются неудачными, потому что они на самом деле не решают существующую бизнес-проблему или не имеют заметного возврата инвестиций (ROI).

Определить элементы дизайна и их отношения

На этом этапе создайте базовую линию для определения границ и контекста системы.
Разложение системы на ее основные компоненты на основе функциональных требований. Декомпозиция может быть смоделирована с использованием матрицы структуры проекта (DSM), которая показывает зависимости между элементами дизайна без указания степени детализации элементов.
На этом этапе первая проверка архитектуры выполняется путем описания ряда системных экземпляров, и этот этап называется архитектурным дизайном на основе функциональных возможностей.

На этом этапе создайте базовую линию для определения границ и контекста системы.

Разложение системы на ее основные компоненты на основе функциональных требований. Декомпозиция может быть смоделирована с использованием матрицы структуры проекта (DSM), которая показывает зависимости между элементами дизайна без указания степени детализации элементов.

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

Оценить дизайн архитектуры

Каждому качественному признаку присваивается оценка, поэтому для сбора качественных показателей или количественных данных проект оценивается.
Он включает оценку архитектуры на соответствие требованиям к атрибутам качества архитектуры.
Если все оценочные атрибуты качества соответствуют требуемому стандарту, процесс архитектурного проектирования завершен.
Если нет, то начинается третий этап проектирования архитектуры программного обеспечения: преобразование архитектуры. Если наблюдаемый атрибут качества не соответствует его требованиям, то необходимо создать новый дизайн.

Каждому качественному признаку присваивается оценка, поэтому для сбора качественных показателей или количественных данных проект оценивается.

Он включает оценку архитектуры на соответствие требованиям к атрибутам качества архитектуры.

Если все оценочные атрибуты качества соответствуют требуемому стандарту, процесс архитектурного проектирования завершен.

Если нет, то начинается третий этап проектирования архитектуры программного обеспечения: преобразование архитектуры. Если наблюдаемый атрибут качества не соответствует его требованиям, то необходимо создать новый дизайн.

Преобразовать дизайн архитектуры

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

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

Он связан с выбором дизайнерских решений для улучшения атрибутов качества при сохранении функциональности домена.

Дизайн трансформируется путем применения операторов, стилей или шаблонов дизайна. Для преобразования возьмите существующий дизайн и примените оператор дизайна, такой как декомпозиция, репликация, сжатие, абстракция и совместное использование ресурсов.

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

Преобразования (т.е. решения, оптимизирующие атрибуты качества) обычно улучшают один или несколько атрибутов качества, в то время как они негативно влияют на другие

Ключевые архитектурные принципы

Ниже приведены ключевые принципы, которые необходимо учитывать при проектировании архитектуры.

Строить, чтобы изменить, а не строить до последнего

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

Уменьшить риск и модель для анализа

Используйте инструменты проектирования, визуализации, системы моделирования, такие как UML, для сбора требований и проектных решений. Воздействия также могут быть проанализированы. Не формализуйте модель в той степени, в которой она подавляет возможность повторения и адаптации проекта.

Использование моделей и визуализаций в качестве инструмента для общения и совместной работы

Эффективная связь проекта, решений и постоянных изменений в дизайне имеет решающее значение для хорошей архитектуры. Использование моделей, представлений и других визуализаций архитектуры для эффективного общения и совместного использования дизайна со всеми заинтересованными сторонами. Это позволяет быстро сообщать об изменениях в дизайне.

Определите и поймите ключевые инженерные решения и области, где ошибки чаще всего допускаются. Инвестируйте в правильное принятие ключевых решений с первого раза, чтобы сделать дизайн более гибким и с меньшей вероятностью нарушить изменения.

Используйте инкрементальный и итеративный подход

Начните с базовой архитектуры, а затем развивайте подходящие архитектуры путем итеративного тестирования для улучшения архитектуры. Итеративно добавляйте детали в проект за несколько проходов, чтобы получить большую или правильную картину, а затем сосредоточьтесь на деталях.

Ключевые принципы дизайна

Ниже приведены принципы проектирования, которые необходимо учитывать для минимизации затрат, требований к обслуживанию и максимизации расширяемости, удобства использования архитектуры.

Разделение проблем

Разделите компоненты системы на конкретные функции, чтобы не было совпадений между функциями компонентов. Это обеспечит высокую когезию и низкое сцепление. Такой подход позволяет избежать взаимозависимости между компонентами системы, что помогает легко поддерживать систему.

Принцип единой ответственности

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

Принцип Наименьшего Знания

Любой компонент или объект не должен знать о внутренних деталях других компонентов. Такой подход позволяет избежать взаимозависимости и помогает в обслуживании.

Минимизация большого дизайна авансом

Минимизируйте крупный дизайн заранее, если требования приложения неясны. Если есть возможность изменения требований, тогда избегайте создания большого проекта для всей системы.

Не повторяйте функциональность

Функциональность «Не повторять» указывает, что функциональность компонентов не должна повторяться и, следовательно, фрагмент кода должен быть реализован только в одном компоненте. Дублирование функциональности в приложении может затруднить реализацию изменений, понизить ясность и внести потенциальные несоответствия.

Предпочитаю композицию наследованию при повторном использовании функциональности

Наследование создает зависимость между дочерними и родительскими классами и, следовательно, блокирует свободное использование дочерних классов. Напротив, композиция обеспечивает большой уровень свободы и уменьшает иерархии наследования.

Определить компоненты и сгруппировать их в логические слои

Компоненты идентификации и проблемная область, которые необходимы системе для удовлетворения требований. Затем сгруппируйте эти связанные компоненты на логическом уровне, который поможет пользователю понять структуру системы на высоком уровне. Избегайте смешивания компонентов разных типов в одном слое.

Определить протокол связи между уровнями

Понимать, как компоненты будут взаимодействовать друг с другом, что требует полного знания сценариев развертывания и производственной среды.

Определить формат данных для слоя

Различные компоненты будут взаимодействовать друг с другом через формат данных. Не смешивайте форматы данных, чтобы приложения можно было легко внедрять, расширять и обслуживать. Постарайтесь сохранить формат данных для слоя одинаковым, чтобы различным компонентам не приходилось кодировать / декодировать данные при обмене данными друг с другом. Это снижает накладные расходы на обработку.

Компоненты системного сервиса должны быть абстрактными

Код, связанный с безопасностью, связью или системными службами, такими как ведение журнала, профилирование и конфигурация, должен быть абстрагирован в отдельных компонентах. Не смешивайте этот код с бизнес-логикой, так как его легко расширить и поддерживать.

Исключения в дизайне и механизм обработки исключений

Предварительное определение исключений помогает компонентам элегантно управлять ошибками или нежелательной ситуацией. Управление исключениями будет одинаковым во всей системе.

Соглашения об именах

Соглашения об именах должны быть определены заранее. Они обеспечивают последовательную модель, которая помогает пользователям легко понять систему. Членам группы легче проверять код, написанный другими, и, следовательно, повышается удобство сопровождения.