Sistemas
Orientados a Objetos
Bibliografia:
• Booch, G. Object Oriented Design with Applications.
The Benjamin/Cummings Publishing Company, Inc.
1991.
• Yourdon, E. Object-Oriented Systems Design - An
Integrated Approach. Prentice-Hall, Inc. 1994
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
1
Programming
Programming in The Large
Programming in The Small
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
2
Programming in The Small
• Exemplos:
– alguns trabalhos acadêmicos
– programas simples
• Características:
– poucas linhas de código (dezenas ou
centenas)
– apenas um programador
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
3
Programming in The Large
• Exemplos:
– controle de processos
– centrais telefônicas
– sistemas gerenciadores de bancos de dados
• Características:
– milhares de linhas de códigos
– equipe de desenvolvimento formada por
várias pessoas
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
4
Sistemas
Simples
Complexos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
5
Exemplos de sistemas Complexos
• o processo de formação do início do Universo
•
•
•
•
•
•
•
•
•
decodificação do DNA
metabolismo de uma célula
o corpo humano
processo de formação das estrelas
software de controle de uma central telefônica
CPA
naves espaciais
sistema de tráfego de uma metrópole
descrição do movimento de uma particular
partícula d’água no curso de um rio
...
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
6
Principal Característica dos Sistemas
Complexos
• Tem a ver com o “Domínio do Problema”
(“Problem Domain”)
• Ultrapassam a capacidade intelectual do ser
humano isolado relativamente a:
– extensão do conhecimento
– profundidade do conhecimento
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
7
A complexidade Inerente ao “Software”
• A complexidade do Domínio do Problema
• A dificuldade em se gerenciar o processo de
desenvolvimento do “software”
• A flexibilidade proporcionada pelo “software”
• A dificuldade para se caracterizar o
comportamento dos sistemas discretos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
8
A Complexidade do “Problem Domain”
• Há sistemas já complexos em sua
funcionalidade pela sua própria natureza
– sistema de comutação para telefonia celular
– sistema eletrônico para aeronaves
– “robot” autônomo
• Acrescente-se os aspectos relativos a:
– facilidades de uso, performance, custo, permanência
e confiabilidade
• O problema de “impedance mismatch”
(usuários x desenvolvedores)
– os usuários muitas vezes têm uma vaga idéia do que
querem
– falta de mecanismos formais para capturar os
requisitos do problema
– alteração dos requisitos durante o desenvolvimento
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
9
Dificuldades em se Gerenciar o Processo de
Desenvolvimento
• Tem a ver com o “Domínio do Problema”
(“Problem Domain”)
O conhecimento inerente aos sistemas grandes
e complexos ultrapassa a capacidade
intelectual do ser humano isolado
relativamente a extensão e/ou profundidade do
conhecimento
Necessidade de equipes para desenvolver
“software”
maior a equipe
mais comunicação
coordenação mais
difícil
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
10
Problema Capital
Manter a unidade e a integridade
do projeto
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
11
O Problema de se caracterizar o
comportamento dos Sistemas Discretos (i)
• Estado de uma aplicação: o conjunto de suas
variáveis, seus valores correntes, os endereços
e a pilha de chamadas de cada processo no
sistema.
• Os sistemas discretos possuem um número
finito de estados
• Em sistemas grandes há uma explosão
combinatorial e o número de estados cresce
muito
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
12
O Problema de se caracterizar o
comportamento dos Sistemas Discretos (ii)
• Nos sistemas contínuos, pequenas alterações
na entrada sempre ocasionarão pequenas
alterações na saída
x
x + dx
y
y + dy
• Nos sistemas discretos (e.g. “software”) cada
evento tem o potencial de colocar o sistema
em um novo estado e, mais ainda, o
mapeamento de estado a estado nem sempre é
determinístico
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
13
O Problema de se caracterizar o
comportamento dos Sistemas Discretos (iii)
• Nos sistemas discretos todos os eventos
externos podem afetar qualquer parte do
estado interno do sistema.
• Para grandes sistemas testes exaustivos são
impossíveis
• deveremos nos contentar com níveis
adequados de confidência quanto à correção
dos sistemas
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
14
A Flexibilidade do “Software”
• O “software” é a quinta-essência da
flexibilidade
• Dificuldade na elaboração de padrões
• Atividade mão-de-obra intensiva
• Contínua reinvenção da roda
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
15
Conseqüências da Complexidade sem Limites
• Quanto mais complexo o sistema maior a
dificuldade de alterá-lo
Ex.: uma vez projetado um prédio de 100 andares e
iniciada a sua construção, dificilmente o mesmo sofrerá
alterações de projeto. Já com o “software”...
• Escassez de bons programadores para criar
todos os produtos demandados pelos usuários
– crise de “software” (“software crisis”)
– cresce o “back log” de “software”, os requisitos são
deficientes, os custos excessivos, etc ...
– parte crescente de pessoal dedicado à manutenção
•
Como os Sistemas Complexos se
organizam?
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
16
Exemplos de Sistemas Complexos (i)
• “Space Shuttle”
• Túnel França-Inglaterra
• A Internet
• Organizações Transnacionais (IBM, AT&T)
• O Sistema Circulatório do Homem
• Estrutura de uma Planta
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
17
Exemplos de Sistemas Complexos (ii)
• A Estrutura de um Computador Pessoal
– natureza hierárquica
– juntas, as partes formam um todo lógico e integrado
– os vários níveis de hierarquia representam diferentes
níveis de abstração
– cada nível é construído “em cima” de outros níveis
– cada nível é auto-contido, em termos de seu
entendimento
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
18
Exemplos de Sistemas Complexos (iii)
CPU
Memória
HDD
Monitor
Teclado
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
19
Exemplos de Sistemas Complexos (iv)
CPU
ALU
UC
Registradores
NANDs
BUS
Lógica
de
Controle
Gates
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
20
Exemplos de Sistemas Complexos (v)
• A Estrutura de Plantas e Animais
– sempre existem fronteiras claras e bem
definidas entre o exterior e o interior de um
dado nível.
– há uma clara separação de objetivos
(“tasks”) entre as partes, nos diferentes
níveis de abstração.
– através da atividade cooperativa de vários
órgãos surgem comportamentos complexos.
ex.: fotossíntese
transpiração
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
21
Exemplos de Sistemas Complexos (vi)
• Planta - complexo organismo multicelular
• Estrutura: raiz, caule e folhas
– raiz: ramos radiculares, pelos absorventes, “root
apex”, coifa
– folha: epiderme, mesófilo, tecido vascular.
células
cloroplasto mitocôndrea núcleo
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
22
Exemplos de Sistemas Complexos (vii)
• Não encontramos partes individuais que sejam
responsáveis por somente pequenas fases de
um processo maior e único.
• Não há partes centralizadas que coordenem as
atividades de outras partes.
• Só através da cooperação mútua das partes se
desenvolve o nível de funcionalidade
encontrado nas plantas.
• Existem elementos comuns que perspassam
diferentes domínios
–
–
–
células (plantas e animais)
sistema vascular para transportar nutrientes para o
organismo
diferenciação de sexos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
23
Exemplos de Sistemas Complexos (vii)
• A Estrutura da Matéria
– Astronomia (Macrocosmo)
– Física Nuclear (Microcosmo)
• Estruturas hierárquicas
– galáxias - “clusters” - estrelas - planetas “debris”
– átomos - elétrons - prótons - nêutrons quarks
• Mecanismos compartilhados que unificam esta
vasta hierarquia:
– parece haver apenas 4 forças fundamentais no
Universo:
gravidade, interação eletro-magnética, força forte,
força fraca
– as Leis de Conservação de Energia e de Momento se
aplicam tanto ao Macrocosmo quanto ao
Microcosmo
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
24
Os 5 Atributos dos Sistemas Complexos (i)
• 1. Hierarquia
Um sistema complexo é composto de
subsistemas inter-relacionados que, por sua
vez, possuem seus próprios subsistemas, e
assim por diante, até que algum nível de
componentes elementares seja alcançado.
=> estrutura hierárquica, que pode ser
decomposta em partes, facilita o entendimento
de sistemas complexos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
25
Os 5 Atributos dos Sistemas Complexos (ii)
• 2. A escolha de quais componentes em um
sistema são primitivos é relativamente
arbitrária e é, em grande parte, dependente do
observador do sistema
Os sistemas complexos são:
“decomposable”: porque podem ser divididos
em partes identificáveis.
“nearly decomposable”: porque as suas partes
não são completamente independentes.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
26
Os 5 Atributos dos Sistemas Complexos (iii)
• 3. As conexões intracomponentes são
geralmente mais importantes (fortes) que as
conexões intercomponentes.
Este fato possibilita a separação de:
dinâmica de alta freqüência dos componentes: envolve
a estrutura interna dos componentes.
dinâmica de baixa freqüência: envolve a interação entre
os componentes.
=> possibilita o estudo interno das partes do
sistema de forma relativamente isolada
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
27
Os 5 Atributos dos Sistemas Complexos (iv)
• 4. Os sistemas hierárquicos são normalmante
compostos de poucos diferentes subsistemas
dispostos segundo várias combinações e
arranjos.
Muitas vezes encontramos subsistemas que
são comuns a diferentes domínios (ex.: células,
circuitos integrados, etc ...)
– células (plantas e animais)
– circuitos integrados (diversos equipamentos
eletrônicos)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
28
Os 5 Atributos dos Sistemas Complexos (v)
• Os sistemas complexos tendem a evoluir no
tempo.
• Os sistemas complexos irão evoluir mais
rapidamente a partir de sistemas simples, se
existirem formas intermediárias estáveis
(Simons).
• 5. Um sistema complexo que funciona
invariavelmente evoluiu de um sistema simples
que funcionava.
• Um sistema complexo projetado do “zero”
nunca funciona e não pode ser consertado
funcionar.Deve-se recomeçar partindo-se de
um sistema simples.
• À medida que o sistema evolui, objetos
anteriormente considerados complexos
tornam-se os objetos primitivos, a partir dos
quais objetos mais complexos são construídos.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
29
Complexidade Organizada e Não-Organizada
• A descoberta de abstrações e mecanismos
comuns facilita o entendimento dos sistemas
complexos.
• Os sistemas complexos não incorporam apenas
uma única hierarquia. Várias hierarquias estão
presentes em um sistema complexo. Duas
hierarquias são especiais:
– estrutural, parte de (“part of”), ou “object
structure”
ex.: Um automóvel pode ser decomposto em:
• sistema de propulsão
• sistema de direção, etc...
– tipo de (“kind of”) ou “class structure”
ex.: motor, motor a álcool, a diesel, a gasolina
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
30
A Forma Canônica de Um Sistema Complexo
(i)
• Combinando-se os conceitos de estrutura de
classes e de objetos com os cinco atributos de
um sistema complexo vemos que praticamente
todos os sistemas complexos apresentam a
mesma forma (canônica) como na figura.
• A estrutura de classes (”kind of hierarchy”) e
a estrutura de objetos (“part of hierarchy”)
não são completamente independentes.
• Cada objeto, na estrutura de objetos representa
uma instância específica de alguma classe.
• Normalmente há muito mais classes que
objetos em um sistema complexo.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
31
A Forma Canônica de Um Sistema Complexo
(ii)
• A análise da estrutura de classes (“kind of
hierarchy”) e da estrutura de objetos (“part of
hierarchy”) revela a redundância do sistema.
• A estrutura de classes abriga o conhecimento
comum relativo às propriedades de cada parte
individual (objeto).
• Os sistemas de “software” bem sucedidos,
explicitamente incorporam uma estrutura de
classes e objetos bem definidas, além dos
cinco atributos dos sistemas complexos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
32
As limitações do ser humano no trato com a
complexidade
• Dilema
A complexidade dos sistemas de
“software” é crescente e os seres
humanos têm limites estruturais
para lidar com esta complexidade.
O que fazer?
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
33
1. O Papel da Decomposição
• “Dividir para reinar”
• Uma decomposição inteligente ataca o
problema da complexidade inerente ao
“software”, forçando uma divisão do espaço de
estado do sistema (Parnas).
• Tipos de Decomposição:
– Decomposição Algorítmica
É uma conseqüência do “top-down structured
design”. Cada módulo do sistema denota um passo
maior em algum processo global.
– Decomposição Orientada a Objetos
Um sistema é encarado como um conjunto de
agentes autônomos (objetos), que colaboram para
efetivar algum comportamento de mais alto nível.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
34
Decomposição Algorítmica X Orientada a
Objetos
• Qual é a forma correta de se decompor um
sistema complexo?
• A visão algorítmica enfatiza a ordem dos
eventos
• A visão orientada a objetos enfatiza os agentes
que causam ou sofrem uma ação
• Trata-se de duas visões ortogonais. Não se
pode construir um sistema baseado
simultaneamente nas duas versões
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
35
Experiência do Booch e colaboradores
(Object Oriented Design with Applications, pg. 16)
1. Aplica primeiro a visão OO, por considerá-la
mais eficiente na organização da complexidade
dos sistemas.
2. Conduz a sistemas menores, através da
reutilização de mecanismos comuns.
3. É mais resiliente (aprersenta maior poder de
recuperação a mudanças) e, assim, está mais
capacitada a evoluir no tempo, porque o
projeto é baseado em formas intermediárias
estáveis.
4. Reduz o risco de desenvolver complexos
sistemas de “software”, pois os mesmos são
projetados para evoluir incrementalmente.
5. Diretamente ataca a complexidade inerente ao
“software”, através da separação de
preocupações (“concerns”) em espaço de
estados de grandes dimensões.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
36
2. O Papel da Abstração
• Os seres humanos desenvolveram uma técnica
excepcionalmente poderosa para lidar com a
complexidade. Abstraem-se dela. Incapazes de
dominar a totalidade de um objeto complexo,
escolhem ignorar detalhes não essenciais,e, ao
invés, tratam apenas com um modelo
idealizado e geral do objeto.
• Através da abstração, usamos agregados de
informação com conteúdo se~mântico cada
vez maior.
• Os objetos representam, como abstrações do
mundo real, um “cluster” coesivo e
particularmente denso de informação.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
37
3. O Papel da Hierarquia
• Um meio de aumentar o conteúdo semântico dos
“pedaços” individuais de informação é reconhecer
explicitamente as hierarquias de classe e objeto.
• A estrutura de classes faz aflorar as redundâncias
existentes.
• A estrutura de objetos mostra como os diferentes objetos
colaboram entre si através de padrões de interação
chamados mecanismos.
• A classificação dos objetos em grupos de abstrações
relacionados, permite a distinção entre as propriedades
comuns e propriedades distintas entre vários objetos.
• A identificação de hierarquias nem sempre é fácil, pois
requer a descoberta de padrões entre vários objetos, e
cada um deles pode incorporar formas de
comportamento muito complicadas.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
38
Projetando Sistemas Complexos
• Engenharia envolve ciência & arte...
• O significado do Projeto
Abordagem disciplinada para inventar uma
solução para um dado problema, provendo
assim um caminho, desde os requisitos do
sistema, até a sua implementação.
• O propósito do Projeto é construir um sistema
que:
– satisfaça uma dada especificação funcional
– adeque-se às limitações do equipamento alvo
– subordine-se aos requisitos implícitos ou explícitos,
relativos à performance e ao uso de recursos
– satisfaça restrições do próprio processo do projeto
(tempo ou ferramentas disponíveis, ou custo)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
39
A Importância da Construção de Modelos
• A construção de modelos adere aos princípios
de decomposição, abstração e hierarquia.
• Cada modelo, em um projeto, descreve um
aspecto específico do sistema sob
consideração.
• Sempre que possível constrói-se novos
modelos, baseados em modelos já existentes e
confiáveis.
• Os modelos nos dão a oportunidade de falhar
sob condições controladas.
• Analisamos os modelos sob condições
esperadas e sob condições não usuais e, então ,
os alteramos, quando eles não se comportam
como o desejado ou esperado.
• De modo a expressar todas as propriedades de
um sistema complexo deve-se usar vários
tipos de modelos.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
40
Elementos dos Métodos para Projetos de
“Software”
• O Projeto de Sistemas de Software Complexos
envolve um processo incremental e interativo.
• Há diversas categorias de métodos para
Projetos.
• Cada método deve incluir:
– Notação - a linguagem para expressar cada
modelo
– Processo - as orientações para a construção
ordenada dos modelos
– Ferramentas - mecanismos que
automatizam tarefas e reforçam as regras
do modelo, de modo que os erros e
inconsistências aflorem
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
41
Os Modelos de Projetos Orientados a Objetos
• Projeto Orientado a Objetos: é um método que
nos leva a uma decomposição orientada a
objetos.
• Resultado:
– “software” mais resiliente (elástico) a
mudanças
– escrito com economia de expressão
– maior nível de confiabilidade e correção,
através da separação inteligente do espaço
de estados
– redução dos riscos de desenvolvimento
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
42
Princípios dos Projetos Orientados a Objetos
(Modelo Objeto)
• Abstração
• Encapsulamento
• Hierarquia
• Modularidade
---------------------------------• Tipos
• Concorrência
• Persistência
(Booch)
• Abstração
• Encapsulamento
• Herança
(Yourdon)
---------------------------------• + Polimorfismo
(Rumbaugh)
---------------------------------• Abstração
• Encapsulamento
• Reuso
• Especialização
• Comunicação entre
Objetos
• Polimorfismo (OMG)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
43
Evolução do Modelo Objeto (i)
Tendências em Engenharia de “Software”
As Gerações das Linguagens de Programação
• 1a Geração (1954-1958) - FORTRAN I,
ALGOL 58, Flowmatic, IPL V
– voltadas para aplicações científicas e de engenharia
– facilidades para escrever expressões matemáticas
• 2a Geração (1959-1961)
– FORTRAN II
separado
– ALGOL 60
dados
– COBOL
– Lisp
ponteiros
- subrotinas, compilação em
- estrutura de blocos, tipos de
- descrição de dados,
manipulação de arquivos
- processamento de listas,
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
44
Evolução do Modelo Objeto (ii)
• 3a Geração (1962-1970)
– PL/1
– ALGOL 68
– Pascal
– Simula
- FORTRAN + ALGOL +
COBOL
- sucessor formal do ALGOL 60
- outro sucessor do ALGOL 60
- classes, abstração de dados
• O “gap” das gerações (1970 - 1980)
– muitas linguagens foram inventadas, porém poucas
permaneceram
• hoje: ADA, CLOS, C++ (C U Simula)
– linguagens orientadas a objetos (“object based”)
– linguagens baseadas em objetos (“object oriented”)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
45
A Topologia das LPs da 1a Geração e Início da
2a
• o subprograma era o bloco básico para a
construção de todas as aplicações
• o erro em uma parte do programa podia ter
efeitos devastadores em outras partes
• quando muitas alterações eram efetuadas em
sistemas de grande porte tornava-se difícil
manter a integridade do projeto original
• após alguma manutenção, um sistema escrito
nestas linguagens continha:
–
–
–
–
–
acoplamentos cruzados entre subprogramas
significados implicados de dados
fluxo de controle entrelaçado
perigos quanto a confiabilidade de todo o sistema
redução na clareza da solução
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
46
A Topologia das Últimas LPs da 2a Geração e
das LPs do Início da 3a Geração
• reconheceu-se a importância dos subprogramas como
intermediários relevantes entre o problema e o
computador
• os subprogramas passaram a ser vistos como
mecanismos de abstração
– foram inventadas linguagens com mecanismos variados
para a passagem de parâmetros
– lançamento da programação estruturada, refletindo-se em:
• aninhamento de subprogramas
• estruturas de controle
• escopo e visibilidade de variáveis
• emergência das metodologias de Projeto Estruturado
(voltadas para “Programming in The Large”)
• houve um maior controle sobre as abstrações dos
algoritmos, porém não resolveu os problemas de
“Programming in The Large” e dos Projetos dos Dados
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
47
A Topologia das LPs do Final da 3a Geração
• compilação em separado de módulos
• todavia, os módulos raramente foram
reconhecidos como mecanismos de abstração
• eram usados simplesmente para agrupar
programas relacionados
• não havia regras para verificar a consistência
semântica entre as interfaces dos módulos
• certos erros na passagem de parâmetros, só
eram descobertos em tempo de execução (ex.:
passagem de parâmetros com inconsistência
entre os tipos)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
48
A Topologia das LPs Baseadas em Objetos e
Orientadas a Objetos
• enfatizou-se a abstração de dados no trato da
complexidade
– uso de procedures (para operações abstratas, mas não era
ideal para a descrição de objetos abstratos)
– descrição dos objetos => conceito de tipos
• os blocos básicos de construção são os módulos
• os módulos representam uma coleção lógica de classes e
objetos, ao invés de programas
• A topologia passa a ser um grafo, e não uma árvore, que
era a a topologia típica das linguagens orientadas a
algoritmos
• quase não há dados globais
• em sistemas imensos encontramos “clusters” de
abstrações construídos em níveis, superpostos uns aos
outros
• em cada nível de abstração encontramos coleções de
objetos que cooperam entre si, a fim de manifestar
algum tipo de comportamento em um nível mais
elevado
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
49
O Modelo Objeto - “The Object Model” (i)
• Modelo Objeto
O conjunto dos princípios que formam os
fundamentos do Projeto Orientado a Objetos.
Um paradigma da Engenharia de Software que
enfatiza os princípios de abstração,
encapsulamento, modularidade, hierarquia,
tipos, concorrência e persistência.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
50
O Modelo Objeto - “The Object Model” (ii)
• mostrou-se um conceito unificador em ciência
da computação
• aplicado em LPs, projeto de interfaces para
usuários, bases de dados, arquitetura de
computadores, etc...
• a razão é que a Orientação a Objetos ajuda a
lidar com a complexidade dos sistemas
• representa um desenvolvimento evolutivo, não
revolucionário
• derivado de várias áreas do conhecimento
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
51
O Modelo Objeto - “The Object Model” (iii)
• Objeto é o conceito fundamental.
• Objeto (definição informal): entidade tangível,
que exibe algum tipo de comportamento bem
definido.
• Conceito básico: objeto serve para unificar as
idéias de algoritmo e abstração de dados.
• Um objeto somente pode alterar o seu estado,
comportamento, ou ser manipulado, ou
relacionar-se com outros objetos em modos
apropriados àquele objeto.
• Existem propriedades invariantes que
caracterizam um objeto em seu
comportamento (ex.: trem, elevador ...)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
52
O Modelo Objeto - “The Object Model” (iv)
• OOP - “Object-Oriented Programming”
(Booch)
OOP é um metodo de implementação no qual
programas são organizados como coleções de
objetos cooperativos, cada qual representando
uma instância de alguma classe, e cujas
classes são todas membras de uma hierarquia
de classes unidas via relações de herança
(“kind of herarchy”).
• Uma LP sem herança não é Orientada a
Objetos. Ela é dita “Object-Based”.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
53
O Modelo Objeto - “The Object Model” (v)
• Segundo Cardelli & Wagner, uma linguagem é
orientada a objetos se:
– suporta objetos que são abstrações de
dados, com interfaces para operações
nomeadas (métodos) e um estado local
oculto.
– Objetos têm um tipo (classe) associado
– Tipos (classes) podem herdar atributos de
supertipos (superclasses)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
54
O Modelo Objeto - “The Object Model” (vi)
• OOD - “Object-Oriented Design” (Booch)
OOD é um método de projeto que incorpora:
• o processo de decomposição orientado a
objetos
• uma notação para mostrar:
– os modelos lógicos e físicos do
sistema
– os modelos estáticos e dinâmicos do
sistema
modelos lógicos: estrutura de classes e
objetos
modelos físicos: arquitetura dos módulos
e dos processos
• OOD - qualquer método que leve a uma
decomposição orientada a objetos.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
55
O Modelo Objeto - “The Object Model” (vii)
• OOA - “Object-Oriented Analysis” (Booch)
OOA é um método de análise que examina os
requisitos do sistema a partir das classes e
objetos encontrados no vocabulário do
domínio do problema.
• As técnicas de análise estruturada tradicionais
(De Marco, Yourdon, Gane e Sarson) têm o
seu foco no fluxo de dados do problema.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
56
Abstração (i)
• Uma abstração surge do reconhecimento das
semelhanças entre certos objetos, situações ou
processos no mundo real, e da decisão de se
concentrar nestas semelhanças e ignorar,
naquele momento, as diferenças.
Ex.: árvores, rios, cavalos, carros, etc ...
• Um conceito qualifica-se como abstração,
somente se ele puder ser descrito,
compreendido e analisado, independentemente
do mecanismo que será usado para
implementá-lo (realizá-lo).
• Uma abstração denota as características
essenciais de um objeto, que o distingüe de
todos os outros tipos de objetos e, assim,
fornece fronteiras conceituais bem definidas,
relativas à perspectiva do observador (Booch).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
57
Abstração (ii)
• Define uma relação entre um grupo de tipos de
objetos (“object types”), de forma que um um
tipo objeto represente um conjunto de
características que são compartilhadas pelos
outros tipos de objetos (OMG - Object
Management Group).
• Qualquer mecanismo que nos permita
representar uma realidade complexa (vários
componentes) em termos de um modelo
simplificado (um único componente de mais
alto nível).
As metodologias OO fundamentam-se na
abstração de dados, usando conceitos análogos
ao de subtipo / supertipo
• Uma abstração enfoca a visão externa do
objeto e, assim, serve para separar o
comportamento essencial do objeto da sua
implementação
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
58
Abstração (iii)
• barreira de abstração: (Sussman “abstraction barrier”): é a divisão:
comportamento / implementação, alcançada
pela aplicação do princípio do “least
commitment”, através do qual a interface de
um objeto provê o seu comportamento
essencial, e nada mais.
• princípio do “least astonishment” (Booch):
uma abstração deve capturar o comportamento
de um objeto em sua totalidade, nem mais,
nem menos.
==> A decisão sobre o conjunto adequado de
abstrações para um determinado domínio é o
problema central do Projeto Orientado a
Objetos (OOD).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
59
Abstração (iv)
Existe um espectro de abstrações, desde os
tipos identificados com o domínio do
problema, até objetos para os quais não há
razão aparente para a sua existência (Seidewitz
e Stark).
• Abstração de Entidades (a ideal!): um objeto que
representa um modelo útil de uma entidade no domínio
do problema.
• Abstração de Ação: um objeto que provê um conjunto
generalizado de operações, as quais (todas) realizam o
mesmo tipo de função.
• Abstração de Máquina Virtual: um objeto que agrupa
operações que são todas usadas por algum nível superior
de controle, ou operações em que todas usam algum
conjunto de operações a nível elementar.
• Abstração Coincidente: um objeto que empacota um
conjunto de operações que não possuem relações umas
com as outras.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
60
Abstração (v)
• Cliente:é qualquer objeto que usa os recursos
de outro objeto.
O comportamento (“behavior”) de um objeto é
caracterizado pelas operações que os seus
clientes podem executar nele e pelas operações
que ele pode executar em outros objetos.
Leva a concentrar a atenção na visão externa
do objeto
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
61
Abstração (vi)
• Protocolo: é o conjunto de operações que um
cliente pode executar sobre um dado objeto.
– ADA
– Smalltalk
– C++
- operation
- method
- member function
variáveis de estado
Objeto
métodos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
62
Exemplos de Abstração
Considerar uma plantação hidropônica
• Sensor de temperatura
• Plano de crescimento para cada tipo de cultura
descreve como a temperatura, luz, nutrientes e
outros fatores devem alterar-se no tempo, a
fim de maximizar a colheita
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
63
Encapsulamento - “Information Hiding” (i)
• A abstração de um objeto deveria preceder as
decisões acerca de sua implementação.
• Uma vez que uma implementação seja
selecionada ela deve ser tratada como um
segredo da abstração e oculta da maioria de
seus clientes.
• Nenhuma parte de um sistema complexo
deveria depender dos detalhes internas de
qualquer outra parte.
• O encapsulamento impede os clientes de terem
uma visão interna dos objetos. Trata-se de uma
barreira efetiva entre diferentes abstrações.
Ex.: programas que usam 3D’s não precisam
se preocupar com a representar física dos
dados.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
64
Encapsulamento (ii)
• Para a abstração ser eficaz a implementação do
conceito deve ser encapsulada.
– “interface”: captura a visão externa da
classe
– “implementation”: compreende a
representação da abstração, assim como os
mecanismos (métodos) que realizam o
comportamento desejado.
• Encapsulamento: é o processo de ocultar
todos os detalhes de um objeto que não
contribuem para as suas características
essenciais (Booch).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
65
Encapsulamento (iii)
• Um encapsulamento inteligente localiza
decisões de projeto que são prováveis de serem
alteradas.
• Encapsulamento em C++
Os membros (métodos) podem ser colocados
nas partes:
– public - visíveis a todos os clientes
– private - completamente encapsulados
– protected - visíveis à classe e às suas
subclasses
– friendship classes - classes cooperativas
que permitem a visão das partes privativas
de outras classes
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
66
Herança (i)
• Hierarquia: é uma classificação ou
ordenamento das abstrações (Booch)
• As duas hirarquias mais importantes de um
sistema complexo:
– estrutura de classes (“kind of”)
– estrutura de objetos (“part of”)
• Herança (hierarquia “is a”)
Define uma relação entre classes, em que uma
classe compartilha a estrutura e o
comportamento definido em uma ou mais
classes (herança simples e herança múltipla,
respectivamente).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
67
Herança (ii)
• Herança: representa uma hierarquia de
abstrações, em que uma subclasse herda de
uma ou mais superclasses. Tipicamente a
subclasse aumenta ou redefine a estrutura e o
comportamento de uma ou mais classes.
• Hierarquias de Generalização / Especialização
Com a evolução da hierarquia, as estruturas e
comportamentos comuns a diferentes classes
tenderão a migrar para superclasses comuns.
– superclasses
=> abstrações
generalizadas
– subclasses
=> especializações
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
68
Tensão entre os Princípios
Abstração
Encapsulamento
Hierarquia
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
69
Herança (iii)
• Para uma classe específica, normalmente há
dois tipos de clientes:
– objetos que invocam operações (métodos)
em instâncias da classe
– subclasses que herdam da classe (viola o
encapsulamento)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
70
Exemplos de Herança
mamíferos
cães
herança
simples
dobermann
rotweiller
dog alemão
herança múltipla
híbrido
dobermann + rotweiller
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
71
Polomorfismo
• Polimorfismo: mecanismo que permite que
diferentes operações (métodos, serviços ou
funções) sobre objetos de diferentes tipos
tenham o mesmo nome (Yourdon).
Isto significa que um objeto pode enviar uma
mensagem para outro objeto sem
necessariamente saber (ou preocupar-se) a
que classe o outro objeto pertence.
• O Polimorfismo é extremamente útil nas fases
de Projeto (“Design”) e Implementação.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
72
Exemplo de Polimorfismo
move
treinador de circo
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
73
Modularidade (i)
• Classes e objetos formam a estrutura lógica de
um sistema. Estas abstrações são agrupadas em
módulos, que integram a estrutura física de
um sistema.
• As conexões entre os módulos são as
assumções que os módulos fazem entre si
(Parnas).
• A maioria das linguagens que suportam o
conceito de módulo distingüem entre
ïnterface” e “implementation”.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
74
Modularidade (ii)
• Em C++
– módulos são arquivos compilados em
separado ...
– as interfaces são colocadas em arquivos .h
(“header files”)
– as implementações, em arquivos .c
– dependências entre estes arquivos são
resolvidas com o uso da macro #include
• Em Pascal
– units
– as units distingüem entre “interface” e
“implementation”
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
75
Modularidade (iii)
• Decidir sobre o conjunto de módulos para um
sistema é tão difícil quanto definir sobre o
conjunto correto de abstrações.
• Uma solução é agrupar classes e objetos
logicamente relacionados em um mesmo
módulo e expor somente aqueles elementos
que os outros módulos devem ver.
• O custo de recompilar o corpo
(“implementation part”) de um módulo é
pequena; só este módulo precisa ser
recompilado e, então “link-editado” com o
restante da aplicação.
• Já o custo de recompilar a “interface” é
relativamente alto. Deve-se recompilar a
interface do módulo, seu corpo, e todos os
módulos que dependem desta interface, os
módulos que dependam destes outros e, assim,
sucessivamente.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
76
Modularidade (iv)
• A interface de um módulo deve ser a mais
simples possível (ocultar tudo o que se puder,
no corpo do módulo)
desejo de encapsular
as abstrações
tornar certas abstrações
visíveis a outros métodos
• Modularidade: é a propriedade de um sistema
que foi decomposto num conjunto de módulos
coesivos e fracamente acoplados (Booch).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
77
Modularidade (v)
• Procurar agrupar classes e objetos em módulos
que facilitem a reutilização
• Lembrar que os módulos freqüentemente
servem como unidade de documentação e
gerenciamento de configuração
• Questões relativas a segurança podem
influenciar no particionamento dos módulos
Atenção:
• A identificação de objetos e classes é parte do
projeto lógico do sistema
• A identificação dos módulos é parte do projeto
físico
• As decisões relativas aos projetos lógico e
físico interagem entre si
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
78
Tipos (i)
• Uma classe implementa um tipo
• Um tipo é a caracterização precisa das
propriedades estruturais ou comportamentais
que toda uma coleção de entidades
compartilha.
• Tipagem (“Typing”): são as restrições da
classe de um objeto, de forma que, objetos de
diferentes tipos não podem ser
intercambiados, ou, na melhor das hipóteses,
somente podem ser intercambiados de modo
muito restrito (Booch).
• Uma linguagem fortemente tipada (“strongly
typed”) é aquela em que todas as expressões
garantidamente são tipo - consistentes.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
79
Tipos (ii)
• Benefícios das linguagens fortemente tipadas:
– Sem a verificação de tipos um programa
pode abortar misteriosamente.
– O ciclo edição - compilação - depuração é
muito tedioso. Assim, a detecção de erros o
mais cedo possível é indispensável.
– As declarações de tipos ajudam na
documentação
– Geração de código mais eficiente
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
80
Tipos (iii)
• “Static and Dynamic Binding”
(Ligação / Associação Estática e Dinâmica)
• “Strong Typing”: refere-se à consistência entre
tipos
• “Static Typing” (“Static Binding” ou “Early
Binding”): significa que os tipos de todas as
variáveis e expressões são fixados em tempo
de compilação.
• “Dynamic Binding”(“Late Binding”): significa
que os tipos de todas as variáveis e expressões
só serão conhecidos em tempo de execução.
• “Strong Typing” e “Binding” são conceitos
independentes
• O Polimorfismo existe quando as “features” de
herança e “dynamic binding” interagem
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
81
Tipos (iv)
• ADA
strongly & static typed
• Object Pascal & C++
strongly typed & dynamic binding
• Smalltalk
untyped & dynamic binding
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
82
Concorrência (i)
• Certos tipos de problemas, em sistemas
automatizados, precisam manipular múltiplos
eventos simultâneamente.
• Alternativas:
– distribuir o código entre vários
processadores (“true concurrency”)
– usar um só processador com “multitasking”
(consegue-se a ilusão de concorrência, via
algoritmos de “time slicing”)
• Um “thread of control” (processo único) é a
raiz, a partir da qual, ações independentes
ocorrem em um sistema.
• Todo programa possui pelo menos um “thread
of control”
• Sistemas com concorrência envolvem vários
“threads”
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
83
Concorrência (ii)
início
fim
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
84
Concorrência (iii)
• Concorrência e OOP são ortogonais nos níveis
mais elementares de abstração.
(OOP ou não, todos os problemas tradicionais
em programação concorrente permanecem)
• Tipos de problemas tratados em concorrência:
– “deadlock”
– “starvation”
– exclusão mútua
• OOP pode aliviar o problema da concorrência,
ocultando-a dentro de abstrações reusáveis.
• Em havendo concorrência, não basta
simplesmente definir os métodos de um objeto.
Devemos certificar-nos que a semântica do
método será preservada na presença de vários
caminhos de controle.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
85
Persistência (i)
• Nos programas, um objeto ocupa um
determinado espaço e existe por um dado
intervalo de tempo.
• Há um espectro (escala) de tempo na vida dos
objetos.
LPs
Bases
de
Dados
• dados resultantes da avaliação de uma expressão
• variáveis locais em ativações de procedures
(funções)
• variáveis globais e ítens do “heap” (cuja
extensão é diferente do escopo)
• dados que existem entre várias execuções de um
mesmo programa
• dados que sobrevivem ao programa
Object Model
+
Persistence
=
OODB
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
86
Persistência (ii)
• Persistência: é a propriedade de um objeto,
através da qual sua existência transcende o
tempo (i.e., o objeto continua a existir após o
seu criador ter deixado de existir) e/ou espaço
(i.e., a localização do objeto move-se do
espaço de endereçamento no qual ele foi
criado).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
87
Benefícios do Modelo Objeto - “Object Model”
(Booch, pag. 71)
• Permite construir sistemas que incorporam os
cinco atributos dos sistemas complexos bem
estruturados.
• Ajuda a explorar o poder de expressão das LPs
Orientadas a Objetos e Baseadas em Objetos.
• Encoraja a reutilização, não somente do
“software”, mas de projetos completos.
• Produz sistemas que são construídos a partir
de formas intermediárias estáveis e, assim, são
mais resilientes a mudanças. Possibilita que os
sistemas possam evoluir no tempo.
• A fase de integração espalha-se por todo o
ciclo de desenvolvimento do “software”, ao
invés de ocorrer como um evento do tipo “big
bang”.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
88
Ciclo de Vida dos Projetos Orientados a
Objetos (i)
• Problema: a gerência precisa saber se o projeto
está sob controle e se o pessoal envolvido está
fazendo as coisas certas no tempo certo.
• Ciclo de Vida: tradicionalmente significa os
passos ou atividades que devem ser
conduzidas durante o projeto.
• “Waterfall Life Cycle”: as atividades são
executadas uma vez e numa seqüência bem
definida. As saídas (“outputs”) de uma
atividade servem de entrada (“inputs”) para a
próxima atividade.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
89
Ciclo de Vida dos Projetos Orientados a
Objetos (ii)
• Nos POO os gerentes defrontam-se com
problemas adicionais, pois não há fases bem
definidas como no “Waterfall Life Cycle”.
• As atividades (análise, projeto, codificação e
teste) ocorrem concorrentemente. Há o grande
perigo de:
“Nothing is done until it’s all done”
• Em POO o desenvolvimento é evolutivo
• Já os gerentes normalmente perseguem:
– fases bem nítidas
– diferentes marcos (“milestomes”)
– diferentes “check-points”
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
90
1. Modelagem dos Objetos
• Num POO todas as atividades do ciclo de vida
compartilham um vocabulário, notação e
estratégias, i.e.,tudo gira em torno de objetos.
• Em termos simplistas, o processo de
desenvolvimento de “software” poderia ser
considerado como uma seqüência de:
– desenvolvimento de objetos centrais
relacionados ao negócio;
– adição de objetos específicos da aplicação;
– por fim, estes objetos seriam envolvidos em
objetos relacionados à implementação, os
quais lidam com aspectos relativos à
estrutura de “hardware” e “software”.
• Em projetos que usam metodologias
tradicionais, as atividades de projeto, análise e
programação não parecem estar relacionadas.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
91
2. Modelagem Estratégica
(Modelagem de Empresa)
• O objetivo é desenvolver um modelo de uma
unidade de negócios ou empresa, a qual pode
conter um número de diferentes sistemas.
• Conceito de grande interese para aqueles que
desenvolvem sistemas de informação
orientados a negócios.
• No passado, quando foi introduzido nas
metodologias de desenvolvimento de
“software”, a ênfase principal era descobrir
pontos comuns entre sistemas.
• Os modelos de dados das empresas,
documentados com diagramas entidaderelacionamento, não foram bem sucedidos ...
• Reengenharia de negócios
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
92
Modelagem de Análise - I
(“Analysis Modeling”)
• Consiste de atividades para descobrir e
documentar os requisitos do usuário para um
sistema específico.
• alguns engenheiros de “software” pensam que
a AM resume-se à criação de protótipos em
C++ e Smalltalk.
• A atividade de análise fundamenta-se na
premissa de que vale a pena formalizar os
requisitos de uma aplicação.
• Outra premissa importante da atividade de
análise é que o ambiente no qual a aplicação
será usada é bem compreendido e
relativamente estável, e o usuário final tem
uma idéia razoável do que deseja da aplicação.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
93
Modelagem de Análise - II
(“Analysis Modeling”)
• Em todas as metodologias de análise o analista
ignora as restrições físicas (“hardware”,
“software”, etc...) e procura criar um
MODELO TECNOLÓGICO PERFEITO.
• Produto final da AM: um modelo formal e
minucioso do que o usuário espera que o
sistema faça.
• Nas metodologias orientadas a objeto há uma
preocupação quanto ao reuso dos objetos
(dados e métodos), desde as fases iniciais.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
94
Modelagem de Projetos (i)
• O propósito da MP é especificar a visão
externa de um conjunto de tipos de objetos.
• Resultado da atividade de MP:
– rigorosa especificação dos tipos de objetos.
(os tipos objetos representam a interface
com o usuário, a lógica do negócio,
componentes da base de dados da aplicação
e aplicações herdadas, encapsuladas e
reusáveis).
– completa especificação das operações e
interfaces.
– agregação (“clustering”) de tipos de objeto
em modelos de projeto.
– projetos para satisfazer os requisitos de
qualidade
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
95
Modelagem de Projetos (ii)
• É na atividade de projeto que as restrições e
facilidades de hw e sw começam a impactar o
modelo desenvolvido a nível de análise
• “user interface”: atividade a nível de análise ou
a nível de projeto?
• “sequencing” + “timing” + “coordination” +
“synchronization”
atividades importantes na fase de projeto
• Nesta fase, muitas vezes o projetista preocupase com:
– comportamento dependente do tempo dos objetos
– comunicação entre os objetos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
96
Modelagem da Implementação
• Típicamente voltada para a distribuição dos
objetos entre os vários componentes de
“hardware” e “software” em uma rede clienteservidor.
• Deve-se ter uma estratégia para determinar
como os objetos e classes serão distribuídos
pelos vários componentes do ambiente
operacional de “hardware” e “software”.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
97
Metodologias de Desenvolvimento de
“Software” (i)
• Desenvolvimento em Cascata (“Waterfall Life
Cycle”), Projeto Interativo, Projetos de
Rápido Desenvolvimento, Modelos de Ciclo
de Vida em Espiral (“Spyral Life Cycle
Models”)
• “Waterfall Life Cycle”: as atividades são
executadas uma vez e numa seqüência bem
definida. As saídas (“outputs”) de uma
atividade servem de entrada (“inputs”) para a
próxima atividade.
• Tipicamente nada pode ser demonstrado para o
usuário final, até que o derradeiro estágio do
ciclo de vida em cascata tenha sido
completado.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
98
Metodologias de Desenvolvimento de
“Software” (ii)
• Os Projetos Orientados a Objetos são
ortogonais aos tradicionais ciclos de vida em
cascata, em virtude de sua abordagem
interativa e incremental.
• As decisões sobre:
– abordagem Orientada a Objetos para
Desenvolvimento de Sistemas
– Waterfall x Prototipagem
são totalmente independentes.
• Muitos acreditam que os benefícios da OO
estão mais intimamente associados com a
ênfase em interação, prototipagem e
desenvolvimento interativo que a outras
características como herança e polimorfismo.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
99
Metodologias de Desenvolvimento de
“Software” (iii)
• Requisitos para sucesso na Prototipagem:
– aceitação política do paradigma
– um “framework” comum para todas as
atividades do ciclo de vida
• A abordagem interativa ajuda a gerência a
distingüir entre progresso real e progresso
mensurável.
• A equipe de desenvolvimento influencia na
metodologia de desenvolvimento
– projetos OO possuem a tendência de envolver
grupos pequenos de desenvolvedores, que trabalham
muito próximos de um também pequeno grupo de
usuários finais.
– projetos com equipes grandes (ex. 200 pessoas) são
mais difíceis de conduzir em um ambiente de
prototipagem rápida. “Waterfall” seria mais
apropriado.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
100
Classes e Objetos - A Natureza de um Objeto
• Conceito: Objetos têm permanência e identidade,
independente de quaisquer operações sobre os mesmos.
• Segundo a perspectiva do entendimento humano, um
objeto é:
– algo visível ou tangível
– algo que pode ser apreendido intelectualmente
– algo para o qual direciona-se o pensamento ou ação
• Um objeto representa um ítem individual e identificável,
unidade ou entidade, real ou abstrata, com um papel
bem definido no domínio do problema.
• atributos como cor, beleza, tempo ou emoções, como
raiva e amor, não são objetos. São todas propriedades
em potencial dos objetos.
• Um objeto possui estado, comportamento e identidade;
a estrutura e comportamento de objetos similares são
definidos em sua classe comum; os termos objeto e
instância são intercambiáveis.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
101
Classes e Objetos - Estado de um Objeto
• O comportamento de um objeto é influenciado
por sua história: a ordem em que operamos um
objeto é importante. A razão para este
comportamento dependente do tempo é o
estado do objeto.
• O estado de um objeto compreende todas as
(usualmente estáticas) propriedades do objeto,
mais os valores correntes (usualmente
dinâmicas) de cada uma dessas propriedades.
• Uma propriedade é uma característica inerente
ou distintiva, traço ou qualidade, que torna o
objeto único.
• As propriedades possuem algum valor ou
podem denotar outro (s) objeto (s).
• Objetos existem no tempo, são identificáveis,
têm estado e são instanciados. Podem ser
criados, destruídos e compartilhados.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
102
Objetos em C++ - Exemplo (i)
struct PersonnelRecord
{
char
*name[100];
int
socialSecurityNumber;
char
*department[10];
float
salary;
};
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
103
Objetos em C++ - Exemplo (ii)
class PersonnelRecord {
public:
char *employeeName () const;
int employeeSocialSecuriryNumber () const;
char *employeeDepartment () const;
protected:
void setEmployeeName (char *name);
void
void
void
float
private:
char
int
char
float
};
setEmployeeSocialSecuriryNumber (int number);
setEmployeeDepartment (char *department);
setEmployeeSalary (float salary);
employeeSalary () const;
*name[100];
socialSecuriryNumber;
*department[10];
salary;
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
104
Classes e Objetos
Comportamento de um Objeto
• Comportamento (“Behavior”): objetos não
existem isoladamente. Eles sofrem ações e
agem sobre outros objetos.
• Comportamento é como um objeto age e
reage, em termos de mudança de estado e
“message passing”.
• O comportamento de um objeto é
completamente definido por suas ações.
• Uma mensagem é simplesmente uma operação
que um objeto realiza sobre outro objeto.
operação = método = mensagem = funcão membro
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
105
O Significado das Operações (i)
• Um cliente tipicamente pode realizar 5 tipos de
operações sobre um objeto:
– Alteração: altera o estado de um objeto
(operação de gravação ou “acessor”);
– Seleção: acessa o estado de um objeto,
porém não o altera (operação de leitura);
– “Iterator”: permite que se tenha acesso a
todas as partes de um objeto, em alguma
ordem pré-definida;
– Construtor: cria um objeto e/ou inicializa o
seu estado;
– Destrutor: libera a área ocupada pelo
objeto e/ou destrói o objeto.
– Em C++ os métodos (“member functions”)
são declarados como parte da definição de
uma classe.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
106
O Significado das Operações (ii)
• Coletivamente, todos os métodos associados a
um objeto compreendem o PROTOCOLO
daquele objeto.
• O PROTOCOLO de um objeto define a
totalidade de seu comportamento e
compreende a totalidade da visão estática e
dinâmica do objeto.
• Objetos como Máquinas de Estado Finitos
• Objetos
– Ativos
– Passivos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
107
Objetos - Identidade
• Identidade: é aquela propriedade de um
objeto que o distingüe de todos os outros
objetos.
• Compartilhamento Estrutural (“Structural
Sharing”): ocorre quando a identidade de um
objeto é duplicada pela atribuição de um
segundo nome.
Atenção: Perigoso, pois permite que o estado
de um objeto seja alterado via um nome, sem
notificar os clientes que usam o segundo
nome.
• Igualdade de Objetos: Pode ter 2 significados:
– i) dois nomes designam o mesmo objeto;
– ii) os objetos são diferentes, mas os seus
estados são idênticos.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
108
Objetos - Ciclo de Vida
• O tempo de vida (“life time”) de um objeto
estende-se do momento de sua criação até o
momento da devolução do espaço por ele
ocupado.
• Um objeto pode continuar a existir, ainda que
todas as referências ao mesmo sejam perdidas.
Para tanto, basta que continue a consumir
espaço.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
109
Relações entre Objetos
• Os objetos contribuem para o comportamento
global de um Sistema por meio da colaboração
mútua.
• As relações entre dois objetos quaisquer
englobam as assunções que cada um faz do
outro, incluindo quais operações podem ser
realizadas e qual o comportamento resultante.
• Dois tipos de hierarquia são de particular
interesse em OOD:
– relações de uso
– relações de incorporação (“containing
relationships”)
• Relação de Uso: quando um objeto envia uma
mensagem para outro objeto
(No diagrama é indicado por uma linha cheia
entre os dois objetos em questão)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
110
Objetos nas Relações de Uso
• Em uma relação de uso, cada objeto pode
desempenhar um dos papéis:
– Ator: um objeto que pode operar sobre
outros objetos, mas que nunca é operado
por outros objetos (ator = objeto ativo).
– Servidor: um objeto que nunca opera sobre
outros objetos. É tão somente operado por
outros objetos.
– Agente: um objeto que pode operar sobre
outros objetos e também ser operado por
outros objetos.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
111
Exemplo de Relação de Uso entre Objetos
v1
Controlador do Processo
v2
Cadinho
v3
T
fogo
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
112
O Significado da Sincronização
• Sempre que um objeto passa uma mensagem
para outro, com o qual tem uma relação de
uso, os dois objetos devem sincronizar-se de
algum modo.
Aplicação completamente sequencial: chamada de
subrotinas
“Multiple threads of control”: mecanismos de
sincronização mais sofisticados para lidar com
problemas como o de exclusão mútua.
• Objeto Sequencial: objeto passivo, cuja
semântica é garantida somente na presença de
um único caminho de controle.
• “Blocking Object”: objeto passivo, cuja
semântica é garantida na presença de múltiplos
caminhos de controle.
• Objeto Concorrente: objeto ativo, cuja
semântica é garantida na presença de múltiplos
caminhos de controle.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
113
“Containing RelationShips”
• Objetos Compostos ou Agregados: trata-se de
objetos que contêm outros objetos.
• reduz o número de objetos visíveis.
• Há um maior acoplamento entre os dois
objetos.
• Ex.: um objeto apartamento pode incorporar os
objetos cozinha, área de serviço, sala de jantar,
quartos, varanda, etc...
• Exemplo em C++:
class Ponto {
int x;
int y;
};
class Circulo {
int raio;
Ponto centro;
};
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
114
A Natureza de uma Classe (i)
• Um objeto é uma entidade concreta, que existe
no tempo e no espaço.
• Uma classe representa uma abstração, a
essência de um objeto ou de vários objetos.
• Uma classe pode ser pensada como: um grupo,
conjunto ou gênero, cujos elementos possuem
atributos em comum; uma divisão do grupo,
separação ou classificação baseada na
qualidade, grau de competência ou condição.
• em OOP: Uma classe é um conjunto de
objetos que compartilham uma estrutura e
comportamento comuns.
Um objeto é uma instância de uma classe.
• A classe captura a estrutura e comportamento
comuns a todos os objetos relacionados. É uma
espécie de “contrato” entre uma abstração e
todos os seus clientes.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
115
A Natureza de uma Classe (ii)
• Uma LP fortemente tipada (“strongly typed”)
detecta violações de contrato em tempo de
compilação.
implementation
interface
interface
visão interna
visão externa
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
116
A Natureza de uma Classe (iii)
• a “interface” de uma classe proporciona a
visão externa da classe
• enfatiza a abstração
• oculta a estrutura e segredos de seu
comportamento
• A “interface” consiste basicamente de:
– declarações de todas as operações (métodos)
aplicáveis às instâncias da classe;
– pode incluir declarações de outras classes,
constantes, variáveis e exceções necessárias para
complementar a abstração
• a implementação da classe provê a sua visão
interna, os segredos de seu comportamento;
basicamente consiste da implementação de
todas as operações definidas em sua interface.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
117
Interface
A interface de uma classe pode ser dividida em
três partes:
• Public:declaração que forma parte da interface
da classe e é visível para todos os clientes que
são visíveis a ela.
• Protected: declaração que forma parte da
interface da classe, mas que não é visível a
quaisquer outras classes, exceto suas
subclasses.
• Private: declaração que forma parte da
interface da classe, mas que não é visível a
quaisquer outras classes.
C++ é a linguagem mais indicada para
explicitar as diferentes partes da interface da
classe (possui, ainda, as classes “friendship”)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
118
Estado do Objeto (i)
• O estado de um objeto deve ter alguma
representação que seja tipicamente expressa
como declarações de constantes e variáveis,
situadas na parte privada da interface da
classe.
• Desta forma, a representação comum dos
objetos de uma classe é encapsulada e
alterações nesta representação não afetarão a
funcionalidade de quaisquer clientes.
• Por que a representação de um objeto é parte da
interface de uma classe (ainda que private) e não de sua
implementação?
Se definíssemos a representação de um objeto na
implementação de uma classe, teríamos que completála, antes que pudéssemos usar quaisquer clientes.
Frustaríamos, assim, o propósito de separar a visão
externa da visão interna.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
119
Estado do Objeto (ii)
• Denominação das constantes e variáveis que
integram a representação de uma classe:
–
–
–
–
“instance variable”
“field”
“member object “
“slot”
- Smalltalk
- Object Pascal
- C++
- Clos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
120
Relações entre Classes (i)
• As classes, como os objetos, não existem
isoladas.
• As abstrações chaves, normalmente estão
relacionadas, formando a estrutura de classes
do projeto.
• Uma relação entre classes indica:
– alguma forma de compartilhamento
(ex.: margaridas e rosas têm pétalas)
– alguma forma de conexão semântica
(ex.: rosas vermelhas e amarelas são
similares)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
121
Relações entre Classes (ii)
Há 3 tipos de relações básicas entre classes:
• generalização (tipo de - “kind of”): indica que
uma classe é uma subclasse de uma outra
classe mais geral.
(ex.: rosa x flor)
• agregação (“part of”): indica que uma classe
é parte de outra.
(ex.: pétala x flor)
• associação: indica alguma conexão semântica
entre 2 classes.
(ex.: rosas x candelabros --> decoração)
• As LPs possuem diversos mecanismos para
expressar estas relações, destacando-se as
relações de: herança, uso, instanciação,
metaclasse.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
122
Herança (i)
• Herança: pode ser usada para expressar
generalização e associação.
Ex.: Dados de Telemetria
Dados de diferentes subsistemas (energia e
propulsão) e de diferentes sensores (radiação,
espectômetro de massa, temperatura,
detectores de colisão com micrometeoros,
etc...)
Os dados telemétricos são usualmente transmitidos
como uma seqüência de bits, consistindo de um
“header”, o qual inclui um “time stamp” e alguma chave
para identificar o tipo de informação que se segue, mais
vários “frames” dos dados processados pelos vários
subsistemas e sensores.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
123
Herança (ii)
struct time {
int elapseDays;
int seconds;
};
struct ElectricalData {
Time
timeStamp;
int
id;
float
fuelCell1Voltage,
fuelCell2Voltage;
float
fuelCell1Amperes,
fuelCell2Amperes;
float
currentPower;
};
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
124
Herança (iii)
Problemas:
• A representação de ElectricalData não está encapsulada.
• Os clientes podem alterar valores de dados importantes.
• A estrutura está exposta. Qualquer mudança na mesma
impactaria todos os clientes. Todas as referências à
estrutura deveriam ser recompiladas.
• As alterações dos clientes podem violar as assunções
que eles tinham sobre a representação e ocasionar erros
nos programas.
• Operações diversas podem aplicar-se a instâncias da
estrutura, mas não há meios de se associar estas
operações à estrutura.
• Há o problema de redundância, no caso de precisarmos
representar centenas de diferentes tipos de dados de
telemetria que incorporem a representação de
ElectricalData e que incluam outros dados adicionais.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
125
Herança (iv)
• Solução (i):
Declarar uma classe para cada tipo de dado de
telemetria.
Ocultamos a representação de cada classe
e associamos os dados às operações aplicadas
sobre os mesmos.
Todavia, não resolvemos o problema da
redundância.
• Solução (ii):
Construir uma hierarquia de classes, em que
classes especializadas herdam a estrutura e
comportamentos definidos pelas classes mais
gerais.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
126
Herança (v)
class TelemetryDate {
public:
TelemetryData (); /* construtores */
TelemetryData (const TelemetryData&);
virtual ~TelemetryData (); /* destrutor */
virtual void send ();
Time currentTime () const;
protected:
int id;
private:
Time timeStamp;
};
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
127
Herança (vi)
class ElectricalData: public TelemetryData {
public:
ElectricalData (float v1, float v2, float a1,
float a2);
ElectricalData (const ElectricalData&);
virtual ~ElectricalData ();
virtual void send ();
virtual float currentPower () const;
protected:
float fuelCell1Voltage, fuelCell2Voltage,
float fuelCell1Amperes, fuelCell2Amperes;
};
• Esta nova classe herda a estrutura e métodos da classe
TelemetryData, mas adiciona sua estrutura e redefine
seu comportamento (no caso, o método send).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
128
O significado da herança entre classes
• Herança: É uma relação entre classes em que
uma classe compartilha a estrutura e o
comportamento definido em uma classe
(herança simples), ou em várias classes
(herança múltipla).
• Superclasse: é a classe da qual se herda.
• Subclasse: é a classe que herda.
• Herança define uma hierarquia “tipo
de”(“kind of”) entre classes.
• Uma subclasse tipicamente aumenta ou
redefine a estrutura e comportamento de suas
superclasses.
• A capacidade de suportar herança é o que
distingüe as LPs baseadas em objeto (“Object
Based”) das LPs Orientadas a Objeto (“Object
Oriented”).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
129
Relações de Herança Simples entre Classes
Telemetry
Data
Electrical
Data
Sensor
Data
Propulsion
Data
Spectometer
Data
Camera
Data
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
Radiation
Data
130
Classes Abstratas
• Classes Abstratas: não são instanciadas.
Em C++ pode-se assegurar que um método de
uma classe seja invocado diretamente. Para
tanto, inicializa-se a sua declaração com zero.
(“pure virtual function”)
C++ proíbe a criação de instâncias de classes
que exportam métodos puramente virtuais.
• Classe Base: é a classe mais geral de uma
estrutura.
• Uma dada classe possui dois tipos de clientes:
– instâncias (objetos)
– subclasses
• Interfaces para estes 2 tipos de clientes são
definidas. Em C++ pode-se escolher que
membros são visíveis para instâncias (objetos),
subclasses, ou ambos.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
131
O Significado do Polimorfismo
• Para entendermos o significado de uma classe
particular devemos, muitas vezes, estudar suas
superclasses, incluindo a sua visão externa.
• Em C++ os métodos declarados como virtuais
em uma classe podem ser redefinidos em suas
subclasses. Os outros métodos, não.
• Polimorfismo: é um conceito na Teoria dos
Tipos (“Type Theory”) no qual um nome pode
denotar objetos de várias classes diferentes,
que são relacionadas por alguma superclasse
comum. Assim, qualquer objeto denotado por
este nome está habilitado a responder a um
conjunto comum de operações em diferentes
modos.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
132
Polimorfismo: Exemplos (i)
• Ex.: Para a classe TelemetryData poderíamos
implementar a função membro send como se
segue:
void Telemetry::send () {
// transmit the id
// transmit the timeStamp
};
• Implementação de send para a classe
ElectricalData:
void ElectricalData::send () {
TelemetryData::send ();
// transmit the fuellCell1Voltage and
//
fuellCell2Voltage
// transmit the fuellCell1Amperes and
//
fuellCell2Amperes
};
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
133
Polimorfismo: Exemplos (ii)
• Supor a existência de instâncias das 2 classes:
TelemetryData telemetry;
ElectricalData electrical (5.0, -5.0, 3.0, 7.0);
• Supor que os objetos telemetry e electrical
foram criados. Se tivermos a função:
void sendTelemetryData (TelemetryData &D) {
d.SEND ();
};
• O que acontece quando fazemos ?
sendTelemetryData (telemetry);
sendTelemetryData (electrical);
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
134
Polimorfismo
• Sem polimorfismo, a alternativa seria o uso de
vários comandos “switch”.
• Polimorfismo é mais útil quando coexistem
várias classes com o mesmo protocolo.
• Polimorfismo e “late binding” andam de mãos
dadas.
• Em C++ o programador pode decidir se uma
função membro usará “late binding” ou “early
binding”.
virtual method
“late binding”
polimorfismo
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
135
Herança e Tipos
• A maior parte das LPS permite à
implementação de um método de uma
subclasse invocar um método definido por
alguma superclasse.
• É comum, para a implementação de um
método redefinido, invocar o método de
mesmo nome definido pela sua classe pai.
• Em C++, pode-se invocar o método de qualquer
antecessor (enquanto o mesmo for visível)
prefixando-se o nome do método com o nome
da classe.
• Um objeto pode referenciar-se a si mesmo
usando o “pointer” implicitamente declarado
“this”.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
136
Polimorfismo: Invocação de Métodos (i)
Shape
Circle
Triangle
Rectangle
Solide
Rectangle
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
137
Polimorfismo: Invocação de Métodos (ii)
Cliente x
Desenhar
n
fig. 1
Lista de Figuras
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
138
Tipos x Relações de Herança
• Uma atribuição de um objeto X para um objeto
Y (Y = X ) é possível se o tipo de X é o
mesmo que o tipo de Y, ou um subtipo de Y.
TelemetryData telemetry;
ElectricalData electrical (5.0, -5.0, 3.0, 7.0);
• comando legal:
telemetry = electrical; //electrical é um
subtipo de telemetry
• comando ilegal:
electrical = telemetry; //telemetry não é um
subtipo de electrical
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
139
Herança Múltipla (i)
• Dois problemas relacionados à herança
múltipla:
– i) como lidar com a colisão de nomes de
superclasses diferentes (métodos e/ou variáveis de
instância com o mesmo nome).
– ii) como manipular heranças repetidas (uma classe
que é antecessora de outra por duas vias distintas).
• Abordagem para solucionar i):
– a semântica da linguagem (sl) poderia encarar uma
colisão de nomes como ilegal e recusar a
compilação da classe.
– a sl poderia assumir que o mesmo nome, introduzido
por diferentes classes, refere-se ao mesmo “slot”
(Clos).
– a sl permite a colisão, mas requer que as referências
ao nome sejam totalmente qualificadas (C++).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
140
Herança Múltipla (ii)
• abordagem para resolver ii):
– tratar as ocorrências de heranças repetidas
como ilegais;
– pode-se permitir duplicação de
superclasses, mas se requer o uso de nomes
totalmente qualificados para se referenciar
a membros de uma cópia específica (C++);
– pode-se tratar múltiplas referências à uma
classe como denotando a mesma classe
(C++, quando a superclasse repetida é
introduzida como uma classe base virtual).
• Polimorfismo Múltiplo:
Multi-métodos que são especializados em mais
que um parâmetro.
Display
DisplayDevice
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
141
Relações de Uso entre Classes
• duas possibilidades:
– a “interface” de uma classe pode usar outra
classe.
– a “implementation” de uma classe pode
usar outra classe
TLibrary
“interface”
1
“implementation”
1
n
1
TBook
TList
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
142
Herança Múltipla x Relações de Uso
• Se uma abstração é maior que a soma das
partes componentes, então as relações de uso
são mais apropriadas.
• Se uma abstração é um tipo de alguma outra
abstração, ou ela é exatamente igual à soma de
seus componentes, então a abordagem mais
indicada é a herança.
===================================
• Relações de Instanciação
Em uma LP fortemente tipada (“strongly
typed”), pode-se usar todas as oportunidades
para se aplicar a coerção de tipos, a fim de
capturar e forçar as nossas decisões de projeto.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
143
“Container Classes” (i)
• Um set (conjunto) é um exemplo de “container
class”, cujas instâncias são coleções de outros
objetos.
• 4 possibilidades para construir-se “Container
Classes”:
i) via o uso de macros (e.g. C++)
Só funciona em pequena escala, porque manutenção
das macros é deselegante e trabalhosa.
Cada instanciação resulta em uma nova cópia do
código.
ii) herança e “late binding” (Smalltalk)
Com esta abordagem pode-se construir somente
classes de agrupamento heterogêneas, porque não há
modo de declarar a classe específica dos elementos
do agrupamento. Cada ítem é tratado como se fosse
uma instância da classe base Object.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
144
“Container Classes” (ii)
iii) Usa-se a abordagem comumente utilizada em
Object Pascal. Constrói-se classes de agrupamento
generalizadas, como em Smalltalk, mas então usa-se
código de “type checking” explícito para forçar a
convenção de que os conteúdos sejam todos da
mesma classe, o que é afirmado quado o “container
object” é criado.
iv) usa-se classes parametrizadas (CLU) ou classes
genéricas.
Servem de “templates” para outras classes. Podem
ser parametrizadas por classes, objetos, e/ou
operações.
Uma classe parametrizada deve ser instanciada antes
que objetos possam ser criados.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
145
Relações de Metaclasse
• Uma metaclasse é uma classe cujas instâncias
são, elas mesmas, classes.
– suportadas em CLOS e Smalltalk
– C++ não suporta explicitamente metaclasses.
Todavia, provê variáveis de classe e
métodos de classe.
– Basta declarar um “member object” ou
“member function” como static, o que
significará que será compartilhado por
todas as instâncias da classe.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
146
Relações entre Classes e Objetos
• Cada objeto é uma instância de alguma classe
• Toda classe possui zero ou mais instâncias
• Classes são estáticas. Sua existência,
semântica e relações são fixadas anteriormente
à execução de um programa.
• A classe da maioria dos objetos é estática.
Uma vez criado o objeto, a sua classe é fixada.
• Objetos são criados e destruídos durante a vida
da aplicação.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
147
O Papel das Classes e Objetos no Projeto
(“Design”)
• Na fase de análise e etapas iniciais do projeto
há duas tarefas principais:
– identificar as classes e objetos que formam
o domínio do problema.
– Inventar as estruturas em que conjuntos de
objetos trabalhem cooperativamente para
prover o comportamento global que
satisfaça os requisitos do sistema.
• “Key abstractions” (classes e objetos)
• “mechanisms of implementation” (as
estruturas cooperativas)
• visão externa / estrutura lógica do sistema
após
visão interna / estrutura física
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
148
Mensurando a Qualidade da Abstração (i)
• Um sistema deve ser construído com um
conjunto mínimo de partes imutáveis.
• Estas partes devem ser tão gerais quanto
possível.
• Todas as partes do sistema devem compor uma
estrutura uniforme (Ingalls, p. 123 Booch)
• O projeto das classes e objetos é um processo
incremental e interativo (experiência do
Booch)
• Métricas para saber se uma classe ou objeto
está bem projetado:
–
–
–
–
–
Acoplamento (“Coupling”)
Coesão (“Cohesion”)
Suficiência (“Sufficiency”)
Completude (“Completeness”)
“Primitiviness”
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
149
Mensurando a Qualidade da Abstração (ii)
• Acoplamento: medida do grau de associação
estabelecido pela conexão entre módulos.
Pode-se reduzir a complexidade através de sistemas
projetados com o mínimo grau de acoplamento possível.
Há uma tensão entre os conceitos de acoplamento e
herança.
• Coesão: mede o grau de conectividade entre os
elementos de um mesmo módulo (objeto ou
classe)
coesão funcional: em que todos os elementos de uma
classe ou módulo atuam em conjunto para prover um
comportamento bem delimitado. É a forma mais
desejada.
coesão acidental: em que abstrações não relacionadas
entre si são agrupadas em uma classe ou módulo. É a
menos desejada.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
150
Mensurando a Qualidade da Abstração (iii)
• Suficiência: Propriedade da classe ou módulo
que captura bastante características da
abstração, de modo a permitir uma interação
eficiente e plena de significado.
• Completude: quando a interface da classe ou
módulo captura toda as características
significativas da abstração.
Enquanto suficiência implica em uma interface mínima,
uma interface completa é aquela que cobre todos os
aspectos da abstração.
Uma classe (ou módulo) completa é aquela cuja
interface é bastante geral, de modo a ser usada por
qualquer cliente.
Operações Primitivas são aquelas que podem ser
eficientemente implementadas, somente tendose acesso à representação interna da abstração.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
151
Heurísticas Para a Escolha de Operações (i)
• Dentro de uma classe as operações (métodos)
devem ser primitivas, de modo a exibirem um
comportamento bem delimitado e bem
definido.
• Separar métodos que não se comunicam.
Desta forma é mais fácil construir subclasses
que redefinam, com sentido, o comportamento
de suas superclasses.
• É comum, em OOD, projetar-se os métodos de
uma classe como um todo, visto que estes
métodos cooperam entre si para formar o
protocolo da abstração.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
152
Heurísticas Para a Escolha de Operações (i)
• Dado um comportamento devemos decidir em
que classe incorporá-lo. Critérios:
– Reusabilidade: o comportamento será útil
em mais de um contexto?
– Complexidade: qual a dificuldade em se
implementar o comportamento?
– Aplicabilidade: quão relevante é o
comportamento para o tipo (classe) em que
poderia ser implementado?
– Conhecimento da Implementação: a
implementação do comportamento depende
dos detalhes internos do tipo (classe)?
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
153
Heurísticas Para a Escolha de Relações (ii)
• Florestas x Árvores
As florestas são mais fracamente acopladas,
porém não exploram os aspectos comuns
existentes entre as classes.
As árvores exploram os aspectos comuns,
porém, para entendermos uma classe
determinada, precisaremos conhecer todas as
classes das quais ela herda seus métodos e/ou
atributos.
• Herança x Relações de Uso
Herança é mais apropriada quando toda
instância de B pode também ser vista como
uma instância de A.
A relação de cliente é mais apropriada quando
quando toda instância de B simplesmente
possui um ou mais atributos de A.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
154
Análise Orientada a Objetos (AOO)
• AOO é um modelo para cpaturar os requisitos
do usuário para um sistema. Baseia-se na OO.
• Dois Exemplos:
– Sistema tradicional de processamento de
dados para gerenciar a publicação e
distribuição de uma revista para os seus
assinantes.
– Sistema de controle de processos para
controlar um elevador.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
155
A Descoberta de Objetos (i)
• O ponto mais importante de uma metodologia
OO é o processo de descobrir que classes e
objetos serão incluídos no modelo.
• Motivação: A descoberta de objetos como
parte do modelo de requisitos é a crença de
que uma representação técnica OO do sistema
estará mais próxima da visão conceitual do
usuário sobre o sistema, que em qualquer outro
modelo adotado.
• Os usuários não pensam em termos de funções
ou entidades. Eles pensam em termos de
objetos. (Todavia, não há provas ...)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
156
A Descoberta de Objetos (ii)
• A descoberta dos objetos essenciais depende
da perspectiva adotada
– dados
– funcional
– comportamental
• Objetos constituem uma métafora natural para
descrever certas aplicações
– GUI front-ends
– arquiteturas cliente-servidor
– processamento de dados distribuídos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
157
Notação Gráfica Para Classes e Objetos (i)
• História:
– DFD’s (“data-flow diagrams”, “bubles” DeMArco, “bubtangles” - GANE-Sarson)
– ERDs (“entity-relationship diagrams”)
• Notação do Yourdon para classes:
nome da classe
atributos
métodos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
158
Notação Gráfica Para Classes e Objetos (ii)
• Notação para Objetos
nome da classe
atributos
métodos
• Notação do Booch
class-name
utility
class-name
object-name
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
159
Notação Gráfica Para Classes e Objetos (iii)
• A escolha da notação
– o analista deve escolher a notação mais
adequada para seus propósitos.
– poder de expressão.
– formal e rigorosa para evitar ambigüidades.
– simples, de forma a ser entendida pelos
usuários.
• Anecessidade dos diagramas aparece quando
iniciamos:
– a construção da hierarquia dos objetos
– a documentação das relações entre objetos
– o detalhamento da comunicação entre
objetos
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
160
Como Encontar Objetos (i)
1. A Perspectiva dos Dados
• aplicar em sistemas em que os dados refletem
as características dominantes do sistema.
• estratégia similar à de descobrir entidades em
um ERD.
• Peter Coad e Yourdon sugerem examinar:
– o domínio do problema, diagramas, figuras e
informações textuais fornecidas pelos usuários.
– interfaces de outros sistemas com o sistema em
questão.
– dispositivos que interagem com a aplicação.
– eventos que deverão ser registrados e relembrados
pelo sistema.
– localizações geográficas que possam ser importantes
para o sistema.
– unidades organizacionais (departamentos, divisões,
etc ...) relevantes para o sistema.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
161
Como Encontar Objetos (ii)
2. A Perspectiva Funcional
• Caracterização dos objetos pelo que eles fazem
• “CRC cards “Class-Responsabiblity-Communication”
– a que classe o objeto pertence?
– que responsabilidades ele possui? que
funções exerce?
– Como ele se comunica com os outros
objetos?
Atenção:
Cuidado para não corromper o Sistema
Orientado a Objetos construindo um modelo
completamente funcional dos requisitos do
usuário.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
162
Como Encontar Objetos (iii)
3. A Perspectiva Comportamental
• Questão Fundamental: Como os objetos se
comunicam?
• Como respondem a mensagens, sinais,
interrupções e outras formas de comunicação?
• Mais voltada para sistemas em tempo real e
sistemas distribuídos.
• Uma visão mais minuciosa do comportamento
dos objetos tipicamente introduz um ou mais
tipos de diagramas adicionais no processo de
AOO.
Diagramas de: transição de estados e de
comunicação de eventos ou interação entre
objetos, para ilustrar a comunicação entre
objetos).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
163
Como Encontar Objetos (iv)
Yourdon sugere:
1. Desenvolver uma lista de eventos ou estímulos
externos aos quais o sistema deva responder.
Tipicamente, cada fluxo de dados de entrada
no diagrama de contexto corresponderá a um
evento na lista de eventos.
2. Projete um diagrama de fluxo de dados inicial
em que cada evento de entrada é capturado por
uma única bolha DFD.
3. Identificar as etapas de processameto
necessárias para o sistema para o sistema
responder ao evento de modo satisfatório.
(Nesta etapa poderá haver a geração de minisDFDs).
4. Agregue os minis-DFDs gerados na etapa 3.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
164
Como Encontar Objetos (v)
5. Para produzir um DFD em níveis, particione
algumas bolhas, usando o processo de
decomposição funcional.
Uma atividade mais importante diz respeito à
agregação de “clusters” de bolhas em
superbolhas em um DFD de nível mais
elevado. Este processo poderia ser repetido até
se conseguir uma única superbolha: o
diagrama de contexto para o sistema.
• A racionalidade ou estratégia para se agregar bolhas é
orientada a objetos por natureza (Yourdon, p. 131).
As bolhas de DFD que foram agregadas em uma única
superbolha de mais alto nível correspondem a funções
ou métodos.
A área de armazenamento comum é semelhante aos
atributos de dados das instâncias dos objetos em uma
classe.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
165
Como Encontar Objetos (vi)
• Candidatos a Classes e Objetos (Shlaer e
Mellor)
– coisas tangíveis (carros, sensores de
pressão, dados
telemétricos, etc...)
– papéis
(professor, fiscal, etc...)
– eventos
(aterrisagem, interrupção,
pedido, etc...)
– interações
(empréstimo, encontro,
intersecção, etc...)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
166
Análise de Domínio (“Domain Analysis”)
• AOO focaliza um problema específico de cada
vez.
• A Análise de Domínio procura identificar as
classes e objetos que são comuns a todas as
aplicações de um dado domínio.
Etapas (Moore e Bailin - Booch, p. 112)
• Construir um esboço de um modelo geral do domínio,
através da consulta a especialistas no domínio.
• Examinar os sistemas existentes no domínio e
representar este entendimento em um formato comum.
• Identificar similaridades e diferenças entre os sistemas
pela consulta a especialistas no domínio.
• Refinar o modelo genérico para acomodar os sistemas
existentes.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
167
Critérios Para Avaliar Candidatos a Objetos
(O que se deve procurar nos objetos candidatos em um modelo AOO)
“Smaller is better” / “Small is beautiful”
• Atributos que devem ser relembrados.
• Mais que um atributo (se o objeto proposto
possui apenas um atributo, muito
provavelmente será um atributo enm outro
objeto. Todavia, em sistemas em Tempo Real
existem objetos sem atributos).
• Funcionalidade Necessária: deve ser possível
identificar um ou mais métodos, ou serviços,
para os objetos propostos: o objeto deve fazer
algo para justificar a sua existência (é
altamente improvável um objeto não possuir
métodos ou serviços).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
168
Critérios Para Avaliar Candidatos a Objetos
(O que se deve procurar nos objetos candidatos em um modelo AOO)
• Funcionalidade Essencial: A funcionalidade
ou comportamento que foi identificada para o
objeto proposto deve ser relevante e
necessária, independentemente da tecnologia
de HW e SW que será usada para implementar
o sistema.
• Atributos Comuns: todos os atributos da classe
proposta deveriam aplicar-se a cada uma das
instâncias da classe (objetos).
• Funcionalidade Comum: todos os membros,
ou serviços, da classe proposta deveriam
aplicar-se a cada uma das instâncias da classe.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
169
Subjects
• Para sistemas grandes (centenas de classes) é importante
agrupá-las em “subjects” (“packages”, “kits”, “clusters”,
“subsystems”).
Subject_1
Subject_2
Classe_1
Classe_2
...
Classe_n
Representação gráfica dos “subjects”
• Usa-se o conceito de “subject” para se combinar classes
distintas e discretas, mas não obstante moderadamente
coesas, em um grupo comum.
• abordagem indicada na gregação de objetos em
“subjects”:
– “top-down” - sistemas de grande porte
– “bottom-up”- sistemas de médio e pequeno porte
• Na maioria das metodologias de AOO pode-se ter vários
níveis de “subjects” (exceto Coad & Yourdon)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
170
Estrutura dos Objetos e Hierarquia das
Classes
O passo seguinte à identificação das classes e
objetos é:
• a organização das classes em hierarquias
baseadas no paradigma de herança, presente
nas metodologias OO.
• a modelagem de estruturas “whole-part”
(todo-parte)
PESSOA (classe) é composta de: CABEÇA,
CORPO e MEMBROS.
Obs.: Embora seja impossível evitar-se o pensar em
hierarquias durante a descoberta inicial dos objetos,
usualmente é mais fácil organizar a hierarquia das
classes, uma vez que se tenha uma idéia razoável de
quais são as classes básicas do sistema.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
171
GENERALIZAÇÃO-ESPECIALIZAÇÃO (i)
• Terminologia:
– Generalização-Especialização (gen-spec)
– Superclasse-Subclasse
– Mecanismo de Herança
– “is a hierarchy”
Notação Gráfica:
Superclasse
SubClasse_2
SubClasse_1
Yourdon
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
172
GENERALIZAÇÃO-ESPECIALIZAÇÃO (ii)
Superclasse
SubClasse_2
SubClasse_1
Rumbaugh
SubClasse_2
SubClasse_1
Superclasse
Booch
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
173
GENERALIZAÇÃO-ESPECIALIZAÇÃO
(iii)
subscriber
comp
subscriber
paying
subscriber
individual
subscriber
Martin-Odell
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
174
GENERALIZAÇÃO-ESPECIALIZAÇÃO (iv)
• Questões:
– As especializações de uma estrutura
gen/spec são mutuamente exclusivas?
– A união de todas as especializações cobre o
conjunto descrito pela generalização?
• A perspectiva OO nas hierarquias gen-spec é
inteiramente diferente da abordagem “subtipos
- supertipos” em uma modelagem de dados
típica. Herança é o traço distintivo.
• herança simples x herança múltipla
vantagens: maior poder na especificação das
classes e mais oportunidades para reuso.
desvantagens: perda de simplicidade
conceitual e de implementação.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
175
Herança Múltipla
Subscriber
Person
Comp
Subscriber
Paying
Subscriber
Individual
Subscriber
v
Corporate
Subscriber
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
176
Hierarquia Todo - Parte (“has a”)
• Possibilita que se descreva uma classe em
termos de suas partes componentes, ou subobjetos.
Whole
n1, n2
n5, n6
n3, n4
n7, n8
Part_1
Part_2
Hierarquia de classes na notação Coad- Yourdon
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
177
Hierarquia “has a”: Notação
Assembly Class
Part_2-class
Part_1-class
Rumbaugh
whole
n1, n2
n3, n4
n5, n6
n7, n8
part_1
part_2
Booch
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
178
Hierarquia “has a”
• Cada instância da classe whole deve consistir
de ni instâncias da classe parti, onde
n1<=ni<=n2.
• Alternativamentecada instância da classe parti
pode ser uma parte de mi instâncias da classe
whole, onde n3<=mi<=n4.
• As partes não herdam atributos ou
comportamentos do todo.
• A implementação das estruturas whole-parts é,
em geral, feita através de “pointers”.
O objeto whole terá um ponteiro (ou coleção
de ponteiros) para as suas partes constituintes.
E as partes, tipicamente terão um “pointer”
para o “whole” a que pertencem.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
179
Como Descobrir Hierarquias “Whole-Part”
em um Sistema?
• Em geral, a descoberta destas hierarquias é
intuitiva.
• Refletem o mundo real?
• O sistema necessita de um registro de
ocorrência das partes?
• As partes estão dentro do escopo do sistema
que estamos modelando?
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
180
Relações entre Objetos (i)
Construção do Modelo OO:
I) Criação da classes e objetos.
II) Criação da hierarquia de classes “gen-spec” e
“whole-part”.
III) Relações entre classes e objetos.
Conceitos:
• Uma relação entre classes e objetos é uma
representação estática de uma ‘política do
usuário.
Ex.: Para cada nota fiscal deve existir exatamente um
cliente e, para todo cliente, pode existir zero ou várias
notas fiscais.
• Uma colaboração entre objetos é uma relação
dinâmica e ativa, que tipicamente envolve o
envio de uma mensagem de um para outro
objeto.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
181
Relações entre Objetos (ii)
• A existência de uma relação entre objetos
quase sempre implica a existência de uma
colaboração, embora trate-se de conceitos
independentes (separados).
• Uma relação entre objetos é, em geral,
implementada via “pointers”, enquanto a
colaboração (mensagem) é implementada via
“procedure call”.
Relações Binárias
• Relações (ou conexões entre instâncias) são
estáticas. Não descrevem o comportamento ou
troca de mensagens entre objetos.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
182
Relações entre Objetos (iii)
Class_2
Class_1
n1, n2
n3, n4
Notação Gráfica
• Uma instância da classe_1 é associada com n
instâncias da classe_2, n1<=n<=n2; e uma
instância da classe_2 é associada com m
instâncias da classe_1, n3<=m<=n4.
• n1 ou n3 = 0 indica uma relação opcional;
senão, a relação é mandatória.
• Se os limites inferior e superior são idênticos,
a cardinalidade é expressa como um único
inteiro.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
183
Relações entre Objetos (iv)
Class_1
Class_2
Notação “Crow’s feet” para relações binárias.
Cada instância da classe_1 é associada com
zero ou mais instâncias da classe_2; cada
instância da classe_2 é associada com uma, e
somente uma, instância da classe_1.
• Um diagrama de relações entre objetos é essencialmente
o mesmo que um diagrama ER
PASSOS:
• determinar se existe alguma relação entre um dado par
de classes.
• determinar se a relação é opcional ou mandatória.
• determinar a multiplicidade da relação.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
184
Relações entre Objetos (v)
CUSTOMER
ORDER
PRODUCT
SALES-PERSON
Relação envolvendo quatro classes e Objetos
• Relações de mais alta ordem são complicadas
de se visualizar, implementar e pensar que as
associações binárias e devem ser evitadas tanto
quanto possível.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
185
Relações entre Objetos (vi)
Casos Especiais de Relações
• Conexões de instância “many-to-many”
(vários x vários)
• Conexões de instância recursivas
• Conexões de instância múltiplas entre classes
• Conexões unárias entre classes
PRODUTO
CLIENTE
0,N
0,N
Uma Relação N:N
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
186
Relações entre Objetos (vii)
CLIENTE
PRODUTO
COMPRAS
0,N
1,N
1
0,N
Introduzindo uma nova classe em uma situação N:N
CLIENTE
COMPRAS
PRODUTO
data
quantidade
A Notação de Rumbaugh para atributos “link”
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
187
Outra Abordagem para o Problema
CLIENTE-PRODUTO
Cliente
Produto
Cliente
Comprador
Cliente
Não-Comprador
1, N
1, N
Produto
Comprado
Produto
Não-Comprado
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
188
Relações entre Objetos (viii)
gerencia
PESSOA
0, N
1
é gerenciado por
Relação Recursiva
CLIENTE
0,N
PRODUTO
compra
0,N
0, 3 recomenda
0, 1
Relações Múltiplas entre Classes
(mais de uma relação entre um par de classes)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
189
Relações entre Objetos (ix)
• Conexões unárias entre classes
(nem sempre as relações são binárias)
Ex.: Eu conheço muito sobre a personalidade
XXX. Será que a personalidade XXX conhece
muito sobre mim?
• Uma forma de representar as relações
unidirecionais seria incluir os limites de
cardinalidade em apenas uma direção, aquela
na qual a relação é válida.
ALTEZA
SÚDITO
0,N
0, N
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
190
Relações entre Objetos (x)
• Conseqüências das Conexões Mandatórias ao
Inserir e Excluir Instâncias:
FABRICANTE
1,N (C)
(D)
PRODUTO
1
• Em alguns casos uma das classes deve ser
considerada como uma classe controladora.
• Se uma instância é excluída, então as
instâncias às quais ela se conecta via uma
relação deveriam também ser excluídas
(relação controladora).
• Questão similar ocorre quando uma nova
instância de uma classe é criada e o modelo
indica que a classe é relacionada a outras
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
191
Atributos dos Objetos (i)
• O Modelo AOO deve incluir a definição dos
atributos para as classes e objetos.
• Os atributos descrevem dados que são ocultos
dentro da classe e objeto e invisíveis ao mundo
externo.
• Os atributos são manipulados (operados) pelos
métodos (serviços) na classe e objeto.
• Os atributos descrevem o estado de um objeto,
enquanto os métodos descrevem o seu
comportamento.
Nome da Classe
atributo_1
…
atributo_n
métodos
Notação Gráfica
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
192
Atributos dos Objetos (ii)
• Adicionalmente usa-se os atributos para
descrever a conexão entre objetos, sob a forma
de “pointers”.
Como Descobrir os Atributos
• O analista deve estudar a aplicação, entrevistar
o usuário e tentar aprende r tanto quanto
possível acerca da verdadeira natureza de cada
classe e objeto do modelo.
(Não há mágica!)
AColocação dos Atributos na Hierarquia de
Classes
• Os atributos das estruturas “gen-spec” de mais
alto nível são automaticamente herdados pelas
subclasses abaixo.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
193
Atributos dos Objetos (iii)
• Todavia, existem diversas situações em que
atributos são inicialmente descritos nas
subclasses. Até que nível da hierarquia deverão
ascender?
Revendo a Hierarquia de Classes
• O processo de revisão deverá resultar num rearranjo da
hierarquia de classes.
• O analista deverá definir os valores legais para os
atributos.
• Atributos com valor “NA - não aplicável” indicam que
não se trata de uma classe simples, porém de uma
estrutura “gen-spec”.
• Objetos com um só atributo podem se tornar, eles
mesmos, um atributo de outro objeto.
• As relações (binárias) entre classes e objetos são
tipicamente implementadas como atributos. Elas são
parte do ESTADO do objeto. Tipicamente não são
incluídas na lista de atributos do objeto.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
194
O Comportamento dos Objetos
• O aspecto dinâmico dos objetos reflete-se em
seu comportamento (envio de mensagens para
outros objetos).
• Modelos de sistemas dependentes da variável
tempo são importantes em:
controle de processos, comutação telefônica,
sistemas de aquisição de dados de alta
velocidade, sistemas de controle em tempo
real, “embedded systems”, etc…
• Nos sistemas de controle de processos e nos
“embedded systems” uma parte importante da
especificação é a descrição do que acontece e
quando. Aplicações com estas características
já são comuns em aplicações comerciais.
• Daí a necessidade de ferramentas de
modelagem que considerem o comportamento
dependente do tempo.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
195
Diagramas “Object Life-History” - OLH (i)
• Os principais elementos do diagrama são:
– retângulos, representando estados
– flechas, representando a mudança de
estados
idle
waiting
for call
recording
message
rewinding
playing
messages
answering
call
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
196
Diagramas OLH (ii)
• Estado: um conjunto de circunstâncias ou
atributos caracterizando uma pessoa ou coisa
em um dado momento; forma ou estado de ser;
condição.
• Os estados representam condições observáveis
em que um sistema pode estar. Assim, um
estado representa algum comportamento do
sistema que seja observável e que dure por
algum intervalo de tempo finito.
• Cada classe tem o seu próprio diagrama OLH,
que descreve o seu microcosmo.
• Pode-se também imaginar um diagrama OLH
único para o sistema em sua totalidade, o qual
representaria a agregação dos OLHs de todos
os objetos do sistema.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
197
Diagramas OLH (iii)
• Solução de Compromisso Prática: Diagrama
de Transição de Estados para descrever o
comportamento de grupos de objetos
cooperantes.
• Envolve o desenvolvimento de um modelo da
história da vida das relações entre classes e
objetos.
• Também é possível desenvolver estes
diagramas a partir da perspectiva das classes e
objetos individuais.
• Alterações de Estado: Normalmente há regras
estabelecendo quais as mudanças de estado
permissíveis.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
198
Diagrama de Transição de Estados
estado_1
estado_2
estado_3
estado_4
estado_5
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
199
Diagramas OLH (iv)
• Condições e Ações: Complementam o
diagrama OLH. As condições acarretam
mudanças de estado no objeto e as ações que o
objeto efetuará ao mudar de estado.
• Uma condição é normalmente um evento
externo ao objeto, capaz de ser detectado; em
geral é uma mensagem enviada por um outro
objeto.
• Em virtude de ter mudado de estado, o objeto
tipicamente efetua algumas ações: impressão
de uma mensagem, realização de cálculos,
apresentação de uma figura, etc...
• Particionamento do Diagrama de Estados
(No caso de diagramas de estado em vários
níveis).
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
200
Construção dos Diagramas OLH
• Identificar todos os estados possíveis
• Explorar todas as conexões possíveis entre os
estados.
Checkout:
•
•
•
•
Todos os estados foram definidos?
Pode-se alcançar todos os estados?
Pode-se sair de todos os estados não-iniciais?
Em cada estado o objeto responde
apropriadamente a todas as condições
possíveis? Inclusive aquelas condições não
muito freqüentes e inesperadas?
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
201
Relações entre o Diagrama OLH e o
Diagrama de Comunicação entre Objetos (i)
• As condições no OLH tipicamente correspondem a
mensagens recebidas pela classe.
• As ações no OLH correspondem a mensagens enviadas
para outros objetos.
• Diagramas OLH são úteis para todos os objetos em
alguns sistemas e para alguns objetos em todos os
sistemas.
• Os diagramas OLH são úteis como ferramentas
informais de “brainstorm” para ajudar na descoberta de
métodos.
• Diagramas OLH facilitam a documentação e explicação
de comportamentos complexos de classes e objetos e na
correção e consistência dos modelos.
Em que estado um objeto deve estar antes :
– i) de ser capaz de aceitar e responder a uma dada
mensagem?
– ii) antes que possa estabelecer uma conexão de
instância (ou quebrar a conexão) com outro objeto?
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
202
Relações entre o Diagrama OLH e o
Diagrama de Comunicação entre Objetos (ii)
classe_1
classe_2
X
estado_1
recebeu msg X
envia msg ‘b’
Y
b
a
classe_3
estado_2
classe_4
recebeu msg Y
envia msg ‘a’
estado_3
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
203
Diagramas OLH (v)
Conclusão:
• O diagrama OLH deve ser opcional.
• Apenas para classes e objetos cujos
comportamentos sejam intrinsecamente
complexos e após uma discussão inicial com o
usuário.
• Considerar diagramas OLH para relações
conectando objetos em “cluster” colaborativos.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
204
Serviços dos Objetos (i)
• Um serviço (método) é um processo
conduzido por um objeto, quando ele recebe
uma mensagem especificamente a ele
direcionada.
• As mensagens são documentadas por uma
flecha que parte da classe/objeto-origem, para
a classe/objeto-destino.
classe_1
método_1
método_2
Representação gráfica de um serviço
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
205
Serviços dos Objetos (ii)
Dentro de uma perspectiva metodológica deve-se:
i) descobrir que serviços são requeridos pelas
classes e objetos;
ii) documentar as mensagens usadas pelas classes
e objetos para comunicar-se umas com as
outras;
iii) especificar minuciosamente a política de
negócios do usuário para cada um dos serviços
identificado.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
206
Descobrindo os Serviços Necessários
Existem 5 tipos de serviços fundamentais:
• implícitos, tais como: criar, modificar, procurar
e excluir.
• associados com conexões de mensagens.
• associados com conexões de instâncias.
• associados com atributos.
• requeridos pelo diagrama OLH.
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
207
Documentando as Conexões de Mensagens (i)
classe_1
classe_2
métodos
métodos
Envio de mensagem para um objeto
classe_1
classe_2
métodos
métodos
Envio de mensagem para uma classe
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
208
Documentando as Conexões de Mensagens (ii)
classe_1
classe_2
x
método_1
método_2
método_3
y
método_4
Uma conexão de mensagens em mais minúcias
classe_1
método_1
método_2
Um objeto enviando mensagem para si mesmo
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
209
Especificando os Serviços em Minúcias
• Descrever o comportamento, em detalhes, para
cada objeto.
• Cada serviço descreve uma função a ser
conduzida após a recepção de uma mensagem.
Se os atributos foram bem definidos, então
cada serviço será pequeno e altamente coeso.
• Usar:
– português estruturado
– diagramas de ação
– fluxogramas
– diagramas de Nassi-Shneiderman
– tabelas de decisão
– linguagens de alto nível (ex.: ADA)
05/96 Copyright by Oscar Luiz Monteiro de Farias, D.Sc.
210