Sistemas Distribuídos
Projeto de Sistemas
Distribuídos
Especialização em Redes de
Computadores
Prof. Fábio M. Costa
Instituto de Informática - UFG
Visão Geral
• Evolução da Tecnologia de Objetos
• Uso de UML no Projeto de Objetos
Distribuídos
• Um Meta-Modelo para Objetos Distribuídos
• Objetos Locais X Objetos Remotos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
2
Evolução da Tecnologia de
Objetos Distribuídos
Uma Breve História de Objetos
Time
DCOM
CORBA
Java
UML
COM
OOAD
1990
Eiffel
DCE
C++
1980
Sun ONC
1970
Original: Wolfgang Emmerich, 2000
Smalltalk
Information Hiding
Simula-67
Prof. Fábio M. Costa - Instituto de Informática / UFG
4
Uso de UML no Projeto de
Objetos Distribuídos
Motivação
• No início dos anos 90: cerca de 10 notações para o
desenvolvimento orientado a objetos
• Usadas para expressar as características de objetos:
– propriedades estáticas e dinâmicas
– propriedades de tipos e instâncias de objetos
• Em 96/97: Unificação das três principais notações
(Booch, Rumbaugh, Jacobson)
• Em Nov/97: Adoção como um padrão do OMG
• Padrão hoje dominante na indústria
• Adequado para o design de objetos distribuídos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
6
UML
• Várias notações em um único padrão
• Cada notação utiliza um tipo de diagrama
apropriado para modelar um sistema de
objetos a partir de um certo “ponto de vista”
–
–
–
–
–
–
Diagramas de Casos de Uso
Diagramas de Seqüência
Diagramas de Classe
Diagramas de Pacotes
Diagramas de Objetos
Diagramas de Estados
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
7
Diagramas de Casos de Uso
Treinador
Planejar Escala
de Treinos
caso de uso
ator
Determinar Jogos
do Campeonato
Federação Nacioal
de Futebol
Técnico
Jogador
Original: Wolfgang Emmerich, 2000
Imprimir Escala
Pessoal
limites do
sistema
Prof. Fábio M. Costa - Instituto de Informática / UFG
8
Diagramas de Seqüência
chamada
mensagem (remota) de
síncrona procedimento
Tony:Trainer
BvB:Team
bookGoalies
Teddy:Player
Nome Objeto Tipo
Stefan:Player :Output
book()
book()
printTrainingPlan
ativação do
objeto
Original: Wolfgang Emmerich, 2000
linha de
tempo
mensagem
assíncrona
destruição
do objeto
Prof. Fábio M. Costa - Instituto de Informática / UFG
9
Diagramas de Classes
Organization
protegido
#name:string
dependência
generalização
agregação
Club
-noOfMembers:int 1
-location:Address
+transfer(p:Player)
1..*
works for
Trainer
-name:string
uses
cardinalidade
1..*
composição
associação
1..*
nome da classe
Player
atributos
Team
plays in -name:string
privado
-role:Position
-name:string
público
1
11..16 -Number:int
+bookGoalies()
operações
+book()
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática
/ UFG
10
Diagrama de Pacotes
Soccer
Clubs
League
Management
National
Team
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
11
Diagrama de Objetos (Instâncias)
Nome do Objeto
Nome do
Atributo
Tipo do Objeto
spurs:Team
name = “Tottenham Hotspurs”
Ligação
klinsi:Player
name=“Jürgen Klinsmann”
role=Forward
Number = 18
Original: Wolfgang Emmerich, 2000
Objeto
Valor do
Atributo
stefan:Player
name = “Stefan Freund”
role = Defender
Number=4
Prof. Fábio M. Costa - Instituto de Informática / UFG
12
Diagramas de Estado
in team
ação durante transição
healthy
estado
composto
in match
estado
playing
/swap
/swap
[!in_squad]
/play
/injury
reserve
injured
[!in_squad]
/play
transição
/recovered
/finish
condição
/finish
free
training
/exercise
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
indica
estado
default 13
Composição de Estados em
Paralelo
Player
/unsatisfaction
happy
/sign_contract
on transfer
list
threads
concorrentes
/resign
in team
Original: Wolfgang Emmerich, 2000
estado
final
Prof. Fábio M. Costa - Instituto de Informática / UFG
14
Um Meta-Modelo para
Objetos Distribuídos
Motivação
• Sistemas distribuídos consistem de
múltiplos componentes
• Componentes são heterogêneos...
• ...Mas precisam ser interoperáveis
• Deve haver um modelo comum para
componentes que expresse:
– os estados dos componentes
– os serviços oferecidos pelos componentes
– as interações entre componentes
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
16
A Abordagem O-O para Sistemas
Distribuídos
Conceitos Genéricos
Modelo Orientado a Objetos
Componentes
Objetos
Estado visível dos
componentes
Atributos dos objetos
Serviços providos pelos
componentes
Interações entre
componentes
Falhas de serviço dos
componentes
Original: Wolfgang Emmerich, 2000
operações dos objetos
(interface)
Requisições para execução de
operações
Exceções
Prof. Fábio M. Costa - Instituto de Informática / UFG
17
Necessidade de um MetaModelo de Objetos
• Há múltiplas abordagens orientadas a objetos
• O middleware de distribuição deve definir
um modelo de objetos que possa servir como
uma base comum para componentes
heterogêneos
• Um modelo genérico de objetos distribuídos
que captura as características comuns entre
os modelos de objetos de diferentes
plataformas de middleware
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
18
Diferentes Níveis de Abstração
Original: Wolfgang Emmerich, 2000
Meta-Object
Facility
Level 3
Meta Object
Model
Level 2
Object
Types
Level 1
Objects
Level 0
Prof. Fábio M. Costa - Instituto de Informática / UFG
19
Objeto
• Possui um identificador único
• Pode haver múltiplas referências diferentes que
apontam para um mesmo objeto
– Referência de objeto
– Usadas por clientes para se referirem ao objeto
• Possui um conjunto de atributos denotando valores
de dados mantidos pelo objeto  estado do objeto
• Relações de equivalência entre referências de
objeto
– Objetos iguais (encapsulam os mesmos dados)
– Objetos idênticos (mesmo objeto)
• Acesso ao estado do objeto: via operações
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
20
Exemplo de Objeto
klinsi:Player
name = “Jürgen Klinsmann”
role = Forward
Number = 18
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
21
Tipo de Objeto
• Define as propriedades de um objeto que
são exportadas para outros objetos (clientes)
– Atributos, operações, exceções
• Múltiplos objetos podem exportar as
mesmas propriedades
– Possuem o mesmo tipo
• Definição de tipo feita apenas uma vez
– Instanciação cria objetos com as propriedades
definidas no tipo
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
22
Atributos
• Definidos por meio de um nome e um tipo
• Tipo de atributo: tipo de objeto ou tipo
elementar (não-objeto)
• Atributos podem ou não ser visíveis a outros
objetos
• Um atributo pode ou não ser modificável por
outros objetos
• Acesso a um atributo: via operações
– get: obtém o valor atual do atributo
– set: altera o valor do atributo
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
23
Exceções
• Requisições de serviço em um sistema
distribuído podem não ser propriamente
executadas
• Exceções: mecanismo usado para reportar o
motivo da falha para o objeto que requisitou
a operação
• Duas categorias de exceções:
– Genéricas: geradas pela plataforma
– Específicas: geradas pela aplicação em
particular – devem ser implementadas
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
24
Operações
• Uma operação é definida através de uma
assinatura, composta de:
–
–
–
–
um nome para a operação
uma lista de parâmetros (in, out, e inout)
um tipo de valor de retorno
uma lista de exceções que uma chamada da
operação pode gerar (em caso de falhas)
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
25
Exemplo de Tipo de Objeto
<<interface>>
Player
-name:string;
-role:Position;
-Number:int;
+void book(in Date d) raises (AlreadyBooked);
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
26
Requisições
• Um objeto cliente pode requisitar a
execução de uma operação por parte de um
objeto servidor
• Através do envio de uma mensagem para o
objeto servidor, contendo:
– nome da operação e parâmetros (in e inout)
• Objetos servidores são identificados através
de referências de objeto
• Clientes devem ser preparados para reagir a
exceções que a requisição possa gerar
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
27
Sub-Tipos
• Propriedades compartilhadas por vários tipos
deveriam ser definidas apenas uma vez
• Tipos de objetos são organizados em uma
hierarquia de tipos
• Sub-tipos herdam atributos, exceções e
operações de seus super-tipos
• Sub-tipos podem redefinir propriedades
herdadas, bem como adicionar novas proprs.
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
28
Herança Múltipla
• Significa que um mesmo tipo de objeto
pode ser sub-tipo de mais do que um supertipo
• Nem todo middleware suporta esta
característica
• Pode levar a ambigüidades
– Ex.: mesmo atributo ou operação definido em
dois super-tipos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
29
Exemplo de Herança Múltipla
<<interface>>
Trainer
-salary:int;
+next_game():Date
<<interface>>
Player
-name:string;
-role:Position;
-Number:int;
+void book(in Date d) raises (AlreadyBooked);
+next_game():Date
<<interface>>
PlayerTrainer
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
30
Polimorfismo
• Modelos de objetos podem ser estaticamente
tipados
• Variáveis com tipos estáticos restrigem o tipo
dos objetos aos quais podem ser associadas
• Polimorfismo permite que a uma variável
sejam associados tando objetos do mesmo
tipo (estático) da variável quanto objetos que
são instâncias de algum de seus sub-tipos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
31
Exemplo de Polimorfismo
chelsea:Team
name = “Chelsea”
v:PlayerTrainer
name = “Gianluca Vialli”
role = Forward
Number = 10
salary=1000000
d:Player
name = “Marcel Desailly”
role=Defender
Number=5
z:Player
name = “Gianfranco Zola”
role=Forward
Number=3
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
32
Objetos Locais
versus
Objetos Distribuídos
Motivação
• Aproveitar a experiência com o projeto de
sistemas orientados a objetos no ambiente
local de linguagens de programação OO
• Projeto de objetos distribuídos é diferente
• Analisar as diferenças
• Evitar alguns problemas mais comuns
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
34
Características estudadas
•
•
•
•
•
•
•
•
Referências
Ativação / Desativação
Migração
Persistência
Latência (atraso) de requisições
Concorrência
Comunicação
Segurança
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
35
Ciclo de Vida de um Objeto
• Objetos criados com uma linguagem de
programação OO residem em uma máquina virtual
• Objetos distribuídos podem ser criados em
máquinas diferentes
• Podem ser copiados ou movidos (migrados) de
uma máquina para outra
• Destruição de objetos: coleta de lixo não funciona
bem em sistemas distribuídos
• Ciclo de vida requer atenção especial durante o
projeto de objetos distribuídos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
36
Referências de Objeto
• Em linguagens de programação OO:
– Ponteiros para endereços de memória
• Em sistemas distribuídos:
– Informação de localização
– Informação de segurança
– Referência para o tipo do objeto
• Referências para objetos distribuídos tendem
a ser maiores (ex.: 40 bytes em Orbix)
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
37
Latência das Requisições
• Chamada de método local: ≈200ns
• Requisição remota: alguns milisegundos
• Esta diferença (uma ordem de magnitude)
precisa ser levada em consideração no
projeto das interfaces de objetos
distribuídos:
– operações devem realizar tarefas “maiores”
– requisições não devem ser muito freqüentes
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
38
Exemplo: Iteração em uma
Seqüência de Objetos
• Java (local)
• Objetos Distribuídos
Vector
List
+size():int
+elementAt(i:int):Object
...
+long list (in how_many:long,
out l:sequence<object>,
out bi:Iterator i)
Iterator
+next_one(out o:Object): boolean
+next_n(in how_many:long,
out l:sequence<object>):boolean
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
39
Ativação / Desativação
• Objetos em uma linguagem de programação OO
estão alocados em memória (virtual) todo o tempo
(desde sua criação até sua destruição)
• Inapropriado para objetos distribuídos
– grande número de objetos
– objetos podem ficar sem uso por muito tempo
– alguns hosts podem ser desligados
• Implementações de objetos distribuídos são
– trazidas para a memória quando necessárias (ativação)
– descartadas da memória (desativação)
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
40
Ativação / Desativação (cont.)
Tony:Trainer
BvB:Team
bookGoalies
Objeto ativado
Desativação do
objeto
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
41
Ativação / Desativação (cont.)
• Questões importantes que surgem:
–
–
–
–
–
Repositório de implementação
Associação entre objetos e processos
Ativação implícita vs. explícita
Quando desativar objetos
Como lidar com requisições concorrentes
• Quem decide sobre estas questões:
– Projetista, Programador, Administrador
• Documentar todas as decisões
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
42
Persistência
• Objetos com estado Vs. Objetos sem estado
• Objetos com estado devem salvar seu
estado entre desativações e ativações
sucessivas
• Em espaço de armazenamento persistente
– Sistema de arquivos
– Banco de dados relacional
– Banco de dados OO
• Faz parte do projeto de um objeto
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
43
Paralelismo
• Execução de objetos no ambiente de uma
linguagem de programação OO
– Seqüêncial
– Concorrente (com múltiplos threads)
• Objetos distribuídos executam em paralelo
• Isto pode ser usado para acelerar a
computação
• Mas requer mecanismos de controle de
concorrência
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
44
Comunicação
• Chamadas de métodos em linguagens de
programação OO são síncronas
– chamador pára e espera pela resposta
• Alternativas para objetos distribuídos
–
–
–
–
requisições síncronas
requisições oneway (sem resposta)
requisições síncronas atrasadas
requisições assíncronas
• Quem decide qual tipo usar:
– Projetista do servidor?
– Projetista do cliente?
• Alternativas disponíveis devem ser documentadas
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
45
Falhas
• Objetos distribuídos são mais susceptíveis a
falhas do que objetos centralizados
– Podem falhar independentemente dos clientes
• Diferentes níveis de confiabilidade para as
requisições podem estar disponíveis
• Clientes devem verificar se o servidor
realmente executou a requisição
– Ex.: através de exceções
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
46
Segurança
• Segurança em aplicações OO pode ser tratada no
nível de seção
• Objetos em linguagens de programação OO não
requerem grandes preocupações com segurança
• Em objetos distribuídos:
–
–
–
–
Quem está requisitando a execução de uma operação?
Como saber que o chamador é quem ele diz ser?
Como decidir se permite ou não acesso a um serviço?
Como provar que o serviço foi provido (de forma que
uma fatura possa ser emitida)
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
47
Pontos-Chave
• Objetos distribuídos passaram de um tema de
pesquisa em linguagens de programação para a
agenda de sistemas distribuídos
• UML pode ser utilizada para o projeto de objetos
distribuídos
• Meta-modelos definem as características de
objetos distribuídos conforme suportados por uma
determinada plataforma
• Projetistas devem estar conscientes das diferenças
entre objetos locais e objetos distribuídos
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
48