Atenção: por essa edição ser muito antiga não há arquivo PDF para download. Os artigos dessa edição estão disponíveis somente através do formato HTML.
Engenharia de Software
Análise, Projeto e Programação 00 na prática - Parte II
Continuando o assunto iniciado no artigo anterior (edição n° 50), vamos praticar mais algumas técnicas de análise, projeto e programação orientados por objetos.
Desta vez nosso objetivo será planejar e construir um sistema, pequeno o suficiente para ilustrar os conceitos e demonstrar resultados significativos. Para o domínio de negócio vamos nos basear no jogo "Banco Imobiliário" (também conhecido como "Monopólio"). O sistema fará a gestão do caixa (o dinheiro em notas) e dos bens (imóveis e empresas) de um jogador. Para construí-lo aplicaremos um conceito de Engenharia de Software conhecido como "ciclo de vida da aplicação”.
Aqueles que assistiram à minha palestra sobre MDA (Model Driven Architecture) com Bold, na BorCon 2003, certamente sentir-se-ão familiarizados com o exemplo, que é uma versão simplificada da que usei na ocasião.
Ciclo de Vida da Aplicação
Há um certo padrão (partem) que pode ser reconhecido em todos os esforços de desenvolvimento de software, com fase se atividades bem características, chamado de ciclo de vida da aplicação (Application Lifecycle). O gerenciamento adequado desse ciclo (ALM - Application Lifecycle Management) ajuda a garantir a qualidade do produto, a maturação do processo de desenvolvimento, o retorno
sobre o investimento e muitos outros benefícios.
A proposta de ALM da Borland é composta por seis processos: Definição, Modelagem, Codificação, Teste, Implantação e Gerenciamento. Para cada processo há um conjunto de ferramentas adequadas às suas atividades. Embora aparentem uma seqüência linear, normalmente esses processos ocorrem em ciclos, seguindo uma abordagem evolutiva, onde a cada "volta" um certo conjunto de funcionalidades é adicionado ao produto sendo construído.
Definição: Os Requisitos do Negócio
Nessa fase do projeto deve-se investir tempo suficiente para o esclarecimento dos requisitos funcionais (regras de negócio, por exemplo), não-funcionais (como qualidade, facilidade de uso, etc) e demais questões necessárias à boa definição do produto a ser construído.
As regras do jogo servirão como documentação inicial para nossa análise, pois elas contêm as definições dos termos, os processos e as exigências do contexto do negócio. É como se já tivéssemos feito as entrevistas com os usuários e mapeado os processos.
O jogo reflete as transações imobiliárias e de prestação de serviços (transportes, por exemplo) em uma determinada região. Os bens que o jogador pode adquirir e administrar são terrenos (com casas ou hotéis) e empresas.
Chamaremos os bens de propriedades, das quais o jogador pode ser o proprietário.
O diagrama de casos de uso, que faz parte da UML, mostra de forma gráfica o que os usuários do sistema podem fazer, ou seja, em que casos o sistema é usado (para fazer o quê?). A preocupação aqui é descrever as ações a partir do ponto de vista do usuário. O "homem palito" representa um ator, isto é, um papel que o usuário desempenha ao utilizar o sistema. Os "balões" são os casos de uso, que geralmente são descritos detalhadamente por um cenário, conforme mostrado a seguir.
Em nosso exemplo admitiremos quatro tipos básicos de transação e duas necessidades do jogador, representados no diagrama de casos de uso da Figura 1.
Um dos objetivos principais da nossa aplicação é manter o saldo do caixa do jogador sempre atualizado (para não ter que ficar contando as notinhas a todo o momento). Também precisamos registrar todas as transações feitas com as propriedades e oferecer ao jogador a possibilidade de analisar a rentabilidade de cada uma (a"Av. Paulista" está dando lucro?).
Nessa fase, além da definição dos requisitos de negócio, normalmente é feita uma descrição detalhada de cada caso de uso, que é chamada de cenário. Veja um exemplo para o caso de uso "Vender propriedade":
