Análise e Projeto no RUP
Contexto
 Após a etapa de análise de requisitos,
temos documentos de requisitos e os
casos de uso em mãos.
 Queremos agora gerar um primeiro
modelo do sistema a partir dos casos
de uso.
 Este modelo é chamado de modelo de
análise.
2009
15/03/2005
MDS - Bacalá
2/28
2
Contexto
Requisitos
2009
15/03/2005
Análise
MDS - Bacalá
Projeto
3/28
3
Atividade de Análise
 Vai proporcionar um método que
permita que criemos um modelo de
classes do sistema a partir dos casos
de uso
 Trará a resposta para a pergunta:
 Quais classes preciso para implementar
estes casos de uso?
2009
15/03/2005
MDS - Bacalá
4/28
4
Análise & RUP
 A maneira como vamos realizar a
etapa de análise se baseia no
processo do RUP (Rational Unified
Process)
 A análise será orientada a casos de
uso, ou seja, os casos de uso servirão
de guia para a etapa de análise
2009
15/03/2005
MDS - Bacalá
5/28
5
Casos de Uso X Análise
casos de uso
análise
Descritos na linguagem
do cliente
Visão externa do
sistema
Captura as
funcionalidades do
sistema
Estruturado por casos
de uso
2009
15/03/2005
Descrito na linguagem
dos desenvolvedores
Visão interna do sistema
Mostra, de modo
abstrato, como a
funcionalidade pode ser
realizada
Estruturado por classes
e pacotes
MDS - Bacalá
6/28
6
Análise & Projeto
Os objetivos do fluxo:
Transformar os requisitos em um projeto do
sistema do que o sistema será
Derivar uma arquitetura robusta do sistema
Adaptar o projeto
2009
MDS - Bacalá
7
Análise versus Projeto
 Foco no entendimento
do problema
 Projeto idealizado
 Comportamento
 Estrutura do sistema
 Requisitos funcionais
 Modelos simples
2009
 Foco no entendimento
da solução
 Operações e atributos
 Performance
 Pensamento no código
 Ciclo de vida de
objetos
 Requisitos nãofuncionais
 Modelo complexo
MDS - Bacalá
8
Visão geral dos artefatos
Modelo de análise
e projeto
Modelo de caso
de uso
Análise e
projeto
Documento da
arquitetura
Modelo de dados
Glossário
2009
Documento
requisitos
MDS - Bacalá
9
Modelo de Analise e Projeto
 A construção do modelo de análise e
projeto é o principal objetivo desta
disciplina
 O modelo de análise e projeto contém
as realizações de casos de uso
 Pode ser particionado em dois
modelos
 Modelo de Analise
 Modelo de Projeto
2009
MDS - Bacalá
10
Realização de Caso de Uso
Caso de Uso
Descreve como o caso
de uso é realizado,
associando o caso de
uso com classes e
outros elementos de
projeto
Realização de Caso
de Uso
Diagramas de Sequência
Diagramas de Colaboração
 Analise e projeto 
 Requisitos 
2009
Diagramas de Classe
MDS - Bacalá
11
Fluxo de Análise e Projeto
Diagrama de
Atividades
2009
MDS - Bacalá
12
Realizar síntese da arquitetura
2009
MDS - Bacalá
13
Objetivo
 Construir e avaliar uma prova de
conceito arquitetural
 Mostrar que existe uma solução possível
de satisfazer os requisitos do sistema
relevantes à arquitetura
2009
MDS - Bacalá
14
Definir a arquitetura candidata
2009
MDS - Bacalá
15
Objetivo
 Criar o esqueleto inicial da
arquitetura do sistema
 Identificar classes de análise dos
casos de uso arquiteturalmente
relevantes
 Atualizar a realização de caso de uso
com as interações entre classes de
análise
2009
MDS - Bacalá
16
Analisar comportamento
2009
MDS - Bacalá
17
Objetivo
 Transformar as descrições sobre o
comportamento providas pelos caso
de uso em um conjunto de elementos
nos quais o modelo de projeto vai se
basear
2009
MDS - Bacalá
18
Projetar componentes
2009
MDS - Bacalá
19
Objetivo
 Refinar as definições dos elementos
acrescentado detalhes sobre como
estes elementos implementam o
comportamento requerido
 Refinar e atualizar as realizações de
casos de uso com os novos elementos
identificados
2009
MDS - Bacalá
20
Projetar Banco de Dados
2009
MDS - Bacalá
21
Objetivo
 Identificar classes persistentes no
modelo de projeto
 Projetar as estruturas de banco de
dados (Modelo de dados)
 Definir mecanismos e estratégias
para armazenar e recuperar dados
2009
MDS - Bacalá
22
Refinar Arquitetura
2009
MDS - Bacalá
23
Objetivo
 Permitir uma transição entre os
elementos e mecanismos de análise
para os de projeto
 Manter a consistência e integração da
arquitetura
 Descrever a arquitetura de execução
e produção da aplicação
2009
MDS - Bacalá
24
Fluxo de Análise e Projeto
Simplificado
Simplificando/Instanciando o
processo para um contexto
específico
Motivação
 O RUP é um Framework
 Genérico e complexo demais, pois visa
atender todos os tipos de projetos de
desenvolvimento de software
 Toda disciplina do RUP deve ser
analisada e customizada de acordo
com as necessidades específicas do
projeto antes de sua implantação
2009
MDS - Bacalá
26
Passos da Atividade de Análise
 Identificar as classes
 Identificar persistência
 Identificar responsabilidades das
classes
 Identificar relacionamentos
 Identificar atributos
2009
15/03/2005
MDS - Bacalá
27/28
27
Fluxo de atividades simplificado
1. Analisar Arquitetura
2. Analisar Caso de Uso
3. Projetar Classes
4. Projetar Banco de Dados
2009
MDS - Bacalá
28
Analisar Arquitetura
Analisar Arquitetura
 Esforço inicial em definir as partes do
sistema e seus relacionamentos
(Arquitetura Inicial)
 Definir as convenções de
modelagem
 Identificar os mecanismos de
análise
 Identificação das abstrações-chave
2009
MDS - Bacalá
30
Arquitetura Inicial
 Quais as principais partes do sistema?
 Como elas interagem entre si?
 Que padrões arquiteturais utilizar (no
todo ou internamente nas partes) ?




2009
MVC
Baseado em camadas
Canais e filtros
Centrado em repositório
MDS - Bacalá
31
Exemplo de arquitetura inicial
Módulo de Vendas
Módulo de
Estoque
Interface Gráfica
Negócio
Socket
Dados
2009
MDS - Bacalá
32
Convenções de modelagem
 O que são?
 Que diagramas e elementos de modelagem
utilizar
 Definir as regras para utilização desses
componentes
 Convenções de nome
 Exemplos
2009
 Casos de uso devem ser nomeados como ações
(Cadastrar usuário)
 Cada realização de caso de uso deve conter:
 Um diagrama de classes
 No mínimo um diagrama de seqüência
representando o fluxo principal de ações
MDS - Bacalá
33
Mecanismos de análise
 O que são?
 Focam nos requisitos não-funcionais do sistema
 Decisão estratégica sobre padrões, politicas e
práticas a serem utilizadas no projeto
 Exemplos




2009
Persistência
Comunicação
Gerenciamento de transações
Segurança
MDS - Bacalá
34
Identificar Abstrações-chave
 Definir classes de análise preliminares
 Conhecimento do domínio
 Requisitos
 Outros artefatos (Glossário e modelo de
negócio)
2009
MDS - Bacalá
35
Analisar Caso de Uso
Objetivos
 Identificar as classes que executam o
fluxo de eventos do caso de uso
 Distribuir o comportamento do caso
de uso nestas classes
 Identificar atributos,
responsabilidades e associações das
classes
2009
MDS - Bacalá
37
Passos para Analisar Caso de
Uso
 Para cada caso de uso:
1. Encontrar classes de análise
2. Distribuir comportamento entre as
classes
 Para cada classe:
3. Descrever responsabilidades
4. Descrever atributos e associações
5. Qualificar mecanismos de análise
2009
MDS - Bacalá
38
Passo 1: Encontrar classes de
análise
 O comportamento do caso de uso é
distribuído em classes de análise
2009
MDS - Bacalá
39
O que são classes de análise?
 Representam o conceito mais abstrato dos
elementos do sistema
 Primeiro passo concreto até chegar em um sistema
executável
 Categorização temporária
 São convertidas para classes de projeto
 Servem para diminuir o gap entre os requisitos e
projeto
 Podem ser dos seguintes tipos
 Fronteira (<<boundary>>)
 Controle (<<control>>)
 Entidade (<<entity>>)
2009
MDS - Bacalá
40
Classes de Fronteira
 Utilizada para modelar a interação
entre um ator e o sistema
 Para cada interação entre um ator e
caso de uso, é criada uma classe de
fronteira
 Possuem o estereótipo
<<boundary>>
2009
15/03/2005
MDS - Bacalá
41/28
41
Classes de Fronteira
 Itermediam a interface para qualquer
coisa externa ao sistema
 Exemplos de classes fronteira <<boundary>>
 GUI
 Interface com outros sistemas
 Interface com dispositivos
 Uma classe de Fronteira por interação
ator X caso de uso
Notação em UML
2009
MDS - Bacalá
42
O Papel de uma Classe de
Fronteira
<<boundary>>
<<control>>
<<boundary>>
Usuário
<<boundary>>
<<entity>>
2009
<<entity>>
Modela interação entre o sistema e seu ambiente
MDS - Bacalá
43
Exemplo de classes de fronteira
Estudante
Matricular-se
Em disciplina
<<boundary>>
FormRegistroCursos
2009
Sistema
Academico
<<boundary>>
SistemaAcademico
MDS - Bacalá
44
Classes de Entidade
 Utilizadas para modelar a informação
manipulada pelo sistema
 Podem ser persistentes ou não
 Conceito análogo às entidades dos
diagramas ER
 São identificadas a partir do fluxo de
eventos do caso de uso
 Possuem o estereótipo <<entity>>
2009
15/03/2005
MDS - Bacalá
45/28
45
Classes de Entidade
 Abstrações chave dos casos de uso
<<entity>>
Glossário
<<entity>>
<<entity>>
Descrição do
Caso de uso
2009
MDS - Bacalá
46
O Papel de uma Classe de
Entidade
<<boundary>>
<<control>>
<<boundary>>
Usuário
<<boundary>>
<<entity>>
2009
<<entity>>
Armazenam e gerenciam informação no sistema
MDS - Bacalá
47
Exemplo de classes de entidade
<<entity>>
Estudante
<<entity>>
Curso
<<entity>>
Horario
2009
MDS - Bacalá
48
Classes de Controle
 Classes responsáveis por controlar o
fluxo de execução do caso de uso
 Normalmente é criada uma classe de
controle para cada caso de uso
 Possuem o estereótipo <<control>>
2009
15/03/2005
MDS - Bacalá
49/28
49
Classes de Controle
 Coordenam o comportamento (lógica
de controle) do caso de uso
 Interface entre fronteira e entidade
<<control>>
2009
MDS - Bacalá
50
O Papel de uma Classe de
Controle
<<boundary>>
<<control>>
<<boundary>>
Usuário
<<boundary>>
<<entity>>
<<entity>>
Coordenam o comportamento do caso de uso
2009
MDS - Bacalá
51
Exemplo de Classe de Controle
Estudante
Matricular-se
Em disciplina
Sistema
Academico
<<control>>
ControladorMatricula
matricurlarAluno()
2009
MDS - Bacalá
52
Exemplo
efetuar login
Usuario
registrar súmulas
das aulas
adicionar turma
remover turma
Professor
Secretária
registrar faltas
Aluno
editar turma
consultar freqüência
editar alunos
remover alunos
adicionar alunos
2009
15/03/2005
MDS - Bacalá
Servidor de e-mail
53/28
53
Exemplo
 Efetuar Login
 Fluxo de eventos:
1. Usuário informa login e senha
2. Sistema checa se o login e senha
conferem
3. Sistema registra a sessão do aluno e
a tela principal do sistema é exibida
2009
15/03/2005
MDS - Bacalá
54/28
54
Exemplo
 Que classes preciso criar?
 uma classe de fronteira para lidar com a
interação dos atores com o sistema
 uma classe de entidade para representar
as informações relevantes do aluno
 uma classe de controle para gerenciar o
fluxo de execução do caso de uso
2009
15/03/2005
MDS - Bacalá
55/28
55
Exemplo
TelaLogin
ControladorLogin
Usuario
Há diferentes opções de visualização dos estereótipos. A opção
padrão é mostrada acima - os estereótipos são visualizados através
da mudança dos ícones das classes. Há também a opção de se
visualizar os estereótipos do modo convencional (<<estereótipo>>).
<<boundary>>
TelaLogin
2009
15/03/2005
<<control>>
ControladorLogin
MDS - Bacalá
<<entity>>
Usuario
56/28
56
Persistência
 Mas caso alguma classe de entidade
precise ser persistente?
 Que classe será responsável por
realizar as tarefas de persistência?
 Para cada classe de entidade que
precise ser persistente, é criada uma
nova classe com o estereótipo
<<entity collection>>
2009
15/03/2005
MDS - Bacalá
57/28
57
Exemplo
<<control>>
ControladorLogin
<<boundary>>
TelaLogin
<<entity collection>>
CadastroUsuarios
2009
15/03/2005
MDS - Bacalá
<<entity>>
Usuario
58/28
58
Passo 2: Distribuir
comportamento
 Para cada fluxo de eventos
 Identificar classes de análise
participantes
 Alocar responsabilidades do caso de uso
às classes de análise
 Modelar interações entre as classes
através dos diagramas de interação
2009
MDS - Bacalá
59
Distribuindo comportamento
entre as classes
Classes de análise
Diagrama de seqüência
Classes de análise com
responsabilidades
Caso de uso
2009
Diagrama de colaboração
MDS - Bacalá
60
Alocando responsabilidades
 Use estereótipos de análise como guia
 Classes de fronteira
 Comportamento que envolve comunicação com
um ator
 Classes de entidade
 Comportamento que envolve informação
encapsulada na abstração
 Classes de controle
 Comportamento específico ao (lógica de
controle do) caso de uso
2009
MDS - Bacalá
61
Guia: Alocando
responsabilidades
 Quem tem a informação necessária
para realizar a responsabilidade
 isso pode envolver apenas uma classe,
mas pode ser preciso criar novas classes
ou relacionamentos entre classes
2009
MDS - Bacalá
62
Modelando interações
 Diagramas de interação (colaboração e
seqüência) modelam interações do sistema
com seus atores
 A interação é iniciada por um ator e
envolve instâncias (objetos) das classes
 Diagramas de interação capturam a
semântica do fluxo de eventos do caso de
uso
 Auxiliam a identificar classes, responsabilidades
e relacionamentos
 Mecanismo de validação da arquitetura
2009
MDS - Bacalá
63
Vários diagramas podem ser
necessários
2009
MDS - Bacalá
64
Anatomia de um Diagrama de
Seqüência
Objetos
:Fornecedor
:Cliente
 Linha da vida 
1: Solicita serviço
Mensagem
Foco do
controle
2009
MDS - Bacalá
Mensagem
reflexiva
1.1: Solicita outro
serviço
Numeração
hierárquica65
Exemplo de diagrama de
Seqüência
janela de
matrícula
: Aluno
controle de
matrícula
mat 101
mat 101
section 1
1: preenche info
2: submete
3: ad curso(Jose, mat 101)
4: ad(Jose)
5: curso aberto?
6: ad(Jose)
2009
MDS - Bacalá
66
Diagrama de Colaboração
Objetos
:Cliente
1: Solicita serviço
Ligação
2009
:Fornecedor
Mensagem
MDS - Bacalá
67
Exemplo de diagrama de
colaboração
janela de curso :
1: informação do curso
2: processa
JanelaCurso
3: adiciona curso
: Secretaria
gerenciador :
curso :
GerenciadorCurriculo
Curso
2009
4: novo curso
MDS - Bacalá
68
Exemplo
: usuário
: TelaLogin
: ControladorLogin
: CadastroAlunos
efetuarLogin(login, senha)
efetuarLogin(login, senha)
checar(login, senha)
registrarSessao()
2009
15/03/2005
MDS - Bacalá
69/28
69
Colaboração X Sequência
 Colaboração
 Sequência
 Mostra os
relacionamentos,
além das interações
 Melhor para
visualizar a
colaboração
 Melhor de ser
usado em reuniões
2009
MDS - Bacalá
 Mostra a sequência
explicíta de
mensagens
 Melhor para
visualizar o fluxo
 Melhor para
cenários complexos
70
Passo 3: Descrever
Responsabilidades
 Atualizar os diagramas de classes
com as responsabilidades
identificadas no de iteração
 Mensagens nestes diagramas
resultam em responsabilidades nas
classes receptoras
2009
MDS - Bacalá
71
Como fazer?
diagrama de
interação
diagrama de
classe
2009
:Fornecedor
:Cliente
// Executar responsabilidade
Fornecedor
// Executar responsabilidade
MDS - Bacalá
72
Classes com métodos
2009
15/03/2005
MDS - Bacalá
73/28
73
Passo 4: Descrever atributos e
associações
 Definir atributos
 Estabelecer agregações e associações
2009
MDS - Bacalá
74
Identificando Atributos
 Também é necessário identificar quais
os atributos das classes
 Um bom conhecimento do domínio do
problema é bastante importante para
esta tarefa, principalmente na
identificação de atributos das classes
de entidade
 Nesta etapa ainda não precisamos
indicar quais os tipos dos atributos
2009
15/03/2005
MDS - Bacalá
75/28
75
Encontrando Atributos
 Possíveis fontes: conhecimento do negócio,
requisitos, glossário, modelo do negócio, etc.
 São propriedades/características das classes
identificadas
 informação de propriedade exclusiva do objeto
 informação que pode ser lida ou escrita por
operações, mas sem outro comportamento a não ser
fornecer um valor
 Se a informação tem comportamento complexo ou
é compartilhada, deve gerar uma classe
2009
MDS - Bacalá
76
Identificando relacionamentos
 As classes identificadas não
funcionam isoladamente, elas se
relacionam com as demais classes
 Os diagramas de interação são muito
úteis nesta tarefa
 Para cada ligação presente nos
diagramas de interação, é necessário
um relacionamento no diagrama de
classes
2009
15/03/2005
MDS - Bacalá
77/28
77
Encontrando Relacionamentos
 Interações entre objetos nos diagrama de
interação pode indicar a necessidade de
definir um relacionamento entre as classes
 Adicionar os elementos de um
relacionamento




2009
Tipo e nome
Navegabilidade
Multiplicidade
Papéis
MDS - Bacalá
78
Encontrando Relacionamentos
1: PerformResponsibility
Diagrama de
Colaboração
:Client
:Supplier
Link
Client
Diagrama
de classe
Supplier
Client
0..*
0..*
Prime suppliers
Supplier
PerformResponsibility()
Association
2009
MDS - Bacalá
79
Diagrama final
2009
15/03/2005
MDS - Bacalá
80/28
80
Gerenciando a consistência
 Classes com responsabilidades similares
são candidatas a serem combinadas
 Uma classe com responsabilidades
disjuntas é candidata a ser dividida
 Classes sem (ou com apenas uma
responsabilidade) e classes que interagem
com muitas classes são candidatas a serem
reexaminadas
2009
MDS - Bacalá
81
Passo 5: Qualificar mecanismos de
análise
 Mapear classes de análise em
mecanismos de análise
Classes de análise
Mecanismos de análise
Estudante
Persistente
ControladorMatricula
Distribuição, Segurança
Curso
Persistente, Interface
Legado
2009
MDS - Bacalá
82
Passo 6: Unificar classes de análise
Realização de Caso
de Uso
Diagramas de Classe
…
Realização de Caso
de Uso
Diagramas de Classe
…
Realização de Caso
de Uso
Diagramas de Classe
…
Diagramas de Classe
2009
MDS - Bacalá
83
Projetar classes
Objetivo
 Detalhar as partes do sistema
 Concretização dos conceitos definidos
até o momento
 Detalhes de implementação e ambiente
de produção





2009
Produtos utilizados
Linguagem de programação
Distribuição
Performance
Restrições físicas
MDS - Bacalá
85
Passos do projeto de classes
Para cada classe:
1.
2.
3.
4.
5.
6.
7.
2009
Criar classes de projeto
Identificar classes persistentes
Definir métodos
Definir atributos
Definir estados
Definir relacionamentos
Contemplar os requisitos não-funcionais
MDS - Bacalá
86
Passo 1: Criar classes de
projeto
 Converter classes de análise
(Fronteira, Controle e Entidade) em
classes de projeto
 Padrões de projeto podem ser
incorporados
 As classes são refinadas para
incorporar os mecanismos
arquiteturais
2009
MDS - Bacalá
87
Projetando classes de fronteira
 GUI (Graphical User Interface)
 Que ferramenta de desenvolvimento de interface
gráfica será utilizada?
 Quant pode ser criada pela ferramenta?
 Que padrões serão utilizados?
 Sistemas Externos
 Que tecnologias/mecanismos de integração?
 Que padrões?
 Projetar como um subsistema…
2009
MDS - Bacalá
88
Projetando classes de entidade
 Classes de Entidade são
 Transitórias
 Persistentes
 São detalhadas no passo “Identificar
classes persistentes”
2009
MDS - Bacalá
89
Projetando classes de controle
 Decisões que deve ser tomadas:
 Elas são realmente necessárias?
 Elas podem/devem ser agrupadas?
 Como decidir?




2009
Complexidade
Operações relacionadas
Probabilidade de mudar
Performance e distribuição
MDS - Bacalá
90
Passo 2: Identificando classes
persistentes
 Instancias da classe precisam preservar o
seu estado
 Estratégia de persistencia é definida para
cada classe persistente
Curso
Candidato
2009
JDBC
Serialização
MDS - Bacalá
BD Relacional
Arquivo
91
Passo 3: Definir Métodos
 Tem como propósito mapear
responsabilidades identificada na
análise para métodos na classe
 Deve-se considerar
 Nome, assinatura e visibilidade dos
métodos
2009
MDS - Bacalá
92
Mapeando operações
:Cliente
- concreto
:Fornecedor
// Realizar alguma operação
Análise
Projeto
:Cliente
:Fornecedor
fazerAlgo()
2009
MDS - Bacalá
+ concreto
93
Passo 4: Definir Atributos
 Tem como propósito formalizar a
definição dos atributos
 Deve-se considerar
 Persistência
 Visibidade, nome, tipo e valor inicial
2009
MDS - Bacalá
94
Passo 5: Definir estado
 Tem como objetivo definir como o
objeto se comporta
 Relevante apenas para objetos com
ciclo de vida complexo
 Pode ser especificado em UML
 Diagrama de estados
 Diagrama de atividades
2009
MDS - Bacalá
95
Diagrama de Estados
 Um diagrama de estados mostra o
ciclo de vida de um objeto
Nome do estado
Estado
Variavel: Tipo = valor
Evento(args)
[condição]
/ Operacao(args)
^obj.enviarMensagem(args)
Ação de entrada
Ação de saída
Atividade
Ações
Atividades
2009
MDS - Bacalá
Transição
96
Exemplo de diagrama de estado
Adiciona Aluno[ contador < 10 ]
Inicializado
Adiciona Aluno /
contador = 0
do: Incializa Curso
Aberto
Cancela
Cancela
[ contador = 10 ]
Cancelado
do: Notifica Alunos
Cancela
2009
MDS - Bacalá
Fechado
do: Finaliza curso
97
Passo 6: Definir Relacionamentos
 Dependências
 Associações
 Simples
 Agregação
 Composição
 Generalização
2009
MDS - Bacalá
98
Passo 7: Contemplar os
requisitos não-funcionais
 Concretização dos mecanismos de análise
 Incorporar responsabilidades em algumas
classes
 Criar novas classes
 Exemplos:
 Segurança  Como armazenar as senhas? Que
algoritmo usar para criptografar uma
mensagem?
 Distribuição  Que tecnologia utilizar? Qual o
impacto da tecnologia nos objetos já definidos?
 Tratamento de logs  Que tipo de operações
deve ter log (Acesso a dados, execução de
negócio, …)
2009
MDS - Bacalá
99
Projetar Banco de Dados
 Mapear as classes persistentes em
conceitos do Banco de Dados
 Definir os tipos de dados mais
adequados para o BD
 Normalizar se necessário
2009
MDS - Bacalá
100