Создание и настройка приложения из моделей

Статья
08/11/2011

Можно генерировать или настраивать части приложения из модели. Модель может быть создана на языке UML или DSL.

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

Создание кода приложения из модели

Самый простой способ создания кода — это использование текстовых шаблонов. Код можно генерировать в том же решении Visual Studio, в котором находится модель. Дополнительные сведения см. в следующих разделах.

Этот метод легко применять последовательно. Начните с приложения, которое работает только для определенного случая, и выберите несколько частей приложения, которые должны изменяться в соответствии с моделью. Переименуйте исходные файлы этих частей, чтобы они стали файлами текстовых шаблонов (TT). На этом этапе исходные файлы CS будут автоматически созданы из файлов шаблонов, поэтому приложение будет работать точно так же, как и до этого.

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

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

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

Настройка приложения из модели

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

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

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

Разработка производного приложения

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

Начинайте с конкретного, потом обобщайте. Сначала напишите конкретную версию приложения. Эта версия должна работать при одном наборе условий. Когда будет определено, что приложение работает правильно, часть его можно сделать производной от модели. Расширяйте производные части постепенно.

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

Например, если набор веб-страниц и связи между ними изменяются, но стиль и формат этих страниц всегда остаются неизменными, то модель должна описывать связи, но не обязана описывать формат этих страниц.
Разделите области ответственности. Если переменные аспекты можно разделить на независимые области, используйте отдельные модели для каждой области. С помощью ModelBus можно определить операции, влияющие как на модели, так и на их взаимосвязи.

Например, используйте одну модель для определения перехода между веб-страницами и другую модель для определения разметки страниц. Дополнительные сведения см. в разделе Практическое руководство. Интеграция моделей UML с другими моделями и средствами.
Моделируйте требование, а не решение. Разработайте язык DSL или адаптируйте язык UML, чтобы он описывал требования пользователя. Напротив, не следует разрабатывать нотацию в соответствии с переменными аспектами реализации.

Например, модель веб-навигации должна представлять веб-страницы и гиперссылки между ними. Модель веб-навигации не должна представлять фрагменты кода HTML или классы в приложении.
Генерирование или интерпретация? Если требования для конкретного развертывания будут изменяться редко, сгенерируйте код программы из модели. Если возможны частые изменения требований или в одном развертывании могут сосуществовать несколько вариантов, напишите приложение, способное считывать и интерпретировать модель.

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

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