Архитектура программного обеспечения включает в себя структуру высокого уровня абстракции программной системы, используя декомпозицию и композицию, с архитектурным стилем и атрибутами качества. Архитектура программного обеспечения должна соответствовать основным требованиям к функциональности и производительности системы, а также удовлетворять нефункциональным требованиям, таким как надежность, масштабируемость, переносимость и доступность.
Архитектура программного обеспечения должна описывать свою группу компонентов, их соединения, взаимодействия между ними и конфигурацию развертывания всех компонентов.
Архитектура программного обеспечения может быть определена многими способами —
-
UML (Unified Modeling Language) — UML — одно из объектно-ориентированных решений, используемых в программном моделировании и проектировании.
-
Модель представления архитектуры (модель представления 4 + 1) — модель представления архитектуры представляет функциональные и нефункциональные требования программного приложения.
-
ADL (язык описания архитектуры) — ADL определяет архитектуру программного обеспечения формально и семантически.
UML (Unified Modeling Language) — UML — одно из объектно-ориентированных решений, используемых в программном моделировании и проектировании.
Модель представления архитектуры (модель представления 4 + 1) — модель представления архитектуры представляет функциональные и нефункциональные требования программного приложения.
ADL (язык описания архитектуры) — ADL определяет архитектуру программного обеспечения формально и семантически.
UML
UML расшифровывается как унифицированный язык моделирования. Это изобразительный язык, используемый для создания чертежей программного обеспечения. UML был создан Object Management Group (OMG). Черновой вариант спецификации UML 1.0 был предложен OMG в январе 1997 года. Он служит стандартом для анализа требований к программному обеспечению и проектных документов, которые являются основой для разработки программного обеспечения.
UML может быть описан как язык визуального моделирования общего назначения для визуализации, определения, конструирования и документирования программной системы. Хотя UML обычно используется для моделирования программной системы, он не ограничен этой границей. Он также используется для моделирования непрограммных систем, таких как технологические потоки в производственном подразделении.
Элементы похожи на компоненты, которые могут быть связаны различными способами для создания полной картины UML, которая называется диаграммой . Таким образом, очень важно понимать различные схемы для реализации знаний в реальных системах. У нас есть две широкие категории диаграмм, и они далее подразделяются на подкатегории: структурные диаграммы и поведенческие диаграммы .
Структурные диаграммы
Структурные диаграммы представляют статические аспекты системы. Эти статические аспекты представляют те части диаграммы, которые образуют основную структуру и поэтому являются стабильными.
Эти статические части представлены классами, интерфейсами, объектами, компонентами и узлами. Структурные диаграммы можно подразделить следующим образом:
- Диаграмма классов
- Диаграмма объектов
- Диаграмма компонентов
- Диаграмма развертывания
- Схема упаковки
- Композитная структура
В следующей таблице приведено краткое описание этих диаграмм.
| Sr.No. | Схема и описание |
|---|---|
| 1 |
Учебный класс Представляет объектную ориентацию системы. Показывает, как классы связаны статически. |
| 2 |
объект Представляет набор объектов и их взаимосвязей во время выполнения, а также представляет статическое представление системы. |
| 3 |
Составная часть Описывает все компоненты, их взаимосвязь, взаимодействия и интерфейс системы. |
| 4 |
Композитная структура Описывает внутреннюю структуру компонента, включая все классы, интерфейсы компонента и т. Д. |
| 5 |
пакет Описывает структуру пакета и организацию. Охватывает классы в пакете и пакеты внутри другого пакета. |
| 6 |
развертывание Диаграммы развертывания представляют собой набор узлов и их взаимосвязей. Эти узлы являются физическими объектами, на которых развернуты компоненты. |
Учебный класс
Представляет объектную ориентацию системы. Показывает, как классы связаны статически.
объект
Представляет набор объектов и их взаимосвязей во время выполнения, а также представляет статическое представление системы.
Составная часть
Описывает все компоненты, их взаимосвязь, взаимодействия и интерфейс системы.
Композитная структура
Описывает внутреннюю структуру компонента, включая все классы, интерфейсы компонента и т. Д.
пакет
Описывает структуру пакета и организацию. Охватывает классы в пакете и пакеты внутри другого пакета.
развертывание
Диаграммы развертывания представляют собой набор узлов и их взаимосвязей. Эти узлы являются физическими объектами, на которых развернуты компоненты.
Поведенческие Диаграммы
Поведенческие диаграммы в основном отражают динамический аспект системы. Динамические аспекты — это в основном меняющиеся / движущиеся части системы. UML имеет следующие типы поведенческих диаграмм —
- Диаграмма вариантов использования
- Схема последовательности
- Схема связи
- Диаграмма состояний
- Диаграмма деятельности
- Обзор взаимодействия
- Диаграмма временной последовательности
В следующей таблице приведено краткое описание этих диаграмм.
| Sr.No. | Схема и описание |
|---|---|
| 1 |
Случай использования Описывает взаимосвязи между функциями и их внутренними / внешними контроллерами. Эти контролеры известны как актеры. |
| 2 |
Деятельность Описывает поток управления в системе. Он состоит из действий и ссылок. Поток может быть последовательным, параллельным или разветвленным. |
| 3 |
State Machine / Государственный график Представляет управляемое событиями изменение состояния системы. Он в основном описывает изменение состояния класса, интерфейса и т. Д. Используется для визуализации реакции системы на внутренние / внешние факторы. |
| 4 |
Последовательность Визуализирует последовательность вызовов в системе для выполнения определенных функций. |
| 5 |
Обзор взаимодействия Объединяет диаграммы действий и последовательностей, чтобы обеспечить обзор потока управления системой и бизнес-процессом. |
| 6 |
связь То же, что и диаграмма последовательности, за исключением того, что она фокусируется на роли объекта. Каждое сообщение связано с порядком следования, номером плюс прошлые сообщения. |
| 7 |
Время последовательности Описывает изменения по сообщениям в состоянии, состоянии и событиях. |
Случай использования
Описывает взаимосвязи между функциями и их внутренними / внешними контроллерами. Эти контролеры известны как актеры.
Деятельность
Описывает поток управления в системе. Он состоит из действий и ссылок. Поток может быть последовательным, параллельным или разветвленным.
State Machine / Государственный график
Представляет управляемое событиями изменение состояния системы. Он в основном описывает изменение состояния класса, интерфейса и т. Д. Используется для визуализации реакции системы на внутренние / внешние факторы.
Последовательность
Визуализирует последовательность вызовов в системе для выполнения определенных функций.
Обзор взаимодействия
Объединяет диаграммы действий и последовательностей, чтобы обеспечить обзор потока управления системой и бизнес-процессом.
связь
То же, что и диаграмма последовательности, за исключением того, что она фокусируется на роли объекта. Каждое сообщение связано с порядком следования, номером плюс прошлые сообщения.
Время последовательности
Описывает изменения по сообщениям в состоянии, состоянии и событиях.
Модель представления архитектуры
Модель — это полное, базовое и упрощенное описание архитектуры программного обеспечения, которое состоит из нескольких представлений с определенной точки зрения или точки зрения.
Представление — это представление всей системы с точки зрения взаимосвязанного набора проблем. Он используется для описания системы с точки зрения различных заинтересованных сторон, таких как конечные пользователи, разработчики, менеджеры проектов и тестировщики.
4 + 1 Посмотреть модель
Модель представления 4 + 1 была разработана Филиппом Крухтеном для описания архитектуры программно-интенсивной системы, основанной на использовании множественных и одновременных представлений. Это модель с несколькими представлениями, которая рассматривает различные функции и проблемы системы. Он стандартизирует документы по разработке программного обеспечения и облегчает понимание проекта всеми заинтересованными сторонами.
Это метод проверки архитектуры для изучения и документирования проектирования архитектуры программного обеспечения, охватывающий все аспекты архитектуры программного обеспечения для всех заинтересованных сторон. Это обеспечивает четыре основных вида —
-
Логический или концептуальный вид — описывает объектную модель проекта.
-
Представление процесса — описывает действия системы, фиксирует аспекты параллелизма и синхронизации проекта.
-
Физическое представление — описывает отображение программного обеспечения на аппаратное обеспечение и отражает его распределенный аспект.
-
Вид разработки — описывает статическую организацию или структуру программного обеспечения при разработке среды.
Логический или концептуальный вид — описывает объектную модель проекта.
Представление процесса — описывает действия системы, фиксирует аспекты параллелизма и синхронизации проекта.
Физическое представление — описывает отображение программного обеспечения на аппаратное обеспечение и отражает его распределенный аспект.
Вид разработки — описывает статическую организацию или структуру программного обеспечения при разработке среды.
Эту модель представления можно расширить, добавив еще одно представление, называемое представлением сценария, или представление варианта использования для конечных пользователей или клиентов программных систем. Он согласуется с другими четырьмя видами и используется для иллюстрации архитектуры, служащей видом «плюс один», моделью вида (4 + 1). На следующем рисунке описана архитектура программного обеспечения с использованием модели пяти одновременных представлений (4 + 1).
Почему это называется 4 + 1 вместо 5?
Представление варианта использования имеет особое значение, поскольку оно детализирует требования высокого уровня системы, в то время как другие представления детализируют — как эти требования реализуются. Когда все остальные четыре представления завершены, это фактически избыточно. Однако все остальные взгляды были бы невозможны без него. На следующем рисунке и в таблице подробно показан вид 4 + 1 —
| логический | Процесс | развитие | физический | сценарий | |
|---|---|---|---|---|---|
| Описание | Показывает компонент (объект) системы, а также их взаимодействие | Показывает процессы / правила рабочего процесса системы и как эти процессы взаимодействуют, фокусируется на динамическом представлении системы | Предоставляет структурные представления системы и описывает статическую организацию системных модулей. | Показывает установку, настройку и развертывание программного приложения | Показывает, что дизайн завершен путем выполнения проверки и иллюстрации |
| Зритель / Держатель кола | Конечный пользователь, аналитики и дизайнер | Интеграторы и разработчики | Программисты и менеджеры программных проектов | Системный инженер, операторы, системные администраторы и установщики системы | Все мнения их мнения и оценщиков |
| Рассматривать | Функциональные требования | Нефункциональные требования | Организация программного модуля (повторное использование управления программным обеспечением, ограничение инструментов) | Нефункциональное требование к базовому оборудованию | Системная согласованность и валидность |
| UML — Диаграмма | Класс, Состояние, Объект, Последовательность, Диаграмма Связи | Диаграмма деятельности | Компонент, схема пакета | Диаграмма развертывания | Диаграмма вариантов использования |
Языки описания архитектуры (ADL)
ADL — это язык, который предоставляет синтаксис и семантику для определения архитектуры программного обеспечения. Это спецификация обозначений, которая предоставляет функции для моделирования концептуальной архитектуры программной системы, отличной от реализации системы.
ADL должны поддерживать компоненты архитектуры, их соединения, интерфейсы и конфигурации, которые являются строительным блоком описания архитектуры. Это форма выражения для использования в описаниях архитектуры и предоставляет возможность разложить компоненты, объединить компоненты и определить интерфейсы компонентов.
Язык описания архитектуры — это язык формальной спецификации, который описывает функции программного обеспечения, такие как процессы, потоки, данные и подпрограммы, а также аппаратный компонент, такой как процессоры, устройства, шины и память.
Трудно классифицировать или дифференцировать ADL и язык программирования или язык моделирования. Тем не менее, существуют следующие требования для того, чтобы язык был классифицирован как ADL —
Он должен быть подходящим для передачи архитектуры всем заинтересованным сторонам.
Он должен подходить для задач создания, уточнения и проверки архитектуры.
Он должен обеспечить основу для дальнейшей реализации, поэтому он должен иметь возможность добавлять информацию в спецификацию ADL, чтобы дать возможность получить окончательную спецификацию системы из ADL.
Он должен иметь возможность представлять большинство общих архитектурных стилей.
Он должен поддерживать аналитические возможности или обеспечивать быструю генерацию прототипных реализаций.