Utilizando UML e Padrões - Parte I

Análise e Projeto Orientados a Objetos

O provérbio "possuir um martelo não torna alguém um arquiteto" é particulamente verdadeiro em relação à tecnologia de objetos. Conhecer uma linguagem orientada a objetos (como C#) é o primeiro passo necessário, mas insuficiente, para criar sistemas orientados a objetos. Aprender a "pensar em termos de objetos" é fundamental.

A análise enfatiza uma investigação do problema e dos requisitos, em vez de uma solução. Se desejamos um novo sistema de informação de biblioteca computadorizado, por exemplo, como ele será usado?

Análise é um termo de significado amplo, melhor qualificado como análise de requisitos (uma investigação de requisitos) ou análise de objetos (uma investigação dos objetos do domínio).

O projeto enfatiza uma solução conceitual que satisfaça os requisitos e não sua implementação. Uma descrição de um esquema de banco de dados e objetos de software é um bom exemplo. Em última instância, projetos podem ser implementados. Da mesma forma que na análise, o termo projeto é melhor qualificado como projeto de objetos ou projeto de banco de dados.

A análise e o projeto foram resumidos na fase faça a coisa certa (análise) e faça certo a coisa (projeto).

Durante a análise orientada a objetos, o objetivo é encontrar e descrever os objetos - ou conceitos - no domínio do problema.

Durante o projeto orientado a objetos, há uma ênfase na definição dos objetos de software e como eles colaboram para a satisfação dos requisitos. No sistema da biblioteca, por exemplo, um objeto de software Livro pode ter um atributo Titulo e um método ObterCapitulo.

Finalmente, durante a implementação ou programação orientada a objetos, os objetos de projeto são implementados, como uma classe Livro em C#.

A Linguagem de Modelagem Unificada (UML) é uma linguagem para especificar, visualizar, construir e documentar os artefatos de sistemas de software, bem como para modelar negócios e outros sistemas que não sejam software.

Objetos e Classes

Um objeto pode ser uma entidade física, como uma cadeira ou um livro. Você pode descrever a cadeira, consertá-la e vendê-la. Você pode comprar um livro, ler o livro, marcar o livro.

Um objeto também pode ser intangível, como um cargo ou a presença em uma aula. Embora um cargo não seja algo que você possa tocar, ele é algo que você pode descrever, discutir, atribuir e completar. A presença em aula pode ser descrita, monitorada e relatada. Qualquer coisa que você possa descrever pode ser representada como um objeto, e essa representação pode ser criada, manipulada e destruida para representar como usar o objeto real que ela modela.

Um objeto é a representação de uma entidade especifica no mundo real, como uma pessoa específica ou um pedido específico. Uma classe é composta de regras que definem o objeto. Por exemplo, o livro é real. Ele é feito de papel, possui dimensões, páginas, cores, IBSN e título. No mundo real, movemos o livro da gráfica, para o depósito, para as lojas e finalmente para a mãos dos leitores. Para acompanhar o livro físico, teríamos que segui-lo fisicamente por todas essas mudanças. Para um livro, isso poderia ser possível, embora bastante dispendioso. Para uma editora que deseja rastrear milhares de livros, a abordagem física seria impossível e nada prática. Em vez disso, a editora cria uma representação do livro, uma descrição que contém informações suficientes para rastrear com precisão o que a editora precisa saber sobre o livro e suas mudanças, a fim de dar suporte aos objetivos de negócios da editora. Depois, para cada mudança relevante que acontece com o livro, a editora altera a representação.

Com a representação individual para todos os livros rastreados pela editora precisa ter a mesma informação, a editora cria um único conjunto de regras que se aplicam a todos os livros. O conjunto de regras é chamado de classe. Uma classe é uma definição, um template, que descreve como criar uma representação precisa de um tipo de objeto específico. Cada objeto é instanciado (criado, tornando real) pelo uso da definição de classe como um template. Porém, cada objeto, cada instância da classe, pode ser descrito usando valores exclusivos para cada uma das regras que a classe define. Por exemplo, a classe diz que cada livro precisa de um ISBN. Mas cada objeto livro recebe um ISBN diferente.

Criando abstrações de objetos

Para usar objetos, primeiro precisamos distinguir entre um objeto real e a representação de um objeto. Em projetos de software, quase sempre estamos trabalhando com representações de objetos. O sistema precisa gerenciar a representação para refletir como você está gerenciando os objetos reais. Por exemplo, um sistema de processamento de pedidos precisa gerenciar clientes, pedidos e produtos. O software, então, gerencia as abstrações para que coincidam com as mudanças que ocorrem nos objetos do mundo real.

Quando um cliente real faz um pedido de um produto, o software cria um objeto de pedido (abstração) que associa o cliente (abstração) ao produto (abstração).

A qualidade e o valor da abstração são definidos pelo modo como ela representa os objetos do mundo real em termos da informação que precisamos manter sobre eles e as coisas que queremos fazer com eles.

Assim, uma abstração representa alguma coisa no mundo real. Uma abstração descreve essa "alguma coisa" usando apenas as informações que dão suporte ao modo como planejamos utilizá-la.

Quando eu preciso entrar em contato com um membro do grupo CAFÉ.NET, por exemplo, eu não preciso saber tudo a respeito dele. Eu poderia contactá-lo usando apenas seu nome e seu número de telefone. Não acrescentaria nada à minha capacidade de comunicar com ele se eu também registrasse seus hábitos de alimentação, os dados de sua família e suas preferências musicais. Todas essas outras informações são válidas e realmente o descrevem, mas não me ajudam a entrar em contato com ele.

O motivo para criarmos abstrações é para realizarmos algum trabalho. Precisamos criar, manipular, e descartar informações para refletir como criamos, manipulamos e descartamos coisas reais.

Assim, para criar uma abstração apropriada, preciso entender o problema do mundo real que a abstração representa. Se eu quiser vender camisas, então minha abstração de camisa precisa incluir pelo menos algum tipo de recurso de indentificação, tamanho custo e preço. Conhecer a pessoa que custurou a camisa, as máquinas que a prepararam ou a embalagem em que foi colocada na fábrica não afeta minha capacidade de vendê-la, de modo que essa informação não é necessária.

A pergunta é "Que informação precisamos ter a respeito da camisa a fim de vendê-la de modo eficaz?"

Leia também