Создание и настройка приложения на основе моделей
Вы можете создавать или настраивать части приложения на основе модели.
Модель представляет требования более непосредственно, чем код. Выводя поведение приложения непосредственно из модели, можно реагировать на изменение требований намного быстрее и надежнее, чем путем обновления кода. Хотя для настройки такого вывода требуется проделать определенную начальную работу, эти затраты окупятся, если ожидаются изменения требований или планируется создание нескольких версий продукта.
Создание кода приложения на основе модели
Самый простой способ создания кода — это использование текстовых шаблонов. Вы можете создать код в том же решении Visual Studio, в котором хранится модель. Дополнительные сведения см. в разделе:
Создание кода во время разработки с помощью текстовых шаблонов T4
Создание кода из доменного языка
Этот метод легко применять последовательно. Начните с приложения, которое работает только для определенного случая, и выберите несколько его частей, которые должны изменяться в соответствии с моделью. Переименуйте исходные файлы этих частей, чтобы они стали файлами текстовых шаблонов (TT). На этом этапе исходные файлы CS будут автоматически созданы из файлов шаблонов, поэтому приложение будет работать точно так же, как и до этого.
Затем можно взять одну часть кода и заменить ее выражением текстового шаблона, которое считывает модель и создает данную часть исходного файла. По крайней мере одно значение модели должно создавать первоначальный исходный код, чтобы приложение можно было запустить снова и оно работало так же, как и раньше. После проверки различных значений модели можно перейти к следующему этапу и вставить выражения шаблона в другую часть кода.
Такой последовательный метод означает, что создание кода обычно является подходом с низким уровнем риска. Получающиеся приложения обычно работают почти так же хорошо, как и вручную написанная версия.
Однако если начинать работу на основе существующего приложения, может оказаться, что для разделения различных поведений, управляемых моделью, требуется обширный рефакторинг, чтобы можно было изменять поведения независимо. Рекомендуется рассматривать этот аспект приложения при оценке стоимости проекта.
Настройка приложения на основе модели
Если нужно изменять поведение приложения во время выполнения, невозможно использовать генерирование кода, при котором исходный код создается до компиляции приложения. Вместо этого вы можете разработать приложение для чтения модели и изменить его поведение соответствующим образом. Дополнительные сведения см. в разделе:
Практическое руководство. Открытие модели из файла в коде программы
Этот метод также может применяться последовательно, но вначале нужно выполнить больший объем работы. Необходимо написать код, который будет считывать модель, и настроить структуру, обеспечивающую доступ к ее значениям для переменных частей. Создание универсальных переменных частей требует больших затрат, чем генерирование кода.
Универсальное приложение обычно работает хуже, чем его специализированный аналог. Если производительность имеет критическое значение, план проекта должен включать в себя оценку этого риска.
Разработка производного приложения
Приведенные ниже общие рекомендации могут оказаться полезными.
Запустите конкретный, а затем обобщайте. Сначала напишите конкретную версию приложения. Эта версия должна работать при одном наборе условий. Когда будет определено, что приложение работает правильно, часть его можно сделать производной от модели. Расширяйте производные части постепенно.
Например, создайте веб-сайт с определенным набором веб-страниц перед проектированием веб-приложения, представляющее страницы, определенные в модели.
Моделировать аспекты варианта. Определите аспекты, которые либо будут различаться в разных развертываниях, либо будут изменяться с течением времени по мере изменения требований. Эти аспекты должны определяться моделью.
Например, если набор веб-страниц и связей между ними изменяется, но стиль и формат страниц всегда совпадает, модель должна описать ссылки, но не обязательно описывать формат страниц.
Отдельные проблемы. Если переменные аспекты можно разделить на независимые области, используйте отдельные модели для каждой из них. С помощью ModelBus можно определить операции, влияющие как на модели, так и на их ограничения.
Например, используйте одну модель для определения навигации между веб-страницами и другой моделью для определения макета страниц.
Моделировать требование, а не решение. Создайте модель таким образом, чтобы она описывала требования пользователей. Не следует разрабатывать нотацию в соответствии с переменными аспектами реализации.
Например, модель веб-навигации должна представлять веб-страницы и гиперссылки между ними. Модель веб-навигации не должна представлять фрагменты HTML или классов в приложении.
Создание или интерпретация? Если требования для конкретного развертывания будут изменяться редко, создайте код программы на основе модели. Если возможны частые изменения требований или в одном развертывании могут сосуществовать несколько вариантов, напишите приложение, способное считывать и интерпретировать модель.
Например, если вы используете модель веб-сайта для разработки ряда различных и отдельно установленных веб-сайтов, необходимо создать код сайта из модели. Но модель используется для управления сайтом, который изменяется каждый день, то лучше написать веб-сервер, который считывает модель и представляет сайт соответствующим образом.
UML или DSL? Рассмотрите возможность создания нотации моделирования с использованием стереотипов для расширения UML. Определите модель DSL при отсутствии схемы UML, удовлетворяющей конкретной цели. Однако избегайте нарушения стандартной семантики языка UML.
Например, схема классов UML представляет собой набор прямоугольников и стрелок. Теоретически с помощью этой нотации можно определить все что угодно. Однако схему классов рекомендуется использовать только в том случае, если вы действительно описываете набор типов. Например, можно адаптировать схемы классов для описания различных типов веб-страниц.