Projeto orientado a objetos

1. Orientação a objetos

A programação orientada a objetos é uma maneira de programar com uma organização e pensamentos diferente da programação estruturada. Quando ouvimos “programação estruturada”, podemos esperar basicamente funções e procedimentos, concentramo-nos na ação a ser executada. Na programação orientada a objetos temos classes, objetos, métodos. Pensamos nas entidades existentes e como elas se relacionam.

A orientação a objetos fornece maior facilidade para modificar um código já escrito e uma visão mais simples do projeto em si, graças a características como encapsulamento. Amarramos características junto às funcionalidades, concentrando código e prevenindo erros.

1.1 Classes

A análise do projeto revelará muitas “entidades” das quais desejamos salvar certos dados e para as quais desejamos delegar determinados processos. As classes são as plantas dessas entidades, possuindo apenas as definições sobre elas, sem nenhum tipo de dado.

Um exemplo simples seria pensar nas pessoas: esperamos que elas possuam idade, nome, peso, altura, dentre outras características; também esperamos que possam pensar, se expressar, se divertir, etc; essa é a nossa definição (simplificada) para a Classe pessoa.

Definimos o que uma pessoa precisa ter e o que ela sabe fazer, mas sendo uma classe, a “Pessoa” em si não pode ter uma idade. Podemos pensar como se fossem plantas de construção de casas. A partir de uma definição (do desenho, métrica, etc) construímos objetos que terão os dados esperados.

1.2 Objetos

Se numa análise detectamos a necessidade de guardar determinadas informações sobre várias pessoas, criamos a classe Pessoa. Mas não basta apenas saber o que uma pessoa pode ter e fazer. Os objetos implementam as definições das classes e as preenchem com dados reais. “Roberto tem 23 anos, pesa 80Kg e mede 1,80cm de altura.”

Roberto é um objeto, uma instância da classe Pessoa. Apesar de “como se divertir” ter sido definido na classe, ele possui dados onde antes apenas deixamos lacunas vagas.

1.3 Propriedades

As propriedades são os dados, o estado cujos Classes e objetos possuem. Um exemplo de propriedade é a idade. Desejamos saber quantos anos uma pessoa tem, portanto acrescentamos essa informação à nossa definição (classe).

1.4 Métodos

Os métodos são “habilidades” as quais definimos na Classe, cujos objetos são capazes de reproduzir. Vamos supor que, no projeto analisado, todas as pessoas necessitem saber falar. Criamos um método “falar” e dentro dele dizemos como essa ação é executada.

1.5 Herança

É possível, na orientação a objetos, termos classes que “herdam” de outras. Todos os dados, públicos ou protegidos, da classe “pai” passam a existir na classe que herda, na “filha”. Isso possibilita modelos mais simples e com menos repetições de dados.

Imagine que, em modelo imaginário, fossem necessárias as classes funcionário e gerente. O funcionário possui uma série de dados e ações básicas. O gerente também deve possuir essas mesmas características, mas com alguns acréscimos, como poder fazer um pedido de compra ou ter uma bonificação maior de salário.

Isso poderia ser resolvido escrevendo uma classe para cada um, porém, se fizermos gerente herdar de funcionário, centralizaremos as informações e evitaremos mais escrita de código.

1.6 Modificadores de acesso

As propriedades e os métodos existentes devem definir o quão “expostos” estão em relação ao ambiente, em relação às outras classes. Lidamos, em geral, com modificadores públicos, privados, protegidos e estáticos, porém, existem outros. Alguns dependem da sua opção de linguagem de programação.

Modificadores públicos expõem a informação para todas as outras classes. Todos podem ter acesso de leitura e modificação, caso seja uma propriedade. Um método público pode ser utilizado por todos.

Utilizando o modificador privado, protegemos a informação ou o método apenas para uso interno à classe, cortando qualquer acesso externo. Um exemplo prático é o ato da fala. Sabemos que precisamos (ou ao menos deveríamos) pensar nas palavras e então pronunciá-las. Porém, nosso corpo dispara uma série de eventos e ações para que a tarefa seja concluída, ações que só ele próprio (e talvez médicos) sabe exatamente porque e como estão ocorrendo.

Entre público e privado temos o modificador Protegido. Ele expõe métodos e propriedades para as classes herdeiras, permitindo acesso direto, como se os protegidos fossem públicos. Entretanto, para classes não herdeiras, o acesso continua fechado. Não é uma prática muito comum, mas é possível.

O modificador de acesso estático permite que os dados e os métodos independam de objetos. O que é estático pertence à classe, todos os objetos que existirem compartilharão da mesma informação.

2. Análise orientada a objetos

Antes de iniciar o projeto, precisamos modelar o problema a ser resolvido. Na abordagem orientada a objetos, buscamos identificar as classes (entidades), o seu funcionamento interno (propriedades, métodos) e os relacionamentos existentes. As informações obtidas geralmente são representadas via diagramas da UML.

O cliente é responsável por fornecer a descrição do problema e um membro da equipe de desenvolvimento, geralmente o analista, deve fazer a modelagem de acordo com as informações disponíveis. Não nos preocupamos com plataformas, linguagens ou hardware neste momento. Apenas desejamos entender o problema, representar o problema, e mapear os elementos.

Basicamente, podemos entender que a análise consiste de todas as atividades feitas com ou para o conhecimento do cliente. A informação produzida é aquela que o cliente deve discutir e aprovar. Com essa definição, a análise invade um pouco o "lado da solução", pois o cliente deve discutir alguns tipos de interações que ocorrerão na interface do usuário, etc.

2.1 Representações

Podemos usar diversas representações para a análise orientada a objetos, mas um padrão adotado e bem aceito é a Linguagem de Modelagem Unificada, a UML. Seu longo repertório de diagramas e sua ampla divulgação facilitam a visão do projeto tanto na etapa de análise quanto na de projeto.

Um diagrama bem “íntimo” à análise é o de Use Case (Caso de Uso), no qual modelamos as interações existentes com o sistema a ser desenvolvido. A partir dele obtemos requisitos funcionais para as classes do sistema.

2.2 UML

No início dos anos 90 foi caracterizada pelo nascimento de uma grande quantidade de métodos e notações para suportar o desenvolvimento orientado a objetos, que tinha demonstrado ser um meio eficaz para produção de software.

Por iniciativa da OMG (Object Management Group), foi aberta a proposta para apresentação de trabalhos de padronização de um modelo para desenvolvimento de sistemas que atendesse ao modelo orientado a objetos. O trabalho vencedor foi apresentado pela Rational Software Corporation e recebeu o nome de UML (Unified Modeling Language).

2.3 Exemplo de Caso de Uso

Para utilizar o Caso de Uso é necessário identificar os atores, entidades que podem interagir com o sistema. Podem ser pessoas ou até mesmo outros sistemas independentes. Para descobrí-los, utilizamos perguntas como “Quem fornece dados?”, Quem inicializa o sistema?”, etc. Também devemos dar um nome para cada caso de uso, representados por balões, além de nomear os atores.

Modelagem simplificada de uma venda em um sistema

Temos o ator Cliente, que pode Buscar um produto e também efetuar uma compra. O ator Vendedor interage com o cliente a efetuar uma compra e criar um cadastro, mas ao buscar um produto, a interação do Cliente é direta com o sistema.

O caso de uso “Checar Cadastro” é, obrigatoriamente, realizado a cada compra. A marcação <<include>> identifica graficamente essa necessidade. Esse exemplo é simples. Podem existir outras marcações e casos de uso.

2.4 Diagrama de Sequência

O diagrama de sequência é usado principalmente para mostrar as interações entre os objetos na ordem sequencial que as interações ocorrem. Muito parecido com o diagrama de classe, os desenvolvedores normalmente pensam que diagramas de sequência foram feitos exclusivamente para eles.

No entanto, os funcionários de uma organização de negócios podem encontrar diagramas de sequência úteis para comunicar como a empresa trabalha atualmente, mostrando como vários objetos de negócios interagem. Além de documentar os assuntos correntes de uma organização, um diagrama de sequência de nível empresarial pode ser usado como um documento de requisitos que registra os requisitos para a implementação do sistema no futuro.

Exemplo de diagrama de sequência. O usuário entra com seus dados e o formulário retorna se é um usuário válido ou não.

3. Projeto Orientado a Objetos

Depois de feita a análise, possuímos a descrição do problema o qual se deseja resolver e uma descrição das classes existentes. Na etapa de projeto, adicionamos novos detalhes complementares para as classes anteriormente mapeadas, que podem ser necessárias do ponto de vista técnico.

Apesar da adição de detalhes serem uma etapa importante, esta pode ser adiada até a implementação, visto que nos preocupamos com os objetos, e não unicamente com cada detalhe.

Podemos inclusive dividir em duas partes: Projeto de Sistemas e Projeto de Objetos. Na primeira, nos concentramos na especificação do sistema, onde cada classe pertence e na interface do usuário. Na segunda, focamos nas classes, sua completeza e seu funcionamento.

Essa flexibilidade é utilizada pela metodologia MDA (Model Driven Architecture), outra criação da OMG, que propõe a divisão do projeto em várias etapas, umas abstratas, que independem da implementação, e outras mais detalhadas e focadas na plataforma, que podem ser utilizadas como base para geração de código.

O resultado do projeto orientado a objetos é uma documentação rica em detalhes, que pode ser passada para código orientado a objeto sem maiores dificuldades.

3.1 Vantagens

O mapeamento do projeto na metodologia orientada a objetos permite uma transcrição mais rápida da etapa de análise. Além disso, podemos utilizar classes e objetos criados em outros projetos, como se estivéssemos re-utilizando componentes.

As representações com a UML permitem uma visão melhor e mais clara do sistema, desde a etapa de análise. Todo o material gerado na etapa de projeto serve como base para a construção do código orientado a objeto.

Conforme geramos a etapa de projeto, revisamos a análise e podemos manter a documentação atualizada. Também podemos utilizar padrões de projetos, que são "soluções prontas" para necessidades comuns num projeto.

3.2 Diagrama de Classe

Mais utilizado na etapa de projeto, a UML dispõe do Diagrama de Classe, que nos permite caracterizar melhor uma classe, do ponto de vista técnico. Sabemos, pela análise, que o sistema possui clientes. Sabemos que eles possuem nome, identificação, CPF e podem realizar algumas ações.

Porém, isso não é o suficiente para o ponto de vista “técnico”. Nome, identificação e CPF precisam de um domínio. Por exemplo, numérico inteiro, com casas decimais, string, etc. Também pode ser detectada a necessidade de um cliente possuir um relacionamento com a classe Produto. No diagrama podemos mostrar essa ligação de uma forma mais clara.

Exemplo de Diagrama de Classe

Conclusão

O uso de análise, projeto e programação orientados a objetos permite um desenvolvimento mais robusto de uma aplicação. Encontramos maiores dificuldades nesse modelo, porém, o processo bem executado nos deixa com uma documentação pronta para o código e para um sistema flexível em funcionamento.

De uma forma simples, podemos colocar que a análise mapeia a necessidade, “entende” o que a aplicação deve fazer. Depois que esse entendimento é validado com o cliente, precisamos pensar numa estrutura que atenda as necessidades vistas anteriormente. O projeto se encarrega de adicionar detalhes à análise pensando em como resolver os problemas.

Por fim, a programação orientada a objetos é a responsável por dar vida à aplicação, seguindo as informações vindas da etapa de projeto.