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

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 г.

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