Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. 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 é retornado se você espera mudanças nos requisitos ou se planeja fazer várias variantes do produto.
Gerando o 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 você 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 a partir de uma linguagem Domain-Specific
Este método é fácil de aplicar gradualmente. 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 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, para que o aplicativo funcione 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 fonte original para que novamente você possa executar o aplicativo e ele funcionará como antes. Depois de testar diferentes valores de modelo, você pode passar a 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 funcionam quase tão bem quanto uma versão manuscrita.
No entanto, se começares com uma aplicação existente, poderás achar que é necessário muito refactoring para separar os diferentes comportamentos regidos pelo modelo, de modo a que possam ser variáveis de forma independente. Recomendamos que avalie este aspeto da candidatura quando estimar o custo do seu projeto.
Configurando seu aplicativo a partir de um modelo
Se você quiser variar o comportamento do seu aplicativo em tempo de execução, não poderá usar a geração de código, que gera 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 de acordo. Para obter mais informações, consulte:
Como abrir um modelo de um ficheiro no código de programa
Este método também pode ser aplicado gradualmente, 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.
Uma aplicação genérica geralmente tem um desempenho menos bom do que os seus homólogos específicos. Se o desempenho for crucial, o seu plano de projeto deve incluir uma avaliação desse risco.
Desenvolvendo um aplicativo derivado
Poderá considerar úteis as seguintes orientações gerais.
Comece específico e, em seguida, generalize. Escreva uma versão específica do seu aplicativo primeiro. Esta versão deve funcionar em um conjunto de condições. Quando você estiver satisfeito que ele está funcionando corretamente, você pode fazer com que parte dele derive de um modelo. Extenda gradualmente as partes derivadas.
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 aspetos variantes. Identifique os aspetos que variarão, seja entre uma implantação e outra, ou ao longo do tempo à medida que os requisitos mudam. Estes são os aspetos que devem ser derivados de um modelo.
Por exemplo, se o conjunto de páginas da Web e links entre elas mudar, mas o estilo e o formato das páginas for sempre o mesmo, o modelo deve descrever os links, mas não precisa descrever o formato das páginas.
Preocupações separadas. Se os aspetos variáveis puderem ser divididos em áreas independentes, use modelos separados para cada área. Usando o ModelBus, você pode definir operações que afetam ambos os modelos e 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 aspetos 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 para uma implantação específica raramente forem alterados, gere o código do programa a partir do modelo. Se os requisitos forem 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, então você deve gerar o código do site a partir do modelo. Mas se você usa seu modelo para controlar um site que muda todos os dias, então é 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 UML. Defina uma DSL se não houver nenhum diagrama UML que se adapte à 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 esta notação você pode, em teoria, definir qualquer coisa. Mas não recomendamos que você use o diagrama de classes, exceto quando 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.