OOA – Object-Oriented Analysis

A programação orientada a objeto, assim como outras metodologias de programação, tem como função representar problemas do domínio do mundo real e encontrar soluções através da simulação em programas. As diferenças com as metodologias estruturais basicamente estão em três conceitos de programação: abstração, ocultamento de informações e modularidade, todas obtidas sem complexidade e compromisso através da programação orientada a objeto.

1.Origens da Programação Orientada a Objeto

Objetos e operações não são novos conceitos de programação, mas a programação orientada a objetos sim. Nos início da era da computação, linguagens assembly permitiram que programadores usassem instruções para manipular dados com nível de abstração muito baixo. Linguagens de alto nível permitiam que simulações pudessem ser realizadas através do modelamento por dados pré-definidos e estruturas de controle que fossem disponíveis como parte da linguagem. Os conceitos de programação desenvolveram-se através do refinamento de função passo-a-passo, modularidade procedural e da programação estruturada. O rápido desenvolvimento das linguagens de programação acabaram mostrando a necessidade de novos conceitos de programação encontrados na programação orientada a objeto, envolvendo a enfatização da abstração dos dados e o modelamento através de um conjunto de objetos de dados ao qual um conjunto de operações estava associado. As facilidades implícitas na programação orientada a objeto indicam que seus métodos tornem-se possivelmente predominantes para o milênio.

2. Conceitos

Vários conceitos de análise orientada a objeto já foram apresentados pelo seminário de programação orientada a objeto. Aqui serão introduzidos novos conceitos importantes que utilizam as terminologias já apresentadas. Recomenda-se a análise do material anteriormente apresentado.

2.1. Objetos, operações e mensagens

Para o entendimento da análise orientada a objeto é preciso estabelecer um mecanismo para (1) a representação da estrutura de dados, (2) a especificação do processo e (3) o procedimento de invocação.

Um objeto é um componente do mundo real que é mapeado para o domínio do programa, no contexto de sistemas computacionais ele é um produtor ou consumidor de informações ou um item de informação. Quando um objeto é mapeado para o programa ele consiste de uma estrutura de dados particulares e processos, chamada de operações, que pode transformar-se numa legítima estrutura de dados. Operações contêm controles e construções procedurais que podem ser invocadas por uma mensagem – um pedido para que o objeto execute uma de suas operações.

O objeto possui também uma parte compartilhada que é sua interface. Mensagens circulam através da interface e especificam que operação do objeto é desejada, mas não como deve ser realizada. O objeto que recebe a mensagem determina como a operação desejada deve ser implementada. Isso é chamado de ocultamento de informações, detalhes de implementação que são escondidos de todos os elementos do programa fora dos objetos. Objetos e suas operações promovem inerente modularidade, elementos de programação (dados e processos) são agrupados juntos com um mecanismo muito bem definido de interface (mensagens).

2.2. Procedimentos de programação

Cinco critérios de avaliação da capacidade de um método de programação para atingir a modularidade e relatar a orientação a objeto são sugeridos (Bertrand Meyer):

· “Decomposability”– a facilidade com que um método ajuda o projetista a decompor um grande problema em pequenos problemas que se relacionam e são fáceis de resolver.

· “Composability” – o grau que um método de projeto assegura que componentes de programação (módulos), uma vez projetados e construídos, possam ser reutilizados para criar outros sistemas.

· “Understandability” – a facilidade com que um componente de programação possa ser entendido sem referências à outras informações ou outros módulos.

· “Continuity” – a habilidade de fazer pequenas alterações em um programa e ter essas alterações manifestadas por si só em correspondentes alterações em apenas um ou em poucos módulos.

· “Protection” – uma característica de arquitetura que irá reduzir a propagação de efeitos colaterais se um erro realmente ocorrer em um dado módulo.

A partir destes critérios são sugeridos cinco princípios básicos de projeto que podem ser derivados de arquitetura modular: (1) unidades modulares de linguística, (2) poucas interfaces, (3) pequenas interfaces, (4) interfaces explícitas, (5) ocultamento de informações.

2.3. Classes, instâncias e inerências

Muitos objetos do mundo físico possuem características razoavelmente similares e realizam operações razoavelmente similares, podendo ser inclusos em várias classes, cada uma tendo seus atributos em comum e que realizam operações comuns. Quando um objeto pertence a uma classe, pode-se saber sobre seus atributos e operações que realiza mesmo que não se possa saber quais são suas funções detalhadas. Todos os objetos são membros de uma classe maior e possui inerente uma estrutura de dados particulares e operações que haviam sido definidos para essa classe. Um objeto é, portanto, uma instância de uma classe maior, e implica, portanto, na inerência de todos os atributos da classe.

2.4. Descrição de objetos

A descrição de projeto de um objeto (uma instância de uma classe ou subclasse) pode ter uma de duas formas:

· Uma descrição de protocolo que estabiliza uma interface de um objeto através da definição de cada mensagem que o objeto pode receber e a operação relacionada que aquele objeto realiza quando ele recebe uma mensagem.

· Uma descrição de implementação que mostra detalhes da implementação para cada operação envolvida por uma mensagem que é passada para um objeto. Detalhes de implementação incluem informações a respeito de partes particulares do objeto, detalhes internos da estrutura de dados e detalhes procedurais que descrevem operações.

O usuário de um serviço providenciado por um objeto deve estar familiarizado com o protocolo que invoca o serviço, especificado pelo o que é desejado. O fornecedor do serviço (o próprio objeto) deve estar consciente de como o serviço deve ser executado para o usuário, isto é, detalhes de implementação. Esse conceito é o de encapsulamento.

3. Métodos de programação orientada a objeto

No material anterior foram apresentados os tópicos de análise orientada a objeto, que definem o trabalho inicial na elaboração de um programa orientado a objeto. A distinção entre análise orientada a objeto e programação orientada a objeto é bastante sutil. Em essência a análise é uma atividade de classificação. A programação implementa através da continuação dos passos da análise:

· Refinamento do trabalho durante a análise, procurando por subclasses, característica de mensagens e outros detalhes de elaboração.

· Representa a(s) estrutura(s) de dados associada(s) com atributos do objeto.

· Representa o detalhe procedural associado com cada operação.

3.1. Definição de classes e objetos

Na etapa de análise definimos o problema e selecionamos então os objetos, definimos suas classes, operações e mensagens, como já foi mencionado no material anterior.

3.2. Refinamento de operações

Uma vez que os objetos do espaço soluções tenham sido identificados, o projetista seleciona o conjunto de operações que agem sobre o objeto. Operações são identificadas através de exame de todos os estados verbais na estratégia informal. Apesar dos diferentes tipos de operações existentes, podemos dividir em três grandes categorias: (1) operações que manipulam dados de alguma forma, (2) operações que realizam uma computação, (3) operações que monitoram um objeto para a ocorrência de um evento de controle.

Um programa é estabelecido através dos procedimentos de análise, mas é na programação que ele é refinado em um maior número de operações específicas que são exigidas para configurar o sistema.

3.3. Componentes e interfaces do programa

Um importante aspecto da qualidade no projeto de programas é modularidade, que é a especificação dos componentes do programa (módulos) que são combinados para formar o programa completo. A abordagem orientada a objeto define o objeto como um componente do programa que está ligado por si só a outros componentes. Mas definir objetos e operações não é suficiente. Durante o projeto deve-se identificar também as interfaces que existem entre objetos e a estrutura de objetos como um todo.

Apesar do componente de um programa ser uma abstração de projeto, ele deve ser apresentado no contexto da linguagem de programação com o qual o projeto será implantado. As partes de implementação de um componente indicam todos os objetos de dados e as operações que agem sobre ele. A parte particular do componente providencia detalhes adicionais ocultos da estrutura de dados e processamento. O primeiro componente do programa a ser identificado deveria ser o módulo de mais alto nível da qual todo o processamento se origina e todas as estruturas de dados se desenvolvem. Algumas partes particulares dos objetos de dados ou detalhes das operações não precisam ser especificados no momento. Estes detalhes de implementação podem ser considerados posteriormente.

4. Representação para programação orientada a objeto

As notações apresentadas no material anterior continuam sendo válidas e são utilizadas no desenvolvimento do projeto de programas, no entanto algumas notações adicionais são propostas e às vezes encontradas no setor da indústria.

4.1. Relações entre classes e objetos

Como uma alternativa para a notação sugerida no material anterior, temos diagramas que explicitam classes e objetos e as relações entre eles. O diagrama de classes indica o arranjo de classes para um sistema. Inerência é indicada através de símbolos de flechas e linhas duplas de conexão mostram o que uma classe usa de informações contidas em outras classes. Os símbolos no final da notação de linha dupla indicam a contagem de instâncias utilizadas.

4.2. Modulação do programa

A notação para módulos na programação orientada a objeto é indicada por locação de classes e objetos para componentes físicos do programa e assim representam a visão implementada da arquitetura do programa. O diagrama modular representa um componente do programa (objeto) como uma caixa que pode ser dividida em partes de especificação (visível por fora) e uma parte particular (também chamada parte de um corpo) que é oculta por fora. Objetos de dados são representados por uma oval alongada enquanto operações que agem sobre os objetos são indicados por retângulos.

5. Implementação de detalhes de programação

As etapas de detalhes de programação orientada a objeto são similares sobre vários aspectos a qualquer metodologia de detalhes de programação de projetos de programas. Interfaces são descritas com detalhes, estruturas de dados são refinadas e especificadas, algoritmos são elaborados para uma unidade do programa usando conceitos fundamentais de programação como refinamento passo-a-passo e programação estrutural. A diferença principal para a programação orientada a objeto é que o processo descrito na seção anterior pode ser aplicado recursivamente a qualquer momento. De fato, definições recursivas de estratégias de soluções são essenciais para alcançar um nível de projeto e abstração de dados da qual detalhes de implementação podem ser derivados.

6. Estratégias alternativas de programação

Uma abordagem para programação orientada a objeto utilizando linguagens de programação específicas (que suportam diretamente abstração, inerência, mensagens e outros conceitos de orientação a objeto) pode ser realizada através das seguintes etapas:

1. Identificação da abstração de dados para cada subsistema

2. Identificação dos atributos de cada abstração

3. Identificação das operações para cada abstração

4. Identificação da comunicação entre objetos

5. Teste do projeto de cenários

6. Aplicação de inerências onde for apropriado.

7. Integração com análise e programação estrutural

Devido ao amplo uso de análise estrutural e projetos estruturados e o intenso interesse na abordagem orientada a objeto uma questão natural surge: podem os dois tipos de análise e estratégia de projetos serem integrados numa abordagem comum? Não há ainda uma resposta definitiva.

As chaves dos elementos de análise e projeto estruturados são os modelos de fluxo, dicionários de dados, controle de especificação, especificação de processos e o diagrama de relação de entidades para modelamento de dados. À primeira vista, o diagrama de fluxo de dados parece ter boa conectividade entre análise orientada a objeto e análise estrutural. Mas isto não ocorre na prática.

O problema reside na terminologia mais tradicional para descrições da indústria – processamento de dados. Acostuma-se a acreditar que o processamento e dados são dois pontos distintos que são fundamentais, de uma certa maneira, para os negócios. Programação orientada a objeto proporciona meios para a ruptura das partições entre processo e dados. E assim, qualidade de programas pode ser evoluída.