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

De LCAD
Ir para: navegação, pesquisa
(Descrever as responsabilidades das classes encontradas)
 
(33 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 1: Linha 1:
 
__TOC__
 
__TOC__
 
+
[[category:Desenvolvimento]]
 
= Processo 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.
 
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.
Linha 11: Linha 11:
 
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.
 
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.
  
[[imagem:iterativo.jpg|frame|center|Figura 1:Ciclo de vida iterativo]]
+
[[imagem:iterativo.jpg|frame|center|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.
 
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 =
 
= 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:
+
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 ==
+
== 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.
 
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.
+
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 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.
+
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:'''
 
  '''Artefato:'''
 
  [[:Media:DVS_tpl.dot|Documento de Visão]]
 
  [[:Media:DVS_tpl.dot|Documento de Visão]]
 +
<BR>''Ao utilizar, acrescente a "<sigla do sistema>-" como prefixo do arquivo e remova o "_tpl"''
  
== Relação de Casos de Uso ==
+
== 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.
 
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.
 
A Relação de Casos de Uso explicita o macro funcionamento de todas interações previstas entre os atores e o sistema.
Linha 32: Linha 33:
 
  '''Artefato:'''
 
  '''Artefato:'''
 
  [[:Media:RCU_tpl.dot|Relação de Casos de Uso]]
 
  [[:Media:RCU_tpl.dot|Relação de Casos de Uso]]
 +
<BR>''Ao utilizar, acrescente a "<sigla do sistema>-" como prefixo do arquivo e remova o "_tpl"''
  
 
== Glossário ==
 
== Glossário ==
Linha 38: Linha 40:
 
  '''Artefato:'''
 
  '''Artefato:'''
 
  [[:Media:GLO_tpl.dot|Glossário]]
 
  [[:Media:GLO_tpl.dot|Glossário]]
 +
<BR>''Ao utilizar, acrescente a "<sigla do sistema>-" como prefixo do arquivo e remova o "_tpl"''
  
 
= Análise de Requisitos =
 
= 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.
 
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 ==
+
== 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.
 
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:'''
 
  '''Artefato:'''
 
  [[:Media:ECU_tpl.dot|Especificação de Caso de Uso]]
 
  [[:Media:ECU_tpl.dot|Especificação de Caso de Uso]]
 +
<BR>''Ao utilizar, acrescente a "<sigla do sistema>-" como prefixo do arquivo e''
 +
''substitua "tpl" pelo nome do Caso de Uso.''
 +
 +
== Glossário ==
  
== [[Metodologia de Desenvolvimento#Glossário|Glossário]] ==
+
Devido ao melhor detalhamento da especificação dos Casos de Uso, é necessário atualizar o [[Metodologia de Desenvolvimento#Glossário|Glossário]].
  
 
= Análise do Processo Estruturado =
 
= 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:
+
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.
== Projetar as classes a partir do detalhamento de cada Caso de Uso ==
+
 
 +
== 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 [[Metodologia de Desenvolvimento#Como Projetar as Classes de Análise a partir do detalhamento do Caso de Uso|Como Projetar as Classes de Análise a partir do detalhamento do Caso de Uso]].
 +
 
 +
'''Artefato:'''
 +
[[:Media:MCA_tpl.dot|Modelo de Classes de Análise]]
 +
<BR>''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.
 
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 ===
+
==== Substantivos que Candidatos a Classes de Análise ====
Identifique todos os substantivos, estes serão candidatos a classes.
+
Identifique todos os substantivos ou pares substantivos-adjetivos nos Fluxos do Caso de Uso, estes serão candidatos a classe.
  
=== Definir quais serão as classes ===
+
==== Classes de Análise ====
[[Imagem:questionario_classes.jpg|frame|right|374px|Figura 1: Questões para identificação de 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.
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.
+
 
 +
[[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.
Linha 67: Linha 86:
 
# '''Este candidato possui relacionamento com quaisquer outros candidatos?'''
 
# '''Este candidato possui relacionamento com quaisquer outros candidatos?'''
  
Para auxiliá-lo neste trabalho, preencha o Documento de Questionamento de Classes.
+
==== Responsabilidades das Classes Encontradas ====
 
+
Após identificar as classes, descreva a responsabilidade de cada uma delas, utilizando o Modelo de Classes de Análise.
'''Artefato:'''
 
[[:Media:DQS_tpl.dot|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.
 
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:'''
+
==== Diagrama de Classes UML (Associações entre as Classes Encontradas) ====
[[:Media:DRC_tpl.dot|Documento de Responsabilidade das Classes]]
+
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).
  
=== Estabelecer as associações entre as classes encontradas ===
+
==== Diagrama de Seqüência para cada Especificação de Caso de Uso ====
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).
+
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.
  
=== Fazer o diagrama de seqüência para cada Especificação de Caso de Uso ===
+
==== Atributos e Operações das Classes ====
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.
+
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.
  
=== Descrever os Atributos e Operações das Classes ===
+
= Implementação e Testes =
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.
+
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 =
 
= Referências =
 
# [http://www.ibm.com/developerworks/rational/library/5383.html Getting from use cases to code]
 
# [http://www.ibm.com/developerworks/rational/library/5383.html Getting from use cases to code]

Edição atual tal como às 17h21min de 14 de setembro de 2012

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