A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by1 Sistemas Orientados a Objetos Bibliografia: Booch, G. Object Oriented Design with Applications.

Apresentações semelhantes


Apresentação em tema: "Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by1 Sistemas Orientados a Objetos Bibliografia: Booch, G. Object Oriented Design with Applications."— Transcrição da apresentação:

1 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by1 Sistemas Orientados a Objetos Bibliografia: Booch, G. Object Oriented Design with Applications. The Benjamin/Cummings Publishing Company, Inc Yourdon, E. Object-Oriented Systems Design - An Integrated Approach. Prentice-Hall, Inc. 1994

2 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by2 Programming Programming in The LargeProgramming in The Small

3 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by3 Programming in The Small Exemplos: –alguns trabalhos acadêmicos –programas simples Características: –poucas linhas de código (dezenas ou centenas) –apenas um programador

4 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by4 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

5 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by5 Sistemas SimplesComplexos

6 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by6 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...

7 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by7 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

8 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by8 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

9 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by9 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

10 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by10 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

11 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by11 Problema Capital Manter a unidade e a integridade do projeto

12 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by12 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

13 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by13 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)

14 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by14 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

15 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by15 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

16 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by16 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

17 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by17 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

18 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by18 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)

19 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by19 Exemplos de Sistemas Complexos (iii) Memória HDDMonitorTeclado CPU

20 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by20 Exemplos de Sistemas Complexos (iv) ALU UC BUS Registradores Lógica de Controle NANDs Gates CPU

21 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by21 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)

22 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by22 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)

23 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by23 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)

24 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by24 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)

25 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by25 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

26 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by26 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)

27 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by27 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)

28 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by28 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)

29 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by29 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)

30 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by30 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

31 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by31 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.

32 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by32 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)

33 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by33 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?

34 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by34 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.

35 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by35 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

36 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by36 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.

37 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by37 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.

38 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by38 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.

39 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by39 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)

40 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by40 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.

41 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by41 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

42 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by42 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

43 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by43 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)

44 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by44 Evolução do Modelo Objeto (i) Tendências em Engenharia de Software As Gerações das Linguagens de Programação 1 a Geração ( ) - FORTRAN I, ALGOL 58, Flowmatic, IPL V –voltadas para aplicações científicas e de engenharia –facilidades para escrever expressões matemáticas 2 a Geração ( ) –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

45 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by45 3 a Geração ( ) –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 ( ) –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)

46 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by46 A Topologia das LPs da 1 a Geração e Início da 2 a 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

47 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by47 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 2 a Geração e das LPs do Início da 3 a Geração

48 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by48 A Topologia das LPs do Final da 3 a 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)

49 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by49 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

50 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by50 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)

51 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by51 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

52 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by52 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)

53 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by53 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)

54 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by54 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)

55 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by55 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)

56 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by56 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)

57 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by57 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).

58 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by58 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)

59 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by59 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)

60 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by60 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)

61 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by61 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

62 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by62 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

63 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by63 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

64 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by64 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 3Ds não precisam se preocupar com a representar física dos dados.

65 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by65 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)

66 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by66 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)

67 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by67 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).

68 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by68 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)

69 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by69 Tensão entre os Princípios Abstração Encapsulamento Hierarquia

70 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by70 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)

71 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by71 Exemplos de Herança mamíferos cães dobermann rotweillerdog alemão híbrido dobermann + rotweiller herança simples herança múltipla

72 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by72 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.

73 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by73 Exemplo de Polimorfismo move treinador de circo

74 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by74 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.

75 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by75 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)

76 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by76 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)

77 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by77 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

78 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by78 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)

79 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by79 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.

80 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by80 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)

81 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by81 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)

82 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by82 ADA strongly & static typed Object Pascal & C++ strongly typed & dynamic binding Smalltalk untyped & dynamic binding Tipos (iv)

83 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by83 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

84 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by84 início fim Concorrência (ii)

85 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by85 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)

86 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by86 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 Bases de Dados OODB Object Model + = Persistence

87 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by87 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)

88 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by88 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.

89 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by89 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.

90 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by90 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 its 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)

91 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by91 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.

92 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by92 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

93 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by93 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.

94 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by94 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)

95 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by95 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

96 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by96 É 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)

97 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by97 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.

98 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by98 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.

99 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by99 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)

100 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by100 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)

101 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by101 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.

102 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by102 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

103 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by103 Objetos em C ++ - Exemplo (i) struct PersonnelRecord { char*name[100]; intsocialSecurityNumber; char*department[10]; floatsalary; };

104 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by104 class PersonnelRecord { public: char*employeeName () const; intemployeeSocialSecuriryNumber () const; char*employeeDepartment () const; protected: voidsetEmployeeName (char *name); voidsetEmployeeSocialSecuriryNumber (int number); voidsetEmployeeDepartment (char *department); voidsetEmployeeSalary (float salary); floatemployeeSalary () const; private: char*name[100]; intsocialSecuriryNumber; char*department[10]; floatsalary; }; Objetos em C ++ - Exemplo (ii)

105 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by105 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 Objetos Comportamento de um Objeto

106 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by106 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.

107 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by107 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)

108 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by108 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.

109 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by109 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

110 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by110 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)

111 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by111 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.

112 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by112 Exemplo de Relação de Uso entre Objetos v1v1 v2v2 v3v3 Controlador do Processo fogo T Cadinho

113 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by113 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.

114 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by114 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; };

115 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by115 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.

116 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by116 Uma LP fortemente tipada (strongly typed) detecta violações de contrato em tempo de compilação. A Natureza de uma Classe (ii) implementation interface visão interna visão externa

117 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by117 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)

118 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by118 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)

119 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by119 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.

120 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by120 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)

121 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by121 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)

122 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by122 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)

123 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by123 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)

124 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by124 struct time { int elapseDays; int seconds; }; struct ElectricalData { TimetimeStamp; intid; floatfuelCell1Voltage, fuelCell2Voltage; floatfuelCell1Amperes, fuelCell2Amperes; floatcurrentPower; }; Herança (ii)

125 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by125 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)

126 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by126 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)

127 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by127 class TelemetryDate { public: TelemetryData (); /* construtores */ TelemetryData (const TelemetryData&); virtual ~TelemetryData (); /* destrutor */ virtual void send (); Time currentTime () const; protected: intid; private: Time timeStamp; }; Herança (v)

128 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by128 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)

129 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by129 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

130 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by130 Relações de Herança Simples entre Classes Telemetry Data Sensor Data Electrical Data Propulsion Data Spectometer Data Camera Data Radiation Data

131 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by131 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.

132 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by132 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.

133 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by133 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)

134 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by134 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)

135 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by135 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

136 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by136 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.

137 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by137 Polimorfismo: Invocação de Métodos (i) Shape Rectangle Circle Triangle Solide Rectangle

138 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by138 Polimorfismo: Invocação de Métodos (ii) Cliente x Lista de Figuras fig. 1 n Desenhar

139 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by139 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

140 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by140 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)

141 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by141 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)

142 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by142 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

143 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by143 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.

144 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by144 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)

145 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by145 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)

146 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by146 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.

147 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by147 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.

148 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by148 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

149 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by149 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

150 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by150 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)

151 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by151 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)

152 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by152 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.

153 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by153 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)

154 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by154 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)

155 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by155 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.

156 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by156 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...)

157 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by157 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)

158 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by158 História: –DFDs (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)

159 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by159 Notação para Objetos Notação do Booch Notação Gráfica Para Classes e Objetos (ii) nome da classe atributos métodos class-name utility class-name object-name

160 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by160 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)

161 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by161 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.

162 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 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)

163 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 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)

164 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by164 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)

165 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by 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)

166 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by166 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)

167 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by167 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.

168 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by168 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).

169 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by169 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)

170 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by170 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_2 Classe_1 Classe_2... Classe_n Representação gráfica dos subjects

171 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by171 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.

172 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by172 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

173 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by173 GENERALIZAÇÃO-ESPECIALIZAÇÃO (ii) Superclasse SubClasse_1 SubClasse_2 Rumbaugh Booch Superclasse SubClasse_1 SubClasse_2

174 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by174 GENERALIZAÇÃO-ESPECIALIZAÇÃO (iii) subscriber individual subscriber comp subscriber paying subscriber Martin-Odell

175 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by175 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)

176 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by176 v Herança Múltipla Subscriber Person Individual Subscriber Paying Subscriber Corporate Subscriber Comp Subscriber

177 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by177 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 n 1, n 2 n 3, n 4 n 5, n 6 n 7, n 8 Hierarquia de classes na notação Coad- Yourdon

178 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by178 Hierarquia has a: Notação Assembly Class Part_1-class Part_2-class Rumbaugh whole part_1 part_2 Booch n 1, n 2 n 3, n 4 n 5, n 6 n 7, n 8

179 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by179 Hierarquia has a Cada instância da classe whole deve consistir de n i instâncias da classe part i, onde n 1 <=n i <=n 2. Alternativamentecada instância da classe part i pode ser uma parte de m i instâncias da classe whole, onde n 3 <=m i <=n 4. 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.

180 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by180 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?

181 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by181 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.

182 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by182 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.

183 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by183 Relações entre Objetos (iii) Uma instância da classe_1 é associada com n instâncias da classe_2, n 1 <=n<=n 2 ; e uma instância da classe_2 é associada com m instâncias da classe_1, n 3 <=m<=n 4. n 1 ou n 3 = 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_2 n 1, n 2 n 3, n 4

184 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by184 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 Crows feet para relações binárias. Class_1 Class_2

185 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by185 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

186 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by186 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 PRODUTO 0,N Uma Relação N:N

187 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by187 Relações entre Objetos (vii) CLIENTE PRODUTO 0,N Introduzindo uma nova classe em uma situação N:N COMPRAS 1 1,N CLIENTE COMPRAS PRODUTO data quantidade A Notação de Rumbaugh para atributos link

188 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by188 Outra Abordagem para o Problema CLIENTE-PRODUTO Cliente Não-Comprador Cliente Comprador Produto Comprado Produto Não-Comprado 1, N

189 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by189 Relações entre Objetos (viii) PESSOA gerencia é gerenciado por 0, N 1 Relação Recursiva CLIENTE PRODUTO 0,N 0, 3 0, 1 Relações Múltiplas entre Classes (mais de uma relação entre um par de classes) compra recomenda

190 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by190 Relações entre Objetos (ix) Conexões unárias entre classes (nem sempre as relações são binárias) Ex.: Eu conheço muito sobre a personalidade XXX. Será que a personalidade XXX conhece muito sobre mim? Uma forma de representar as relações unidirecionais seria incluir os limites de cardinalidade em apenas uma direção, aquela na qual a relação é válida. ALTEZA SÚDITO 0,N

191 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by191 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 PRODUTO 1,N (C) (D) 1

192 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by192 Atributos dos Objetos (i) O Modelo AOO deve incluir a definição dos atributos para as classes e objetos. Os atributos descrevem dados que são ocultos dentro da classe e objeto e invisíveis ao mundo externo. Os atributos são manipulados (operados) pelos métodos (serviços) na classe e objeto. Os atributos descrevem o estado de um objeto, enquanto os métodos descrevem o seu comportamento. Nome da Classe atributo_1 … atributo_n métodos Notação Gráfica

193 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by193 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.

194 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by194 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.

195 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by195 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.

196 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by196 Diagramas Object Life-History - OLH (i) Os principais elementos do diagrama são: –retângulos, representando estados –flechas, representando a mudança de estados idle waiting for call recording message rewinding playing messages answering call

197 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by197 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)

198 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by198 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)

199 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by199 Diagrama de Transição de Estados estado_1 estado_2 estado_3 estado_5 estado_4

200 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by200 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)

201 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by201 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?

202 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by202 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?

203 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by203 classe_1 classe_3 classe_2 classe_4 X Y a 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

204 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by204 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)

205 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by205 Serviços dos Objetos (i) Um serviço (método) é um processo conduzido por um objeto, quando ele recebe uma mensagem especificamente a ele direcionada. As mensagens são documentadas por uma flecha que parte da classe/objeto-origem, para a classe/objeto-destino. classe_1 método_1 método_2 Representação gráfica de um serviço

206 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by206 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)

207 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by207 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.

208 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by208 Documentando as Conexões de Mensagens (i) classe_1 classe_2 classe_1 classe_2 métodos Envio de mensagem para um objeto Envio de mensagem para uma classe

209 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by209 Documentando as Conexões de Mensagens (ii) classe_1 classe_2 método_1 método_2mé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

210 Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by210 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)


Carregar ppt "Oscar Luiz Monteiro de Farias, D.Sc.05/96 Copyright by1 Sistemas Orientados a Objetos Bibliografia: Booch, G. Object Oriented Design with Applications."

Apresentações semelhantes


Anúncios Google