Projeto Orientado a Objetos

Diego Doná1, Wellinton Rodrigo1

1
Faculdade Salesiana Dom Bosco de Piracicaba, Piracicaba – SP – Brasil
Diego: diedona@gmail.com, Wellinton: bankai_akatsuki@yahoo.com.br
Abstract. This article aims to explain the process of the object oriented design.
Also, explains briefly the relative topics, like object oriented programming and
object oriented analysis.
Resumo. Este artigo tem por objetivo apresentar o processo de um projeto
orientado a objeto e como ele funciona. Procura também explicar, de forma
breve, os tópicos relativos, como a orientação a objetos e a análise orientada
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 objeto 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 delegar determinados processos. As classes são as plantas dessas entidades,
possuindo apenas as definições sobre ela, 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 80 Kilos e mede 1,80 cm 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 que as 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” que definimos na Classe, que os 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 outra. Todos os
dados públicos e 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, centralizamos as informações e evitamos mais
escrita de código.

1.6 Modificadores de acesso

As propriedades e métodos existentes devem definir o quão “exposto” estão em relação
ao ambiente, em relação as 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 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) saibam 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 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), 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, devem 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 e 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 ampla divulgação facilitam a visão do projeto tanto na etapa
de análise quanto na de projeto.
Um diagrama bem “íntimo” a análise é o de Use Case (Caso de Uso), na 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 caracterizado 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 aberto a proposta para
apresentação de trabalhos de padronização de um modelo para desenvolvimento de
sistemas que atendesse ao modelo orientado a objetos. A proposta vencedora foi
apresentada 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, as entidades que podem
interagir com o sistema. Podem ser pessoas ou até mesmo outros sistemas
independentes. Para descobri-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.
 Figura 1. 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 é direta com o sistema, ou seja, não
necessita de um ator.
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 seqüência é usado principalmente para mostrar as interações entre os
objetos na ordem seqüencial que as interações ocorrem. Muito parecido com o diagrama
de classe, os desenvolvedores normalmente pensam diagramas de seqüência foram
feitos exclusivamente para eles.
No entanto, os funcionários de uma organização de negócios podem encontrar
diagramas de seqüê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 seqüê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.

Figure 2. 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 que se deseja resolver e
uma descrição das classes existentes. Na etapa de projeto, adicionaremos 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, estes podem ser
adiados 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
funcionamento.
Essa flexibilidade é utilizada pela metodologia MDA (Model Driven
Architecture), outra criação da OMG, que propõem 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 possui um
relacionamento com a classe Produto. No diagrama podemos mostrar essa ligação de
uma forma mais clara.
 Figura 3. Exemplo de Diagrama de Classe

Conclusão
O uso da análise, projeto e programação orientada a objeto 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 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.

Referências
Rational Inc. (2004) “Análise/Projeto e Programação Orientadas a objeto”,
http://www.malima.com.br/article_read.asp?id=39, Outubro.
Caelum (2009) “FJ-11 | Java e Orientação a Objetos”.
Universidade Regional Integrada do Alto do Uruguai e das Missões. “Análise Orientada
a Objetos”
José Carlos Macoratti. (2004) “Modelando sistemas em UML - Casos de uso”,
http://imasters.uol.com.br/artigo/2753?cn=2753&cc=145, Novembro.
Apress Publishing. (2005) “Introducing UML: Object Oriented Analysis and Design”,
http://www.devshed.com/c/a/Practices/Introducing-UMLObjectOriented-Analysis-
and-Design/, Julho.
IBM Coporation. (2004) “UML basics: The sequence diagram”,
http://www.ibm.com/developerworks/rational/library/3101.html, Fevereiro.