Antes de programar: Análise Orientada a Objetos

Vamos recordar como pensar na solução computacional de um problema pelo ponto de vista da orientação a objetos. Este texto não é específico para Java, vale para qualquer linguagem que lhe possibilite programar OO (orientado a objetos).

Linguagens de programação orientadas a objeto assim como C++ e Java nos forçam a desenvolver em outro paradigma. Mais que desenvolver, esse novo paradigma provoca também modificações na análise de um software, oferecendo as diversas "visões" do mesmo problema, cada visão busca identificar e de certa forma representar os artefatos do software a ser desenvolvido.

O que é um objeto?

Objeto é a unidade base desse paradigma de análise e programação. Um objeto é uma abstração da realidade de tal forma que lhes restem apenas as características que interessam no mundo computacional. Não necessariamente um objeto computacional tenha que ser um objeto real.

Ao definir um objeto (e chamamos isso de classe, pois descreve uma "categoria", "conjunto de objetos"), nos perguntamos o que ele tem, e o que ele faz (os atributos e os métodos).

Exemplos:
Conexão com o banco de dados
- (tem) usuário
- (tem) senha
- (tem) endereço do servidor de BD
- (tem) nome do banco de dados
- (faz) Conectar
- (faz) Desconectar

Aqui basicamente definimos o objeto "conexão", que não é um objeto do mundo real, mas existe no mundo computacional.

Livro
- (tem) Título
- (tem) Autor
- (tem) Editora
- (tem) Nro de páginas
- (faz) ???

O que um livro faz? Quais são as ações de um livro? Aqui chegamos a mais um ponto interessante. As características e ações (atributos e métodos) de UM MESMO OBJETO DO MUNDO REAL podem ser diferentes para problemas distintos. Cada análise usa apenas o que é necessário daquele objeto na resolução do problema. Sendo assim, para uma transportadora, pouco importa o título do livro, importa qual o seu peso e volume (volume de quantidade de espaço), características essas que são dispensáveis para o caso de uma biblioteca.

Conclusão 1: A representação de um objeto no mundo computacional é menos complexa do que no mundo real, pois no mundo computacional usa-se apenas o que convém para a resolução de um problema epecífico. Faz-se uma abstração.

Isso nos leva a segunda conclusão.
Conclusão 2: A análise orientada a objetos torna as coisas mais simples, porque cada objeto é uma entidade simples, tendo de forma organizada seus atributos e métodos.

Para finalizar esse tópico, um objeto é representado, documentado, descrito através de uma Classe. O objeto é uma instância de uma classe, é um exemplar dentre os vários objetos que são do tipo de uma determinada classe.

Qual o problema de programar ou analisar estruturado?

Na verdade não há problema que não possa ser contornado, programadores e analistas experientes que nunca pensaram "orientado a objetos" tem em geral soluções elegantes para seus sotwares. O que acontece é que cada um tem uma, e cada um gasta um bom tempo até chegar a melhor solução, e a minha solução pode não se aplicar a outra pessoa, outro problema computacional.

Orientação a objeto é um padrão de como fazer as coisas de modo que todos o façam daquela forma, objetivando nenhum retrabalho, total reaproveitamento de códigos e análises já feitas anteriormente e ainda que isso se aplique a uma ampla gama de problemas computacionais.

Quem programa/analisa estrutural, pensa em que funções o software como um todo deverá ter. Orientado a objetos, pensa-se que dados e que ações cada objeto deverá ter. Pensando assim, em fragmentos mais pequenos e menos complexos há menos risco de esquecer ou menosprezar algum detalhe que no futuro (em uma análise/programação) estruturada poderia aparecer apenas durante um estágio avançado do desenvolvimento e complicar o projeto todo.

Em geral costuma-se dizer que os dados possuem maior integridade quando tratados por um programa OO, porque cada objeto é responsável apenas por SEUS métodos e seus dados, podendo apenas o objeto fazer sua manipulação, e isso de forma especializada.

Quem programa procedural/estruturado programa errado?

Não, em geral programas pequenos e de baixa complexidade não precisam de muito trabalho de análise para que possam ser desenvolvidos. A regra do custo/benefício da POO e análise OO é conforme o "tamanho do problema", quanto maior o programa, maiores serão os benefícios de uma análise OO.

Porém é mais trabalhoso no processo inicial a análise OO em comparação da estruturada, e na estruturada, os resultados em forma de "programa executável" (quando é um problema pequeno) tendem a aparecer antes. Como tanto para analisar como para programar OO há muitas regras, demora mais até que a "burocracia" seja resolvida e possa-se programar efetivamente. Ressalto que esse trabalho adicional de análise é muito valho, uma análise mal feita é um projeto fracassado.

Ok, e como eu analiso um problema "pelo ponto de vista da orientação a objetos" ?

Se leu até aqui já deve ter notado. O primeiro passo é identificar quem seão os objetos do problema. Vamos a um exemplo que fica mais fácil. Queremos fazer um software que é um dicionário, então um dos objetos é "o dicionário", um outro objeto poderiam ser "as palavras". Temos dois objetos, agora temos que descobrir dos nossos objetos quais atributos nos interessam.

Objeto dicionário:
Nro de palavras
Idioma

Objeto palavra
TextoPalavra
TextoSignificado

O segundo passo é identificar que ações correspondem a cada objeto. No caso o objeto "dicionário" teria os métodos "abrir", "fechar" e "procurar palavra". temos aqui mais um tópico interessante, o dicionário "procura palavras" ou seja, as palavras tem uma "relação" com o objeto "dicionário.

Mapeando as relações entre as classes podemos montar um diagrama de classes, que é um dos principais artefatos da análise pelo padrão UML.

UML? Quer dizer que tem um padrão para produzir uma especificação de análise orientada a objetos?

Exato, UML é um padrão para criar documentos de análise de software OO.

UML (Unified Modeling Language), de acordo com Rumbaugh e Jacobson (2000), é uma linguagem para especificar, visualizar e construir os artefatos de sistemas de software. Ela é um sistema de notação (incluindo a semântica para suas notações) dirigida à modelagem de sistemas, usando conceitos orientados a objetos.

Nossa! Mas isso é complicado de mais. Não teria como resumir isso tudo "ao essencial" ?

Muita coisa é essencial, tem que ler muito e praticar, não teria como resumir não.

Justamente por ser muitas regras, precisar ter uma "base de conhecimento" pelo menos "meio boa" é que a maioria ainda prefere analisar e programar de forma estruturada (cada um cria seus padrões), e que os quem programa e analisa OO se destaca, se fosse "comum" não teria porque fazer um blog falando de Java, que é uma linguagem voltada para programação OO.

Ok, me de alguns links então ...

Pesquise no google sobre "orientação a objeto", "análise orientada a objetos"... vá seguindo as pistas.

É interessante ler também algum livro (ou apostila) sobre UML, seja UML 1 ou 2.

Vamos aos softwares:

Jude Comunnity - Um programa free para criar documentos UML de análise de software.

Umbrello - É o software usado pelo pessoal que faz análise do KDE. Na documentação do KDE tem o help completíssimo. Eu particularmente aprendi mais sobre OO lendo essa documentação do que em livros. É claro, o conjunto é quem compõe a obra, talvez sem os livros o que diz na documentação não faria sentido nenhum.

Em futuras postagens que envolvam algum documento UML, usarei o Umbrello por preferência própria.

É isso! Até mais ver.

Referências:

RUMBAUGH, James; JACOBSON, Ivar; BOOCH, Grady. UML : Guia do Usuário. Rio de Janeiro, Campus, 2000.

RITTER, Helton. PACHECO, Jonas R. Gestão Financeira para Propriedades Rurais na Perspectiva de Análise Orientada a Objetos. Relatório de Prática Profissional Direcionada III do curso Bacharelado do Sistemas de Informação. Três de Maio, SETREM: novembro de 2008.