Metodologia de Desenvolvimento

Processo de Desenvolvimento

O Processo de desenvolvimento de sistema aqui adotado é uma abordagem visando a produção rápida com a utilização de um conjunto mínimo de ferramentas necessárias sob o nosso ponto de vista. Dessa forma, o processo é constituído basicamente das seguintes etapas:

• Modelagem do Negócio (Entendimento e mapeamento do Negócio)
• Análise de Requisitos (Detalhamento das Necessidades)
• Análise do Processo Estruturado (Projeto do Sistema)
• Implementação e Testes

Algumas disciplinas da engenharia de software (como gerenciamento de riscos, entre outras) não serão aqui abordadas de forma explicita nesta primeira versão. O que não significa que não devem ser utilizadas ao se seguir este processo. Este processo possui ciclo de vida baseado no ciclo de vida iterativo, e é dividido em fases. O objetivo é que a cada iteração seja gerada uma versão executável do sistema em desenvolvimento como na Figura 1.

Figura 1: Ciclo de vida iterativo

Dessa forma, o projeto se inicia na Modelagem do Negócio, passando pela Análise de Requisitos, seguindo para a Análise do Processo Estruturado e terminando um ciclo com a Implementação e Testes. Devem ser realizadas tantas iterações quantas forem necessárias para se construir o sistema, entregando um produto pronto para ser executado a cada iteração.

Modelagem do Negócio

Esta etapa do processo visa o entendimento do negócio, através da documentação de como ele funciona, o que realiza e quem são os envolvidos. Para isto, é preciso trabalhar para redigir os documentos a seguir da maneira mais precisa possível, com a participação de todos os envolvidos no projeto.

Documento de Visão do Problema (Negócio)

O propósito deste documento é coletar, analisar e definir as necessidades de alto-nível e características do sistema, focando nas potencialidades requeridas pelos afetados e usuários-alvo. A Visão do Problema documenta o ambiente geral de processos desenvolvidos para o sistema, fornecendo a todos os envolvidos uma descrição compreensível deste e suas macro-funcionalidades. Reuna os envolvidos no projeto para construir o Documento de Visão. Este documento deve ser feito com a participação de todos, que deverão concordar com o seu conteúdo. Não se deve partir para a próxima etapa sem que o documento de visão tenha sido terminado e consensado entre todos.

Artefato:
Documento de Visão

Ao utilizar, acrescente a "<sigla do sistema>-" como prefixo do arquivo e remova o "_tpl"

Relação de Casos de Uso do Sistema Associados ao Problema (Negócio)

O propósito deste documento é explicitar e definir em alto-nível como os envolvidos interagem com o sistema. A Relação de Casos de Uso explicita o macro funcionamento de todas interações previstas entre os atores e o sistema.

Artefato:
Relação de Casos de Uso

Ao utilizar, acrescente a "<sigla do sistema>-" como prefixo do arquivo e remova o "_tpl"

Glossário

O propósito deste documento é manter uma relação dos termos empregados durante o projeto como referência comun para todos os envolvidos.

Artefato:
Glossário

Ao utilizar, acrescente a "<sigla do sistema>-" como prefixo do arquivo e remova o "_tpl"

Análise de Requisitos

Esta etapa do processo visa o detalhamento das necessidades identificadas. Aqui deve-se realizar a especifiação de cada Caso de Uso identificado na Modelagem do Negócio, o que é comumente chamado de "Realização de um Caso de Uso". Além disso, após a especificação dos casos de uso, é necessária a atualização do glossário.

Especificação dos Casos de Uso do Sistema Associados ao Problema (Negócio)

O propósito deste documento é descrever um Caso de Uso sem entrar em detalhes de implementação do sistema. A especificação do caso de uso tem de ser tal que descreva as interações do(s) ator(es) com o sistema, especificando como o caso de uso começa e termina.

Artefato:
Especificação de Caso de Uso

Ao utilizar, acrescente a "<sigla do sistema>-" como prefixo do arquivo e
substitua "tpl" pelo nome do Caso de Uso.

Glossário

Devido ao melhor detalhamento da especificação dos Casos de Uso, é necessário atualizar o Glossário.

Análise do Processo Estruturado

Esta etapa do processo visa definir a estrutura lógica e distribuir as funcionalidades expressas nos requisitos entre os diversos elementos lógicos que irão compor o sistema. O guia aqui empregado para acompanhamento da análise é o preenchimento do Modelo de Classes de Análise. Os passos para seu preenchimento encontram-se logo após a sua descrição.

Modelo de Classes de Análise

O propósito deste documento é descrever as classes necessárias ao atendimento do caso de uso, do ponto de vista do usuário. Para cada Caso de Uso, faça um Modelo de Classes de Análise, mantendo a coerência entre os Modelos de Classes de Análise já prontos. Divergências e/ou conflitos entre classes de análise de casos de uso diferentes têm de ser resolvidos.

Recomenda-se preencher o Modelo de Classes de Análise seguindo os passos sobre Como Projetar as Classes de Análise a partir do detalhamento do Caso de Uso.

Artefato:
Modelo de Classes de Análise

Ao utilizar, acrescente a "<sigla do sistema>-" como prefixo do arquivo e
substitua "tpl" pelo nome do Caso de Uso.

Como Projetar as Classes de Análise a partir do detalhamento do Caso de Uso

A técnica empregada aqui é a chamada "dissecação gramatical". Nesta técnica, deve-se separar todos os substantivos ou pares substantivos-adjetivos. Siga os passos a seguir para empregar a técnica.

Substantivos que Candidatos a Classes de Análise

Identifique todos os substantivos ou pares substantivos-adjetivos nos Fluxos do Caso de Uso, estes serão candidatos a classe.

Classes de Análise

Realize o questionário mostrado na Figura 2 para auxiliá-lo na decisão de quais substantivos devem ser classes. Se a resposta é "não", isto significa que muito provavelmente o candidato em questão não é uma classe. Prossiga para o próximo candidato. Se a resposta é "sim", continue realizando as questões. Se todas as respostas forem sim, considere o candidato como uma classe.

Figura 2: Questões para identificação de classes

1. Este candidato está dentro do sistema? Caso não esteja, ele provavelmente é um ator.
2. Este candidato possui comportamento identificável para o domínio do problema? Por exemplo, é possível dizer os serviços/funções que este candidato possui e oferece?
3. Este candidato possui estrutura identificável? Por exemplo, é possível dizer que dados ele possui e manipula?
4. Este candidato possui relacionamento com quaisquer outros candidatos?

Responsabilidades das Classes Encontradas

Após identificar as classes, descreva a responsabilidade de cada uma delas, utilizando o Modelo de Classes de Análise. A responsabilidade de uma classe descreve os serviços que esta classe provê no sistema e, nenhuma outra classe provê. Responsabilidades em classes diferentes não devem se sobrepor.

Diagrama de Classes UML (Associações entre as Classes Encontradas)

Tendo descrito as responsabilidades de cada classe, o próximo passo é estabelecer as associações entre elas. Recomenda-se utilizar a ferramenta Jude (ou outra ferramenta UML) para construir um Diagrama de Classes UML. Identifique a semântica de cada relacionamento no diagrama (associação, agregação, composição ou herança).

Diagrama de Seqüência para cada Especificação de Caso de Uso

A distribuição do comportamento entre as classes é feita através do diagrama de seqüência. Construa um diagrama de seqüência para cada especificação de caso de uso afim de demonstrar como cada classe interage para realizar o trabalho necessário de cada um deles. Durante a construção do diagrama, pode haver a necessidade de se adicionar classes pertinentes ao sistema, dado que nesta etapa o detalhamento é maior do que anteriormente.

Atributos e Operações das Classes

Por fim, descreva os atributos e operações das classes pensando já na implementação. Nesta etapa, deve-se buscar um detalhamento pensando na modularização do código e suas funcionalidades. Atualize o Diagrama de Classes com os atributos e operações.

Implementação e Testes

Esta etapa do processo visa a construção/alteração do sistema de acordo com o projeto. Espera-se que ao chegar nesta fase seja possível construir o sistema a partir das classes projetadas.

Referências

1. Getting from use cases to code