GRASP: uma abordagem metódica para projeto OO básico,

analise entre padrões

Joelson Isidro¹ e Vitor Melo²

Ciência da Computação - Centro Universitário de João Pessoa (Unipê)

BR 230 - Km , Água Fria - CEP 58053-000 - João Pessoa - Paraíba – Brasil

joelson.isidro@gmail.com¹, vitorma.leite@gmail.com²

Abstract. This article presents a earlier study about projects standards who will be

teached during the course of system analysis and design II. The ideia is to compare

standards related to GRASP.

Resumo. Este artigo tem como objetivo o estudo antecipado de padrões de projetos

que serão ministrados durante o curso de análise e projeto de sistemas II. A ideia é

fazer uma comparação entre os padrões que são relacionados ao GRASP.

1. Introdução

Para uma boa definição de um projeto OO é essencial iniciar-se pela distribuição

de responsabilidades. Sendo assim, é tomado como modelo de apoio os

princípios/padrões GRASP (General Responsability Assignment Software Patterns),

que torna a distribuição de responsabilidade entre as classes uma tarefa mais criteriosa e

eficiente, melhorando de forma significativa a qualidade de seu projeto e reduzindo os

problemas de arquitetura mais comuns.

Muitos padrões, de acordo com uma determinada categoria específica de

problemas, guiam à atribuição de responsabilidades a objetos, são esses que serão

enfatizados no decorrer do desenvolvimento do artigo.

2. Padrões

As responsabilidades dos objetos são divididas em duas: característica que seria

o “conhecer” e o comportamento que é o “fazer” em relação às classes.

Existem nove padrões GRASP, mas dentre todos eles, iremos destacar apenas 5

que estão relacionados aos nossos estudos: Criador, Especialista na informação,

Acoplamento Baixo, Controlador e Coesão Alta. Esses padrões não anunciam novas

idéias, mas sim nomeiam e codificam princípios básicos amplamente usados.

2.1 Criador (Creator)

Uma das atividades mais freqüentes em um projeto OO é criar objetos. Mas

apesar disso, é necessário que haja um aspecto geral, que faça com que as

responsabilidades de criação sejam bem atribuídas e assim o projeto terá um

acoplamento baixo, encapsulamento e reutilização.

O objetivo mais comum do padrão Criador é encontrar um criador de que tenha

necessidade em se conectar com o objeto criado e essa conexão se faz pelo princípio da

agregação que se baseia no conceito todo-parte ou montante-parte , como um Avião que

agrega uma asa ou um corpo agrega um braço.

De acordo com a figura acima, quem deveria criar uma instancia de

LinhaDetalheVenda deveria ser a classe Venda , pois a mesma agrega as instâncias de

LinhaDetalheVenda.

Chegando a essa conclusão temos o seguinte diagrama:

2.2 Especialista na informação (Information Expert)

Diferentemente do padrão criador, o especialista da informação se preocupa em

atribuir as responsabilidades a classe e não ao objeto. Ele diz que o primeiro candidato a

receber a responsabilidade é aquele que possui a informação necessária para executar a

tarefa.

Como um exemplo muito comum, podemos observar o exemplo de uma venda,

basta pensar em qual classe será a responsável pelo cálculo de uma venda?

2.3 Baixo Acoplamento (Low Coupling)

Em um sistema orientado a objetos, os objetos são todos interligados, uns

mandando mensagens a outros. O baixo acoplamento é responsável por medir o quanto

uma classe está ligada a outra, isso é possível através do diagrama de classe, quando se

observa a ligação fisicamente, ou quando avaliamos uma classe e constatamos que ela

tem muito conhecimento de outra, ou quando uma classe depende de muitos elementos

de outra classe, isso se chama alto acoplamento. O alto acoplamento traz diversos

problemas para um sistema, entre eles: difícil entendimento, difícil reutilização e

propagação de mudanças.

A solução para isso seria minimizar o acoplamento entre as classes, ou seja,

deixá-las com baixo acoplamento. Existem quatro tipos de acoplamento:

Acoplamento de dados: quando uma classe conhece os dados da outra;

Acoplamento de controle: quando uma classe exerce controle sobre o

comportamento de outra.

Acoplamento de dados globais: quando dois ou mais objetos compartilham os

mesmos dados.

Acoplamento de dados Internos: quando um objeto altera os dados locais de

outro objeto, isso em java não é difícil de evitar, é só utilizar variáveis private,

ao invés de públicas.

2.4 Controlador (Controller)

Um evento de entrada de um sistema é um evento gerado por um ator externo.

Ele está associado com operações do sistema, operações do sistema em resposta a

eventos do sistema, da mesma forma que os métodos e as mensagens estão

relacionados. O padrão responsável por tratar os eventos do sistema é chamado de

padrão controlador.

É levantada a questão: Qual é o primeiro objeto, além da camada de IU, que

recebe e coordena uma operação do sistema? A maneira de avaliar a solução é pensar

em das duas escolhas possíveis propostas pelo padrão.

A responsabilidade a ser a atribuída ao objeto deve seguir uma dessas duas

escolhas:

- representa todo o “sistema”, um “objeto raiz” (controlador fachada)

- representar um cenário de caso de uso (ou um controlador de sessão).

2.5 Coesão Alta (High Cohesion)

Interliga-se com todos os padrões já citado acima. O termo coesão significa no

projeto de objetos que as responsabilidades vista no padrão Expert, dadas aos elementos

vista no padrão acoplamento baixo estejam fortemente relacionadas e focalizadas.

Se um elemento com responsabilidades altamente relacionadas não realizam um

grande volume de trabalho, afirmamos que ele tem uma coesão alta. Dificultando a

compreensão, reutilização e a manutenabilidade.

Uma classe com baixa coesão faz muitas coisas não relacionadas ou executa

muitas tarefas. Uma classe que executa muitas tarefas não possui a aplicação do padrão

especialista, pois, não há delegação de responsabilidades, bem como tarefas que não são

adequadas a ela. Classes com múltiplas responsabilidades ou com alta granularidade

estão propensas a ter uma alta coesão.

3. Paralelo

Padrão Atribuição

Criador Quem deve ser responsável pela criação de uma nova instância da

classe?

Especialista na

Informação

Qual o princípio geral de atribuição de responsabilidades à objetos?

Acoplamento

Baixo

Como apoiar dependência baixa, baixo impacto de modificação e

aumento de reuso?

Controlador Qual o objeto o primeiro objeto, além da camada de IU, que recebe e

coordena uma operação do sistema?

Coesão Alta Como manter os objeto bem focados, inteligíveis, gerenciáveis e

como o efeito colaterável apoiar Acoplamento Baixo?

4. Considerações Finais

Analisando os padrões abordados no artigo, vale destacar a importância que a

boa atribuição das responsabilidades em um projeto OO trás para o seu projeto um valor

maior no que se refere a padronização e organização mesmo. Além claro, de deixar seu

projeto mais apto para futuras mudanças, permitindo a melhor compreensão para os

desenvolvedores que serão responsáveis pela manutenabilidade do software.

Essas atribuições nem sempre são perceptíveis em uma primeira visão do

desenvolvedor, pois a facilidade de operar com esses padrões é adquirida com a

experiência e a adoção dessas regras desde o início de um projeto. Visto que

inicialmente, se o desenvolvimento não seguir regras e nem planejamento o ciclo de

desenvolvimento de um software cresce sem controle e sua estrutura não se torna

entendível por todos, sendo assim, a aplicação dos padrões se torna mais complicada.

De outro modo, com a adoção dos padrões e aplicação da maneira correta, o

processo de desenvolvimento do software pode fluir de uma forma bem mais eficiente e

funcional.

5. Referências

GRASP – como atribuir responsabilidades com eficiência, uma introdução (2009).

Disponível em: http://www.brasiltech.net/agilez/2009/09/13/grasp-como-atribuir-

responsabilidades-com-eficiencia-introducao-padroes-para-atribuicao-de-

resposabilidade/. Acesso em 12/08/2011.

Murta, Leonardo. Padrões GRASP. Disponível em:

http://www.professores.uff.br/fcbernardini/files/tpa/Padroes_Projeto_GRASP.pdf.

Acesso em 12/08/2011.

Larman, Craig (2007). Utilizando UML e padrões: uma introdução à análise e ao

projeto orientado a objetos e ao desenvolvimento iterativo, 3. ed. – Porto Alegre,

Bookman.