Архитектура ПО — определение, виды

Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:

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

· соединение выбранных элементов структуры и поведения во всё более крупные системы;

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

Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.

Архитектурный вид состоит из 2 компонентов:

· Элементы

· Отношения между элементами

Архитектурные виды можно поделить на 3 основных типа:

· Модульные виды (англ. module views) — показывают систему как структуру из различных программных блоков.

· Компоненты-и-коннекторы (англ. component-and-connector views) — показывают систему как структуру из параллельно запущенных элементов (компонентов) и способов их взаимодействия (коннекторов).

· Размещение (англ. allocation views) — показывает размещение элементов системы во внешних средах.

Примеры модульных видов:

· Декомпозиция (англ. decomposition view) — состоит из модулей в контексте отношения «является подмодулем»

· Использование (англ. uses view) — состоит из модулей в контексте отношения «использует» (т.е. один модуль использует сервисы другого модуля)

· Вид уровней (англ. layered view) — показывает структуру, в которой связанные по функциональности модули объединены в группы (уровни)

· Вид классов/обобщений (англ. class/generalization view) — состоит из классов, связанные через отношения «наследуется от» и «является экземпляром»

· Примеры видов компонентов-и-коннекторов:

· Процессный вид (англ. process view) — состоит из процессов, соединённых операциями коммуникации, синхронизации и/или исключения

· Параллельный вид (англ. concurrency view) — состоит из компонентов и коннекторов, где коннекторы представляют собой «логические потоки»

· Вид обмена данными (англ. shared-data (repository) view) — состоит из компонентов и коннекторов, которые создают, сохраняют и получают постоянные данные

· Вид клиент-сервер (англ. client-server view) — состоит из взаимодействующих клиентов и серверов и коннектором между ними (например, протоколов и общих сообщений)

· Примеры видов размещения:

· Развертывание (англ. deployment view) — состоит из программных элементов, их размещения на физических носителях и коммуникационных элементов

· Внедрение (англ. implementation view) — состоит из программных элементов и их соответствия файловым структурам в различных средах (разработческой, интеграционной и т.д.)

· Распределение работы (англ. work assignment view) — состоит из модулей и описания того, кто ответственен за внедрение каждого из них

Хотя было разработано несколько языков для описания архитектуры программного обеспечения, в настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В качестве стандарта «для моделирования программных систем (и не только)» был создан язык UML.

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

Классический жизненный цикл

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

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

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

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

Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Проектирование программного обеспечения состоит в создании представлений:

· архитектуры программного обеспечения;

· модульной структуры программного обеспечения;

· алгоритмической структуры программного обеспечения;

· структуры данных;

· входного и выходного интерфейса (входных и выходных форм данных).

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

Кодирование состоит в переводе результатов проектирования в текст на языке программирования.

Тестирование – выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

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

Цели изменений:

· исправление ошибок;

· адаптация к изменениям внешней среды программного обеспечения;

· усовершенствование программного обеспечения по требованиям заказчика.

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

Достоинства классического жизненного цикла:

5. дает план и временной график по всем этапам проекта;

6. упорядочивает ход конструирования.

Недостатки классического жизненного цикла:

5. реальные проекты часто требуют отклонения от стандартной последовательности шагов;

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

7. результаты проекта доступны заказчику только в конце работы.