Aulas 10 & 11 &12

julho 22, 2010

Nessas aulas exploramos a estratégia de modularização orientada a aspectos como uma operacionalização importante para as caractéristicas de usabilidade e entendimento, em particular.

Veja que o aspecto de modularização é principalmente importante quanto falamos da transparência da informação, e o caso particular dessa representação estar detalhando o processo.

Vale lembrar o artigo de Osterweil Software processes are software too.

Portanto ao tornarmos o processo mais transparente com a inclusão de operacionalizações estamos no fundo contribuindo negativamente (“hurt” do NFR) para a transparência da informação sobre o processo.

A tese da Claudia propõe uma estratégia que minimiza essa problema.  Ela parte da idéia de que a modularização de informação sobre processos transparentes pode ser beneficiada com o uso da idéia de aspectos.  Portanto empregar a estratégia de aspectos é uma operacionalização do conceito de entendimento quando da transparência da informação.

O conceito de aspectos surgiu em função de problemas que programadores de orientação a objetos enfrentam.  A programação orientada a objetos prega o pensamento taxonômico pensando que coisas estão organizadas segundo famílias cujos os membros herdam características de seus antepassados.  Essa idéia de herança facilita o tratamento da redundância, porque concentra características nas descrições dos antepassados.  Na linguagem de orientação a objetos estamos falando de classes que concentram características de seus antepassados.   Essa estratégia é desejada justamente porque economiza repetições e organiza a memória.

No entanto, a medida que sistemas de software ficam complexos, várias famílias (classes) passam a pertencer (mereologicamente) a um conjunto que tem objetivos comuns (sistema).  Quando isso ocorre, operações que são necessárias em uma família passam também a ser necessária a outras famílias.  Usamos em aula o exemplo das famílias de móveis, veículos e calçados.  Cada uma dessa famílias tem suas características comuns fatoradas na classe, mas se por exemplo estivermos pensando na característica lustrar (uma característica funcional) esta estará presente em todas as três famílias.  Essa repetição torna a descrição do sistema mais complexa.

A idéia de aspectos é uma idéia de fatoração onde a característica fatorada sabe onde deve ser aplicada.  Portanto a fatoração clássica em software, implementada por uma referência de chamada (instruções do tipo “call” ou “função”) são substituídas por estruturas que encapsulam as características fatoradas e que sabem onde devem ser aplicadas.

Com isso é desnecessário explicitar em classes as características comuns a várias classes, porque essas serão tratadas a parte e elas próprias saberão onde serão utilizadas.

Essa inversão de responsabilidade da fatoração é um grande ganho para que as representações fiquem mais simples e mais abstratas, mas recaem em um problema que é como as características comuns sabem onde serão úteis?

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: