Banco de Dados Orientado a Objetos pt 3

Modelagem e Projeto para BDOO´s

ANÁLISE ORIENTADA A OBJETOS

Diretamente derivada dos conceitos da programação e do projeto orientado a objeto, a análise orientada a objeto é certamente a mais nova das abordagens de análise de sistemas. Baseada na decomposição do sistema de acordo com os objetos ( entidades de dados ) manipulados por este, esta abordagem oferece como principais benefícios os seguintes fatores:
a) Mantém a modelagem do sistema e, conseqüentemente, a automação do mesmo o mais próximo possível de uma visão conceitual do mundo real.
b) Baseia a decomposição e modelagem do sistema nos dados, que é o elemento mais estável de todos aqueles que compõem um sistema de informação.
c) De todas as abordagens de análise conhecidas até o momento, a análise orientada a objetos é, certamente, a que oferece maior transparência na passagem da análise ( modelo essencial ) para o projeto ( modelo de implementação ). Isso porque, se for seguida a técnica de projeto orientado a objeto, a passagem de um modelo para o outro será feita através da introdução de detalhes, não.requerendo uma reorganização do modelo, como é o caso na passagem de análise estruturada para o projeto estruturado.
É interessante que façamos a definição de Classes e Objetos, (9):
a) Objeto: "Uma abstração de alguma coisa em um domínio de problema, refletindo as capacidades de um sistema de manter informações sobre sí, interagir com sí, ou ambos, um encapsulamento de Valores, de Atributos e seus Serviços exclusivos".
b) Classe: "Uma coleção de objetos que podem ser descritos com o mesmo Atributo ou Serviço".

---

Análise Orientada a Objeto, uma abordagem passo a passo
Pode-se perguntar: Porque não usar as técnicas de análise já estabelecidas, como a análise estruturada. A evolução da análise estruturada nos mostra que há uma série de desenvolvimentos, a programação estruturada é precedida pelo projeto estruturado, que por sua vez é precedido pela análise estruturada. A análise e o projeto estruturado são construídos no topo de noções básicas da programação estruturada tradicional, incluindo a separação de dados e processos.
Algumas noções básicas de programação orientada a objetos são diferentes da programação tradicional.
Por instância, objetos encapsulam ambos comportamento e estado, enquanto as linguagens tradicionais de programação deliberadamente mantém uma separação.
A seguir apresentaremos uma abordagem de desenvolvimento de sistemas orientados a objetos, numa abordagem passo a passo, (3):
OBA (Object Behavior Analysis) provém um modelo conceitual para um primeiro estágio na criação de uma aplicação orientada a objeto. Usando esta abordagem como um passo positivo no processo de construção, com sucesso, de um sistema flexível orientado a objeto.
A OBA tenta responder questões que a análise tradicional de sistemas não consegue responder, e isto de uma maneira natural, encorajando a interação entre as diversas fases do desenvolvimento e com o auxílio da prototipação rápida especialmente nas fases de análise e projeto.
Uma implicação desta abordagem é que analisar, projetar e implementar, não do tipo, "vamos fazer certo da primeira vez". Na prática geralmente isso é impossivel, ter a informação que se necessita para uma análise completa, muito menos interpretar e representar todas as coisas corretamente sem interações. Interações controladas contribuem para clarificar e tornar mais completas as especificações e projeto.
OBA consiste de uma compreenção da aplicação e identificação 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 aplicação fará, primeiro entrevista-se o usuário para a aplicação pretendidada observando então a ação para ver o que ela fará, quem ou o quê interagirá com o sistema , em que ordem ocorrerá, e quais as diferentes ações tomadas. O ponto principal é uma lista dos desejos necessários para o sistema analisado, o mais alto nível do comportamento define as responsabilidades do sistema.
A saída desta etapa é uma lista dos comportamentos desejados do sistema e uma lista de suas propriedades visíveis,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.
Cartões de modelagem, usados nesta etapa, são pequenos cartões indexados com os termos:"nome", "responsabilidade" e "colaboradores",escrito neles. Nesses cartões escreve-se o comportamento do sistema (responsabilidades), o que ou quem é responsável por um comportamento em particular, tão bem quanto para padrões de comportamento (nome) e quem ou o que este agente responsável interage (colaboradores).
Os objetos de aplicação são compostos desses objetos concretos, conceitos, processos e eventos que exibem comportamentos significativos.
A saída da etapa 2 é uma lista de objetos, os quais relatados em grupos de comportamento e propriedades visíveis. Pode ser necessário 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, classificação significa agrupar objetos de acordo com alguma similaridade de comportamento (função) e estado (forma). Classificar objetos primariamente pelo comportamento é a chave da OBA. Para isso, deve ser visto comportamentos similares em diferentes objetos.
A saída da etapa 3 é um diagrama de relacionamento hierárquico entre os objetos, baseados na forma abstrata usando o critério de comportamento similar. Uma importante tarefa no mundo da orientação a objeto é distinguir o abstrato a partir do específico. OBA inicia o projeto com o pé direito, por auxiliar na localização de conceitos que serão usados para ambas classes, abstrato e concreto durante o projeto e implementação.
d) Etapa 4: Identificando os relacionamentos
A etapa 4 envolve um desenho de um esboço preliminar dos objetos em relação uns com os outros. Usando esse esboço, tão bem quanto um "script" e os cartões 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 descrição,a mais clara possível, em termos de linguagem natural, dos relacionamentos entre os objetos. Então simplifica-se essas descrições de linguagens. De outro modo, reduzindo uma descrição simplificada em linguagem natural para os subconjuntos dos relacionamentos implementáveis em OOL, é parte da fase de projeto e não da fase de análise.
e) Etapa 5: Modelando o Processo
Necessita-se para determinar quais objetos iniciam atividades e identificar qual a sequencia das atividades, para isso são usados os "scripts" desenvolvidos na etapa 1 para iniciar o modelo de aplicação.
Pode-se especificar o ciclo de vida dos objetos e seus "status" em diferentes partes do ciclo.
f) A Análise Final:
O resultado da OBA são as especificações das necessidades, escrita em termos de comportamento requerido, que delinea os objetos primários como eles são organizados. Esta especificação inclui objetos superordenados a partir de um agrupamento por comportamento e objetos subordenados.
O comportamento primário e estado da cada objeto é listado, bem como seus relacionamentos dos objetos e as sequências de atividades. Os "scripts" produzidos na OBA são especialmente usados no detalhamento de como trabalhará a interface com o usuário.
Com o uso da OBA para análise de um sistema orientado a objeto, obtém-se uma especificação do comportamento que enfatiza os aspectos da alta reusabilidade do sistema, que é, os protocolos de comportamento e os agrupamentos hierárquicos dos objetos de acordo com o protocolo.
Uma análise cuidadosa, focando as abstrações comportamentais, promovem uma redução no código,por calçar o caminho para uma boa construção hierárquica e hereditariedade e o seu uso prudente pode ajudar a produzir uma clara e compreensível estrutura de aplicação orientada a objeto.

PROJETO ORIENTADO A OBJETOS (OOD)

Uma vez construido o Modelo Essencial do sistema, necessitamos construir o seu Modelo de Implementação, ou seja, o seu projeto físico. Para essa fase do ciclo de vida do sistema, assim como para as demais, existem diversos métodos 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 modularização.
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 não únicamente no produto final.
c) Aumentar a manutenabilidade por separar intrinsicamente partes voláteis do sistema daquelas que são estáveis.
Já no Projeto Orientado a Objetos, temos alguns benefícios tais como:
a) A arquitetura do sistema é desenvolvida a partir dos objetos por ele manipulados. Em um sistema de informações, os objetos correspondem às entidades de dados utilizadas.
b) Para cada objeto são definidas as funções ou serviços que deverá permitir, direta ou indiretamente, o atendimento aos requisitos estabelecidos. Todos os serviços correspondentes a um mesmo objeto devem ser integrados e estruturados em um único módulo, estabelecendo-se assim a funcionalidade do objeto.
c) Um objeto, através de seus serviços, pode colaborar com outros objetos. Esta colaboração se processa através da troca de mensagens entre os objetos cliente e servidor.
a) O objeto pode também herdar algumas funcionalidades correspondentes a seu objeto "pai", o qual deve representar, conceitualmente, uma entidade mais genérica.
Entre as principais vantagens oferecidas pelo método do projeto orientado por objeto temos:
a) Fornece regras precisas para a modularização do sistema.
b) Desenvolvimento de uma arquitetura mais estável, uma vez que se estrutura com base no modelo de dados utilizado, o qual apresenta pouca vulnerabilidade a mudanças na funcionalidade do sistema.
c) Alto grau de reusabilidade das rotinas desenvolvidas.
d) Maior facilidade de transição da fase de análise para a fase de projeto.

PROTOTIPAÇÃO ORIENTADA A OBJETO

A prototipação orientada a objeto (8) é baseada em abstração de dados e hereditariedade. Objetos encapsulam o dado em sistemas de prototipação servindo como base para o projeto e a implementação. Desde que o dado na implementação é geralmente mais estável que as etapas do processo, isto conduz a descrição do sistema que é mais fácil para ser modificado que através da abstração procedural. Hereditariedade ajuda a reduzir o trabalho envolvido na construção do sistema por inclusão de aspectos comuns de código em diferentes contextos sem a repetição explícita de detalhes. Objetos também provem componentes convenientes para código reusavel, processamento paralelo e controle de versões, desse modo, as abordagens orientadas a objeto fazem protótipos mais flexíveis e facilmente automatizaveis.
O OOD e a prototipação (9) tem vínculos em comum pois; é uma maneira natural de trabalhar, experimenta-se a interface humana, para a clarificação dos requisitos procurados, para a praticidade do projeto, para a entrega, funcionalmente, tão cedo quanto possível.

CONCLUSÕES

A orientação a objetos (2) é uma mudança cultural, muito mais do que uma mudança tecnológica, ela é um paradigma, uma revolução industrial do software baseada na reusabilidade e intercambialidade entre as partes que alterará o universo de software tão fortemente quanto a revolução industrial alterou a manufatura.
O paradigma muda das linguagens procedurais para as linguagens orientadas a objeto, com o direcionamento para ambientes de alto nível como o Smalltalk.
Do mesmo modo as metodologias mudam das estruturadas para as orientadas a objetos, não podendo haver uma continuidade nas técnicas estruturadas existentes, confirmando (1), "os métodos estruturados Não podem ser objetificados".
Grandes organizações mudam lentamente, velhas metodologias, quando há, são difíceis de mudar o no entanto se requer uma mudança radical na maneira de como sistemas serão desenvolvidos a partir de agora, isto é, orientados a objeto e com auxílio de CASE.
Os anos 90 serão de gradual aceitação da orientação a objetos e não podendo tomar por base antigas metodologias.
Orientação a objetos promete muito mais do que "apontar e clicar" a interface de janelas, e com a popularização das arquiteturas abertas, redes distribuídas, CASE e ambientes gráficos o seu destino está definido.