O Fluxo de Análise e Projeto
© Alexandre Vasconcelos
[email protected]
[email protected]
Centro de Informática da UFPE/
Qualiti Software Processes
1/29
Objetivos desta parte


Apresentar conceitos utilizados no fluxo de
análise e projeto
Dar uma visão geral das atividades,
responsáveis e artefatos deste fluxo
2/29
O Fluxo de Análise e Projeto
Os objetivos do fluxo:
• Transformar os requisitos em um projeto (inicialmente
abstrato) do sistema
• Desenvolver uma arquitetura robusta
• Adaptar o projeto levando em consideração os requisitos
da futura implementação
Fonte: Rational 3/29
Visão geral dos artefatos
Modelo de análise
e projeto
Modelo de caso
de uso
Glossário
Documento
requisitos
Análise e
projeto
Documento da
arquitetura
Modelo de dados
Mapeamento das
classes de análise
em elementos de
projeto
4/29
Sobre os artefatos





A construção do modelo de análise e projeto é o
principal objetivo deste fluxo de atividades
O modelo de análise e projeto contém as realizações
de casos de uso
O mapeamento das classes de análise em classes de
projeto é um artefato temporário do desenvolvimento
O documento da arquitetura é opcional e é usado para
descrever em detalhes uma determinada arquitetura
A elaboração do modelo de dados está fora do escopo
do curso, mas pode conter, por exemplo, o
mapeamento do modelo OO para o relacional
5/29
Realização de Caso de Uso


Descreve como o caso de uso é realizado,
associando o caso de uso com classes e outros
elementos de projeto
Em UML, uma realização de caso de uso pode ser
representada através de um conjunto de diagramas:
diagrama de classe
 diagramas de interação


diagrama de seqüência

diagrama de colaboração
6/29
Artefato Modelo de Análise e
Projeto
Diagramas de Sequência
Diagramas de Colaboração
Modelo de análise e projeto
Diagramas de Classe
7/29
Modelo de Análise e Projeto

Pode ser um só artefato
 evoluindo
de uma visão abstrata (nas atividades
de análise), para uma visão detalhada (nas
atividades de projeto)

Podem ser feitos dois artefatos
 um
modelo de análise
 um modelo de projeto (inicia igual à última
versão do modelo de análise e evolui
independentemente)
8/29
Análise X Projeto

Análise
Foco no problema
 Comportamento (caixa
preta, sem detalhes de
implementação)
 Estrutura do sistema
 Requisitos funcionais
 Modelo simples


Projeto
Foco em uma solução
 Operações e atributos
 Representação próxima
do código
 Requisitos não
funcionais (exemplo:
desempenho), além dos
funcionais
 Modelo complexo

Fonte: IBM Rational
9/29
O Fluxo de Atividades
Projetar
Arquitetura
Arquiteto de
Software
Analista de
Sistemas
Projetista de
Banco de Dados
Revisor de
projeto
Analisar
Casos de Uso
Projetar
Casos de Uso
Projetar
Subsistemas
Projetar
classes
Revisar
Projeto
Projetar
Base de Dados
10/29
Atividade: Analisar Caso de Uso
Projetar
Arquitetura
Arquiteto de
Software
Analista de
Sistemas
Projetista de
Banco de Dados
Revisor de
projeto
Analisar
Casos de Uso
Projetar
Casos de Uso
Projetar
Subsistemas
Projetar
classes
Revisar
Projeto
Projetar
Base de Dados
11/29
Objetivos desta atividade


Encontrar classes de análise (fronteira, controle
e entidade) e distribuir comportamento dos
casos de uso entre estas (utilizando diagramas
de seqüência e/ou colaboração)
Para cada classe, descrever suas
responsabilidades, atributos e associações
Esta atividade é realizada para cada caso de uso!
12/29
Visão geral dos artefatos
Glossário
Documento de
requisitos
Modelo de caso de uso
Documento da
arquitetura
Analisar
caso de uso
Classes de análise
Realização de caso de uso
Modelo de análise e projeto
13/29
Fonte: Rational
Atividade: Projetar Arquitetura
Projetar
Arquitetura
Arquiteto de
Software
Analista de
Sistemas
Projetista de
Banco de Dados
Revisor de
projeto
Analisar
Casos de Uso
Projetar
Casos de Uso
Projetar
Subsistemas
Projetar
classes
Revisar
Projeto
Projetar
Base de Dados
14/29
Objetivos desta atividade



Avaliar o conjunto das classes de análise
Definir elementos de projeto (classes de projeto
e subsistemas) e organizá-los em pacotes
Definir a estrutura da aplicação
No final do projeto da arquitetura tudo deve estar
pronto para que os projetistas possam detalhar as
realizações dos casos de uso de maneira uniforme!
15/29
Visão geral dos artefatos
Mapeamento das
classes de análise em
elementos de projeto
Modelo de casos
de uso
Documento
de requisitos
Modelo de análise e projeto
(classes de análise)
Projetar
Arquitetura
Documento da
arquitetura
Modelo de análise e projeto
(classes de projeto e
subsistemas) 16/29
Atividade: Projetar Caso de Uso
Projetar
Arquitetura
Arquiteto de
Software
Analista de
Sistemas
Projetista de
Banco de Dados
Revisor de
projeto
Analisar
Casos de Uso
Projetar
Casos de Uso
Projetar
Subsistemas
Projetar
classes
Revisar
Projeto
Projetar
Base de Dados
17/29
Objetivos desta atividade

Refinar as realizações de casos de uso
(elaboradas na análise de casos de uso)
incluindo os elementos de projeto
 Incorporando

persistência nas realizações
O objetivo final é ter um modelo consistente
que sirva de referência para a implementação
do caso de uso
18/29
Visão geral dos artefatos
Documento de
requisitos
Realização de
caso de uso
Subsistemas de projeto
Projetar
Caso de Uso
Realização de
caso de uso
Classes de projeto
Caso de uso
19/29
Fonte: Rational
Atividade: Projetar Subsistema
Projetar
Arquitetura
Arquiteto de
Software
Analista de
Sistemas
Projetista de
Banco de Dados
Revisor de
projeto
Analisar
Casos de Uso
Projetar
Casos de Uso
Projetar
Subsistemas
Projetar
classes
Revisar
Projeto
Projetar
Base de Dados
20/29
Objetivos desta atividade

Identificar elementos internos ao subsistema (classes e
outros subsistemas) que realizem a interface do
subsistema



O comportamento da interface deve ser distribuído entre
estes elementos, de forma análoga à análise e ao projeto
de casos de uso
Este processo pode gerar novas dependências do
subsistema com elementos externos
A atividade é realizada uma vez para cada subsistema,
podendo ser recursiva (gerando outros subsistemas)
21/29
Visão geral dos artefatos
Subsistemas e e interfaces de projeto
Subsistemas e interfaces de projeto
(atualizado)
Projeto de
Subsistema
Realização de caso de uso
Realização de caso de uso
(atualizado)
Classes de projeto
Fonte: Rational
22/29
Atividade: Projetar Classes
Projetar
Arquitetura
Arquiteto de
Software
Analista de
Sistemas
Projetista de
Banco de Dados
Revisor de
projeto
Analisar
Casos de Uso
Projetar
Casos de Uso
Projetar
Subsistemas
Projetar
classes
Revisar
Projeto
Projetar
Base de Dados
23/29
Objetivos desta atividade



Detalhar a estrutura interna (atributos e
operações) das classes de projeto
Identificar classes e relacionamentos adicionais
Garantir que as classes fornecem o
comportamento necessário à realização dos
casos de uso
Realizada para cada classe da iteração corrente
24/29
Na prática...

Os passos desta atividade são realizados
simultaneamente às atividades de projeto:
 projeto
da arquitetura;
 projeto de casos de uso e
 projeto de subsistemas

Aqui o objetivo é rever o que foi feito, refinando
e acrescentando detalhes
25/29
Visão geral dos artefatos
Requisitos não
funcionais
Classes de projeto
Realização de casos de uso
Projetar
classes
Classes de projeto
Modelo de
análise e projeto
26/29
Projeto em Equipe

A partir do esboço do documento de requisitos
Parte 1: Faça a análise (produzindo diagramas de
interação e um VOPC com estereótipos,
responsabilidades e associações para 3 casos de uso
slecionados; identifique classes persistentes)
 Parte 2: Faça o projeto da arquitetura identificando
subsistemas, interfaces, pacotes e camadas. Produza
um diagrama de pacotes, relacione classes de análise
com elementos de projeto, e agrupe elementos de
projeto em camadas.

27/29
Projeto em Equipe
 Parte
3: Faça o projeto de um caso de uso,
refazendo os diagramas de interação e o VOPC
já incluindo elementos de projeto (deve ilustrar
inclusão de persistência e interfaces de
subsistemas)
 Parte 4: Faça o projeto de um subsistema e de
uma classe
28/29
O Fluxo de Análise e Projeto
© Alexandre Vasconcelos
[email protected]
[email protected]
Centro de Informática da UFPE/
Qualiti Software Processes
29/29