O Modelo Lógico: Definição e Planejamento de Aplicações
A segunda etapa em um processo de design de aplicativo COM+ é dividir o modelo conceitual nas camadas lógicas da arquitetura de três camadas: a camada de apresentação ou serviços de usuário, a camada intermediária ou serviços de negócios e a camada de dados ou serviços de dados. Se você não estiver familiarizado com a arquitetura de três camadas, consulte Usando um modelo de arquitetura de três camadas.
Comece esse processo examinando o modelo conceitual para substantivos e verbos. Os substantivos muitas vezes podem se traduzir em objetos de negócios (classes), e os verbos associados a eles podem se traduzir em ações (métodos das classes). Embora possa ser difícil definir todos os substantivos como objetos de negócios, omissões ou erros se tornarão óbvios quando você concluir o modelo lógico.
A maioria dos objetos de negócios acabará na camada de serviços corporativos, com os objetos restantes divididos entre objetos de interface do usuário na camada de serviços do usuário e objetos de dados na camada de serviços de dados. Ao criar um modelo lógico usando a arquitetura de três camadas, lembre-se do seguinte:
- Alguns dos substantivos no design conceitual não representarão partes físicas reais de dados, mas podem representar uma ação no sistema ou a função de um objeto de negócios no sistema. Um objeto comercial também pode ser um serviço que executa algum tipo de controle do sistema, como uma ID de login para segurança.
- Evite criar objetos de negócios vagos "lendo nas entrelinhas" no modelo conceitual. Esses objetos de negócios podem não estar corretos, e você deve considerá-los cuidadosamente antes de incluí-los no modelo lógico. Se parecerem corretos, adicione-os ao modelo conceitual explicitamente.
- Evite criar objetos de negócios que expressem a mesma informação ou função; A duplicação pode ser dispendiosa em termos de velocidade e desempenho da aplicação.
- Determine as dependências do objeto. Alguns substantivos no modelo conceitual podem ser simplesmente atributos de outros objetos de negócios. Decida se o atributo pode existir independentemente. Em caso afirmativo, deve tornar-se o seu próprio objeto comercial; caso contrário, ele deve ser combinado com o objeto de negócios apropriado.
- Evite criar objetos de negócios que tentam fazer muito. Sobrecarregar objetos de negócios pode significar mais tempo gasto separando código mais tarde e pode ser uma dor de cabeça de manutenção. Objetos distintos no modelo conceitual não devem ser combinados; eles devem permanecer objetos de negócios separados. Você pode lidar com quaisquer semelhanças usando código para delegar suas funções comuns a um objeto de negócios.
- Remova todos os objetos de negócios que não são usados em nenhum cenário de uso. Se os objetos se destinam a acomodar o crescimento futuro, considere implementá-los após a conclusão do aplicativo inicial.
Neste ponto, você pode começar a pensar em termos de computadores e código. A partir desses serviços corporativos, determine a funcionalidade de exibição e entrada que você precisa fornecer como serviços de usuário. Defina quais tabelas e procedimentos armazenados precisam ser fornecidos como serviços de dados. Para concluir o modelo lógico, defina as interfaces para cada serviço e inclua definições de cada campo de dados e suas regras de validação. Inclua também todas as funções, sua sintaxe e seus parâmetros.
A definição de serviço ou objeto não deve incluir nenhum aspecto da implementação física. A intenção é fornecer uma diretriz clara para os construtores de componentes lógicos trabalharem e permitir que outros programadores codifiquem partes do aplicativo que podem usar o componente antes que ele seja realmente concluído. No design do modelo lógico, você deve documentar cada tela, função e objeto. Não prossiga para o modelo físico ou implementação até atender a esses critérios. Se você prosseguir enquanto o modelo conceitual e o modelo lógico não estiverem de acordo, você terá sérios problemas mais tarde no ciclo de desenvolvimento.
O desenvolvimento incremental de um aplicativo COM+ é comum. Isso envolve criar um subconjunto dos componentes finais conhecidos e testá-los em cada camada do aplicativo: camadas de cliente, de negócios e de dados — até o armazenamento de dados. Esse modelo de trabalho fornece informações sobre requisitos adicionais pelo cliente e considerações de implementação. Muitas vezes, esse modelo de trabalho é testado em um único computador.
Tópicos relacionados