Modelagem de Sistemas

Prévia do material em texto

1
Modelagem de Sistemas 
Orientado a Objeto
por
Rita Suzana Pitangueira Maciel
2009
© ritasuzana@dcc.ufba.br
© ritasuzana@dcc.ufba.br 2
Bibliografia
�UML – Guia do Usuário
ִJames Rumbaugh, Grady Booch, e al. 
ִUML e padrões. Craig Larman
�Princípios de Análise e Projeto de Sistemas 
com UML
ִEduardo Bezerra
�Especificação da UML
ִ http://www.omg.org/technology/documents/formal/uml.htm.
© ritasuzana@dcc.ufba.br 3
Avaliação
�Estudo de Caso – Modelagem
�Exercícios em sala 
© ritasuzana@dcc.ufba.br 4
Roteiro
�Desenvolvimento de Software
�Engenharia de Software
�Conceitos Básicos da Orientação a Objeto
�Análise Orientada a Objeto
�UML
© ritasuzana@dcc.ufba.br 5
Desenvolvimento de Software
�Utilização de computadores na sociedade
ִcrescente demanda por soluções 
computadorizadas
�Evolução do hardware tem sido mais 
acentuada
ִmáquinas cada vez mais velozes e com maior 
capacidade de processamento
© ritasuzana@dcc.ufba.br 6
Desenvolvimento de Software
�Crise de Software
ִdemanda muito superior à capacidade de 
desenvolvimento
ִqualidade insuficiente dos produtos
ִestimativas de custo e tempo raramente 
cumpridas nos projetos
© ritasuzana@dcc.ufba.br 7
Engenharia de Software
�Área de pesquisa 
�Objetivos
ִmelhoraria da qualidade dos produtos de 
software
ִaumento da produtividade no processo de 
desenvolvimento 
© ritasuzana@dcc.ufba.br 8
Engenharia de Software
�Construção de uma solução computadorizada
ִConsiste
mapeamento do problema a ser resolvido no 
mundo real num modelo de solução no Espaço de 
Soluções
Espaço de Soluções
• meio computacional
© ritasuzana@dcc.ufba.br 9
Engenharia de Software
�A modelagem envolve
ִidentificação de objetos e operações 
relevantes no mundo real 
ִmapeamento desses em representações 
abstratas no Espaço de Soluções
© ritasuzana@dcc.ufba.br 10
Engenharia de Software
�Gap Semântico
ִHiato semântico
ִdistância existente entre o problema no mundo real e 
o modelo abstrato construído
ִquanto menor ele for, mais direto será o 
mapeamento
mais rapidamente serão construídas soluções para o 
problema
ִárea de atuação da Engenharia de Software
© ritasuzana@dcc.ufba.br 11
Engenharia de Software
Objeto 1 Objeto 2
Objeto 3
Programas
Dados
Hiato Semântico
Mundo Real
Mundo 
Computacional
© ritasuzana@dcc.ufba.br 12
Engenharia de Software
�Técnicas e métodos têm sido propostos para 
as diferentes fases do processo de 
desenvolvimento, buscando minimizar o gap.
�Abordagens para o Desenvolvimento de 
Software
ִMétodos Orientados a Funções 
ִMétodos Orientados a Dados
ִMétodos Orientados a Objeto
© ritasuzana@dcc.ufba.br 13
Engenharia de Software
�Funções
ִ são ativas e têm comportamento
�Dados 
ִsão repositórios passivos de informação
ִafetados por funções
�Divisão tem origem na arquitetura de 
hardware de Von Neumann
ִseparação entre programa e dados é 
fortemente enfatizada.
© ritasuzana@dcc.ufba.br 14
Engenharia de Software
�Métodos Orientados a Funções
ִconduzem o desenvolvimento de software 
estruturando as aplicações segundo a ótica 
das funções (ações) que o sistema deverá 
realizar
ִO sistema é decomposto em funções
dados são enviados entre elas
ִAnálise Estruturada 
Cris Gane
© ritasuzana@dcc.ufba.br 15
Engenharia de Software
�Métodos Orientados a Dados
ִenfatizam a identificação e estruturação dos 
dados
ִsubjulgando a análise das funções para um 
segundo plano
ִOrigem
Modelo de Entidades e Relacionamentos (MER)
Peter Chen,1979
© ritasuzana@dcc.ufba.br 16
Engenharia de Software
�Métodos Orientados a Dados - Motivação
ִA ênfase nas funções leva a sistemas com 
muita redundância 
ִInconsistentes e difíceis de serem integrados
ִDados possuem existência própria nas 
organizações independentemente dos 
processos que os manipulam
ִDados são muito mais estáveis que as 
funções em uma organização
© ritasuzana@dcc.ufba.br 17
Engenharia de Software
�Metodologias Dados X Função
ִmodelo de dados deve representar a
realidade
conhecimento da realidade, muitas vezes, passa
pelo conhecimento das funções
ִtodas as funções têm de conhecer como os
dados estão armazenados (estrutura dos
dados)
ִmudanças na estrutura dos dados quase
sempre acarretam modificações em todas as
funções relacionadas a essa estrutura
© ritasuzana@dcc.ufba.br 18
Engenharia de Software
�Metodologias Dados X Função
ִambas as abordagens afastam-se do mundo 
real
ִdados e funções são aspectos fundamentais 
que guardam estreita inter-relação na 
concepção de um sistema
devem ser tratados em conjunto
ִinterpretação dos dados é provida pelos 
programas que lêem ou escrevem dados
ִprogramas podem dar diferentes 
interpretações aos dados 
necessário conhecer como eles foram projetados 
para poder interpretá-los corretamente 
© ritasuzana@dcc.ufba.br 19
Engenharia de Software
�Métodos Orientados a Objeto
ִpartem de um ponto de vista distinto e 
intermediário
ִmundo real é composto de objetos
ִobjeto é uma entidade que combina 
estrutura de dados e comportamento 
funcional
ִsistemas são modelados como um número 
de objetos que interagem entre si
© ritasuzana@dcc.ufba.br 20
Engenharia de Software
�Métodos Orientados a Objeto
ִobjetivos
diminuir o gap semântico 
trabalhar com noções intuitivas durante todo o 
ciclo de vida
retardar, ao máximo, a introdução de conceitos 
de implementação
ִperspectiva mais humana de observação da 
realidade
© ritasuzana@dcc.ufba.br 21
Engenharia de Software
�Métodos Orientados a Objeto
• Capacidade de enfrentar novos domínios de
aplicação;
• Melhoria da interação entre analistas e
especialistas;
• Aumento da consistência interna dos resultados da
análise;
• Uso de uma representação básica consistente para
a análise e projeto;
• Alterabilidade, legibilidade e extensibilidade;
• Possibilidade de ciclos de desenvolvimento
variados;
• Apoio à reutilização.
© ritasuzana@dcc.ufba.br 22
Conceitos Básicos
�Objeto
ִunidade real ou abstrata
ִindividualizada
ִrepresenta um conceito da realidade humana
ִocupa
espaço físico (mundo físico)
lógico (memória)
ִentidade que incorpora uma abstração 
relevante para o conceito da aplicação
© ritasuzana@dcc.ufba.br 23
Conceitos Básicos
�Objeto
ִAbstração
© ritasuzana@dcc.ufba.br 24
Conceitos Básicos
�Estado
ִconjunto das propriedades de um objeto
ִatributos e aos valores a eles associados
© ritasuzana@dcc.ufba.br 25
Conceitos Básicos
�Comportamento
ִconjunto de serviços (operações) que outros 
objetos (clientes) podem requisitar
© ritasuzana@dcc.ufba.br 26
Conceitos Básicos
�Operações
ִrecuperam ou manipulam a informação de 
estado de um objeto
ִreferem-se apenas às estruturas de dados do 
próprio objeto
não devem acessar diretamente estruturas de 
outros objetos
ִalvo invocado por um objeto
ִserviço de uma classe 
© ritasuzana@dcc.ufba.br 27
Conceitos Básicos
�Identidade
ִcada objeto tem uma identidade própria
ִobjetos têm existência própria
ִobjetos são distintos mesmo se seu estado e 
comportamento forem iguais
ִcada objeto dispõe de um identificador único 
pelo qual pode ser referenciado 
inequivocamente
© ritasuzana@dcc.ufba.br 28
Conceitos Básicos
�Um objeto possui estado, exibe algum 
comportamento bem definido e possui 
identidade própria
© ritasuzana@dcc.ufba.br 29
Conceitos Básicos
�Encapsulamento
ִInteração entre objetos sem conhecimento 
do funcionamento interno
© ritasuzana@dcc.ufba.br 30
Conceitos Básicos
�Encapsulamentoִocultamento de informação
ִseparação dos aspectos externos de um 
objeto acessíveis por outros objetos
ִdetalhes internos de implementação ocultos 
dos demais objetos
ִa estrutura de um objeto e a implementação 
de seus métodos são encapsuladas
© ritasuzana@dcc.ufba.br 31
Conceitos Básicos
�Encapsulamento
ִusuários têm conhecimento
operações que podem ser requistadas
do que as operações realizam
ִnão é necessário saber como foram 
implementadas 
© ritasuzana@dcc.ufba.br 32
Conceitos Básicos
�Encapsulamento
ִMotivação
facilitar a reutilização de objetos 
garantir estabilidade aos sistemas
base para a localização de decisões de projeto 
que necessitam ser alteradas
Se a operação está encapsulada
• apenas o objeto que a define precisa ser modificado,
garantindo estabilidade ao sistema.
© ritasuzana@dcc.ufba.br 33
Conceitos Básicos
�Classe
ִmodelo que descreve a estrutura e o 
comportamento de objetos
ִdescrição de atributos e operações
ִos objetos compartilham
atributos
operações
relações
semântica
ִconjunto de objetos
© ritasuzana@dcc.ufba.br 34
Conceitos Básicos
�Instância
ִum membro descrito por uma classe
ִobjetos que se comportam da maneira 
especificada pela classe 
ִuso informal
objeto -> instância
© ritasuzana@dcc.ufba.br 35
Conceitos Básicos
�Método
ִprocedimento
ִimplementação de uma operação
�Métodos Construtores
ִChamados quando objetos são 
inicializados
�Os objetos se comunicam através de 
mensagens
ִOperações são executadas sempre que um objeto 
recebe uma mensagem de outro objeto
© ritasuzana@dcc.ufba.br 36
Conceitos Básicos
�Persistência
ִpropriedade de objetos através da qual sua 
existência transcende o tempo e/ou o espaço
ִobjeto poder continuar a existir após seu 
criador ter deixado de existir
ִtempo de vida é independente do tempo de 
vida do programa que o criou
© ritasuzana@dcc.ufba.br 37
Conceitos Básicos
�Polimorfismo
ִQuando a mesma operação possui 
métodos (implementação) diferentes em 
classes distintas
ִExemplos
Mover uma janela
Mover uma figura
Transferir um funcionário
Transferir um departamento
© ritasuzana@dcc.ufba.br 38
Conceitos Básicos
�Polimorfismo -Vantagens
ִPermite 
envio de mensagens a um objeto sem a determinação exata 
do seu tipo.
extensibilidade do sistema com pouco ou nenhum impacto 
nas classes existentes.
construção de classes genéricas para efetuar tarefas gerais 
comuns aos softwares, como as estruturas de dados.
© ritasuzana@dcc.ufba.br 39
Conceitos Básicos
�Sobrecarga
• Um método pode ter o mesmo nome que outro 
método na mesma classe.
• Isto é usual quando existem duas ou mais formas 
diferentes de se realizar a mesma tarefa.
• Neste caso diz-se que o método está sobrecarregado.
© ritasuzana@dcc.ufba.br 40
Conceitos Básicos
�Sobrecarga
• Uma sobrecarga é válida se a assinatura do método 
difere no número ou no tipo dos parâmetros.
• Diferenças no nome dos parâmetros não são 
relevantes.
• Diferenças no tipo de retorno são permitidas, mas 
não são relevantes.
© ritasuzana@dcc.ufba.br 41
Conceitos Básicos
�Herança
ִÉ o compartilhamento de atributos e 
operações entre classes baseado em uma 
relação de hierarquia
ִHierarquia
CLASSES E SUB CLASSES
ִUma subclasse herda todas as 
propriedades da sua superclasse
ִÉ adicionado suas próprias propriedades 
ou atributos
Ex: WINDOWS
• Scrolling Windows
• Fixed Windows
© ritasuzana@dcc.ufba.br 42
Conceitos Básicos
�Herança
ִum mecanismo para modelar similaridades
entre classes
ִpossibilita tornar explícitos atributos e
serviços comuns em uma hierarquia de
classes
ִpossibilita reutilização, captura explícita de
características comuns e definição
incremental de classes
© ritasuzana@dcc.ufba.br 43
Conceitos Básicos
�Herança Simples
ִquando uma subclasse herda características 
de uma única superclasse
�Herança Múltipla
ִquando uma classe é definida a partir de 
duas ou mais superclasses
ִproblema
colisão de atributos e/ou métodos
© ritasuzana@dcc.ufba.br 44
Análise Orientada a Objeto
�Sistemas concebidos e implementados em 
uma forma próxima de como a mente 
humana percebe o mundo da aplicação
�Aplicação
ִobjetos
ִinteração entre objetos distintos
ִobjetos com comportamento próprio
ִobjetos com propriedades diversas
ִcomunicação entre objetos
© ritasuzana@dcc.ufba.br 45
Análise Orientada a Objeto
�Desenvolvimento incremental e evolutivo
�Reusabilidade
�Possibilidade de incorporação de pequenas 
diferenças a elementos do sistema
ִgeneralização/especialização
�Modularidade
© ritasuzana@dcc.ufba.br 46
Análise Orientada a Objeto
�Propósito
ִDefinição de todas as classes (e os
relacionamentos e comportamento associados
a ela) que são relevantes para o problema a
ser resolvido.
© ritasuzana@dcc.ufba.br 47
Análise Orientada a Objeto
�Tarefas (fases)
• Levantamento de Requisitos
• Identificação de Classes
• Especificação de Hierarquias de Classes
• Identificação de Associações e Atributos
• Modelagem do Comportamento
• Definição das Operações
© ritasuzana@dcc.ufba.br 48
Análise Orientada a Objeto
� Fases
ִ Modelagem conceitual
ִ Projeto e Design
ִ Implementação
© ritasuzana@dcc.ufba.br 49
UML
�Unified Modeling Language
ִLinguagem de modelagem
ִNão é uma metodologia
não prescreve procedimentos de utilização
ִBaseada 
OMT
• James Rumbaugh
BOOCH
• Grady Booch
OOSE
• Jacobson 
© ritasuzana@dcc.ufba.br 50
UML
© ritasuzana@dcc.ufba.br 51
UML
�Objetivos
ִLinguagem de modelagem visual
ִExtensibilidade e especialização para apoiar 
conceitos essenciais
ִIndependente de linguagens de programação e 
processos de desenvolvimento
ִEncorajar o crescimento do número de 
ferramentas orientadas a objeto no mercado
© ritasuzana@dcc.ufba.br 52
UML 2.0
© ritasuzana@dcc.ufba.br 53
UML 2.0
�Motivação
ִApoio ao Desenvolvimento Dirigido a 
Modelos
ִDesenvolvimento Baseado em Componentes
ִ Sistemas de Tempo Real
ִMais “formalização”
OCL – Object Constraint Language
© ritasuzana@dcc.ufba.br 54
UML
�Visões
ִA documentação de um sistema pode ser 
refletida em visões distintas.
© ritasuzana@dcc.ufba.br 55
UML - Visões
�Caso de Uso 
ִComportamento do sistema através da ótica 
do usuário 
ִFuncionalidades do sistema
ִNão especifica a organização do sistema
ִPode ser especificada:
Diagrama de casos de uso
Diagramas de interação, estados e atividades
© ritasuzana@dcc.ufba.br 56
UML - Visões
�Projeto
ִVocabulário do problema e a sua solução
ִDefine o aspecto lógico e interno do sistema
ִEstrutura estática e dinâmica dos objetos
© ritasuzana@dcc.ufba.br 57
UML - Visões
� Processo
ִFoco em questões relacionadas a mecanismos de 
concorrência e sincronismo
ִTrata a divisão do sistema em processos e 
processadores:
execuções paralelas;
gerenciamento de eventos assíncronos;
comunicação e a concorrência de threads.
� Possui foco no desempenho e escalabilidade do sistema
© ritasuzana@dcc.ufba.br 58
UML - Visões
�Implementação 
ִMontagem e funcionamento do sistema físico 
ִComponentes 
ִArquivos 
�Implantação 
ִTopologia de hardware em que o sistema é 
executado
© ritasuzana@dcc.ufba.br 59
UML
�Modelagem Estrutural
ִDiagrama de Classe
ִDiagrama de Objeto
ִDiagrama de Componente
ִDiagrama de Estrutura Composta
ִDiagrama de Pacotes
ִDiagramas de Implantação
© ritasuzana@dcc.ufba.br 60UML
�Modelagem Comportamental
ִDiagrama de Caso de Uso
ִDiagrama de Seqüência
ִDiagrama de Comunicação
ִDiagrama de Tempo
ִDiagrama de Estado
ִDiagramas de Atividades
© ritasuzana@dcc.ufba.br 61
UML - Diagramas
Diagrama de
Comunicação
© ritasuzana@dcc.ufba.br 62
Diagrama de Caso de Uso
Sistema
Caso de usointeração
ator
© ritasuzana@dcc.ufba.br 63
UML
�Diagrama de Caso de Uso
ִDescreve a visão externa do sistema
ִInteração típica entre um usuário e um 
sistema
ִInterações com o mundo exterior
ִVisão de alto nível da resposta do sistema 
em relação a uma requisição do usuário
ִApresenta possíveis situações do mundo real 
para o sistema
© ritasuzana@dcc.ufba.br 64
Diagrama de Caso de Uso
�Ferramenta essencial 
ִna captura dos requisitos de um sistema
ִplanejamento e controle de projetos iterativos
� A captura dos casos de uso é a primeira atividade a 
ser realizada na fase de análise de requisitos.
� A maioria dos casos de uso será gerada durante a 
fase de análise de requisitos 
� Outros casos de uso podem ser descobertos à 
medida que o trabalho prossegue
© ritasuzana@dcc.ufba.br 65
Diagrama de Caso de Uso
� Requisitos Funcionais
ִ Requisitos do Usuário
ִ Requisitos de Sistema
� Um modelo que descreve os requisitos de um sistema através de casos 
de uso.
ִ Contrato entre o cliente e os desenvolvedores
� Uso
ִ clientes - melhor entender o sistema
ִ projetistas - base do trabalho
ִ testadores - projetar atividades de teste
ִ gerente - planejar as atividades de desenvolvimento
ִ arquiteto - identificar requisitos da arquitetura
© ritasuzana@dcc.ufba.br 66
Diagrama de Caso de Uso
� Elementos
ִAtores e Casos de Uso
ִAtor 
Agente externo que interage com o sistema.
Comunica-se com o sistema enviando e recebendo mensagens.
Pode representar: pessoas, papéis, outros sistemas, outros 
órgãos,etc...
• Mais comum
• Papel que um usuário desempenha com respeito ao sistema
Qualquer coisa que troque informação com o sistema
Leitor
© ritasuzana@dcc.ufba.br 67
Diagrama de Caso de Uso
ִElementos
Casos de uso

• Funcionalidades requeridas externamente.
• Modelam um diálogo entre um ator e o sistema
• É sempre iniciado por um ator (direta ou indiretamente).
• Deve ser completo (atômico).
• Despacha algum valor para o ator.
© ritasuzana@dcc.ufba.br 68
Diagrama de Caso de Uso
Ator1
Ator2
Caso de 
Uso1
Caso de 
Uso2
Caso de 
Uso3 ator
caso de uso
© ritasuzana@dcc.ufba.br 69
�Modelo de Caso de Uso
ִUm conjunto de casos incluídos por um limite de 
domínio
� Resumindo ...
ִ“É uma descrição de um conjunto de seqüências de 
ações, inclusive variantes, que um sistema executa 
para produzir um resultado de valor observável por 
um ator”
ִEspecifica o que o sistema irá fazer, mas não como
Diagrama de Caso de Uso
© ritasuzana@dcc.ufba.br 70
Diagrama de Caso de Uso
Marcação de Consulta 
ou exames
Consulta Médica
Encaminhamento do 
associado para exames
Coleta do Material do 
Exame
Diagnose
Associado
Credenciado
© ritasuzana@dcc.ufba.br 71
Diagrama de Caso de Uso
N Caso de Uso Quem Inicia Ação Descrição do Caso de Uso
1 Marcação de 
consultas ou 
exames
Associado
O associado entra em contato com 
o credenciado para marcar 
consultas ou exames
2 Consulta 
Médica
Associado O associado encaminha-se ao local da 
consulta e é atendido pelo 
credenciado
3 Encaminhamento do associado para 
exames
Credenciado
O credenciado encaminha o 
associado para a realização de 
exames laboratoriais
© ritasuzana@dcc.ufba.br 72
Diagrama de Caso de Uso
�Atores são externos ao sistema 
ִdefinir fronteiras entre atores e casos de uso, 
está-se delimitando o escopo do sistema
�Atores não precisam ser descritos em 
detalhes
© ritasuzana@dcc.ufba.br 73
Diagrama de Caso de Uso
�Relacionamentos entre casos de usos
ִusa (include) 
ִestende (extends) 
© ritasuzana@dcc.ufba.br 74
Diagrama de Caso de Uso
�Relacionamento usa
ִocorre quando há uma porção de 
comportamento que é similar ao longo de um 
ou mais casos de uso e não se deseja repetir 
a sua descrição
ִatividades duplicadas em outros casos de 
uso
ִum caso de uso inicia o outro
© ritasuzana@dcc.ufba.br 75
Diagrama de Caso de Uso
�Relacionamento usa - Exemplo
Comprar Itens
Pagar com Dinheiro
Pagar com Cheque
Pagar com Cartão
Cliente Caixa
<<include>>
<<include >>
<<include>>
© ritasuzana@dcc.ufba.br 76
Diagrama de Caso de Uso
�Relacionamento usa – Exemplo
N Caso de Uso Quem Inicia Ação Descrição do Caso de Uso
1 Comprar Itens Cliente O Cliente se dirige ao caixa com os itens que deseja comprar, paga, 
recebe nota e leva os itens. 
2 Pagamento 
com Dinheiro
Cliente
O cliente paga com dinheiro, o 
caixa registra a entrada da quantia 
e saída do troco.
3 Pagamento com 
Cheque Cliente
O cliente paga com cheque, o 
caixa registra informações, 
solicita autorização e registra a 
entrada da quantia.
© ritasuzana@dcc.ufba.br 77
Diagrama de Caso de Uso
�Relacionamento estende
ִquando se tem um caso de uso que é similar 
a outro, mas faz alguma coisa a mais
ִvariações de um caso de uso tais como 
tratamento de exceções
ִdescreve-se o comportamento normal em um 
caso de uso e o comportamento não usual 
em outro
© ritasuzana@dcc.ufba.br 78
Diagrama de Caso de Uso
�Relacionamento Estende-Exemplo
Aluno
Matricular Aluno
Matricular Aluno Transferido
<<extend>>
extension points
Solic.Transfer.
© ritasuzana@dcc.ufba.br 79
Diagrama de Caso de Uso
�Relacionamento Estende-Exemplo
© ritasuzana@dcc.ufba.br 80
Diagrama de Caso de Uso
�Relacionamento estende
ִdeve ser usado da seguinte forma:
Em primeiro lugar, capture o caso de uso normal,
simples;
Para cada passo neste caso de uso, pergunte:
• “O que pode andar errado aqui?” e “Como isto pode
funcionar de forma diferente?”;
Descreva todas as variações como extensões do
caso de uso dado
Pode haver um número relativamente alto de
extensões e, ao listá-las separadamente, fica mais
fácil de entender.
© ritasuzana@dcc.ufba.br 81
Diagrama de Caso de Uso
�Utilize o relacionamento estende quando
estiver descrevendo uma variação de um
comportamento normal
�Utilize o relacionamento usa quando houver 
repetição em dois ou mais casos de uso 
separados e for desejável evitar esta 
repetição
© ritasuzana@dcc.ufba.br 82
Diagrama de Caso de Uso
�Casos de uso enfocam uma particular 
funcionalidade
ִanalise da funcionalidade total do sistema de 
maneira incremental
�Casos de uso para áreas funcionalmente 
diferentes podem ser desenvolvidos 
independentemente
ִreunião posterior para formar um modelo de 
requisitos completo
�Desenvolvimento em paralelo
© ritasuzana@dcc.ufba.br 83
Diagrama de Caso de Uso
�Uma vez que a funcionalidade do sistema 
tiver sido capturada nos casos de uso, ela 
deve ser alocada a diferentes classes
ִUma classe pode ser comum a diversos 
casos de uso
© ritasuzana@dcc.ufba.br 84
UML - Diagrama de Classe
�Após a análise de requisitos
�Modelo cerne
�A identificação das classes é uma tarefa 
crucial para o desenvolvimento de um 
sistema OO
© ritasuzana@dcc.ufba.br 85
Diagrama de Classe
�Diagrama de Classe
ִEstrutura estática do sistema
ִDefinição de Classes
Atributos
Métodos
© ritasuzana@dcc.ufba.br 86
Diagrama de Classe
�Identificação das classes do sistema
• Estude o domínio de aplicação;
• Faça uma observação geral no ambiente real onde
existe o problema;
• Procure ouvir atentamente os especialistas do
domínio do problema;• Verifique, se existirem, resultados de AOOs
anteriores em domínios semelhantes;
• Observe outros sistemas no mesmo domínio ou
em domínios similares;
• Consulte fontes bibliográficas
© ritasuzana@dcc.ufba.br 87
Diagrama de Classe
�Observe os seguintes elementos
ִobjetos físicos ou conceituais que formam 
uma abstração coesa
sistema precisa manipular informações
ִoutros sistemas e “terminadores externos” 
que se comunicam ou interagem com o 
sistema 
• informações estão sendo trocadas;
ִdispositivos físicos com os quais o sistema 
em estudo terá de interagir
sem considerar a tecnologia para implementar o 
sistema em si
© ritasuzana@dcc.ufba.br 88
Diagrama de Classe
�Potenciais candidatos a classes 
• coisas que são parte do domínio de informação do
problema;
• ocorrências ou eventos que precisam ser
registrados e lembrados pelo sistema;
• papéis desempenhados pelas diferentes pessoas
que interagem direta ou indiretamente com o
sistema;
• locais físicos ou geográficos e lugares que
estabelecem o contexto do problema;
• unidades organizacionais (departamentos,
divisões, etc...) que possam ser relevantes para o
sistema.
© ritasuzana@dcc.ufba.br 89
UML - Classes
�Exemplos
Professor
nome: String
titulação:integer
altera-gratificação ( ): Real
Professor Professor
nome: String
titulação:integer
© ritasuzana@dcc.ufba.br 90
UML - Diagrama de Classes
�Generalização / Especialização
Pessoa
EstudanteProfessor Técnico
Pessoa
EstudanteProfessor Técnico
© ritasuzana@dcc.ufba.br 91
UML - Diagrama de Classes
�Generalização/Especialização
ִExemplos
Pessoa
EstudanteProfessor Técnico
{disjunta, incompleta}
© ritasuzana@dcc.ufba.br 92
UML - Diagrama de Classes
�Generalização/Especialização
ִClasse Abstrata
Uma classe que não possui instâncias
ִClasse Concreta
Uma classe que é diretamente instanciada
© ritasuzana@dcc.ufba.br 93
UML - Diagrama de Classes
�Herança Múltipla
ִUma classe pode possuir mais de uma 
superclasse e herdar características de todas 
estas classes
ִClasse de junção
classe com mais de uma superclasse
© ritasuzana@dcc.ufba.br 94
UML - Diagrama de Classes
�Herança Múltipla
ִExemplo
Veículo
Veículo
Terrestre
Veículo 
Aquático
Carro VeículoAnfíbio Barco
© ritasuzana@dcc.ufba.br 95
UML - Diagrama de Classes
�Diretrizes podem ser usadas analisar as 
hierarquias modeladas
• modelam relações “é-um-tipo-de”
• toda subclasse deve ser um tipo específico das suas
superclasses.
• uma subclasse deve suportar toda a
funcionalidade (atributos, relacionamentos e
operações) definida por suas superclasses, e
possivelmente mais.
• a funcionalidade comum a diversas classes deve
ser posicionada o mais alto possível na hierarquia.
• Classes abstratas não podem herdar de classes
concretas.
• Classes que não adicionam funcionalidade devem 
ser eliminadas. 
© ritasuzana@dcc.ufba.br 96
UML - Diagrama de Classes
�Se uma classe é dita sub-classe de outra
ִ todas as instâncias da sub-classe têm de ser 
também, por definição, instâncias da super-
classe.
ִTudo que válido para a super-classe
(relacionamentos, atributos e operações) têm
de ser válido também para a sub-classe
© ritasuzana@dcc.ufba.br 97
UML - Diagrama de Classes
�Associação
ִRelacionamento estrutural
ִ“Conexão” entre objetos
ִDescreve um conjunto de ligações em 
potencial
Professor ensina Disciplina
© ritasuzana@dcc.ufba.br 98
UML - Diagrama de Classes
�Associação - Grau
Disciplina
requer
Professor ensina Disciplina
Professor Sala de Aula
Disciplina
ensina-em
© ritasuzana@dcc.ufba.br 99
UML - Diagrama de Classes
�Associação - Multiplicidade
0..1 - a cardinalidade pode ser 0 ou 1;
1 - a cardinalidade só pode ser 1;
0..* - a cardinalidade pode variar de 0 até infinito;
* - a cardinalidade pode variar de 0 até infinito;
1..* - a cardinalidade pode variar de 1 até infinito;
1..6 - a cardinalidade pode variar de 1 até 6;
1..3,7..10,15,19..* - a cardinalidade pode ser 1, 2, 3, 7,
8, 9, 10, 15, e a partir de 19 até infinito.
© ritasuzana@dcc.ufba.br 100
UML - Diagrama de Classes
ensina Disciplina1 1..*Professor
�Multiplicidade - Exemplo
© ritasuzana@dcc.ufba.br 101
UML - Diagrama de Classes
�Papel
ִIdentifica a função exercida por um objeto 
em uma associação.
ִÉ uma extremidade de uma associação
Trabalha-Para
Pessoa Empresa
Empregado Empregador
0..*1
© ritasuzana@dcc.ufba.br 102
UML - Diagrama de Classes
�Associação – Navegabilidade
ִComo é possível chegar em um objeto a 
partir de outro
ִPor padrão associações são bidirecionais
 Ambas classes sabem do seu relacionamento 
com a outra
© ritasuzana@dcc.ufba.br 103
UML - Diagrama de Classes
�Associação Bidirecional
Vôo
Aeronave
-vooAssociado
-aeronaveAssociado
0..*
0..1
© ritasuzana@dcc.ufba.br 104
UML - Diagrama de Classes
�Associação Unidirecional
ִMostra que as classes são relacionadas, mas 
que só uma delas está ciente desta relação
ִContêm apenas um nome de papel, um valor 
de multiplicidade e um atributo de visibilidade
© ritasuzana@dcc.ufba.br 105
UML - Diagrama de Classes
� Associação Unidirecional
© ritasuzana@dcc.ufba.br 106
UML - Diagrama de Classes
�Associação Unidirecional
RelatorioVôoOverbook
Vôo
-vooOverbook
0..*
© ritasuzana@dcc.ufba.br 107
UML - Diagrama de Classes
�Ordenação
ִNo relacionamento 1:N ou N:M existe uma 
ordenação entre os elementos
ִNão especifica como a ordenação é 
estabelecida
Janela Tela
visível
{ordenadas}
11..*
© ritasuzana@dcc.ufba.br 108
titulação: String
avaliação: Integer
UML - Diagrama de Classes
�Classe de Associação / Relacionamento
� Quando um relacionamento entre classes 
possui atributos ou outras informações 
necessárias
Professor Estudante*1..*
Orientação
© ritasuzana@dcc.ufba.br 109
UML - Diagrama de Classes
�Agregação
ִum objeto é composto por outros objetos
ִdefine a relação “é parte de”
Laboratório Equipamento
1..*1
© ritasuzana@dcc.ufba.br 110
UML - Diagrama de Classes
�Agregação Composição
ִTipo mais forte de agregação
ִObjetos agregados dependem fortemente 
objeto agregador
ִSó existem enquanto o objeto agregador 
existir
parágrafo frase1..*1
© ritasuzana@dcc.ufba.br 111
UML - Diagrama de Classes
�Agregação Composição
ִTempo de vida vinculados
ִOs objetos que fazem parte do composto 
e são criados após o composto e são 
destruídos junto com o composto
ִObjeto agregado só pode fazer parte de 
um agregador em um determinado 
momento
parágrafo frase1..*1
© ritasuzana@dcc.ufba.br 112
UML - Diagrama de Classes
�Agregação Composição
ִNo “Baixo nível”
Agregação Simples
• Termos de passagem por parâmetro, seria uma 
passagem por valor. 
Agregação Composição
• Passagem por referência.
• O todo contém as partes (e não referências para as 
partes). Quando o todo desaparece, todas as partes 
também desaparecem. 
© ritasuzana@dcc.ufba.br 113
UML - Diagrama de Classes
public class A {
private B b;
public A( ){
b = new 
B();
}
}
public class B {
public B( ){
}
}
�Agregação Composição
© ritasuzana@dcc.ufba.br 114
UML - Diagrama de Classes
�Intefaces
ִColeção de operações
ִEspecificam serviço de uma classe ou 
componente
ִComportamento externo e visível
Assinatura das operações IJanela
abrir()
fechar()
mover()
exibir()
IJanela
abrir()
fechar()
mover()
exibir()
<<Interface>>
© ritasuzana@dcc.ufba.br 115
UML - Diagrama de Classes
�Interfaces
ִRepresentação através de classe 
estereotipada(<<interface>>) ou por um 
círculo.
ִPodem participar de associações, 
generalizações e dependências.
© ritasuzana@dcc.ufba.br 116
UML - Diagrama de Classes
�Dependência
ִRelacionamento de utilização
ִEspecifica que a alteração em um item 
poderá afetar o outro que o utiliza
ִRepresentada por uma seta com linha 
tracejada
DeclaracaoIR Calculadora
usa
1 1
© ritasuzana@dcc.ufba.br 117
UML - Diagrama de Classes
�Perspectivas
ִConceitual 
Representa os conceitos do domínio em estudo. 
Perspectiva destinada ao cliente.
ִEspecificação 
Tem foco nos principais aspectos da arquitetura, nos 
principais métodos.
• Foco no o que e não como eles irão ser implementados. 
Perspectiva destinada as pessoas que não precisam saber 
detalhes de desenvolvimento.
• Tais como gerentes de projeto
© ritasuzana@dcc.ufba.br 118
UML - Diagrama de Classes
�Implementação
ִ Vários detalhes de implementação
Navegabilidade, tipo dos atributos, etc.
ִPerspectiva destinada ao time de
desenvolvimento.
UML – Diagrama de Pacotes
Se um sistema é composto de uma 
quantidade pequena de classes, é fácil 
gerenciá-las
Sistemas grandes podem ser compostos 
por centenas de classes
Nestes casos é necessário um 
mecanismo para agrupá-las de modo a 
facilitar a sua utilização e manutenção© ritasuzana@dcc.ufba.br 119
© ritasuzana@dcc.ufba.br 120
UML – Diagrama de Pacotes
�Pacotes 
ִsão mecanismos de propósito geral para 
organizar elementos em grupos. 
ִElemento de um modelo que pode conter 
outros elementos do modelo.
ִAgrupam logicamente classes e outros 
pacotes.
Artefatos de 
Controle
© ritasuzana@dcc.ufba.br 121
UML – Diagrama de Pacotes
� Visão de alto nível 
�Pacotes possuem uma interface pública, que 
é realizada por suas classes componentes
Artefatos da
GUI
Artefatos de
Controle
© ritasuzana@dcc.ufba.br 122
UML- Diagrama de Interação
Evento de saída
(resposta)
Objeto 1 Objeto 2
mensagem
Ator Ator
Evento de entrada
(estímulo)
Tempo
�Descrevem como grupos de objetos 
colaboram em um certo comportamento 
interno do sistema
© ritasuzana@dcc.ufba.br 123
UML- Diagrama de Interação
�O fluxo de execução de um cenário é
capturado através de diagramas de
interações
ִDiagrama de Sequência
ִDiagrama de Comunicação
© ritasuzana@dcc.ufba.br 124
Diagramas de Interação
�Diagramas de Seqüência
ִÊnfase na ordenação temporal de 
mensagens
�Diagramas de Comunicação
ִÊnfase nas mensagens trocadas por objetos 
relacionados 
© ritasuzana@dcc.ufba.br 125
UML- Diagrama de Seqüência
�Comportamento dos objetos em um sistema
ִExibe as classes e objetos que participam de
um cenário
ִExibe as mensagens trocadas pelos
participantes para possibilitar a
funcionalidade no cenário
Seqüência temporal de mensagens
© ritasuzana@dcc.ufba.br 126
UML- Diagrama de Seqüência
�Notação para objetos
© ritasuzana@dcc.ufba.br 127
UML- Diagrama de Seqüência
�Componentes
Classe-1 Classe-2
[condição]
* msg()
descrição textual do 
que está 
acontecendo.
...
© ritasuzana@dcc.ufba.br 128
UML- Diagrama de Seqüência
�Nível mais detalhado 
© ritasuzana@dcc.ufba.br 129
UML- Diagrama de Seqüência
�Nível elementar
© ritasuzana@dcc.ufba.br 130
UML - Diagrama de Seqüência
�Mensagem Reflexiva
ִAutomensagem
Remetente é também o receptor.
Corresponde a uma mensagem para this 
(self). 
© ritasuzana@dcc.ufba.br 131
UML - Diagrama de Seqüência
�Mensagem criação
© ritasuzana@dcc.ufba.br 132
UML - Diagrama de Seqüência
�Mensagem exclusão
© ritasuzana@dcc.ufba.br 133
UML - Diagrama de Seqüência
�Exemplo
 : cliente Solicitação_Pedido Pedido Itens de Estoque
Item Pedido
solicita_pedido(dados_cliente, lista de i tens)
inclui_pedido(numero,data,dados_cliente)
verifica_itens_estoque(item, qtd)
inclui_item_pedido(item_estoque)
atualiza_estoque(item,qtd)
© ritasuzana@dcc.ufba.br 134
UML - Diagrama de Seqüência
�Exercício
ִAlterar o diagrama anterior
© ritasuzana@dcc.ufba.br 135
UML - Diagrama de Comunicação
�Colaboração
ִvisão de um conjunto de elementos de 
modelagem
ִpropósito particular
ִInteração organizada em torno de objetos
© ritasuzana@dcc.ufba.br 136
UML - Diagrama de Comunicação
�Componentes
: Nome_classe_2
1*: [condição] msg()
: Nome_classe_1
© ritasuzana@dcc.ufba.br 137
UML - Diagrama de Comunicação
funcionário
pedido
Item de 
pedido
Item de 
estoque
Item de 
entrega
1: preparar pedido
2:incluir itens
3: remover
4:atualizar pedido
© ritasuzana@dcc.ufba.br 138
Diagrama Seqüência versus 
Diagrama de Comunicação
�Ambos expressam informações semelhantes 
porém de maneira diferente
�Diagrama de Colaboração
ִrelacionamento entre objetos
ִtempo é uma dimensão separada
�Diagrama de Seqüência
ִseqüência explícita das mensagens
© ritasuzana@dcc.ufba.br 139
UML - Modularização das Interações
� Embora ainda sejam válidos na UML 2.0, os elementos de controle 
(condição e iteração) foram parcialmente substituídos por outros 
elementos na UML 2.0:
ִ Quadros de interação
ִ Fragmentos combinados
ִ Operadores de Interações
ִ Quadro de interação (interaction frame)
� Fornecem um contexto no interior do qual pode-se posicionar os 
elementos dos diagramas de interação.
� Elemento gráfico que serve para modularizar a construção de 
diagramas de seqüência e comunicação
© ritasuzana@dcc.ufba.br 140
UML - Modularização das Interações
�Quadros e Fragmentos
ִObjetivos específicos:
 Dar um nome ao diagrama que aparece dentro 
do quadro;
 Fazer referência a um diagrama definido 
separadamente;
 Definir o fluxo de controle da interação.
© ritasuzana@dcc.ufba.br 141
UML - Modularização das Interações
�Digramas Nomeados
ִNome do diagrama
Na UML 2.0 todo diagrama de interação pode ser 
posicionado dentro de um quadro
 A orelha do quadro deve conter uma expressão 
da forma:
• TipoDiagrama NomeDiagrama
– Onde TipoDiagrama pode ser:
– sd - para diagramas de sequência
– comm – para diagramas de comunicação
– activity – para diagramas de atividades
© ritasuzana@dcc.ufba.br 142
UML - Modularização das Interações
�Exemplo Geral
© ritasuzana@dcc.ufba.br 143
UML - Modularização das Interações
�Referencias a Diagramas
ִA orelha de um quadro pode também servir para
indicar que este corresponde a uma ocorrência de
interação
ִ Graficamente:
 é um quadro rotulado com a palavra-chave ref
 o nome da interação é posicionado no interior do quadro
ִPode ser usada para fatorar interações comuns a
vários diagramas em um único quadro e reutilizar o
quadro várias vezes
© ritasuzana@dcc.ufba.br 144
UML - Modularização das Interações
�Referências Exemplos
© ritasuzana@dcc.ufba.br 145
UML - Modularização das Interações
�Fluxo de controle
ִPermite definir a lógica procedimental (fluxo de
controle) nos diagramas de interação
Fragmento combinado: graficamente corresponde a uma
ou mais interações (sequências de mensagens) encapsuladas
em um quadro
 Operador de interação é representado na orelha do quadro
correspondente ao fragmento
 Operandos do fragmento (que são as
interações)posicionados dentro do quadro
ִ Se houver mais de um operando, são separados por
uma linha tracejada
© ritasuzana@dcc.ufba.br 146
UML - Modularização das Interações
�Composição interna de um fragmento
combinado:
ִ Um ou mais operandos de interação
ִ Zero ou mais condições de guarda (restrição
da interação)
ִ Um operador de interação
© ritasuzana@dcc.ufba.br 147
UML - Modularização das Interações
�Exemplo– Fluxo de controle
© ritasuzana@dcc.ufba.br 148
UML - Modularização das Interações
�Possíveis operadores de interação.
ִ “alt” (alternativa)
 modela construções do tipo se-então-senão dos
operandos definidos com alt, apenas um é executado
ִ “opt” (opção)
 modela a construção do tipo se-então similar ao alt,
porém associado a apenas um operando
ִ “loop” (iteração) representa que o operando deve
ser executado zero ou mais vezes após o nome do
operador é possível representar oslimites mínimo e
máximo do número de iterações
 Sintaxe: loop [(<minint>[,<maxint>])]; * indefinido
© ritasuzana@dcc.ufba.br 149
UML - Modularização das Interações
�Exemplo alt
© ritasuzana@dcc.ufba.br 150
UML - Modularização das Interações
�Exemplo opt
© ritasuzana@dcc.ufba.br 151
UML - Modularização das Interações
�Exemplo interações
© ritasuzana@dcc.ufba.br 152
UML - Modularização das Interações
© ritasuzana@dcc.ufba.br 153
UML - Diagrama de Estado
�Descrevem o comportamento de um sistema
ִpara cada classe
ִmostrar o comportamento ao longo do 
tempo de vida de um objeto
© ritasuzana@dcc.ufba.br 154
UML - Diagrama de Estado
�Componentes
Estado-1
faça: atividade-A1
Evento [Condição] / Ação
Estado-2
© ritasuzana@dcc.ufba.br 155
�Estado
ִabstração dos valores dos atributos de um 
objeto
ִum estado ocupa uma duração no tempo
ִa resposta de um objeto para um evento 
depende dos valores dos seus atributos no 
momento
UML - Diagrama de Estado
© ritasuzana@dcc.ufba.br 156
Diagrama de Estado
�Estado (cont)
ִa resposta de um objeto para um evento 
depende dos valores dos seus atributos no 
momento
ִé normalmente associada a uma atividade 
continua
fax chamando
alterando pedido
registrando pedido
© ritasuzana@dcc.ufba.br 157
Diagrama de Estado
�Nome: deve descrever claramente o estado;
�Atividades:
ִDe entrada: ocorrem ao entrarmos no 
estado;
ִDe saída: ocorrem ao saírmos do estado;
ִConvencional: ocorrem enquanto o objeto 
estiver naquele estado.
© ritasuzana@dcc.ufba.br 158
Diagrama de Estado
�Evento
ִOcorrência relevante para o sistema com 
localização no tempo e espaço
ִEstímulo de um objeto para o outro
ִeventos podem ser concorrentes
ִeventos precedem ou sucedem outros 
eventos
ִpodem conter informações
© ritasuzana@dcc.ufba.br 159
Diagrama de Estado
�Evento (cont)
ִÉ uma transmissão unidirecional de um 
objeto para outro
ִExemplos
partida de aviões
• empresa aérea, número do vôo, cidade
botão do mouse apertado
telefone levantado
solicitação de pedido
© ritasuzana@dcc.ufba.br 160
Diagrama de Estado
�Estados e eventos se complementam
ִo estado especifica a resposta do objeto 
para eventos de entrada
ִum estado corresponde a um intervalo de 
tempo entre dois eventos
© ritasuzana@dcc.ufba.br 161
Diagrama de Estado
�Resumindo
© ritasuzana@dcc.ufba.br 162
Diagrama de Estado
FAX EMPRESA
ocioso
discando chamando
digito n
Aciona o fax
Emitindo tom 
discagem
Primeiro Dígito
sinal de chamada
recebendo 
sinal fax
sinal do fax cliente
Enviando
documento
documento
Deslig
a
Final do documentoAguardando
novo 
documento
documento
desconectado
© ritasuzana@dcc.ufba.br 163
Diagrama de Estado
�Mais um exemplo
© ritasuzana@dcc.ufba.br 164
UML – Diagrama de Atividades
� Gráfico de Fluxo
ִFluxo de controle de uma atividade para outra
�Modelagem de Etapas de um processo 
computacional
ִSequenciais
ִConcorrentes
© ritasuzana@dcc.ufba.br 165
UML – Diagrama de Atividades
�Atividade
ִExecução não atomica em andamento em um 
máquina de estados.
ִTrabalho ou tarefa a ser realizada
Passos em um workflow
Execução de uma operação
ִSeqüenciais ou concorrentes.
ִResultam em ações
Computações atômicas executáveis
• Mudanças de estado
• Resultado de valor
© ritasuzana@dcc.ufba.br 166
UML – Diagrama de Atividades
�Componentes
ִEstados
Atividade
Ação
ִTransições
ִObjetos
© ritasuzana@dcc.ufba.br 167
UML – Diag. de Atividades
�Componentes
ִEstados
Atividades
Ação
ִTransições
ִObjetos
�Exemplo
ִConstrução de uma casa
Estado Inicial
Estado Final
EstadoAção/Atividade
Ramificação 
Sequencial
Bifurcação 
Concorrente
União Concorrente
© ritasuzana@dcc.ufba.br 168
UML – Diagrama de Atividades
�Estados de Ação
ִSão atômicos e não podem ser decompostos
ִTempo de execução NÃO é relevante
© ritasuzana@dcc.ufba.br 169
UML – Diagrama de Atividades
�Estado de Atividade
ִNão são atômicos e podem ser decompostos
ִTempo de execução um tanto quanto 
relevante
© ritasuzana@dcc.ufba.br 170
UML – Diagrama de Atividades
�Raias
© ritasuzana@dcc.ufba.br 171
UML - Diagramas de Implantação
�Descreve o hardware e o software que 
implementam o sistema
ִmapeamento da arquitetura lógica de 
classes para uma arquitetura física
componentes
nós de processamento
comunicação entre nós
�Diagrama de Componente
�Diagrama de Implantação
© ritasuzana@dcc.ufba.br 172
UML - Diagrama de Componente
�Modela os componentes do sistema e dependências 
entre eles.
�Elementos de Modelagem
ִcomponente
unidade de software usada para compor o sistema;
ִinterface
conjunto de operações suportado (realizado) por um 
componente;
cada componente pode prover múltiplas interfaces;
componentes podem utilizar (depender) interfaces de outros 
componentes.
© ritasuzana@dcc.ufba.br 173
UML - Diagrama de Componente
Pedido.exe Estoque.exe
Pedido.cls
© ritasuzana@dcc.ufba.br 174
Diagrama de Implantação
�Descreve o arranjo de componentes executáveis em 
nós de execução.
ִPermite avaliar conseqüências da distribuição e 
alocação de recursos.
ִSão apresentados em dois níveis:
Descritivo (geral);
De instância (específico).
ִNó
Recurso computacional (tempo de execução)
• Computadores, memória, dispositivos periféricos.
© ritasuzana@dcc.ufba.br 175
Diagrama de Implantação
�Nível descritivo (geral)
ִDescreve os elementos contidos em cada nó.
ִEspecifica as dependências entre elementos 
(possivelmente em nós distintos).
ִPadrão de comunicação entre nós.
© ritasuzana@dcc.ufba.br 176
Diagrama de Implantação
nódependência
comunicação
© ritasuzana@dcc.ufba.br 177
Diagrama de Implantação
�De Instância (específico)
ִApresenta instâncias de nós, e comunicação efetiva entre 
eles.
ִApresenta os nós para uma versão/configuração especifica 
do sistema.
Nó
Comunicação
© ritasuzana@dcc.ufba.br 178
Projeto Orientado a Objeto
�Análise Orientada a Objetos
ִidentifica e define 
classes que refletem diretamente o domínio do 
problema 
responsabilidades do sistema
�Projeto Orientado a Objetos
ִtransforma o modelo de análise em um 
modelo de projeto 
ִserve de base para a construção do software
© ritasuzana@dcc.ufba.br 179
Projeto Orientado a Objeto
�Decisões estratégicas de alto nível
�Dependente de aspectos:
ִcaracterísticas da linguagem de programação a ser 
utilizada
ִmodelo de persistência de objetos
ִcaracterísticas da plataforma de implementação
ִcaracterísticas da interface com o usuário
ִModularização do projeto em subsistemas
ִEstrutura de comunicação e controle entre os 
subsistemas 
ִInterfaces entre subsistemas 
 possibilitar o trabalho paralelo de desenvolvimento 
© ritasuzana@dcc.ufba.br 180
Projeto Orientado a Objeto
�Identifica e define classes adicionais
ִrefletem os requisitos de implementação
�Diagramas da fase de análise
ִutilizados para capturar os requisitos de 
implementação
�UML não especifique explicitamenteque 
notações destes diagramas
ִDiagrama de Componente
ִDiagrama de Implantação
© ritasuzana@dcc.ufba.br 181
Projeto Orientado a Objeto
�Projeto da Arquitetura do Sistema
ִdescreve subsistemas
ִcomunicações entre eles
�Projeto de Objetos
ִdescreve aspectos de implementação de 
cada uma das classes 
ִprojeto procedural de cada operação
ִdefinição de classes internas
ִprojeto de estruturas de dados para os 
atributos das classes
© ritasuzana@dcc.ufba.br 182
Projeto da Arquitetura
�Uma estrutura elegante pode 
freqüentemente ser elaborada usando 
camadas e partições
�Camada 
ִé um subsistema que adiciona valor a 
subsistemas de menor nível de abstração 
�Partição 
ִé um subsistema "paralelo" a outros 
subsistemas 
© ritasuzana@dcc.ufba.br 183
Projeto da Arquitetura
�Camadas e Partições
© ritasuzana@dcc.ufba.br 184
Projeto da Arquitetura
�Sistemas de informação 
ִNormalmente incluem uma interface com o 
usuário e persistência (quase todos!)
ִ Arquitetura em 3 camadas 
(3-tier architecture) 
© ritasuzana@dcc.ufba.br 185
Projeto da Arquitetura
�Arquitetura em Três Camadas
© ritasuzana@dcc.ufba.br 186
Projeto da Arquitetura
�Arquitetura em Três Camadas
ִApresentação
Trata toda a interface com o usuário
 Janelas, relatórios, etc. 
Também chamada
• Camada de Interface com o Usuário
• Camada de Serviços do Usuário
© ritasuzana@dcc.ufba.br 187
Projeto da Arquitetura
�Arquitetura em Três Camadas (cont)
ִ Lógica da Aplicação
 Tarefas e regras que governam o processo
 Domínio do problema 
Também chamada 
• Camada de Aplicação
• Camada de Serviços de Aplicação 
• Negócios
© ritasuzana@dcc.ufba.br 188
Projeto da Arquitetura
�Arquitetura em Três Camadas (cont)
ִ Dados
 Mecanismo de armazenamento persistente 
Também chamada 
• Camada de Gerência de Dados
• Camada de Serviços de Dados
• Camada de Armazenamento
© ritasuzana@dcc.ufba.br 189
Projeto da Arquitetura
�Arquitetura em Três Camadas (cont)
ִO que vai em cada camada pode mudar 
ligeiramente
ִExemplo
lógica de aplicação na camada de dados usando 
Stored Procedures (bom)
lógica de aplicação na camada de apresentação 
usando linguagens de scripts(?)
© ritasuzana@dcc.ufba.br 190
Projeto da Arquitetura
�Por que uma arquitetura em 3 camadas? 
ִAproveitamento dos PCs da empresa e oferecer 
sistemas com interface gráficas amigáveis e 
integradas ao desktop 
ִOs primeiros sistemas cliente-servidor
 Duas camadas 
Juntando as camadas de apresentação e de aplicação
Problemas
• Falta de escalabilidade (conexões a bancos de dados) 
• Enormes problemas de suporte (mudanças à lógica de 
aplicação forçava instalações) 
• Nenhum suporte a Thin Clients (PDA, celulares, smart cards, 
quiosques, ...) 
• Dificuldade de acessar fontes heterogêneas (legado CICS, 
3270, ...) 
• Dificuldade de criar software reutilizável para rodar em clientes 
© ritasuzana@dcc.ufba.br 191
Projeto da Arquitetura
�A arquitetura em 3 camadas permite: 
ִUsar o browser como cliente universal
 levando ao conceito de Intranet 
ִEvitar instalação em computadores de 
clientes, parceiros, fornecedores, etc. 
ִImplementar serviços automáticos de 
persistência, gerência de transações, 
balanceamento de carga,etc.
© ritasuzana@dcc.ufba.br 192
Projeto da Arquitetura
�UML provê o conceito de package para 
agrupar elementos 
�Este mecanismo pode ser utilizado para 
evidenciar os subsistemas e suas 
dependências 
© ritasuzana@dcc.ufba.br 193
Projeto da Arquitetura
�A arquitetura em camadas pode ser 
representada em UML:
© ritasuzana@dcc.ufba.br 194
Projeto Orientado a Objeto
�Projeto de Objetos
ִum projeto detalhado dos atributos e das 
operações que compõem cada classe
ִespecificação das mensagens que conectam 
as classes com seus colaboradores
ִespecificação dos métodos
© ritasuzana@dcc.ufba.br 195
Conclusão
�Paradigma da Orientação a Objeto
ִRealidade
ִSistemas Distribuídos (objetos distribuídos)
ִSistemas Hipermídia
�UML 2.0 
ִUm passo além 
�Maior necessidade de modelagem
ִMaior complexidade do ambiente
�Problemas de décadas continuam
ִausência da modelagem