Sistemas Orientados a Objetos

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

2. Programming Programming in The Large Programming in The Small

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

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

5. Sistemas Simples Complexos

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

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

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

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

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

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

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

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

14. O Problema de se caracterizar o comportamento dos Sistemas Discretos (iii) • Nos sistemas discretos todos os eventos externos podem afetar qualquer parte do estado interno do sistema. • Para grandes sistemas testes exaustivos são impossíveis • deveremos nos contentar com níveis adequados de confidência quanto à correção dos sistemas

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

16. 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?

17. Exemplos de Sistemas Complexos (i) • “Space Shuttle” • Túnel França-Inglaterra • A Internet • Organizações Transnacionais (IBM, AT&T) • O Sistema Circulatório do Homem • Estrutura de uma Planta

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

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

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

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

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

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

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

25. Os 5 Atributos dos Sistemas Complexos (i) • 1. Hierarquia Um sistema complexo é composto de subsistemas inter-relacionados que, por sua vez, possuem seus próprios subsistemas, e assim por diante, até que algum nível de componentes elementares seja alcançado. => estrutura hierárquica, que pode ser decomposta em partes, facilita o entendimento de sistemas complexos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

50. O Modelo Objeto - “The Object Model” (i) • Modelo Objeto O conjunto dos princípios que formam os fundamentos do Projeto Orientado a Objetos. Um paradigma da Engenharia de Software que enfatiza os princípios de abstração, encapsulamento, modularidade, hierarquia, tipos, concorrência e persistência.