Análise e Desenho Orientados por Objetos (1/4)

By: Adail Retamal

Abstract: Parte 1 de 4. Princípios, conceitos e técnicas para tirar o máximo de benefício da tecnologia de objetos. Introdução à orientação por objetos.

Em outros artigos mostrei como o paradigma de programação orientada por objetos (OOP – Object-Oriented Programming) pode significar melhor organização, planejamento, desenvolvimento e manutenção de uma aplicação. Porém, programar OO sem um desenho (design) OO pode ser uma tarefa difícil, levando a uma implementação deficiente, sem os benefícios de médio e longo prazo esperados da OOP. E para obter um bom desenho OO (OOD - Object-Oriented Design) precisamos de um método de análise OO (OOA - Object-Oriented Analysis). Sem uma visão de mundo OO, derivar um projeto OO para uma boa implementação OO torna-se um enorme desafio, senão inútil. Assim, nas próximas edições, mostrarei os princípios fundamentais da OOA e OOD (ou OOAD - Object-Oriented Analysis and Design), que naturalmente levam a uma boa OOP.

O material apresentado será uma síntese de diversas metodologias, mas há muito tempo tenho usado preferencialmente a abordagem sugerida pelo Dr. Peter Coad, a quem tenho muito que agradecer, tanto pela OOAD quanto pela metodologia ágil conhecida como FDD (Feature-Driven Development).

    Antes da Análise OO

A visão de mundo orientada por objetos oferece um excelente paradigma para o entendimento de um determinado contexto ou situação, denominado domínio do problema. Anteriormente, dois outros enfoques eram muito comuns: o enfoque funcional e o enfoque de dados.

No enfoque funcional decompõe-se o domínio do problema de acordo com suas funções, algoritmos e procedimentos. Os dados recebem um tratamento secundário, às vezes em forma de repositórios (arquivos), outras vezes simplesmente figurando entre as operações. Dois diagramas são comumente usados para modelagem:

  • DHF (Diagrama Hierárquico de Funções): mostra como os módulos estão organizados e conectados, seguindo uma hierarquia arquitetural e funcional;
  • Fluxograma: demonstra de forma gráfica o fluxo de operações de um determinado algoritmo.

No enfoque de dados há uma enorme preocupação em mostrar o que acontece com os dados na medida em que estes transitam entre as diversas “bolhas” de processamento. As funções, quando necessário, são explicitadas separadamente. Os dois diagramas mais usados são:

  • DFD (Diagrama de Fluxo de Dados): mostra as bolhas de processamento, os dutos de dados e os repositórios, normalmente seguindo um esquema de refinamento, onde as bolhas principais são detalhadas (“explodidas”) em outros diagramas, formando uma hierarquia de diagramas;
  • DER (Diagrama de Entidade-Relacionamento): demonstra a estrutura das entidades presentes no domínio do problema e os relacionamentos existentes entre elas. Geralmente é usado para derivar o script para um banco de dados relacional.

    Um pouco de história

É interessante notar que, historicamente, dados e funções sempre foram considerados separadamente, desde a arquitetura do hardware até muitas linguagens de programação não-OO. No hardware, foi o húngaro Johann Louis von Neumann, por volta de 1945, quem sugeriu que tanto os dados quanto os programas fossem armazenados na mesma memória. Os computadores que usamos hoje ainda usam muito da “arquitetura von Neumann” (pronuncia-se algo como “fon nóiman”).

No mundo do software, os conceitos OO já começaram a aparecer por volta de 1959. Alguns anos depois, a linguagem Simula-67 apareceu justamente para facilitar simulações, oferecendo várias características de orientação por objetos. Smalltalk foi desenvolvida nas décadas de 1970 e 1980 e é considerada uma das mais puras e completas linguagens OO. C++ apareceu na década de 1980, e Eiffel, por volta de 1985. Java só apareceu em 1995 e C#, em 2000.

E o que tudo isso tem a ver com você? Bom, talvez seja surpresa para muitos, mas em 1989 a Borland lançou o Turbo Pascal 5.5 com ObjectPascal, com extensões para OOP! Um novo tipo de dados chamado object permitia a definição de um “registro” que possuía, além de variáveis, declarações de funções e procedimentos. E diferentemente de um record, um object podia herdar de um outro object! O mundo OO estava aberto para os “pascaleiros”!

Cinco anos, e várias melhorias, depois, a Borland fez um grande favor ao mundo e lançou o Delphi 1.0, onde o object virou class (para desfazer um dilema filosófico)! Agora vivemos a experiência .Net e, como de costume, a Borland salva o dia e lança o Delphi for .Net! A experiência OO será elevada a um nível ainda maior, suportada por um ambiente de execução totalmente OO, a CLR (Common Language Runtime), que é a máquina virtual do .Net.

Nesses 15 anos, aprendemos a programar OO, criar componentes, construir hierarquias e organizar melhor as aplicações. Mas creio que ainda não temos aplicado a OO onde ela pode ajudar mais (e para a qual foi originalmente concebida): entender e simular o mundo ao nosso redor!

    Afinal, o que é Análise OO?

É um método de análise que examina os requisitos a partir da perspectiva das classes e objetos encontrados no vocabulário do domínio do problema, enfatizando a construção de modelos do mundo real usando uma visão de mundo orientada por objetos.

Construir uma VCL é realmente engenhoso e eu sou muito grato por isso! Mas e quanto à aplicação, ao domínio do problema? Continuamos a programar nas decomposições funcionais e/ou orientadas pelos dados...

E como mudar? Como “começar de novo”? Felizmente não é tão difícil quanto se imagina. É só prestarmos atenção a como as crianças aprendem...

A Teoria da Classificação diz que na compreensão do mundo real costumamos empregar três métodos:

  • Diferenciação, baseada na experiência de cada um (as pessoas e os outros objetos);
  • Distinção entre o todo e suas partes (a pessoa e seus órgãos e tecidos)
  • Formação de, e distinção entre, as diferentes classes de objetos (classes de pessoas, classes de veículos, etc.)

Assim, muito do que sabemos hoje seguiu essa metodologia. Primeiro vemos um monte de objetos passando à nossa frente. Daí conseguimos distinguir determinados grupos, através de suas similaridades e diferenças. Um pouco adiante começamos a perceber que certas coisas possuem outras coisas dentro delas (quem nunca desmontou ou quebrou um brinquedo ou um rádio?). Depois começamos a dar nome aos grupos que montamos, classificando-os. Adão provavelmente seguiu esse processo em seu primeiro emprego (leia em Gênesis 2:19-20)!

Robert Kiyosaki, autor de “Pai Rico, Pai Pobre”, sugere que “inteligência é a capacidade de fazer distinções mais refinadas”. Assim, podemos dizer que uma análise é “melhor” que outra pela forma com que fazem as distinções. Um analista é mais “inteligente” que outro por causa de sua capacidade de observação e distinção, que leva a uma melhor especificação.

Boas notícias, certo? Se já fazemos isso instintivamente, será apenas uma questão de praticar de forma metódica e habitual, e teremos dado um passo significativo para adotar a OOA em nossos projetos!

    Conceitos Fundamentais

A orientação por objetos está baseada em conceitos essenciais, que a distingue de outros paradigmas. E eles não são restritos à programação, mas estendem-se à análise e ao projeto. Entre outros, os principais são:

  • Abstração: Princípio de ignorar os aspectos de um assunto não relevantes para o propósito em questão, tornando possível uma concentração maior nos assuntos principais. Pense no objeto “pessoa”. Se você estiver criando um sistema para um hospital, provavelmente irá considerar aspectos tais como peso, altura e tipo sangüíneo. Mas eles seriam necessários numa vídeo-locadora?
  • Encapsulamento: Princípio de que cada componente do programa deve conter uma única decisão de projeto, isto é, um agrupamento de aspectos relacionados a uma idéia ou entidade. Além disso, a interface para cada módulo é definida de forma a revelar o menos possível sobre seu funcionamento interno, implementando o ocultamento de informação. Assim, se for necessário alterar alguma coisa dentro da “cápsula”, o mundo exterior não precisa (ou pelo menos não deveria precisar) ser alterado por causa disso. Nosso objeto “pessoa”, por exemplo, agrupa as informações e comportamentos de um ser humano, enquanto esconde como isso é feito.
  • Identidade: Um objeto distingue-se de outro pelo simples fato de existir. Sua identidade independe dos valores de seus atributos. Podemos ter dois objetos idênticos (dois gêmeos, por exemplo), mas ainda sim sabemos que são dois objetos independentes. Ao alocarmos dois objetos na memória do computador, embora possam ter todos os atributos iguais, seus endereços de memória são diferentes. Dois registros idênticos em uma tabela diferenciam-se pela sua chave primária única.
  • Herança: Mecanismo para expressar a similaridade entre classes, simplificando a definição de classes iguais a outras que já foram definidas (reutilização de código). Representa generalização e especialização, tornando explícitos os atributos e serviços comuns em uma hierarquia de classes. Um empregado é uma pessoa. Portanto, se definimos uma classe com os atributos e serviços típicos de uma pessoa, podemos aproveitar tudo isso para especificar um empregado, concentrando-nos agora apenas no que ele tem de diferente (normalmente a mais).
  • Polimorfismo: Capacidade de uma mesma mensagem ser entendida e executada de forma diferente por objetos distintos. Peça a uma pessoa para “cantar”. Cada tipo de pessoa irá responder ao pedido de forma diferente (algumas melhores que outras :). Polimorfismo é também a possibilidade de manipular objetos mais especializados como se fossem objetos mais genéricos. Se você pedir a um empregado, um gerente ou um cantor, para “cantar”, você não precisa saber a priori que tipo de pessoa ele é, pois “cantar” está definido na classe Pessoa, e mesmo se os indivíduos pertencerem a classes mais especializadas, por herança eles continuam sendo da classe Pessoa e, portanto, conseguem responder ao pedido para “cantar”. Os programas de calouros na TV atestam isso de forma irrefutável!
  • Associação: União ou conexão de idéias. Agrupar certas coisas que acontecem em algum ponto no tempo ou sob circunstâncias similares. Pessoas associam-se para os mais diversos fins: sociedade comercial, esportes, relacionamentos, projetos. A definição do tipo de associação busca espelhar o que acontece na vida real. Pessoas também estão associadas a coisas (carros, livros, ...), lugares (imóveis, aeroportos, ...), serviços (empréstimos, exames, ...), etc. Além das associações simples, também podemos ter composições (carro=motor+rodas+...) e agregações (um curso é um agregado de disciplinas).

    Mãos à obra?

Então, vamos começar a tão aguardada análise OO! Mas antes temos que arranjar um problema, um contexto, um domínio de negócios. Que tal a vídeo-locadora citada acima? Não, isso está muito manjado... Controle acadêmico? Boa tentativa... Um hospitalzinho? Outra hora...

Enquanto não decido, saiba que não importa qual o domínio do problema, fatalmente encontraremos quatro tipos básicos de objetos em todos eles:

  • Pessoas, lugares ou coisas: esses são os objetos mais fáceis de observar, pois são físicos. Mesmo se forem entidades abstratas, pelo próprio estudo do processo de negócio são rapidamente detectados.
  • Momentos ou intervalos: são eventos que ocorrem no processo real e que precisam ser registrados. O evento pode ser instantâneo (uma venda, um depósito) ou ocorrer durante um intervalo de tempo (uma locação, uma viagem).
  • Papéis: geralmente as pessoas, lugares ou coisas participam dos eventos desempenhando algum tipo de papel específico. Por exemplo, uma pessoa participa de uma venda como cliente ou vendedor. Um aeroporto pode desempenhar o papel de destino, origem ou escala de um vôo.
  • Descrições (tipo catálogo): quando uma coisa ou lugar possui uma descrição razoavelmente constante, essa descrição pode ficar separada do objeto real e ser reutilizada por outros objetos. Um carro tem sua placa, cor e número de chassi, mas sua descrição geral (número de portas, potência, etc.) pode ficar em um catálogo reutilizável por diversos carros do mesmo modelo.

Só quatro? Claro, é possível que você encontre um ou outro desvio dessa classificação geral, mas tenha isso como base e vá se acostumando com a idéia. Isso pode lhe economizar muito tempo na hora de analisar e projetar! Esses quatro tipos básicos são chamados de arquétipos.

Ah, sim! Nosso domínio de negócio... Bom, nos próximos artigos desenvolveremos uma análise, projeto e programação de uma aplicação que nos possibilite controlar a nossa rede de estacionamentos de veículos, a OOPark. Ela é dona dos melhores pontos da cidade e oferece alguns serviços adicionais para os clientes, mas precisa de uma boa aplicação que lhe ajude a melhorar tanto o atendimento aos fregueses quanto a gestão do negócio.

    Lição de Casa

Pense e pesquise sobre o assunto. Faça visitas a alguns estacionamentos e pergunte como funcionam. A tentação é grande, mas tente não criar tabelas ou formulários, mesmo que mentalmente. Apenas aprenda sobre o processo de negócio. Afinal, estamos na fase de análise, ok?

Sua tarefa aqui é identificar os objetos participantes do sistema real, suas características, comportamentos e relacionamentos principais. Não tente detalhar muito agora. Faremos isso quando estivermos projetando. Com a lista de objetos em mãos, tente classificá-los com relação aos quatro arquétipos apresentados.

Vocês têm trinta dias para terminar. Quem não fizer a lição de casa ficará de castigo, pois não aprenderá na prática!

Um grande abraço e até a próxima aula! Ops, artigo...

Server Response from: ETNASC02