Введение

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

Так что же такое архитектура? Как появилась структура? Сегодня эта статья проиллюстрирует мои взгляды на архитектуру из собственного опыта.

что такое архитектура

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

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

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

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

Архитектура системы в основном описывает основные компоненты системы и отношения между этими компонентами и то, как они взаимодействуют.

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

Чтобы минимизировать затраты, удовлетворить функциональные требования и максимизировать масштабируемость и доступность структуры системы, нам необходимо учитывать следующие ключевые принципы проектирования:

Разделение интересов

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

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

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

принцип наименьшего знания

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

Сведите к минимуму большой дизайн заранее

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

Не повторяйте функции

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

Чтобы отдать приоритет комбинации повторного использования функциональности вместо наследования

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

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

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

Определите формат данных для взаимодействия между компонентами

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

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

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

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

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

соглашение об именовании

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

Описание архитектуры

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

UML

UML должен быть знаком каждому, его полное название Unified Modeling Language, это графический язык. Спецификация UML1.0 была предложена Object Management Group (OMG) в январе 1997 года. Он используется в качестве стандарта для анализа требований к программному обеспечению и проектной документации, которая является основой для разработки программного обеспечения.

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

UML в основном делится на две категории: структурные диаграммы и диаграммы поведения.

Блок-схема представляет статические компоненты системы. Эти статические компоненты представлены классами, интерфейсами, объектами, компонентами и узлами. Структурная схема содержит следующие части:

Диаграмма классов: представляет различные классы в объектно-ориентированной системе и отношения между ними.
Граф объектов: Граф объектов представляет объекты и их отношения во время выполнения.
Диаграмма компонентов: Диаграмма компонентов описывает все компоненты, интерфейсы и их взаимодействие в системе.
Составная структура: описывает внутреннюю структуру компонента, включая все классы, интерфейс компонента и т. д.
Пакеты: Пакеты в основном содержат классы и другие пакеты.
График развертывания. Граф развертывания представляет собой набор узлов и их взаимосвязей. Эти узлы являются физическими объектами, на которых развернуты компоненты.

Диаграммы поведения представляют возможные действия в системе. Диаграммы поведения могут включать следующее:

Диаграмма вариантов использования: описывает взаимосвязь между функциями и их внутренними/внешними контроллерами. Эти контроллеры называются акторами.
Диаграмма деятельности: описывает поток управления в системе. Он состоит из действий и ссылок. Поток может быть последовательным, параллельным или разветвленным.
Диаграмма состояний: представляет изменения состояния системы, управляемые событиями. Он описывает изменения состояния классов, интерфейсов и т.д.
Диаграмма последовательности: Визуализируйте порядок, в котором конкретная функция выполняется в системе.
Комбинируйте диаграммы действий и последовательности действий, чтобы получить представление о потоке управления системами и бизнес-процессами.

Просмотр архитектуры

Это взгляд всей системы с точки зрения группы связанных проблем. Он используется из разных заинтересованных сторон (таких как конечные пользователи, разработчики, менеджеры проектов и тестеров) описывают точку зрения системы. Здесь, чтобы представить режим просмотра, называемый 4 + 1.

Модель представления 4+1 была изобретена Филиппом Крухтеном. Эта модель описывает архитектуру систем с интенсивным использованием программного обеспечения, основанную на использовании нескольких представлений и параллельных представлений. Это модель с несколькими представлениями, в которой рассматриваются различные функции и задачи системы. Он стандартизирует документацию по проектированию программного обеспечения и упрощает понимание проекта всеми заинтересованными сторонами.

Он содержит 4 основных представления, а именно:

1. 逻辑视图或概念视图-它描述了设计的对象模型。    
   2.  流程视图-描述了系统的活动，包括并发和同步。     
   3. 物理视图-它描述了软件到硬件的映射并反映了其分布式关系。   
   4.  开发视图-它描述了环境开发中软件的静态组织和结构。

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

ADL

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

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

Суммировать

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

Эта статья была включена вwoohoo.floydpress.com/06-программное обеспечение…

Самая популярная интерпретация, самая глубокая галантерея, самые краткие уроки и множество трюков, о которых вы не знаете, ждут вас!

Добро пожаловать, чтобы обратить внимание на мой официальный аккаунт: «Программируйте эти вещи», разбирайтесь в технологиях, лучше поймите себя!