Até não muito pouco tempo, software e hardware estavam tão próximos que se dizia que "software is shipped free with hardware". Essa situação foi evoluindo até que em 1968, o primeiro gerenciador independente de banco de dados foi introduzido, marcando o descolamento, em termos comerciais e de desenvolvimento, do software e do hardware.

Outros bancos de dados (gerenciadores de) foram surgindo, adotando estruturas hierárquicas e assemelhadas, até que no final dos anos 70, surgiu um novo modelo - o modelo relacional, que por suas características de flexibilidade, entre outras, tornou-o extremamente atrativo para os usuários. O desenvolvimento de sistemas ficou mais fácil, e os bancos de dados relacionais rapidamente tornaram-se o padrão aceito pela indústria; pode-se dizer que desde o final dos anos 80, a maioria absoluta das aplicações foi desenvolvida "em cima" dos DB relacionais.

No entanto, à medida em que o uso de computadores se expandiu, diferentes trabalhos passaram a ser executados com a utilização dos mesmos - tornou-se necessário trabalhar com diferentes tipos de dados, como sons, imagens, etc. Rapidamente se compreendeu que o trabalho com esses tipos de dados necessitaria de um suporte diferente em termos de gerenciadores de bancos de dados, de linguagens e, por conseqüência, de técnicas de desenvolvimento. Nos dias de hoje, tabelas seguem sendo o melhor meio para se armazenar dados acerca das vendas ou da folha de pagamento de uma empresa, pois esses dados tendem a ser bidimensionais por natureza - agora, se adicionarmos a eles uma foto ou uma impressão digital, por exemplo, uma tabela começa a ser inadequada para esse fim - lembrando que todo software é uma abstração ou modelo de alguma coisa do mundo real, podemos dizer que a tecnologia OO torna possível refletir mais claramente essas realidades.

Os conceitos OO começaram a se solidificar nos anos 60/70 - sistemas comerciais tornaram-se disponíveis na segunda metade dos anos 80, quando Smalltalk e C++ tornaram-se realidade, vindo logo a seguir os bancos de dados e as técnicas OO, das quais há hoje uma grande variedade, como se verá mais à frente. Mais a título de curiosidade, pode-se dizer que o termo OO foi criado nos anos 70, durante o desenvolvimento do SmallTalk, no centro de pesquisas da Xerox em Palo Alto, Califórnia.

Ao se falar de Orientação a Objetos, evidentemente o primeiro conceito a ser apresentado é o de Objeto. Um objeto é qualquer coisa, real ou abstrata, a respeito da qual armazenamos dados - um animal, uma organização, um avião, uma parte desse avião ou uma reserva num vôo desse avião - um objeto inclusive pode ser constituído por outros objetos.

Um tipo de objeto é uma categoria de objeto e um objeto é uma instância de um tipo de objeto. Utilizando o jargão de bancos de dados, Aluno, Professor e Disciplina seriam tipos de entidade, havendo muitas instâncias de cada tipo de entidade, como por exemplo, instâncias de Aluno seriam os alunos João, José e Pedro, instâncias de Disciplina seriam Matemática, Latim, etc. De forma análoga, em termos de Tecnologia de Objetos, um tipo de objeto poderia ser um avião e objetos poderiam ser B747, B737, etc. Cabe observar no entanto que objeto é diferente de entidade, pois essa preocupa-se apenas com os dados, enquanto objeto preocupa-se tanto com os dados como com os métodos com os quais os dados são manipulados.

A classe "descreve"um grupo de objetos com propriedades semelhantes (atributos), o mesmo comportamento (operações), os mesmos relacionamentos com outros objetos e a mesma semântica (Hirama, 1998). Ao construirmos uma classe, estamos implementando um tipo de objeto. Ela especifica uma estrutura de dados e os métodos que se aplicam a cada um de seus objetos. Deve-se observar que aqui tipo de objeto deve ser encarado como um conceito que especifica uma família de objetos sem estipular como o tipo e o objeto são implementados. Os tipos de objeto são especificados durante a análise, mas quando se implementam tipos de objeto, outros termos são usados - no caso que nos interessa mais de perto, o das linguagens OO, os tipos de objeto são implementados como classes. Martin (1994) nos dá um exemplo claro acerca do assunto: "A implementação da classe especifica a estrutura de dados para cada um de seus objetos. Por exemplo, uma classe Empregado incluiria dados sobre cargo, salário, etc. Além disso, cada classe define um conjunto de operações permissíveis que permitem o acesso e a modificação de dados do objeto. Uma classe "Empregado" poderia incluir operações, tais como "contratar" e "promover". Os detalhes sobre o método da operação são especificados pela classe - o método é armazenado uma vez, e todos os objetos de determinada classe podem compartilhá-lo. O termo classe refere-se à implementação de tipos de objeto. Ele refere-se a bibliotecas de classes como repositórios de classes existentes que podem ser usadas por um analista. Muito do sucesso do desenvolvimento de sistemas OO está em se determinar um bom conjunto de classes, pois isso acelera o desenvolvimento, pois o reuso implica em menos linhas de código (que por sua vez implica em menos bugs) e menores custos de manutenção.

Os métodos especificam a maneira pela qual os dados de um objeto são manipulados. Assim, um objeto tem suas propriedades representadas pelos tipos de dados e seu comportamento representado pelos métodos. Dois métodos associados ao tipo de objeto Avião poderiam ser um relacionasse todos os aviões e outro que calculasse a média de combustível consumido por milha voada. Aproveitando a menção feita a bancos de dados no item anterior, é importante mencionar que no mundo OO, a estrutura de dados e os métodos para cada tipo de objeto são armazenados juntos. A estrutura de dados não pode ser acessada ou manipulada, exceto pelos métodos que fazem parte do tipo de objeto.

Encapsulamento é o ato de ocultar do usuário os detalhes da implementação de um objeto, através do empacotamento simultâneo dos dados e métodos - a idéia básica é deixar visível a um usuário apenas o que ele necessita ver (e acessar, evifdentemente). O objeto esconde seus dados de outros objetos e permite que estes sejam acessados por intermédio de seus próprios métodos - se todos os programas pudessem acessar os dados de quaisquer maneiras que os usuários desejassem, os dados poderiam ser facilmente corrompidos ou usados de forma inadequada. O encapsulamento oculta os detalhes de um objeto de seus usuários, que conhecem quais operações do objeto podem ser solicitadas, mas não conhecem os detalhes acerca de como uma operação é executada. Voltando a falar em reuso e manutenção, o encapsulamento é importante porque separa a maneira como um objeto se comporta da maneira como ele é implementado. Isso permite que as implementações do objeto sejam modificadas sem exigir que os aplicativos que as usam sejam também modificados. É mais fácil de modificar programas usando-se o encapsulamento porque um tipo de objeto é modificado de uma vez só. Se um tipo de objeto for modificado, somente os métodos e as estruturas de dados associados a esse tipo de objeto são afetados, e usualmente apenas alguns desses métodos e estruturas de dados o são. O comportamento do tipo de objeto pode ser modificado e testado, independentemente de outros tipos de objetos. Martin (1995) no dá um exemplo muito didático: "Um aparelho de videocassete (VCR) é um exemplo de objeto. Ele tem certos tipos especificados de comportamento. Um VCR Sony AH-8500 é um tipo de objeto, e um aparelho individual poderia ser uma instância deste tipo. Todos os aparelhos desse tipo têm os mesmos métodos. O VCR contém componentes complexos, sendo que muitos contêm, eles mesmos, componentes, mas você não precisa saber sobre eles. Os componentes eletrônicos ou seus dados não podem ser acossados diretamente. (ele avisa: "Cuidado. Não Abra. Risco de Choque Elétrico"). Você pode usar somente os métodos especificados. O encapsulamento impede a interferência nas partes internas e oculta a complexidade dos componentes. Você está preocupado somente com o comportamento do VCR descrito em seu manual. Esse tipo de objeto tem muitos métodos, tais como reproduzir gravar, carregar e descarregar a fita cassete, etc. Os dados do objeto não podem ser usados, exceto com esses métodos. Mensagens telefônicas não podem ser gravadas no VCR ou o timer não pode ser usado para operar a cafeteira elétrica".

Um objeto reage a uma solicitação. Esta faz com que uma operação execute o método apropriado e, se o sistema assim determinar, envie resposta. A mensagem que constitui a solicitação contém o nome do objeto, o nome da operação e, freqüentemente, parâmetros - note-se que uma operação pode envolver mais de um objeto. O usuário não precisa conhecer os detalhes do objeto, apenas como se comunicar com ele e como ele responde. Voltando ao avião, ao acionar o comando dos flaps, o piloto vê uma ação sendo executada e recebe resposta através de seu painel de controle - todos os objetos "Avião" são controlados dessa forma (ao menos didaticamente), mas o piloto não poderá mudar a temperatura do cockpit usando o comando dos flaps, porque aqui outro tipo de mensagem será necessária.

Herança

O conceito de herança é um dos que fazem com que a tecnologia OO tenha como grande atrativo a aceleração do processo de desenvolvimento. Se já existir uma classe que pode responder a diferentes mensagens, por que construir uma nova classe, quase sempre semelhante à já existente, para responder a algumas novas mensagens - ou então reescrever a classe? As linguagens OO mais comuns permitem que se crie uma subclasse, que herda todas as características da classe-mãe - isso permite que ao se escrever um novo programa, pode-se simplesmente utilizar classes já existentes, quando estas tem um comportamento análogo às exigidas pelo novo programa

Pode ser definido como a capacidade de duas ou mais classes responderem à mesma solicitação, cada uma a seu modo. Note-se que passar a mesma mensagem a dois objetos de classes diferentes pode produzir resultados completamente diferentes. Por exemplo, fazendo analogia com um automóvel, a mensagem "pise no pedal" terá efeitos completamente diferentes quando o pedal for o do freio ou o do acelerador. Voltando ao nosso meio, a mensagem "imprima", pode gerar efeitos diferentes dependendo da impressora à qual for enviada.

Todos aqueles que tem uma experiência profissional razoavelmente longa como desenvolvedores, tem visto a adoção de diversos modismos, todos eles apresentados como a "silver bullet" de que fala o professor Kechi Hirama (1998). Empresas simplesmente abandonam investimentos de porte em software, hardware e treinamento; novos produtos, em especial de empresas da área financeira, deixam de ser lançados, etc., tudo enquanto a empresa se movimenta para adotar a última novidade, a "salvação da lavoura"... Foi assim com o downsizing, com o Natural, etc. Por tudo isso, os profissionais da área devem ver sempre com muita cautela essas novidades, sem no entanto se aferrarem ao que já existe ou considerarem tudo que é novo inútil. Dentro dessa perspectiva, surge a pergunta: por que OO? Evidentemente, porque essa tecnologia pode trazer benefícios aos seus usuários, gerando a possibilidade de mudar drasticamente a maneira pela qual se administra as equipes de desenvolvimento e a própria forma pela qual se desenvolve sistemas. E quais seriam esses benefícios? São os que serão apresentados a seguir.

Talvez a queixa mais comum levada aos desenvolvedores de software seja a lentidão com que sistemas são desenvolvidos, gerando custos, perda de oportunidades de mercado, etc. OO permite que aplicativos sejam criados com componentes pré-existentes, aumentando a velocidade de desenvolvimento.

As classes são projetadas de forma que possam ser utilizadas em muitos sistemas. Para maximizar a reutilização, as classes podem ser construídas de forma que possam ser customizadas para cada sistema. Uma biblioteca de classes irá surgindo naturalmente à medida em que se usa OO, fazendo com que cada vez mais classes possam estar disponíveis para uso na organização - a experiência mostra que bibliotecas de classes normalmente crescem rapidamente. Um dos principais objetivos das técnicas baseadas em objetos é o de se conseguir reaproveitamento em massa na construção de software.

O software construído de classes estáveis, bem testadas é menos suscetível a erros do que o software desenvolvido "do zero". A adoção de técnicas formais para criar métodos tem recursos para gerar software de alta confiabilidade, com pouca probabilidade de ocorrência de 'bugs". Esse software tende a ter mais qualidade, porque é construído com componentes que foram repetidamente testados e aperfeiçoados.

As estruturas de dados só podem ser usadas com métodos específicos. Isso é particularmente importante nos sistemas cliente-servidor e distribuídos, onde usuários desconhecidos podem tentar acessar o sistema.

Os programas são construídos em partes pequenas, cada uma das quais é geralmente fácil de ser entendida e codificada. O programador cria um método para cada classe, um de cada vez. O método transforma o estado dos objetos, de modo normalmente simples, se considerado isoladamente - isso também torna a manutenção, a nível de programa, mais fácil.

OO é especialmente indicado para tratamento de imagens, vídeo, voz, etc., através dos Binary Large Objects, ou BLOBS.

Aplicativos já existentes, não-baseados em objetos, freqüentemente podem ser preservados, se adaptados para OO. Um caso típico é o do Oracle 8, cujo fornecedor diz ser um "banco de dados objeto-relacional" - essa caracterísitica permite migração rápida e econômica, preservando investimentos.

As classes devem ser projetadas para serem independentes de plataformas (hardware e software), empregando mensagens em formatos padrão. Isso permite que as classes sejam utilizadas por diferentes sistemas operacionais, gerenciadores de banco de dados, hardware, etc. - o desenvolvedor não tem que se preocupar com o ambiente em que seu sistema operará.

OO permitirá que se utilize diretórios de software de objetos amplamente distribuídos, com as classes de uma máquina interagindo com classes de outro local, sem precisar saber onde elas residem, trocando mensagens no formato padrão. Processamento paralelo/concorrente também será mais fácil. Espera-se também melhoria de performance do hardware, pois os bancos de dados baseados em objetos têm demonstrado um desempenho muito superior ao dos bancos de dados relacionais, no caso de aplicativos com estrutura de dados muito complexas.

É importante inicialmente dizer que nesta parte do trabalho o termo "método" não será utilizado no sentido em que a palavra é normalmente utilizada em OO ( métodos especificam a maneira pela qual os dados de um objeto são manipulados, etc.) - mas sim num sentido próximo ao de "metodologia".

Muito freqüentemente, os envolvidos no desenvolvimento de sistemas adotam uma ferramenta nova, que pode ser uma linguagem, um gerenciador de bancos de dados, etc., porém os utilizam de acordo com as velhas técnicas de análise e projeto - com isso, deixam de desfrutar de todos os benefícios que essa ferramenta pode trazer. OO não é uma exceção - se se pretende usar essa tecnologia radicalmente nova, deve-se tentar usa-la não só tem termos de linguagens de programação ou gerenciadores de bancos de dados, mas também considerar-se métodos adequados para desenvolvimento de sistemas.

Como diz Giorno (1997), objetos e mensagens são os mecanismos centrais da Tecnologia OO. De um modo geral, desenvolver um Sistema Orientado a Objetos (SOO) envolve, inicialmente, identificar e especificar objetos, seus relacionamentos e seus atributos. As funcionalidades exigidas do sistema devem ser equacionadas em termos de troca de mensagens, por meio da definição de interações entre objetos e da especificação de métodos correspondentes. Alguma forma de controle destas funcionalidades deve ser considerada com a implementação ocorrendo em uma linguagem ou ferramenta computacional OO. Este esforço deve ser complementado pela incorporação de uma interface de usuário amigável e pela integração do sistema a seu ambiente de trabalho.

Uma metodologia de desenvolvimento proporciona uma abordagem sistemática para o desenvolvimento e o detalhamento destas atividades, proporcionando elementos para assegurar que o sistema será construído de forma correta. O número de "metodologias" propostas na literatura para a construção de SOOs é elevado. São métodos ainda em evolução, carecendo de validações, experimentações e conseqüentes refinamentos para que possam ser considerados metodologias. Dentre esses métodos, os que vem se destacando na literatura OO e cujas características básicas serão apresentadas aqui, são: Coad/Yourdon (OOA/OOD), OOSE, OMT, VMT, SOMA e Fusão.

Essa elevada disponibilidade de métodos OO (em curioso contraste com a escassez de gerenciadores de bancos de dados OO "comerciais"), impacta, de forma positiva, a disseminação da tecnologia.

Diz o prof. Giorno (1997), que um método de desenvolvimento OO deve ser considerado quando esteja apto a:

- cobrir as etapas de análise e projeto do cicio de vida de desenvolvimento, proporcionando transições suaves entre estas etapas ;

- visualizar o processo de desenvolvimento como uma atividade de modelagem, proporcionando diferentes, porém relacionados, tipos de modelos;

- proporcionar conceitos, notações, regras e modelos bem definidos, completos e coerentes;

- - suportar aspectos técnicos e gerenciais para o desenvolvimento de sistemas computacionais (não pode ser apenas uma curiosidade de laboratório);

- estar publicamente disponível na forma de livro didático com conteúdo razoavelmente completo e consistente.

São chamados "métodos de segunda geração" aqueles que incorporam ou estendem conceitos utilizados nos métodos pioneiros, como é o caso daqueles que serão abordados a seguir.

Desenvolvido por Peter Coad e Edward Yourdon (1991), divide o processo de desenvolvimento nas etapas de Análise, Projeto e Implementação.

Em sua etapa de Análise, o método concentra-se em especificar o domínio de problemas e os requisitos do sistema por meio de cinco atividades, resumidas a seguir na ordem proposta de execução: Identificação de Objetos (identificar entidades do domínio de problemas que serão responsabilidades do sistema'); Identificação de Estruturas (identificar relações entre os objetos identificados, de modo a organizá-los em hierarquias e estruturas); Identificação de Assuntos (identificar agrupamentos de objetos identificados e as correspondentes hierarquias e estruturas, de modo a separá-ios em grupos denominados assuntos); Definição de Atributos (especificar os objetos identificados) e Definição de Serviços, onde serão definidas as operações passíveis de serem executadas pelos objetos identificados.

Para ver el gráfico faltante haga click en el menú superior " Bajar trabajo"

Esta parte do método é a denominada OOA (OO Analysis), enquanto a OOD (OO Design), modela uma dada implementação, basicamente adicionando os módulos de interação com os usuários e de gerenciamento de tarefas e dados, de forma cumprir as etapas de Projeto e de implementação.

O método Object-Oriented Software Engineering - OOSE, desenvolvido por I. Jacobson e lançado em 1992, constitui uma versão simplificada do método Objectory do mesmo autor e tem como finalidade apoiar desenvolvimentos orientados a objetos com base na noção de use cases .

Um use case é um cenário de uso particular do sistema proposto, envolvendo algum agente (usuário, outros sístemas, etc.) efetuando alguma transação com o sistema para atingir algum objetivo. O use case representa então um diálogo entre um ator (representando aquilo que interage com o sistema), que inicia o diálogo, e o sistema, capturando alguma funcionalidade desse último pela representação do que o agente será capaz de fazer com o sistema; a lista de todos use cases coletados especifica todos os modos possíveis de usar o sistema .

O método OOSE gera então cinco modelos para a criação de um sistema OO, os modelos de Requisitos (capta a funcionalidade requerida do sistema sob a perspectiva dos usuários); de Análise (define a estrutura de objetos do sistema); de Projeto (refina o modelo de Análise em termos do ambiente de implementação), de Implementação (Converte os blocos refinados para as características da da linguagem escolhida) e de Teste, que permitirá testar o sistema através de especificações de teste derivadas dos use cases.

Para ver el gráfico faltante haga click en el menú superior " Bajar trabajo"

O Método Object Modeling Technique - OMT , foi desenvolvido por uma equipe liderada por James Rumbaugh, trabalhando para a General Electric em seu Research and Development Center.

O método sugere que o processo de desenvolvimento seja dividido nas etapas de Análise, Projeto do Sistema, Projeto do Objeto e Implementação.

Em sua etapa de Análise, o método concentra-se em especificar o domínio de problemas e os requisitos do sistema prospectivo por meio do desenvolvimento iterativo de 3 modelos: de Objetos, que descreve as classes, seus relacionamentos, seus atributos e suas operações; Dinâmico, que descreve o comportamento de cada classe, e Funcional, que descreve as operações, as transformações dos dados, efetuadas pelo sistema.

A etapa de Projeto concentra-se na arquitetura global do sistema, a que se chega através da otimização e ao refinamento dos modelos produzidos na etapa anterior organiza as classes em subsistemas, define aspectos típicos de implementação (persistência de objetos, controle, prioridades, etc.).

Por sua vez, a etapa de Projeto do Objeto envolve projetar algoritmos para executar as operações, estabelecer os caminhos de acesso aos dados, projetar os controles, revisar as hierarquias de classes para ajustar o processo de herança , determinar a representação dos atributos de valor etc.

A etapa de Implementação é similar à que usualmente se adota para outros métodos.

Para ver el gráfico faltante haga click en el menú superior " Bajar trabajo"

Deve-se observar que esse método encontra-se em fase de unificação com o método Booch - seus idealizadores (Rambaugh e Grady Booch respectivamente), deram a público recentemente fins de 1995), para avaliação, um documento em que propõem critérios para a unificação desses métodos. Dentre esses critérios, está a adoção da Unified Modeling Language (UML), que também está sendo considerada por autores de outros métodos, como se verá à frente.

O método Visual Modeling Technique - VMT, foi desenvolvido por uma equipe de profissionais da IBM, e integra técnicas propostas por outros métodos, sendo voltado para programação visual, como o Visual Age. Este integração foi motivada por considerações acerca de pontos fracos de outros métodos e sobre os elementos de outros métodos que poderiam ser incorporados aos métodos já existentes - aqui há uma clara tentativa de transformar uma proposta própria em benchmark, característica dos grandes fornecedores de software e hardware; seu objetivo básico foi construir um método que aproveitasse pontos fortes ao mesmo tempo que compensasse pontos fracos de métodos OO existentes, além de e integrar programação visual ao processo de desenvolvimento de software OO. A IBM adotou OMT como estrutura básica para seu método; a ele foram somadas características de outros métodos, como os "use cases" do método OOSE, e outros.

O ciclo de desenvolvimento VMT, que deve ser acompanhado pela construção um dicionário de dados, inicia-se com o planejamento estratégico e a modelagem dos processos de negócios da organização, não só para o atendimento às necessidades do sistema em questão, mas de todas as áreas de negócio da organização, permitindo identificar e priorizar aplicações potenciais. Essa abordagem é característica da IBM, e retrata sua visão bastante comercial (e defensável) do processo de desenvolvimento de sistemas.

O processo de desenvolvimento, que ocorre após o planejamento estratégico, é interativo e incremental. Cada interação consiste em um período de planejamento, seguido por um período de produção e por um período de avaliação. Análise, projeto, implementação e teste ocorrem durante cada período de produção do processo de desenvolvimento. Os processos podem interagir para produzir um nova versão do sistema por meio de um acréscimo nos requisitos, refletindo-se em um acréscimo no sistema.

Para ver el gráfico faltante haga click en el menú superior " Bajar trabajo"

O método Semantic Object Modeling Approach - SOMA, desenvolvido por Ian Graham na Inglaterra, foi inicialmente elaborado como uma extensão do método Coad-Yourdon, incorporando propostas de outros métodos, e especialmente idéias e técnicas das áreas de Inteligência Artificial e Modelagem Semântica de Dados, de modo a permitir a especificação de Sistemas Baseados em Conhecimento. Com essas alterações, a conexão com o método Coad-Yourdon tomou-se tênue segundo Graham (1995).

Ainda segundo os defensores do método, o método previne que se evite que os desenvolvedores, mesmo de forma não intencional, adotem técnicas estruturadas, o que iria descaracterizar o sistema em desenvolvimento como OO, em especial diminuindo as possibilidades de reuso.

Dizem também que SOMA pode ser utilizado para a modelagem global da empresa e do ambiente em que opera, embora com uma abordagem diferente da utilizada quando o método é empregado com seus objetivos originais.

Este método, desenvolvido por pessoal vinculado à Hewlett-Packard (HP), foi lançado em 1992 e provê suporte para as vertentes técnica e gerencial do processo de desenvolvimento de software, que é dividido em três fases: Análise, Design e Implementação. O método inclusive define a ordem em que as coisas devem ser feitas dentro de cada fase e fornece critérios acerca de quando se deve iniciar uma nova fase, sendo por isso bastante "didático".

Outro ponto bastante interessante do método, é a existência de uma versão "lightweight" (peso leve) do mesmo, que pode ser utilizada quando não for necessária ou possível, (geralmente por questões de tempo) a utilização do método em sua plenitude - isso mostra uma interessante amarração do método ao "mundo real".

Fusão foi bastante influenciado pelo método Booch, especialmente naquilo que era considerado o ponto forte desse último: a documentação - alguns críticos do Booch condenavam a forma quase obssessiva com que esse tema era tratado no método, com muitos símbolos, diagramas, etc.

O método proporciona um caminho direto para a implementação a partir da definição de requisitos, suportando todos os conceitos fundamentais da tecnologia OO, e atua nas etapas de análise, projeto e implementação do desenvolvimento de software, não só OO como também convencional.

Uma peculiaridade deste método é o fato de não definir e nem associar métodos (aqui sim no sentido que OO da a esse termo) a classes na fase de análise - nessa fase, propõe que o desenvolvedor deva concentra-se em especificar as tarefas que o sistema deve executar (o que?), adiando a especificação da comunicação entre objetos (como?) para a fase de design. O método diz que nessa fase o desenvolvedor deve se concentrar na compreensão do domínio dos problemas e dos requisitos do sistema que está sendo considerado, gerando como produto final da fase um modelo completo desse sistema e de como ele deverá interagir com o mundo exterior.

Já para a fase de design, Fusão propõe uma abordagem sistemática para a produção de modelos abstratos, orientados a objetos e relacionados ao comportamento do sistema. Os modelos produzidos na fase de análise são refinados para que se atinja esse objetivo, permitindo que na fase de implementação os modelos sejam codificados em alguma linguagem. Nessa altura, a maioria das decisões acerca do projeto foram tomadas, mas ainda é necessário administrar alguns problemas, como performance, controle de qualidade, etc.

A HP e o Kings College, de Londres, estão lançando uma nova geração do Fusão, que incorporará a Unified Modeling Language (UML), que parece caminhar no sentido de se tornar um novo padrão na indústria.

Há uma grande preocupação com a praticidade do método, nessa sua nova geração - isso, aliás, já era uma preocupação, que inclusive gerou a versão "peso leve" do mesmo. Há também preocupação com administração de riscos (risk management), levando ao conceito de método "just enough" ("apenas o suficiente"), balanceando o risco e os esforços para atingimento dos objetivos do projeto e com sua aplicabilidade a qualquer tamanho de projeto (fator que freqüentemente desencoraja a aplicação de métodos para aplicações de pequeno porte e o que também acaba "contaminando" uma dada instalação, de forma a que progressivamente se abandona a adoção de métodos para todas as aplicações) - esperam os autores que essa abordagem encorage a adoção plena de técnicas de desenvolvimento OO.

Outra novidade é o suporte à arquitetura "n-tier", que também vem se popularizando rapidamente.

Quanto à UML, acredita-se deva ser a mesma observada com atenção - vem sendo "patrocinada" por HP, Oracle e Microsoft, o que aumenta suas chances de se tornar um padrão.

Finalizando, é importante tornar a observar que Fusão é também proposto como um método para desenvolvimento de sistemas convencionais, não voltados a objetos, o que pode fazer do mesmo a ponte que uma organização poderá utilizar em sua transição para o mundo OO.

Para ver el gráfico faltante haga click en el menú superior " Bajar trabajo"

Deixando agora o campo dos métodos, é oportuno tecer algumas considerações acerca das técnicas para desenvolvimento OO, técnicas estas que implícita ou explicitamente estão embutidas nos métodos de que se falou anteriormente. Serão considerações de ordem geral que visam enriquecer um pouco o assunto.

O mundo das técnicas orientadas a objeto executadas com ferramentas CASE baseadas em repositórios é diferente do mundo estruturado em que vivemos. O projetista pensa em termos de objetos e seu comportamento, o código é gerado, etc., de forma que a maioria dos sistemas pode ser construída sem se precisar pensar em loops, desvios e estruturas de controle do programa. O construtor do sistema aprende um "estilo" diferente de pensamento. Eventos causam mudanças no estado dos objetos - a maioria destas mudanças de estado requer pequenas estruturas de código, de forma que a codificação estará menos propensa a erros. Os tipos de objeto são construidos de tipos de objeto mais simples. Assim que os tipos de objeto funcionem bem, o projetista trata-os como uma caixa-preta, fazendo com que a engenharia de software assuma características da engenharia de hardware.

O contraste entre a orientação a processo e a OO pode ser resumido da seguinte maneira: o processamento de dados convencional concentra-se nos tipos de processos que manipulam tipos de dados. A OO concentra-se nos tipos de objetos cuja estrutura de dados pode ser manipulada somente com os métodos da classe de objetos. Ocorrem eventos que mudam o estado de um objeto. Cada mudança de estado comumente é simples para o programa, de forma que se pode dividir a programação em partes relativamente simples. Cada objeto, com efeito, executa uma função específica independentemente de outros objetos. Ele responde a mensagens, sem saber por que a mensagem foi enviada ou quais serão as conseqüências de sua ação. Uma vez que os objetos agem individualmente, cada classe pode ser mudada de uma forma amplamente independente de outras classes. Isso torna a classe, de certa forma, fácil de testar e modificar - isso implica em que a manutenção de sistemas orientados a objeto é muito mais fácil do que a manutenção de sistemas convencionais, como já foi dito anteriormente.

O mundo orientado a objeto é mais disciplinado do que as técnicas estruturadas convencionais. Ele leva a um mundo de classes reusáveis no qual grande parte do processo de desenvolvimento de software será a montagem de classes existentes bem comprovadas.

Independentemente do método que seja utilizado, a análise e o projeto OO têm diversas características importantes:

- Eles mudam a maneira como as pessoas pensam sobre os sistemas. A maneira OO de pensar é mais natural para a maioria das pessoas do que as técnicas de análise e projeto estruturados. Afinal de contas, o mundo consiste em objetos. Começa-se a aprender sobre eles na infância e descobre-se que têm certos tipos de comportamento. Se você sacudir um chocalho, ele faz barulho. Desde a mais tenra idade, categoriza-se objetos quando descobre-se seu comportamento. Usuários finais e homens de negócios pensam naturalmente em termos de objetos, eventos e acionadores. Pode-se criar diagramas OO com os quais eles podem interagir, ao passo que encontrarão dificuldades de relacionamento com diagramas de entidade-relacionamento, gráficos estruturados e diagramas de fluxo de dados.

- Sistemas freqüentemente podem ser construidos aproveitando-se objetos existentes. Isso leva a um elevado grau de reusabilidade, o que gera economia e abrevia o tempo de - essa talvez seja a razão principal pela qual empresas estão se interessando por OO.

- Os repositórios CASE deverão conter uma biblioteca sempre crescente de tipos de objetos, alguns comprados e outros construidos dentro da propria organização. Esses tipos de objeto provavelmente se tornarão poderosos à medida que crescerem em complexidade. A maioria de tais tipos de objeto será projetada, de forma que eles possam ser customizados de acordo com as necessidades de diferentes sistemas. Levando a um extremo, no futuro não se comprará mais sistemas prontos (pacotes), mas sim tipos de objetos.

As ferramentas OO permitem refinamento durante a implementação, o que leva a resultados finais muito melhores. Além disso, poder-se-á ter uma modelagem mais realista. A análise baseada em objetos modela a organização ou a área a ser atendida, de uma forma mais próxima da realidade do que o faz a análise convencional: a análise se traduz diretamente em projeto e implementação. Com as técnicas convencionais, o paradigma muda quando passamos de análise para projeto e de projeto para programação. Com as técnicas baseadas em objetos, análise, projeto e implementação usam o mesmo paradigma e o refinam sucessivamente.

As ferramentas CASE OO ainda deverão evoluir bastante - pode-se prever que elas usarão técnicas gráficas para projetar as classes e as interações entre elas e para adaptar objetos já existentes aos novos aplicativos. As ferramentas deverão facilitar a modelagem em termos de eventos, gatilhos, estado do objeto, e assim por diante. As ferramentas CASE deverão permitir que se gere código assim que as classes estejam definidas e deverão permitir que o projetista use e teste os métodos criados. As ferramentas deverão ser projetadas de forma a fomentar criatividade máxima e refinamento constante do projeto, durante a sua construção.

Há uma grande quantidade de linguagens de programação OO. Porém, por este trabalho estar voltado para os sistemas comerciais, apenas quatro serão mencionadas: C++, Smalltalk, Java e Eiffel (Montlick, 1997).

 Para ver el gráfico faltante haga click en el menú superior " Bajar trabajo"

C++

C++ é uma versão OO do C, com o qual é compatível - na realidade, pode ser visto como um superset do C - código em C pode ser incorporado a programas C++. É uma linguagem que produz programas rápidos, eficientes - ao custo de sacrificar alguma flexibilidade. C ++ tornou-se popular a ponto de fazer com que muitos novos compiladores C sejam na realidade C/C++. Observe-se que para tirar proveito de toda a potencialidade do C++, os programadores devem mudar seus esquemas correntes de raciocínio - é muito comum que usuários experimentados de C continuem usando na verdade seus esquemas mentais antigos, enquanto escrevendo código C++, o que faz com que os mesmos usem muito pouco do poder do C++ (Votre, 1998).

Para o público leigo, talvez a mais conhecida dessas linguagens seja o Java - apesar de a maioria sequer saber que ela é uma linguagem OO. A Internet e os browsers são a causa dessa popularidade, que, pelo que se pode sentir, fará com que Java vá se tornar o padrão de linguagem para a Internet, Intranets e Extranets. Java pode ser vista como uma mistura de C++ e Smalltalk - tem sintaxe similar à do C++, o que torna fácil seu uso para os que já conhecem essa última. Face ao seu êxito no mercado, muitas ferramentas auxiliares para desenvolvimento Java estão chegando ao mercado, o que num efeito "bola de neve" certamente tornará essa uma linguagem ainda mais popular.

É considerada uma linguagem totalmente OO - o próprio C++ faz algumas concessões em relação ao padrão OO, principalmente para diminuir o tamanho do código e obter maior velocidade de execução. Seus usuários dizem que permite a construção de programas mais rapidamente que C++, desde que o programador seja adequadamente treinado. Por ser totalmente OO, não permite que os programadores simplesmente se "aproximem" passo a passo, como os programadores C fazem em relação ao C++ - isso gera uma necessidade maior de treinamento, mais no que se refere a metodologia e técnicas OO do que em detalhes de programação (a sintaxe Smalltalk é mais simples que as do C ou C++). Diferentemente deste último, que tem um padrão sólido, vários dialetos Smalltalk estão disponíveis comercialmente, sendo os mais comuns VisualWorks, Smalltalk/V, Visual Smalltalk e VisualAge - esse último desenvolvido pela IBM, cuja força diante do mercado faz com que seu produto tenda a se destacar em relação aos demais.

Bertrand Meyer projetou Eiffel segundo estritos princípios OO, o que permite um alto grau de integração entre projeto e implementação. É uma linguagem considerada de mais fácil aprendizado e uso que C++, embora razões de mercado talvez justifiquem a maior popularidade deste último, embora esteja se observando um aumento no uso do Eiffel para o desenvolvimento de aplicações para a área financeira, em especial no Canadá e Estados Unidos.

Os Bancos de Dados baseados em objetos (OODB) surgiram no final dos anos 80, derivados da necessidade de suportar a programação baseada em objetos. Os programadores de Smalltalk e C++ precisavam de um depósito para o que eles chamavam de dados persistentes, ou seja, dados que permanecem após a conclusão de um processo. Os bancos de dados baseados em objetos tomaram-se importantes para certos tipos de aplicações com dados complexos, como por exemplo, CAD e BLOBs (grandes objetos binários, tais como imagens, som, vídeo e texto não-formatado) - tais aplicações geraram a necessidade de suportar diversos tipos de dados, e não apenas tabelas simples, colunas e linhas, como os bancos de dados relacionais - logo a seguir, os usuários compreenderam o valor das técnicas baseadas em objetos também para os sistemas ditos comerciais.

Na análise tradicional, os modelos conceituais, os modelos para projeto e os modelos para definição do banco de dados e o modelo de acesso ao banco são todos diferentes. Ao contrário, as técnicas baseadas em objetos usam os mesmos modelos conceituais para análise, projeto e construção.

A utilização de um mesmo modelo conceitual para todos os aspectos do desenvolvimento simplifica o mesmo e, se utilizado com ferramentas CASE-OO, melhora a comunicação entre os usuários, analistas e programadores e reduz a probabilidade de erros.

A análise tradicional utiliza os modelos de entidade-relacionamento e a decomposição funcional, e os analistas desenvolvem matrizes que mapeiam as funções e os tipos de entidade. O projeto tradicional utiliza uma visão diferente do mundo: diagramas de fluxos de dados, diagramas de estrutura e diagramas de ação. A programação utiliza outro modelo conceitual diferente: os programadores não pensam em termos de diagramas de fluxo de dados. A tecnologia dos bancos de dados tradicionais utiliza ainda um outro modelo conceitual, empregando tabelas, com a necessidade de fazer junções e projeções para acesso aos dados de que se necessita.

Em contraste com isto, os bancos de dados baseados em objetos foram projetados para serem integrados com as linguagens de programação baseadas em objetos, como C++ e Smalltalk. Eles utilizam o mesmo modelo de objetos. Não há obrigatoriamente necessidade de uma linguagem de banco de dados diferente da linguagem de programação. Por exemplo, com alguns bancos de dados baseados em objetos, a linguagem C++ é usada para todas as definições e manipulações do banco de dados. O mesmo modelo de objetos é também utilizado para a análise e para o projeto. O analista pode definir objetos e comportamentos de alto nível, que o programador estenderá para objetos de nível mais baixo, que herdarão as propriedades e o comportamento dos objetos superiores. Com boas ferramentas CASE-OO, tão logo os objetos sejam especificados na tela, o código pode ser gerado, a partir deles, por interpretação.

O projeto de bancos de dados relacionais é bem separado do projeto de programa. O banco de dados é um espaço à parte do espaço do programa. O programador tem que achar um meio de extrair e colocar dados nas tabelas. Com os bancos de dados baseados em objetos, o programador lida com objetos transientes e objetos persistentes, de forma uniforme. Os objetos persistentes fazem parte do banco de dados e, portanto, vê-se removida a fronteira conceitual entre programação e banco de dados. A análise, o projeto, a geração de código e a geração de banco de dados podem ser feitas, interativamente, por um único profissional, usando um modelo conceitual unificado, o que pode aumentar em muito a velocidade de desenvolvimento e manutenção de um sistema.

Alguns dos mais conhecidos gerenciadores de bancos de dados OO são: Gemstone, Itasca, Objectivity, Object Store, Ontos e Versant (Martin, 1993) - curiosamente, nenhum deles desenvolvido pelos grandes fabricantes de software que atuam por aqui.

Muitos recursos dos bancos de dados convencionais são importantes nos bancos de dados baseados em objeto, como por exemplo: bloqueio para controles de atualizações concorrentes, rotinas de recuperação, características de segurança e integridade dos dados, , ferramentas diversas, etc .

RDBs e OODBs têm alguns objetivos e características fundamentalmente diferentes, como já se viu até agora . Em alguns ambientes computacionais, predominam as necessidades que são melhor atendidas por RDBs - em outros ambientes computacionais, os bancos de dados relacionais não atendem adequadamente às necessidades, e os OODBs trazem maiores vantagens. Para se pesar as vantagens de uma tecnologia de bancos de dados sobre a outra, é preciso que se tenha compreensão do processo de desenvolvimento do aplicativo em questão. Este processo de desenvolvimento não é generalizado. Uma tecnologia de banco de dados não é capaz de satisfazer a todo o universo de aplicativos, e as necessidades dos aplicativos devem ser levadas em consideração quando se analisa as vantagens de uma tecnologia de banco de dados sobre a outra - pode-se mesmo dizer que isso é óbvio, apesar de muitos profissionais da área acreditarem no contrário, colocando a tecnologia disponível, especialmente quando se trata da "última moda", num verdadeiro altar.

Um objetivo básico dos bancos de dados relacionais é a independência dos dados. Os dados são separados dos processos e são normalizados. Portanto, eles podem ser usados para diferentes aplicativos, muitos dos quais podem não estar previstos quando as estruturas de dados são projetadas. Por outro lado, um objetivo básico dos bancos de dados baseados em objetos é o encapsulamento. Os dados são associados com uma classe específica que utiliza métodos específicos. O banco de dados armazena esses dados e os métodos. Os dados e os métodos são inseparáveis. Os dados são projetados para serem usados exclusivamente pela sua classe. As classes serão utilizadas em muitos aplicativos diferentes - temos independência de classes, e não meramente independência de dados.

Com um banco de dados relacional, os dados podem ser fisicamente reorganizados, sem alterar os programas do aplicativo que utiliza os dados. Com um banco de dados baseado em objetos, a classe pode ser reorganizada, sem interferir nos sistemas que a utilizam.

Os bancos de dados baseados em objetos podem ser construídos usando-se duas diferentes abordagens. A primeira utiliza um sistema gerenciador de bancos de dados relacional existente e acrescenta uma camada para processar as solicitações e armazenar os métodos e outras funcionalidades OO. Essa abordagem tem um mérito: preserva a estrutura física do atual banco de dados e pode ser implementada mais rapidamente do que se tudo fosse feito de novo desde o início - essa abordagem gera os chamados banco de dados objeto-relacionais. É muito interessante notar que os grandes fornecedores tem apresentado soluções nessa área, ao contrário do puro e simples lançamento de produtos "100% OO"; existem no mercado, entre outros: Cincom Systems /Total ORDB; Hewlett-Packard/Odapter; Informix/INFORMIX-Universal Server, IBM/DB2; Oracle/Oracle 8; Unisys/OSMOS, etc.

A segunda abordagem reconsidera a arquitetura dos sistemas de bancos de dados e produz uma nova arquitetura otimizada para atender às necessidades da tecnologia baseada em objetos - os que defendem essa abordagem dizem que dessa forma pode-se alcançar um desempenho muito melhor do que simplesmente estendendo a tecnologia relacional.

Alguns autores consideram que a primeira abordagem em realidade poderia ser subdividida em duas, mas no nível de detalhe em que este trabalho aborda o assunto, isso poderia ser encarado como mera tecnicidade.

Um dos principais objetivos da tecnologia tradicional de bancos de dados é a independência de dados. As estruturas de dados devem ser independentes dos processos que usam os dados. Os dados, então, podem ser empregados de qualquer maneira que o usuário deseje. Ao contrário, um dos principais objetivos da tecnologia baseada em objetos é o encapsulamento, o que significa que os dados só podem ser empregados com os métodos que fazem parte da respectiva classe. A intenção é que as classes sejam reutilizáveis e por essa razão, as classes devem ser livres de erros e só devem ser alteradas quando absolutamente necessário. A tecnologia das bases de dados tradicionais foi concebida para suportar processos que estão sujeitos a inúmeras modificações, e por isso a independência dos dados se fazia necessária. Os bancos de dados baseados em objetos suportam classes, algumas das quais quase nunca se modificam. As estruturas de dados em um banco de dados baseado em objetos devem ser bem otimizadas para suportar a classe na qual elas estão encapsuladas. Portanto, nos bancos de dados baseados em objetos, os objetivos são fundamentalmente distintos daqueles dos bancos de dados relacionais.

É importante observar que os OODB tem um desempenho muito superiores aos RDB quando se trata de aplicativos com muita associação de dados, pelas seguintes razões principais: os objetos se referem uns aos outros usando ponteiros, mecanismo de busca mais eficiente que o de junção; os OODB tornam os agrupamentos físicos mais eficientes, pois as estruturas relacionadas ficam próximas umas às outras no disco, o que reduz drasticamente o tempo de recuperação dos dados - com um banco de dados relacional, os objetos implementados são traduzidos em tabelas e ficam, tipicamente, espalhados, e finalmente, nos RDB há certos tipos de dados (multimídia é o exemplo clássico), que dificilmente podem ser representados como tabelas, o que dificulta sua recuperação.

Os OODBs não substituirão, completamente os RDBs - pelo menos até onde se pode vislumbrar. O objetivo dos bancos de dados relacionais de tornar os dados independentes dos aplicativos permanecerá importante para a maioria dos dados. Sempre necessitaremos organizar bancos de dados que possam ser utilizados de maneiras imprevisíveis. Em contraste, os bancos de dados baseados em objeto estabelecem que os dados só podem ser utilizados com os métodos definidos. Os bancos de dados relacionais e os bancos de dados baseados em objetos, portanto, atendem a necessidades distintas, e por isso prevê-se que, no futuro, a tecnologia de bancos de dados baseados em objetos não irá substituir, mas sim coexistir com, a tecnologia de bancos de dados relacionais - essa é inclusive a opinião de C. J. Date, o pai da tecnologia relacional, que acredita num "casamento entre a tecnologia relacional e as partes boas da tecnologia OO ".

Em termos de linguagens, pode-se esperar uma consolidação, ou uma penetração ainda maior de Java, C++ e SmallTalk, que deverão realmente continuar a ser as grandes ferramentas de programação OO.

Já quanto às metodologias (acima apresentadas como métodos), pode-se acreditar numa maior utilização das voltadas a objetos, principalmente por estarem ocorrendo investimentos de grandes fornecedores de software no desenvolvimento de metodologias "objeto-relacionais", no sentido de que podem ser aplicadas ao desenvolvimento de sistemas não 100% OO, mas que certamente serão uma das pontes que permitirão uma futura migração para o mundo OO, de forma gradual e não traumática.

Outro fator a ser considerado é a CORBA (Common Object Request Broker Architecture) que é um standard para objetos distribuidos desenvolvido Object Management Group (OMG). O OMG é um consórcio de desenvolvedores e usuários finais de software, e o objetivo é o desenvolvimento de produtos que suportem esses padrões. A idéia central é que os objetos, de forma transparente, peçam e recebam respostas, independentemente da linguagem em que foram os mesmos construídos, dos ambientes operacionais em que sejam processados, etc. CORBA vem ganhando espaço no mundo OO, e se seu sucesso se confirmar, certamente será um fator adicional para a afirmação da tecnologia OO.

Certamente alguns anos devem se passar antes que OO esteja consolidado entre os grandes sistemas corporativos (se isso vier a ocorrer) - no entanto, os profissionais da área certamente devem, no mínimo, desenvolverem esforços no sentido de se manterem informados acerca da tecnologia, se não por outro motivo, pelo menos para serem considerados profissionais "up to date"...

- Coad, Peter e Yourdon, E - Object-Oriented Analysis, Yourdon Press, 1991

- Giorno, Fernando A. C. - Tecnologia de Orientação a Objetos, U. Mackenzie, 1997

- Graham, Ian - Migrating to Object Technology, Addison-Wesley, 1995

- Hirama, Kechi - Notas de aula, Universidade Mackenzie, 1998

- Martin, James - Princípios de Análise e Projeto Baseados em Objetos, Campus, 1994

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

- Montlick, Terry - What is OO Software?, Software Design Consultants (material capturado na Internet em 11/03/97, em http://www.soft-design.com/softinfo/objects.html) , 1997

- Votre, Vilmar Pedro - C++ Explicado e Aplicado, ZeroErro Engenharia de Software, 1998 e Notas de aula, Universidade Mackenzie, 1998.

O presente trabalho visa apresentar os conceitos básicos inerentes à Orientação a Objetos (OO), de forma a permitir o entendimento dos princípios que devem ser observados para o desenvolvimento de sistemas nesse ambiente - neste trabalho considerou-se principalmente os sistemas ditos, em nosso ambiente, "comerciais" ou "aplicativos". Essa tecnologia oferece uma nova e poderosa forma de se desenvolver software. Objetos podem ser encarados como "caixas pretas", que enviam e recebem mensagens. Essa abordagem, quando adequadamente usada, acelera o processo de desenvolvimento e manutenção de sistemas, inclusive por permitir o reuso de código. É importante mencionar que a OO exige uma sensível alteração na forma de raciocínio dos desenvolvedores, não só no que tange à estrutura dos sistemas, como também no próprio trabalho de programação.

Orientação a Objetos, OO, Objeto, Tipos de Objeto, Classe, Métodos, Encapsulamento, Mensagens, Herança, Polimorfismo

Trabajo enviado por:
Vivaldo José Breternitz
Mestre em Engenharia Elétrica
Professor universitário e executivo de instituição financeira
bacor199[arroba]banespa.com.br