Gerar e configurar o aplicativo por meio de modelos
Você pode gerar ou configurar partes do aplicativo a partir de um modelo.
O modelo representa os requisitos mais diretamente do que o código. Ao derivar o comportamento do aplicativo diretamente do modelo, você pode responder aos requisitos alterados de uma forma muito mais rápida e confiável do que com a atualização do código. Embora algum trabalho inicial seja necessário para configurar a derivação, esse esforço será recompensado se houver alterações nos requisitos ou se você pretende produzir diversas variantes do produto.
Geração do código do seu aplicativo a partir de um modelo
A maneira mais fácil de gerar código é usando modelos de texto. Você pode gerar código na mesma solução do Visual Studio na qual mantém o modelo. Para obter mais informações, consulte:
Geração de código na hora de design usando modelos de texto T4
Gerando código a partir de uma linguagem específica do domínio
Esse método é fácil de aplicar incrementalmente. Comece com um aplicativo que funciona apenas para um caso específico e escolha algumas partes dele que você quer variar em comparação com o modelo. Renomeie os arquivos de origem dessas partes para que eles se tornem arquivos de modelo de texto (.tt). Neste ponto, os arquivos .cs de origem serão gerados automaticamente a partir dos arquivos de modelo, portanto, o aplicativo funcionará como antes.
Então, você poderá pegar uma parte do código e substituí-la por uma expressão de modelo de texto, que lê o modelo e gera essa parte do arquivo de origem. Pelo menos um valor do modelo deve gerar a origem original, para que você possa executar novamente o aplicativo, e ele funcionará como antes. Depois de testar valores de modelo diferentes, comece a inserir expressões de modelo em outra parte do código.
Esse método incremental significa que a geração de código costuma ser uma abordagem de baixo risco. Os aplicativos resultantes geralmente têm um desempenho tão bom quanto uma versão escrita à mão.
No entanto, se você começar com um aplicativo existente, perceberá a necessidade de muita refatoração para separar os diferentes comportamentos que são regidos pelo modelo, para que eles possam ser variados independentemente. Recomendamos que você avalie esse aspecto do aplicativo estimar o custo do seu projeto.
Configuração de seu aplicativo a partir de um modelo
Se você quiser variar o comportamento do aplicativo em tempo de execução, não poderá usar a geração de código, que gera o código-fonte antes da compilação do aplicativo. Em vez disso, você pode projetar seu aplicativo para ler o modelo e variar seu comportamento adequadamente. Para obter mais informações, consulte:
Como abrir um modelo a partir de um arquivo no código do programa
Esse método também pode ser aplicado incrementalmente, mas há mais trabalho no início. Você precisa escrever o código que lerá o modelo e configurar uma estrutura que permita que seus valores sejam acessíveis às partes variáveis. Tornar genéricas as partes variáveis é mais caro do que a geração do código.
Um aplicativo genérico geralmente tem um desempenho inferior do que seus equivalentes específicos. Se o desempenho for crucial, seu plano de projeto deverá incluir uma avaliação desse risco.
Desenvolvimento de um aplicativo derivado
Você pode achar as diretrizes gerais a seguir úteis.
Comece de forma específica e, depois, generalize. Primeiro, escreva uma versão específica do aplicativo. Essa versão deve funcionar em um conjunto de condições. Quando estiver funcionando corretamente, você pode fazer com que parte dela derive de um modelo. Estenda as partes derivadas gradualmente.
Por exemplo, crie um site que tenha um conjunto específico de páginas da Web antes de criar um aplicativo Web que apresente páginas definidas em um modelo.
Modele os aspectos variantes. Identifique os aspectos que variarão, seja entre uma implantação e outra, ou ao longo do tempo, à medida que os requisitos forem alterados. Esses são os aspectos que devem ser derivados de um modelo.
Por exemplo, se o conjunto de páginas da Web e os links entre elas forem alterados, mas o estilo e o formato das páginas forem sempre os mesmos, o modelo deverá descrever os links, mas não precisa descrever o formato das páginas.
Preocupações separadas. Se os aspectos variáveis puderem ser divididos em áreas independentes, use modelos separados para cada área. Com o ModelBus, você pode definir operações que afetam os modelos e as restrições entre eles.
Por exemplo, use um modelo para definir a navegação entre as páginas da Web e um modelo diferente para definir o layout das páginas.
Modele o requisito, não a solução. Crie o modelo para que descreva os requisitos do usuário. Por outro lado, não projete a notação de acordo com os aspectos variáveis da implementação.
Por exemplo, o modelo de navegação da Web deve representar páginas da Web e hiperlinks entre elas. O modelo de navegação da Web não deve representar fragmentos de HTML ou classes em seu aplicativo.
Gerar ou interpretar? Se os requisitos de uma implantação específica raramente forem alterados, gere o código do programa do modelo. Se os requisitos puderem ser alterados com frequência ou coexistirem em mais de uma variante na mesma implantação, escreva o aplicativo para que ele possa ler e interpretar um modelo.
Por exemplo, se você usar seu modelo de site para desenvolver uma série de sites diferentes e instalados separadamente, deverá gerar o código do site do modelo. Mas você usa seu modelo para controlar um site que muda todos os dias, será melhor escrever um servidor Web que lê o modelo e apresenta o site de acordo.
UML ou DSL? Considere criar sua notação de modelagem usando estereótipos para estender a UML. Defina um DSL se não houver diagrama de UML que se ajuste à finalidade. Mas evite quebrar a semântica padrão da UML.
Por exemplo, um diagrama de classe de UML é uma coleção de caixas e setas; com essa notação, você pode, em teoria, definir qualquer coisa. Mas não recomendamos que você use o diagrama de classe, exceto quando estiver de fato descrevendo um conjunto de tipos. Por exemplo, você pode adaptar diagramas de classe para descrever diferentes tipos de páginas da Web.