Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Você pode gerar ou configurar partes do seu 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 forma muito mais rápida e confiável do que atualizando o código. Embora algum trabalho inicial seja necessário para configurar a derivação, esse investimento será retornado se você espera alterações nos requisitos ou se planeja fazer várias variantes do produto.
Gerando o código de 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 em tempo de design usando modelos de texto T4
Gerando código de uma linguagem Domain-Specific
Esse método é fácil de aplicar incrementalmente. Comece com um aplicativo que funcione apenas para um caso específico e escolha algumas partes dele que você deseja variar do modelo. Renomeie os arquivos de origem dessas partes para que eles se tornem arquivos de modelo de texto (.tt). Neste ponto, os arquivos de .cs de origem serão gerados automaticamente a partir dos arquivos de modelo, portanto, o aplicativo funcionará como antes.
Em seguida, você pode 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, novamente, você possa executar o aplicativo e ele funcione como antes. Depois de testar valores de modelo diferentes, você pode passar para inserir expressões de modelo em outra parte do código.
Esse método incremental significa que a geração de código geralmente é uma abordagem de baixo risco. Os aplicativos resultantes geralmente executam quase tão bem quanto uma versão escrita à mão.
No entanto, se você começar com um aplicativo existente, poderá descobrir que muita refatoração é necessária 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 ao estimar o custo do seu projeto.
Configurando 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 que o aplicativo seja compilado. 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 do 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 as partes variáveis genéricas é mais caro do que a geração de código.
Um aplicativo genérico geralmente tem um desempenho menor do que seus equivalentes específicos. Se o desempenho for crucial, seu plano de projeto deverá incluir uma avaliação desse risco.
Desenvolvendo um aplicativo derivado
Você pode achar as diretrizes gerais a seguir úteis.
Inicie específico e generalize. Escreva uma versão específica do aplicativo primeiro. Essa versão deve funcionar em um conjunto de condições. Quando estiver satisfeito e certo de que está funcionando corretamente, você pode fazer com que parte disso seja derivada 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 links entre elas for alterado, mas o estilo e o formato das páginas forem sempre os mesmos, o modelo deverá descrever os links, mas não precisará 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. Usando o ModelBus, você pode definir operações que afetam os dois 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. Projete o modelo para que ele 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 na Web deve representar páginas da Web e hiperlinks entre elas. O modelo de navegação na 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 a partir do modelo. Se os requisitos podem mudar com frequência ou podem coexistir 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 a partir do modelo. Mas você usa seu modelo para controlar um site que muda todos os dias e, em seguida, é melhor escrever um servidor Web que lê o modelo e apresenta o site adequadamente.
UML ou DSL? Considere criar sua notação de modelagem usando estereótipos para estender a UML. Defina uma DSL se não houver nenhum diagrama UML que atenda à finalidade. Mas evite quebrar a semântica padrão da UML.
Por exemplo, um diagrama de classe 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 onde você está de fato descrevendo um conjunto de tipos. Por exemplo, você pode adaptar diagramas de classe para descrever diferentes tipos de páginas da Web.