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

Языки описания архитектуры ( ADL ) используются в нескольких дисциплинах: системное проектирование , разработка программного обеспечения , а также моделирование и проектирование предприятия.

Сообщество системных инженеров использует язык описания архитектуры в качестве языка и/или концептуальной модели для описания и представления системных архитектур .

Сообщество разработчиков программного обеспечения использует язык описания архитектуры в качестве компьютерного языка для создания описания архитектуры программного обеспечения . В случае так называемой технической архитектуры об архитектуре необходимо сообщить разработчикам программного обеспечения; функциональная архитектура доводится до сведения различных заинтересованных сторон и пользователей. Некоторые ADL, которые были разработаны: Acme (разработан CMU ), AADL (стандартизован SAE ) , C2 (разработан UCI ), SBC-ADL (разработан Национальным университетом Сунь Ятсена ), Darwin (разработан Имперским колледжем ). Лондон ) и Райт (разработка CMU ).

Обзор

ISO /IEC/IEEE 42010. Документ « Системная и программная инженерия — Описание архитектуры» определяет язык описания архитектуры как «любую форму выражения для использования в описаниях архитектуры» и определяет минимальные требования к ADL .

Сообщество корпоративного моделирования и инженеров также разработало языки описания архитектуры, предназначенные для уровня предприятия. Примеры включают ArchiMate (теперь стандарт The Open Group ), DEMO , ABACUS (разработанный Технологическим университетом Сиднея ). Эти языки не обязательно относятся к компонентам программного обеспечения и т. д. Однако большинство из них относятся к архитектуре приложения как к архитектуре, которая сообщается разработчикам программного обеспечения.

Большая часть написанного ниже относится в первую очередь к точке зрения сообщества разработчиков программного обеспечения.

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

История

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

Коробка и линия долгое время были наиболее преобладающим средством описания SA. Предоставляя полезную документацию, уровень неформальность ограничивала полезность описания архитектуры. Требовался более строгий способ описания SA. Цитируя Аллена и Гарлана (1997): «Хотя эти [прямоугольные] описания могут предоставить полезную документацию, текущий уровень неформальности ограничивает их полезность. Поскольку обычно неточно то, что подразумевается под такими архитектурными описаниями, может оказаться невозможным проанализировать архитектуру на предмет согласованности или определить ее нетривиальные свойства. Более того, невозможно проверить, соответствует ли реализация системы своему архитектурному замыслу». Аналогичный вывод сделан Перри и Вольфом (1992). в котором сообщается, что: «Помимо предоставления четкой и точной документации, основная цель спецификаций состоит в том, чтобы обеспечить автоматизированный анализ документов и выявить различные виды проблем, которые в противном случае остались бы незамеченными».

С тех пор было проведено исследование формальных языков описания SA. Были предложены десятки формальных ADL, каждый из которых характеризуется разными концептуальными архитектурными элементами, разным синтаксисом или семантикой, ориентирован на конкретную операционную область или подходит только для разных методов анализа. Например, были представлены доменно-ориентированные ADL для работы со встроенными системами и системами реального времени (такими как AADL, ВОСТОК-АДЛ, и ЕАДЛ ), приложения контура управления (DiaSpec ), архитектуры продуктовой линейки (Koala ) и динамические системы (Π-ADL )). ADL, предназначенные для анализа, были предложены для решения задач доступности, надежности, безопасности, потребления ресурсов, качества данных и анализа производительности в реальном времени (AADL, поведенческий анализ (Fractal) )) и анализ надежности (TADL ).

Однако эти усилия не нашли должного внедрения в промышленной практике. Некоторые причины отсутствия признания в отрасли были проанализированы Вудсом и Хиллиардом. Панди, Клементс, и другие: формальные ADL редко интегрируются в жизненный цикл программного обеспечения, они редко поддерживаются зрелыми инструментами, почти не документируются, ориентированы на очень специфические потребности и не оставляют места для расширений, позволяющих добавлять новые функции.

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

Исследование 2013 года обнаружили, что специалисты-практики в целом удовлетворены конструктивными возможностями ADLS, которые они использовали, но у них есть несколько серьезных проблем: им не хватает функций анализа и возможности определять дополнительные функциональные свойства; те, которые используются на практике, в основном возникли в результате промышленного развития, а не академических исследований; им требовалось больше формальности и удобство использования.

Характеристики

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

Минимальные требования

Язык должен:

• Быть подходящим для передачи архитектуры всем заинтересованным сторонам.
• Поддержка задач по созданию, доработке и проверке архитектуры.
• Обеспечить основу для дальнейшей реализации, чтобы иметь возможность добавлять информацию в спецификацию ADL, чтобы окончательную спецификацию системы можно было получить из ADL.
• Обеспечить возможность представления большинства распространенных архитектурных стилей.
• Поддержка аналитических возможностей или быстрое создание прототипов

У ADL есть общие черты:

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

ADL различаются по своей способности:

• Обрабатывать конструкции реального времени, такие как сроки и приоритеты задач, на архитектурном уровне.
• Поддержка спецификации различных архитектурных стилей. Мало кто занимается объектно-ориентированным наследованием классов или динамическими архитектурами.
• Поддержка анализа архитектуры
• Обработка различных экземпляров одной и той же архитектуры в зависимости от архитектуры линейки продуктов.

ADL

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

ADL

• Не существует универсального соглашения о том, что должны представлять ADL, особенно в отношении поведения архитектуры.
• Используемые в настоящее время представления относительно сложны для анализа и не поддерживаются коммерческими инструментами.
• Большинство ADL имеют тенденцию быть вертикально оптимизированными для определенного вида анализа.

Общие понятия архитектуры

Сообщество ADL в целом согласно с тем, что архитектура программного обеспечения — это набор компонентов и связей между ними. Но существуют разные типы архитектур, такие как:

Архитектура соединения объектов

• Конфигурация состоит из интерфейсов и соединений объектно-ориентированной системы.
• Интерфейсы определяют функции, которые должны предоставляться модулями, соответствующими интерфейсу.
• Соединения, представленные интерфейсами вместе с графом вызовов
• Соответствие обычно обеспечивается языком программирования.
  • Декомпозиция — связывание интерфейсов с уникальными модулями.
  • Соответствие интерфейса — статическая проверка синтаксических правил.
  • Целостность связи — видимость между модулями

Архитектура подключения интерфейса

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

Большинство ADL реализуют архитектуру интерфейсного соединения.

Архитектура

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

Дизайн — это абстракция и спецификация шаблонов и функциональных элементов, которые были или будут реализованы. Архитектура на ступень выше как по абстракции, так и по степени детализации. Следовательно, архитектура по своей природе более топологична, чем проектирование, поскольку она определяет, где встречаются основные компоненты и как они связаны друг с другом. Архитектура фокусируется на разделении основных областей функциональности на компоненты высокого уровня, где они будут физически или виртуально находиться, какие готовые компоненты могут эффективно использоваться, в целом, какие интерфейсы будет предоставлять каждый компонент, какие протоколы будут использоваться между их, а также какие методы и шаблоны высокого уровня могут лучше всего соответствовать расширяемости , ремонтопригодности , надежности, долговечности, масштабируемости и другим нефункциональным целям. Проектирование — это детализация этих вариантов и более конкретное разъяснение того, как функциональные требования будут удовлетворены посредством делегирования частей этой функциональности более детальным компонентам и того, как эти более мелкие компоненты будут организованы в более крупные.

Зачастую часть архитектуры создается во время концептуализации приложения, системы или сети и может появиться в нефункциональных разделах документации с требованиями. Канонически дизайн не указывается в требованиях, а скорее определяется ими.

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

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

Примеры

• АрхиМейт
• Язык архитектурного анализа и проектирования
• Модель C4 (программное обеспечение)
• Дарвин (АДЛ)
• ВОСТОК-АДЛ
• Райт (АДЛ)

Подходы к архитектуре

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

См. также

• ААДЛ
• Дарвин
• Язык сценариев
• Язык описания оборудования

Внешние ссылки

• Медвидович Н.; Тейлор, Р.Н. (январь 2000 г.). «Структура классификации и сравнения языков описания архитектуры программного обеспечения». Транзакции IEEE по разработке программного обеспечения . 26 (1): 70–93. дои : 10.1109/32.825767 .
• Малаволта, Ивано; Лаго, Патрисия; Муччини, Генри; Пелличчоне, Патрицио; Тан, Энтони (2013). «Чего промышленности нужны архитектурные языки: обзор». Транзакции IEEE по разработке программного обеспечения . 39 (6): 869–891. дои : 10.1109/TSE.2012.74 . S2CID   6383726 .
• Языки описания архитектуры // Университет Мелардален
• Клементс, ПК (1996). «Обзор языков описания архитектуры» (PDF) . Материалы 8-го международного семинара по спецификации и проектированию программного обеспечения . стр. 16–25. дои : 10.1109/IWSSD.1996.501143 . ISBN  0-8186-7361-3 . S2CID   7307554 . Архивировано из оригинала (PDF) 24 декабря 2013 г.
• СЧЕТЫ
• АКМЕ
• АДМЛ
• Эзоп
• АО-АДЛ
• ArchiMate Пример ADL для архитектуры предприятия
• ByADL (Build Your ADL) - Университет Л'Акуилы
• С2 САДЛ
• ДАОП-АДЛ
• ДЕМО Еще один пример корпоративной архитектуры ADL.
• DiaSpec - подход и инструмент для создания распределенной среды на основе архитектуры программного обеспечения.
• Малаволта, И.; Муччини, Х.; Пелличчоне, П.; Тамбурри, Д. (январь – февраль 2010 г.). «Обеспечение совместимости архитектурных языков и инструментов посредством технологий преобразования моделей». Транзакции IEEE по разработке программного обеспечения . 36 (1): 119–140. дои : 10.1109/TSE.2009.51 . S2CID   6825192 . ДВОЙНО
• Быстрый
• ССЭП
• Юникон
• Райт