Introdução A Orientado A Objetos

O principal objetivo deste livro é apresentar um processo que possibilite aos analistas, projetistas e programadores a compreensão e utilização de um método sistemático orientado a objetos para desenvolvimento de software.

A justificativa deste trabalho parte da observação de que a maioria dos livros sobre análise e projeto de sistemas orientados a objetos, atualmente usados como livro-texto nos cursos superiores de computação no país, não apresenta informações suficientes para viabilizar a aplicação prática da orientação a objetos.

Neste livro, são feitos uma interpretação e um detalhamento do método de análise e projeto apresentado por Craig Larman (2002), o qual é baseado no Processo Unificado (Unified Process ou UP).

A motivação para o uso do método de Larman deve-se ao fato de que este é um processo bastante conciso e eficiente para análise e projeto de sistemas orientados a objetos. Neste método, cada artefato tem uma razão muito clara para existir e as conexões entre os diferentes artefatos são muito precisas.

Desde o início, o processo leva sistematicamente à produção de software de boa qualidade, isto é, bem organizado, baseado em uma arquitetura multicamadas e com possibilidade de sistematicamente incluir novos requisitos e modificar os requisitos existentes, mesmo que o sistema já esteja implementado. Além disso, a interconexão muito clara entre todos os artefatos (diagramas e documentos) usados, permite a utilização de ferramentas CASE (Computer Aided Software Engineering) adaptadas ao processo.

1.1 Desenvolvimento de Sistemas Orientados a Objetos

Em primeiro lugar, deve-se discutir a questão sobre o que é realmente desenvolver sistemas orientados a objetos. Ao observar a forma como a análise e o projeto de sistemas vêm sendo ensinados e praticados em muitos lugares, pode-se verificar que muitos profissionais simplesmente adotam uma linguagem orientada a objetos ou até algum fragmento de metodologia orientada a objetos, mas sem ter realmente muita noção do que estão fazendo.

O problema de fazer profissionais migrarem de paradigmas mais antigos para orientação a objetos apresenta situações caricatas. Em determinada situação, durante uma palestra, alguém comentou que programava há muitos anos usando a linguagem C, e que havia resolvido começar a trabalhar com C++, mas que após alguns meses não notou absolutamente nenhuma vantagem nesta migração.

Essa pessoa realmente não viu diferença entre as linguagens porque faltou a ela saber o que havia por trás da nova abordagem, e que a linguagem C++ é mais interessante do que C não porque é mais potente ou mais complexa, mas porque traz consigo uma maneira muito mais sensata de se pensar e organizar sistemas.

O seguinte ditado certamente tem muita relação com a situação descrita acima: “Comprar um martelo não transforma você em um arquiteto”; pelo menos não necessariamente.

De nada adianta realizar pesados investimentos em ferramentas CASE orientadas a objetos sem que se compreenda claramente a forma de pensar orientada a objetos. O uso de diagramas não vai necessariamente melhorar a qualidade do software produzido. Para que um profissional possa chegar a ser um arquiteto de software, existe uma série de conhecimentos que precisam ser compreendidos, e espera-se que este livro possa dar uma boa contribuição para que estes tópicos sejam abordados com profundidade.

1.2 Linguagem de Modelagem Unificada - UML

Várias pessoas acreditam que UML é uma metodologia, por causa do “M” na sigla. Mas, na verdade, não é. A letra mais importante nesta sigla é o “L”, de “Linguagem”. UML quer dizer “Unified Modeling Language” (Linguagem de Modelagem Unificada) e é, portanto, uma linguagem, que pode ser usada para descrever coisas. Porém, conhecer uma linguagem não implica na habilidade de saber usá-la para produzir artefatos úteis. Por exemplo, a língua portuguesa é uma linguagem, mas uma pessoa que sabe escrever em português não sabe necessariamente fazer boa poesia.

Quando se usa a linguagem UML ao invés do português, escrever poesia corresponde a produzir projetos de sistemas de forma elegante. Como diz Booch (1996), não há uma definição precisa sobre o que é um projeto elegante, mas quem vê um projeto normalmente percebe se ele é elegante. Pode-se acrescentar ainda que quem produz software elegante sabe que está fazendo isso, ao passo que quem está fazendo software deselegante, normalmente não tem consciência disso.

1.3 Software Elegante e Deselegante

O software deselegante é aquele software feito sem uma estrutura clara. O software deselegante é aquele do qual não se consegue reusar partes e que não se consegue entender como funciona sem uma boa carga de documentação (e muitas vezes nem assim); é também aquele no qual uma pequena modificação em uma de suas características pode causar um não funcionamento generalizado.

O software elegante é o software cuja estrutura é intrinsecamente mais fácil de compreender, que é autodocumentado e pode ser compreendido em nível macro ou em detalhes. Ele é mais fácil de modificar: quando alguma de suas características é mudada, ele continua funcionando.

Comparando-se o projeto de software ao projeto de automóveis, um projeto deselegante de um automóvel poderia exigir que o proprietário desmontasse o motor cada vez que quisesse trocar o óleo. Este projeto de automóvel certamente seria deselegante e também muito inconveniente. Imagine, portanto, um software onde, para adicionar alguma nova característica seja necessário reescrever grande parte do código.

O projeto de automóveis hoje em dia desenvolveu-se muito, graças à incorporação de padrões de projeto (design patterns), que são como lições aprendidas ao longo dos anos. Infelizmente o software desenvolvido no varejo ainda não atingiu este nível de sofisticação, e ainda hoje profissionais desenvolvem software equivalente a um carro com a entrada do óleo escondida embaixo do motor.

A proposta deste livro é apresentar um método sistemático que possibilite ao desenvolvedor de software incorporar boas técnicas de desenvolvimento para incluir elegância em seus projetos.

1.4 Análise

A análise enfatiza a investigação do problema. O objetivo da análise é levar o analista a investigar e a descobrir. Para que esta etapa seja realizada em menos tempo e de forma mais precisa, deve-se ter um bom método de trabalho.

Esta etapa é importantíssima porque ninguém é capaz de entender perfeitamente um problema usual de sistemas de informação na primeira vez que o olha. Então, esse