Архитектура программного обеспечения
Архитектура программного обеспечения (англ. software architecture ) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними. Этот термин также относится к документированию архитектуры программного обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации между заинтересованными лицами (англ. stakeholders ), позволяет зафиксировать принятые на ранних этапах проектирования решения о высокоуровневом дизайне системы и позволяет использовать компоненты этого дизайна и шаблоны повторно в других проектах.
Содержание
Обзор
Область компьютерных наук с момента своего образования столкнулась с проблемами, связанными со сложностью программных систем. Ранее проблемы сложности решались разработчиками путем правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин «архитектура программного обеспечения» является относительно новым для индустрии разработки ПО, фундаментальные принципы этой области неупорядоченно применялись пионерами разработки ПО начиная с середины 1980-х. Первые попытки осознать и объяснить программную архитектуру системы были полны неточностей и страдали от недостатка организованности, часто это была просто диаграмма из блоков, соединенных линиями. В 1990-е годы наблюдается попытка определить и систематизировать основные аспекты данной дисциплины. Первоначальный набор шаблонов проектирования, стилей дизайна, передового опыта (best-practices), языков описания и формальная логика были разработаны в течение этого времени. ЕПИ-3-11 супер Основополагающей идеей дисциплины программной архитектуры является идея снижения сложности системы путем абстракции и разграничения полномочий. На сегодняшний день до сих пор нет согласия в отношении четкого определения термина «архитектура программного обеспечения».
Являясь в настоящий момент своего развития дисциплиной без четких правил о «правильном» пути создания системы, проектирование архитектуры ПО все еще является смесью науки и искусства. Аспект «искусства» заключается в том, что любая коммерческая система подразумевает наличие применения или миссии. То, какие ключевые цели имеет система, описывается с помощью сценариев как нефункциональные требования к системе, также известные как атрибуты качества, определяющих, как будет вести себя система. Атрибуты качества системы включают в себя отказоустойчивость, сохранение обратной совместимости, расширяемость, надежность, пригодность к сервисному обслуживанию (maintainability), доступность, безопасность, удобство использования, а также другие качества. С точки зрения пользователя программной архитектуры, программная архитектура дает направление для движения и решения задач, связанных со специальностью каждого такого пользователя, например, заинтересованного лица, разработчика ПО, группы поддержки ПО, специалиста по сопровождению ПО, специалиста по развертыванию ПО, тестера, а также конечных пользователей. В этом смысле архитектура программного обеспечения на самом деле объединяет различные точки зрения на систему. Тот факт, что эти несколько различных точек зрения могут быть объединены в архитектуре программного обеспечения является аргументом в защиту необходимости и целесообразности создания архитектуры ПО еще до этапа разработки ПО.
История
Начало архитектуре программного обеспечения как концепции было положено в научно-исследовательской работе Эдсгера Дейкстры в 1968 году и Дэвида Парнаса в начале 1970-х. Эти ученые подчеркнули, что структура системы ПО имеет важное значение, и что построение правильной структуры — критически важно. Популярность изучения этой области возросла с начала 1990-х годов вместе с научно-исследовательской работой по исследованию архитектурных стилей (шаблонов), языков описания архитектуры, документирования архитектуры, и формальных методов.
В развитии архитектуры программного обеспечения как дисциплины играют важную роль научно-исследовательские учреждения. Мэри Шоу и Дэвид Гэрлан из университета Carnegie Mellon написали книгу под названием «Архитектура программного обеспечения: перспективы новой дисциплины в 1996 году», в которой выдвинули концепции архитектуры программного обеспечения, такие как компоненты, соединители (connectors), стили и так далее. В калифорнийском университете институт Ирвайна по исследованию ПО в первую очередь исследует архитектурные стили, языки описания архитектуры и динамические архитектуры.
Первым стандартом программной архитектуры является стандарт IEEE 1471: ANSI / IEEE 1471—2000: Рекомендации по описанию преимущественно программных систем. Он был принят в 2007 году, под названием ISO ISO / IEC 42010:2007.
Темы по программной архитектуре
Языки описания архитектуры
Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации.
Виды (views)
Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.
Хотя было разработано несколько языков для описания архитектуры программного обеспечения, в настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В качестве стандарта «для моделирования программных систем (и не только)» был создан язык UML.
Базовые фреймворки для архитектуры ПО (software architecture frameworks)
Существуют следующие фреймворки, относящихся к области архитектуры ПО:
Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к области архитектуры предприятия (enterprise architectures).
Отличие архитектуры ПО от детального проектирования ПО
Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией функциональных требований.
Архитектура ПО, которую также можно представить себе в виде разработки стратегии — это деятельность, связанная с определением глобальных ограничений, накладываемых на проектирование системы, такие как выбор парадигмы программирования, архитектурных стилей, стандарты разработки ПО, основанные на использовании компонентов, принципы проектирования и ограничения, накладываемые государственным законодательством. Детальное проектирование, то есть разработка тактики — это деятельность, связанная с определением локальных ограничений проекта, такие как шаблоны проектирования, архитектурные модели, идиомы программирования и рефакторинга. Согласно «гипотезе напряжения/окрестности» (Intension/Locality Hyphotysis), различие между архитектурным и детальным проектированием определяется критерием окрестности (Locality Criteria), согласно которому утверждение, что дизайн ПО не является локальным (а является архитектурным) истинно тогда и только тогда, когда программа, которая удовлетворяет этому критерию может быть расширена в программу, которая не удовлетворяет ему. Например, стиль приложения клиент-сервер является архитектурным стилем (стратегическим дизайном), потому что программа, которая построена на этом принципе, может быть расширена в программу, которая не является клиент-сервером, например, путем добавления peer-to-peer узлов.
Архитектура является проектированием (дизайном), но не всякий дизайн является архитектурным дизайном. На практике, архитектор определяет грань между архитектурой программного обеспечения (архитектурным дизайном) и детальным дизайном (неархитектурным проектированием). Не существует правил или инструкций, как сделать это, которые подходят для любого случая.
Примеры архитектурных стилей и моделей
Есть много распространенных способов разработки программных модулей и их связей, в том числе:
Примечания
Ссылки
Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл
Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)
CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML
Полезное
Смотреть что такое «Архитектура программного обеспечения» в других словарях:
архитектура программного обеспечения — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN software architecture … Справочник технического переводчика
Инженерия программного обеспечения — Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия
Производитель программного обеспечения — Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия
Разработка программного обеспечения — Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия
Тестирование программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Сопровождение программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Проектирование программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • … Википедия
Качество программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Внедрение программного обеспечения — Эта статья слишком короткая. Пожалуйста … Википедия
Спецификация программного обеспечения — Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) законченное описание поведения программы, которую требуется разработать. Включает ряд пользовательских сценариев (англ. use… … Википедия
4 типа архитектуры программного обеспечения
Детальный обзор существующих подходов
Зачем нужна архитектура ПО
Первые разработчики создавали программное обеспечение без архитектуры. Сначала это казалось удобным: никаких издержек, связанных с планированием, и ускоренное прототипирование. Но мере усложнения ПО теряло гибкость и управляемость, а каждое новое изменение обходилось все дороже. Это мешало развивать проект за границы, определенные изначально. Такая система получила название Большой комок грязи (Big Ball of Mud).
За годы развития ПО разработчикам удалось придумать надежные подходы, чтобы устранить недостатки проектирования без архитектуры. Ниже представлены некоторые из самых известных.
Подробно рассмотрим каждую из них.
Многослойная архитектура
Этот подход работает по принципу разделения ответственностей. ПО разделено на слои, лежащие друг на друге, и каждый из них выполняет определенную обязанность.
Архитектура делит ПО на следующие слои.
Данные и элементы управления проходят через каждый слой в дизайне и передаются от одного к другому. Эта система также повышает уровень абстракции и в некоторой степени даже стабильность ПО.
Преимущества
Недостатки
Многоуровневая архитектура
Этот архитектурный подход разделяет комплекс ПО на уровни по принципу взаимодействия “клиент-сервер”. Архитектура может иметь один, два и больше уровней, разделяющих ответственности между поставщиком данных и потребителем.
Этот подход использует шаблон Request Response для связи между уровнями. В отличие от многослойной архитектуры, он предлагает масштабируемость, которая может быть как горизонтальной (масштабирование сети с помощью высокопроизводительных узлов), так и вертикальной (масштабирование каждого узла путем повышения его производительности).
Одноуровневая система
В данном подходе единая система работает как на стороне сервера, так и клиента. Это обеспечивает простоту развертывания и отличную скорость связи, а также устраняет необходимость межсистемного взаимодействия (Inter-system communication — ISC).
Такая система подходит только для небольших однопользовательских приложений.
Двухуровневая система
Эта система состоит из двух физических машин в качестве сервера и клиента. Она обеспечивает изоляцию операций управления данными, обработки данных и операций представления.
Трехуровневая и n-уровневая системы
Такие архитектуры обладают высокой масштабируемостью как по горизонтали, так и по вертикали. Реализация n-уровневой системы, как правило, обходится дороже, но обеспечивает высокую производительность. Поэтому она обычно применяется в крупных и комплексных программных решениях.
Этот подход можно сочетать с современной сервис-ориентированной архитектурой, чтобы создавать сложнейшие модели. Поскольку реализация может оказаться дорогостоящей с точки зрения времени и ресурсов, рекомендуется использовать его для сложных ПО, требующих производительности и масштабируемости.
Сервис-ориентированная архитектура (SOA)
Эта архитектурная модель состоит из компонентов и приложений, которые связываются друг с другом с помощью четко определенных сервисов.
Она состоит из 5 элементов:
Клиент отправляет запрос с использованием стандартного протокола и формата данных по сети. Этот запрос обрабатывается ESB (enterprise service bus — сервисная шина предприятия), которая считается сердцем сервис-ориентированной архитектуры и отвечает за оркестровку и маршрутизацию. С помощью сервисного репозитория ESB направляет запрос в специальный сервис, который может взаимодействовать с другими сервисами и базами данных, чтобы составить полезную нагрузку (данные) ответа.
Полный вызов ответа на запрос согласуется с правилами управления и безопасности SOA для выполнения безопасной и корректной транзакции.
Как правило, сервисы делятся на два вида.
Типы сервисов
Mикросервисная архитектура
При таком подходе приложение разрабатывается как набор небольших сервисов, каждый из которых работает в собственном процессе и связывается с легковесными механизмами, обычно API для HTTP-ресурса.
Архитектура работает по принципу компонентизации сервисов. Она разделяет программное обеспечение на различные изолированные компоненты (сервисы), каждый из которых несет единую ответственность. Изменения в одной сервисе не должны затрагивать другие.
Состав микросервисов
Архитектура состоит из изолированных компактных микросервисов, способных расширяться независимо друг от друга. Она включает 5 следующих компонентов:
Характеристики микросервисов
Микросервисная архитектура должна включать следующие характеристики.
Рекомендуется развивать каждый микросервис отдельно под управлением разных команд. Поскольку передача данных происходит по стандартному протоколу и формату данных, структура одного сервиса не затронет функциональность сопутствующих.
Что такое архитектура программных систем
Однако архитектура не ограничивается рамками структуры программного продукта. Сотрудники группы разработчиков архитектур IEEE называют архитектуру «концепцией системы высочайшего уровня в своей среде» [IEP1471]. В этом определении архитектура охватывает такие аспекты, как целостность системы, экономическую целесообразность ее реализацию, эстетику программирования и стиль. В рамках архитектуры рассматриваются не только внутренние элементы системы, но и взаимодействие системы с внешней средой, включая пользовательскую среду и среду разработки.
В Rational Unified Process (RUP) архитектура системы программы (в данной точке) представляет собой организацию или структуру важных компонентов системы, взаимодействующих посредством интерфейсов, где компоненты состоят из последовательно уменьшающихся компонентов и интерфейсов.
Описание архитектуры
Для обсуждения структуры программы сначала следует определить архитектурное представление, способ описания важных аспектов архитектуры. В RUP это описание фиксируется в Документе по архитектуре программного обеспечения.
Архитектурные представления
Архитектуру программного обеспечения можно проиллюстрировать с помощью нескольких архитектурных представлений. Каждое архитектурное представление связано с некоторым определенным набором вопросов, интересующих участников разработки: пользователей, проектировщиков, менеджеров, технических специалистов, обслуживающий персонал и так далее.
Архитектурные представления охватывают основные решения, принятые при выборе структуры программного обеспечения, и демонстрируют декомпозицию архитектуры на составляющие ее компоненты, соединители и формы [PW92]. Решения, принимаемые при выборе структуры, обусловлены функциональными и дополнительными требованиями, а также другими ограничениями. В свою очередь, эти решения порождают новые ограничения в отношении требований и последующих решений на более низких уровнях.
Типичный набор архитектурных представлений
Архитектуру можно представить в виде совокупности архитектурных представлений, каждое из которых описывает «значимый для архитектуры» элемент модели. В RUP отправной точкой при разработке архитектуры служит типичный набор архитектурных представлений, который называется «моделью 4+1» [KRU95]. Модель содержит следующие компоненты:
Подробную информацию об архитектурных представлениях можно найти в документе по архитектуре программного обеспечения. Можно создавать и другие представления, отражающие те или иные аспекты системы: представление интерфейса, представление защиты, представление данных и т.д. В простых системах можно обойтись без некоторых из представлений, входящих в модель 4+1.
Фокус архитектуры
Хотя перечисленные выше представления могут полностью охватывать проект системы, в состав архитектуры входят только вполне определенные аспекты:
По сути архитектурные представления представляю собой абстракции, или упрощенные представления, проекта в целом, в которых убраны ненужные детали и подчеркнуты важнейшие характеристики. Эти характеристики приобретают особую важность при обсуждении следующих вопросов:
Шаблоны архитектуры
Примеры шаблонов архитектуры
В [BUS96] шаблоны архитектуры сгруппированы по характеристикам систем, в которых они наиболее часто применяются, при этом одна категория отведена под шаблоны общей структуры. В следующей таблице показаны категории [BUS96] и содержащиеся в них шаблоны.
| Категория | Шаблон |
|---|---|
| Структура | Уровни |
| Конвейеры и фильтры | |
| Классная доска | |
| Распределенные системы | Посредники |
| Интерактивные системы | Модель-представление-контроллер |
| Представление-абстракция-управление | |
| Адаптивные системы | Отражения |
| Микроядра |
Две из этих категорий подробно описаны в данной главе в качестве иллюстрации идей. Подробное описание можно найти в книге [BUS96]. Шаблоны представлены в следующей широко распространенной форме:
Имя шаблона
Контекст
Большая система, нуждающаяся в декомпозиции
Задача
Система должна работать одновременно с несколькими уровнями абстракции. Например, система должна принимать во внимание вопросы управления аппаратным обеспечением, вопросы, связанные с общими службами, и вопросы, относящиеся к конкретным предметным областям. Крайне нежелательно разрабатывать вертикальные компоненты, в которых придется иметь дело со сложностями на всех уровнях сразу. Такой подход потребует многократного решения одних и тех же задач (вероятно, различными способами) в разных компонентах.
Решение
В многослойной архитектуре элементы проекта (классы, пакеты, подсистемы) могут пользоваться только службами элементов, находящихся на один уровень ниже. Примерами служб могут служить обработка событий, обработка ошибок, обращение к базе данных и т.п. В такой архитектуре механизмы взаимодействия более структурированы, чем вызовы операционной системы, использующиеся на нижнем уровне.
2. Уровни бизнес-системы
На этой диаграмме приведен еще один пример многослойной структуры с вертикальными слоями приложений и горизонтальными слоями инфраструктуры. В данном случае цель заключается в максимальном сокращении длины «трубопровода» и максимальной утилизации общих элементов структуры приложения. В противном случае может получиться так, что разные сотрудники будут решать одну и ту же задачу несколько раз, причем по-разному.
Более подробная информация об этом шаблоне приведена в разделе Рекомендация: многослойные структуры.
Имя шаблона
Контекст
Предметная область, в котором закрытое (алгоритмическое) решение задачи не существует или неизвестно. Примерами могут служить системы искусственного интеллекта, системы распознавания голоса или системы внешнего наблюдения.
Задача
Различные агенты должны скоординированно решить задачу, с которой не в состоянии справиться ни один из них в отдельности. Результаты работы отдельных агентов должны быть доступны всем остальным агентам, которые принимают решение о том, могут ли они оказать помощь в поиске решения, и в случае положительного ответа публикуют результаты своей работы.
Последовательность, в которой агенты принимают участие в решении задачи, не фиксирована и может зависеть от стратегии решения задачи.
Разные агенты могут поставлять входные данные (результаты или частичные решения) в разных форматах и представлениях.
Агентам неизвестно о существовании других агентов напрямую, однако они могут оценивать вклад других агентов в решение задачи.
Решение
У некоторых агентов знаний есть доступ к общему хранилищу данных, которое называется доской. Доска снабжена интерфейсом для просмотра и изменения ее содержимого. Объект или модуль управления активирует агенты в соответствии с некоторой стратегией. После активации агент анализирует информацию на доске и принимает решение о том, может ли он помочь в решении задачи. Если агент решает, что он может помочь, управляющий объект может предоставить ему право на запись частичного (или конечного) решения на доске.
На этой диаграмме показано структурное (или статическое) представление, смоделированное с помощью UML. Это часть параметризуемого кооперирования, для которого фактические параметры устанавливаются в момент создания экземпляра по шаблону.
Архитектурный стиль
Для архитектуры программного продукта или отдельного архитектурного представления можно задать атрибут, который называется архитектурным стилем. Этот атрибут позволяет сократить количество доступных форм и придать архитектуре определенное единообразие. Стиль можно определить с помощью набора шаблонов или путем выбора конкретных компонентов и соединителей. Для отдельно взятых систем элементы стиля можно включить в руководство по архитектурному стилю в форме рабочего продукта рекомендаций по проекту RUP. От стиля напрямую зависят простота понимания и целостность архитектуры.
Архитектурный эскиз
Графическое изображение архитектурного представления называется архитектурным эскизом. Эскизы представлений, описанных выше, составляются из следующих диаграмм языка UML [UML01]:
Процесс разработки архитектуры
© Copyright IBM Corp. 1987, 2006. Все права защищены..