Sistemas Orientados a Objetos Bibliografia: Booch, G. Object Oriented Design with Applications. The Benjamin/Cummings Publishing Company, Inc. 1991. Yourdon, E. Object-Oriented Systems Design - An Integrated Approach. Prentice-Hall, Inc. 1994

Programming in The Large Programming in The Small

Programming in The Small Exemplos: alguns trabalhos acadêmicos programas simples Características: poucas linhas de código (dezenas ou centenas) apenas um programador

Programming in The Large Exemplos: controle de processos centrais telefônicas sistemas gerenciadores de bancos de dados Características: milhares de linhas de códigos equipe de desenvolvimento formada por várias pessoas

Sistemas Simples Complexos

Exemplos de sistemas Complexos o processo de formação do início do Universo decodificação do DNA metabolismo de uma célula o corpo humano processo de formação das estrelas software de controle de uma central telefônica CPA naves espaciais sistema de tráfego de uma metrópole descrição do movimento de uma particular partícula d’água no curso de um rio ...

Principal Característica dos Sistemas Complexos Tem a ver com o “Domínio do Problema” (“Problem Domain”) Ultrapassam a capacidade intelectual do ser humano isolado relativamente a: extensão do conhecimento profundidade do conhecimento

A complexidade Inerente ao “Software” A complexidade do Domínio do Problema A dificuldade em se gerenciar o processo de desenvolvimento do “software” A flexibilidade proporcionada pelo “software” A dificuldade para se caracterizar o comportamento dos sistemas discretos

A Complexidade do “Problem Domain” Há sistemas já complexos em sua funcionalidade pela sua própria natureza sistema de comutação para telefonia celular sistema eletrônico para aeronaves “robot” autônomo Acrescente-se os aspectos relativos a: facilidades de uso, performance, custo, permanência e confiabilidade O problema de “impedance mismatch” (usuários x desenvolvedores) os usuários muitas vezes têm uma vaga idéia do que querem falta de mecanismos formais para capturar os requisitos do problema alteração dos requisitos durante o desenvolvimento Atencão: Não confundir evolução com manutenção. Os sistemas evoluem com o tempo, i. e., modificam-se.

Dificuldades em se Gerenciar o Processo de Desenvolvimento Tem a ver com o “Domínio do Problema” (“Problem Domain”) O conhecimento inerente aos sistemas grandes e complexos ultrapassa a capacidade intelectual do ser humano isolado relativamente a extensão e/ou profundidade do conhecimento Necessidade de equipes para desenvolver “software” maior a equipe mais comunicação coordenação mais difícil

Manter a unidade e a integridade do projeto Problema Capital Manter a unidade e a integridade do projeto

O Problema de se caracterizar o comportamento dos Sistemas Discretos (i) Estado de uma aplicação: o conjunto de suas variáveis, seus valores correntes, os endereços e a pilha de chamadas de cada processo no sistema. Os sistemas discretos possuem um número finito de estados Em sistemas grandes há uma explosão combinatorial e o número de estados cresce muito

O Problema de se caracterizar o comportamento dos Sistemas Discretos (ii) Nos sistemas contínuos, pequenas alterações na entrada sempre ocasionarão pequenas alterações na saída x 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 (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

A Flexibilidade do “Software” O “software” é a quinta-essência da flexibilidade Dificuldade na elaboração de padrões Atividade mão-de-obra intensiva Contínua reinvenção da roda

Conseqüências da Complexidade sem Limites Quanto mais complexo o sistema maior a dificuldade de alterá-lo Ex.: uma vez projetado um prédio de 100 andares e iniciada a sua construção, dificilmente o mesmo sofrerá alterações de projeto. Já com o “software”... Escassez de bons programadores para criar todos os produtos demandados pelos usuários crise de “software” (“software crisis”) cresce o “back log” de “software”, os requisitos são deficientes, os custos excessivos, etc ... parte crescente de pessoal dedicado à manutenção Como os Sistemas Complexos se organizam?

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

Exemplos de Sistemas Complexos (ii) A Estrutura de um Computador Pessoal natureza hierárquica juntas, as partes formam um todo lógico e integrado os vários níveis de hierarquia representam diferentes níveis de abstração cada nível é construído “em cima” de outros níveis cada nível é auto-contido, em termos de seu entendimento

Exemplos de Sistemas Complexos (iii) CPU Memória HDD Monitor Teclado

Exemplos de Sistemas Complexos (iv) CPU ALU UC BUS Lógica de Controle Registradores NANDs Gates

Exemplos de Sistemas Complexos (v) A Estrutura de Plantas e Animais sempre existem fronteiras claras e bem definidas entre o exterior e o interior de um dado nível. há uma clara separação de objetivos (“tasks”) entre as partes, nos diferentes níveis de abstração. através da atividade cooperativa de vários órgãos surgem comportamentos complexos. ex.: fotossíntese transpiração

Exemplos de Sistemas Complexos (vi) Planta - complexo organismo multicelular Estrutura: raiz, caule e folhas raiz: ramos radiculares, pelos absorventes, “root apex”, coifa folha: epiderme, mesófilo, tecido vascular. células cloroplasto mitocôndrea núcleo “root apex”: é o ponto mais baixo da raiz, aonde ocorre o crescimento. “root cap”(coifa): para proteger as zonas meristemáticas, onde ocorre a mitose (crescimento) núcleo: contém o DNA - material genético mitocôndrea: responsável pelo metabolismo. transforma glicose em energia, através do ciclo de Grbi e da cadeia respiratória cloroplasto: responsável pela absorção da luz. xilena (ou vasos lenhosos): conduzem a seiva bruta vasos liberianos: conduzem o líber ou seiva elaborada

Exemplos de Sistemas Complexos (vii) Não encontramos partes individuais que sejam responsáveis por somente pequenas fases de um processo maior e único. Não há partes centralizadas que coordenem as atividades de outras partes. Só através da cooperação mútua das partes se desenvolve o nível de funcionalidade encontrado nas plantas. Existem elementos comuns que perspassam diferentes domínios células (plantas e animais) sistema vascular para transportar nutrientes para o organismo diferenciação de sexos

Exemplos de Sistemas Complexos (vii) A Estrutura da Matéria Astronomia (Macrocosmo) Física Nuclear (Microcosmo) Estruturas hierárquicas galáxias - “clusters” - estrelas - planetas - “debris” átomos - elétrons - prótons - nêutrons - quarks Mecanismos compartilhados que unificam esta vasta hierarquia: parece haver apenas 4 forças fundamentais no Universo: gravidade, interação eletro-magnética, força forte, força fraca as Leis de Conservação de Energia e de Momento se aplicam tanto ao Macrocosmo quanto ao Microcosmo

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

Os 5 Atributos dos Sistemas Complexos (ii) 2. A escolha de quais componentes em um sistema são primitivos é relativamente arbitrária e é, em grande parte, dependente do observador do sistema Os sistemas complexos são: “decomposable”: porque podem ser divididos em partes identificáveis. “nearly decomposable”: porque as suas partes não são completamente independentes.

Os 5 Atributos dos Sistemas Complexos (iii) 3. As conexões intracomponentes são geralmente mais importantes (fortes) que as conexões intercomponentes. Este fato possibilita a separação de: dinâmica de alta freqüência dos componentes: envolve a estrutura interna dos componentes. dinâmica de baixa freqüência: envolve a interação entre os componentes. => possibilita o estudo interno das partes do sistema de forma relativamente isolada

Os 5 Atributos dos Sistemas Complexos (iv) 4. Os sistemas hierárquicos são normalmante compostos de poucos diferentes subsistemas dispostos segundo várias combinações e arranjos. Muitas vezes encontramos subsistemas que são comuns a diferentes domínios (ex.: células, circuitos integrados, etc ...) células (plantas e animais) circuitos integrados (diversos equipamentos eletrônicos)

Os 5 Atributos dos Sistemas Complexos (v) Os sistemas complexos tendem a evoluir no tempo. Os sistemas complexos irão evoluir mais rapidamente a partir de sistemas simples, se existirem formas intermediárias estáveis (Simons). 5. Um sistema complexo que funciona invariavelmente evoluiu de um sistema simples que funcionava. Um sistema complexo projetado do “zero” nunca funciona e não pode ser consertado funcionar.Deve-se recomeçar partindo-se de um sistema simples. À medida que o sistema evolui, objetos anteriormente considerados complexos tornam-se os objetos primitivos, a partir dos quais objetos mais complexos são construídos.

Complexidade Organizada e Não-Organizada A descoberta de abstrações e mecanismos comuns facilita o entendimento dos sistemas complexos. Os sistemas complexos não incorporam apenas uma única hierarquia. Várias hierarquias estão presentes em um sistema complexo. Duas hierarquias são especiais: estrutural, parte de (“part of”), ou “object structure” ex.: Um automóvel pode ser decomposto em: sistema de propulsão sistema de direção, etc... tipo de (“kind of”) ou “class structure” ex.: motor, motor a álcool, a diesel, a gasolina

A Forma Canônica de Um Sistema Complexo (i) Combinando-se os conceitos de estrutura de classes e de objetos com os cinco atributos de um sistema complexo vemos que praticamente todos os sistemas complexos apresentam a mesma forma (canônica) como na figura. A estrutura de classes (”kind of hierarchy”) e a estrutura de objetos (“part of hierarchy”) não são completamente independentes. Cada objeto, na estrutura de objetos representa uma instância específica de alguma classe. Normalmente há muito mais classes que objetos em um sistema complexo.

A Forma Canônica de Um Sistema Complexo (ii) A análise da estrutura de classes (“kind of hierarchy”) e da estrutura de objetos (“part of hierarchy”) revela a redundância do sistema. A estrutura de classes abriga o conhecimento comum relativo às propriedades de cada parte individual (objeto). Os sistemas de “software” bem sucedidos, explicitamente incorporam uma estrutura de classes e objetos bem definidas, além dos cinco atributos dos sistemas complexos

As limitações do ser humano no trato com a complexidade Dilema A complexidade dos sistemas de “software” é crescente e os seres humanos têm limites estruturais para lidar com esta complexidade. O que fazer?

1. O Papel da Decomposição “Dividir para reinar” Uma decomposição inteligente ataca o problema da complexidade inerente ao “software”, forçando uma divisão do espaço de estado do sistema (Parnas). Tipos de Decomposição: Decomposição Algorítmica É uma conseqüência do “top-down structured design”. Cada módulo do sistema denota um passo maior em algum processo global. Decomposição Orientada a Objetos Um sistema é encarado como um conjunto de agentes autônomos (objetos), que colaboram para efetivar algum comportamento de mais alto nível. Um objeto é simplesmente uma entidade tangível que exibe um comportamento bem definido; Objetos fazem coisas; Diz-se aos objetos como realizar coisas, enviando-se mensagens aos mesmos.

Decomposição Algorítmica X Orientada a Objetos Qual é a forma correta de se decompor um sistema complexo? A visão algorítmica enfatiza a ordem dos eventos A visão orientada a objetos enfatiza os agentes que causam ou sofrem uma ação Trata-se de duas visões ortogonais. Não se pode construir um sistema baseado simultaneamente nas duas versões

Experiência do Booch e colaboradores (Object Oriented Design with Applications, pg. 16) 1. Aplica primeiro a visão OO, por considerá-la mais eficiente na organização da complexidade dos sistemas. 2. Conduz a sistemas menores, através da reutilização de mecanismos comuns. 3. É mais resiliente (aprersenta maior poder de recuperação a mudanças) e, assim, está mais capacitada a evoluir no tempo, porque o projeto é baseado em formas intermediárias estáveis. 4. Reduz o risco de desenvolver complexos sistemas de “software”, pois os mesmos são projetados para evoluir incrementalmente. 5. Diretamente ataca a complexidade inerente ao “software”, através da separação de preocupações (“concerns”) em espaço de estados de grandes dimensões.

2. O Papel da Abstração Os seres humanos desenvolveram uma técnica excepcionalmente poderosa para lidar com a complexidade. Abstraem-se dela. Incapazes de dominar a totalidade de um objeto complexo, escolhem ignorar detalhes não essenciais,e, ao invés, tratam apenas com um modelo idealizado e geral do objeto. Através da abstração, usamos agregados de informação com conteúdo se~mântico cada vez maior. Os objetos representam, como abstrações do mundo real, um “cluster” coesivo e particularmente denso de informação.

3. O Papel da Hierarquia Um meio de aumentar o conteúdo semântico dos “pedaços” individuais de informação é reconhecer explicitamente as hierarquias de classe e objeto. A estrutura de classes faz aflorar as redundâncias existentes. A estrutura de objetos mostra como os diferentes objetos colaboram entre si através de padrões de interação chamados mecanismos. A classificação dos objetos em grupos de abstrações relacionados, permite a distinção entre as propriedades comuns e propriedades distintas entre vários objetos. A identificação de hierarquias nem sempre é fácil, pois requer a descoberta de padrões entre vários objetos, e cada um deles pode incorporar formas de comportamento muito complicadas.

Projetando Sistemas Complexos Engenharia envolve ciência & arte... O significado do Projeto Abordagem disciplinada para inventar uma solução para um dado problema, provendo assim um caminho, desde os requisitos do sistema, até a sua implementação. O propósito do Projeto é construir um sistema que: satisfaça uma dada especificação funcional adeque-se às limitações do equipamento alvo subordine-se aos requisitos implícitos ou explícitos, relativos à performance e ao uso de recursos satisfaça restrições do próprio processo do projeto (tempo ou ferramentas disponíveis, ou custo)

A Importância da Construção de Modelos A construção de modelos adere aos princípios de decomposição, abstração e hierarquia. Cada modelo, em um projeto, descreve um aspecto específico do sistema sob consideração. Sempre que possível constrói-se novos modelos, baseados em modelos já existentes e confiáveis. Os modelos nos dão a oportunidade de falhar sob condições controladas. Analisamos os modelos sob condições esperadas e sob condições não usuais e, então , os alteramos, quando eles não se comportam como o desejado ou esperado. De modo a expressar todas as propriedades de um sistema complexo deve-se usar vários tipos de modelos.

Elementos dos Métodos para Projetos de “Software” O Projeto de Sistemas de Software Complexos envolve um processo incremental e interativo. Há diversas categorias de métodos para Projetos. Cada método deve incluir: Notação - a linguagem para expressar cada modelo Processo - as orientações para a construção ordenada dos modelos Ferramentas - mecanismos que automatizam tarefas e reforçam as regras do modelo, de modo que os erros e inconsistências aflorem

Os Modelos de Projetos Orientados a Objetos Projeto Orientado a Objetos: é um método que nos leva a uma decomposição orientada a objetos. Resultado: “software” mais resiliente (elástico) a mudanças escrito com economia de expressão maior nível de confiabilidade e correção, através da separação inteligente do espaço de estados redução dos riscos de desenvolvimento

Princípios dos Projetos Orientados a Objetos (Modelo Objeto) Abstração Encapsulamento Hierarquia Modularidade ---------------------------------- Tipos Concorrência Persistência (Booch) Abstração Encapsulamento Herança (Yourdon) ---------------------------------- + Polimorfismo (Rumbaugh) Reuso Especialização Comunicação entre Objetos Polimorfismo (OMG)

Evolução do Modelo Objeto (i) Tendências em Engenharia de “Software” As Gerações das Linguagens de Programação 1a Geração (1954-1958) - FORTRAN I, ALGOL 58, Flowmatic, IPL V voltadas para aplicações científicas e de engenharia facilidades para escrever expressões matemáticas 2a Geração (1959-1961) FORTRAN II - subrotinas, compilação em separado ALGOL 60 - estrutura de blocos, tipos de dados COBOL - descrição de dados, manipulação de arquivos Lisp - processamento de listas, ponteiros

Evolução do Modelo Objeto (ii) 3a Geração (1962-1970) PL/1 - FORTRAN + ALGOL + COBOL ALGOL 68 - sucessor formal do ALGOL 60 Pascal - outro sucessor do ALGOL 60 Simula - classes, abstração de dados O “gap” das gerações (1970 - 1980) muitas linguagens foram inventadas, porém poucas permaneceram hoje: ADA, CLOS, C++ (C U Simula) linguagens orientadas a objetos (“object based”) linguagens baseadas em objetos (“object oriented”)

A Topologia das LPs da 1a Geração e Início da 2a o subprograma era o bloco básico para a construção de todas as aplicações o erro em uma parte do programa podia ter efeitos devastadores em outras partes quando muitas alterações eram efetuadas em sistemas de grande porte tornava-se difícil manter a integridade do projeto original após alguma manutenção, um sistema escrito nestas linguagens continha: acoplamentos cruzados entre subprogramas significados implicados de dados fluxo de controle entrelaçado perigos quanto a confiabilidade de todo o sistema redução na clareza da solução

A Topologia das Últimas LPs da 2a Geração e das LPs do Início da 3a Geração reconheceu-se a importância dos subprogramas como intermediários relevantes entre o problema e o computador os subprogramas passaram a ser vistos como mecanismos de abstração foram inventadas linguagens com mecanismos variados para a passagem de parâmetros lançamento da programação estruturada, refletindo-se em: aninhamento de subprogramas estruturas de controle escopo e visibilidade de variáveis emergência das metodologias de Projeto Estruturado (voltadas para “Programming in The Large”) houve um maior controle sobre as abstrações dos algoritmos, porém não resolveu os problemas de “Programming in The Large” e dos Projetos dos Dados

A Topologia das LPs do Final da 3a Geração compilação em separado de módulos todavia, os módulos raramente foram reconhecidos como mecanismos de abstração eram usados simplesmente para agrupar programas relacionados não havia regras para verificar a consistência semântica entre as interfaces dos módulos certos erros na passagem de parâmetros, só eram descobertos em tempo de execução (ex.: passagem de parâmetros com inconsistência entre os tipos)

A Topologia das LPs Baseadas em Objetos e Orientadas a Objetos enfatizou-se a abstração de dados no trato da complexidade uso de procedures (para operações abstratas, mas não era ideal para a descrição de objetos abstratos) descrição dos objetos => conceito de tipos os blocos básicos de construção são os módulos os módulos representam uma coleção lógica de classes e objetos, ao invés de programas A topologia passa a ser um grafo, e não uma árvore, que era a a topologia típica das linguagens orientadas a algoritmos quase não há dados globais em sistemas imensos encontramos “clusters” de abstrações construídos em níveis, superpostos uns aos outros em cada nível de abstração encontramos coleções de objetos que cooperam entre si, a fim de manifestar algum tipo de comportamento em um nível mais elevado

O Modelo Objeto - “The Object Model” (i) 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” (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

O Modelo Objeto - “The Object Model” (iii) Objeto é o conceito fundamental. Objeto (definição informal): entidade tangível, que exibe algum tipo de comportamento bem definido. Conceito básico: objeto serve para unificar as idéias de algoritmo e abstração de dados. Um objeto somente pode alterar o seu estado, comportamento, ou ser manipulado, ou relacionar-se com outros objetos em modos apropriados àquele objeto. Existem propriedades invariantes que caracterizam um objeto em seu comportamento (ex.: trem, elevador ...)

O Modelo Objeto - “The Object Model” (iv) OOP - “Object-Oriented Programming” (Booch) OOP é um metodo de implementação no qual programas são organizados como coleções de objetos cooperativos, cada qual representando uma instância de alguma classe, e cujas classes são todas membras de uma hierarquia de classes unidas via relações de herança (“kind of herarchy”). Uma LP sem herança não é Orientada a Objetos. Ela é dita “Object-Based”. OOP usa objetos e não algoritmos, como os blocos de construção lógicos e fundamentais. cada objeto é uma instância de uma classe as classes são relacionadas entre si via relações de herança. Uma LP sem herança não é Orientada a Objetos. Ela é dita “Object-Based”. Se algum dos elementos acima estiver faltando, o programa não pode ser dito orientado a objetos

O Modelo Objeto - “The Object Model” (v) Segundo Cardelli & Wagner, uma linguagem é orientada a objetos se: suporta objetos que são abstrações de dados, com interfaces para operações nomeadas (métodos) e um estado local oculto. Objetos têm um tipo (classe) associado Tipos (classes) podem herdar atributos de supertipos (superclasses)

O Modelo Objeto - “The Object Model” (vi) OOD - “Object-Oriented Design” (Booch) OOD é um método de projeto que incorpora: o processo de decomposição orientado a objetos uma notação para mostrar: os modelos lógicos e físicos do sistema os modelos estáticos e dinâmicos do sistema modelos lógicos: estrutura de classes e objetos modelos físicos: arquitetura dos módulos e dos processos OOD - qualquer método que leve a uma decomposição orientada a objetos.

O Modelo Objeto - “The Object Model” (vii) OOA - “Object-Oriented Analysis” (Booch) OOA é um método de análise que examina os requisitos do sistema a partir das classes e objetos encontrados no vocabulário do domínio do problema. As técnicas de análise estruturada tradicionais (De Marco, Yourdon, Gane e Sarson) têm o seu foco no fluxo de dados do problema.

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

Abstração (ii) Define uma relação entre um grupo de tipos de objetos (“object types”), de forma que um um tipo objeto represente um conjunto de características que são compartilhadas pelos outros tipos de objetos (OMG - Object Management Group). Qualquer mecanismo que nos permita representar uma realidade complexa (vários componentes) em termos de um modelo simplificado (um único componente de mais alto nível). As metodologias OO fundamentam-se na abstração de dados, usando conceitos análogos ao de subtipo / supertipo Uma abstração enfoca a visão externa do objeto e, assim, serve para separar o comportamento essencial do objeto da sua implementação

Abstração (iii) barreira de abstração: (Sussman -“abstraction barrier”): é a divisão: comportamento / implementação, alcançada pela aplicação do princípio do “least commitment”, através do qual a interface de um objeto provê o seu comportamento essencial, e nada mais. princípio do “least astonishment” (Booch): uma abstração deve capturar o comportamento de um objeto em sua totalidade, nem mais, nem menos. ==> A decisão sobre o conjunto adequado de abstrações para um determinado domínio é o problema central do Projeto Orientado a Objetos (OOD).

Abstração (iv) Existe um espectro de abstrações, desde os tipos identificados com o domínio do problema, até objetos para os quais não há razão aparente para a sua existência (Seidewitz e Stark). Abstração de Entidades (a ideal!): um objeto que representa um modelo útil de uma entidade no domínio do problema. Abstração de Ação: um objeto que provê um conjunto generalizado de operações, as quais (todas) realizam o mesmo tipo de função. Abstração de Máquina Virtual: um objeto que agrupa operações que são todas usadas por algum nível superior de controle, ou operações em que todas usam algum conjunto de operações a nível elementar. Abstração Coincidente: um objeto que empacota um conjunto de operações que não possuem relações umas com as outras.

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

Abstração (vi) Protocolo: é o conjunto de operações que um cliente pode executar sobre um dado objeto. ADA - operation Smalltalk - method C++ - member function variáveis de estado Objeto métodos

Considerar uma plantação hidropônica Sensor de temperatura Exemplos de Abstração Considerar uma plantação hidropônica Sensor de temperatura Plano de crescimento para cada tipo de cultura descreve como a temperatura, luz, nutrientes e outros fatores devem alterar-se no tempo, a fim de maximizar a colheita Incluir código da pág. 44 do livro Object Oriented design with Applications, Grady Booch

Encapsulamento - “Information Hiding” (i) A abstração de um objeto deveria preceder as decisões acerca de sua implementação. Uma vez que uma implementação seja selecionada ela deve ser tratada como um segredo da abstração e oculta da maioria de seus clientes. Nenhuma parte de um sistema complexo deveria depender dos detalhes internas de qualquer outra parte. O encapsulamento impede os clientes de terem uma visão interna dos objetos. Trata-se de uma barreira efetiva entre diferentes abstrações. Ex.: programas que usam 3D’s não precisam se preocupar com a representar física dos dados.

Encapsulamento (ii) Para a abstração ser eficaz a implementação do conceito deve ser encapsulada. “interface”: captura a visão externa da classe “implementation”: compreende a representação da abstração, assim como os mecanismos (métodos) que realizam o comportamento desejado. Encapsulamento: é o processo de ocultar todos os detalhes de um objeto que não contribuem para as suas características essenciais (Booch).

Encapsulamento (iii) Um encapsulamento inteligente localiza decisões de projeto que são prováveis de serem alteradas. Encapsulamento em C++ Os membros (métodos) podem ser colocados nas partes: public - visíveis a todos os clientes private - completamente encapsulados protected - visíveis à classe e às suas subclasses friendship classes - classes cooperativas que permitem a visão das partes privativas de outras classes

Herança (i) Hierarquia: é uma classificação ou ordenamento das abstrações (Booch) As duas hirarquias mais importantes de um sistema complexo: estrutura de classes (“kind of”) estrutura de objetos (“part of”) Herança (hierarquia “is a”) Define uma relação entre classes, em que uma classe compartilha a estrutura e o comportamento definido em uma ou mais classes (herança simples e herança múltipla, respectivamente).

Herança (ii) Herança: representa uma hierarquia de abstrações, em que uma subclasse herda de uma ou mais superclasses. Tipicamente a subclasse aumenta ou redefine a estrutura e o comportamento de uma ou mais classes. Hierarquias de Generalização / Especialização Com a evolução da hierarquia, as estruturas e comportamentos comuns a diferentes classes tenderão a migrar para superclasses comuns. superclasses => abstrações generalizadas subclasses => especializações incluir exemplo da página 56 do livro Object Oriented Design with Applications, Grady Booch

Tensão entre os Princípios Abstração Encapsulamento Hierarquia

Herança (iii) Para uma classe específica, normalmente há dois tipos de clientes: objetos que invocam operações (métodos) em instâncias da classe subclasses que herdam da classe (viola o encapsulamento)

dobermann + rotweiller Exemplos de Herança mamíferos cães herança simples dobermann rotweiller dog alemão herança múltipla híbrido dobermann + rotweiller

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. Incluir exemplo de C++

Exemplo de Polimorfismo move treinador de circo

Modularidade (i) Classes e objetos formam a estrutura lógica de um sistema. Estas abstrações são agrupadas em módulos, que integram a estrutura física de um sistema. As conexões entre os módulos são as assumções que os módulos fazem entre si (Parnas). A maioria das linguagens que suportam o conceito de módulo distingüem entre ïnterface” e “implementation”.

Modularidade (ii) Em C++ módulos são arquivos compilados em separado ... as interfaces são colocadas em arquivos .h (“header files”) as implementações, em arquivos .c dependências entre estes arquivos são resolvidas com o uso da macro #include Em Pascal units as units distingüem entre “interface” e “implementation”

Modularidade (iii) Decidir sobre o conjunto de módulos para um sistema é tão difícil quanto definir sobre o conjunto correto de abstrações. Uma solução é agrupar classes e objetos logicamente relacionados em um mesmo módulo e expor somente aqueles elementos que os outros módulos devem ver. O custo de recompilar o corpo (“implementation part”) de um módulo é pequena; só este módulo precisa ser recompilado e, então “link-editado” com o restante da aplicação. Já o custo de recompilar a “interface” é relativamente alto. Deve-se recompilar a interface do módulo, seu corpo, e todos os módulos que dependem desta interface, os módulos que dependam destes outros e, assim, sucessivamente. Exemplificar em C++

Modularidade (iv) A interface de um módulo deve ser a mais simples possível (ocultar tudo o que se puder, no corpo do módulo) Modularidade: é a propriedade de um sistema que foi decomposto num conjunto de módulos coesivos e fracamente acoplados (Booch). desejo de encapsular as abstrações tornar certas abstrações visíveis a outros métodos

Modularidade (v) Procurar agrupar classes e objetos em módulos que facilitem a reutilização Lembrar que os módulos freqüentemente servem como unidade de documentação e gerenciamento de configuração Questões relativas a segurança podem influenciar no particionamento dos módulos Atenção: A identificação de objetos e classes é parte do projeto lógico do sistema A identificação dos módulos é parte do projeto físico As decisões relativas aos projetos lógico e físico interagem entre si

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. Typing is the enforcement of the class of an object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways. incluir exemplos C++ ver pág. 62 do Booch

Tipos (ii) Benefícios das linguagens fortemente tipadas: Sem a verificação de tipos um programa pode abortar misteriosamente. O ciclo edição - compilação - depuração é muito tedioso. Assim, a detecção de erros o mais cedo possível é indispensável. As declarações de tipos ajudam na documentação Geração de código mais eficiente

Tipos (iii) “Static and Dynamic Binding” (Ligação / Associação Estática e Dinâmica) “Strong Typing”: refere-se à consistência entre tipos “Static Typing” (“Static Binding” ou “Early Binding”): significa que os tipos de todas as variáveis e expressões são fixados em tempo de compilação. “Dynamic Binding”(“Late Binding”): significa que os tipos de todas as variáveis e expressões só serão conhecidos em tempo de execução. “Strong Typing” e “Binding” são conceitos independentes O Polimorfismo existe quando as “features” de herança e “dynamic binding” interagem

strongly & static typed Object Pascal & C++ Tipos (iv) ADA strongly & static typed Object Pascal & C++ strongly typed & dynamic binding Smalltalk untyped & dynamic binding

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”

Concorrência (ii) início fim

Concorrência (iii) Concorrência e OOP são ortogonais nos níveis mais elementares de abstração. (OOP ou não, todos os problemas tradicionais em programação concorrente permanecem) Tipos de problemas tratados em concorrência: “deadlock” “starvation” exclusão mútua OOP pode aliviar o problema da concorrência, ocultando-a dentro de abstrações reusáveis. Em havendo concorrência, não basta simplesmente definir os métodos de um objeto. Devemos certificar-nos que a semântica do método será preservada na presença de vários caminhos de controle. Incluir exemplo do Booch, pág. 67

Persistência (i) LPs Bases de Dados + = OODB 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 + = Object Model Persistence OODB

Persistência (ii) Persistência: é a propriedade de um objeto, através da qual sua existência transcende o tempo (i.e., o objeto continua a existir após o seu criador ter deixado de existir) e/ou espaço (i.e., a localização do objeto move-se do espaço de endereçamento no qual ele foi criado).

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”. Aplicações do Modelo Objeto: ver pág. 72 do Booch.

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. Incluir figura sobre o “Waterfall Life Cycle

Ciclo de Vida dos Projetos Orientados a Objetos (ii) Nos POO os gerentes defrontam-se com problemas adicionais, pois não há fases bem definidas como no “Waterfall Life Cycle”. As atividades (análise, projeto, codificação e teste) ocorrem concorrentemente. Há o grande perigo de: “Nothing is done until it’s all done” Em POO o desenvolvimento é evolutivo Já os gerentes normalmente perseguem: fases bem nítidas diferentes marcos (“milestomes”) diferentes “check-points”

1. Modelagem dos Objetos Num POO todas as atividades do ciclo de vida compartilham um vocabulário, notação e estratégias, i.e.,tudo gira em torno de objetos. Em termos simplistas, o processo de desenvolvimento de “software” poderia ser considerado como uma seqüência de: desenvolvimento de objetos centrais relacionados ao negócio; adição de objetos específicos da aplicação; por fim, estes objetos seriam envolvidos em objetos relacionados à implementação, os quais lidam com aspectos relativos à estrutura de “hardware” e “software”. Em projetos que usam metodologias tradicionais, as atividades de projeto, análise e programação não parecem estar relacionadas.

2. Modelagem Estratégica (Modelagem de Empresa) O objetivo é desenvolver um modelo de uma unidade de negócios ou empresa, a qual pode conter um número de diferentes sistemas. Conceito de grande interese para aqueles que desenvolvem sistemas de informação orientados a negócios. No passado, quando foi introduzido nas metodologias de desenvolvimento de “software”, a ênfase principal era descobrir pontos comuns entre sistemas. Os modelos de dados das empresas, documentados com diagramas entidade-relacionamento, não foram bem sucedidos ... Reengenharia de negócios

Modelagem de Análise - I (“Analysis Modeling”) Consiste de atividades para descobrir e documentar os requisitos do usuário para um sistema específico. alguns engenheiros de “software” pensam que a AM resume-se à criação de protótipos em C++ e Smalltalk. A atividade de análise fundamenta-se na premissa de que vale a pena formalizar os requisitos de uma aplicação. Outra premissa importante da atividade de análise é que o ambiente no qual a aplicação será usada é bem compreendido e relativamente estável, e o usuário final tem uma idéia razoável do que deseja da aplicação.

Modelagem de Análise - II (“Analysis Modeling”) Em todas as metodologias de análise o analista ignora as restrições físicas (“hardware”, “software”, etc...) e procura criar um MODELO TECNOLÓGICO PERFEITO. Produto final da AM: um modelo formal e minucioso do que o usuário espera que o sistema faça. Nas metodologias orientadas a objeto há uma preocupação quanto ao reuso dos objetos (dados e métodos), desde as fases iniciais.

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

Modelagem de Projetos (ii) É na atividade de projeto que as restrições e facilidades de hw e sw começam a impactar o modelo desenvolvido a nível de análise “user interface”: atividade a nível de análise ou a nível de projeto? “sequencing” + “timing” + “coordination” + “synchronization” atividades importantes na fase de projeto Nesta fase, muitas vezes o projetista preocupa-se com: comportamento dependente do tempo dos objetos comunicação entre os objetos

Modelagem da Implementação Típicamente voltada para a distribuição dos objetos entre os vários componentes de “hardware” e “software” em uma rede cliente-servidor. Deve-se ter uma estratégia para determinar como os objetos e classes serão distribuídos pelos vários componentes do ambiente operacional de “hardware” e “software”.

Metodologias de Desenvolvimento de “Software” (i) Desenvolvimento em Cascata (“Waterfall Life Cycle”), Projeto Interativo, Projetos de Rápido Desenvolvimento, Modelos de Ciclo de Vida em Espiral (“Spyral Life Cycle Models”) “Waterfall Life Cycle”: as atividades são executadas uma vez e numa seqüência bem definida. As saídas (“outputs”) de uma atividade servem de entrada (“inputs”) para a próxima atividade. Tipicamente nada pode ser demonstrado para o usuário final, até que o derradeiro estágio do ciclo de vida em cascata tenha sido completado.

Metodologias de Desenvolvimento de “Software” (ii) Os Projetos Orientados a Objetos são ortogonais aos tradicionais ciclos de vida em cascata, em virtude de sua abordagem interativa e incremental. As decisões sobre: abordagem Orientada a Objetos para Desenvolvimento de Sistemas Waterfall x Prototipagem são totalmente independentes. Muitos acreditam que os benefícios da OO estão mais intimamente associados com a ênfase em interação, prototipagem e desenvolvimento interativo que a outras características como herança e polimorfismo.

Metodologias de Desenvolvimento de “Software” (iii) Requisitos para sucesso na Prototipagem: aceitação política do paradigma um “framework” comum para todas as atividades do ciclo de vida A abordagem interativa ajuda a gerência a distingüir entre progresso real e progresso mensurável. A equipe de desenvolvimento influencia na metodologia de desenvolvimento projetos OO possuem a tendência de envolver grupos pequenos de desenvolvedores, que trabalham muito próximos de um também pequeno grupo de usuários finais. projetos com equipes grandes (ex. 200 pessoas) são mais difíceis de conduzir em um ambiente de prototipagem rápida. “Waterfall” seria mais apropriado.

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.

Classes e Objetos - Estado de um Objeto O comportamento de um objeto é influenciado por sua história: a ordem em que operamos um objeto é importante. A razão para este comportamento dependente do tempo é o estado do objeto. O estado de um objeto compreende todas as (usualmente estáticas) propriedades do objeto, mais os valores correntes (usualmente dinâmicas) de cada uma dessas propriedades. Uma propriedade é uma característica inerente ou distintiva, traço ou qualidade, que torna o objeto único. As propriedades possuem algum valor ou podem denotar outro (s) objeto (s). Objetos existem no tempo, são identificáveis, têm estado e são instanciados. Podem ser criados, destruídos e compartilhados. Incluir exemplo da pág. 79

Objetos em C++ - Exemplo (i) struct PersonnelRecord { char *name[100]; int socialSecurityNumber; char *department[10]; float salary; };

Objetos em C++ - Exemplo (ii) class PersonnelRecord { public: char *employeeName () const; int employeeSocialSecuriryNumber () const; char *employeeDepartment () const; protected: void setEmployeeName (char *name); void setEmployeeSocialSecuriryNumber (int number); void setEmployeeDepartment (char *department); void setEmployeeSalary (float salary); float employeeSalary () const; private: char *name[100]; int socialSecuriryNumber; char *department[10]; float salary; }; a representação da classe está oculta a todos os clientes; se a estrutura da classe for alterada, o módulo que a contém deverá ser recompilado, porém nenhum cliente será afetado; as decisões de projeto explicitamente estabelecem que operações podem ser realizadas nos objetos da classe; todos os clientes podem ter acesso a nome, número da seguridade social e ao departamento de um empregado. Porém apenas alguns clientes especiais têm permissão para “setar” estes valores; somente clientes especiais podem recuperar o salário de um empregado;

Comportamento de um Objeto Classes e Objetos Comportamento de um Objeto Comportamento (“Behavior”): objetos não existem isoladamente. Eles sofrem ações e agem sobre outros objetos. Comportamento é como um objeto age e reage, em termos de mudança de estado e “message passing”. O comportamento de um objeto é completamente definido por suas ações. Uma mensagem é simplesmente uma operação que um objeto realiza sobre outro objeto. operação = método = mensagem = funcão membro Incluir exemplo de “behavior” - pág. 81

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.

O Significado das Operações (ii) Coletivamente, todos os métodos associados a um objeto compreendem o PROTOCOLO daquele objeto. O PROTOCOLO de um objeto define a totalidade de seu comportamento e compreende a totalidade da visão estática e dinâmica do objeto. Objetos como Máquinas de Estado Finitos Objetos Ativos Passivos

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.

Objetos - Ciclo de Vida O tempo de vida (“life time”) de um objeto estende-se do momento de sua criação até o momento da devolução do espaço por ele ocupado. Um objeto pode continuar a existir, ainda que todas as referências ao mesmo sejam perdidas. Para tanto, basta que continue a consumir espaço.

Relações entre Objetos Os objetos contribuem para o comportamento global de um Sistema por meio da colaboração mútua. As relações entre dois objetos quaisquer englobam as assunções que cada um faz do outro, incluindo quais operações podem ser realizadas e qual o comportamento resultante. Dois tipos de hierarquia são de particular interesse em OOD: relações de uso relações de incorporação (“containing relationships”) Relação de Uso: quando um objeto envia uma mensagem para outro objeto (No diagrama é indicado por uma linha cheia entre os dois objetos em questão)

Objetos nas Relações de Uso Em uma relação de uso, cada objeto pode desempenhar um dos papéis: Ator: um objeto que pode operar sobre outros objetos, mas que nunca é operado por outros objetos (ator = objeto ativo). Servidor: um objeto que nunca opera sobre outros objetos. É tão somente operado por outros objetos. Agente: um objeto que pode operar sobre outros objetos e também ser operado por outros objetos.

Exemplo de Relação de Uso entre Objetos v1 v2 Controlador do Processo Cadinho v3 T fogo

O Significado da Sincronização Sempre que um objeto passa uma mensagem para outro, com o qual tem uma relação de uso, os dois objetos devem sincronizar-se de algum modo. Aplicação completamente sequencial: chamada de subrotinas “Multiple threads of control”: mecanismos de sincronização mais sofisticados para lidar com problemas como o de exclusão mútua. Objeto Sequencial: objeto passivo, cuja semântica é garantida somente na presença de um único caminho de controle. “Blocking Object”: objeto passivo, cuja semântica é garantida na presença de múltiplos caminhos de controle. Objeto Concorrente: objeto ativo, cuja semântica é garantida na presença de múltiplos caminhos de controle.

“Containing RelationShips” Objetos Compostos ou Agregados: trata-se de objetos que contêm outros objetos. reduz o número de objetos visíveis. Há um maior acoplamento entre os dois objetos. Ex.: um objeto apartamento pode incorporar os objetos cozinha, área de serviço, sala de jantar, quartos, varanda, etc... Exemplo em C++: class Ponto { int x; int y; }; class Circulo { int raio; Ponto centro; Incluir exemplos de objetos compostos em C++

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.

A Natureza de uma Classe (ii) Uma LP fortemente tipada (“strongly typed”) detecta violações de contrato em tempo de compilação. implementation interface interface visão interna visão externa

A Natureza de uma Classe (iii) a “interface” de uma classe proporciona a visão externa da classe enfatiza a abstração oculta a estrutura e segredos de seu comportamento A “interface” consiste basicamente de: declarações de todas as operações (métodos) aplicáveis às instâncias da classe; pode incluir declarações de outras classes, constantes, variáveis e exceções necessárias para complementar a abstração a implementação da classe provê a sua visão interna, os segredos de seu comportamento; basicamente consiste da implementação de todas as operações definidas em sua interface.

Interface A interface de uma classe pode ser dividida em três partes: Public:declaração que forma parte da interface da classe e é visível para todos os clientes que são visíveis a ela. Protected: declaração que forma parte da interface da classe, mas que não é visível a quaisquer outras classes, exceto suas subclasses. Private: declaração que forma parte da interface da classe, mas que não é visível a quaisquer outras classes. C++ é a linguagem mais indicada para explicitar as diferentes partes da interface da classe (possui, ainda, as classes “friendship”)

Estado do Objeto (i) O estado de um objeto deve ter alguma representação que seja tipicamente expressa como declarações de constantes e variáveis, situadas na parte privada da interface da classe. Desta forma, a representação comum dos objetos de uma classe é encapsulada e alterações nesta representação não afetarão a funcionalidade de quaisquer clientes. Por que a representação de um objeto é parte da interface de uma classe (ainda que private) e não de sua implementação? Se definíssemos a representação de um objeto na implementação de uma classe, teríamos que completá-la, antes que pudéssemos usar quaisquer clientes. Frustaríamos, assim, o propósito de separar a visão externa da visão interna.

Estado do Objeto (ii) 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

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)

Relações entre Classes (ii) Há 3 tipos de relações básicas entre classes: generalização (tipo de - “kind of”): indica que uma classe é uma subclasse de uma outra classe mais geral. (ex.: rosa x flor) agregação (“part of”): indica que uma classe é parte de outra. (ex.: pétala x flor) associação: indica alguma conexão semântica entre 2 classes. (ex.: rosas x candelabros --> decoração) As LPs possuem diversos mecanismos para expressar estas relações, destacando-se as relações de: herança, uso, instanciação, metaclasse.

Herança (i) Herança: pode ser usada para expressar generalização e associação. Ex.: Dados de Telemetria Dados de diferentes subsistemas (energia e propulsão) e de diferentes sensores (radiação, espectômetro de massa, temperatura, detectores de colisão com micrometeoros, etc...) Os dados telemétricos são usualmente transmitidos como uma seqüência de bits, consistindo de um “header”, o qual inclui um “time stamp” e alguma chave para identificar o tipo de informação que se segue, mais vários “frames” dos dados processados pelos vários subsistemas e sensores.

Herança (ii) struct time { int elapseDays; int seconds; }; struct ElectricalData { Time timeStamp; int id; float fuelCell1Voltage, fuelCell2Voltage; float fuelCell1Amperes, fuelCell2Amperes; float currentPower;

Herança (iii) Problemas: A representação de ElectricalData não está encapsulada. Os clientes podem alterar valores de dados importantes. A estrutura está exposta. Qualquer mudança na mesma impactaria todos os clientes. Todas as referências à estrutura deveriam ser recompiladas. As alterações dos clientes podem violar as assunções que eles tinham sobre a representação e ocasionar erros nos programas. Operações diversas podem aplicar-se a instâncias da estrutura, mas não há meios de se associar estas operações à estrutura. Há o problema de redundância, no caso de precisarmos representar centenas de diferentes tipos de dados de telemetria que incorporem a representação de ElectricalData e que incluam outros dados adicionais.

Herança (iv) Solução (i): Declarar uma classe para cada tipo de dado de telemetria. Ocultamos a representação de cada classe e associamos os dados às operações aplicadas sobre os mesmos. Todavia, não resolvemos o problema da redundância. Solução (ii): Construir uma hierarquia de classes, em que classes especializadas herdam a estrutura e comportamentos definidos pelas classes mais gerais.

Herança (v) class TelemetryDate { public: TelemetryData (); /* construtores */ TelemetryData (const TelemetryData&); virtual ~TelemetryData (); /* destrutor */ virtual void send (); Time currentTime () const; protected: int id; private: Time timeStamp; };

class ElectricalData: public TelemetryData { public: Herança (vi) class ElectricalData: public TelemetryData { public: ElectricalData (float v1, float v2, float a1, float a2); ElectricalData (const ElectricalData&); virtual ~ElectricalData (); virtual void send (); virtual float currentPower () const; protected: float fuelCell1Voltage, fuelCell2Voltage, float fuelCell1Amperes, fuelCell2Amperes; }; Esta nova classe herda a estrutura e métodos da classe TelemetryData, mas adiciona sua estrutura e redefine seu comportamento (no caso, o método send).

O significado da herança entre classes Herança: É uma relação entre classes em que uma classe compartilha a estrutura e o comportamento definido em uma classe (herança simples), ou em várias classes (herança múltipla). Superclasse: é a classe da qual se herda. Subclasse: é a classe que herda. Herança define uma hierarquia “tipo de”(“kind of”) entre classes. Uma subclasse tipicamente aumenta ou redefine a estrutura e comportamento de suas superclasses. A capacidade de suportar herança é o que distingüe as LPs baseadas em objeto (“Object Based”) das LPs Orientadas a Objeto (“Object Oriented”).

Relações de Herança Simples entre Classes Telemetry Data Sensor Electrical Propulsion Spectometer Camera Radiation

Classes Abstratas: não são instanciadas. Em C++ pode-se assegurar que um método de uma classe seja invocado diretamente. Para tanto, inicializa-se a sua declaração com zero. (“pure virtual function”) C++ proíbe a criação de instâncias de classes que exportam métodos puramente virtuais. Classe Base: é a classe mais geral de uma estrutura. Uma dada classe possui dois tipos de clientes: instâncias (objetos) subclasses Interfaces para estes 2 tipos de clientes são definidas. Em C++ pode-se escolher que membros são visíveis para instâncias (objetos), subclasses, ou ambos.

O Significado do Polimorfismo Para entendermos o significado de uma classe particular devemos, muitas vezes, estudar suas superclasses, incluindo a sua visão externa. Em C++ os métodos declarados como virtuais em uma classe podem ser redefinidos em suas subclasses. Os outros métodos, não. Polimorfismo: é um conceito na Teoria dos Tipos (“Type Theory”) no qual um nome pode denotar objetos de várias classes diferentes, que são relacionadas por alguma superclasse comum. Assim, qualquer objeto denotado por este nome está habilitado a responder a um conjunto comum de operações em diferentes modos.

Polimorfismo: Exemplos (i) Ex.: Para a classe TelemetryData poderíamos implementar a função membro send como se segue: void Telemetry::send () { // transmit the id // transmit the timeStamp }; Implementação de send para a classe ElectricalData: void ElectricalData::send () { TelemetryData::send (); // transmit the fuellCell1Voltage and // fuellCell2Voltage // transmit the fuellCell1Amperes and // fuellCell2Amperes Primeiro, invoca-se a função send definida na superclasse e então, aumenta-se o comportamento enviando-se os dados associados com a classe especializada.

Polimorfismo: Exemplos (ii) Supor a existência de instâncias das 2 classes: TelemetryData telemetry; ElectricalData electrical (5.0, -5.0, 3.0, 7.0); Supor que os objetos telemetry e electrical foram criados. Se tivermos a função: void sendTelemetryData (TelemetryData &D) { d.SEND (); }; O que acontece quando fazemos ? sendTelemetryData (telemetry); sendTelemetryData (electrical);

Polimorfismo Sem polimorfismo, a alternativa seria o uso de vários comandos “switch”. Polimorfismo é mais útil quando coexistem várias classes com o mesmo protocolo. Polimorfismo e “late binding” andam de mãos dadas. Em C++ o programador pode decidir se uma função membro usará “late binding” ou “early binding”. virtual method “late binding” polimorfismo

Herança e Tipos A maior parte das LPS permite à implementação de um método de uma subclasse invocar um método definido por alguma superclasse. É comum, para a implementação de um método redefinido, invocar o método de mesmo nome definido pela sua classe pai. Em C++, pode-se invocar o método de qualquer antecessor (enquanto o mesmo for visível) prefixando-se o nome do método com o nome da classe. Um objeto pode referenciar-se a si mesmo usando o “pointer” implicitamente declarado “this”.

Polimorfismo: Invocação de Métodos (i) Shape Circle Triangle Rectangle Solide Rectangle

Polimorfismo: Invocação de Métodos (ii) Cliente x Desenhar n fig. 1 Lista de Figuras

Tipos x Relações de Herança Uma atribuição de um objeto X para um objeto Y (Y = X ) é possível se o tipo de X é o mesmo que o tipo de Y, ou um subtipo de Y. TelemetryData telemetry; ElectricalData electrical (5.0, -5.0, 3.0, 7.0); comando legal: telemetry = electrical; //electrical é um subtipo de telemetry comando ilegal: electrical = telemetry; //telemetry não é um subtipo de electrical

Dois problemas relacionados à herança múltipla: Herança Múltipla (i) Dois problemas relacionados à herança múltipla: i) como lidar com a colisão de nomes de superclasses diferentes (métodos e/ou variáveis de instância com o mesmo nome). ii) como manipular heranças repetidas (uma classe que é antecessora de outra por duas vias distintas). Abordagem para solucionar i): a semântica da linguagem (sl) poderia encarar uma colisão de nomes como ilegal e recusar a compilação da classe. a sl poderia assumir que o mesmo nome, introduzido por diferentes classes, refere-se ao mesmo “slot” (Clos). a sl permite a colisão, mas requer que as referências ao nome sejam totalmente qualificadas (C++).

Herança Múltipla (ii) abordagem para resolver ii): tratar as ocorrências de heranças repetidas como ilegais; pode-se permitir duplicação de superclasses, mas se requer o uso de nomes totalmente qualificados para se referenciar a membros de uma cópia específica (C++); pode-se tratar múltiplas referências à uma classe como denotando a mesma classe (C++, quando a superclasse repetida é introduzida como uma classe base virtual). Polimorfismo Múltiplo: Multi-métodos que são especializados em mais que um parâmetro. Display DisplayDevice

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 Classes “friend ship” em C++: possibilitam o acesso a membros de outra classe que, de outra forma, seriam “privates”. TLibrary “interface” “implementation” 1 1 n 1 TBook TList

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. Ver exemplo da pág. 117 do Booch - Object Oriented Design with Applications.

“Container Classes” (i) Um set (conjunto) é um exemplo de “container class”, cujas instâncias são coleções de outros objetos. 4 possibilidades para construir-se “Container Classes”: i) via o uso de macros (e.g. C++) Só funciona em pequena escala, porque manutenção das macros é deselegante e trabalhosa. Cada instanciação resulta em uma nova cópia do código. ii) herança e “late binding” (Smalltalk) Com esta abordagem pode-se construir somente classes de agrupamento heterogêneas, porque não há modo de declarar a classe específica dos elementos do agrupamento. Cada ítem é tratado como se fosse uma instância da classe base Object.

“Container Classes” (ii) iii) Usa-se a abordagem comumente utilizada em Object Pascal. Constrói-se classes de agrupamento generalizadas, como em Smalltalk, mas então usa-se código de “type checking” explícito para forçar a convenção de que os conteúdos sejam todos da mesma classe, o que é afirmado quado o “container object” é criado. iv) usa-se classes parametrizadas (CLU) ou classes genéricas. Servem de “templates” para outras classes. Podem ser parametrizadas por classes, objetos, e/ou operações. Uma classe parametrizada deve ser instanciada antes que objetos possam ser criados.

Relações de Metaclasse Uma metaclasse é uma classe cujas instâncias são, elas mesmas, classes. suportadas em CLOS e Smalltalk C++ não suporta explicitamente metaclasses. Todavia, provê variáveis de classe e métodos de classe. Basta declarar um “member object” ou “member function” como static, o que significará que será compartilhado por todas as instâncias da classe.

Relações entre Classes e Objetos Cada objeto é uma instância de alguma classe Toda classe possui zero ou mais instâncias Classes são estáticas. Sua existência, semântica e relações são fixadas anteriormente à execução de um programa. A classe da maioria dos objetos é estática. Uma vez criado o objeto, a sua classe é fixada. Objetos são criados e destruídos durante a vida da aplicação.

O Papel das Classes e Objetos no Projeto (“Design”) Na fase de análise e etapas iniciais do projeto há duas tarefas principais: identificar as classes e objetos que formam o domínio do problema. Inventar as estruturas em que conjuntos de objetos trabalhem cooperativamente para prover o comportamento global que satisfaça os requisitos do sistema. “Key abstractions” (classes e objetos) “mechanisms of implementation” (as estruturas cooperativas) visão externa / estrutura lógica do sistema após visão interna / estrutura física

Mensurando a Qualidade da Abstração (i) Um sistema deve ser construído com um conjunto mínimo de partes imutáveis. Estas partes devem ser tão gerais quanto possível. Todas as partes do sistema devem compor uma estrutura uniforme (Ingalls, p. 123 Booch) O projeto das classes e objetos é um processo incremental e interativo (experiência do Booch) Métricas para saber se uma classe ou objeto está bem projetado: Acoplamento (“Coupling”) Coesão (“Cohesion”) Suficiência (“Sufficiency”) Completude (“Completeness”) “Primitiviness”

Mensurando a Qualidade da Abstração (ii) Acoplamento: medida do grau de associação estabelecido pela conexão entre módulos. Pode-se reduzir a complexidade através de sistemas projetados com o mínimo grau de acoplamento possível. Há uma tensão entre os conceitos de acoplamento e herança. Coesão: mede o grau de conectividade entre os elementos de um mesmo módulo (objeto ou classe) coesão funcional: em que todos os elementos de uma classe ou módulo atuam em conjunto para prover um comportamento bem delimitado. É a forma mais desejada. coesão acidental: em que abstrações não relacionadas entre si são agrupadas em uma classe ou módulo. É a menos desejada.

Mensurando a Qualidade da Abstração (iii) Suficiência: Propriedade da classe ou módulo que captura bastante características da abstração, de modo a permitir uma interação eficiente e plena de significado. Completude: quando a interface da classe ou módulo captura toda as características significativas da abstração. Enquanto suficiência implica em uma interface mínima, uma interface completa é aquela que cobre todos os aspectos da abstração. Uma classe (ou módulo) completa é aquela cuja interface é bastante geral, de modo a ser usada por qualquer cliente. Operações Primitivas são aquelas que podem ser eficientemente implementadas, somente tendo-se acesso à representação interna da abstração.

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.

Heurísticas Para a Escolha de Operações (i) Dado um comportamento devemos decidir em que classe incorporá-lo. Critérios: Reusabilidade: o comportamento será útil em mais de um contexto? Complexidade: qual a dificuldade em se implementar o comportamento? Aplicabilidade: quão relevante é o comportamento para o tipo (classe) em que poderia ser implementado? Conhecimento da Implementação: a implementação do comportamento depende dos detalhes internos do tipo (classe)?

Heurísticas Para a Escolha de Relações (ii) Florestas x Árvores As florestas são mais fracamente acopladas, porém não exploram os aspectos comuns existentes entre as classes. As árvores exploram os aspectos comuns, porém, para entendermos uma classe determinada, precisaremos conhecer todas as classes das quais ela herda seus métodos e/ou atributos. Herança x Relações de Uso Herança é mais apropriada quando toda instância de B pode também ser vista como uma instância de A. A relação de cliente é mais apropriada quando quando toda instância de B simplesmente possui um ou mais atributos de A.

Análise Orientada a Objetos (AOO) AOO é um modelo para cpaturar os requisitos do usuário para um sistema. Baseia-se na OO. Dois Exemplos: Sistema tradicional de processamento de dados para gerenciar a publicação e distribuição de uma revista para os seus assinantes. Sistema de controle de processos para controlar um elevador.

A Descoberta de Objetos (i) O ponto mais importante de uma metodologia OO é o processo de descobrir que classes e objetos serão incluídos no modelo. Motivação: A descoberta de objetos como parte do modelo de requisitos é a crença de que uma representação técnica OO do sistema estará mais próxima da visão conceitual do usuário sobre o sistema, que em qualquer outro modelo adotado. Os usuários não pensam em termos de funções ou entidades. Eles pensam em termos de objetos. (Todavia, não há provas ...)

A Descoberta de Objetos (ii) A descoberta dos objetos essenciais depende da perspectiva adotada dados funcional comportamental Objetos constituem uma métafora natural para descrever certas aplicações GUI front-ends arquiteturas cliente-servidor processamento de dados distribuídos

Notação Gráfica Para Classes e Objetos (i) História: DFD’s (“data-flow diagrams”, “bubles” - DeMArco, “bubtangles” - GANE-Sarson) ERDs (“entity-relationship diagrams”) Notação do Yourdon para classes: nome da classe atributos métodos

Notação Gráfica Para Classes e Objetos (ii) Notação para Objetos Notação do Booch nome da classe atributos métodos utility class-name class-name object-name

Notação Gráfica Para Classes e Objetos (iii) A escolha da notação o analista deve escolher a notação mais adequada para seus propósitos. poder de expressão. formal e rigorosa para evitar ambigüidades. simples, de forma a ser entendida pelos usuários. Anecessidade dos diagramas aparece quando iniciamos: a construção da hierarquia dos objetos a documentação das relações entre objetos o detalhamento da comunicação entre objetos

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.

Como Encontar Objetos (ii) 2. A Perspectiva Funcional Caracterização dos objetos pelo que eles fazem “CRC cards - “Class-Responsabiblity-Communication” a que classe o objeto pertence? que responsabilidades ele possui? que funções exerce? Como ele se comunica com os outros objetos? Atenção: Cuidado para não corromper o Sistema Orientado a Objetos construindo um modelo completamente funcional dos requisitos do usuário.

Como Encontar Objetos (iii) 3. A Perspectiva Comportamental Questão Fundamental: Como os objetos se comunicam? Como respondem a mensagens, sinais, interrupções e outras formas de comunicação? Mais voltada para sistemas em tempo real e sistemas distribuídos. Uma visão mais minuciosa do comportamento dos objetos tipicamente introduz um ou mais tipos de diagramas adicionais no processo de AOO. Diagramas de: transição de estados e de comunicação de eventos ou interação entre objetos, para ilustrar a comunicação entre objetos).

Como Encontar Objetos (iv) Yourdon sugere: 1. Desenvolver uma lista de eventos ou estímulos externos aos quais o sistema deva responder. Tipicamente, cada fluxo de dados de entrada no diagrama de contexto corresponderá a um evento na lista de eventos. 2. Projete um diagrama de fluxo de dados inicial em que cada evento de entrada é capturado por uma única bolha DFD. 3. Identificar as etapas de processameto necessárias para o sistema para o sistema responder ao evento de modo satisfatório. (Nesta etapa poderá haver a geração de minis-DFDs). 4. Agregue os minis-DFDs gerados na etapa 3.

Como Encontar Objetos (v) 5. Para produzir um DFD em níveis, particione algumas bolhas, usando o processo de decomposição funcional. Uma atividade mais importante diz respeito à agregação de “clusters” de bolhas em superbolhas em um DFD de nível mais elevado. Este processo poderia ser repetido até se conseguir uma única superbolha: o diagrama de contexto para o sistema. A racionalidade ou estratégia para se agregar bolhas é orientada a objetos por natureza (Yourdon, p. 131). As bolhas de DFD que foram agregadas em uma única superbolha de mais alto nível correspondem a funções ou métodos. A área de armazenamento comum é semelhante aos atributos de dados das instâncias dos objetos em uma classe. Cuidado! Há o perigo de se deturpar o modelo OO, partindo-se da análise estruturada / modelo funcional.

Como Encontar Objetos (vi) Candidatos a Classes e Objetos (Shlaer e Mellor) coisas tangíveis (carros, sensores de pressão, dados telemétricos, etc...) papéis (professor, fiscal, etc...) eventos (aterrisagem, interrupção, pedido, etc...) interações (empréstimo, encontro, intersecção, etc...)

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. Um especialista no domínio não precisa ser um engenheiro de “software”; precisa apenas, ser intimamente familiar com todos os elementos do problema em questão. Deve falar o vocabulário do domínio do problema.

“Smaller is better” / “Small is beautiful” 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).

Critérios Para Avaliar Candidatos a Objetos (O que se deve procurar nos objetos candidatos em um modelo AOO) Funcionalidade Essencial: A funcionalidade ou comportamento que foi identificada para o objeto proposto deve ser relevante e necessária, independentemente da tecnologia de HW e SW que será usada para implementar o sistema. Atributos Comuns: todos os atributos da classe proposta deveriam aplicar-se a cada uma das instâncias da classe (objetos). Funcionalidade Comum: todos os membros, ou serviços, da classe proposta deveriam aplicar-se a cada uma das instâncias da classe.

Representação gráfica dos “subjects” 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) Subject_1 Subject_2 Classe_1 Classe_2 ... Classe_n Representação gráfica dos “subjects”

Estrutura dos Objetos e Hierarquia das Classes O passo seguinte à identificação das classes e objetos é: a organização das classes em hierarquias baseadas no paradigma de herança, presente nas metodologias OO. a modelagem de estruturas “whole-part” (todo-parte) PESSOA (classe) é composta de: CABEÇA, CORPO e MEMBROS. Obs.: Embora seja impossível evitar-se o pensar em hierarquias durante a descoberta inicial dos objetos, usualmente é mais fácil organizar a hierarquia das classes, uma vez que se tenha uma idéia razoável de quais são as classes básicas do sistema.

GENERALIZAÇÃO-ESPECIALIZAÇÃO (i) Terminologia: Generalização-Especialização (gen-spec) Superclasse-Subclasse Mecanismo de Herança “is a hierarchy” Notação Gráfica: Superclasse SubClasse_1 SubClasse_2 Yourdon

GENERALIZAÇÃO-ESPECIALIZAÇÃO (ii) Superclasse SubClasse_1 SubClasse_2 Rumbaugh Superclasse SubClasse_1 SubClasse_2 Booch

GENERALIZAÇÃO-ESPECIALIZAÇÃO (iii) subscriber comp subscriber “comp subscriber” e “paying subscriber” são classes disjuntas. A barra indica que a subclasse ïndividual subscriber” não cobre todas as instâncias da superclasse. paying subscriber individual subscriber Martin-Odell

GENERALIZAÇÃO-ESPECIALIZAÇÃO (iv) Questões: As especializações de uma estrutura gen/spec são mutuamente exclusivas? A união de todas as especializações cobre o conjunto descrito pela generalização? A perspectiva OO nas hierarquias gen-spec é inteiramente diferente da abordagem “subtipos - supertipos” em uma modelagem de dados típica. Herança é o traço distintivo. herança simples x herança múltipla vantagens: maior poder na especificação das classes e mais oportunidades para reuso. desvantagens: perda de simplicidade conceitual e de implementação. A notaçãp da metodologia Coad-Yourdon não possui meios para indicar a resposta às questões acima.

Herança Múltipla Person Subscriber Paying Comp Subscriber Subscriber v Corporate Subscriber Individual Subscriber

Hierarquia Todo - Parte (“has a”) Possibilita que se descreva uma classe em termos de suas partes componentes, ou sub-objetos. Whole n1, n2 n5, n6 n3, n4 n7, n8 Part_1 Part_2 Hierarquia de classes na notação Coad- Yourdon

Hierarquia “has a”: Notação Assembly Class Part_1-class Part_2-class Rumbaugh whole n1, n2 n5, n6 n3, n4 n7, n8 part_1 part_2 Booch

Hierarquia “has a” Cada instância da classe whole deve consistir de ni instâncias da classe parti, onde n1<=ni<=n2. Alternativamentecada instância da classe parti pode ser uma parte de mi instâncias da classe whole, onde n3<=mi<=n4. As partes não herdam atributos ou comportamentos do todo. A implementação das estruturas whole-parts é, em geral, feita através de “pointers”. O objeto whole terá um ponteiro (ou coleção de ponteiros) para as suas partes constituintes. E as partes, tipicamente terão um “pointer” para o “whole” a que pertencem.

Como Descobrir Hierarquias “Whole-Part” em um Sistema? Em geral, a descoberta destas hierarquias é intuitiva. Refletem o mundo real? O sistema necessita de um registro de ocorrência das partes? As partes estão dentro do escopo do sistema que estamos modelando?

Relações entre Objetos (i) Construção do Modelo OO: I) Criação da classes e objetos. II) Criação da hierarquia de classes “gen-spec” e “whole-part”. III) Relações entre classes e objetos. Conceitos: Uma relação entre classes e objetos é uma representação estática de uma ‘política do usuário. Ex.: Para cada nota fiscal deve existir exatamente um cliente e, para todo cliente, pode existir zero ou várias notas fiscais. Uma colaboração entre objetos é uma relação dinâmica e ativa, que tipicamente envolve o envio de uma mensagem de um para outro objeto.

Relações entre Objetos (ii) A existência de uma relação entre objetos quase sempre implica a existência de uma colaboração, embora trate-se de conceitos independentes (separados). Uma relação entre objetos é, em geral, implementada via “pointers”, enquanto a colaboração (mensagem) é implementada via “procedure call”. Relações Binárias Relações (ou conexões entre instâncias) são estáticas. Não descrevem o comportamento ou troca de mensagens entre objetos.

Relações entre Objetos (iii) Uma instância da classe_1 é associada com n instâncias da classe_2, n1<=n<=n2; e uma instância da classe_2 é associada com m instâncias da classe_1, n3<=m<=n4. n1 ou n3 = 0 indica uma relação opcional; senão, a relação é mandatória. Se os limites inferior e superior são idênticos, a cardinalidade é expressa como um único inteiro. Class_1 Class_2 n1, n2 n3, n4 Notação Gráfica

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. Class_1 Class_2 Notação “Crow’s feet” para relações binárias.

Relações entre Objetos (v) Relações de mais alta ordem são complicadas de se visualizar, implementar e pensar que as associações binárias e devem ser evitadas tanto quanto possível. CUSTOMER ORDER PRODUCT SALES-PERSON Relação envolvendo quatro classes e Objetos

Relações entre Objetos (vi) Casos Especiais de Relações Conexões de instância “many-to-many” (vários x vários) Conexões de instância recursivas Conexões de instância múltiplas entre classes Conexões unárias entre classes Rumbaugh e colaboradores sugerem que a notação da modelagem explicitamente assegure ao analista como descrever os atributos de uma relação. CLIENTE PRODUTO 0,N 0,N Uma Relação N:N

Relações entre Objetos (vii) CLIENTE COMPRAS PRODUTO 0,N 1,N 1 0,N Introduzindo uma nova classe em uma situação N:N COMPRAS CLIENTE PRODUTO data quantidade A Notação de Rumbaugh para atributos “link”

Outra Abordagem para o Problema CLIENTE-PRODUTO Não-Comprador Cliente Comprador 1, N 1, N Produto Comprado Produto Não-Comprado

Relações entre Objetos (viii) gerencia PESSOA 0, N 1 é gerenciado por Relação Recursiva CLIENTE PRODUTO 0,N compra 0,N 0, 3 recomenda 0, 1 Relações Múltiplas entre Classes (mais de uma relação entre um par de classes)

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

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 PRODUTO FABRICANTE 1,N (C) (D) 1 Os detalhes das relações controladoras e dependentes envolvem um conhecimento substancial do estado e comportamento das classes e objetos Manter sempre a consistência: modelo --> diagrama --> comportamento dos objetos

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

Atributos dos Objetos (ii) Adicionalmente usa-se os atributos para descrever a conexão entre objetos, sob a forma de “pointers”. Como Descobrir os Atributos O analista deve estudar a aplicação, entrevistar o usuário e tentar aprende r tanto quanto possível acerca da verdadeira natureza de cada classe e objeto do modelo. (Não há mágica!) AColocação dos Atributos na Hierarquia de Classes Os atributos das estruturas “gen-spec” de mais alto nível são automaticamente herdados pelas subclasses abaixo.

Atributos dos Objetos (iii) Todavia, existem diversas situações em que atributos são inicialmente descritos nas subclasses. Até que nível da hierarquia deverão ascender? Revendo a Hierarquia de Classes O processo de revisão deverá resultar num rearranjo da hierarquia de classes. O analista deverá definir os valores legais para os atributos. Atributos com valor “NA - não aplicável” indicam que não se trata de uma classe simples, porém de uma estrutura “gen-spec”. Objetos com um só atributo podem se tornar, eles mesmos, um atributo de outro objeto. As relações (binárias) entre classes e objetos são tipicamente implementadas como atributos. Elas são parte do ESTADO do objeto. Tipicamente não são incluídas na lista de atributos do objeto.

O Comportamento dos Objetos O aspecto dinâmico dos objetos reflete-se em seu comportamento (envio de mensagens para outros objetos). Modelos de sistemas dependentes da variável tempo são importantes em: controle de processos, comutação telefônica, sistemas de aquisição de dados de alta velocidade, sistemas de controle em tempo real, “embedded systems”, etc… Nos sistemas de controle de processos e nos “embedded systems” uma parte importante da especificação é a descrição do que acontece e quando. Aplicações com estas características já são comuns em aplicações comerciais. Daí a necessidade de ferramentas de modelagem que considerem o comportamento dependente do tempo.

Diagramas “Object Life-History” - OLH (i) Os principais elementos do diagrama são: retângulos, representando estados flechas, representando a mudança de estados idle waiting for call recording message playing messages rewinding answering call

Diagramas OLH (ii) Estado: um conjunto de circunstâncias ou atributos caracterizando uma pessoa ou coisa em um dado momento; forma ou estado de ser; condição. Os estados representam condições observáveis em que um sistema pode estar. Assim, um estado representa algum comportamento do sistema que seja observável e que dure por algum intervalo de tempo finito. Cada classe tem o seu próprio diagrama OLH, que descreve o seu microcosmo. Pode-se também imaginar um diagrama OLH único para o sistema em sua totalidade, o qual representaria a agregação dos OLHs de todos os objetos do sistema.

Diagramas OLH (iii) Solução de Compromisso Prática: Diagrama de Transição de Estados para descrever o comportamento de grupos de objetos cooperantes. Envolve o desenvolvimento de um modelo da história da vida das relações entre classes e objetos. Também é possível desenvolver estes diagramas a partir da perspectiva das classes e objetos individuais. Alterações de Estado: Normalmente há regras estabelecendo quais as mudanças de estado permissíveis.

Diagrama de Transição de Estados

Diagramas OLH (iv) Condições e Ações: Complementam o diagrama OLH. As condições acarretam mudanças de estado no objeto e as ações que o objeto efetuará ao mudar de estado. Uma condição é normalmente um evento externo ao objeto, capaz de ser detectado; em geral é uma mensagem enviada por um outro objeto. Em virtude de ter mudado de estado, o objeto tipicamente efetua algumas ações: impressão de uma mensagem, realização de cálculos, apresentação de uma figura, etc... Particionamento do Diagrama de Estados (No caso de diagramas de estado em vários níveis).

Construção dos Diagramas OLH Identificar todos os estados possíveis Explorar todas as conexões possíveis entre os estados. Checkout: Todos os estados foram definidos? Pode-se alcançar todos os estados? Pode-se sair de todos os estados não-iniciais? Em cada estado o objeto responde apropriadamente a todas as condições possíveis? Inclusive aquelas condições não muito freqüentes e inesperadas?

Relações entre o Diagrama OLH e o Diagrama de Comunicação entre Objetos (i) As condições no OLH tipicamente correspondem a mensagens recebidas pela classe. As ações no OLH correspondem a mensagens enviadas para outros objetos. Diagramas OLH são úteis para todos os objetos em alguns sistemas e para alguns objetos em todos os sistemas. Os diagramas OLH são úteis como ferramentas informais de “brainstorm” para ajudar na descoberta de métodos. Diagramas OLH facilitam a documentação e explicação de comportamentos complexos de classes e objetos e na correção e consistência dos modelos. Em que estado um objeto deve estar antes : i) de ser capaz de aceitar e responder a uma dada mensagem? ii) antes que possa estabelecer uma conexão de instância (ou quebrar a conexão) com outro objeto?

Relações entre o Diagrama OLH e o Diagrama de Comunicação entre Objetos (ii) classe_1 classe_2 X estado_1 recebeu msg X envia msg ‘b’ Y b a estado_2 classe_3 classe_4 recebeu msg Y envia msg ‘a’ estado_3

Diagramas OLH (v) Conclusão: O diagrama OLH deve ser opcional. Apenas para classes e objetos cujos comportamentos sejam intrinsecamente complexos e após uma discussão inicial com o usuário. Considerar diagramas OLH para relações conectando objetos em “cluster” colaborativos.

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

Serviços dos Objetos (ii) Dentro de uma perspectiva metodológica deve-se: i) descobrir que serviços são requeridos pelas classes e objetos; ii) documentar as mensagens usadas pelas classes e objetos para comunicar-se umas com as outras; iii) especificar minuciosamente a política de negócios do usuário para cada um dos serviços identificado.

Descobrindo os Serviços Necessários Existem 5 tipos de serviços fundamentais: implícitos, tais como: criar, modificar, procurar e excluir. associados com conexões de mensagens. associados com conexões de instâncias. associados com atributos. requeridos pelo diagrama OLH.

Documentando as Conexões de Mensagens (i) classe_1 classe_2 métodos métodos Envio de mensagem para um objeto classe_1 classe_2 métodos métodos Envio de mensagem para uma classe

Documentando as Conexões de Mensagens (ii) classe_1 classe_2 x método_1 método_3 método_2 método_4 y Uma conexão de mensagens em mais minúcias classe_1 método_1 método_2 Um objeto enviando mensagem para si mesmo

Especificando os Serviços em Minúcias Descrever o comportamento, em detalhes, para cada objeto. Cada serviço descreve uma função a ser conduzida após a recepção de uma mensagem. Se os atributos foram bem definidos, então cada serviço será pequeno e altamente coeso. Usar: português estruturado diagramas de ação fluxogramas diagramas de Nassi-Shneiderman tabelas de decisão linguagens de alto nível (ex.: ADA)