Mudanças entre as edições de "Metodologia de Desenvolvimento"

De LCAD
Ir para: navegação, pesquisa
(Definir quais serão as classes)
(Definir quais serão as classes)
Linha 59: Linha 59:
  
 
=== Definir quais serão as classes ===
 
=== Definir quais serão as classes ===
Realize o questionário mostrado na Figura 1 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.
+
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.
  
[[Imagem:questionario_classes.jpg|frame|center|Figura 1: Questões para identificação de classes]]
+
[[Imagem:questionario_classes.jpg|frame|center|Figura 2: Questões para identificação de classes]]
  
 
# '''Este candidato está dentro do sistema?''' Caso não esteja, ele provavelmente é um ator.
 
# '''Este candidato está dentro do sistema?''' Caso não esteja, ele provavelmente é um ator.

Edição das 14h42min de 7 de maio de 2008

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 Sistema

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 Sistema 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 a 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

Relação de Casos de Uso

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

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

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

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

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. Para isto, é utilizada uma abordagem que compreende as etapas a seguir:

Projetar as classes a partir do detalhamento de cada 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.

Separar os Substantivos

Identifique todos os substantivos, estes serão candidatos a classes.

Definir quais serão as classes

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?

Para auxiliá-lo neste trabalho, preencha o Documento de Questionamento de Classes.

Artefato:
Documento de Questionamento de Classes

Descrever as responsabilidades das classes encontradas

Após identificar as classes, descreva a responsabilidade de cada uma delas, utilizando o Documento de Responsabilidade das Classes. 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.

Artefato:
Documento de Responsabilidade das Classes

Estabelecer as 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).

Fazer o 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 dos casos de uso para 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.

Descrever os 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.

Referências

  1. Getting from use cases to code