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."
[...] continue lendo...