Construa uma Aplicação 100% OO - Parte 3 - .Net Magazine 63

Esse artigo faz parte da revista .NET Magazine edição 63. Clique aqui para ler todos os artigos desta edição

Construa uma Aplicação 100% OO – Parte 3

Introdução

“Programar é divertido, mas desenvolver sistemas com qualidade é difícil”. A frase que coroou as duas primeiras partes desse artigo volta a figurar nessa terceira parte, por sintetizar o mote de discussão do trabalho que vem sendo conduzido. Basicamente, queremos apresentar os motivos do porque devemos consumir tempo de projeto com a documentação e o planejamento, ao invés de partirmos direto para a programação do sistema.

Esse artigo objetiva fornecer ao leitor a visualização ampla de um processo profissional de desenvolvimento de sistemas através do uso de modernas técnicas de análise orientada a objetos e de gerenciamento de projetos. A proposta desta série de artigos é apresentar desde o mapeamento do processo de negócios, passando pela engenharia de requisitos, análise, projeto, implementação e chegando até a implantação do sistema desenvolvido. Faremos o uso consistente da UML e veremos a evolução do processo de análise e os resultados alcançados na construção da aplicação.

Na primeira parte do artigo contextualizamos os conhecimentos a respeito das técnicas de gerência de projetos e da metodologia de desenvolvimento de sistemas que utilizamos como norteadores desse trabalho. Inicializamos o processo de desenvolvimento com a especificação do escopo do projeto e com o planejamento do plano de iterações, através da estrutura analítica do projeto, que nos permitiu chegar ao cronograma.

Na segunda parte do artigo continuamos trilhando nosso caminho pelo processo de desenvolvimento através da modelagem do processo de negócios a ser suportado pelo novo sistema. Elencamos os requisitos funcionais e não-funcionais e especificamos as regras de negócio que restringirão os aspectos de negócio no âmbito do aplicativo. Confeccionamos também o diagrama de casos de uso e o protótipo do sistema, que nos permitiu ampliar a visão da solução modelada.

Nessa terceira parte do artigo faremos a especificação de um caso de uso. Utilizaremos duas técnicas comumente aplicadas: a especificação textual e o diagrama de atividades, com a respectiva análise comparativa das duas abordagens. Confeccionaremos também o artefato de mensagens e a primeira versão do diagrama de classes (elementos pertinentes ao domínio do negócio). Com isso, estaremos prontos para o projeto e a construção da aplicação, que serão abordados na quarta parte do artigo.

A Especificação de Casos de Uso

O diagrama de casos de uso do Sistema de Controle de Recursos Materiais (SCRM), confeccionado na segunda parte desse artigo, possibilitou a identificação dos cenários de uso entre os usuários e o sistema em desenvolvimento. Cada caso de uso do diagrama representa uma unidade de trabalho de importância significativa. Devemos observar que os casos de uso têm o objetivo de descrever como o sistema deverá se comportar e não como deverá ser construído, mantendo-nos, portanto, abstraídos das restrições tecnológicas existentes.

A especificação de processamentos em lote (processos batch) em formato de casos de uso é uma questão relativamente polêmica. Algumas literaturas preconizam que os processos em lote, por não terem interação com o usuário final (cliente), não são casos de uso. Outros autores defendem ainda que o ator desse tipo de caso de uso seria o Operador de Computador ou o componente de agendamento de tarefas do sistema operacional em que o processo será executado e que o processamento produz algo significativo para o usuário final devendo, portanto, ser representado como um caso de uso normal. No entanto, os estudos são unânimes quanto aos processos operacionais, como, por exemplo, a manutenção da base de dados, a indexação de documentos ou a cópia de segurança (backup), não serem significativos para o processo de negócio, não devendo, portanto, serem representados como casos de uso.

Cada caso de uso do diagrama especifica um contexto de aplicação do sistema. A especificação de um caso de uso pode ser textual ou gráfica, através do Diagrama de Atividades. A prática nos mostra que a descrição de um processamento complexo, com muitas operações condicionais e regras de negócio, será melhor representada por um Diagrama de Atividades.

Na descrição textual devemos evitar o uso de termos técnicos e expressões com significado dúbio ou de difícil compreensão pelos leitores. O caso de uso deve ser claro o suficiente para ser plenamente compreendido por todos os envolvidos no processo de desenvolvimento, em especial, o usuário do sistema. A especificação de caso de uso é um artefato de negócio e, como tal, deve ser plenamente compreendido pelo cliente gestor e ser validado e assinado pelo mesmo, garantindo-se a conformidade com os requisitos levantados.

O Quadro 1 apresenta a especificação do caso de uso Manter Cadastro de Grupo de Recursos do Sistema de Controle de Recursos Materiais. Esse caso de uso faz parte da 3ª iteração do projeto, que, doravante, será utilizada como nossa base de estudos.