apostila poo

CENTRO FEDERAL DE EDUCAO TECNOLGICA DA PARABA

DIRETORIA DE ENSINO COORDENAO DE INFORMTICA

INTRODUO AO

PARADIGMA DE

ORIENTAO A OBJETOS

MENSAGEM

OBJETO A

OBJETO B

AUTOR: PROF. CARLOS ALBERTO KAMIENSKI

JOO PESSOA, JULHO DE 1996

Introduo ao Paradigma de Orientao a Objetos

Copyright 1996 - Carlos Alberto Kamienski CEFET-PB - verso preliminar

NDICE 1. Introduo

1.1. Por que estudar o paradigma de orientao a objetos ? .......................... 1.2. A natureza das novas aplicaes ............................................................. 1.3. O desafio das novas tecnologias ............................................................. 1.4. Os ambientes de programao modernos ................................................ 1.5. Programao Orientada a Objetos ...........................................................

2. Conceitos bsicos e terminologia 2.1. Abstrao de dados ................................................................................. 2.2. Objetos .................................................................................................... 2.3. Mensagens ............................................................................................... 2.4. Mtodos ................................................................................................... 2.5. Classes ..................................................................................................... 2.6. Herana ................................................................................................... 2.6. Polimorfismo ........................................................................................... 2.7. Relaes entre Objeto, Classe e Herana ................................................

2.7.1. Classificao/Instanciao ....................................................... 2.7.2. Generalizao/Especializao .................................................. 2.7.3. Composio/Decomposio .....................................................

3. Avaliao da POO 3.1. Vantagens da POO .................................................................................. 3.2. Desvantagens da POO ............................................................................. 3.3. O estilo de programao com POO ......................................................... 3.4. Programao Dirigida por Eventos .........................................................

4. Linguagens Tpicas 4.1. A linguagem de programao SmallTalk ................................................ 4.2. A linguagem de programao C++ ......................................................... 4.3. A linguagem de programao Object Pascal ..........................................

5. O paradigma de orientao a objetos 5.1. Desenvolvimento Orientado a Objetos ................................................... 5.2. Anlise Orientada a Objetos ................................................................... 5.3. Projeto Orientado a Objetos .................................................................... 5.4. Tcnica de Modelagem de Objetos .........................................................

5.4.1. Anlise ...................................................................................... 5.4.2. Projeto do sistema .................................................................... 5.4.3. Projeto dos Objetos ..................................................................

5.5. Bancos de Dados Orientados a Objetos .................................................. 5.6. Outras utilizaes da Orientao a Objetos ............................................

5.6.1. Reengenharia de Processos Orientada a Objetos ..................... 5.6.2 Ambientes de Desenvolvimento de Software Orientados a

Objetos ...................................................................................... 5.6.3 Interfaces Grficas de Usurio Orientadas a Objetos ............... 5.6.4 Sistemas Operacionais Orientados a Objetos ............................

6. Bibliografia

111223556899

1113151515161617181920212225273131333334353636373838

383939

39


Copyright 1996 - Carlos Alberto Kamienski - CEFET-PB - verso preliminar

1

1. Introduo O paradigma de Orientao a Objetos (OO) no apenas um nome pomposo, uma nova terminologia ou modismo sem efeito prtico. Possui o objetivo, e consegue obt-lo em conjunto com outras tecnologias, de atenuar o que se convencionou chamar de crise do software. No incio do era dos computadores o hardware era to caro que o custo do software era muitas vezes desprezado nas organizaes. As aplicaes eram tambm, se comparadas com a atualidade, representativamente mais simples. Com o passar do tempo observou-se que os custos associados ao hardware diminuram gradativamente, enquanto que os custos do software aumentaram assustadoramente. Hoje, em uma instalao os custos associados com o software superam em vrias vezes cos custos de hardware, e a tendncia que isto aumente cada vez mais. 1.1. Por que estudar o paradigma de orientao a objetos ? Existem qualidades que atualmente todas as empresas querem atribuir a seus produtos, que nem implementam corretamente. Trs qualidades mais notrias so:

1. Sistema aberto: tudo atualmente aberto, mesmo que no siga padres (que define os sistemas abertos) de mercado ou de direito.

1. Arquitetura cliente/servidor: tudo atualmente cliente/servidor, mesmo que no possibilite a diviso do software entre clientes e servidores.

1. Orientao a objetos: tudo atualmente orientado a objetos, mesmo que no implemente objetos, classes e herana.

O primeiro bom motivo para estudar o paradigma de orientao a objetos distinguir quais produtos so orientados a objetos e quais no so. O segundo que a orientao a objetos no s moda, est-se utilizando e vai se utilizar cada vez mais desde Reengenharia de Processos Orientada a Objetos at Bancos de Dados Orientados a Objetos, passando pela anlise, projeto e programao. 1.2. A natureza das novas aplicaes A natureza das novas aplicaes de computadores tem evoludo mais rapidamente que a capacidade de concretiz-las. Algumas caractersticas crticas de novas aplicaes e necessidades emergentes incluem:

Tamanho e complexidade: Software de uso geral tem dezenas de Mbytes de cdigo-fonte. Mesmo pacotes utilitrios cuja arquitetura interna passa em larga medida despercebida pelo usurio comum chegam facilmente a essa faixa. Por outro lado, a prpria arquitetura interna das aplicaes altamente complexa, incluindo paralelismo, transaes mltiplas, forte interao grfica, etc.

Alta confiabilidade: Na medida em que sistemas automatizados vo sendo introduzidos para assistir usurios comuns no especializados em tarefas



2

complexas, a margem de erro aceitvel se torna cada vez menor, uma vez que, a rigor, o prprio operador de um sistema est a reboque do sistema e no o contrrio.

Alto desempenho: Novas aplicaes demandam alto desempenho em clculos (ex.: rastreamento por satlites, previso do tempo, sistemas de informaes geogrficas, CAD, etc.) e/ou em coordenao e comunicao entre as partes (usando redes de computadores, por exemplo).

1.3. O desafio das novas tecnologias O software sempre muito caro, os prazos no so cumpridos e a manuteno problemtica. O problema bsico a ser enfrentado em desenvolvimento de software , em poucas palavras:

CONSTRUIR SOFTWARE RPIDO, BARATO E FLEXVEL

Construir Rpido: Na medida em que os requisitos e plataformas so fludos e evolutivos, despender tempo excessivo terrvel. Por outro lado, com o backlog de aplicaes a desenvolver cada vez maior, a construo de software mais rpido uma necessidades na prtica.

Construir Barato: O custo de desenvolvimento relativamente alto, devido estruturao da tarefa nos moldes atuais em linhas de montagem hiper-dimensionadas, e devido baixa produtividade. necessrio um aumento drstico na quantidade e qualidade de software produzido por indivduos, passando pela reutilizao de software j desenvolvido.

Construir Flexvel: Sistemas devem ser arquitetados de tal forma que sua alterao para qualquer fim (modificao ou extenso para atender a novos requisitos, reutilizao em outros projetos, etc.) seja fcil.

Linhas de ao para atacar esses problemas tm includo:

investigao de novas tcnicas e seu suporte adequado em ambientes integrados para desenvolvimento de software;

reviso do modelo clssico de ciclo de vida de sistemas e de mtodos de desenvolvimento de software;

melhor compreenso de aspectos fundamentais envolvidos no processo de software.

Tais linhas de ao tm em geral seguido caminhos isolados, quando no conflitantes. H, contudo, uma nfase crescente em idias convergindo para o chamado paradigma de orientao a objetos, como uma possvel foco integrador dessas linhas. 1.4. Os ambientes de programao modernos



3

Os ambientes de Desenvolvimento de Software tm evoludo muito nos ltimos anos para incorporar vrias tecnologias num movimento sinrgico em direo obter melhores condies do desenvolvimento de sistemas. Com relao s ferramentas especficas para a programao, atualmente vrias caractersticas tm se firmado em termos de mercado:

Programao visual: programao visual se refere utilizao de interfaces grficas interativas para o desenvolvimento de programas. Dessa forma, o programador no desempenho da sua tarefa, obtm os mesmos benefcios das GUI (Grafical User Interface - interface grfica de usurio) que ele projeta.

Programao dirigida por eventos. Nos ambientes grficos o processamento perde o carter puramente seqencial que se est acostumado para ser dirigido pelos eventos gerados pelo usurio (seo 3.4).

Programao para Windows: existem vrios ambiente que utilizam programao visual e processamento dirigido por eventos, mas o Windows tornou-se o padro em termos de ambiente desktop. A programao para Windows tm certas caractersticas especficas, como o tratamento de mensagens e recursos, que no entanto, somente so de interesse de programadores de sistemas bsicos em linguagens como C.

Programao orientada a objetos: o assunto desse trabalho

RAD (Rapid Application Development): significa desenvolvimento rpido de aplicaes; ambientes que implementam RAD permitem o desenvolvimento de programas de entrada e sada de dados utilizando pouco ou nenhum cdigo (o cdigo gerado automaticamente). Utiliza a programao visual.

Prototipagem: um prottipo uma aplicao que ainda no tem toda a funcionalidade final. Seu objetivo maior o dilogo com o usurio e os refinamentos sucessivos. Tipicamente, sistemas so construdos desenhando suas telas e relatrios facilmente, com RAD, e vai evoluindo gradativamente medida que seu desenvolvimento prossegue, at adquirir toda a funcionalidade desejada.

Arquitetura Cliente/Servidor: os ambientes modernos permitem a diviso do programa entre cdigo cliente e servidor, que pode ser executado em mquinas distintas em um ambiente distribudo. Os ambientes possuem drivers para acessar SQL de vrios bancos de dados e conexo ODBC.

Sistemas abertos: em geral o objetivo de aderir a padres alcanado nesses ambientes

Gerenciamento de equipes de desenvolvedores: equipes de desenvolvedores trabalhando em um sistema complexo precisam de uma organizao nvel de programas. Os ambientes modernos proporcionam facilidades de check-in/check-out (bloqueio para leitura e escrita de componentes do sistema), controle de verses e at o armazenamento dos sistemas integralmente em bancos de dados.



4

1.5. Programao Orientada a Objetos Programao orientada a objetos (POO) uma metodologia de programao adequada ao desenvolvimento de sistemas de grande porte, provendo modularidade e reusabilidade. A POO introduz uma abordagem na qual o programador visualiza seu programa em execuo como uma coleo de objetos cooperantes que se comunicam atravs de mensagens. Cada um dos objetos instncia de uma classe e todas as classes formam uma hierarquia de classes unidas via relacionamento de herana. Existem alguns aspectos importantes na definio de POO:

Usa objetos, e no funes ou procedimentos como seu bloco lgico fundamental de construo de programas

Objetos comunicam-se atravs de mensagens

Cada objeto instncia de uma classe

Classes esto relacionadas com as outras via mecanismos de herana

POO uma maneira de programar que difere substancialmente da programao tradicional, como em COBOL, Pascal, FORTRAN, C e outras linguagens. O que torna a POO diferente que em vez de iniciar um programa escrevendo um lao principal e ento todas as subrotinas que constituem a aplicao, inicia-se decidindo quais objetos a aplicao requer e ento os objetos so caracterizados com propriedades e comportamento. Objetos so agrupados em uma hierarquia de classes, como a hierarquia existente no reino animal.

A expresso programao orientada a objetos derivada do conceito de objeto utilizado na linguagem Simula 67. Nesta linguagem, a execuo de um programa realizada de maneira cooperativa, mas no paralela, seguindo uma organizao em corrotinas, de uma coleo de objetos. Os objetos compartilhando uma estrutura comum so ditos instncias de uma mesma classe.

Embora outras linguagens de programao tenham mostrado algumas tendncias orientao a objetos, Smalltalk ainda a linguagem mais representativa do paradigma de objetos. Mais do que uma linguagem de programao, Smalltalk um completo ambiente de programao refletindo a filosofia de orientao a objetos.

Programao orientada a objetos d nfase estrutura de dados, adicionando funcionalidade ou capacidade de processamento a estas estruturas. Em linguagens tradicionais, a importncia maior atribuda a processos, e sua implementao em subprogramas. Em uma linguagem como Pascal, procedimentos ativos agem sobre dados passivos que foram passados a eles. Em linguagens orientadas a objetos, ao invs de passar dados a procedimentos, requisita-se que objetos realizem operaes neles prprios.

Alguns aspectos so fundamentais na definio de programao orientada a objetos, que sero devidamente investigados neste trabalho:

Abstrao de dados Objetos Mensagens



5

Classes Herana Polimorfismo

2. Conceitos bsicos e terminologia Para que se possa utilizar uma linguagem de programao orientada a objetos necessrio primeiramente conhecer os conceitos e a terminologia utilizada por este paradigma. 2.1. Abstrao de dados Um conceito que teve muita influncia na POO chama-se programao com tipos abstratos de dados. Tipos abstratos de dados possuem caractersticas como encapsulamento e modularidade.

A noo de tipos de dados ocorre na maioria das linguagens de programao tradicionais. Na declarao do tipo de uma varivel, delimita-se o conjunto de valores que ela pode assumir e as operaes que ela pode sofrer. A especificao de um tipo de dados deve definir os objetos constituintes do tipo e as operaes aplicveis a estes objetos. Alm disso, possvel estabelecer uma maneira de representao para os objetos.

Geralmente, uma linguagem de programao prov alguns tipos bsicos pr-definidos (tipos primitivos) e ainda oferece mecanismos para definio de novos tipos de dados renomeando tipos existentes ou agregando alguns tipos primitivos e/ou definidos pelo usurio (em Pascal, por exemplo, utiliza-se o comando type para criar novos tipos de dados). Existem linguagens que alm de proporcionarem tipos de dados primitivos e tipos de dados definidos pelo usurio, incorporam o conceito de tipos abstratos de dados. Tipos abstratos de dados envolvem a disponibilidade de dados e operaes (comportamento) sobre estes dados em uma nica unidade.

A abstrao de dados utilizada para introduzir um novo tipo de objeto, que considerado til no domnio do problema a ser resolvido. Os usurios do tipo abstrato de dados preocupam-se apenas com o comportamento dos objetos do tipo, demonstrado em termos de operaes significativas para tais objetos, no necessitando conhecer como estes objetos esto representados ou como as operaes so realizadas neles (ocultamento de informao). Portanto, uma abstrao de dados consiste de um conjunto de valores e de operaes que completamente caracterizam o comportamento dos objetos. Esta propriedade garantida fazendo-se com que as operaes sejam a nica maneira de criar e manipular os objetos. Como conseqncia, necessrio incluir operaes suficientes para proporcionar todas as possveis aes que os objetos possam sofrer.

Mais precisamente, um tipo abstrato de dados pode ser definido como um tipo de dados que satisfaz as seguintes condies:



6

A representao e definio do tipo e as operaes nos objetos do tipo so descritos em uma nica unidade sinttica (como em uma Unit, em Turbo Pascal)

A representao (implementao) dos objetos do tipo escondida das unidades de programa que utilizam o tipo; portanto, as nicas operaes possveis em tais objetos so aquelas que fazem parte da definio (interface) do tipo.

O estilo de programao com tipos abstratos de dados inclui o princpio de encapsulamento, que proporciona ocultamento e proteo de informao, viabilizando a manuteno e facilitando a evoluo de sistemas. Com o encapsulamento da estrutura de dados que representa os objetos e dos procedimentos que representam as possveis operaes sobre os objetos, tem-se que uma alterao na estrutura de dados provavelmente exigir modificaes nos procedimentos, porm o efeito dessas modificaes fica restrito s fronteiras da unidade sinttica que descreve o tipo (a Unit, no caso). Se a interface permanecer a mesma, as unidades de programa que utilizam o tipo no necessitam sofrer alteraes.

Uma outra vantagem que pode ser citada o considervel aumento de confiabilidade obtido atravs do princpio da proteo. Unidades de programa que utilizam um tipo no esto aptas a fazer modificaes diretamente. Elas somente podem chamar as operaes que esto disponveis na interface, aumentando a integridade dos objetos. 2.2. Objetos Na viso de uma linguagem imperativa tradicional (Pascal, C, COBOL, etc.), os objetos aparecem como uma nica entidade autnoma que combina a representao da informao (estruturas de dados) e sua manipulao (procedimentos), uma vez que possuem capacidade de processamento e armazenam um estado local. Pode-se dizer que um objeto composto de (Figura 2.1):

Propriedades: so as informaes, estruturas de dados que representam o estado interno do objeto. Em geral, no so acessveis aos demais objetos.

Comportamento: conjunto de operaes, chamados de mtodos, que agem sobre as propriedades. Os mtodos so ativados (disparados) quando o objeto recebe uma mensagem solicitando sua execuo. Embora no seja obrigatrio, em geral uma mensagem recebe o mesmo nome do mtodo que ela dispara. O conjunto de mensagens que um objeto est apto a receber est definido na sua interface.

Identidade: uma propriedade que diferencia um objeto de outro; ou seja, seu nome.



7

OPERAO 1

OPERAO 2

OPERAO 3

ESTADO INTERNO

IMPLEMENTAES DAS OPERAES 1, 2 E 3

{INTERFACE

Figura 2.1. Estrutura de um objeto

Enquanto que os conceitos de dados e procedimentos so freqentemente tratados separadamente nas linguagens de programao tradicionais, em POO eles so reunidos em uma nica entidade: o objeto. A figura 2.2 apresenta outra visualizao para um objeto.

MTODOS

ATRIBUTOS

Figura 2.2. Outra representao para um objeto

No mundo real no difcil a identificao de objetos (em termos de sistemas, objetos so todas as entidades que podem ser modeladas, no apenas os nossos conhecidos objetos inanimados). Como exemplo, em uma empresa pode-se identificar claramente objetos da classe (seo 2.4) empregado.

Um empregado possui uma identidade prpria, seu nome: Jos da Silva. Possui tambm propriedades como: endereo, idade, dependentes, salrio, cargo, entre outras. O comportamento pode ser determinado por operaes como: aumentar salrio, listar dependentes e alterar cargo. As propriedades somente podem ser manipuladas atravs das operaes definidas na interface do objeto, de modo que a forma de armazenamento das propriedades e a implementao das operaes so desconhecidas pelas outras entidades externas (encapsulamento de informaes).

AUMENTARSALRIO

LISTARDEPENDENTES

. . . . . .

NOME

CARGO

SALRIO

Figura 2.3. O objeto Empregado



8

Benefcios proporcionados pelos objetos:

Uma vez que objetos utilizam o princpio da abstrao de dados (seo 2.1), o encapsulamento de informao proporciona dois benefcios principais para o desenvolvimento de sistemas:

Modularidade: o cdigo fonte para um objeto pode ser escrito e mantido independentemente da cdigo fonte de outros objetos. Alm disso, um objeto pode ser facilmente migrado para outros sistemas.

Ocultamento de informao: um objeto tem uma interface pblica que os outros objetos podem utilizar para estabelecer comunicao com ele. Mas, o objeto mantm informaes e mtodos privados que podem ser alterados a qualquer hora sem afetar os outros objetos que dependem dele. Ou seja, no necessrio saber como o objeto implementado para poder utiliz-lo.

2.3. Mensagens Um objeto sozinho no muito til e geralmente ele aparece como um componente de um grande programa que contem muitos outros objetos. Atravs da interao destes objetos pode-se obter uma grande funcionalidade e comportamentos mais complexos.

Objetos de software interagem e comunicam-se com os outros atravs de mensagens. Quando o objeto A deseja que o objeto B execute um de seus mtodos, o objeto A envia uma mensagem ao objeto B (Figura 2.4). Algumas vezes o objeto receptor precisa de mais informao para que ele saiba exatamente o que deve fazer; esta informao transmitida juntamente com a mensagem atravs de parmetros.

MENSAGEM

OBJETO A

OBJETO B

Figura 2.4. O envio de mensagens entre objetos

Uma mensagem formada por trs componentes bsicos:

o objeto a quem a mensagem endereada (receptor) o nome do mtodo que se deseja executar os parmetros (se existirem) necessrios ao mtodo

Estes trs componentes so informao suficiente para o objeto receptor executar a mtodo desejado. Nada mais necessrio. Ento, objetos em processos



9

distintos ou ainda em mquinas distintas podem comunicar-se atravs do uso de mensagens.

Como exemplo, pode-se imaginar a realizao de uma operao aritmtica utilizando-se objetos, mtodos e mensagens. Uma adio realizada enviando-se uma mensagem a um objeto representando o nmero. A mensagem especifica que a operao desejada a adio e tambm o nmero que deve ser somado ao objeto receptor. Ento, a operao x+ y interpretada como a mensagem + sendo enviada ao objeto x com o parmetro y. Pode parecer estranho primeira vista, mas em SmallTalk operaes aritmticas so realmente tratadas dessa forma.

A ttulo de comparao com as linguagens convencionais, uma mensagem se comporta como uma chamada de subrotina (procedimento ou funo). A sintaxe em geral tambm muito parecida.

Benefcios proporcionados pelas mensagens:

Desde que tudo que um objeto pode fazer expressado pelos seus mtodos, a troca de mensagens suporta todos os tipos possveis de interao entre objetos

Para enviar e receber mensagens, objetos no precisam estar no mesmo processo ou mquina (ex: CORBA)

2.4. Mtodos Um mtodo implementa algum aspecto do comportamento do objeto. Comportamento a forma como um objeto age e reage, em termos das suas trocas de estado e troca de mensagens.

Um mtodo uma funo ou procedimento que definido na classe e tipicamente pode acessar o estado interno de um objeto da classe para realizar alguma operao. Pode ser pensado como sendo um procedimento cujo primeiro parmetro o objeto no qual deve trabalhar. Este objeto chamado receptor (seo 2.3). Abaixo apresentada uma notao possvel para o envio de uma mensagem (invocao do mtodo)

receptor.nome_da_mensagem(par1, par2, par3)

Muitas vezes quando se trabalha com objetos deseja-se realizar certas operaes no momento da criao e destruio de um objeto. Em algumas linguagens dado um tratamento de modo a ficar transparente ao programador a sua implementao. Em outras, necessrio utilizar mtodos especiais para este fim, chamados de construtores e destrutores.

Construtores so usados para criar e inicializar objetos novos. Tipicamente, a inicializao baseada em valores passados como parmetros para o construtor. Destrutores so usados para destruir objetos. Quando um destrutor invocado, as aes definidas pelo usurio so executadas, e ento a rea de memria alocada para o objeto liberada. Em algumas linguagens, como C++, o construtor chamado automaticamente quando um objeto declarado. Em outras, como Object Pascal, necessrio chamar explicitamente o construtor antes de poder utiliz-lo.



10

Um exemplo de utilizao de construtores e destrutores seria gerenciar a quantidade de objetos de uma determinada classe que j foram criados at o momento. No construtor pode-se colocar cdigo para incrementar uma varivel e no destrutor o cdigo para decrement-la. Na seo 4 so apresentados exemplos da utilizao de construtores e destrutores. 2.5. Classes Objetos de estrutura e comportamento idnticos so descritos como pertencendo a uma classe, de tal forma que a descrio de suas propriedades pode ser feita de uma s vez, de forma concisa, independente do nmero de objetos idnticos em termos de estrutura e comportamento que possam existir em uma aplicao. A noo de um objeto equivalente ao conceito de uma varivel em programao convencional, pois especifica uma rea de armazenamento, enquanto que a classe vista como um tipo abstrato de dados, uma vez que representa a definio de um tipo.

Cada objeto criado a partir de uma classe denominado de instncia dessa classe. Uma classe prov toda a informao necessria para construir e utilizar objetos de um tipo particular, ou seja, descreve a forma da memria privada e como se realizam as operaes das suas instncias. Os mtodos residem nas classes, uma vez que todas as instncias de uma classe possuem o mesmo conjunto de mtodos, ou seja, a mesma interface.

Cada instncia pertence a uma classe e uma classe pode possuir mltiplas instncias. Devido ao fato de todas as instncias de uma classe compartilharem as mesmas operaes, qualquer diferena de respostas a mensagens aceitas por elas, determinada pelos valores das variveis de instncia.

Em algumas linguagens, aparece tambm a definio de variveis de classe. Variveis de classe surgem quando se tem a viso de classes sendo manipuladas como objetos. Esta abordagem se torna til ao se tentar manter classes contendo informao. Como exemplo, uma classe poderia armazenar o nmero de objetos que tenham sido instanciados da classe at um certo momento. Cita-se, ainda, a importncia de se ter classes como objetos para modelar a entidade que recebe uma mensagem requisitando a criao de um novo objeto (como em Object Pascal).

A Figura 2.5 ilustra o relacionamento entre classes e objetos. Cada objeto instanciado a partir de uma classe possui as propriedades e comportamento definidos na classe, da mesma maneira que uma varivel incorpora as caractersticas do seu tipo. A existncia de classes proporciona um ganho em reusabilidade. pois o cdigo das operaes e a especificao da estrutura de um nmero potencialmente infinito de objetos esto definidos em um nico local, a classe. Cada vez que um novo objeto instanciado ou que uma mensagem enviada, a definio da classe reutilizada. Caso no existissem classes, para cada novo objeto criado, seria preciso uma definio completa do objeto.



11

CLASSE 1 CLASSE 2 CLASSE 3

OBJETOS DA CLASSE 1

OBJETOS DA CLASSE 2

OBJETOS DA CLASSE 3

Figura 2.5. Relacionamento entre classes e objetos

No exemplo de uma empresa seria possvel criar classes para vrias entidades a ser modeladas, como: empregados, departamentos, filiais, produtos, documentos fiscais, etc. Na definio da classe empregado, so especificados as suas propriedades e comportamento e escrito o cdigo fonte da sua implementao. Quando um novo empregado admitido na empresa, ele criado como uma instncia da classe empregado, e automaticamente possui todas as caractersticas da classe.

Metaclasses

Uma metaclasse uma classe de classes. Pode-se julgar conveniente que, em uma linguagem ou ambiente, classes tambm possam ser manipuladas como objetos. Por exemplo, uma classe pode conter variveis contendo informaes teis, como:

o nmero de objetos que tenham sido instanciados da classe at certo instante;

um valor mdio de determinada propriedade, calculado sobre os valores especficos desta propriedade nas instncias (por exemplo, mdia de idade de empregados).

Essas variveis no devem ser criadas para cada objeto (instncia), mas para cada classe deve existir apenas uma cpia de cada. Para implementar isto conveniente considerar uma classe como sendo tambm um objeto. Neste caso, a classe precisar ser instncia de outra classe. Esta classe de classes chama de metaclasse.

Benefcios proporcionados pelas classes:

O maior benefcio proporcionado pela utilizao das classes a reusabilidade de cdigo, uma vez que todos os objetos instanciados a partir dela incorporam as suas propriedades e seu comportamento. 2.6. Herana O mecanismo de herana permite a reutilizao das propriedades de uma classe na definio de outra. A classe mais generalizada chamada superclasse e a



12

mais especializada, subclasse. No desenvolvimento de software, herana surge como a maneira para garantir que caixas pretas construdas no se tornem caixas isoladas. Atravs da herana, novas caixas pretas so obtidas aproveitando-se operaes j implementadas, proporcionando a reusabilidade de cdigo existente. Assim como no mundo dos seres humanos, o objeto descendente no tem nenhum trabalho para receber a herana. Ele a recebe simplesmente porque um objeto descendente.

Herana a contribuio original do paradigma de objetos, que o diferencia da programao com tipos abstratos de dados. Ela viabiliza a construo de sistemas a partir de componentes reusveis. A herana no s suporta a reutilizao entre sistemas, mas facilita diretamente a extensabilidade em um mesmo sistema. Diminui a quantidade de cdigo para adicionar caractersticas a sistemas j existentes e tambm facilita a manuteno de sistemas, tanto provendo maior legibilidade do cdigo existente, quanto diminuindo a quantidade de cdigo a ser acrescentada.

A herana no limitada a apenas um nvel; a rvore de herana, ou hierarquia de classes pode ser to profunda quanto for necessrio. Mtodos e variveis internas so herdados por todos os objetos dos nveis para baixo. Quanto mais para baixo na hierarquia uma classe estiver, mais especializado o seu comportamento. Vrias subclasses descendentes podem herdar as caractersticas de uma superclasse ancestral, assim como vrios seres humanos herdam as caractersticas genticas de um antepassado.

EMPREGADO

GERENTE EXECUTIVO COLABORADOR

GERENTE DEPARTAMENTO

PRESIDENTE DIRETOR GERENTE DIVISO

Figura 2.6. Herana na classe Empregado

Na figura 2.6 pode-se ver a hierarquia de classes para a classe Empregado. As classes Executivo, Gerente e Colaborador herdam todos os mtodos e variveis da classe Empregado; alm disso, podem redefini-los e criar novas caractersticas. A classe Presidente, tambm herda todas as caractersticas da classe Executivo, que por sua vez j herdou da classe Empregado.

A herana interpretada da seguinte maneira: se B subclasse de A (conseqentemente, A superclasse de B), ento:

os objetos da classe B suportam todas as operaes suportadas pelos objetos da classe A, exceto aquelas redefinidas

as variveis de instncia de B incluem todas as variveis de instncia de A.

Analisando os itens acima, tem-se que uma subclasse compartilha o comportamento e o estado de sua superclasse, podendo redefini-lo para seu prprio



13

uso. Alm disso, possvel acrescentar novas caractersticas que identificam um comportamento prprio. A maior parte das linguagens orientadas a objetos utiliza herana como uma tcnica para prover suporte especializao, e no permitem que uma classe exclua uma operao herdada.

A utilizao de herana em linguagens orientadas a objetos pode afetar o encapsulamento de informao. Alm dos clientes da classe que simplesmente requisitam operaes sobre instncias da classe, surge uma nova categoria de clientes que so as classes definidas atravs da herana, ou seja, as subclasses. Geralmente, s subclasses permitido o total acesso representao das variveis de instncias definidas na sua superclasse. Desta forma, compromete-se o princpio de encapsulamento, uma vez que as variveis de instncia de uma classe sero parte implcita da interface que ela proporciona para as suas possveis subclasses. Mudanas na implementao de uma classe, como por exemplo a remoo de uma varivel de instncia, poder comprometer a implementao de suas subclasses. Assim, no existe mais a liberdade para modificar a representao de uma classe em provocar efeitos nos seus clientes.

Herana no necessariamente est limitada a uma nica superclasse. Uma subclasse pode herdar caractersticas de diversas superclasses, introduzindo o conceito de herana mltipla. Indiscutivelmente, obtido um maior potencial para o compartilhamento de cdigo, porm a possibilidade de conflitos, como o confronto de nomes entre as operaes herdadas, entre mltiplas superclasses aumenta a complexidade dos sistemas.

Benefcios proporcionados pela herana:

Subclasses provem comportamentos especializados tomando-se como base os elementos comuns definidos pela superclasse. Atravs do uso da herana, pode-se reutilizar o cdigo da superclasse vrias vezes.

Pode-se implementar classes que definem comportamentos genricos (chamadas de classes abstratas). A essncia da superclasse definida e pode ser parcialmente implementada, mas a maior parte da classe deixada indefinida e no implementada. Os detalhes so definidos em subclasses especializadas, que podem ser implementadas inclusive por outros programadores de acordo com sua necessidade.

2.6. Polimorfismo Polimorfismo refere-se capacidade de dois ou mais objetos responderem mesma mensagem, cada um a seu prprio modo. A utilizao da herana torna-se fcil com o polimorfismo. Desde que no necessrio escrever um mtodo com nome diferente para responder a cada mensagem, o cdigo mais fcil de entender. Por exemplo, sem polimorfismo, para inserir um novo empregado, seria necessrio o seguinte cdigo:

Colaborador1.InsereColaborador Gerente1.InsereGerente Presidente1.InserePresidente



14

Neste caso, Colaborador1, Gerente1 e Presidente1 so objetos das respectivamente das classes Colaborador, Gerente e Presidente. Com o polimorfismo, no necessrio ter um mtodo diferente para cada tipo de objeto. Pode-se simplesmente escrever o seguinte:

Colaborador.Insere Gerente.Insere Presidente.Insere

Neste exemplo, os trs diferente empregados tm trs diferentes mtodos para ser inseridos, embora o tenha sido utilizado o mtodo com o mesmo nome. No cdigo para esses empregados, seria necessrio escrever trs mtodos diferentes: um para cada tipo de empregado. O mais importante a ser observado que as trs rotinas compartilham o mesmo nome.

O polimorfismo obviamente no nos auxilia a reutilizar o cdigo. Em vez disso, ele til na compreenso de programas. Desde que uma grande quantidade de objetos compartilham o mesmo comportamento com implementaes ligeiramente diferentes, encontrar uma maneira de diminuir o nmero de linhas de cdigo para invocar estes comportamentos auxilia imensamente. Os programadores que so usurios da classe Empregado no precisam saber que a maneira de inserir um empregado diferente; quando eles querem inserir, somente utilizam o mtodo Insere.

Se considerarmos que o mtodo Insere est sendo utilizado dentro de uma estrutura de repetio, fica bastante aparente o ganho obtido em legibilidade e tamanho do cdigo. Sem a utilizao de polimorfismo esta estrutura seria:

Para todos os Empregados Faa Se Empregado Presidente Ento

Empregado[i].InserePresidente Se Empregado Gerente Ento

Empregado[i].InsereGerente Se Empregado Colaborador Ento

Empregado[i].InsereColaborador Fim Se

Fim Para

Com a utilizao do polimorfismo seria possvel utilizar o seguinte cdigo:

Para todos os Empregados Faa Empregado[i].Insere

Fim Para

O polimorfismo visto nos exemplos acima implica na existncia de mtodos com implementao diferente com o mesmo nome em classes distintas. Outra forma simples de polimorfismo permite a existncia de vrios mtodos com o mesmo nome, definidos na mesma classe, que se diferenciam pelo tipo ou nmero de parmetros suportados. Isto conhecido como polimorfismo paramtrico, ou sobrecarga de operadores (overloading). Neste caso, uma mensagem poderia ser enviada a um objeto com parmetros de tipos diferentes (uma vez inteiro, outra real, por exemplo), ou com nmero varivel de parmetros. O nome da mensagem seria o mesmo, porm o mtodo invocado seria escolhido de acordo com os parmetros enviados.



15

Dependendo das caractersticas da linguagem e do tipo de polimorfismo suportado por ela, a implementao do polimorfismo pode exigir facilidades proporcionadas pela ligao dinmica. De um modo geral, uma ligao (binding) uma associao, possivelmente entre um atributo e uma entidade ou entre uma operao e um smbolo. Uma ligao dita esttica se ocorre em tempo de compilao ou de interligao (linking) e no mais modificada durante toda a execuo do programa. A ligao dinmica feita em tempo de execuo ou pode ser alterada no decorrer da execuo do programa.

Com a ligao dinmica, a ligao do operador a uma particular operao pode ser feita em tempo de execuo, isto , o cdigo compilado para um tipo abstrato de dados pode ser usado para diferentes tipos de dados, aumentando consideravelmente sua reusabilidade. Entretanto, o uso de ligao dinmica compromete a eficincia de implementao.

Benefcios proporcionados pelo polimorfismo

Legibilidade do cdigo: a utilizao do mesmo nome de mtodo para vrios objetos torna o cdigo de mais fcil leitura e assimilao, facilitando muito a expanso e manuteno dos sistemas.

Cdigo de menor tamanho: o cdigo mais claro torna-se tambm mais enxuto e elegante. Pode-se resolver os mesmos problemas da programao convencional com um cdigo de tamanho reduzido.

2.7. Relaes entre Objeto, Classe e Herana

Objetos, classes e o mecanismo de herana permitem a definio de hierarquias de abstraes, que facilitam o entendimento e o gerenciamento da complexidade dos sistemas estudados. Isto porque classes agrupam objetos com caractersticas iguais, enquanto herana estrutura classes semelhantes.

A capacidade em classificar objetos e classes concede grande poder de modelagem conceitual e classificao, podendo expressar relaes entre comportamentos, tais como classificao/instanciao, generalizao/especializao e agregao/composio. Facilita a compreenso humana do domnio estudado e tambm o desenvolvimento de programas que o satisfaa. Pode-se dizer que a grande vantagem do paradigma de objetos a possibilidade de expressar diretamente este poder de modelagem conceitual numa linguagem de programao orientada a objetos. Assim, o modelo conceitual proposto durante a etapa de anlise no se perde nas etapas de projeto e implementao. O que em geral ocorre a sua extenso. 2.7.1. Classificao/Instanciao A capacidade de classificar objetos (em classes) permite expressar relaes do tipo classificao/instanciao. O relacionamento feito a partir da observao de diversos fenmenos para categorizao dos mesmos em grupos (classes), com base no conjunto de propriedades comuns a todos. Por exemplo, dois computadores, IBM PC e Machintosh, podem ser classificados como instncias (objetos, modelos, ou espcimes) da classe (categoria) Microcomputador (Figura 2.7). A relao inversa



16

a de instanciao de uma publicao (IBM PC, por exemplo) a partir da classe Microcomputador.

MICROCOMPUTADOR

IBM PC MACHINTOSH

INSTANCIAO

CLASSIFICAO

Figura 2.7. Relao de classificao/instanciao 2.7.2. Generalizao/Especializao Este tipo de relao ocorre quando, a partir a observao de duas classes, abstramos delas uma classe mais genrica. Por exemplo, as classes Microcomputador e Mainframe podem ser considerados casos especiais da classe Computador. Esta classe considerada uma generalizao das duas primeiras, que so chamadas de especializaes da classe Computador (Figura 2.8). A idia da generalizao/especializao a base para a classificao das espcies nas cincias naturais. Do ponto de vista de propriedades, o pressuposto que as subclasses tenham todas as propriedades das classes de quem elas so especializaes. Deve haver pelo menos uma propriedade que diferencie duas classes especializadas (subclasses) a partir da mesma classe genrica (superclasse). Este o tipo de relao utilizado com o mecanismo de herana.

ESPECIALIZAO

GENERALIZAO MAINFRAMEMICROCOMPUTADOR

COMPUTADOR

Figura 2.8. Relao de generalizao/especializao 2.7.3. Composio/Decomposio A relao de composio (ou agregao)/decomposio permite que objetos sejam compostos pela agregao de outros objetos ou componentes. Neste relacionamento, so determinados que instncias (objetos) de uma classe so compostas por instncias de outras classes. Essa operao denominada decomposio e a relao inversa, a formao de uma nova classe como um agregado de classes preexistentes, denominada composio. Por exemplo, instncias da



17

classe Microcomputador so compostas por, entre outras, instncias das classes Teclado e Vdeo (Figura 2.9).

DECOMPOSIO

COMPOSIOVDEOTECLADO

MICROCOMPUTADOR

Figura 2.9. Relao de composio/decomposio

3. Avaliao da POO O paradigma de objetos no apenas um nome pomposo. Seu objetivo claro melhorar a produtividade dos programadores no desenvolvimento a sistemas. A POO realmente torna mais rpidas as atividades de programao e manuteno de sistemas de informao. Assim como a programao estrutura melhorou a qualidade dos sistemas em relao aos mtodos praticados anteriormente (programas estilo spagueti recheados de comandos goto), a POO surge como um modelo promissor para solucionar as necessidades crescentes da nossa sociedade por sistemas informatizados.

A grande vantagem do paradigma de objetos o seu carter unificador: trata todas as etapas do desenvolvimento de sistemas e ambientes sob uma nica abordagem. Nesse sentido, podemos ter anlise, projeto, programao, banco de dados e ambientes orientados a objetos, eliminando as diferenas de impedncia entre eles. 3.1. Vantagens da POO A POO tem alcanado tanta popularidade devido s vantagens que ela traz. Entre elas podemos citar:

Reusabilidade de cdigo Escalabilidade de aplicaes Mantenabilidade Apropriao

A reusabilidade de cdigo , sem dvida, reconhecida como a maior vantagem da utilizao de POO, pois permite que programas sejam escritos mais rapidamente. Todas as empresas sofrem de deficincia em seus sistemas informatizados para obter maior agilidade e prestar melhores servios a seus clientes. Um levantamento feito na AT&T, a gigante das telecomunicaes nos EUA, identificou uma deficincia da ordem de bilhes de linhas de cdigo. Uma vez que a demanda est sempre



18

aumentando, procura-se maneiras de desenvolver sistemas mais rapidamente, o que est gerando uma srie de novas metodologias e tcnicas de construo de sistemas (por exemplo, ferramentas CASE). A POO, atravs da reusabilidade de cdigo, traz uma contribuio imensa nesta rea, possibilitando o desenvolvimento de novos sistemas utilizando-se muito cdigo j existente. A maior contribuio para reusabilidade de cdigo apresentada pela herana.

Escalabilidade pode ser vista como a capacidade de uma aplicao crescer facilmente sem aumentar demasiadamente a sua complexidade ou comprometer o seu desempenho. A POO adequada ao desenvolvimento de grandes sistemas uma vez que pode-se construir e ampliar um sistema agrupando objetos e fazendo-os trocar mensagens entre si. Esta viso de sistema uniforme, seja para pequenos ou grandes sistemas (logicamente, deve-se guardar as devidas propores).

O encapsulamento proporciona ocultamento e proteo da informao. Acessos a objetos somente podem ser realizados atravs das mensagens que ele est habilitado a receber. Nenhum objeto pode manipular diretamente o estado interno de outro objeto. De modo que, se houver necessidade de alterar as propriedades de um objeto ou a implementao de algum mtodo, os outros objetos no sofrero nenhum impacto, desde que a interface permanea idntica. Isto diminui em grande parte os esforos despendidos em manuteno. Alm disso, para utilizar um objeto, o programador no necessita conhecer a fundo a sua implementao.

O polimorfismo torna o programa mais enxuto, claro e fcil de compreender. Sem polimorfismo, seriam necessrias listas enormes de mtodos com nomes diferentes mas comportamento similar. Na programao, a escolha de um entre os vrios mtodos seria realizada por estruturas de mltipla escolha (case) muito grandes. Em termos de manuteno, isto significa que o programa ser mais facilmente entendido e alterado.

A herana tambm torna a manuteno mais fcil. Se uma aplicao precisa de alguma funcionalidade adicional, no necessrio alterar o cdigo atual. Simplesmente cria-se uma nova gerao de uma classe, herdando o comportamento antigo e adiciona-se novo comportamento ou redefine-se o comportamento antigo.

Outra vantagem da POO tambm uma desvantagem: apropriao. Problemas do mundo real so freqentemente solucionados facilmente utilizando as tcnicas de orientao a objetos. As nossas mentes so classificadores naturais de coisas. Tipicamente ns classificamos coisas em hierarquias de classes. A POO leva vantagem desse fato e nos fornece uma estrutura que funciona como a nossa mente. Apropriao significa agrupar os objetos de comportamento similar em classes e essas classes em hierarquias de herana. 3.2. Desvantagens da POO Apesar de das inmeras vantagens, a POO tem tambm algumas desvantagens, que incluem:

Apropriao Fragilidade Linearidade de desenvolvimento



19

A apropriao apresentada tanto como uma vantagem como uma desvantagem, porque a POO nem sempre soluciona os problemas elegantemente. Enquanto que a mente humana parece classificar objetos em categorias (classes) e agrupar essas classes em relacionamentos de herana, o que ela realmente faz no to simples. Em vez disso, objetos com caractersticas mais ou menos similares, e no precisamente definidas, so reunidos em uma classificao. A POO requer definies precisas de classes; definies flexveis e imprecisas no so suportadas. Na mente humana, essas classificaes podem mudar com o tempo. Os critrios para classificar objetos podem mudar significativamente. A apropriao utilizada na POO torna-a muito rgida para trabalhar com situaes dinmicas e imprecisas.

Alm disso, algumas vezes no possvel decompor problemas do mundo real em uma hierarquia de classes. Negcios e pessoas tm freqentemente regras de operaes sobre objetos que desafiam uma hierarquia limpa e uma decomposio orientada a objetos. O paradigma de objetos no trata bem de problemas que requerem limites nebulosos e regras dinmicas para a classificao de objetos.

Isto leva ao prximo problema com POO: fragilidade. Desde que uma hierarquia orientada a objetos requer definies precisas, se os relacionamentos fundamentais entre as classes chave mudam, o projeto original orientada a objetos perdido. Torna-se necessrio reanalisar os relacionamentos entre os objetos principais e reprojetar uma nove hierarquia de classes. Se existir uma falha fundamental na hierarquia de classes, o problema no facilmente consertado. A mente humana adapta-se continuamente, e geralmente adequadamente, a situaes novas. Ela encontra maneiras de classificar objetos no ambiente automaticamente. Enquanto a nossa mente tem essa capacidade, os ambientes POO no so to bem equipados.

Em virtude dessa fragilidade, a POO requer anlise e projeto frontal para assegurar que a soluo adequada. Com isto existe uma tendncia em criar uma abordagem linear de desenvolvimento, em vez de cclica. Infelizmente, alguns problemas so perversos, o que significa que no se sabe como resolver um problema at efetivamente resolv-lo. Tais problemas desafiam at mesmo os melhores projetistas e analistas de sistemas. Utilizar a abordagem de Desenvolvimento Rpido de Aplicaes (RAD - Rapid Application Development, utilizada pelo Delphi, SQL-Windows e outros ambientes de desenvolvimento para Windows adequados prototipagem) com ciclos entre o projeto do prottipo, construo e realimentao do usurio algumas vezes uma boa maneira de resolver problemas perversos. Entretanto, a POO necessita de um projeto cuidadoso da hierarquia de classes, o que pode elevar os custos da sua utilizao em um ambiente RAD. 3.3. O estilo de programao com POO O estilo de programao induzido pelo paradigma de objetos tem caractersticas muito precisas:

Modularidade: o estilo impe alta modularidade na tarefa de projeto e programao. O conceito de objetos e sua descrio em classes incorporando dados e operaes constituem um critrio de modularizao altamente efetivo e propiciam uma boa traduo prtica de encapsulamento de informaes.



20

Suporte a generalizao/especializao: o estilo suporta diretamente a estruturao de conceitos em hierarquias de generalizao/especializao que representa a deficincia fundamental de abordagens de programao limitadas a tipos abstratos de dados (TADs).

Viso balanceada entre dados e processos: o estilo tenta induzir, ao contrrio de outros mtodos, uma viso integrada de dados e processos na modelagem conceitual de aplicaes.

Composio botton-up de aplicao: o estilo privilegia a composio de uma nova aplicao a partir de composio de classes de aplicaes preexistentes. Nesse sentido, a composio da aplicao bottom-up (de baixo para cima, ao contrrio de top-down).

A atividade incremental e evolutiva: o estilo favorece uma abordagem incremental de programao, onde pequenas modificaes podem ser rapidamente efetuadas e testadas, quer a partir da criao de novas classes, quer a partir da rpida especializao de um classe preexistente.

Reusabilidade de cdigo: o estilo favorece a reutilizao de cdigo j existente, na forma de bibliotecas de classes que sero diretamente instanciadas ou modificadas pelo usurio.

Robustez: o estilo favorece a criao de aplicaes robustas, ou seja, muito estveis em situaes sujeitas a falhas. A maioria das linguagens orientadas a objetos possui mecanismos de tratar adequadamente erros vindos do usurio e tambm excees do sistema.

Programao em grande escala: o estilo adequado ao desenvolvimento de sistemas grandes e complexos com equipes formadas por vrios programadores. Algumas caractersticas apresentadas acima contribuem substancialmente para este item, como a modularidade e a reusabilidade.

3.4. Programao Dirigida por Eventos Existe uma confuso muito comum atualmente com relao POO e Programao Dirigida por Eventos (PDE). Os dois conceitos costumam ser usados indisciplinadamente e tambm misturados. Um erro comum pensar que todas as linguagem de programao para Windows (que implementa a PDE) so tambm orientadas a objetos.

A linguagem SmallTalk, que a linguagem orientada a objetos mais pura nasceu em conjunto com um ambiente grfico de desenvolvimento. A seguir alguns sistemas copiaram a idia das interfaces grficas de usurio(GUI), alguns implementando POO, outros no. Na realidade as tcnicas de orientao a objetos trazem muitos benefcios s interfaces de usurio, como ser visto na seo 5.

Os conceitos de POO foram apresentados nas sees 2 e 3 e dizem respeito objetos, classes, herana, polimorfismo, etc. A PDE diz respeito maneira como a execuo dos programas tratada nos ambientes de desenvolvimento e contrasta diretamente com a programao seqencial. POO e PDE representam aspectos



21

distintos porm complementares, que utilizados em conjunto obtm alto grau de sinergia nos resultados apresentados.

Um determinado ambiente de desenvolvimento, como pode ser visto na Tabela 3.1, pode ter caractersticas de POO e PDE, de apenas uma delas, ou de nenhuma.

Ambiente POO PDE COBOL tradicional NO NO Visual Basic NO SIM Turbo C++ SIM NO Delphi SIM SIM

Tabela 3.1. Ambientes POO e PDE

A seguir ser dada uma pequena viso comparativa entre programao seqencial e programao dirigida por eventos.

Programao Seqencial

Programao Seqencial o que se imagina quando se pensa em programao. o modelo bsico para os programadores desde que a programao comeou, e fcil de conceituar. Em programao seqencial, h um incio, meio e fim. Ela unidirecional. Tipicamente um programa seqencial possui os seguintes passos:

1. Inicializar todas as variveis 2. Ler os dados 3. Aplicar um algoritmo sobre os dados 4. Escrever os resultados

Onde o algoritmo poderia ser qualquer coisa, desde ordenar dados alfabeticamente at calcular horscopo.

Em um nvel fundamental, exatamente isso o que ocorre dentro do computador. Pode-se ver um computador realizando muitas atividades ao mesmo tempo, mas uma CPU pode somente realizar efetivamente uma por vez. Parece que elas so executadas ao mesmo tempo porque o computador (o sistema operacional, na realidade) troca rapidamente de uma tarefa para outra

O modelo Seqencial continua ainda sendo verdadeiro, mas algumas vezes til olhar de um ponto de vista diferente, ou de um nvel de abstrao diferente.

Programao Dirigida por Eventos

Programao Dirigida por Eventos o modelo que tipicamente utilizado pelos sistemas operacionais e programas aplicativos atuais. Na Programa Dirigida por Eventos, no existe um foco de processamento linear que o programa segue. Um programa configurado como uma coleo de tratadores (handlers) que so utilizados quando os vrios eventos ocorrem. Um tratador de eventos constitui-se basicamente em subrotina em um programa (um procedimento ou uma funo). Um programa dirigido por eventos pode ser imaginado como tendo os seguintes passos:

1. Inicializar 2. Configurar a interface



22

3. Esperar por um evento 4. Quando um evento ocorrer, deve-se trat-lo 5. Ir para o passo 3 (o estado de espera)

Por exemplo, um evento pode ser: o usurio clica em um cone, o usurio escolhe Novo em um menu, ou o usurio pressiona a tecla c.

A principal diferena entre esses dois paradigmas que em Programao Dirigida por Eventos, qualquer coisa pode acontecer. Um usurio (ou um programa, ou um computador atravs de um rede, etc.) pode causar um determinado evento dentre um vasto repertrio de possibilidades. Os eventos disponveis (que so tratados) so aqueles geralmente que o programador achar necessrios.

Pode-se notar que a Programao Dirigida por Eventos constitui-se apenas em uma camada no topo da Programao Seqencial. Um programa constitudo de muitos tratadores de eventos, que so programas seqenciais, em vez de um nico grande programa seqencial. A Programao Dirigida por Eventos ento justamente um nvel de abstrao em cima do nosso modelo seqencial bsico, que torna mais fcil a tarefa de projetar e escrever programas. A linguagem de programao utilizada para implementar os tratadores de eventos pode seguir o paradigma procedimental tradicional (linguagens como Pascal, C, Cobol, Fortran, etc.), orientado a objetos alm de outros possveis.

4. Linguagens Tpicas Com relao ao suporte a objetos, pode-se classificar as linguagens de programao em: no baseadas em objetos, baseadas em objetos, baseadas em classes e orientadas a objetos.

Uma linguagem que no suporte objetos como uma construo primitiva , obviamente, no baseada em objetos. Exemplos de linguagens no baseadas em objetos so Pascal, C, FORTRAN e COBOL.

Caso uma linguagem suporte objetos, ento ela denominada como sendo baseada em objetos. As linguagens baseadas em objetos incluem Modula-2, ADA, CLU, Simula, SmallTalk, C++ e Object Pascal.

Para ser considerada uma linguagem baseada em classes necessrio que todo objeto pertena a alguma classe. CLU, Simula, SmallTalk, C++ e Object Pascal so tambm linguagens baseadas em classes, mas no o so o ADA e Modula-2. Uma linguagem orientada a objetos baseada em classes dispostas em hierarquias. SmallTalk, C++ e Object Pascal so orientadas a objetos, uma vez que suas classes suportam o mecanismo de herana. CLU baseada em classes, mas no orientada a objetos, uma vez que suas classes no suportam herana.

Linguagens baseadas em classes so um subconjunto prprio das linguagens baseadas em objetos, enquanto linguagens orientadas a objetos so um subconjunto prprio das linguagens baseadas em classes. A Figura 4.1 mostra o relacionamento entre as classes de linguagens de programao baseadas a objetos.



23

BASEADAS EMOBJETOS

BASEADAS EMCLASSES

ORIENTADAS AOBJETOS

ADA

CLU

SMALLTALK C++

+ CLASSES

+ HERANA

Figura 4.1. Relacionamento entre classes de linguagens baseadas em objetos

Estas classes de linguagens so teis para distinguir as diferentes linguagens baseadas em objetos existentes, como base em suas caractersticas, relacionamento estas distines com a capacidade da linguagem em suportar determinada metodologia. Por isso, deve-se considerar o efeito de objetos, classes e herana na metodologia de programao. 4.1. A linguagem de programao SmallTalk A linguagem de programao Smalltalk inteiramente implementada com base no modelo de objetos comunicando-se seqencialmente atravs de mensagens. A idia fundamental caracterizando a linguagem a uniformidade. Um objeto representa um componente do sistema, isto , representa nmeros, filas, diretrios de discos, compiladores, etc.

Em SmallTalk o paradigma de objetos levado s ltimas conseqncias. Todas as entidades manipuladas por um programa so objetos ou referncias a objetos. A construo 5 + 2, por exemplo, que em outras linguagens geralmente considerada uma expresso aritmtica, interpretada em SmallTalk como um objeto representando o inteiro 5 ao qual enviada a mensagem + cujo argumento outro objeto representando o valor inteiro 2. Nesse caso, o objeto que representa o valor 5 efetua a operao de soma e retorna como resposta um objeto representando o valor inteiro 7.

As entidades bsicas manipuladas em Smalltalk refletem os conceitos j apresentados. Um objeto consiste de uma rea de memria (variveis de instncia) e de operaes (mtodos). Uma mensagem vista como uma requisio para um objeto realizar uma de suas operaes. A definio da interface de um objeto feita atravs das mensagens que o objeto pode responder. Esta interface restringe a manipulao da rea privada de um objeto s operaes associadas s mensagens. O envio de uma mensagem a um objeto acarreta a procura de um mtodo cujo seletor seja adequado mensagem. Se o mtodo no for encontrado na interface da classe deste objeto a procura passa a ser feita na interface da sua superclasse, e assim sucessivamente.



24

Desta forma, a ligao (binding) da mensagem com um mtodo a ser executado feita em tempo de execuo. Outra caracterstica da linguagem que no se trabalha com a verificao de tipos, j que no existe a associao de uma varivel a um tipo.

As classes descrevem a implementao de objetos que representam componentes do sistema possuindo comportamentos idnticos. Como todas as entidades do sistema Smalltalk so vistas como objetos e todos os objetos so instncias de uma classe, as prprias classes devem ser representadas por instncias de uma classe, surgindo o conceito de metaclasses. Em verses preliminares da linguagem existia apenas uma nica metaclasse, chamada Class. Com esta abordagem, o protocolo de todas as classes estava limitado a ser o mesmo. Assim, mltiplas metaclasses so necessrias porque mensagens para iniciao de novas instncias so diferentes para diversas classes. Portanto, uma classe uma instncia nica de uma metaclasse, que possui o objetivo de definir o protocolo de utilizao da classe.

Todas as metaclasses so instncias de uma classe chamada Metaclass e possuem uma superclasse abstrata (Class) que descreve a natureza geral das metaclasses. Cada metaclasse pode adicionar novas mensagens de criao de instncias ou redefinir as mensagens fundamentais, isto , cada metaclasse adiciona o comportamento especfico sua nica instncia atravs dos mtodos da classe apresentados como parte da descrio da classe. O uso de mensagens de classe tambm importante para a iniciao de variveis de classe.

Um objeto alocado explicitamente por intermdio da mensagem new. No entanto, no existem mecanismos para especificao de destruio de um objeto. Faz-se a utilizao de uma tcnica de recuperao automtica de memria garbage collection, tornando o processo de destruio de objetos transparente ao usurio.

O mecanismo de herana simples, uma vez que uma subclasse derivada de apenas uma superclasse direta e muitas classes podem compartilhar a mesma superclasse, resultando em uma hierarquia em forma de rvore. O ambiente Smalltalk possui uma biblioteca de classes contendo uma hierarquia concebida na definio do sistema. A esta biblioteca novas classes podem ser adicionadas pelos usurios. Desta maneira, o programador Smalltalk sempre cria uma nova classe como sendo uma subclasse de uma classe j existente. Uma classe do sistema, chamada Object e que a nica no sistema a no possuir superclasse, descreve as similaridades de todos os objetos do sistema. Portanto, toda classe dever pelo menos ser subclasse de Object.

Um programa em SmallTalk uma expresso ou uma seqncia de expresses separadas pelo smbolo . (ponto). Expresses podem ser:

1. um literal (objeto constante como nmeros, caracteres, cadeias e vetores compostos por literais);

2. uma varivel (referncia a um objeto);

3. um envio de mensagem;

4. um bloco (uma seqncia, delimitada por colchetes, de expresses separadas por ., cuja ao postergada).



25

Na Figura 4.2. pode-se ver um trecho de programa em SmallTalk onde so definidas as classes Empregado e Gerente.

class name

Empregado superclass

Object Instance variable names

nome salario

class variable names

NumeroDeEmpregados class methods

initialize NumeroDeEmpregados := 0

new

| newEmp | newEmp := super new. NumeroDeEmpregados := NumeroDeEmpregados + 1. ^newEmp

instance methods

atualizaNome: umNome nome := umNome

nome

^nome atualizaSalario: umSalario

salario := umSalario salario

^salario

class name

Gerente superclass

Empregado Instance variable names

comissao



26

instance methods

atualizaComissao: umaComissao

comissao := umaComissao salario

^(salario + comissao)

Figura 4.2. Definio de classes em SmallTalk Na Figura 4.3 est listado um trecho de programa que retorna a quantidade de nmeros mpar em um vetor.

| v nOdd |

v := #(1 5 2 3 6). nOdd := 0. v do: [:elem | elem odd ifTrue: [nOdd := nOdd + 1 ]]. v at: 1 put: nOdd. ^nOdd

Figura 4.3. Programa exemplo em SmallTalk 4.2. A linguagem de programao C++ A linguagem de programao C++ foi desenvolvida a partir da linguagem procedimental C, acrescentando a idia de tipos abstratos de dados e fornecendo o mecanismo de herana para proporcionar o suporte programao orientada a objetos. As preocupaes da linguagem C com as questes de eficincia do cdigo gerado, flexibilidade e portabilidade permaneceram presentes em C++. Existe tambm o compromisso de compatibilidade com a linguagem C. Portanto, as construes usuais em C devero ser tratadas pelo compilador C++.

O conceito de tipos abstratos de dados implementado atravs da construo de classes. As classes especificam um conjunto de objetos (instncias da classe) que possuem caractersticas comuns (variveis de instncia e operaes). Em C++ a declarao de uma classe pode ser dividida em trs sees com o objetivo de controlar a visibilidade dos elementos da classe:

Privada (private), que limita a manipulao das variveis de instncia e operaes apenas s rotinas da prpria classe, ou seja, aquelas rotinas definidas na declarao da classe, exceto o caso das funes amigas, descrito mais adiante;

Protegida (protected), que estende o acesso aos elementos da classe a todas as suas subclasses;

Pblica (public), que define a interface das instncias da classe. Todos os elementos declarados nesta seo esto disponveis aos clientes da classe.



27

Vale salientar que, se variveis de instncia so declaradas como pblicas, torna-se possvel trat-las diretamente, ou seja, no necessria a invocao de operaes para fazer acessos. Desta forma, uma varivel de instncia pode ser vista como uma componente de uma estrutura (struct) em C.

As variveis de instncia declaradas em uma classe possuem um tipo associado, uma vez que a declarao feita da mesma forma como em C. O conceito de varivel de classe existente na linguagem Smalltalk implementado atravs da clusula static, isto , uma varivel declarada como static torna-se disponvel a todas as instncias de uma classe, havendo um compartilhamento do mesmo dado. As operaes, mtodos do Smalltalk, so implementadas como funes em C, sendo permitida a sobrecarga de identificadores, isto , pode existir a definio de duas ou mais funes com o mesmo nome, sendo a distino feita atravs do tipo e/ou do nmero de argumentos. O acesso a objetos de uma classe pode ser restrito s funes que so declaradas como parte da classe do objeto. Tais funes so chamadas de funes membros. Alm de funes membros, funes declaradas como amigas da classe esto autorizadas a manipular elementos privados e protegidos da classe sem pertencer ao escopo desta classe. Tambm existe a possibilidade de fazer com que todas as funes de uma classe sejam amigas de outra classe, resultando em uma relao de amizade entre classes. Com este conceito de amizade, C++ compromete a filosofia de tipos abstratos de dados, violando o encapsulamento de informao.

A criao e iniciao de objetos so feitas por intermdio de funes membros especialmente declaradas com este objetivo, denominadas construtores. Um objeto pode ser criado como:

Automtico: criado toda vez que sua declarao encontrada na execuo do programa e destrudo quando o bloco em que ele ocorre deixado;

Esttico: criado no incio da execuo do programa e somente destrudo quando o programa terminado;

Dinmico: Criado utilizando-se o operador new e destrudo atravs do operador delete;

Membro: criado como membro de outra classe ou como elemento de um vetor ou estrutura.

Funes membros existentes para a destruio de objetos so chamadas de destruidores. Portanto, C++ no prov nenhum mecanismo para realizar a recuperao automtica de memria garbage collection. O acesso a um membro de uma classe feito de forma semelhante ao acesso de elementos de uma estrutura em C. Ao contrrio de Smalltalk, a ligao de uma mensagem a um mtodo feita em tempo de compilao, a menos que seja solicitada a ligao dinmica, no caso do mtodo ser declarado como virtual. Uma funo membro declarada com virtual especifica que poder existir uma redefinio em quaisquer das possveis subclasses.

A linguagem C++ suporta o conceito de herana mltipla. Assim, mais de uma classe pode contribuir para a formao da estrutura e do comportamento das instncias de uma classe. O programador pode definir classes que no so especializaes de nenhuma outra. Classes deste tipo so chamadas bsicas. Para uma classe que possui duas ou mais superclasses diretas a especificidade destas



28

superclasses na sua definio determinada atravs da ordem na qual as superclasses esto relacionadas. A primeira delas a mais especfica. A questo de conflitos de nomes foi resolvida atravs do operador de escopo (::).

Como os tipos existentes na linguagem C foram mantidos em C++, no torna-se restrita a estruturao de dados apenas atravs de classes e a linguagem pode ser utilizada sem estar associada programao orientada a objetos.

Na Figura 4.4. pode-se ver um trecho de programa em C++ onde so definidas as mesmas classes Empregado e Gerente do exemplo em SmallTalk;

class empregado {

string* nome; float salario; static int numeroDeEmpregados;

public: empregado(); ~empregado() { numeroDeEmpregados--; } void atualizaNome(string* umNome) { nome = umNome; } string* obtemNome() { return nome } void atualizaSalario(float umSalario) { salario = umSalario; } float obtemSalario() { return salario }

}; int empregado::numeroDeEmpregados = 0; empregado::empregado() {

nome = NULL; salario = 0.0; numeroDeEmpregados++;

} class gerente : public empregado {

float comissao; public:

gerente() { comissao = 0.0; } void atualizaComissao(float umaComissao) { comissao = umaComissao; } float obtemSalario();

} float gerente::obtemSalario();

return (document::obtemSalario() + comissao); }

Figura 4.4. Definio de classes em C++ 4.3. A linguagem de programao Object Pascal A linguagem Object Pascal uma extenso linguagem procedimental Pascal, suportando os conceitos do paradigma de orientao a objetos. Object Pascal foi



29

criada por desenvolvedores da Apple Computer e em 1986 tornou-se pblica como a linguagem a ser suportada pelo ambiente de desenvolvimento da famlia de computadores Macintosh, da Apple. Teve um grande impulso em 1995, quando a Borland lanou o Delphi, um ambiente para programao para Windows que a utiliza como linguagem de programao para o desenvolvimento de aplicaes.

Object Pascal suporta completamente os conceitos de POO. Permite a definio de objetos, o gerenciamento de objetos por classes e o relacionamento de classes atravs do mecanismo de herana. Suporta tambm a definio de mtodos polimrficos, mas no permite a herana mltipla (como em SmallTalk e ao contrrio de C++). Alm disso, no permitido polimorfismo paramtrico (o mesmo nome do mtodo, diferenciado apenas pelo tipo ou quantidade de parmetros passados na mensagem).

Alm do mecanismo bsico de encapsulamento obtido atravs dos objetos, Object Pascal suporta o encapsulamento em outro nvel, atravs de units. Units so mdulos dentre dos quais pode-se definir quaisquer elementos de Object Pascal, como variveis, objetos, procedimentos, exceto outra unit. Uma unit implementa o ocultamento de informao em dois nveis de visibilidade: interface e implementao (implementation). Na interface so declarados os dados, procedimentos e funes visveis fora da unit. Na implementao so declaradas as caractersticas visveis somente no interior da unit.

importante frisar que Object Pascal uma linguagem de propsito geral, podendo ser empregada para desenvolver os mais variados tipos de aplicaes, desde sistemas em tempo real que controlam uma indstria, at um sistema de informaes de uma loja de departamentos. O que faz a diferena so as bibliotecas de classes disponveis para um certo domnio de aplicao. No ambiente Delphi, as bibliotecas de classes para Object Pascal esto direcionadas para o desenvolvimento de sistemas de informao em arquiteturas cliente/servidor.

Em Object Pascal todos as classes so descendentes da classe TObject, de modo que as funes bsicas de manipulao de objetos so tratadas nessa classe genrica (como o construtor e destrutor das instncias). Se em uma declarao de classe for omitida a superclasse, automaticamente ela ser subclasse de TObject.

Os componentes de uma classe so:

Campos: definem os itens de dados que existem em cada instncia da classe. Isto similar a um campo de um registro (estrutura composta).

Mtodos: um procedimento ou funo que efetua alguma operao em um objeto. Existem mtodos especiais que so o construtor e o destrutor. O construtor define as aes associadas com a criao de um objeto (inicializaes, alocao de memria, etc.). O destrutor descreve as aes a serem tomadas quando o objeto destrudo, com a liberao de memria.

Propriedades: so atributos para os quais so definidas aes para a sua leitura e escrita.

O ocultamento de informao nas classes de Object Pascal implementado em cinco nveis, utilizando os seguintes atributos de visibilidade:



30

Public: os componentes declarados na seo public de uma classe no tm nenhuma restrio quanto sua visibilidade

Published: as regras de visibilidade so idnticas s de public. A diferena est no fato de que gerado informao de tipagem em tempo de execuo para campos e propriedades da seo published.

Automated: as regras de visibilidade so idnticas s de public. A diferena est no fato de que gerado informao de tipagem para automao para mtodos e propriedades da seo automated. Esta informao torna possvel a criao de servidor OLE (Object Linking and Embedding).

Protected: os componentes declarados na seo protected de uma classe somente podem ser vistos dentro da prpria classe e suas descendentes.

Private: a visibilidade dos componentes declarados na seo private de uma classe restrita ao mdulo (unit) que contem a declarao da classe. Ou seja, em todo o escopo da unit, pode-se acessar os componentes declarados na seo private.

Programas escritos em Object Pascal podem seguir a sintaxe e semntica tradicional da programao procedimental em Pascal, ou seja, o seu compilador, compila programas que no utilizem as tcnicas de POO. A grande vantagem dos ambientes que fornecem bibliotecas de classes pr-definidas est no fato de que se obtm os benefcios da POO sem utiliz-la conscientemente. O ambiente customizado e a programao auxiliada pelas tcnicas de POO embora o programador no se d conta disso. O Delphi utiliza este conceito.

unit Empregado; interface type TEmpregado = class protected Nome: string[30]; Salario: real; public constructor Create; destructor Destroy; procedure AtualizaNome (umNome: string); function ObtemNome: string; procedure AtualizaSalario (umSalario: real); function ObtemSalario: real; class procedure Inicializa; end; TGerente = class (TEmpregado) private Comissao: real; public constructor Create; procedure AtualizaComissao (umaComissao: real); function ObtemSalario: real;



31

end; implementation var NumeroDeEmpregados: integer; class procedure TEmpregado.Inicializa; begin NumeroDeEmpregados := 0; end; constructor TEmpregado.Create; begin inherited Create; Nome := ''; Salario := 0.0; NumeroDeEmpregados := NumeroDeEmpregados + 1; end; destructor TEmpregado.Destroy; begin inherited Destroy; NumeroDeEmpregados := NumeroDeEmpregados - 1; end; procedure TEmpregado.AtualizaNome (umNome: string); begin Nome := umNome; end; function TEmpregado.ObtemNome: string; begin ObtemNome := Nome; end; procedure TEmpregado.AtualizaSalario (umSalario: real); begin Salario := umSalario; end; function TEmpregado.ObtemSalario: real; begin ObtemSalario := Salario; end; constructor TGerente.Create; begin inherited Create; Comissao := 0.0; end; procedure TGerente.AtualizaComissao (umaComissao: real); begin



32

Comissao := umaComissao; end; function TGerente.ObtemSalario: real; begin ObtemSalario := Salario + Comissao; end; end.

Figura 4.5. Definio de classes em Object Pascal

5. O paradigma de orientao a objetos O paradigma de orientao a objetos apresenta a caracterstica fundamental de unificar os esforos no desenvolvimento de sistemas. Nas sees acima foram abordados os aspectos tericos da orientao a objetos, com nfase na programao. Aqui ser abordado o assunto de maneira mais ampla, apresentando como os vrios nveis de tcnicas, modelos e ambientes esto evoluindo em torno da orientao a objetos. 5.1. Desenvolvimento Orientado a Objetos O desenvolvimento de sistemas orientado a objetos envolve a utilizao de metodologias bem definidas e sedimentadas. A metodologia consiste na construo de um modelo de um domnio de aplicao e na posterior adio a este dos detalhes de implementao durante o projeto de um sistema.

Uma Metodologia Orientada a Objeto (MOO) para desenvolvimento de sistemas, consiste basicamente de: notaes grficas, processos e ferramentas. Alm disso uma boa metodologia deveria prover (nem todas abordam os aspectos abaixo):

Orientao para estimativa de custos; Aspectos de gerenciamento de projetos; Medidas para controle correticidade Procedimentos e polticas para garantia de qualidade de software Descries de papis (funes desempenhadas por pessoas) e programas de

treinamento detalhados Exemplos completos (trabalhados no mundo real) Exerccios de treinamento; Tcnicas bem definidas para utilizao do mtodo

Existem atualmente algumas Metodologias Orientadas a Objetos que podem ser consultadas em livros ou publicaes especializadas, entre as quais pode-se citar: Metodologia de Berard, consistindo de:



33

Berard, E. V., Essays on Object-Oriented Software Engineering, v. 1, Prentice Hall, 1993.

Berard, E. V., A Project Management Handbook for Object-Oriented Software Development, Berard Software Engineering, Inc., 1992.

Metodologia de Booch, consistindo de:

Booch, G., Object-Oriented Design With Applications, Benjamin/Cummings, 1991.

Metodologia de Colbert, consistindo de:

Colbert, E., "The Object-Oriented Software Development Method: A Practical Approach to Object-Oriented Development," Anais de TRI-Ada '89, ACM, out. 1989.

Metodologia de Coad e Yourdon, consistindo de:

Coad, P. & Yourdon, E, Object-Oriented Analysis, Prentice Hall, 1990.

Coad, P. & Yourdon, E, Object-Oriented Design, Prentice Hall, 1990. Metodologia de Embley e Kurtz, consistindo de:

Embley, D.W. et al., Object-Oriented Systems Analysis, A Model-Driven Approach, Yourdon Press/Prentice Hall, 1992.

Metodologia da IBM, consistindo de:

IBM, Object-Oriented Design: A Preliminary Approach - Documento GG24-3647-00, IBM International Technical Support Center, 1990.

IBM, Object-Oriented Analysis of the ITSO Common Scenario - Documento GG24-3566-00. IBM International Technical Support Center, 1990

Metodologia de Martin e Odell, consistindo de:

Martin, J., & Odell, J.J., Object-Oriented Analysis and Design, Prentice Hall, 1992.

Metodologia de Rumbaugh, consistindo de:

Rumbaugh, M. et al, Object-Oriented Modeling and Design, Prentice Hall, 1991.

Metodologia de Shlaer e Mellor, consistindo de:

Shlaer, S. & Mellor, S.J., Object-Oriented Systems Analysis: Modeling the World In Data, Yourdon Press/Prentice Hall, 1988.

Shlaer, S. & Mellor, S.J., Object-Oriented Systems Analysis: Modeling the World In States, Yourdon Press/Prentice Hall, 1992.



34

Metodologia de Wirfs-Brock, consistindo de:

Wirfs-Brock, R. et al, Designing Object-Oriented Software, Prentice Hall, 1990.

Na seo 5.4 ser apresentada resumidamente a metodologia de Rumbaugh, conhecida como Tcnica de Modelagem de Objetos (TMO). 5.2. Anlise Orientada a Objetos A anlise responsvel pelo desenvolvimento de uma representao, a mais completa, concisa, correta e legvel possvel do domnio do problema. O analista parte do enunciado do problema, e constri um modelo da situao do mundo real, mostrando suas propriedades relevantes. O analista deve trabalhar em conjunto com o usurio para entender o problema uma vez que as definies dos problemas raramente so completas ou corretas.

O modelo de anlise uma abstrao concisa e precisa do que o sistema desejado dever fazer, no como o sistema dever faz-lo. Os objetos do modelo devem ser conceitos do domnio da aplicao e no conceitos de implementao computacional, como, por exemplo, estruturas de dados. Um bom modelo pode ser compreendido e criticado por peritos em aplicaes que no sejam programadores. O modelo de anlise no deve conter quaisquer decises de implementao.

A Anlise Orientada a Objetos (AOO) empenha-se em entender e modelar, em termos de conceitos de orientao a objetos (objetos, classes, herana) um determinado problema dentro de um domnio de problema. Isto dentro de uma perspectiva do usurio ou de um especialista sobre o domnio em questo e com nfase em modelar o mundo real. O produto, ou modelo resultante, da AOO especifica um sistema completo e um conjunto integral de requisitos (especificaes) e a interface externa do sistema a ser construdo.

Mtodos convencionais de anlise de sistemas (DeMarco, Yourdon, Gane & Sarson, Shlaer & Mellor) distanciam-se da forma de pensar das pessoas. J os orientados a objetos facilitam a interao analista/usurio, pois modelam o mundo identificando classes e objetos que formam o vocabulrio do domnio do problema. Como resultado, possvel a modelagem de domnios de problemas mais desafiadores com resultados de anlise mais consistentes.

A anlise orientada a objetos facilita a representao explcita dos pontos comuns do domnio da aplicao, atravs do uso de mecanismos de estruturao (herana, composio, classificao). So elaboradas especificaes que facilitam as alteraes que se fazem constantemente necessrias devido a mudanas de requisitos. Existe tambm o potencial para reutilizao de resultados obtidos em anlises anteriores, principalmente num mesmo domnio de aplicao. Isto leva a uma melhor qualidade dos sistemas desenvolvidos. O resultado de um processo de AOO facilita o entendimento do sistema para a etapa de projeto. 5.3. Projeto Orientado a Objetos



35

A etapa de projeto o processo de mapear os requisitos de sistema definidos durante a etapa de anlise para uma representao abstrata de uma implementao especfica do sistema, dentro de restries de custo e desempenho. O projetista de sistemas toma decises de alto nvel relativamente arquitetura geral. Durante o andamento do projeto, o sistema alvo organizado em subsistemas baseados tanto na estrutura da anlise quanto na arquitetura proposta. O projetista de sistemas deve decidir quais caractersticas de desempenho devem ser otimizadas, escolher a estratgia de ataque ao problema e realizar alocaes experimentais de recursos.

Projeto Orientado a Objetos (PrOO) um mtodo de projeto que incorpora um processo de decomposio orientado a objetos e uma notao para descrever um modelo lgico e fsico, bem como esttico e dinmico do sistema projetado. Existem duas partes importantes nesta definio:

O PrOO leva a uma decomposio orientada a objetos do sistema

Utiliza uma notao para expressar os diferentes modelos dos projeto lgico e fsico do sistema

o suporte para decomposio orientada a objetos que torna o projeto orientado a objetos bastante diferente do projeto estruturado. Aquele usa classes e objetos como abstraes para estruturar logicamente os sistemas, enquanto este usa abstraes de funes para estruturao.

As metodologias orientadas a objetos utilizam uma progresso de AOO para PrOO para POO. Um domnio de problema tem muitas possveis realizaes, ou diferentes AOOs (depende de quem realiza a anlise). Uma AOO tem muitas possveis realizaes, ou diferentes PrOOs, mas uma notao similar utilizada para anlise e projeto. Um PrOO tem tambm muitas realizaes, ou diferentes POOs, mas permite que haja uma seleo de ma linguagem especfica entre vrias (ou seja, escolher a melhor linguagem para implementar o projeto). A maneira como a progresso encaminhada e como so escolhidas as realizaes depende da metodologia utilizada e do contexto com o q

apostila poo

Documents