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

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

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

Концепции

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

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

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

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

История

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

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

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

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

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

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

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

После работы Перри и Вольфа возникли две точки зрения на описание архитектуры программного обеспечения.[нужна цитата ]:

  • Школа с несколькими представлениями
  • Структуралистская школа

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

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

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

Точки зрения на архитектуру

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

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

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

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

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

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

Фреймворки архитектуры

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

  • 4+1
  • RM-ODP (Эталонная модель открытой распределенной обработки)
  • TOGAF

Несколько просмотров

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ а б Perry, D.E .; Вольф, А. Л. (1992). «Основы исследования архитектуры программного обеспечения». Примечания по разработке программного обеспечения ACM SIGSOFT 17 (4): 40. doi: 10.1145 / 141874.141884
  2. ^ а б П. Б. Крухтен, "Модель представления архитектуры" 4 + 1 ", IEEE Software, vol. 12, вып. 6. С. 42–50, ноябрь 1995 г.
  3. ^ А. Финкельштейн, Дж. Крамер, Б. Нусейбе, Л. Финкельштейн и М. Гедике. Точки зрения: структура для интеграции нескольких точек зрения в разработку системы. Международный журнал программной инженерии и инженерии знаний, 2 (1): 31-58, 1992.
  4. ^ а б П. К. Клементс, Ф. Бахманн, Л. Басс, Д. Гарлан, Дж. Айверс, Р. Литтл, Р. Норд и Дж. Стаффорд, Документирование архитектур программного обеспечения: взгляды и не только. Аддисон Уэсли, 2003.
  5. ^ Г. Эстрин, Р.С. Фенчел, Р.Р. Разук, М.К. Вернон, "The Sсистема ARчитатель Аpprentice ", 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 г.

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