Anlise Orientada a Objetos

Consiste na definio de classes (objetos), suas operaes (mtodos), seus

atributos e seus relacionamentos com base no problema a ser analisado e
resolvido.
De forma introdutria e resumida, o processo de anlise OO consiste, no
incio, na elaborao de casos de uso. Estes, em conjunto com as descries
dos casos de uso sero utilizados para a modelagem das classes relevantes
para a soluo do problema.
Tambm podem ser usados como documentos complementares para a
definio das classes, os seguintes:

Glossrio: consiste nos significados dos conjuntos de termos

utilizados no negcio que est sendo mapeado nos casos de uso;
Documento de arquitetura:

O resultado da anlise destes documentos ser o modelo orientado a

objetos, que composto por diagramas UML de sequncia e classe. Porm,
alm destes, podem ser usados outros tipos de diagramas, desde que aja
algum ganho no entendimento do negcio.
O esteretipo usado nos diagramas de classe so esteretipos de anlise e
no os usados normalmente. O uso destes esteretipos especficos melhora
a identificao das classes do modelo.
Os esteretipos de anlise so divididos em:

Classe de fronteira (ou boundary);

Classe de controle (ou control);
Classe de entidade (ou entity).

Classes de fronteira so responsveis por modelar a interao entre o

ambiente do sistema e seus trabalhos internos. Essa interao consiste em
transformar ou converter eventos e observar as mudanas na apresentao
do sistema.
Classes de controle modelam um comportamento de controle especfico de
um ou alguns casos de uso. vista como uma ponte entre a camada mais
externa (classes de fronteira) e a mais interna (classes de entidade).
Classes de entidade so responsveis por modelar comportamentos e
informaes que devem ser armazenados. Ela deve manter armazenado e
atualizado informaes relativas ao negcio do sistema.
Processo de Anlise Orientada a Objetos
Para definir classes a partir das descries de casos de uso, necessrio
uma boa capacidade de abstrao. Porm se dividirmos este processo em
etapas, o trabalho acaba no sendo to complicado. Portando, a AOO pode
ser dividia nas seguintes etapas.
Identificando os principais conceitos do sistema
Primeiramente deve-se realizar a leitura atenta dos casos de uso e do
glossrio, buscando o seu entendimento. Aps isso, devemos identificar os

conceitos mais importantes e bvios do sistema. Estes conceitos so

chamados de abstraes chave, eles devem vim acompanhados de uma
breve descrio e dos seus possveis relacionamentos.
A identificao destas abstraes chave so importante, pois elas servem
como uma referncia primria que ir auxiliar toda a anlise restante do
sistema.
importante ter em mente que estas
inicialmente no devem ser consideradas
pois conforme a anlise do sistema for
soluo OO ir se ampliar e com isso
abstraes iniciais. Estas abstraes so
anlise.

abstraes chave encontradas

verdade absolutas e imutveis,
ocorrendo o entendimento da
podendo haver alteraes nas
um guia inicial para ajudar na

Criando diagramas de sequncia com base em responsabilidade

Para esta tarefa, devemos em cada cenrio do caso de uso realizar uma
releitura de todos os seus passos. Conforme essas releituras dos passos
forem ocorrendo, devemos identificar as classes de fronteira, controle e
entidade que esto ali de forma implcita.
Nessa etapa, as abstraes chaves identificadas anteriormente iro ajudar
na identificao das classes de entidade. Pois, tanto as abstraes chave
quanto as classes de entidade esto intimamente ligadas aos conceitos de
negcio do sistema. As abstraes chaves so uma primeira viso, no to
apurada, do negcio que nosso sistema tratar, est viso se tornar mais
apurada conforme formos transformando as abstraes chave em classes
de entidade.
Com as classes encontradas, devemos tambm nesta etapa, dividir
corretamente as responsabilidades entra as classes. De modo que essas
responsabilidades sejam coerentes com as classes identificadas.
As responsabilidades de uma classe, definem, as operaes que a
classe pode realizar e as informaes que ela pode conter para
cumprir com est responsabilidade
Ao invs de, a partir da leitura do caso de uso criarmos diagramas de classe,
primeiro, criamos diagramas de sequncia. Pois apesar de no ser comum,
a forma mais natural de se trabalhar. Afinal, em uma cenrio de caso de uso
teremos a interao entre os atores e o sistema, com isso conforme formos
fazendo a leitura dos passos deste caso, podemos facilmente identificar as
mensagens que devem ser trocadas dentro do sistema entre os objetos,
para a realizao de uma tarefa.
Conforme o desenvolvimento do diagrama de sequncia ocorre, vo
surgindo gradualmente tambm as classes presente no cenrio. No final
deste processo teremos um ou mais diagramas de sequncia para cada
cenrio de caso de uso. E tambm teremos provavelmente um diagrama de
classe para todo caso de uso, pois as ferramentas de diagramao UML
usadas atualmente para a criao de diagramas de sequncia tambm
contemplam diagramas de classe.
Preenchendo e refinando as classes

Aps a definio dos diagramas de sequncia e classe, chegou a hora de

arruma-los. Como cada cenrio de caso de uso foi analisado de forma
isolada possvel que tenhamos criado classes com responsabilidades
iguais mas em diagramas de sequncia diferentes. Portanto devemos fazer
uma varredura no diagrama de classes visando eliminar redundncias.
Devemos analisar os vnculos entre as classes, que so as mensagens
trocadas entre elas no diagrama de sequncia, estas mensagens
representam o relacionamento entre as classes. O refinamento seria saber
identificar qual o relacionamento certo entre estas classes no diagrama de
classes. Por exemplo, o relacionamento pode ser uma agregao ou uma
composio.
Alm do relacionamento, podemos tambm identificar os atributos das
classes com base nas mensagens trocadas entre os objetos no diagrama de
sequncia, pois uma mensagem pode ter o objetivo de enviar informao de
uma classe A para uma classe B, neste caso a informao trafegada seria
um atributo da classe A. Porm, podem haver casos em que uma classe A
precisa acessar uma classe B para fornecer informao, neste caso
provavelmente est informao seria guardada em um atributo da classe B.
Devemos ainda desconfiar quando as classes de entidade no trocarem
mensagens entre si no diagrama de sequncia para resolver passos do caso
de uso. Isso pode significar que as responsabilidades das classes no foram
bem divididas.
Padres de Anlise
Um dos documentos utilizados para auxiliar na anlise OO o documento
de arquitetura, este documento possui mecanismos de anlise OO. Existem
mecanismos de anlise focados na diviso de responsabilidade entre as
classes. Estes mecanismos so chamados de GRASP (General Responsibility
Assignment Software Patterns), eles foram criados de forma bem genrica,
com isso podem ser usados em vrias anlises OO. Utiliza-los representa
uma boa prtica na atribuio de responsabilidade para as classes.
Especialista (Expert)
o padro mais utilizado para atribuio de responsabilidades. Esse padro
determina a classe que ser a especialista em determinada informao.
Essa classe especialista uma classe que contm todas as informaes
necessrias para cumprir a responsabilidade que lhe foi atribuda, ou que
sabe como obter tal informao.
Por exemplo, em um sistema de vendas temos as classes Venda e
ItemVenda, a classe que ser responsvel por conter todas as informaes
relativas a venda de produtos ser a classe Venda, pois, ela detm o
conhecimento sobre todos os seus ItemVenda. Enquanto que a classe
ItemVenda, contm apenas informaes sobre um determinado item
venda. Neste caso a classe Venda ser composta por ItemVenda.
Muitas vezes as responsabilidades atribudas no tem um correspondente
no mundo real. No exemplo anterior a responsabilidade de calcular a venda

ficou com a classe venda, porm no mundo real quem faria isto seria uma
pessoa. Em OO objetos inertes ou conceitos podem ter responsabilidades.
Criador (Creator)
Padro que ir definir uma classe criadora. Est classe criadora ser
responsvel pela criao de instncias de um outra classe. Para que uma
classe seja definida como criadora, est, deve conter a outra classe como
parte dela ou estar fortemente associado a outra classe. Assim, por
exemplo, se uma das seguintes condies for verdadeira uma classe C ser
responsvel pela criao de instncias de uma classe D:

C
C
C
C
C

agrega objetos D;
contm objetos D;
registra instncias de objetos D;
usa de maneira muito prxima objetos de D;
um especialista com relao criao de D.

Controlador (Controller)
Padro que define uma classe responsvel por tratar os eventos do sistema.
Existem duas formas de atribuir est responsabilidade a uma classe.
A primeira seria criar uma classe que ir tratar todos os eventos de uma
caso de uso, nesse caso estamos criando uma controlador de caso de uso.
A segunda forma seria criar uma classe que controlaria todo o sistema, um
controlador de fachada.
As classes de fronteira, no devem ser responsveis pela tratamento de
eventos do sistema, elas devem apenas delegar est funo para a classe
de controle. Dessa forma temos um baixo nvel de acoplamento, pois as
classes de fronteira que constituem a camada de interface com o usurio
no so responsveis pelo tratamento de eventos, podendo ser facilmente
substitudas.
Baixo Acoplamento (Low Coupling)
Acoplamento o quanto uma classe est associada a outra classe. Esta
conexo pode ser observada em vrios relacionamentos. Uma classe com
acoplamento baixo, no possui tanta dependncia em relao a outra
classe. J em uma classe com acoplamento alto, uma alterao em uma
classe associada a est, pode ocasionar vrias mudanas na mesma.
Portanto, devemos evitar associaes que sejam redundantes no modelo de
classes.
Coeso Alta (High Coesion)