Sistemas Orientados a Objetos
description
Transcript of Sistemas Orientados a Objetos
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 1
SistemasOrientados 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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 2
Programming
Programming in The Large Programming in The Small
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 3
Programming in The Small
• Exemplos:
– alguns trabalhos acadêmicos
– programas simples
• Características:
– poucas linhas de código (dezenas ou centenas)
– apenas um programador
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 4
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 5
Sistemas
Simples Complexos
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 6
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
• ...
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 7
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 8
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 9
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 10
• 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
Dificuldades em se Gerenciar o Processo de Desenvolvimento
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 11
Problema Capital
Manter a unidade e a integridade do projeto
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 12
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 13
• Nos sistemas contínuos, pequenas alterações na entrada sempre ocasionarão pequenas alterações na saída
x y
x + dx 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
O Problema de se caracterizar o comportamento dos Sistemas Discretos (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 14
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 15
• 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
A Flexibilidade do “Software”
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 16
• 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?
Conseqüências da Complexidade sem Limites
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 17
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 18
• 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
Exemplos de Sistemas Complexos (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 19
Exemplos de Sistemas Complexos (iii)
Memória HDD Monitor Teclado
CPU
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 20
Exemplos de Sistemas Complexos (iv)
ALUUC BUS
Registradores
Lógica de
Controle
NANDs Gates
CPU
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 21
• 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
Exemplos de Sistemas Complexos (v)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 22
• 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
Exemplos de Sistemas Complexos (vi)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 23
• 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
Exemplos de Sistemas Complexos (vii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 24
• 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
Exemplos de Sistemas Complexos (vii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 25
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 26
• 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.
Os 5 Atributos dos Sistemas Complexos (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 27
• 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
Os 5 Atributos dos Sistemas Complexos (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 28
• 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)
Os 5 Atributos dos Sistemas Complexos (iv)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 29
• 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.
Os 5 Atributos dos Sistemas Complexos (v)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 30
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 31
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 32
• 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
A Forma Canônica de Um Sistema Complexo (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 33
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?
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 34
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 35
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 36
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 37
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 38
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 39
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)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 40
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 41
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 42
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 43
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)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 44
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 - subrotinas, compilação em
separado– ALGOL 60 - estrutura de blocos, tipos de dados– COBOL - descrição de dados,
manipulação de arquivos– Lisp - processamento de listas, ponteiros
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 45
• 3a Geração (1962-1970)– PL/1 - FORTRAN + ALGOL +
COBOL
– ALGOL 68 - sucessor formal do ALGOL 60
– Pascal - outro sucessor do ALGOL 60
– Simula - 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”)
Evolução do Modelo Objeto (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 46
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 47
• 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
A Topologia das Últimas LPs da 2a Geração e das LPs do Início da 3a Geração
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 48
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)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 49
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 50
• 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.
O Modelo Objeto - “The Object Model” (i)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 51
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 52
• 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 ...)
O Modelo Objeto - “The Object Model” (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 53
• 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”.
O Modelo Objeto - “The Object Model” (iv)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 54
• 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)
O Modelo Objeto - “The Object Model” (v)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 55
• 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.
O Modelo Objeto - “The Object Model” (vi)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 56
• 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.
O Modelo Objeto - “The Object Model” (vii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 57
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).
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 58
• 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
Abstração (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 59
• 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).
Abstração (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 60
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.
Abstração (iv)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 61
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 62
• Protocolo: é o conjunto de operações que um cliente pode executar sobre um dado objeto.
– ADA - operation
– Smalltalk - method
– C++ - member function
Abstração (vi)
métodos
variáveis de estado
Objeto
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 63
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
Exemplos de Abstração
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 64
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 65
• 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).
Encapsulamento (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 66
• 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
Encapsulamento (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 67
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).
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 68
• 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
Herança (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 69
Tensão entre os Princípios
Abstração
Encapsulamento Hierarquia
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 70
• 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)
Herança (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 71
Exemplos de Herança
mamíferos
cães
dobermann rotweiller dog alemão
híbrido dobermann + rotweiller
herançasimples
herança múltipla
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 72
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 73
Exemplo de Polimorfismo
move
treinador de circo
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 74
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”.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 75
• 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”
Modularidade (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 76
• 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.
Modularidade (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 77
• A interface de um módulo deve ser a mais simples possível (ocultar tudo o que se puder, no corpo do módulo)
• Modularidade: é a propriedade de um sistema que foi decomposto num conjunto de módulos coesivos e fracamente acoplados (Booch).
Modularidade (iv)
desejo de encapsular as abstrações
tornar certas abstrações visíveis a outros métodos
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 78
• 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
Modularidade (v)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 79
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 80
• 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
Tipos (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 81
• “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
Tipos (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 82
• ADA
strongly & static typed
• Object Pascal & C++
strongly typed & dynamic binding
• Smalltalk
untyped & dynamic binding
Tipos (iv)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 83
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”
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 84
início
fim
Concorrência (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 85
• 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.
Concorrência (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 86
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.
• 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
LPs
Basesde
Dados
OODBObject Model + =Persistence
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 87
• 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).
Persistência (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 88
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”.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 89
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 90
• 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”
Ciclo de Vida dos Projetos Orientados a Objetos (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 91
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 92
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 entidade-relacionamento, não foram bem sucedidos ...
• Reengenharia de negócios
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 93
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 94
• 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.
Modelagem de Análise - II (“Analysis Modeling”)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 95
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 96
• É 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 preocupa-se com: – comportamento dependente do tempo dos objetos
– comunicação entre os objetos
Modelagem de Projetos (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 97
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 cliente-servidor.
• 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”.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 98
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 99
• 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.
Metodologias de Desenvolvimento de “Software” (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 100
• 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.
Metodologias de Desenvolvimento de “Software” (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 101
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 102
• 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.
Classes e Objetos - Estado de um Objeto
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 103
Objetos em C++ - Exemplo (i)
struct PersonnelRecord
{
char *name[100];
int socialSecurityNumber;
char *department[10];
float salary;
};
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 104
class PersonnelRecord {
public:
char *employeeName () const;
int employeeSocialSecuriryNumber () const;
char *employeeDepartment () const;
protected:
void setEmployeeName (char *name);
void setEmployeeSocialSecuriryNumber (int number);
void setEmployeeDepartment (char *department);
void setEmployeeSalary (float salary);
float employeeSalary () const;
private:
char *name[100];
int socialSecuriryNumber;
char *department[10];
float salary;
};
Objetos em C++ - Exemplo (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 105
• 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
Classes e ObjetosComportamento de um Objeto
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 106
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 107
• 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
O Significado das Operações (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 108
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 109
• 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.
Objetos - Ciclo de Vida
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 110
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)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 111
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 112
Exemplo de Relação de Uso entre Objetos
v1 v2
v3C
ontr
olad
or d
o P
roce
sso
fogoT
Cadinho
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 113
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 114
“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;
};
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 115
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 116
• Uma LP fortemente tipada (“strongly typed”) detecta violações de contrato em tempo de compilação.
A Natureza de uma Classe (ii)
implementation
interface
interface
visão interna visão externa
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 117
• 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.
A Natureza de uma Classe (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 118
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”)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 119
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 120
• Denominação das constantes e variáveis que integram a representação de uma classe:
– “instance variable” - Smalltalk
– “field” - Object Pascal
– “member object “ - C++
– “slot” - Clos
Estado do Objeto (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 121
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)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 122
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.
Relações entre Classes (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 123
• 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.
Herança (i)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 124
struct time {
int elapseDays;
int seconds;
};
struct ElectricalData {
Time timeStamp;
int id;
float fuelCell1Voltage, fuelCell2Voltage;
float fuelCell1Amperes,
fuelCell2Amperes;
float currentPower;
};
Herança (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 125
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.
Herança (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 126
• 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.
Herança (iv)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 127
class TelemetryDate {
public:
TelemetryData (); /* construtores */
TelemetryData (const TelemetryData&);
virtual ~TelemetryData (); /* destrutor */
virtual void send ();
Time currentTime () const;
protected:
int id;
private:
Time timeStamp;
};
Herança (v)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 128
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).
Herança (vi)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 129
• 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”).
O significado da herança entre classes
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 130
Relações de Herança Simples entre Classes
TelemetryData
SensorData
ElectricalData
PropulsionData
SpectometerData
CameraData
RadiationData
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 131
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 132
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 133
• 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
};
Polimorfismo: Exemplos (i)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 134
• 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);
Polimorfismo: Exemplos (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 135
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 136
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”.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 137
Polimorfismo: Invocação de Métodos (i)
Shape
RectangleCircle Triangle
Solide Rectangle
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 138
Polimorfismo: Invocação de Métodos (ii)
Cliente x
Lista de Figuras
fig. 1
n
Desenhar
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 139
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 140
• 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++).
Herança Múltipla (i)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 141
• 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
Herança Múltipla (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 142
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
TBook TList
“interface” “implementation”1
n
1
1
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 143
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 144
• 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.
“Container Classes” (i)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 145
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.
“Container Classes” (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 146
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 147
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 148
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
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 149
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”
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 150
• 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.
Mensurando a Qualidade da Abstração (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 151
• 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 tendo-se acesso à representação interna da abstração.
Mensurando a Qualidade da Abstração (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 152
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 153
• 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)?
Heurísticas Para a Escolha de Operações (i)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 154
• 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.
Heurísticas Para a Escolha de Relações (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 155
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 156
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 ...)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 157
• 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
A Descoberta de Objetos (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 158
• 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
Notação Gráfica Para Classes e Objetos (i)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 159
• Notação para Objetos
• Notação do Booch
Notação Gráfica Para Classes e Objetos (ii)
nome da classe
atributos
métodos
class-nameutility
class-name object-name
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 160
• 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
Notação Gráfica Para Classes e Objetos (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 161
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 162
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.
Como Encontar Objetos (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 163
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).
Como Encontar Objetos (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 164
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 minis-DFDs).
4. Agregue os minis-DFDs gerados na etapa 3.
Como Encontar Objetos (iv)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 165
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.
Como Encontar Objetos (v)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 166
• 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...)
Como Encontar Objetos (vi)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 167
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 168
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).
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 169
• 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.
Critérios Para Avaliar Candidatos a Objetos(O que se deve procurar nos objetos candidatos em um modelo AOO)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 170
• Para sistemas grandes (centenas de classes) é importante agrupá-las em “subjects” (“packages”, “kits”, “clusters”, “subsystems”).
• 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)
Subjects
Subject_1 Subject_2Classe_1Classe_2...Classe_n
Representação gráfica dos “subjects”
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 171
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 172
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:
Yourdon
Superclasse
SubClasse_1 SubClasse_2
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 173
GENERALIZAÇÃO-ESPECIALIZAÇÃO (ii)
Superclasse
SubClasse_1 SubClasse_2
Rumbaugh
Booch
Superclasse
SubClasse_1 SubClasse_2
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 174
GENERALIZAÇÃO-ESPECIALIZAÇÃO (iii)
subscriber
individualsubscriber
compsubscriber
payingsubscriber
Martin-Odell
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 175
• 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.
GENERALIZAÇÃO-ESPECIALIZAÇÃO (iv)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 176
v
Herança Múltipla
SubscriberPerson
Individual Subscriber
PayingSubscriber
CorporateSubscriber
CompSubscriber
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 177
Hierarquia Todo - Parte (“has a”)
• Possibilita que se descreva uma classe em termos de suas partes componentes, ou sub-objetos.
Whole
Part_1 Part_2
n1, n2
n3, n4
n5, n6
n7, n8
Hierarquia de classes na notação Coad- Yourdon
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 178
Hierarquia “has a”: Notação
Assembly Class
Part_1-class Part_2-class
Rumbaugh
whole
part_1 part_2
Booch
n1, n2
n3, n4
n5, n6
n7, n8
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 179
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 180
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?
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 181
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 182
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 183
Relações entre Objetos (iii)
• 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.
Notação Gráfica
Class_1 Class_2n1, n2
n3, n4
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 184
Relações entre Objetos (iv)
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.
Notação “Crow’s feet” para relações binárias.
Class_1 Class_2
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 185
Relações entre Objetos (v)
• 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.
CUSTOMER ORDER
PRODUCT SALES-PERSON
Relação envolvendo quatro classes e Objetos
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 186
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
CLIENTE PRODUTO0,N
0,N
Uma Relação N:N
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 187
Relações entre Objetos (vii)
CLIENTE PRODUTO0,N
0,N
Introduzindo uma nova classe em uma situação N:N
COMPRAS
1
1,N
CLIENTECOMPRAS PRODUTO
dataquantidade
A Notação de Rumbaugh para atributos “link”
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 188
Outra Abordagem para o Problema CLIENTE-PRODUTO
Cliente
ClienteNão-Comprador
ClienteComprador
Produto
ProdutoComprado
ProdutoNão-Comprado
1, N
1, N
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 189
Relações entre Objetos (viii)
PESSOAgerencia
é gerenciado por
0, N
1
Relação Recursiva
CLIENTE PRODUTO0,N
0,N0, 3
0, 1
Relações Múltiplas entre Classes(mais de uma relação entre um par de classes)
compra
recomenda
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 190
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ÚDITO0,N
0, N
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 191
Relações entre Objetos (x)
• Conseqüências das Conexões Mandatórias ao Inserir e Excluir Instâncias:
• 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
FABRICANTE PRODUTO1,N (C) (D) 1
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 192
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_nmétodos
Notação Gráfica
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 193
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 194
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 195
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 196
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
waitingfor call
recordingmessage rewinding
playingmessages
answeringcall
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 197
• 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.
Diagramas OLH (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 198
• 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.
Diagramas OLH (iii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 199
Diagrama de Transição de Estados
estado_1
estado_2
estado_3
estado_5
estado_4
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 200
• 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).
Diagramas OLH (iv)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 201
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?
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 202
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?
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 203
classe_1
classe_3
classe_2
classe_4
X
Ya
b
Relações entre o Diagrama OLH e o Diagrama de Comunicação entre Objetos (ii)
recebeu msg X
recebeu msg Y
envia msg ‘b’
envia msg ‘a’
estado_1
estado_3
estado_2
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 204
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.
Diagramas OLH (v)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 205
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_1método_2
Representação gráfica de um serviço
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 206
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.
Serviços dos Objetos (ii)
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 207
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.
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 208
Documentando as Conexões de Mensagens (i)
classe_1 classe_2
classe_1 classe_2
métodos métodos
métodos métodos
Envio de mensagem para um objeto
Envio de mensagem para uma classe
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 209
Documentando as Conexões de Mensagens (ii)
classe_1 classe_2
método_1
método_2 método_4
método_3
x
y
Uma conexão de mensagens em mais minúcias
classe_1
método_1
método_2
Um objeto enviando mensagem para si mesmo
Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 210
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)