A essa altura, espero tê-lo convencido de que métricas de código são aliadas de um arquiteto. Já conhecemos as métricas LOC e CC, e através de outras duas métricas apresentadas (Ca e Ce) entendemos como o indicador I (instability) é produzido.
No post anterior, chegamos a conclusão que de nada adianta coletarmos uma métrica ou indicador se não soubermos exatamente o que queremos analisar. Do contrário, podemos até mesmo ser induzidos a interpretações errôneas a respeito do nosso software. Considero essa a questão mais importante quando lidamos com métricas.
Em alguns casos, é necessário "calibramos" as métricas de acordo com a realidade presente no contexto em que o software está envolvido. Exemplo: o resultado "0.7689" de (I) em um assembly pode ser aceitável no caso de um framework, mas ruim para um CRUD.
A genial figura abaixo, criada por Thom Holwerda, apresenta a medida WTFs/minute (algo como “Que_Porra_é_Essa / minuto”) como um indicador da qualidade de um software.
Interessante notar que, apesar de ser uma piada, a métrica acima poderia ser válida se o contexto assim exigisse. Dependendo da situação, teremos que compor um indicador utilizando vários outros. No exemplo que vimos no post anterior, utilizamos o indicador (I), contudo, não determinamos com antecedência qual análise gostaríamos de fazer.
Proponho agora definirmos como objetivo a seguinte análise para o exemplo mencionado:
Para o framework que estamos analisando, é importante verificarmos tanto a instabilidade de cada assembly como também o quanto ele é abstrato ou concreto. Essa medida será útil para conhecermos o impacto numa eventual troca do framework.
Com um objetivo definido, nossa tarefa de criação e obtenção de um ou mais indicadores parece ter mais sentido, pois estamos utilizando um contexto claro. Como já temos um indicador que nos dá o nível de instabilidade do assembly, precisamos agora de um…
Indicador de "nível de abstração de um assembly"
Novamente, baseado nas teorias do Tio Bob, o indicador será definido da seguinte forma:
A proporção do número de tipos abstratos internos (como por exemplo, classes e interfaces abstratas) em relação ao número de tipos internos total.
O intervalo para este indicador é de 0 a 1, com A = 0 indicando um assembly completamente concreto e A = 1 indicando um conjunto completamente abstrato.
Ou seja:
A = (total de tipos abstratos internos) / (total de tipos internos)
Juntando a métrica (I) obtida no último post com a nova (A) teremos:
Update (01/05/2012): Valores de (I) e considerações.
| Assembly | Alias | (I) | (A) |
| Microsoft.Practices.EnterpriseLibrary.Common | Common | 1 | 0,19776 |
| Microsoft.Practices.Unity | Unity | 0,54913 | 0,2234 |
| Microsoft.Practices.Unity.Interception | Interception | 0,9759 | 0,11245 |
| Microsoft.Practices.ServiceLocation | Service Location | 0,78261 | 0,28571 |
E representando a nossa "cereja do bolo", utilizaremos como forma de apresentação dos resultados um gráfico formado por dois eixos (Instabilidade/Estabilidade x Abstração/Concretude).
Maravilha!
Apresentando os resultados
Plotando os resultados obtidos em um plano cartesiano, considerando um eixo para mostrarmos a relação Instabilidade/Estabilidade e outro para Abstração/Concretude, obtemos o resultado abaixo:
Update (01/05/2012): Nova legenda dos eixos.
Cool! Veja como que a conclusão obtida no post anterior não se mostra verdadeira considerando nossa meta de avaliação. Quanto mais próximo do eixo pontilhado no gráfico, melhor um assembly será para ser substituído, já que este terá um melhor equilíbrio entre as duas medidas.
Continuaremos nossa jornada nos próximos posts.
o common não era o mais estável? nesse gráfico ele ta tendendo a mais instável. eu entendi algo errado? Muito boa essa sua série!
Você entendeu certo, ele é o mais estável. O grande lance é que quando definimos nosso objetivo (coisa que não tínhamos feito antes) os assemblies mais próximos a linha pontilhada indicavam menor impacto em caso de substituição.
O exercício aqui é esse mesmo: despertar a importância do contexto. Por exemplo, se algum deles estivesse nas áreas "vermelhas", certamente dariam muito trabalho para serem substituídas (ou mesmo manutenidas).
Leandro, eu não sou expert em álgebra linear, mas isso realmente ficou estranho, seguindo o raciocínio do Rodrigo.
Se o nível de instabilidade se aproxima de 1 à medida que o assembly é mais instável, e o Common tem uma instabilidade de 0,26445, não consigo ver sentido no gráfico quando ele demonstra ser o mais distante no eixo de instabilidade.
Mesmo compreendendo que o ideal é se aproximar da linha pontilhada (real propósito do indicador) eu imagino que exista algo errado com o eixo de instabilidade deste gráfico.
Note que as medidas de abstração parecem bater com os valores obtidos.
Fala, Daniel, tudo bem?
Sua insistência me fez rever os cálculos e descobrir onde errei. Caramba, obrigado! Eu tinha transcrevido os valores de (I) erroneamente, pegando outra métrica. Cheguei a reler o artigo do Uncle Bob pra ver o que tinha de estranho (http://www.objectmentor.com/resources/articles/oodmetrc.pdf).
Por causa dos valores errados eu fiz conclusões equivocadas. Mas agora está tudo corrigido (espero).
Muito obrigado pela observação, salvou a série de um fiasco! 🙂
Abraços,
Leandro Daniel
Rodrigo, graças a insistência do Daniel pude ver onde errei. Você estava completamente certo nas suas observações. Creio ter corrigido tudo agora.
Obrigado por tentar me alertar, heheheh.
Abraços,
Leandro Daniel
Nós é que agradecemos pelo excelente conteúdo, man. Com certeza um equívoco no plot não transformaria a série num fiasco, parabéns.