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

Описание архитектуры программного обеспечения — это набор практик для выражения, передачи и анализа архитектур программного обеспечения (также называемый архитектурной визуализацией), а также результат применения таких практик через рабочий продукт, выражающий архитектуру программного обеспечения ( 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 ). Точка зрения определяет не только сформулированные проблемы (то есть, которые необходимо решить), но и представление, используемые типы моделей, используемые соглашения и любые правила согласованности (соответствия), чтобы обеспечить согласованность представления с другими представлениями.

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

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

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

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

Язык описания архитектуры ( ADL ) — это любое средство выражения, используемое для описания архитектуры программного обеспечения ( ISO/IEC/IEEE 42010 ).С 1990-х годов было разработано множество ADL специального назначения, в том числе AADL (стандарт SAE), Wright (разработанный Carnegie Mellon), Acme (разработанный Carnegie Mellon), xADL (разработанный UCI), Darwin (разработанный Имперским колледжем Лондона ). , DAOP-ADL (разработан Университетом Малаги) и ByADL (Университет Аквилы, Италия). Ранние ADL уделяли особое внимание системам моделирования с точки зрения их компонентов, разъемов и конфигураций. Более поздние ADL (такие как ArchiMate и SysML), как правило, представляют собой языки «широкого спектра», способные выражать не только компоненты и соединители, но и множество задач посредством множества подъязыков. Помимо языков специального назначения, существующие языки, такие как UML, могут использоваться в качестве ADL «для анализа, проектирования и реализации программных систем, а также для моделирования бизнеса и подобных процессов».

Архитектурные каркасы

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

Арк42
Модель С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 ):

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

Ссылки

^ Jump up to: ^а ^б Перри, Делавэр; Вольф, Алабама (1992). «Основы изучения архитектуры программного обеспечения». Замечания по разработке программного обеспечения ACM SIGSOFT 17 (4): 40. doi:10.1145/141874.141884
^ Jump up to: ^а ^б П. Б. Крухтен, «Модель архитектуры представления «4+1», IEEE Software, vol. 12, нет. 6, стр. 42–50, ноябрь 1995 г.
^ А. Финкельштейн, Дж. Крамер, Б. Нусейбе, Л. Финкельштейн и М. Гедике. Точки зрения: структура для интеграции различных точек зрения при разработке системы. Международный журнал программной инженерии и инженерии знаний, 2 (1): 31-58, 1992.
^ Jump up to: ^а ^б П.К. Клементс, Ф. Бахманн, Л. Басс, Д. Гарлан, Дж. Айверс, Р. Литтл, Р. Норд и Дж. Стаффорд, Документирование архитектуры программного обеспечения: взгляды и не только. Эддисон Уэсли, 2003.
^ Г. Эстрин , Р. С. Фенчел, Р. Р. Разук, М. К. Вернон , « системного архитектора AR Ученик » , IEEE Transactions of Software Engineering, 1986.
^ Ф. ДеРемер и Х. Х. Крон, «Программирование в целом и программирование в малом», Транзакции IEEE по разработке программного обеспечения, 1976.
^ М. Шоу и Д. Гарлан, Архитектура программного обеспечения: перспективы новой дисциплины, Prentice Hall, 1996.
^ Э. Вудс и Р. Хиллиард, «Языки описания архитектуры на практике» http://doi.ieeecomputersociety.org/10.1109/WICSA.2005.15
^ А. Янсен и Дж. Бош, «Архитектура программного обеспечения как набор архитектурных проектных решений», Материалы 5-й рабочей конференции IEEE / IFIP по архитектуре программного обеспечения, 2005 г.

См. также

[PW-1] Jump up to: ^а ^б Перри, Делавэр; Вольф, Алабама (1992). «Основы изучения архитектуры программного обеспечения». Замечания по разработке программного обеспечения ACM SIGSOFT 17 (4): 40. doi:10.1145/141874.141884

[PBK-2] Jump up to: ^а ^б П. Б. Крухтен, «Модель архитектуры представления «4+1», IEEE Software, vol. 12, нет. 6, стр. 42–50, ноябрь 1995 г.

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

[VnB-4] Jump up to: ^а ^б П.К. Клементс, Ф. Бахманн, Л. Басс, Д. Гарлан, Дж. Айверс, Р. Литтл, Р. Норд и Дж. Стаффорд, Документирование архитектуры программного обеспечения: взгляды и не только. Эддисон Уэсли, 2003.

[5] Г. Эстрин , Р. С. Фенчел, Р. Р. Разук, М. К. Вернон , « системного архитектора AR Ученик » , IEEE Transactions of Software Engineering, 1986.

[6] Ф. ДеРемер и Х. Х. Крон, «Программирование в целом и программирование в малом», Транзакции IEEE по разработке программного обеспечения, 1976.

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

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

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

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]