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

Практики анализа архитектур программного обеспечения

Описание архитектуры программного обеспечения — это набор практик для выражения, передачи и анализа архитектур программного обеспечения (также называемых архитектурной визуализацией), а также результат применения таких практик посредством рабочего продукта, выражающего архитектуру программного обеспечения ( ISO/IEC/IEEE 42010 ).

Описания архитектуры (AD) также иногда называют представлениями архитектуры , спецификациями архитектуры ^[1] или документацией архитектуры программного обеспечения .

Концепции

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

Часто модели описания архитектуры организованы в несколько представлений архитектуры таким образом, что «каждое [представление] рассматривает конкретные проблемы, представляющие интерес для различных заинтересованных сторон системы». ^[2] Точка зрения архитектуры — это способ взглянуть на систему ( RM ODP ). Каждое представление в описании архитектуры должно иметь точку зрения, документирующую проблемы и заинтересованные стороны, которым оно адресовано, а также типы моделей, нотации и соглашения по моделированию, которые оно использует ( ISO/IEC/IEEE 42010 ).

Использование нескольких представлений, хотя и эффективно для общения с различными заинтересованными сторонами, а также для регистрации и анализа различных проблем, порождает потенциальные проблемы: поскольку представления, как правило, не являются независимыми, потенциальная возможность их совпадения означает, что между представлениями одной системы может быть избыточность или несогласованность. ^{[3] Для определения и управления}соответствиями между представлениями для обмена подробностями, уменьшения избыточности и обеспечения согласованности могут использоваться различные механизмы .

Распространенное заблуждение относительно описаний архитектуры заключается в том, что AD обсуждают только «технические вопросы», но AD должны решать вопросы, имеющие значение для многих заинтересованных сторон. Некоторые вопросы являются техническими; многие — нет: AD используются для помощи архитекторам, их клиентам и другим лицам в управлении затратами, графиком и процессом. Связанное с этим заблуждение заключается в том, что AD решают только структурные аспекты системы. Однако это редко удовлетворяет заинтересованных сторон, чьи интересы часто включают структурные, поведенческие, эстетические и другие «дополнительные функциональные» проблемы.

История

Самые ранние описания архитектуры использовали неформальные изображения и диаграммы и связанный с ними текст. Неформальные описания остаются наиболее широко используемыми представлениями в промышленности. ^[4] Влияние на описание архитектуры оказали области программной инженерии (такие как абстракция данных и программирование в целом) и системное проектирование (такое как SARA ^[5] ).

Работа над программированием в больших масштабах, например, языки взаимодействия модулей (MIL), была сосредоточена на выражении крупномасштабных свойств программного обеспечения: ^[6] модули (включая программы, библиотеки, подпрограммы и подсистемы) и модульные связи (зависимости и взаимосвязи между модулями). Эта работа повлияла как на архитектурное мышление о языках программирования (например, Ada), так и на нотации проектирования и архитектуры (такие как диаграммы Бура и карты вариантов использования, кодифицированные в архитектурных особенностях UML: пакеты, подсистемы, зависимости), а также на большую часть работы над языками описания архитектуры. В дополнение к MIL, под влиянием зрелой работы в областях требований и проектирования в программной инженерии, различные виды моделей были «подняты» из программной инженерии и проектирования для применения к описанию архитектур. К ним относятся функциональные и активные модели из структурного анализа SADT , методы моделирования данных (сущность-отношение) и объектно-ориентированные методы.

Перри и Вольф ^[1] привели прецедент из строительной архитектуры, описывающий роль множественных видов: «Архитектор здания работает с заказчиком с помощью ряда различных видов, в которых подчеркивается какой-то конкретный аспект здания».

Перри и Вольф утверждали, что представление архитектур должно включать: {элементы, форму и обоснование} , различая три вида элементов (и, следовательно, три вида представлений):

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

Перри и Вольф определили четыре цели или области применения описаний архитектуры (в своей статье они называются «спецификациями архитектуры»):

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

После статьи Перри и Вольфа возникли две школы мысли по описанию архитектуры программного обеспечения ^{[ необходима ссылка ]} :

Школа множественных просмотров
Структуралистская школа

Механизмы описания архитектуры

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

точки зрения архитектуры
языки описания архитектуры
Архитектурные фреймворки

Архитектурные точки зрения

Описания архитектуры программного обеспечения обычно организованы в представления , которые аналогичны различным типам чертежей , сделанных в архитектуре зданий . Каждое представление рассматривает набор системных проблем, следуя соглашениям своей точки зрения , где точка зрения является спецификацией, которая описывает нотации, методы моделирования, которые должны использоваться в представлении для выражения рассматриваемой архитектуры с точки зрения заданного набора заинтересованных сторон и их проблем ( ISO/IEC 42010 ). Точка зрения определяет не только сформулированные проблемы (т. е. те, которые должны быть рассмотрены), но и представление, используемые виды моделей, используемые соглашения и любые правила согласованности (соответствия), чтобы поддерживать представление согласованным с другими представлениями.

Примеры точек зрения включают в себя:

Функциональная точка зрения
Логическая точка зрения
Точка зрения информации/данных
Точка зрения модуля
Точка зрения компонентов и соединителей
Точка зрения требований
Точка зрения разработчика/реализации
Точка зрения параллелизма/процесса/времени выполнения/потока/выполнения
Точка зрения производительности
Точка зрения безопасности
Физическая/развертывание/установка точка зрения
Точка зрения действий/обратной связи пользователя

Термин viewtype используется для обозначения категорий схожих представлений, имеющих общий набор элементов и отношений. ^[4]

Языки описания архитектуры

Язык описания архитектуры ( ADL ) — это любое средство выражения, используемое для описания архитектуры программного обеспечения ( ISO/IEC/IEEE 42010 ). С 1990-х годов было разработано множество специализированных ADL, включая AADL (стандарт SAE), Wright (разработанный Carnegie Mellon), Acme (разработанный Carnegie Mellon), xADL (разработанный UCI), Darwin (разработанный Imperial College London ), DAOP-ADL (разработанный University of Málaga) и ByADL (University of L'Aquila, Italy). Ранние ADL делали акцент на моделировании систем с точки зрения их компонентов, соединителей и конфигураций. Более поздние ADL (такие как ArchiMate и SysML) имели тенденцию быть языками «широкого спектра», способными выражать не только компоненты и соединители, но и различные проблемы с помощью нескольких подъязыков. Помимо языков специального назначения, существующие языки, такие как UML, могут использоваться в качестве ADL «для анализа, проектирования и внедрения систем на основе программного обеспечения, а также для моделирования бизнес-процессов и аналогичных процессов».

Архитектурные фреймворки

Архитектурная структура охватывает «соглашения, принципы и практики для описания архитектур, установленных в рамках определенной области применения и/или сообщества заинтересованных сторон» ( ISO/IEC/IEEE 42010 ). Структура обычно реализуется в терминах одной или нескольких точек зрения или ADL. Фреймворки, представляющие интерес для архитектуры программного обеспечения, включают:

Arc42
Модель С4
4+1
RM-ODP (эталонная модель открытой распределенной обработки)
ТОГАФ

Несколько видов

Представленный в очень влиятельной статье Крухтена 1995 года о «модели представления 4+1» , этот подход подчеркивал различные заинтересованные стороны и проблемы, которые необходимо моделировать. ^[2]

Структурализм

Во-вторых, в работах CMU и других работах отражено представление о том, что архитектура представляет собой высокоуровневую организацию системы во время выполнения и что архитектура должна быть описана в терминах ее компонентов и соединителей: «архитектура программной системы определяет эту систему в терминах вычислительных компонентов и взаимодействий между этими компонентами» ^{[7] .}

В 1990-2000-х годах большая часть академической работы по ADL проводилась в рамках парадигмы компонентов и соединителей. Однако эти ADL оказали очень малое влияние на промышленность. ^[8] С 1990-х годов наблюдается сближение подходов к описанию архитектуры, и в 2000 году IEEE 1471 систематизировал лучшие практики: поддержка, но не требование, множественных точек зрения в AD.

Описание архитектуры через решения

Развивая рациональный аспект оригинальной формулы Перри и Вольфа, возникла третья школа мысли, документирующая решения и причины решений как существенный способ понимания и выражения архитектуры программного обеспечения. ^[9] Этот подход рассматривает решения как первоклассные элементы описания архитектуры, делая явным то, что часто подразумевалось в более ранних представлениях.

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

Описания архитектуры служат различным целям, включая ( ISO/IEC/IEEE 42010 ):

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

Ссылки

^ ab Perry, DE; Wolf, AL (1992). "Основы изучения архитектуры программного обеспечения". ACM SIGSOFT Software Engineering Notes 17 (4): 40. doi:10.1145/141874.141884
^ ab PB Kruchten, «Модель представления архитектуры '4+1'», IEEE Software, т. 12, № 6, стр. 42–50, ноябрь 1995 г.
^ А. Финкельштейн, Дж. Крамер, Б. Нусейбех, Л. Финкельштейн и М. Годике. Точки зрения: структура для интеграции множественных перспектив в разработку систем. Международный журнал по программной инженерии и инженерии знаний, 2(1):31-58, 1992.
^ ab PC Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord и J. Stafford, Документирование архитектур программного обеспечения: взгляды и далее. Addison Wesley, 2003.
^ Г. Эстрин , Р. С. Фенчел, Р. Р. Разук, М. К. Вернон , «Ученик архитектора систем дополненной реальности » , Труды IEEE по программной инженерии, 1986.
^ Ф. ДеРемер и Х. Х. Крон, «Программирование в целом против программирования в малом», Труды IEEE по программной инженерии, 1976.
^ М. Шоу и Д. Гарлан, Архитектура программного обеспечения: перспективы новой дисциплины, Prentice Hall, 1996.
^ Э. Вудс и Р. Хиллиард, «Языки описания архитектуры на практике» http://doi.ieeecomputersociety.org/10.1109/WICSA.2005.15
^ А. Янсен и Дж. Бош, «Архитектура программного обеспечения как набор архитектурных проектных решений», Труды 5-й рабочей конференции IEEE/IFIP по архитектуре программного обеспечения, 2005.

Смотрите также

[PW-1] Perry, DE; Wolf, AL (1992). "Основы изучения архитектуры программного обеспечения". ACM SIGSOFT Software Engineering Notes 17 (4): 40. doi:10.1145/141874.141884

[PBK-2] PB Kruchten, «Модель представления архитектуры '4+1'», IEEE Software, т. 12, № 6, стр. 42–50, ноябрь 1995 г.

[3] А. Финкельштейн, Дж. Крамер, Б. Нусейбех, Л. Финкельштейн и М. Годике. Точки зрения: структура для интеграции множественных перспектив в разработку систем. Международный журнал по программной инженерии и инженерии знаний, 2(1):31-58, 1992.

[VnB-4] PC Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord и J. Stafford, Документирование архитектур программного обеспечения: взгляды и далее. Addison Wesley, 2003.

[5] Г. Эстрин , Р. С. Фенчел, Р. Р. Разук, М. К. Вернон , «Ученик архитектора систем дополненной реальности » , Труды IEEE по программной инженерии, 1986.

[6] Ф. ДеРемер и Х. Х. Крон, «Программирование в целом против программирования в малом», Труды IEEE по программной инженерии, 1976.

[7] М. Шоу и Д. Гарлан, Архитектура программного обеспечения: перспективы новой дисциплины, Prentice Hall, 1996.

[8] Э. Вудс и Р. Хиллиард, «Языки описания архитектуры на практике» http://doi.ieeecomputersociety.org/10.1109/WICSA.2005.15

[9] А. Янсен и Дж. Бош, «Архитектура программного обеспечения как набор архитектурных проектных решений», Труды 5-й рабочей конференции IEEE/IFIP по архитектуре программного обеспечения, 2005.