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 Análise Projeto

2009
15/03/2005 MDS - Bacalá 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 Descrito na linguagem
do cliente dos desenvolvedores
Visão externa do Visão interna do sistema
sistema
Captura as Mostra, de modo
funcionalidades do abstrato, como a
sistema funcionalidade pode ser
realizada
Estruturado por casos Estruturado por classes
de uso e pacotes

2009
15/03/2005 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  Foco no entendimento
do problema da solução
 Projeto idealizado  Operações e atributos
 Comportamento  Performance
 Estrutura do sistema  Pensamento no código
 Requisitos funcionais  Ciclo de vida de
 Modelos simples objetos
 Requisitos não-
funcionais
 Modelo complexo

2009 MDS - Bacalá 8

 Visão geral dos artefatos

Modelo de análise
e projeto

Modelo de caso
de uso
Análise e Documento da
arquitetura
projeto

Modelo de dados
Glossário Documento
requisitos

2009 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 Realização de Caso
de Uso

Descreve como o caso

de uso é realizado,
associando o caso de Diagramas de Sequência
uso com classes e
outros elementos de Diagramas de Colaboração
Diagramas de Classe
projeto

 Requisitos   Analise e projeto 

2009 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) ?
 MVC
 Baseado em camadas
 Canais e filtros
 Centrado em repositório

2009 MDS - Bacalá 31

Exemplo de arquitetura inicial

Módulo de Vendas
Módulo de
Interface Gráfica Estoque

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
 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

2009 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
 Persistência
 Comunicação
 Gerenciamento de transações
 Segurança

2009 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>> <<entity>>

Modela interação entre o sistema e seu ambiente

2009 MDS - Bacalá 43
Exemplo de classes de fronteira

Matricular-se
Estudante Em disciplina Sistema
Academico

<<boundary>> <<boundary>>
FormRegistroCursos SistemaAcademico

2009 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>> <<entity>>

Armazenam e gerenciam informação no sistema

2009 MDS - Bacalá 47
Exemplo de classes de entidade

<<entity>> <<entity>>
Estudante 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

Matricular-se
Estudante Em disciplina Sistema
Academico

<<control>>
ControladorMatricula

matricurlarAluno()

2009 MDS - Bacalá 52

Exemplo

efetuar login
Usuario
registrar súmulas
adicionar turma das aulas

remover turma
Professor
Secretária registrar faltas
Aluno

editar turma
consultar freqüência

editar alunos remover alunos

adicionar alunos Servidor de e-mail

2009
15/03/2005 MDS - Bacalá 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>> <<control>> <<entity>>

TelaLogin ControladorLogin Usuario

2009
15/03/2005 MDS - Bacalá 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

<<boundary>> <<control>>
TelaLogin ControladorLogin

<<entity collection>> <<entity>>

CadastroUsuarios Usuario

2009
15/03/2005 MDS - Bacalá 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 Diagrama de colaboração

Classes de análise com

Caso de uso responsabilidades

2009 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

:Cliente :Fornecedor
 Linha da vida  Mensagem
reflexiva
1: Solicita serviço

1.1: Solicita outro

Mensagem serviço

Foco do
controle Numeração
2009 MDS - Bacalá hierárquica65
Exemplo de diagrama de
Seqüência

janela de controle de mat 101 mat 101

: Aluno
matrícula matrícula 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 :Fornecedor
1: Solicita serviço

Ligação Mensagem

2009 MDS - Bacalá 67

Exemplo de diagrama de
colaboração
janela de curso :
1: informação do curso JanelaCurso
2: processa

3: adiciona curso
: Secretaria

curso : gerenciador :

Curso GerenciadorCurriculo

4: novo curso
2009 MDS - Bacalá 68
Exemplo

: CadastroAlunos
: usuário : TelaLogin : ControladorLogin

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  Mostra a sequência
relacionamentos, explicíta de
além das interações mensagens
 Melhor para  Melhor para
visualizar a visualizar o fluxo
colaboração  Melhor para
 Melhor de ser cenários complexos
usado em reuniões

2009 MDS - Bacalá 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 :Cliente :Fornecedor

interação
// Executar responsabilidade

diagrama de Fornecedor
classe
// Executar responsabilidade

2009 MDS - Bacalá 72

Classes com métodos

<<boundary>> <<control>>
TelaLogin ControladorLogin

efetuarLogin(login, senha) efetuarLogin(login, senha)

registrarSessao()

<<entity collection>>
CadastroUsuarios <<entity>>
Usuario
checar(login, senha)

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

 Tipo e nome
 Navegabilidade
 Multiplicidade
 Papéis

2009 MDS - Bacalá 78

Encontrando Relacionamentos
1: PerformResponsibility
Diagrama de
Colaboração :Client :Supplier

Link
Client Supplier

Client 0..* 0..* Supplier

Diagrama
de classe Prime suppliers PerformResponsibility()

Association

2009 MDS - Bacalá 79

Diagrama final
<<control>>
<<boundary>>
ControladorLogin
TelaLogin
* 1 efetuarLogin(login, senha)
efetuarLogin(login, senha)
registrarSessao()

<<entity collection>> 1 <<entity>>

CadastroUsuarios Usuario
login
checar(login, senha) senha

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 Realização de Caso Realização de Caso
de Uso de Uso de Uso

Diagramas de Classe Diagramas de Classe

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
 Produtos utilizados
 Linguagem de programação
 Distribuição
 Performance
 Restrições físicas

2009 MDS - Bacalá 85

Passos do projeto de classes
Para cada classe:
1. Criar classes de projeto
2. Identificar classes persistentes
3. Definir métodos
4. Definir atributos
5. Definir estados
6. Definir relacionamentos
7. Contemplar os requisitos não-funcionais

2009 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?
 Complexidade
 Operações relacionadas
 Probabilidade de mudar
 Performance e distribuição

2009 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

JDBC
Curso BD Relacional

Serialização
Candidato Arquivo

2009 MDS - Bacalá 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 - concreto

:Cliente :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

Evento(args)
Nome do estado [condição]
/ Operacao(args)
Variavel: Tipo = valor ^obj.enviarMensagem(args)
Estado
Ação de entrada
Ação de saída Ações
Atividade
Atividades Transição
2009 MDS - Bacalá 96
Exemplo de diagrama de
estado

Adiciona Aluno[ contador < 10 ]

Adiciona Aluno /
Inicializado contador = 0
do: Incializa Curso
Aberto

Cancela
Cancela [ contador = 10 ]
Cancelado
do: Notifica Alunos
Fechado
Cancela do: Finaliza curso

2009 MDS - Bacalá 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