Архитектура программного обеспечения рассматривает программные системы на более абстрактном уровне, по сравнению с традиционными модулями, объектами или непосредственным кодом. Для того чтобы была возможность моделировать на таком уровне архитекторы должны обладать достаточно мощным и выразительным языком моделирования, а также инструментарием для управления моделью.
Традиционно представление архитектуры происходит в каком-либо языке представления архитектуры ADL. На сегодняшний день в области разработок – учеными и практиками уже создано относительно большое количество ADL для решения, под час, только определенного рода задач. Если попытаться найти общее среди различных ADL, то можно выявить, что большинство языков разделяют общие конструкции моделирования и концепции, включая компоненты, соединители и установки, конфигурации архитектуры. Различные ADL представляются небольшим набором особенностей и инструментарием, что можно отнести к специфике области применения этих языков в конкретных проектах.
Язык описания архитектуры можно охарактеризовать как «предоставление возможностей для моделирования концептуальной архитектурой программных систем, не зависимо от конкретной системной реализации. ADL предоставляет как концептуальный синтаксис, так и концептуальный инструментарий для описания архитектуры» [1].
В рамках сравнения ADL и Unified Modeling Language (UML), мы постараемся вкратце перечислить требования, сформулированные для языка претендующего на звание ADL[2], а так же описать, в чем UML [3] требует доработок.
В своей работе Aynur Abdurazik [4] сформулировал набор необходимых рекомендаций, которых следует придерживаться для того, чтобы создаваемый язык бы идеальным ADL:
- ADL должен обеспечивать возможность применения его для описания всех частей, возможно составной, архитектуры. Все описания, всех составных частей архитектуры должны быть сделаны на ADL, включая динамические и статические структуры. Компоненты, соединители и их типы должны быть определимы в каждой структуре и уровень детализации информации должен быть настраиваемый при формировании архитектуры
- ADL должен поддерживать стадии архитектуры: создание, усовершенствование и проверку на корректность. Это должно включать правила проверки уже сделанных частей, насколько завершена архитектура в целом
- ADL должна предоставлять возможность представления большинства архитектурных стилей
- ADL должен быть в состоянии предоставить структуры, содержащие краткое описание частей архитектуры и информацию не прямого назначения – не архитектурную, а для словесного описания
- ADL должна позволять архитектуре дальнейшее развитие, то есть должна быть возможность внесение новой информации, изменения описания архитектуры для получения конечного варианта архитектуры из ее описания на ADL
- Если язык может выразить информацию уровня реализации, он должен обладать возможностью сравнения более чем одной реализацией структуры уровня архитектуры системы. Язык должен поддерживать описание близких реализаций удовлетворяющих общей архитектуре
- ADL должен поддерживать либо возможность анализа архитектуры, основанную на информации уровня проектирования, либо возможность быстрой генерации прототипа реализации данной архитектуры для соответствующего анализа.
Теперь мы можем представить, как должен выглядеть идеальный ADL, при этом стоит учесть, что данные утверждения были сделаны не так давно – примерно в 1999 году.
Рассмотрим UML с точки зрения неудобства его использования как ADL:
«Минусы» UML:
- Соответствие: графическое представление слишком громоздкое для непосредственного отображения такого, как соответствие между элементами в различных представлениях
- Протоколы: Возможность показа «peer-to-peer» взаимодействия отсутствует в UML
- Интерфейс компонента: Приходиться использовать вложения интерфейса для отображения взаимодействия интерфейса и компонента, но визуально это вводит в заблуждение
- Динамические аспекты архитектуры: Класс диаграммы UML описываю статические структуры системы. Несмотря на то, что UML обладает диаграммами активностей, которые описывают динамику поведения, они не позволяют проводить динамическое настраивание системы. Нет возможности описать динамическое поведение всей системы в целом
- Единая последовательность деятельности: диаграммы последовательных действий UML описывают особенности последовательной активности. Система в целом может находиться в различных режимах, и установки этих режимов могут меняться со временем. В общем смысле диаграммы последовательностей и активностей не поддерживаются в UML, даже созданием избыточного количества диаграмм активностей или состояний решить проблему не удается
Замечания к UML
- UML не предоставляет понятий уровня компонентной разработки в полной мере. То есть, мы можем логически рассмотреть, как реализуется тот или иной use-case, но для проектирования каких-либо достаточно крупных систем, как универсальный язык, UML не подходит
- Классы, основные строительные элементы UML, не могут использоваться для проектирования сложных больших систем – они слишком мелкие для решения подобных задач
«Плюсы» UML
- Возможность полно описать статическую структуру архитектуры
- Изменчивость, возможность быстрого изменения архитектуры
- Частичная реализация последовательностей и активностей
Реально UML сейчас не используется для реализации сложных, крупных, узко специализированных проектов, которые требуют построения архитектуры, для начала большими блоками – модулями. Реализация какой-либо ADL средствами UML влечет изменение метамодели UML – что уже трудно назвать UML, скорее использование известного механизма. Однако, построение объектной архитектуры на сегодняшний день остается самым популярным способом моделирования для задач, решаемых средствами объектно-ориентированных языков. Для проектирования сложных, специальных систем разрабатываются новые ADL со всем необходимым инструментарием или же пользуются современные разработки, такие как xADL.
Компонентное проектирование позволяет проектировать на другом уровне – уровне составных частей и их взаимодействие между собой. Самым крупным модулем в UML может быть набор пакетов, в компонентном проектировании крупной единицей считается компонент, а он в свою очередь может быть чем угодно. Однако возможность детального описания устройства компонента должно быть также описано более подходящим способом, будь то объектно-ориентированный подход, модульный, компонентный – не важно, главное чтобы цели были достигнуты.
