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


Programming

Programming in The Large Programming in The Small


Programming in The Small

• Exemplos:

– alguns trabalhos acadêmicos

– programas simples

• Características:

– poucas linhas de código (dezenas ou centenas)

– apenas um programador


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


Sistemas

Simples Complexos


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

• ...


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


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


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


• 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


Problema Capital

Manter a unidade e a integridade do projeto


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


• 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)


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


• 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”


• 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


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


• 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)


Exemplos de Sistemas Complexos (iii)

Memória HDD Monitor Teclado

CPU


Exemplos de Sistemas Complexos (iv)

ALUUC BUS

Registradores

Lógica de

Controle

NANDs Gates

CPU


• 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)


• 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)


• 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)


• 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)


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


• 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)


• 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)


• 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)


• 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)


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


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.


• 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)


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?


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.


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


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.


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.


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.


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)


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.


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


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


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)


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


• 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)


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


• 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


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)


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


• 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)


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


• 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)


• 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)


• 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)


• 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)


• 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)


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).


• 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)


• 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)


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)


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


• 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


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


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.


• 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)


• 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)


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).


• 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)


Tensão entre os Princípios

Abstração

Encapsulamento Hierarquia


• 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)


Exemplos de Herança

mamíferos

cães

dobermann rotweiller dog alemão

híbrido dobermann + rotweiller

herançasimples

herança múltipla


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.


Exemplo de Polimorfismo

move

treinador de circo


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”.


• 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)


• 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)


• 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


• 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)


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.


• 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)


• “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)


• ADA

strongly & static typed

• Object Pascal & C++

strongly typed & dynamic binding

• Smalltalk

untyped & dynamic binding

Tipos (iv)


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”


início

fim

Concorrência (ii)


• 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)


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


• 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)


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”.


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.


• 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)


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.


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


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.


• 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”)


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


• É 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)


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”.


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.


• 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)


• 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)


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.


• 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


Objetos em C++ - Exemplo (i)

struct PersonnelRecord

{

char *name[100];

int socialSecurityNumber;

char *department[10];

float salary;

};


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)


• 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


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.


• 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)


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.


• 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


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)


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.


Exemplo de Relação de Uso entre Objetos

v1 v2

v3C

ontr

olad

or d

o P

roce

sso

fogoT

Cadinho


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.


“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;

};


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.


• 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


• 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)


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”)


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.


• 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)


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)


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)


• 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)


struct time {

int elapseDays;

int seconds;

};

struct ElectricalData {

Time timeStamp;

int id;

float fuelCell1Voltage, fuelCell2Voltage;

float fuelCell1Amperes,

fuelCell2Amperes;

float currentPower;

};

Herança (ii)


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)


• 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)


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)


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)


• 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


Relações de Herança Simples entre Classes

TelemetryData

SensorData

ElectricalData

PropulsionData

SpectometerData

CameraData

RadiationData


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.


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.


• 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)


• 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)


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


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”.


Polimorfismo: Invocação de Métodos (i)

Shape

RectangleCircle Triangle

Solide Rectangle


Polimorfismo: Invocação de Métodos (ii)

Cliente x

Lista de Figuras

fig. 1

n

Desenhar


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


• 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)


• 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)


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


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.


• 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)


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)


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.


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.


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


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”


• 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)


• 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)


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.


• 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)


• 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)


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.


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 ...)


• 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)


• 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)


• 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


• 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)


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.


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)


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)


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)


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)


• 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)


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.


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).


• 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)


• 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”


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.


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


GENERALIZAÇÃO-ESPECIALIZAÇÃO (ii)

Superclasse


Rumbaugh

Booch

Superclasse



GENERALIZAÇÃO-ESPECIALIZAÇÃO (iii)

subscriber

individualsubscriber

compsubscriber

payingsubscriber

Martin-Odell


• 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)


v

Herança Múltipla

SubscriberPerson

Individual Subscriber

PayingSubscriber

CorporateSubscriber

CompSubscriber


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


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


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.


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?


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.


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.


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


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


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


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


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”


Outra Abordagem para o Problema CLIENTE-PRODUTO

Cliente

ClienteNão-Comprador

ClienteComprador

Produto

ProdutoComprado

ProdutoNão-Comprado

1, N

1, N


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


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


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


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


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.


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.


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.


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


• 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)


• 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)


Diagrama de Transição de Estados

estado_1

estado_2

estado_3

estado_5

estado_4


• 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)


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?


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?


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


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)


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


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)


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.


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


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


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)

sistemas orientados a objetos

Documents