Enade - AnaliseProjetoSistemas

Prévia do material em texto

Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
1
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Revisão ENADE 
Análise e Projeto de Sistemas
Professor 
Alberto Tavares da Silva
2
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
3
• Exemplos de PDS existentes:
✓ RUP
✓ XP
✓ SCRUM
• Alguns objetivos de um PDS:
✓ Definir quais as atividades a serem executadas ao longo do projeto;
✓ Definir quando, como e por quem tais atividades serão executadas; 
✓ Prover pontos de controle para verificar o andamento do desenvolvimento; 
✓ Padronizar a forma de desenvolver software em uma organização.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
4
Atividades típicas de um PDS
• Levantamento de requisitos
• Análise de requisitos
• Projeto
• Implementação
• Testes
• Implantação
Engenharia de requisitos
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
5
Modelo em Cascata
• Esse modelo apresenta uma tendência para a progressão 
seqüencial entre uma fase e a seguinte. 
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
6
Modelo iterativo e incremental 
• Desenvolvimento em “minicascatas”.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
7
Modelo Espiral
https://www.google.com.br/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwjR0Pbb0rTVAhXMIpAKHcJYDMoQjRwIBw&url=https%3A%2F%2Ffelipelirarocha.wordpress.com%2F2013%2F07%2F13%2Fciclo-de-vida-de-projeto%2F&psig=AFQjCNGcpkmZJpG7Qv81tmxBtVFGEMgPIw&ust=1501629163638426
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
8
• No processo de Prototipagem o desenvolvedor interage diretamente com o 
usuário, escutando seus pedidos e desenvolvendo, imediatamente, um protótipo 
do produto desejado. 
• O usuário, então, utiliza esse protótipo e fornece ao desenvolvedor novas 
informações que o levam a modificar o protótipo, de maneira a atender todas as 
necessidades do usuário.
• É claramente um processo de desenvolvimento baseado em um ciclo de 
realimentação de informações, com alta participação do usuário.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
RUP 
Ponto de Vista Gerencial
Concepção
Elaboração
1 2 3 ... 
Construção
Transição
16
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Requisito de software
• A especificação de requisitos é um contrato entre clientes e 
equipe de desenvolvimento, devendo esclarecer aos clientes o que 
será entregue como produto do trabalho da equipe de 
desenvolvimento. 
• Esses clientes devem ser capazes de compreender a mensagem e 
fornecer feedback sobre eventuais falhas na especificação, para 
que estas sejam corrigidas de imediato, antes que trabalho errado 
seja produzido mais tarde no projeto. 
• O objetivo principal da especificação é documentar de forma fiel e 
completa todas as necessidades dos clientes e obter um aceite 
(aprovação) sobre o que se está propondo entregar em termos de 
produto.
11
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Rastreabilidade dos requisitos 
• Uma especificação rastreável é aquela que estabelece relação entre 
requisitos, suas origens e produtos derivados. Isso torna a especificação 
mais modificável, mais fácil de verificar se está correta e completa, além de 
facilitar a análise de impacto das mudanças. 
• A rastreabilidade auxilia a verificar a conformidade do produto com os 
requisitos, seja identificando requisitos que estão faltando (especificação 
incompleta) ou sobrando (especificação incorreta). A rastreabilidade 
também ajuda a identificar se todos os objetivos de negócio estão cobertos 
pelos requisitos e produtos gerados, prevenindo insatisfações das partes 
interessadas. 
12
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
• Funcionais
• Não funcionais
• Domínio
Tipos de Requisitos
13
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Requisitos
Não funcionais
Produto Organizacionais Externos
Eficiência Confiabilidade Portabilidade
Usabilidade Padrões
Implemen-
tação
Entrega
Interopera-
bilidade
Legislativos
Privacidade Segurança
Éticos
Requisitos Não Funcionais
14
Produto
Eficiência
Usabilidade
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Propriedade Métrica para Especificar Requisito Não Funcional
Velocidade Transações processadas/segundo
Tempo de resposta ao evento/usuário
Tempo de refresh de tela
Tamanho K bytes
RAM
Facilidade de uso Tempo de treinamento
Número de frames de ajuda
Confiabilidade Tempo médio para falhar
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Disponibilidade
Robustez Tempo de reinício depois de uma falha
Porcentagem de eventos que causam falhas
Probabilidade de que os dados sejam corrompidos por falhas
Portabilidade Porcentagem de declarações dependentes de sistemas-alvo
Número de sistemas-alvo
15
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Requisitos de Domínio: Regras de negócio 
• Requisitos que se originam do domínio de aplicação do sistema, 
em vez das necessidades específicas dos usuários do sistema. 
• Podem ser requisitos funcionais novos (1), restrições sobre 
requisitos existentes (2) ou computações específicas(3). 
• Exemplos de requisitos de domínio:
1) Devido às restrições de direitos autorais, algumas classes de 
documentos serão excluídas após a impressão.
2) Um aluno pode se matricular em uma disciplina desde que ele tenha 
sido aprovado nas disciplinas consideradas pré-requisitos.
3) O cálculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 
+ Nota2 * 3)/5.
16
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
17
Atividades típicas de um PDS
• Levantamento de requisitos
• Análise de requisitos
• Projeto
• Implementação
• Testes
• Implantação
Engenharia de requisitos
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Domínio do 
Problema
Elicitação de 
Requisitos
Análise de 
Requisitos
Validação de 
Requisitos
Verificação 
de Requisitos
18
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Domínio do 
Problema
Elicitação de 
Requisitos
Análise de 
Requisitos
Validação de 
Requisitos
Verificação 
de Requisitos
Documentos de 
Requisitos
19
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Domínio do 
Problema
Elicitação de 
Requisitos
Análise de 
Requisitos
Validação de 
Requisitos
Verificação 
de Requisitos
Documentos de 
Requisitos
Modelos
20
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Domínio do 
Problema
Elicitação de 
Requisitos
Análise de 
Requisitos
Validação de 
Requisitos
Verificação 
de Requisitos
Documentos de 
Requisitos
Modelos
21
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Domínio do 
Problema
Elicitação de 
Requisitos
Análise de 
Requisitos
Validação de 
Requisitos
Verificação 
de Requisitos
Documentos de 
Requisitos
Modelos
22
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
23
• Levantamento de requisitos
• Análise de requisitos
• Projeto
• Implementação
• Testes
• Implantação
Engenharia de requisitos
APÓS A ANÁLISE.....
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
• Durante o levantamento de requisitos, a equipe de 
desenvolvimento tenta entender o domínio que deve ser 
automatizado pelo sistema de software. 
• Há várias técnicas utilizadas para isso, como, por exemplo: 
▪ leitura de obras de referência e livros-texto;
▪ observação do ambiente do usuário - ETNOGRAFIA;
▪ realização de entrevistas com os usuários;
▪ entrevistas com especialistas do domínio;
▪ reutilização de análises anteriores;
▪ comparação com sistemas preexistentes do mesmo domínio do 
negócio. 
ELICITAÇÃO DE REQUISITOS
24
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Modelo de Casosde Uso
Diagrama de Caso de Uso
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Visões de um Sistema
Visão de 
Projeto
Visão de 
Implementação
Visão de 
Processo
Visão de 
Implantação
Casos de Uso
26
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
27
Exemplo de DCU
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
28
Ator, caso de uso, comunicação
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
29
Inclusão (include)
• Exemplo: 
• Referência no texto do caso de uso inclusor: 
Include(Fornecer Identificação)
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
30
Extensão (extend)
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
31
Generalização
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
32
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Modelo de Caso de Uso 
Descrição de Caso de Uso
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
34
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
35
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
36
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
37
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
38
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
39
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
40
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
41
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Modelo de Classes de Análise
42
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
43
Modelo de Análise: Foco no Problema
▪ O modelo de análise não representa detalhes da solução do 
problema.
▪ Embora este sirva de ponto de partida para uma posterior definição das 
classes de software (especificação).
Venda
data
hora
Venda
-data:Date
-hora:Time
+getTotal():Currency
Pagamento
quantia 1 1Pago-por
Pagamento
-quantia: Currency
+getValor(): Currency
1 1Pago-por
Projeto (Especificação)
Análise
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Classe - Diagramação 
Nome da Classe
Atributos
Operações
44
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Exemplo (classe ContaBancária)
45
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Operações
• O comportamento da classe é representado por operações
• As operações podem ser encontradas examinando-se os diagramas 
de interação 
Coordenação
addCurso (Aluno, Curso)
Formulário de 
Registro
Coordenação
Add Curso(João,Inglês)
46
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Funcionário
Lotação1..* 1
é lotado Lota
Departamento
Nome da Associação
Papéis
Multiplicidade
Multiplicidade
Associação Binária
47
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Funcionário Chefiar
*
1
é chefiado
chefia
Associação Reflexiva 
48
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Associação Ternária
Funcionário
*
*
Departamento
Projeto
*
49
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
50
Multiplicidades 
▪ Representam a informação dos limites inferior e superior da 
quantidade de objetos aos quais outro objeto pode se associar.
▪ Cada associação em um diagrama de classes possui duas 
multiplicidades, uma em cada extremo da linha de associação.
Nome Simbologia na UML
Apenas Um 1..1 (ou 1)
Zero ou Muitos 0..* (ou *)
Um ou Muitos 1..*
Zero ou Um 0..1
Intervalo Específico l
i
..l
s
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Associações - Multiplicidades
Classe
1 Exatamente um
Classe
* Muitos (zero ou mais)
Classe
0..1 Zero ou um
51
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
52
Exemplos (multiplicidade)
Exemplo:
– Pode haver um cliente que esteja associado a vários pedidos.
– Pode haver um cliente que não esteja associado a pedido algum.
– Um pedido está associado a um, e somente um, cliente. 
Exemplo:
– Uma corrida está associada a, no mínimo, dois velocistas 
– Uma corrida está associada a, no máximo, seis velocistas. 
– Um velocista pode estar associado a várias corridas.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
53
Conectividade
▪ A conectividade corresponde ao tipo de associação entre duas 
classes: “muitos para muitos”, “um para muitos” e “um para 
um”.
▪ A conectividade da associação entre duas classes depende dos 
símbolos de multiplicidade que são utilizados na associação.
Conectividade Em um extremo No outro extremo
Um para um 0..1
1
0..1
1
Um para muitos 0..1
1
*
1..*
0..*
Muitos para muitos *
1..*
0..*
*
1..*
0..*
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
54
Exemplos de Conectividade
gerencia gerenciado
1 0..1
alocado aloca
0..* 1
alocado aloca
0..* 1..*
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Associação - Agregação
▪ Forma especial de Associação que serve para mostrar que uma 
determinada classe de objetos é composta por outra classe.
▪ Semanticamente indica que o objeto parte é um atributo do 
objeto todo (é-parte-de).
▪ A agregação oferece uma variação denominada COMPOSIÇÃO .
55
TimeTorneio
0..* *
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
▪ O objeto parte só tem existência se o objeto todo existir. 
▪ A multiplicidade da associação é sempre 1 do lado do objeto 
todo. 
▪ A representação é feita colocando-se um losango cheio do lado 
do objeto todo.
Item PedidoPedido
1 1..*
Associação - Composição
56
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Classe Associativa
57
Fornecedor 1..*1..* Produto
Fornecimento
quantidade
fornece fornecido
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Classe Associativa
58
Médico 1..*1..* Paciente
Consulta
data
diagnóstico
atende atendido
Exame
solicita solicitado
0..*0..*
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
▪ É um relacionamento entre em elemento mais geral (superclasse) e um 
elemento mais específico (subclasse).
▪ Indica que a superclasse tem atributos, operações e associações comuns 
que são compartilhados por todas as subclasses derivadas.
▪ Um objeto de uma subclasse é um tipo-de objeto da superclasse.
Herança
Funcionário
Engenheiro Motorista
59
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Classe Abstrata
• Uma classe que provê organização.
60
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Pessoa
Professor Aluno
IMatricula
Interface
61
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Herança - Restrições
▪ Sobreposição - objetos podem ocorrer simultaneamente em mais de 
uma subclasse de uma mesma superclasse.
▪ Disjunção - objetos só podem pertencer a uma subclasse de uma 
mesma superclasse.
▪ Completo - todas as subclasses estão representadas.
▪ Incompleto - Nem todas as subclasses estão representadas.
Funcionário
Engenheiro Motorista
{disjunção, incompleto} {sobreposição, completo}
Pessoa
Cliente Funcionário
62
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
PedidoItemPedidoProduto
nome = "Caderno M"
descrição = "Caderno em espiral tamanho médio"
preçoUnitário = 4,50
desconto = 15
produto20 : Produto
nome = "Caneta ESF"
descrição = "Caneta esferográfica 5mm"
preçoUnitário = 1,20
desconto = 2
produto12 : Produto
nome = "Esquadro"
descrição = "Esquadro de acrílico 20 cm"
preçoUnitário = 2,35
desconto = 10
produto07 : Produto
quantidade = 20
item2 : ItemPedido
quantidade = 6
item1 : ItemPedido
quantidade = 1
item3 : ItemPedido
data = 13/09/2002
hora = 10:00am
Pedido1 : Pedido
Diagrama de Objetos
63
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
64
Modelagem de Atividades
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares 65
Diagrama de atividade
fork
join
Revisão ENADE – Análise eProjeto de Sistemas
Prof Tavares 66
Exemplo (Raias de Natação) 
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
67
Modelagem de processos do negócio
Estudo de Caso: Cia Marítima
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Modelo de Estados
68
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
69
Notação Básica da UML para Diagramas de 
Transição de Estados
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
ItemComercial 
precoDeVenda
condicaoDeInspecao
US$ 2,95
US$ 3,14
US$ 5,75
Recebido
SobInspecao
ReprovadoAprovado•Atributo com muitos 
valores possíveis.
•Pouca restrição na 
transição dos valores 
possíveis.
• Atributo con poucos valores possíveis.
• Restrições significativas, pois não se pode 
trocar de “recebido” para “aprovado” ou 
“reprovado” sem antes passar por 
“sobInspeção”.
Estado
70
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Tempo
ligado
Motor
ligado
Motor
ligado
Motor
desligado
desligado
•Eventos reapresentam pontos no tempo;
•Estados reapresentam intervalos de tempo.
Transições
71
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
72
Cláusula do - exemplo 
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
73
Cláusula do - exemplo 
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
74
Exemplo de ponto de junção 
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Neutro
push N
Contramarcha
Frente 
upshift
Primeira TerceiraSegunda
upshift
downshift downshift
push C
push Fpush N
pare
TransmissaoDeCarro.status
Estados Aninhados
75
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Aberto Confirmado
cliente confirma pedido
Cancelado
cliente cancela pedido
cliente cancela pedido
[self.statusDeRemesa = not remetido]
after (30 dias)
Cliente.notificarCancelado(self)
cliente faz pedido
PedidoCliente.status
76
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Modelo de Classes de Projeto
77
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares 78
• As principais atividades realizadas na fase de projeto são:
1. Detalhamento dos aspectos dinâmicos do sistema. 
2. Refinamento dos aspectos estáticos e estruturais do sistema. 
3. Detalhamento da arquitetura do sistema. 
4. Definição das estratégias para armazenamento, gerenciamento e 
persistência dos dados manipulados pelo sistema. 
5. Realização do projeto da interface gráfica com o usuário.
6. Definição dos algoritmos a serem utilizados na implementação.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares 79
Algumas decisões Arquiteturais
• Linguagem de Programação
• Frameworks que serão utilizados
• Camadas
• Persistência
• Segurança
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Objetos «entity»
Categorização BCE
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
81
Layer «control»
BLL
Categorização BCE
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
82
C V
M
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
83
Sintaxe para atributos
e operações
• Obs.: classes utilitárias podem ser utilizadas como 
tipos para atributos. (e.g., Moeda, Quantia, 
TipoCarro, Endereco)
+obterNome() : String
+definirNome(in umNome : String)
+obterDataNascimento() : Data
+definirDataNascimento(in umaData : Data)
+obterTelefone() : String
+definirTelefone(in umTelefone : String)
+obterLimiteCrédito() : Moeda
+definirLimiteCrédito(in umLimiteCrédito : float)
+obterIdade() : int
+obterQuantidadeClientes() : int
+obterIdadeMédia() : float
Cliente
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
84
Visibilidade e Encapsulamento
• Os três qualificadores de visibilidade aplicáveis aos atributos também podem ser 
aplicados às operações.
+ representa visibilidade pública
# representa visibilidade protegida
- representa visibilidade privativa
• O real significado desses qualificadores depende da linguagem de programação 
em questão.
• Usualmente, o conjunto das operações públicas de uma classe são chamadas de 
interface dessa classe.
– Note que há diversos significados para o termo interface.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
85
Membros estáticos
• Membros estáticos são representados no diagrama de classes por 
declarações sublinhadas. 
– Atributos estáticos (variáveis de classe) são aqueles cujos valores valem para a classe 
de objetos como um todo.
• Diferentemente de atributos não-estáticos (ou variáveis de instância), cujos valores são 
particulares a cada objeto.
– Métodos estáticos são os que não precisam da existência de uma instância da classe a 
qual pertencem para serem executados.
• Forma de chamada: NomeClasse.Método(argumentos)
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
86
Navegabilidade de associações
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
87
Conectividade 1:1
public class Professor {
private GradeDisciplinas grade;
...
}
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
88
Conectividade 1:N
• Formas alternativas para representação de uma associação 
cuja conectividade é 1:N. 
refinamento
original
refinamento
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
89
Conectividade 1:N (cont)
public class Aluno {
private Set<Participacao> participacoes;
...
public boolean adicionarParticipacao(Participacao p){
...
}
public boolean removerParticipacao(Participacao p) {
...
}
}
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
90
Conectividade N:M
refinamento
original
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
91
Implementação de classes 
associativas
refinamentooriginal
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Tipos de herança
• Com relação à quantidade de superclasses que certa classe pode ter. 
herança simples herança múltipla
92
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
93
Operações abstratas (cont)
• Na UML, a assinatura de uma operação abstrata é definida em 
itálico.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
94
• Operações polimórficas também podem existir em classes abstratas.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
95
Interface 
public interface ElementoDiagrama {
double PI = 3.1425926; //static and final constant.
void desenhar(); 
void redimensionar();
}
public class Circulo implements ElementoDiagrama {
…
public void desenhar() { /* draw a circle*/ }
public void redimensionar() { /* draw a circle*/ }
}
public class Retangulo implements ElementoDiagrama {
…
public void desenhar() { /* draw a circle*/ }
public void redimensionar() { /* draw a circle*/ }
}
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Modelagem de Interação
96
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
97
Da Análise ao Projeto
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
98
Diagramas de Interação
• Duas visões:
– (1) Baseada na Organização (Diagrama de Comunicação)
– (2) Baseada em Tempo (Diagrama de Sequência)
Diagrama de sequência: foco nas mensagens enviadas no decorrer do tempo.
Diagrama de comunicação: foco nas mensagens enviadas entre objetos que 
estão relacionados.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Mensagens versus Responsabilidades
• Qual o objetivo da construção dos diagramas de interação?
– Identificar mensagens e, em última análise, responsabilidades (operações e atributos)
Uma mensagem implica na existência de uma operação no 
objeto receptor. A resposta do objeto receptor ao recebimento 
de uma mensagem é a execução da operação correspondente. 
99
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
100
Sintaxe UML para mensagens 
• Mensagemsimples, sem cláusula alguma.
1: adicionarItem(item)
• Mensagem com cláusula de condição.
3 [a > b]: trocar(a, b)
• Mensagem com cláusula de iteração e com limites indefinidos.
2 *: desenhar( )
• Mensagem com cláusula de iteração e com limites definidos. 
2 *[i := 1..10]: figuras[i].desenhar( )
• Mensagem aninhada com retorno armazenado na variável x.
1.2.1: x := selecionar(e)
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
101
Sintaxe UML para mensagens 
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
102
Notação para objetos
• Objetos são representados pela notação de um retângulo com o nome do objeto sublinhado dentro 
dele.
• Pode-se representar objetos anônimos ou objetos nomeados, dependendo da situação.
• Elementos de uma coleção também podem ser representados.
• Classes também podem ser representadas.
– Para o caso de mensagens enviadas para a classe.
– Uma mensagem para uma classe dispara a execução de uma operação estática. 
– A representação de uma classe em um diagrama de sequência é a mesma utilizada para objetos, 
porém o nome da classe não é sublinhado. 
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
103
Notação para multiobjetos
• Uma multiobjeto é representado graficamente na UML através de dois 
retângulos superpostos.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
104
Diagrama de Sequência
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
105
• Em uma mensagem reflexiva (ou auto-mensagem) o remetente é também o receptor.
– Corresponde a uma mensagem para this (self). 
– O que isso significa na prática?
Diagrama de Sequência
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
106
Diagrama de Sequência
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
107
Diagrama de Sequência
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
108
Diagrama de Sequência
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
109
Diagrama de Comunicação
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
110
Diagrama de Comunicação
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
111
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
112
Diagramas Referenciados
Fazer referência a um diagrama definido separadamente.
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
113
Fluxo de Controle: Alternativas
Mapeamento Objeto-Relacional
Mapeamento de Objetos 
para o Modelo Relacional
Mapeamento Objeto-Relacional
Cliente(id, CPF, nome, telefone, logradouro, dataNascimento, idCPF)
CPF(id, número, digitoVerificador)
Cliente(id, nome, telefone, logradouro, dataNascimento, CPF, CEP)
Mapeamento: Classes e seus atributos
Mapeamento Objeto-Relacional
0..1
1
Gerenciado
-matrícula : String
-CPF : String
-nome : String
-endereço : String
-CEP : String
Empregado
-sigla : String
-nome : String
Departamento
Departamento(id, sigla, nome, idEmpregadoGerente )
Empregado( id, matrícula, CPF, nome, endereço, CEP )
Mapeamento de associações 1:1
Mapeamento Objeto-Relacional
• Seja Ca a classe na qual cada objeto se associa com muitos objetos da classe Cb.
• Sejam Ta eTb as relações resultantes do mapeamento de Ca e Cb, respectivamente.
• Neste caso, deve-se adicionar uma chave estrangeira em Ta para referenciar a chave 
primária de Tb.
Departamento( id, sigla, nome, idEmpregadoGerente )
Empregado(id, matrícula, CPF, nome, endereço, CEP, idDepartamento)
1
*
Trabalha
-matrícula : String
-CPF : String
-nome : String
-endereço : String
-CEP : String
Empregado
-sigla : String
-nome : String
Departamento
Mapeamento de associações 1:N
Mapeamento Objeto-Relacional
-matrícula : String
-CPF : String
-nome : String
-endereço : String
-CEP : String
Empregado
-nome : String
-verba : Decimal
Projeto
* *
Alocado
Departamento(id, sigla, nome, idEmpregadoGerente)
Empregado(id, matrícula, CPF, nome, endereço, CEP, idDepartamento)
Alocação(idProjeto, idEmpregado)
Projeto(id, nome, verba)
Departamento(id, sigla, nome, idEmpregadoGerente)
Empregado(id, matrícula, CPF, nome, endereço, CEP, idDepartamento)
Alocação(id, idProjeto, idEmpregado)
Projeto(id, nome, verba)
Mapeamento de associações N:M
Mapeamento Objeto-Relacional
Empregado(id,matrícula,nome,dataContratação,idCônjunge,idSupervisor)
matrícula : String
nome : String
dataContratação : Data
Empregado
supervisor 1
supervisionado
*
marido
0..1
esposa 0..1
Mapeamento de associações reflexivas
Mapeamento Objeto-Relacional
Técnico( id, nome )
Projeto( id, nome, verba )
Computador( id, modelo )
Alocação( id, idProjeto, idTécnico, idComputador )
-nome
Técnico
-modelo
Computador
-nome
-verba
Projeto
* *
*
Alocação
Mapeamento de associações n-árias
Mapeamento Objeto-Relacional
matrícula
nome
Empregado
sigla
nome
verbaAnual
Projeto
líder 1 0..1
nome
descrição
Ferramenta
dataUso
Utilização
* *
cargaHorária
remuneração
Trabalho
* 0..1
Empregado(id, matrícula, nome)
Projeto(id, sigla, nome, verbaAnual, idEmpregadoLíder)
Ferramenta(id, nome, descrição)
Utilização(id, idFerramenta, idProjeto, dataUso )
Trabalho(id, idEmpregado, idProjeto, cargaHorária, remuneração)
Mapeamento de classes associativas
Mapeamento Objeto-Relacional
Mapeamento de generalizações
endereço
Contribuinte
CPF
nome
dataNascimento
PessoaFísica
CNPJ
razãoSocial
PessoaJurídica
Contribuinte(id, endereço)
PessoaFísica(id, nome, dataNascimento, CPF, idContribuinte)
PessoaJurídica(id, CNPJ, razãoSocial, idContribuinte)
Pessoa(id,nome,endereço,dataNascimento,CPF,CNPJ,razãoSocial,tipo)
PessoaFísica(id, dataNascimento, nome, endereço, CPF)
PessoaJurídica(id, CNPJ, endereço, razãoSocial)
Mapeamento Objeto-Relacional
Arquitetura de SW
Modelo de Implementação
Modelo de Implantação
Arquitetura de SW
Na realidade, não existem propriamente diagramas de pacotes em UML; em 
vez disso, pacotes e relações entre pacotes aparecem em outros diagramas, 
de acordo com o tipo de pacote: 
✓ Pacotes de classes (pacotes lógicos) - em diagramas de classes.
✓ Pacotes de componentes – em diagramas de componentes
✓ Pacotes de nós – em diagramas de distribuição/ instalação.
✓ Pacotes de casos de uso – em diagramas de casos de uso.
Diagrama de Pacotes
Arquitetura de SW
• Uma vez que representa um agrupamento, um pacote é em geral “dono” de 
diversos elementos: classes, interfaces, componentes, nós, colaborações, casos de 
uso, diagramas, e até outros pacotes.
Diagrama de Pacotes
Arquitetura de SW
Diagrama de Pacotes
Arquitetura de SWDiagrama de Pacotes
Arquitetura de SW
• Uma divisão tipicamente encontrada para as camadas lógicas de um 
SSOO é a que separa o sistema nas seguintes camadas: 
– apresentação, aplicação, domínio e serviços técnicos. 
• Da esquerda para a direita, temos camadas cada vez mais genéricas. 
• Também da esquerda para a direita, temos a ordem de dependência 
entre as camadas; 
– por exemplo a camada da apresentação depende (requisita serviços) da camada 
de aplicação, mas não o contrário. 
Camadas de software
Arquitetura de SW
Camadas de software - BCE
Arquitetura de SW
Padrão 
M
V
C
Camadas de software - MVC
Arquitetura de SW
132
Modelo de Implementação
Diagrama de Componentes
Arquitetura de SW
• A UML identifica os seguintes estereótipos para componentes:
– «document»: denota um documento.
– «executable»: denota um programa que possa ser executado num nó.
– «file»: denota um documento contendo código fonte ou dados.
– «library»: denota uma biblioteca dinâmica ou estática.
– «table»: denota uma tabela de uma base de dados.
Diagrama de Componentes
Arquitetura de SW
Diagrama de Componentes
Arquitetura de SW
Diagrama de Componentes
Arquitetura de SWDiagrama de Componentes
Arquitetura de SW
Modelo de Implantação
Diagrama de Implantação
Arquitetura de SW
• Exemplo de diagrama de implantação
Diagramade Implantação
Arquitetura de SW
✓ Diversas notações para diagrama de implantação e diagrama de 
componentes
Alocação de Componentes
Arquitetura de SW
✓ Exemplo de diagrama de componentes embutido em um
diagrama de implantação.
Relações entre Nós e Componentes
Arquitetura de SW
Diagrama de Implantação
Arquitetura de SW
Service Oriented Architecture
SOA
Arquitetura de SW
•Arquitetura Orientada a Serviços (SOA) não é
uma tecnologia, não é uma metodologia, não é
um serviço, mas é um conceito de arquitetura
corporativa que promove a integração entre o
negócio e a TI por meio de conjunto de
interfaces de serviços acoplados.
Arquitetura de SW
Obrigado!
144
Mapeamento Objeto-Relacional
Obrigado!
145
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Obrigado!
146
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Obrigado!
147
Revisão ENADE – Análise e 
Projeto de Sistemas
Prof Tavares
Obrigado!
148