GRASP: uma abordagem metdica para projeto OO bsico, analise entre padres

Joelson Isidro e Vitor Melo Cincia da Computao - Centro Universitrio de Joo Pessoa (Unip) BR 230 - Km , gua Fria - CEP 58053-000 - Joo Pessoa - Paraba 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 padres de projetos que sero ministrados durante o curso de anlise e projeto de sistemas II. A ideia fazer uma comparao entre os padres que so relacionados ao GRASP.

1.

Introduo

Para uma boa definio de um projeto OO essencial iniciar-se pela distribuio de responsabilidades. Sendo assim, tomado como modelo de apoio os princpios/padres GRASP (General Responsability Assignment Software Patterns), que torna a distribuio 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 padres, de acordo com uma determinada categoria especfica de problemas, guiam atribuio de responsabilidades a objetos, so esses que sero enfatizados no decorrer do desenvolvimento do artigo.

2.

Padres

As responsabilidades dos objetos so divididas em duas: caracterstica que seria o conhecer e o comportamento que o fazer em relao s classes. Existem nove padres GRASP, mas dentre todos eles, iremos destacar apenas 5 que esto relacionados aos nossos estudos: Criador, Especialista na informao, Acoplamento Baixo, Controlador e Coeso Alta. Esses padres no anunciam novas idias, mas sim nomeiam e codificam princpios bsicos amplamente usados.

2.1

Criador (Creator)

Uma das atividades mais freqentes em um projeto OO criar objetos. Mas apesar disso, necessrio que haja um aspecto geral, que faa com que as responsabilidades de criao sejam bem atribudas e assim o projeto ter um acoplamento baixo, encapsulamento e reutilizao.

O objetivo mais comum do padro Criador encontrar um criador de que tenha necessidade em se conectar com o objeto criado e essa conexo se faz pelo princpio da agregao que se baseia no conceito todo-parte ou montante-parte , como um Avio que

agrega uma asa ou um corpo agrega um brao.

De acordo com a figura acima, quem deveria criar uma instancia de LinhaDetalheVenda deveria ser a classe Venda , pois a mesma agrega as instncias de LinhaDetalheVenda. Chegando a essa concluso temos o seguinte diagrama:

2.2

Especialista na informao (Information Expert)

Diferentemente do padro criador, o especialista da informao se preocupa em atribuir as responsabilidades a classe e no ao objeto. Ele diz que o primeiro candidato a receber a responsabilidade aquele que possui a informao necessria para executar a tarefa. Como um exemplo muito comum, podemos observar o exemplo de uma venda, basta pensar em qual classe ser a responsvel pelo clculo de uma venda?

2.3

Baixo Acoplamento (Low Coupling)

Em um sistema orientado a objetos, os objetos so todos interligados, uns mandando mensagens a outros. O baixo acoplamento responsvel por medir o quanto uma classe est ligada a outra, isso possvel atravs do diagrama de classe, quando se observa a ligao 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: difcil entendimento, difcil reutilizao e propagao de mudanas. A soluo 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 no difcil de evitar, s utilizar variveis private, ao invs de pblicas. Controlador (Controller)

2.4

Um evento de entrada de um sistema um evento gerado por um ator externo. Ele est associado com operaes do sistema, operaes do sistema em resposta a eventos do sistema, da mesma forma que os mtodos e as mensagens esto relacionados. O padro responsvel por tratar os eventos do sistema chamado de padro controlador. levantada a questo: Qual o primeiro objeto, alm da camada de IU, que recebe e coordena uma operao do sistema? A maneira de avaliar a soluo pensar em das duas escolhas possveis propostas pelo padro. A responsabilidade a ser a atribuda ao objeto deve seguir uma dessas duas escolhas: - representa todo o sistema, um objeto raiz (controlador fachada) - representar um cenrio de caso de uso (ou um controlador de sesso).

2.5

Coeso Alta (High Cohesion)

Interliga-se com todos os padres j citado acima. O termo coeso significa no projeto de objetos que as responsabilidades vista no padro Expert, dadas aos elementos vista no padro acoplamento baixo estejam fortemente relacionadas e focalizadas.

Se um elemento com responsabilidades altamente relacionadas no realizam um grande volume de trabalho, afirmamos que ele tem uma coeso alta. Dificultando a compreenso, reutilizao e a manutenabilidade. Uma classe com baixa coeso faz muitas coisas no relacionadas ou executa muitas tarefas. Uma classe que executa muitas tarefas no possui a aplicao do padro especialista, pois, no h delegao de responsabilidades, bem como tarefas que no so adequadas a ela. Classes com mltiplas responsabilidades ou com alta granularidade esto propensas a ter uma alta coeso.

3.

Paralelo
Padro Criador Atribuio Quem deve ser responsvel pela criao de uma nova instncia da classe? Qual o princpio geral de atribuio de responsabilidades objetos? Como apoiar dependncia baixa, baixo impacto de modificao e aumento de reuso? Qual o objeto o primeiro objeto, alm da camada de IU, que recebe e coordena uma operao do sistema? Como manter os objeto bem focados, inteligveis, gerenciveis e como o efeito colatervel apoiar Acoplamento Baixo?

Especialista na Informao Acoplamento Baixo Controlador Coeso Alta

4.

Consideraes Finais

Analisando os padres abordados no artigo, vale destacar a importncia que a boa atribuio das responsabilidades em um projeto OO trs para o seu projeto um valor maior no que se refere a padronizao e organizao mesmo. Alm claro, de deixar seu projeto mais apto para futuras mudanas, permitindo a melhor compreenso para os desenvolvedores que sero responsveis pela manutenabilidade do software. Essas atribuies nem sempre so perceptveis em uma primeira viso do desenvolvedor, pois a facilidade de operar com esses padres adquirida com a experincia e a adoo dessas regras desde o incio de um projeto. Visto que inicialmente, se o desenvolvimento no seguir regras e nem planejamento o ciclo de desenvolvimento de um software cresce sem controle e sua estrutura no se torna entendvel por todos, sendo assim, a aplicao dos padres se torna mais complicada. De outro modo, com a adoo dos padres e aplicao da maneira correta, o processo de desenvolvimento do software pode fluir de uma forma bem mais eficiente e funcional.

5.

Referncias

GRASP como atribuir responsabilidades com eficincia, uma introduo (2009). Disponvel em: http://www.brasiltech.net/agilez/2009/09/13/grasp-como-atribuirresponsabilidades-com-eficiencia-introducao-padroes-para-atribuicao-deresposabilidade/. Acesso em 12/08/2011.

Murta, Leonardo. Padres GRASP. Disponvel http://www.professores.uff.br/fcbernardini/files/tpa/Padroes_Projeto_GRASP.pdf. Acesso em 12/08/2011.

em:

Larman, Craig (2007). Utilizando UML e padres: uma introduo anlise e ao projeto orientado a objetos e ao desenvolvimento iterativo, 3. ed. Porto Alegre, Bookman.