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