Artigo Clube Delphi Edição 51 - Engenharia de Software

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da Revista Clube Delphi Edição 51.

Esse artigo faz parte da revista Clube Delphi edição 51. Clique aqui para ler todos os artigos desta edição



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":

 

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?