Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

Обзор [ править ]

ISO / IEC / IEEE 42010 [1] документ, системы и программное обеспечение описание инженерно-архитектура , определяет язык описания архитектуры как «любая форма выражения для использования в описании архитектуры» и указывает минимальные требования по ADLs .

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

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

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

История [ править ]

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

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

С тех пор был проведен ряд исследований формальных языков для описания SA. Были предложены десятки формальных ADL, каждый из которых характеризуется различными концептуальными архитектурными элементами, разным синтаксисом или семантикой, ориентирован на конкретную операционную область или подходит только для различных методов анализа. Например, доменно-ориентированные ADL были представлены для работы со встроенными системами и системами реального времени (такими как AADL, [4] EAST-ADL, [5] и EADL [6] ), приложениями контура управления (DiaSpec [7] ), архитектуры продуктовой линейки (Koala [8] ) и динамических систем (Π-ADL [9])). ADL, ориентированные на анализ, были предложены для работы с доступностью, надежностью, безопасностью, потреблением ресурсов, качеством данных и анализом производительности в реальном времени (AADL, поведенческий анализ (Fractal [10] )) и анализом надежности (TADL [11] ).

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

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

Фактически, как было подчеркнуто в недавнем исследовании, проведенном с практиками [17], хотя практики в целом удовлетворены возможностями проектирования, обеспечиваемыми используемыми ими языками, они недовольны особенностями архитектурного языкового анализа и их способностями определять дополнительные функциональные свойства. ; архитектурные языки, используемые на практике, в основном берут начало в промышленном развитии, а не в академических исследованиях; От архитектурного языка требуется больше формальности и лучшего удобства использования.

Характеристики [ править ]

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

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

Язык должен:

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

Общее у ADL:

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

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

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

Положительные элементы ADL [ править ]

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

Отрицательные элементы ADL [ править ]

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

Общие концепции архитектуры [ править ]

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

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

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

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

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

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

Архитектура против дизайна [ править ]

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

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

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

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

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

Примеры [ править ]

Ниже в списке указаны кандидаты на звание лучшего [ цитата ] ADL на сегодняшний день.

Актуальный список существующих в настоящее время архитектурных языков см . В разделе «Актуальный список ADL» .

  • Первичные кандидаты
    • ABACUS (UTS)
    • ACME / ADML (CMU / USC)
    • ADML (больше не в разработке)
    • ByADL (Build Your ADL) - Университет Аквилы
    • LePUS3 и Class-Z (Университет Эссекса)
    • Rapide (Стэнфорд)
    • Райт (CMU)
    • Юникон (CMU)
  • Вторичные кандидаты
    • Эзоп (CMU)
    • MetaH (Honeywell)
    • AADL (SAE) - rchitecture нализ & D ESIGN L anguage
    • C2 SADL (UCI)
    • SADL (СОИ) - S ystem rchitecture D ПИСАНИЕ л anguage
  • Прочие (несекретные)
    • Lileanna - L ibrary I nterconnect L anguage E Xtended с Энн otated А - да
    • Dually: обеспечение взаимодействия архитектурных языков и инструментов с помощью технологий преобразования моделей
    • Подобно ArchC SystemC , фокусируется на наборах команд и моделях памяти .
    • АО-АДЛ
    • ArchiMate Пример ADL для корпоративной архитектуры
    • Модель C4
    • DAOP-ADL
    • ДЕМО Еще один пример корпоративной архитектуры ADL
    • DiaSpec - подход и инструмент для создания распределенной структуры из программной архитектуры.
    • SSEP
    • Юникон
    • xADL

Подходы к архитектуре [ править ]

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

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

См. Также [ править ]

  • AADL
  • Дарвин
  • СЧЕТЫ
  • Язык сценариев
  • Язык описания оборудования

Ссылки [ править ]

  1. ^ Комитет ISO / IECJTC 1 / SC 7 (2011-03-01). «ISO / IEC FDIS42010» (PDF) . Архивировано из оригинального (PDF) 26 апреля 2012 года . Проверено 5 декабря 2011 .
  2. ^ Allen, R .; Гарлан Д. (1997). «Формальная основа для архитектурного соединения». ACM Transactions по программной инженерии и методологии . 6 (3): 213. CiteSeerX 10.1.1.40.66 . DOI : 10.1145 / 258077.258078 . 
  3. ^ Перри, Германия; Вольф, А.Л. (1992). «Основы изучения архитектуры программного обеспечения» (PDF) . Примечания по разработке программного обеспечения ACM SIGSOFT . 17 (4): 40. CiteSeerX 10.1.1.40.5174 . DOI : 10.1145 / 141874.141884 .  
  4. ^ «AADL - Архитектурный анализ и язык дизайна» . Институт программной инженерии, Университет Карнеги-Меллона. Июль 2019.
  5. ^ "ВОСТОК-АДЛ" .
  6. ^ Li, J .; Pilkington, NT; Xie, F .; Лю, К. (2010). «Язык описания встроенной архитектуры». Журнал систем и программного обеспечения . 83 (2): 235. CiteSeerX 10.1.1.134.8898 . DOI : 10.1016 / j.jss.2009.09.043 . 
  7. ^ "AADL" . Архивировано из оригинала на 2013-06-01 . Проверено 10 декабря 2012 .
  8. ^ Ван Оммеринг, Р .; Van Der Linden, F .; Kramer, J .; Маги, Дж. (2000). «Компонентная модель Koala для программного обеспечения бытовой электроники». Компьютер . 33 (3): 78. CiteSeerX 10.1.1.469.8243 . DOI : 10.1109 / 2.825699 . 
  9. Перейти ↑ Oquendo, Flavio (2004). «П-АДЛ». Примечания по разработке программного обеспечения ACM SIGSOFT . 29 (3): 1. DOI : 10,1145 / 986710,986728 . ISSN 0163-5948 . 
  10. ^ Bruneton, E .; Coupaye, T .; Leclercq, M .; Quéma, V .; Стефани, JB (2006). «Компонентная модель FRACTAL и ее поддержка в Java». Программное обеспечение: практика и опыт . 36 (11–12): 1257. CiteSeerX 10.1.1.471.4374 . DOI : 10.1002 / spe.767 . 
  11. ^ "ТАДЛ" . 2009-04-29.
  12. ^ Woods, E .; Хиллиард, Р. (2005). «Языки описания архитектуры на практике». 5-я рабочая конференция IEEE / IFIP по архитектуре программного обеспечения (WICSA'05) . п. 243. DOI : 10,1109 / WICSA.2005.15 . ISBN 978-0-7695-2548-8.
  13. ^ Пандей, Р. К. (2010). «Языки описания архитектуры (ADL) против UML». Примечания по разработке программного обеспечения ACM SIGSOFT . 35 (3): 1. DOI : 10,1145 / 1764810,1764828 .
  14. Перейти ↑ Clements, PC (1996). «Обзор языков описания архитектуры». Труды 8-го Международного семинара по спецификации и дизайну программного обеспечения . С. 16–00. CiteSeerX 10.1.1.208.3401 . DOI : 10.1109 / IWSSD.1996.501143 . ISBN  978-0-8186-7361-0.
  15. ^ "Гарлан_TR" .
  16. ^ Перес-Мартинес, JE; Сьерра-Алонсо, А. (2004). «UML 1.4 против UML 2.0 как языки для описания программных архитектур». Архитектура программного обеспечения . Конспект лекций по информатике. 3047 . п. 88. DOI : 10.1007 / 978-3-540-24769-2_7 . ISBN 978-3-540-22000-8.
  17. ^ Малаволта, Ивано; Лаго, Патрисия; Муччини, Генри; Пелличчоне, Патрицио; Тан, Энтони (2013). «Что нужно индустрии от архитектурных языков: обзор». IEEE Transactions по разработке программного обеспечения . 39 (6): 869–891. DOI : 10.1109 / TSE.2012.74 .

Внешние ссылки [ править ]

  • Medvidovic, N .; Тейлор, Р. Н. (январь 2000 г.). «Структура классификации и сравнения языков описания архитектуры программного обеспечения». IEEE Transactions по разработке программного обеспечения . 26 (1): 70–93. DOI : 10.1109 / 32.825767 .
  • Малаволта, Ивано; Лаго, Патрисия; Муччини, Генри; Пелличчоне, Патрицио; Тан, Энтони (2013). «Что нужно индустрии от архитектурных языков: обзор». IEEE Transactions по разработке программного обеспечения . 39 (6): 869–891. DOI : 10.1109 / TSE.2012.74 .
  • Языки описания архитектуры // Университет Мелардален
  • Клементс, PC (1996). «Обзор языков описания архитектуры» (PDF) . Труды 8-го Международного семинара по спецификации и дизайну программного обеспечения . С. 16–25. DOI : 10.1109 / IWSSD.1996.501143 . ISBN 0-8186-7361-3. Архивировано из оригинального (PDF) 24 декабря 2013 года.
  • СЧЕТЫ
  • ACME
  • ADML
  • Эзоп
  • АО-АДЛ
  • ArchiMate Пример ADL для корпоративной архитектуры
  • ByADL (Build Your ADL) - Университет Аквилы
  • C2 SADL
  • DAOP-ADL
  • ДЕМО Еще один пример корпоративной архитектуры ADL
  • DiaSpec - подход и инструмент для создания распределенной структуры из программной архитектуры.
  • Malavolta, I .; Muccini, H .; Pelliccione, P .; Тамбурри, Д. (январь – февраль 2010 г.). «Обеспечение взаимодействия архитектурных языков и инструментов с помощью технологий преобразования моделей». IEEE Transactions по разработке программного обеспечения . 36 (1): 119–140. DOI : 10.1109 / TSE.2009.51 . ДВОЙНО
  • Rapide
  • SSEP
  • Юникон
  • Райт