Você está na página 1de 19

Banco de dados Orientado a Objetos

Arquivo e Banco de Dados

ndice
1. 2. 3. 4. 5. 6. Introduo Conceitos Bsico Modelagem e Projeto para BDOOs Persistncia em BDOO's Transaes, Concorrncia, Recuperao, Versionamento de BDOOs Concluso e Bibliografia

Banco De Dados Orientado a Objetos 1.0 Introduo


Hoje, o banco de dados orientados a objeto um fator emergente que integra banco de dados e a tecnologia de orientao a objetos. Por um lado, a necessidade de realizar manipulaes complexas para os banco de dados existentes e uma nova gerao de aplicaes de banco de dados geralmente requisitam mais diretamente um banco de dados orientado a objeto. Por outro lado, aplicaes de linguagens orientadas a objeto e sistemas esto exigindo capacidades de banco de dados, tais como continuidade, simultaneidade e transaes, dos seus ambientes. Estas necessidades esto levando criao de sistemas poderosos, chamados banco de dados orientados a objeto. Os bancos de dados orientados a objeto iniciaram-se primeiramente em projetos de pesquisa nas universidade e centros de pesquisa. Em meados dos anos 80, eles comearam a se tornar produtos comercialmente viaveis. Hoje, eles so mais de 25 produtos no mercado. ndice Prximo

Banco de Dados Orientado a Objetos 2.0 Conceitos Bsicos


Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos
O desenvolvimento dos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos (SGBDOO) teve origem na combinao de idias dos modelos de dados tradicionais e de linguagens de programao orientada a objetos. No SGBDOO, a noo de objeto usada no nvel lgico e possui caractersticas no encontradas nas linguagens de programao tradicionais, como operadores de manipulao de estruturas, gerenciamento de armazenamento, tratamento de integridade e persistncia dos dados. Os modelos de dados orientados a objetos tem um papel importante nos SGBDs porque, em primeiro lugar, so mais adequados para o tratamento de objetos complexos (textos, grficos, imagens) e dinmicos (programas, simulaes). Depois, por possurem maior naturalidade conceitual e, finalmente, por estarem em consonncia com fortes tendncias em linguagens de programao e engenharia de software. O casamento entre as linguagens de programao e banco de dados um dos problemas que esto sendo tratados de forma mais adequada no contexto de orientao a objetos. Apresenta-se adiante os conceitos bsicos de modelos de dados e SGBDs orientados a objetos.

Modelos de Dados Orientados a Objetos Superficialmente, pode-se dizer que orientao a objetos corresponde organizao de sistemas como uma coleo de objetos que integram estruturas de dados e comportamento. Alm desta noo bsica, a abordagem inclui um certo nmero de conceitos, princpios e mecanismos que a diferenciam das demais. Seus principais conceitos so apresentados em seguida. Abstrao a considerao apenas das propriedades comuns de um conjunto de objetos, omitindo os detalhes, utilizada com freqncia na definio de valores similares e na formao de um tipo a partir de outro, em diferentes nveis de abstrao. O uso de abstraes permite a gerao de tipos baseada em hierarquias de tipos e de relacionamentos. Os principais conceitos de abstrao utilizados em banco de dados so generalizao e agregao. A

generalizao corresponde associao " um" onde, a partir de propriedades comuns de diferentes entidades, criada uma outra entidade. O processo inverso a especializao. A agregao corresponde a associao "parte de". Objeto Os objetos so abstraes de dados do mundo real, com uma interface de nomes de operaes e um estado local que permanece oculto. As abstraes da representao e das operaes so ambas suportadas no modelo de dados orientado a objetos, ou seja, so incorporadas as noes de estruturas de dados e de comportamento. Um objeto tem um estado interno descrito por atributos que podem apenas ser acessados ou modificados atravs de operaes definidas pelo criador do objeto. Um objeto individual chamado de instncia ou ocorrncia de objeto. A parte estrutural de um objeto (em banco de dados) similar noo de entidade no modelo Entidade-Relacionamento. Identidade de Objeto Num modelo com identidade de objetos, estes tm existncia independente de seus valores correntes e dos endereos de armazenamento fsico. A identidade do objeto geralmente gerada pelo sistema. A impossibilidade de garantir a identificao de objetos exclusivamente atravs de suas propriedades estruturais e comportamentais motivou a definio de identificadores nicos de objetos, que persistem no tempo de forma independente ao estado interno do objeto. A identidade de objetos elimina as anomalias de atualizao e de integridade referencial, uma vez que a atualizao de um objeto ser automaticamente refletida nos objetos que o referenciam e que o identificador de um objeto no tem seu valor alterado. Objetos Complexos Os objetos complexos so formados por construtores (conjuntos, listas, tuplas, registros, colees, arrays) aplicados a objetos simples (inteiros, booleanos, strings). Nos modelos orientados a objetos, os construtores so em geral ortogonais, isto , qualquer construtor pode ser aplicado a qualquer objeto. No modelo relacional este no o caso, visto que s possvel aplicar o construtor de conjuntos s tuplas e o construtor de registro a valores atmicos. A manuteno de objetos complexos, independente de sua composio, requer a definio de operadores apropriados para sua manipulao como um todo, e transitivos para seus componentes. Exemplos destas operaes so: a atualizao ou remoo de um objeto e cpia profunda ou rasa. Encapsulamento O encapsulamento possibilita a distino entre a especificao e a implementao das operaes de um objeto, alm de prover a modularidade que permite uma melhor estruturao das aplicaes ditas complexas, bem como a segurana dentro do sistema. Em banco de dados se diz que um objeto est encapsulado quando o estado oculto ao usurio e o objeto pode ser consultado e modificado exclusivamente por meio das operaes a ele associadas.

Existe uma certa discusso sobre as consultas em banco de dados quando est incorporada a noo de encapsulamento: Deve-se tornar visvel apenas as operaes e deixar ocultos os dados e as implementaes ? interessante relaxar o encapsulamento apenas para as consultas ? Como deve ser realizada a otimizao de consultas em SGBDOO com encapsulamentos ? Tipo de Objetos O tipo de objeto pode ser visto como a descrio ou especificao de objetos. Um tipo possui duas partes, interface (visvel para o usurio do tipo) e implementao (visvel s para o usurio construtor do tipo). Existem vrias vantagens em se ter um sistema de tipos em um modelo de dados. Alm de modularidade e segurana, do ponto de vista da evoluo do sistema os tipos so especificaes do comportamento que podem ser compostos e modificados incrementalmente, para formar novas especificaes. Classes Um conjunto de objetos que possui o mesmo tipo (atributos, relacionamentos, operaes) pode ser agrupado para formar uma classe. A noo de classe associada ao tempo de execuo, podendo ser vista como uma representao por extenso, enquanto que o tipo uma representao intencional. Cada classe tem um tipo associado, o qual especifica a estrutura e o comportamento de seus objetos. Assim, a extenso da classe denota o conjunto dos objetos atualmente existentes na classe e o tipo prov a estrutura destes objetos. Herana Herana um mecanismo que permite ao usurio definir tipos de forma incremental, por refinamento de outros j existentes, permitindo composio de tipos em que as propriedades de um ou mais tipos so reutilizadas na definio de um novo tipo. De fato, ela corresponde a transferncia de propriedades estruturais e de comportamento de uma classe para suas subclasses. As principais vantagens de herana so prover uma maior expressividade na modelagem dos dados, facilitar a reusabilidade de objetos e definir classes por refinamento, podendo fatorar especificaes e implementaes como na adaptao de mtodos gerais para casos particulares, redefinindo-os para estes, e simplificando a evoluo e a reusabilidade de esquemas de banco de dados. Tipos de Herana Os dois tipos de herana, simples e mltipla, so descritos a seguir:
q

Herana Simples: Na herana simples um certo tipo pode ter apenas um supertipo, da mesma forma uma subclasse s herda diretamente de uma nica classe. Podemos classificar esta herana em quatro subtipos: de substituio, de incluso, de restrio e de especializao. Herana Mltipla: Nesta herana um tipo pode ter supertipos e os mesmos refinamentos de herana simples. H basicamente dois tipos de conflitos referentes herana mltipla: entre o tipo e o supertipo e entre mltiplos supertipos. O primeiro pode ser resolvido dando-se prioridade

definio presente no tipo, e no a no supertipo. Com os conflitos entre mltiplos supertipos, como uma resoluo por default pode causar heranas no desejadas, a abordagem mais segura baseada na requisio explcita da interveno do usurio. Mtodos e Mensagens Um mtodo, em relao a um objeto, corresponde ao comportamento dos objetos, implementando uma operao associada a uma ou mais classes, de forma similar aos cdigos dos procedimentos usados em linguagens de programao tradicionais, que manipula o objeto ou parte deste. Cada objeto tem um certo nmero de operaes para ele definida. Para cada operao pode-se ter um ou mais mtodos de implementao associados. As mensagens so a forma mais usada para se ativar os mtodos. Num SGBDOO os objetos se comunicam e so ativados atravs de mensagens enviadas entre eles. Polimorfismo Em sistemas polimrficos uma mesma operao pode se comportar de diferentes formas em classes distintas. Como exemplo temos o operao print que ser implementada de forma diferente se o objeto correspondente for um texto ou uma imagem: dependendo do objeto teremos um tipo de impresso. Temse tambm polimorfismo quando ocorre a passagem de diferentes tios de objetos como parmetros enviados a outros objetos Um mesmo nome pode ser usado por mais de uma operao definida sobre diferentes objetos, o que caracteriza uma sobrecarga (overloading). A redefinio do operador para cada um dos tipos de objetos definidos caracteriza uma sobreposio (overriding). As operaes so ligadas aos programas em tempo de execuo caracterizando o acoplamento tardio ou late binding. Outros conceitos Finalmente h duas propriedades fundamentais para a construo de um SGBDOO: extensibilidade e completude computacional. A primeira garante que o conjunto de tipos oferecidos pelo sistema permite a definio de novos tipos e no h distino entre os tipos pr-definidos e os definidos pelo usurio. A segunda implica que a linguagem de manipulao de um banco de dados orientado a objetos pode exprimir qualquer funo computacional. ndice Anterior Prximo

Banco de Dados Orientado a Objetos 6.0 Concluso


O Banco de Dados entrou no mercado em meados da dcada de 80. Atualmente h mais de dez empresas de banco de dados orientado a objetos vendendo mais de 25 produtos de banco de dados orientado a objetos. Alm disso, os banco de dados relacionais esto incorporando recursos orientados a objeto em seus produtos da prxima gerao. Essas duas tendncias devem prosseguir. Ambas proporcionam poderosos recursos de modelagem orientada a objeto aos desenvolvedores de aplicao. Os BDOOs constituem uma importante etapa na evoluo dos Sistemas gerenciadores de banco de dados. Alm disso, embora os BDOOs sejam normalmente caracterizados como aqueles cujos recursos satisfazem s exigencias das aplicaes de banco de dados "avanadas", todas as aplicaes de banco de dados podem se beneficiar dos poderosos conceito de modelagem dos BDOOs. Num futuro proximo, muitos usurios se beneficiaro dos produtos que fornecem um modelo orientado a objetos com persistencia e outros recursos de banco de dados. A nfase ser no beneficio da orientao a objeto e o BDOOs para o usurio final. Tanto os desenvolvedores como os usurios finais se beneficiaro dos BDOOs. Todavia, h alguns desafios e questes em aberto, pricipalmente na rea de padres e modelos ajustados. Em um mundo cujos problemas parecem ser agravadas com o tempo, uma simplificao de seus "modelos" talvez seja bem vinda. Os bancos de dados e os servidores de Banco de dados sero definitivamente a parte principal da computao medida que caminhamos para o seculo XXI. Independente de ser como extenses de banco de dados relacionais ou como produtos e empresas de SGBDOO "novis", espera-se que uma percentagem substancial das tecnologias de SGBD seja orientada a objetos.

Bibliografia
Khoshafian, Strag - BANCO DE DADOS ORIENTADOS A OBJETOS - IBPI press, WILEY Internet http://www.rhein-neckar.de/~cetus/software.html http://www.nce.ufrj.br/~marciosd/pfinal

http://cogeae.pucsp.br/~fea/bjsucesu.htm ndice Anterior

Banco de Dados Orientado a Objetos 4.0 Persistncia em Banco de Dados Orientado a Objeto.
O termo persistncia raramente utilizado no contexto de banco de dados. Preferencialmente, o termo usado banco de dados, que conota o espao de objeto resiliente, concorrentemente compartilhado. A funo de um sistema de gerenciamento de banco de dados permitir o acesso e a atualizao simultneos de bancos de dados persistentes. A fim de garantir a persistncia dos dados a longo prazo, os sistemas de gerenciamento de banco de dados utilizam vrias estratgias de recuperao em caso de falhas na transao, no sistema ou no meio. H uma relao fundamental entre o compartilhamento e a persistncia simultneos em banco de dados. As atualizaes de transao devem persistir, mas, como o banco de dados persistentes ao mesmo tempo acessado e atualizado, o sistema de gerenciamento de banco de dados deve preocupar-se com a coerncia dos objetos de dados persistentes. Isso normalmente obtido por meio de estratgias de controle e recuperao concorrentes.

Nveis de Persistncia
Os dados manipulados por um banco de dados orientado a objeto podem ser transientes ou persistente. Os dados transientes s so validos dentro de um programa ou transao, eles se perdem quando o programa ou a transao termina. Os dados persistentes, por outro lado, so armazenados fora do contexto de um programa e assim sobrevivem a varias invocaes de programas. Dados persistentes normalmente consistem nos bancos de dados compartilhado, acessados e atualizados atravs de transaes. Por exemplo, banco de dados pessoais, banco de dados de inventrio e banco de dados de vendedores, contas ou itens, todos contem dados persistentes. No entanto, h vrios nveis de persistncia. Os objetos menos persistentes so aqueles criados e destrudos em procedures. Depois, h os objetos que persistentem dentro do espao de trabalho de uma transao, mas que so invalidados quando a transao termina. As transaes so normalmente executadas dentro de uma sesso. O usurio estabelece seu login e define diferentes parmetros ambientais dentro de um sesso, como caminhos, opes de exibio, janelas, etc. Se o sistema suportar o multiprocessamento, vrias transaes podero estar ativas dentro da mesma sesso de usurio ao mesmo tempo. Todas estas transaes compartilharo os objetos da sesso. No entanto, quando o usurio terminar a sesso, os objetos da sesso sero invalidados. O nico tipo de objeto que persiste atravs das transaes so objetos permanentes normalmente compartilhados por vrios usurios. Esses objetos persistem atravs de transaes, instabilizaes de sistema e ate de meio. Tecnicamente, esses so os objetos recuperveis do banco de dados.

ndice Anterior Prximo

Banco de Dados Orientado a Objetos 5.0 Transaes, Concorrncia, Recuperao e Vercionamento de BDOOs
Transaes
Uma transao um programa executado inteiramente ou ento no executado. As transaes devem mapear bancos de dados de um estado coerente para outro. Para manter a coerncia, as transaes devem passar pelo teste ACID: Atomicidade, coerncia, isolamento, e durabilidade.

Atomicidade
Como uma transao executada inteiramente ou ento no executada, ou a seqncia completa de operaes aplicada ao banco de dados ou ento nenhuma. Este recurso chama-se de Atomicidade; as transaes so atmicas.

Coerncia
Diz-se que o banco de dados coerente se todas as suas restries de integridade so satisfeitas. Pressupe-se que na execuo de uma transao, na ausncia de interferncia de outras transaes concorrentes, o banco de dados seja levado de um estado coerente para outro.

Isolamento
Como as transaes so executadas concorrentemente no mesmo banco de dados, elas devem ser isoladas das outras operaes. Do contrrio, a operao intercalada de transaes concorrente pode levar a anomalias. Assim, os SGBD suportam isolamento, que fornece segurana contra interferncias entre as transaes concorrentes.

Durabilidade
A durabilidade est relacionada capacidade do SGBO de se recuperar de falhas no sistema e no meio. As atualizaes de uma transao efetivada devem devem ser preservadas e registradas em algum meio durvel. Deve-se manter redundncia suficiente para que se reconstrua um banco de dados coerente.

Transaes aninhadas
As transaes de aplicaes de banco de dados orientadas a objetos so normalmente mais demoradas que as de aplicao comerciais convencionais. Alonga durao das transaes em aplicaes avanadas uma caracterstica das aplicaes de banco de dados da prxima gerao. Varias estratgias relacionadas longa durao das transaes foram propostas na pesquisa de banco de dados. Algumas estratgias influenciaram as implementaes de banco de dados orientado a objetos. As transaes aninhadas so utilizadas para resolver alguns problemas associados as transaes de longa durao. Um modelo de transao aninhada pode conter subtransaes, tambm chamadas de transaes-filhas. Em uma transao aninhada, todas as transaes-filhas devem ser efetivadas para que a transao de alto nvel se efetive. Cada subtransao deve ser concluda ou abortada. Tambm, em aplicaes avanadas, as tarefas normalmente envolve vrios usurios. As transaes em cooperao so utilizadas para suportar essas tarefas em conjunto.

Concorrncia
Vrios algoritmos de controle podem ser usados para garantir a capacidade de serializao das transaes e a coerncia do banco de dados. O mais notvel deles o bloqueio. Nos bancos de dados orientados a objeto, o bloqueio pode ser associado a vrios grnulos que so manipulados pelos usurios, incluindo classes, instancias e objetos complexos. Nos bancos de dados orientados a objeto, h dois aspectos de bloqueio que so relevantes para o compartilhamento concorrente de objetos: Bloqueio de Hierarquia de classe: As classes nos bancos de dados orientados a objeto so organizadas em hierarquias de herana, de modo que cada classe da hierarquia tenha uma extenso ou instancia preexistente. Por isso importante fornecer bloqueio de granularidade a essas estruturas. Por exemplo, uma superclasse poderia bloquear implicitamente todas as subclasses no mesmo modo de bloqueio. As subclasses incluem os descendentes diretos da superclasse e os descendentes de suas subclasses. Bloqueio de Objeto complexo: Os bancos de dados orientados a objetos contm objetos que podem referenciar ou incorporar outros objetos. Alem disso, alguns objetos so "valores", enquanto outros possuem identidade. Para otimizar a concorrncia na presena de modelos que envolvam objetos complexos, foram analisados vrios esquemas de bloqueio de "objetos compostos" ou de "objetos dependentes" para objetos complexos.

Recuperao
A confiabilidade e a grata recuperao de falhas so importantes recursos de um sistema de gerenciamento de banco de dados. O gerenciador de recuperao o modulo que administras as tcnicas de recuperao dessas falhas. Os trs importantes tipos de falhas que so responsabilidade do

gerenciador de recuperao so: as falhas de transao, as falhas no sistema, as falhas no meio. Uma das estruturas mais utilizadas para o gerenciamento de recuperao o log. O log utilizado para registrar e armazenar as imagens anteriores e posteriores dos objetos atualizados. A imagem anterior o estado do objeto antes da atualizao da transao, e a imagem posterior o estado do objeto aps a atualizao da transao. Quase todos os bancos de dados orientados a objeto suportam a recuperao. A maioria dos SGBDOO utiliza o logging para a recuperao do banco de dados a um estado coerente. Alguns utilizam a duplicao ou espelhamento de dados.

Vercionamento
O acesso a estados anteriores ou a estados alterados de objetos parte inerente de muitas aplicaes. Ele obtido por meio de vrias verses do mesmo objeto. O gerenciamento de verso em um banco de dados orientados a objeto consiste em ferramentas e construes que automatizam ou simplificam a construo e a organizao de verses ou configuraes. Sem essas ferramentas, caberia ao usurio organizar e manter as verses. Podemos considerar a configurao como um grupo de objetos tratados como uma unidade para bloqueio e Vercionamento. Os objetos individuais dentro da configurao podem sofrer modificaes, de modo que cada objeto pode Ter um histrico das verses. Vrios objetos dentro da configurao so atualizados em momentos diferentes e no necessariamente na mesma freqncia. ndice Anterior Prximo

Banco de Dados Orientado a Objetos 3.0 Modelagem e Projeto para BDOOs


ANLISE ORIENTADA A OBJETOS
Diretamente derivada dos conceitos da programao e do projeto orientado a objeto, a anlise orientada a objeto certamente a mais nova das abordagens de anlise de sistemas. Baseada na decomposio do sistema de acordo com os objetos ( entidades de dados ) manipulados por este, esta abordagem oferece como principais benefcios os seguintes fatores: a) Mantm a modelagem do sistema e, conseqentemente, a automao do mesmo o mais prximo possvel de uma viso conceitual do mundo real. b) Baseia a decomposio e modelagem do sistema nos dados, que o elemento mais estvel de todos aqueles que compem um sistema de informao. c) De todas as abordagens de anlise conhecidas at o momento, a anlise orientada a objetos , certamente, a que oferece maior transparncia na passagem da anlise ( modelo essencial ) para o projeto ( modelo de implementao ). Isso porque, se for seguida a tcnica de projeto orientado a objeto, a passagem de um modelo para o outro ser feita atravs da introduo de detalhes, no.requerendo uma reorganizao do modelo, como o caso na passagem de anlise estruturada para o projeto estruturado. interessante que faamos a definio de Classes e Objetos, (9): a) Objeto: "Uma abstrao de alguma coisa em um domnio de problema, refletindo as capacidades de um sistema de manter informaes sobre s, interagir com s, ou ambos, um encapsulamento de Valores, de Atributos e seus Servios exclusivos". b) Classe: "Uma coleo de objetos que podem ser descritos com o mesmo Atributo ou Servio".

Anlise Orientada a Objeto, uma abordagem passo a passo Pode-se perguntar: Porque no usar as tcnicas de anlise j estabelecidas, como a anlise estruturada. A evoluo da anlise estruturada nos mostra que h uma srie de desenvolvimentos, a programao estruturada precedida pelo projeto estruturado, que por sua vez precedido pela anlise estruturada. A anlise e o projeto estruturado so construdos no topo de noes bsicas da programao estruturada tradicional, incluindo a separao de dados e processos.

Algumas noes bsicas de programao orientada a objetos so diferentes da programao tradicional. Por instncia, objetos encapsulam ambos comportamento e estado, enquanto as linguagens tradicionais de programao deliberadamente mantm uma separao. A seguir apresentaremos uma abordagem de desenvolvimento de sistemas orientados a objetos, numa abordagem passo a passo, (3): OBA (Object Behavior Analysis) provm um modelo conceitual para um primeiro estgio na criao de uma aplicao orientada a objeto. Usando esta abordagem como um passo positivo no processo de construo, com sucesso, de um sistema flexvel orientado a objeto. A OBA tenta responder questes que a anlise tradicional de sistemas no consegue responder, e isto de uma maneira natural, encorajando a interao entre as diversas fases do desenvolvimento e com o auxlio da prototipao rpida especialmente nas fases de anlise e projeto. Uma implicao desta abordagem que analisar, projetar e implementar, no do tipo, "vamos fazer certo da primeira vez". Na prtica geralmente isso impossivel, ter a informao que se necessita para uma anlise completa, muito menos interpretar e representar todas as coisas corretamente sem interaes. Interaes controladas contribuem para clarificar e tornar mais completas as especificaes e projeto. OBA consiste de uma compreeno da aplicao e identificao dos comportamentos iniciais, definindo os objetos que exibem esses comportamentos, classificando os objetos, identificando os relacionamentos entre eles e modelando seus ciclos de vida. a) Etapa 1: Identificando os comportamentos Para compreender o que a aplicao far, primeiro entrevista-se o usurio para a aplicao pretendidada observando ento a ao para ver o que ela far, quem ou o qu interagir com o sistema , em que ordem ocorrer, e quais as diferentes aes tomadas. O ponto principal uma lista dos desejos necessrios para o sistema analisado, o mais alto nvel do comportamento define as responsabilidades do sistema. A sada desta etapa uma lista dos comportamentos desejados do sistema e uma lista de suas propriedades visveis,bem como de "scripts". b) Etapa 2: Definindo os objetos Uma vez definidos os comportamentos iniciais necessita-se determinar a sua performance. Encontrar os objetos um passo para compreender a sua performance. Imediatamente v-se quem ou o que responsavel por um comportamento particular.

Cartes de modelagem, usados nesta etapa, so pequenos cartes indexados com os termos:"nome", "responsabilidade" e "colaboradores",escrito neles. Nesses cartes escreve-se o comportamento do sistema (responsabilidades), o que ou quem responsvel por um comportamento em particular, to bem quanto para padres de comportamento (nome) e quem ou o que este agente responsvel interage (colaboradores). Os objetos de aplicao so compostos desses objetos concretos, conceitos, processos e eventos que exibem comportamentos significativos. A sada da etapa 2 uma lista de objetos, os quais relatados em grupos de comportamento e propriedades visveis. Pode ser necessrio fazer esta etapa mais de uma vez para atualizar a lista de objetos (p. ex.: adicionar uma classe de objetos). c) Etapa 3: Classificando os objetos Neste caso, classificao significa agrupar objetos de acordo com alguma similaridade de comportamento (funo) e estado (forma). Classificar objetos primariamente pelo comportamento a chave da OBA. Para isso, deve ser visto comportamentos similares em diferentes objetos. A sada da etapa 3 um diagrama de relacionamento hierrquico entre os objetos, baseados na forma abstrata usando o critrio de comportamento similar. Uma importante tarefa no mundo da orientao a objeto distinguir o abstrato a partir do especfico. OBA inicia o projeto com o p direito, por auxiliar na localizao de conceitos que sero usados para ambas classes, abstrato e concreto durante o projeto e implementao. d) Etapa 4: Identificando os relacionamentos A etapa 4 envolve um desenho de um esboo preliminar dos objetos em relao uns com os outros. Usando esse esboo, to bem quanto um "script" e os cartes de modelagem, pode -se criar uma tabela que clarifica os relacionamentos que cada objeto tem uns com os outros. Para OBA, necessita-se obter uma descrio,a mais clara possvel, em termos de linguagem natural, dos relacionamentos entre os objetos. Ento simplifica-se essas descries de linguagens. De outro modo, reduzindo uma descrio simplificada em linguagem natural para os subconjuntos dos relacionamentos implementveis em OOL, parte da fase de projeto e no da fase de anlise. e) Etapa 5: Modelando o Processo Necessita-se para determinar quais objetos iniciam atividades e identificar qual a sequencia das atividades, para isso so usados os "scripts" desenvolvidos na etapa 1 para iniciar o modelo de aplicao. Pode-se especificar o ciclo de vida dos objetos e seus "status" em diferentes partes do ciclo.

f) A Anlise Final: O resultado da OBA so as especificaes das necessidades, escrita em termos de comportamento requerido, que delinea os objetos primrios como eles so organizados. Esta especificao inclui objetos superordenados a partir de um agrupamento por comportamento e objetos subordenados. O comportamento primrio e estado da cada objeto listado, bem como seus relacionamentos dos objetos e as sequncias de atividades. Os "scripts" produzidos na OBA so especialmente usados no detalhamento de como trabalhar a interface com o usurio. Com o uso da OBA para anlise de um sistema orientado a objeto, obtm-se uma especificao do comportamento que enfatiza os aspectos da alta reusabilidade do sistema, que , os protocolos de comportamento e os agrupamentos hierrquicos dos objetos de acordo com o protocolo. Uma anlise cuidadosa, focando as abstraes comportamentais, promovem uma reduo no cdigo,por calar o caminho para uma boa construo hierrquica e hereditariedade e o seu uso prudente pode ajudar a produzir uma clara e compreensvel estrutura de aplicao orientada a objeto.

PROJETO ORIENTADO A OBJETOS (OOD)


Uma vez construido o Modelo Essencial do sistema, necessitamos construir o seu Modelo de Implementao, ou seja, o seu projeto fsico. Para essa fase do ciclo de vida do sistema, assim como para as demais, existem diversos mtodos alternativos, como o Projeto Estruturado, e o Projeto Orientado a Objetos. Um problema existente no projeto estruturado a sua taxa de subjetividade dos conceitos de modularizao. Alguns objetivos chave para o projeto orientado a objetos (9): a) Aumento da produtividade pelo aumento da manutenabilidade e enfase na reusabilidade. b) Incremento da qualidade, por nfase no processo de desenvolvimento de software, e no nicamente no produto final. c) Aumentar a manutenabilidade por separar intrinsicamente partes volteis do sistema daquelas que so estveis. J no Projeto Orientado a Objetos, temos alguns benefcios tais como: a) A arquitetura do sistema desenvolvida a partir dos objetos por ele manipulados. Em um sistema de

informaes, os objetos correspondem s entidades de dados utilizadas. b) Para cada objeto so definidas as funes ou servios que dever permitir, direta ou indiretamente, o atendimento aos requisitos estabelecidos. Todos os servios correspondentes a um mesmo objeto devem ser integrados e estruturados em um nico mdulo, estabelecendo-se assim a funcionalidade do objeto. c) Um objeto, atravs de seus servios, pode colaborar com outros objetos. Esta colaborao se processa atravs da troca de mensagens entre os objetos cliente e servidor. a) O objeto pode tambm herdar algumas funcionalidades correspondentes a seu objeto "pai", o qual deve representar, conceitualmente, uma entidade mais genrica. Entre as principais vantagens oferecidas pelo mtodo do projeto orientado por objeto temos: a) Fornece regras precisas para a modularizao do sistema. b) Desenvolvimento de uma arquitetura mais estvel, uma vez que se estrutura com base no modelo de dados utilizado, o qual apresenta pouca vulnerabilidade a mudanas na funcionalidade do sistema. c) Alto grau de reusabilidade das rotinas desenvolvidas. d) Maior facilidade de transio da fase de anlise para a fase de projeto.

PROTOTIPAO ORIENTADA A OBJETO


A prototipao orientada a objeto (8) baseada em abstrao de dados e hereditariedade. Objetos encapsulam o dado em sistemas de prototipao servindo como base para o projeto e a implementao. Desde que o dado na implementao geralmente mais estvel que as etapas do processo, isto conduz a descrio do sistema que mais fcil para ser modificado que atravs da abstrao procedural. Hereditariedade ajuda a reduzir o trabalho envolvido na construo do sistema por incluso de aspectos comuns de cdigo em diferentes contextos sem a repetio explcita de detalhes. Objetos tambm provem componentes convenientes para cdigo reusavel, processamento paralelo e controle de verses, desse modo, as abordagens orientadas a objeto fazem prottipos mais flexveis e facilmente automatizaveis. O OOD e a prototipao (9) tem vnculos em comum pois; uma maneira natural de trabalhar, experimenta-se a interface humana, para a clarificao dos requisitos procurados, para a praticidade do projeto, para a entrega, funcionalmente, to cedo quanto possvel.

CONCLUSES

A orientao a objetos (2) uma mudana cultural, muito mais do que uma mudana tecnolgica, ela um paradigma, uma revoluo industrial do software baseada na reusabilidade e intercambialidade entre as partes que alterar o universo de software to fortemente quanto a revoluo industrial alterou a manufatura. O paradigma muda das linguagens procedurais para as linguagens orientadas a objeto, com o direcionamento para ambientes de alto nvel como o Smalltalk. Do mesmo modo as metodologias mudam das estruturadas para as orientadas a objetos, no podendo haver uma continuidade nas tcnicas estruturadas existentes, confirmando (1), "os mtodos estruturados No podem ser objetificados". Grandes organizaes mudam lentamente, velhas metodologias, quando h, so difceis de mudar o no entanto se requer uma mudana radical na maneira de como sistemas sero desenvolvidos a partir de agora, isto , orientados a objeto e com auxlio de CASE. Os anos 90 sero de gradual aceitao da orientao a objetos e no podendo tomar por base antigas metodologias. Orientao a objetos promete muito mais do que "apontar e clicar" a interface de janelas, e com a popularizao das arquiteturas abertas, redes distribudas, CASE e ambientes grficos o seu destino est definido. ndice Anterior Prximo

Você também pode gostar