 Problemas nas métricas |
| Olá, pessoal. No GENTES anterior (sobre a tese do Pedro, dia 13/08/2008), discutimos alguns problemas de métricas. O GENTES do dia 03/09/2008 terá um paper relacionado. Assim sendo, decidi postar aqui dois dos problemas discutidos para deixar documentado. Além disso, podemos refinar essas idéias aqui no fórum para discutí-las em mais detalhes no GENTES. a) Criação de interface aumenta o acoplamento (métrica CBC). Classe X --> Classe Y (CBC total = 1) Classe X --> Interface <-- Classe Y (apesar da criação de uma interface, que pode teoricamente diminuir o acoplamento, temos CBC total = 2) b) Modularização de um concern em um aspecto. Imaginemos um concern espalhado em 5 classes. Após modularizá-lo em um aspecto, estamos tirando o espalhamento, localizando o concern (mudanças são localizadas) e podemos remover códigos duplicados. Apesar desses ganhos, devido a 5 referências para as classes, a métrica de CBC aumenta... CBC total = 5. | 
|
| Add your comments to the Discussion |
| Oi, Rodrigo. Com relação a sua pergunta "em relação a coupling, não seria mais interessante utilizar DSMs, que consideram bem a noção de interface?" acho que poderia ser uma boa. Mas acho que as métricas podem ser interessantes no contexto da "força" do acoplamento. Claro que essa noção de "força" precisaria ser melhor definida, mas um CBC muito alto mostra que uma classe pode estar super, hiper acoplada com outra. E isso um "x" na DSM não mostra. | MarcioRibeiro | 20 Aug 2008 - 19:32 |
| "mas acho que não dá para ter uma modularização completa de concerns... isso não existe." Beleza!!! Esse é o ponto chave. Modularidade não requer que um concern seja confinado a apenas um artefato. Talvez a discussão sobre modularidade deva ser conduzida em um nivel mais alto, como Parnas defende. Se um concern pode ser projetado independente dos outros, evoluir de forma independente, etc...... pouco importa se ele é implementado em uma, duas, ou dez classes. | RodrigoBonifacio | 18 Aug 2008 - 22:44 |
| em relação a "se você estiver certo, não é possível modularizar várias features"... o que quis dizer é que talvez não seja válido modularizar algumas features "crosscutting" usando aspectos. Outras unidades de modularização podem ser melhores. Acho que quantificação e tangling são informações adicionais que podem ser consideradas para decidir pelo uso ou não de aspectos. Uma dúvida, é comum modularizar features que passam por diferentes camadas em um único aspecto? |
RodrigoBonifacio | 18 Aug 2008 - 22:33 |
| com relação a "Mas aí a análise pode ser no sentido de que o concern de negócio não está mais modularizado, pois possivelmente outras funcionalidades estariam em um outro pacote", concordo. mas acho que não dá para ter uma modularização completa de concerns... isso não existe. a idéia é modularizar o que se deseja desenvolver, manter, entender e reusar (compor, por exemplo para dar suporte a variações em LPS) separadamente. | PauloBorba | 18 Aug 2008 - 21:40 |
| com relação a "Por exemplo, a implementação de uma funcionalidade que se espalha por componentes de GUI, negocio, persistência, exceção, etc. é um concern crosscutting. Mas, conforme conversamos, não vale a pena modularizar esse tipo de concern em um aspecto." também tenho minhas dúvidas... se você estiver certo, não é possível modularizar várias features! fernanda deve analisar isso na tese dela. | PauloBorba | 18 Aug 2008 - 21:36 |
| sobre "ele considera um concern crosscutting se estiver espalhado", acho furado por várias razões. primeiro, se eu modularizo tal concern ele deixa de ser crosscutting? nestes casos é melhor se basear em uma definição precisa. a que faz mais sentido para mim é a do masuhara e kiczales. nela, não existe nem espaço para se dizer A é croscutting. só fala-se A crosscuts B em relação a X se... (olhar paper de ECOOP) seguindo a definição deles, também não parece fazer sentido dizer que "um concern é crosscutting se estiver espalhado"... | PauloBorba | 18 Aug 2008 - 21:32 |
| Em relação ao ítem (b) Não entendi muito bem o cenário Márcio. Após ler a tese do Marc Eady, fiquei com a impressão que a forma como ele calcula o grau de espalhamento e de foco fazem sentido. Talvez apenas as conclusões possam ser revistas. Por exemplo, como Leopoldo destacou, e está bem claro na tese, ele considera um concern crosscutting se estiver espalhado. Talvez até nisso ele esteja correto. A questão que me faço é que talvez nem todo concern que é crosscutting deve ser modularizado em um aspecto. Por exemplo, a implementação de uma funcionalidade que se espalha por componentes de GUI, negocio, persistência, exceção, etc. é um concern crosscutting. Mas, conforme conversamos, não vale a pena modularizar esse tipo de concern em um aspecto. Bom, ele poderia estar modularizado em um único pacote, envolvendo várias classes e aí o pacote poderia ser usado como unidade de modularização e, para efeito de cálculo de scattering, o concern estaria modularizado. Mas aí a análise pode ser no sentido de que o concern de negócio não está mais modularizado, pois possivelmente outras funcionalidades estariam em um outro pacote. |
RodrigoBonifacio | 18 Aug 2008 - 08:51 |
| Em relação ao ítem (a) Discutimos que uma possível solução seria "ponderar" os tipos de relacionamento (dependência, associação, especialização de classe, implementação de interface). Esse pode ser um caminho. Mas talvez seja necessário a condução de experimentos para derivar o peso de cada tipo de relacionamento. Uma dúvida: em relação a coupling, não seria mais interessante utilizar DSMs, que consideram bem a noção de interface? |
RodrigoBonifacio | 18 Aug 2008 - 08:44 |
-- MarcioRibeiro - 16 Aug 2008
Edit | Attach | Print version | History: %REVISIONS% | Backlinks | Raw View | Raw edit | More topic actions
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback