Разработка DSL для описания архитектуры программного обеспечения, часть 1

Архитектура программного обеспечения определяет различные части программной системы и то, как они связаны друг с другом. Поддержание кодовой базы в соответствии с ее архитектурным планом имеет решающее значение для обеспечения возможности сопровождения сложного программного обеспечения в течение его срока службы. Конечно, архитектура будет развиваться с течением времени, но всегда лучше иметь архитектуру и применять ее, чем отказываться от организации своего кода. (См. Мой недавний пост в блоге: Любите свою архитектуру )

Проблемы начинаются, когда дело доходит до описания вашей архитектуры в формальной и обязательной форме. Вы можете написать хорошую статью в Вики, чтобы описать архитектуру вашей системы, или описать ее на слайде Powerpoint или с набором диаграмм UML; но это было бы совершенно бесполезно, поскольку невозможно автоматически проверить, соблюдается ли ваша архитектура кодом. И каждый, кто когда-либо работал над нетривиальным проектом с более чем двумя разработчиками, знает, что правила будут нарушены. Это приводит к постоянно растущему накоплению архитектурных долгов со всевозможными нежелательными побочными эффектами для долгосрочной устойчивости программного обеспечения. Вы также можете использовать Sonargraph 7 или аналогичные инструменты для создания графического представления вашего архитектурного проекта.Это уже намного лучше, потому что вы можете применять правила в ваших автоматических сборках или даже непосредственно в IDE. Но это также означает, что всем, кто хочет понять архитектуру, понадобится инструмент, чтобы увидеть ее. Вы также не сможете изменить архитектуру, не имея доступа к инструменту.

Было бы неплохо, если бы вы могли описать свою архитектуру как код, если бы у вас был DSL (предметно-ориентированный язык), который может использоваться архитекторами программного обеспечения для описания архитектуры системы и который достаточно выразителен и читабелен, чтобы каждый разработчик мог в состоянии это понять? Что ж, нам потребовалось некоторое время , чтобы придумать с этой идеей, но теперь я считаю , что это является недостающим куском головоломки , чтобы значительно увеличить принятие формализованных и осуществимых правил архитектуры программного обеспечения. Долгосрочные выгоды от их использования просто хороши, чтобы их игнорировать.

Приступая к разработке языка, мы сформулировали несколько основных требований:

1. Должна быть возможность описать архитектуру в наборе файлов. Некоторые из них должны быть достаточно общими, чтобы их можно было использовать во многих проектах, например, общий шаблон, описывающий многоуровневую систему.
2. Должна быть возможность описать архитектуру в форме нескольких совершенно независимых аспектов. Например, один аспект описывает разделение на слои, другой аспект описывает компоненты, а третий аспект рассматривает разделение логики клиента и сервера.
3. С другой стороны, язык также должен быть достаточно мощным, чтобы описать всю архитектуру в одном аспекте.
4. DSL должен быть легким для чтения и легким в освоении.

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

Архитектура как код

Основные строительные блоки: компоненты и артефакты

Чтобы описать архитектуру формально, нам сначала нужно подумать об основных строительных блоках, которые мы могли бы использовать для описания архитектуры системы. Наименьшая единица дизайна — это то, что мы называем физическим компонентом (или просто компонентом в его краткой форме). Для большинства языков, таких как Java или C #, это будет просто один исходный файл, для других языков, таких как C или C ++, компонент представляет собой комбинацию файла заголовка с соответствующими исходными файлами, которые реализуют элементы, объявленные в заголовке. Чтобы определить архитектуру, вы должны сгруппировать связанные компоненты в архитектурные артефакты. Затем вы можете сгруппировать несколько таких артефактов в артефакты более высокого уровня и так далее. Для каждого артефакта вы также определяете, какие другие артефакты могут ими использоваться.

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

"Core/com/hello2morrow/Main"                          // Main.java in package com.hello2morrow
"External [Java]/[Unknown]/java/lang/reflect/Method"  // The Method class from java.lang.reflection
"NHibernate/Action/SimpleAction"                      // SimpleAction.cs in subfolder of NHibernate
"External [C#]/System/System/Uri"                     // An external class from System.dll

"Core/**/business/**"             // All components from the Core module with "business" in their name
"External*/*/java/lang/reflect/*" // All components in java.lang.reflect

artifact Business
{
    include "Core/**/business/**"
}

artifact Reflection
{
    include "External*/*/java/lang/reflect/*"
}

artifact Business
{
    include "Core/**/business/**"
    connect default to Reflection.default
}

artifact Reflection
{
    include "External*/*/java/lang/reflect/*"
}

artifact Business
{
    // ...
    connect to Reflection
}

// ...

artifact Reflection
{
    include "External*/*/java/lang/reflect/*"

    interface default
    {
        include all
        exclude "**/Method"
    }
}

artifact Business
{
    include "Core/**/business/**"

    connector CanUseReflection
    {
        // Only include the controller classes in Business
        include "**/controller/**"
    }

    connect CanUseReflection to Reflection
}

// ...

artifact Business
{
    include "Core/**/business/**"

    hidden artifact Reflection
    {
        // Need a strong pattern to bypass patterns defined by parent artifact 
        strong include "External*/*/java/lang/reflect/*"
    }
}

artifact Business
{
    include "Core/**/business/**"

    hidden artifact Reflection
    {
        // Need a strong pattern to bypass patterns defined by parent artifact 
        strong include "External*/*/java/lang/reflect/*"
    }

    interface Refl
    {
        export Reflection
    }
}

artifact Business
{
    include "Core/**/business/**"

    exposed hidden artifact Reflection
    {
        // Need a strong pattern to bypass patterns defined by parent artifact 
        strong include "External*/*/java/lang/reflect/*"
    }
}

artifact name
{
    // include and exclude filters
    // nested artifacts
    // interfaces and connectors
    // connections
}

interface iname
{
    // include and exclude filter
    // exported nested interfaces
}

connector cname
{
    // include and exclude filters
    // included nested connectors
}