Autor: Dante Carlos Antunes


A OOA (object – Oriented Analysis) faz parte do universo das tecnologias, orientadas a objetos, junto com a OOD (Object-Oriented Design) e a OOP ( Object-Oriented Programming).

Na perspectiva do nosso Roteiro de Análise e Construção de Sistemas (RACS), faríamos a seguinte associação com as tecnologias orientadas a objetos:

                            Fases do RACS

                            Planejamento Global

                            ---------- Investigação da Situação-Problema

OOA ---------------------------> Modelagem da Essência da Solução

OOD ---------------------------> Projeto Físico do Sistema

OOP ---------------------------> Construção do Sistema

                            Implantação do Sistemas

                            Avaliação Global

A Análise Orientada a Objetos parte do paradigma de que o mundo é formado de objetos e de que desenvolver um sistema nada mais é que criar uma simulação dos objetos e de seu comportamento.

Um objeto para a OOA, segundo Coad e Yourdon, é uma “abstração de alguma coisa em um domínio de problemas, exprimindo as capacidades de um sistema de manter informações sobre ela, interagir com ela, ou ambos. Um objeto também pode ser visto como um encapsulamento de valores de Atributos e de seus Serviços exclusivos”:

Ao conjunto de objetos que apresenta um grupo comum de atributos e serviços, damos o nome de CLASSE. Para facilitar o entendimento, podemos fazer uma comparação com o Modelo de Entidades-Relacionamentos:

MER                                    OOA

Entidade ------------------> Classe

Ocorrência ----------------> Objeto

Atributo -------------------> Atributo

Por exemplo, dentro de um sistema de cadastramento de veículos teríamos entre outras, a classe VEÍCULOS que conteria um conjunto de registros ou ocorrência, um para cada veículo cadastrado. Cada um destes registros representa um OBJETO para a OOA.

SE aprofundássemos a nossa análise, descobriríamos que existem tipos diferentes de veículos tais como: veículo-caminhão, veículo-de-passeio e veículo-ônibus. Estaríamos diante das sub-classes da classe veículo. É interessante notar que, embora existam atributos e comportamentos específicos a cada uma das sub-classes, também existem atributos e comportamentos comuns entre elas, isto é, as sub-classes herdam características das classes hierarquicamente superiores. Este aspecto – HERANÇA – é profundamente explorado e é uma das razões de ser das tecnologias orientadas a objeto.

Pelo que foi exposto até agora parece não haver muita diferença entre a Análise Orientada a Objetos e a Modelagem Entidade-Relacionamento, mas esta diferença existe e é fundamental.

Na OOA, guardamos nas classes de objeto mais que simplesmente os dados ou atributos; guardamos também, os serviços exclusivos sobre estes dados.

No exemplo da classe VEÍCULOS, teríamos os atributos Placa, Proprietário, Data-Compra, Potência, Marca, Cor etc. E os serviços Incluir-Veículo, Calcular-idade-Veículo, Deletar-Veículo, entre outros.

Para a sub-classe VEÍCULOS – CAMINHÃO, além do que foi herdado, teríamos os atributos Capacidade-de-cargas e Distância-entre-Eixos, e mais os serviços de Calcular-Tempo-Vida-Útil e Reservar-Espaço-para-frete.

Na OOA, só é possível incluir, alterar, acessar e excluir objetos de uma classe através de um acionamento de seus serviços exclusivos. Trata-se do conceito de ENCAPSULAMENTO, que dá a uma classe de objetos, características de “caixa-preta”. Para acionar este serviços, o usuário ou outro objeto deve emitir uma mensagem para o objeto receptor, indicando qual função deve ser executada e quais os argumentos servirão de parâmetros para esta função. Nas linguagens tradicionais, não orientadas a objetos, seria algo parecido com acionar uma subrotina via comando CALL .

Coad e Yourdon, no seu livro Análise Baseada Em Objetos, indicam uma série de atividades (não necessariamente executadas em seqüência) que o analista deve executar para aplicar OOA:

* Localização de classes e Objetos
* Identificação de Estruturas (Generalização-Especialização e Todo-Parte)
* Identificação de Assuntos (Agrupamento de Classes de Objetos afins para dividir a complexidade)
* Definição de Atributos
* Definição de Serviços

Nos métodos estruturados tradicionais de análise de sistemas, ou abordávamos os problemas através dos processos, ou através dos dados; era aquele velho e eterno conflito, embora sempre tenham havido tentativas isoladas de mesclar as duas visões. A Análise Orientada a Objetos, embora precise ainda evoluir muito, engloba naturalmente os dois enfoques, à medida que empacota numa mesma classe de objetos os seus dados e o seu comportamento (serviços ou processos).

Vai demorar algum tempo ainda para que assimilemos completamente os novos conceitos introduzidos, pelas tecnologias orientadas a objetos, pois de certa maneira elas revolucionam a nossa maneira de ver as coisas. Mas está muito claro que elas serão o estado da arte dos anos 90 na engenharia de software.

Esta tendências se tornará irreversível quando os fabricantes tradicionais de software disponibilizarem linguagens e gerenciadores de banco de dados, orientados a objetos, poderosos o suficiente, para atender grandes aplicações com eficiência. Somado a isto, está a grande capacidade que a orientação a objetos tem de atender perfeitamente às diretrizes de reutilização recomendadas pela reengenharia de sistemas, aspecto vital para o aumento da produtividade no desenvolvimento de software daqui para a frente.

Cabe a nós, analistas e programadores, ficarmos atentos as avanços desta nova abordagem no desenvolvimento de sistemas, sob pena de ficarmos ultrapassados.