BRÁULIO ROBERTO SCHUSTER - … · brÁulio roberto schuster avaliaÇÃo da qualidade de diagramas...
49
BRÁULIO ROBERTO SCHUSTER AVALIAÇÃO DA QUALIDADE DE DIAGRAMAS DE CLASSE UML EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE UTILIZANDO MÉTRICAS. CANOAS, 2009
Transcript of BRÁULIO ROBERTO SCHUSTER - … · brÁulio roberto schuster avaliaÇÃo da qualidade de diagramas...
BRÁULIO ROBERTO SCHUSTER
AVALIAÇÃO DA QUALIDADE DE DIAGRAMAS DE CLASSE UML EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE
UTILIZANDO MÉTRICAS.
CANOAS, 2009
BRÁULIO ROBERTO SCHUSTER
AVALIAÇÃO DA QUALIDADE DE DIAGRAMAS DE CLASSE UML EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE
UTILIZANDO MÉTRICAS.
Trabalho de conclusão do curso de Ciência da Computação do Centro Universitário La Salle – Unilasalle, como exigência parcial para a obtenção do grau de Bacharel em Ciência da Computação.
Orientação: Prof. Me. Abraham Lincoln Rabelo de Sousa
Às famílias,
de sangue e de coração.
AGRADECIMENTOS
Ao Sr. Hugo Pinto Ribeiro, pelo apoio financeiro e intelectual no começo
dessa caminhada.
A minha mãe, meu irmão Zé e minha irmã Jussa, não só por essa conquista,
mas também pela batalha da vida.
A Adriana, que me levantou e empurrou nos momentos de fraqueza.
Aos amigos, que esperam a festa com ansiedade.
Aos professores pela paciência, em especial ao meu orientador Lincoln, sem
o qual não seria possível a realização desse trabalho.
"Ciência da computação tem tanto a ver com o computador como a Astronomia com o telescópio, a Biologia com o microscópio, ou a Química com os tubos de ensaio. A Ciência não estuda ferramentas, mas o que fazemos e o que descobrimos com elas."
Edsger Wybe Dijkstra
RESUMO
Nos projetos de desenvolvimento de software, cada vez mais se tem utilizado o
paradigma de Orientação a Objeto, sendo que os requisitos do sistema a ser
desenvolvido são representados por diagramas UML, de uma maneira visual e em
um alto nível de abstração. A modelagem com UML é semiformal, visto que não
possuem semântica definida. Isso permite um mesmo modelo tenha diferentes
interpretações. Nesse cenário, os diagramas UML possuem influência direta na
qualidade do produto final, o software. Características indesejadas em diagramas
UML poderão resultar em uma má concepção do software, ou ainda levar a
manutenção durante a fase de desenvolvimento, aumentando assim o custo e
tempo do projeto, ou até mesmo em não atendimento dos requisitos. Com base no
estudo de métricas já existentes para diagramas UML, tomando como referência
artigos científicos é apresentado um estado da arte, foram selecionadas duas
métricas, escolhidas pela validação empírica e conceitual por parte de seus autores,
e também pelas mesmas serem citadas em outros artigos. O trabalho ainda avalia
as métricas aplicando-as em um projeto de desenvolvimento de software, não como
validação do projeto ou da métrica, mas como demonstração de sua utilização e
para geração de dados para análise. A métrica proposta auxilia o gerente de projeto,
ou qualquer stakeholder, a avaliar quantitativamente os diagramas UML de um
projeto, sendo um bom indicativo quantitativo na fase inicial de projetos de
desenvolvimento de software, podendo evitar futuras manutenções. O trabalho
aborda não só a indicação de uma métrica, mas também como é sua aplicação e
análise.
Palavras-Chave: Diagramas UML, Métricas, Gerencia de Projetos.
ABSTRACT
In projects of software development, the paradigm of Object Orientation increasingly
have been used, and the requirements of the system being developed is represented
by UML diagrams in a visual way and at a high level of abstraction. Modeling with
UML is semi-formal, since there is no semantics. This allows the same model have
different interpretations. In this scenario, the UML diagrams have direct bearing on
the quality of the final product, the software. Features wanted on UML diagrams can
result in a poorly designed software, or even lead to maintenance during the
development phase, thus increasing the cost and design time, or even not meeting
requirements. Based on the study of metrics to existing UML diagrams, taking as
reference papers presents a state of the art, two metrics were selected, chosen by
the conceptual and empirical validation by their authors, and also for them to be cited
in other articles. The study also evaluates the metrics and applaies them to design a
software development, not as a validation of the project or measure, but as a
demonstration of their use and to generate data for analysis. The proposed metric
helps the project manager or any stakeholder to assess quantitatively the UML
diagrams of a project, being a good quantitative indication in the initial project
development software, can avoid future maintenance. The work covers not only the
indication of a metric, but also how its application and analysis.
Key words: UML Diagrams. Metrics. Projects Management.
LISTA DE ABREVIATURAS
UML – Unified Modeling Language (Linguagem de Modelagem Unificada).
OMG - Object Management Group (Grupo de Gerenciamento Dirigido a Objeto).
IEEE - Institute of Electrical and Electronics Engineers (Instituto de Engenheiros Elétricos e Eletrônicos).
RUP - Rational Unified Process (Processo Unificado da Rational).
XML – Extensible Markup Language (Linguagem de Etiquetas Extensíveis).
OO – Object-Oriented (Orientação a Objeto).
OOD - Object-Oriented Design (Desenho da Orientação a Objeto).
NC – Número de Classes.
NA – Número de Atributos.
NM – Número de Métodos.
NASSOC – Número de Associações.
NAGG – Número de Agregações.
NDEP – Número de dependências.
NGEN – Número de Generalizações.
NGENH – Número de hierarquias de Generalização.
NAGGH – Número de hierarquias de Agregação.
MAXDIT – Máximo DIT.
MAXHAGG – Máximo HAAG.
CK – Chidamber e Kemerer.
WMC - Numero de métodos ponderados por Classes.
DIT - Profundidade de herança da arvore.
NOC – Número de filhos.
CBO – Acoplamento entre objeto de classes.
RFC – Resposta para uma classe.
LCOM – Falta de coesão em métodos.
SUMÁRIO
1 INTRODUÇÃO................................................................................. 09
1.1 Objetivo ........................................................................................... 12
1.2 Método de Pesquisa ....................................................................... 12
2 FUNDAMENTAÇÃO TEÓRICA ....................................................... 15
2.1 Diagramas UML .............................................................................. 15
2.2 Padrões de Desenho de Software ................................................ 16
2.3 Métricas ........................................................................................... 20
2.4 Estado da Arte ................................................................................ 21
2.5 Considerações sobre o capítulo ................................................... 27
3 SELEÇÃO E APLICAÇÃO DAS MÉTRICAS .................................. 28
3.1 Projeto ............................................................................................. 28
3.2 Métrica #1 (Métrica Genero) .......................................................... 30
3.3 Métrica #2 (Métrica CK) .................................................................. 32
3.4 Aplicação das Métricas .................................................................. 34
3.5 Considerações sobre o capítulo ................................................... 41
4 CONCLUSÃO .................................................................................. 42
5 TRABALHOS FUTUROS ................................................................ 44
REFERÊNCIAS................................................................................ 46
9
1 INTRODUÇÃO
Nos projetos de desenvolvimento de software, cada vez mais se tem utilizado o
paradigma de Orientação a Objeto (OO). Segundo Tonsig (2003), a OO passou a se
destacar a partir dos anos 90, e suas principais vantagens são a reutilização do
software e facilidade de manutenção. Tonsig (2003) ainda cita que a OO criou a
expectativa de criar software mais rapidamente, mais confiável e a custo baixo.
“Essencial ao desenvolvimento atual de sistemas de software é o paradigma da
orientação a objetos.” (BEZERRA, 2002 pág. 4).
O paradigma da Orientação a Objeto, em um projeto de desenvolvimento de
software, não é auto-suficiente, ou seja, não basta informar que será utilizado o
paradigma de Orientação a Objeto, o mesmo deve ser representado de alguma
forma. Essa representação é feita nos dias atuais com a UML1 (Linguagem de
Modelagem Unificada), que é o padrão adotado pelo Grupo de Gerenciamento de
Objeto – OMG2 (2007). Segundo Bezerra (2002) e Page-Jones (2001) a UML é uma
linguagem composta por elementos visuais, elaborados para representar sistemas
sobre o paradigma de Orientação a Objeto. Essa representação é feita através de
diagramas que tem por objetivo capturar e representar os conceitos e as
construções de um sistema orientado a objeto. Os diagramas ainda podem ter um
detalhamento descritivo de sua representação visual.
Sobre a UML temos a seguinte definição “Trata-se de uma linguagem com
uma especificação semântica semiformal, que inclui sintaxe abstrata, regras bem-
definidas, e semântica dinâmica.” (PAGE-JONES, 2001 pág. 80). Apesar de a UML
ter regras bem-definida para sua elaboração, sua criação ainda depende do
conhecimento do analista que irá desenhar a UML para representar o sistema a ser
desenvolvido, com seus requisitos e funcionalidades. Como Tonsig (2003) afirma, a
UML não é um processo de desenvolvimento de software, mas sim uma linguagem
para modelar, e é esse o artefato final da UML, um modelo que representa o
software a ser desenvolvido.
1 Do Inglês Unified Modeling Language. 2 Do Inglês, Object Management Group.
10
Apesar das técnicas de elaboração de um diagrama UML, e alguns dos
softwares de apoio onde a mesma pode ser elaborada ter opções que podem
corrigir ou melhorar o diagrama (e.g. refatoração) conforme Fowler (2004), sua
elaboração é feita por um analista e é difícil uma avaliação por outro analista ou
gerente de projeto sem tomar conhecimento de todo o projeto. Mesmo com
conhecimento sobre o projeto e diagramas UML, a análise, ainda assim, é baseada
em fatores subjetivos e qualitativos, o que pode gerar uma modelagem em
desacordo com os requisitos, ou uma modelagem falha. Essa modelagem tem
influência direta no software que será desenvolvido, caso a mesma tenha algum
problema, na fase de desenvolvimento isso pode gerar atraso, insucesso do projeto
ou manutenção nos diagramas e no software, o que gera custos adicionais ao
projeto. Ainda como fator complicador a UML pode ser desenhada em um alto-nível
de abstração (OMG, 2007), o que faz com que detalhes importantes não sejam
considerados na análise subjetiva que será realizada.
Conforme o guia PMBook (2004, pág. 8) “O gerenciamento de projetos é a
aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do
projeto a fim de atender aos seus requisitos”. Por essa ótica, o gerente de projeto,
além dos seus conhecimentos, necessita de ferramentas e técnicas para utilizar em
todas as etapas do projeto, para que o mesmo seja realizado dentro dos requisitos
definidos e tenham sucesso. No que diz respeito a projetos de desenvolvimento de
software com Orientação a Objetos, além dos níveis de conhecimento diferentes
entre gerente de projeto e analista, o gerente pode também não ter conhecimento
algum sobre diagramas UML.
As métricas podem ser aplicadas no processo de desenvolvimento de
software, não só para melhoria do próprio processo, mas também para auxiliar em
estimativas, controles de qualidade e projeto, assim como avaliação de
produtividade (PRESSMAN, 2005). Com uma métrica pode-se criar critérios
objetivos de avaliação da qualidade da UML, para medir e expressar em números
essa medida.
Apesar do foco principal desse trabalho não ser a gerência de projetos, mas
sim métricas para diagramas UML, é importante observar que a qualidade do
produto final de um projeto está ligada diretamente a três fatores, Custo, Escopo e
Tempo (PMBook. 2004). Qualquer alteração em um desses fatores afeta os demais
11
diretamente, e conseqüentemente a qualidade do produto. Utilizando métricas, o
gerente de projeto poderá verificar indícios de problemas que poderão ocorrer na
fase de execução e controle do software a ser desenvolvido, antes do início da
programação propriamente dita, evitando atrasos, custos adicionais e até mesmo
insucesso do projeto.
Diante desse cenário, onde a utilização do paradigma da OO é crescente, e o
mesmo é representado por diagramas UML em projetos de desenvolvimento de
software, surgem alguns questionamentos como: É possível medir quantitativamente
os diagramas UML ainda na fase inicial do projeto? Se for possível, essas medidas
serão bons indicadores de problemas nos diagramas? Esses diagramas afetam
diretamente a qualidade do produto final, ou seja, o software? É possível algum
stakeholder, sem conhecimento técnico, fazer essa análise dos diagramas UML?
Para ajudar a responder esses questionamentos, visando à melhora da
qualidade de software desenvolvido em projetos, o foco desse trabalho é auxiliar o
gerente de projetos, ou qualquer stakeholder do projeto, a avaliar diagramas UML
com métricas quantitativas respondendo a seguinte pergunta: Como e quais
métricas podem ser utilizadas para avaliar a qualidade de diagramas UML em
projetos de desenvolvimento de software?
Assim, a contribuição desse trabalho é indicar uma métrica e avaliar a mesma,
procurando dar um passo a frente na utilização de métricas em projetos reais em
empresas.
Outros pesquisadores já discorreram sobre o tema, com abordagens
diferentes, como por exemplo Yi, Wu e Gan (2004), que além das métricas sobre
diagrama de classe, ainda trabalha a questão da validação empírica sobre as
métricas utilizadas. O artigo de Yi, Wu e Gan (2004), tem como foco principal o
estudo das métricas e análise comparativa das mesmas, com finalidade da
discussão de vantagens e desvantagens. Diferentemente dessa proposta que além
de análises das métricas, pretende auxiliar o gerente de projetos na análise da UML.
12
1.1 Objetivo
Com o intuito de responder as questões já citadas, visando melhorar a
qualidade de software desenvolvido, esse trabalho tem como objetivo a busca de
métricas que possam medir diagramas UML, com indicativos quantitativos.
Essa busca será feita através de pesquisa de artigos científicos que tenham
como proposta principal a utilização de métricas aplicadas em diagramas UML. Com
base nessa pesquisa será elaborado o estado da arte, em seguida serão estudados
os artigos verificando o caminho que o estado da arte indica. Esse estudo pretende
fornecer uma referência para auxiliar gerentes de projetos, ou qualquer stakeholder,
a medir quantitativamente diagramas UML ainda na fase inicial de um projeto, para
fornecer indicações sobre os diagramas UML.
A referência citada será a indicação de quais métricas, das estudadas, que
podem ser aplicadas em um projeto. Para avaliação e demonstração das métricas
indicadas, será selecionado um projeto que tenha diagramas UML necessários para
aplicação da(s) métrica(s) indicada(s).
A aplicação de métricas nos diagramas não visa indicar se os diagramas são
bem elaborados e não contém erros, mas procura indicar se há indícios de mau
desenho dos diagramas, evitando problemas na fase de execução e
desenvolvimento do projeto. Fazendo uma analogia com Dijkstra que afirma “Testes
provam a presença de erros, mas nunca sua ausência”.
Após a aplicação das métricas serão feitas análises dos resultados, e
posteriormente as conclusões. Não será desenvolvida nenhuma ferramenta para a
aplicação das métricas, porém foram utilizadas ferramentas já existentes para
análise.
1.2 Método de Pesquisa
A partir da pesquisa bibliográfica foi realizado um estudo, com base no que foi
proposto, visando a aplicação de uma métrica a ser selecionada, em projetos de
13
desenvolvimento de software que tenham o foco na Orientação a Objeto e com
diagramas UML, avaliando essa métrica. Segundo Wainer (2007), avaliar é um
processo para julgar o mérito e valor de um sistema.
Essa avaliação foi realizada utilizando a métrica selecionada no estudo do
estado da arte, aplicada em um projeto de desenvolvimento de software. Não coube
a esse trabalho definir um número de projetos a serem analisados necessários para
chegar a uma conclusão que possa servir de ajuda a gerentes de projetos, ou caso
contrário uma negativa sobre a métrica.
Para Wainer (2007), existem poucas “leis” na Ciência da Computação, e essas
poucas leis têm as seguintes características, descritas por ele:
“• têm um caráter estatístico - isto é, elas são leis válidas para grandes quantidades de exemplos, mas não necessariamente para um exemplo; • são rasas - isto é, elas se parecem mais com “descobertas,” e não com leis ou teorias gerais que permitem a derivação de várias conclusões (que podem ser posteriormente verificadas ou não); • a maioria delas são datadas - isto é, as leis são válidas para um particular período, e não se espera que elas continuem válidas indefinidamente”.
A proposta desse trabalho não teve a pretensão de formular uma “lei” para a
Ciência da Computação, mas pretendeu gerar algum dado estatístico, para
responder algumas questões como: Será que é viável um gerente de projeto
analisar quantitativamente um diagrama UML através de métricas?
A metodologia utilizada na pesquisa, embora não se tenham realizados
Experimentos, que são manipulações de variáveis para observar o comportamento
de outras, seguiu características descritas a seguir, baseadas em Wainer (2007):
a) quanto à natureza foi uma pesquisa aplicada, por ter como objetivo gerar
conhecimentos para aplicações práticas de problemas específicos,
envolvendo verdades e interesses locais;
b) quanto à abordagem, foi utilizada a abordagem quantitativa por considerar
que tudo pode ser quantificável, o que significa traduzir em números,
opiniões e informações para classificá-las e analisá-las. Requer o uso de
recursos e técnicas estatísticas (percentagem, média, desvio-padrão,
coeficiente de correlação, análise de regressão, etc.);
14
c) quanto aos objetivos a pesquisa foi exploratória visando proporcionar maior
familiaridade com o problema com vistas a torná-lo explícito ou a construir
hipóteses. Envolveu levantamento bibliográfico; análise de exemplos que
estimularam a compreensão. Assumindo, em geral, as formas de Pesquisas
Bibliográficas e Estudos de Caso;
d) quanto ao procedimento técnico foi uma pesquisa bibliográfica e, expo-facto.
Bibliográfica por ter sido elaborada a partir de material já publicado. Expo-
facto pelo estudo ter se realizado após a ocorrência dos fatos.
15
2. FUNDAMENTAÇÃO TEÓRICA
O estudo de conceitos básicos, mas fundamentais, sobre diagramas UML,
mais especificamente qual diagrama será alvo das métricas, fornece subsídios para
compreensão do trabalho, incluindo a apresentação de padrões de desenvolvimento
de software, explorando importantes conceitos a respeito de OO. Essas abordagens
são a base do estudo que é o estado da arte sobre métricas aplicadas a diagramas
UML.
2.1 Diagramas UML
No início dos anos 90, o paradigma da Orientação a Objeto ganhou grande
destaque no desenvolvimento de software; esse destaque, e posteriormente
entusiasmo foi devido a três aspectos: potencial para reutilização de software,
facilidade de manutenção e unificação das fases de análise e programação,
(TONSIG, 2002). Chahal e Singh (2009) chegam a citar que a OO foi anunciada
como a ‘bala de prata’ para solução dos problemas do desenvolvimento de software.
Dois significados conceituais são importantes ressaltar, segundo o dicionário
Aurélio (FERREIRA, 2008), Paradigma que é um modelo ou padrão, e Objeto é
“Tudo que é perceptível por qualquer dos sentidos”. No desenvolvimento de
software, objeto segundo Tonsig (2002), é uma representação abstrata de coisas do
mundo real e Larman (2002) ainda complementa que objetos são coisas, conceitos
ou entidades.
Para representar os objetos no desenvolvimento de software, foi criada a UML
(Unified Modeling Language) ou Linguagem de Modelagem Unificada. A UML é um
meta-modelo que procurou reunir todas as boas práticas da OO, que se tornou
padrão através da OMG, que é o órgão que cuida e regulamenta os padrões de
Orientação a Objeto. O principal objetivo da UML é a criação de modelos para
16
auxilio no desenvolvimento de software com OO. Esses modelos são os diagramas
UML.
A UML atualmente está na versão 2.0 e é composta de 13 diagramas que
representam, em um alto nível, o software que será desenvolvido, os diagramas são
distribuídos em 3 classes (OMG, 2007):
a) diagramas estruturais: diagrama de classes, diagrama de objetos, diagrama
de componentes, diagrama de estrutura composta, pacote de diagramas, e
diagramas de desenvolvimento;
b) diagramas de comportamento: diagrama caso de uso, diagrama de atividade
e diagrama de máquina de estados;
c) diagramas de Interação: diagrama de seqüência, diagrama de comunicação,
diagrama de tempo e diagrama de interação de visão geral.
Como o objetivo principal desse trabalho foi avaliação de métricas em
diagramas UML, foram estudados artigos científicos que aplicaram ou propuseram
alguma métrica nesses diagramas.
A partir dos artigos estudados foi definido que o diagrama UML avaliado seria o
Diagrama de Classe, por ser citado na maioria dos artigos e segundo Yi, Wu, Gan
(2004), Genero, Piattini, Manso e Cantone (2003), Genero, Piatini e Manso (2004),
Tang e Chen (2002), o diagrama de classe é o mais importante diagrama UML,
como se fosse à espinha dorsal do UML. Ainda, Debnath, et. al (2005) afirmam que
o Diagrama de Classe é o principal diagrama UML para sistemas Orientados a
Objeto.
2.2 Padrões de Desenho de Software
Os padrões de desenho de software são padrões que visam auxiliar o
desenvolvimento de software com OO. Basicamente os padrões definem o
problema, a solução para o mesmo e quando aplicar. Esses padrões são utilizados
17
na fase de projeto, especificamente na parte de desenho, e não é tratada
reutilização de código.
Um padrão tem quatro elementos básicos (GAMMA, et al. 2000), que são:
a) nome do padrão: referencia o problema do projeto;
b) problema: descrição do problema e em que contexto ele está;
c) solução: descreve em termos gerais, pois é um padrão e não uma solução
específica como seus elementos atuam e se relacionam;
d) conseqüências: indica os resultados e análises esperados da aplicação do
padrão.
Os padrões mais conhecidos e utilizados são o GRASP “Padrões para
Atribuição de Responsabilidade” (General Responsibility Assignment Software
Patterns) e GoF "Gangue dos Quatro" (Gang of Four). Esses padrões surgiram no
início da década de 90, juntamente com o crescimento da OO, através de Kent Beck
e Ward Cunningham, que propuseram os primeiros modelos.
O padrão GoF é dividido em três famílias que são (GAMMA et al., 2000):
a) padrões de criação composto por:
- Abstract Factory,
- Builder,
- Factory Method,
- Prototype,
- Singleton;
b) padrões estruturais:
- Adapter,
- Bridge,
- Composite,
- Decorator,
- Façade,
- Flyweight,
18
- Proxy;
c) padrões comportamentais;
- Chain of Responsibility,
- Command,
- Interpreter,
- Iterator,
- Mediator,
- Memento,
- Observer,
- State,
- Template Method,
- Visitor.
Não se abordou cada padrão do GoF, pois focou-se o padrão GRASP, que
conforme Larman (2002) “Os padrões GRASP descrevem princípios fundamentais
de atribuição de responsabilidades a objetos.” que é uma das características desse
trabalho. Os padrões GRASP são:
- Controller,
- Creator,
- Expert,
- Law of Demeter,
- Low Coupling,
- High Cohesion,
- Polymorphism e Pure Fabrication.
O interesse em padrões não foi sua aplicação nesse trabalho, mas sim seus
conceitos, no que dizem respeito a diagramas de classe UML.
No padrão Low Coupling (Acoplamento Fraco), Larman (2002) indica que o
acoplamento é a medida de quanto uma classe está ligada a outras, e que o
19
desejável, são classes com baixo acoplamento, o que também é indicado por
Chahal e Singh (2009). Essa característica é desejável, pois um acoplamento de
classes fraco (ou baixo) indica que uma classe não depende de outras, assim sua
reutilização e manutenção é mais simples. Já uma classe com acoplamento forte
(ou alto), indica que a classe depende de muitas outras classes o que pode incorrer
em problemas como difícil compreensão, difícil reutilização e difícil manutenção.
Outro padrão importante é a High Cohesion (Coesão Alta), nesse padrão
Larman (2002) afirma que “... coesão (ou mais especificamente, coesão funcional) é
uma medida de quão fortemente relacionadas e focalizadas são as
responsabilidades de uma classe.”. Page-Jones (2001) ainda define coesão como a
inter-relação das características de uma classe, mais especificamente atributos e
métodos. Com isso uma classe com alta coesão é desejada para um bom projeto
(Chahal e Singh, 2009), uma classe com baixa coesão pode incorrer em problemas
iguais ao acoplamento forte, ou seja, difícil compreensão, difícil reutilização e difícil
manutenção (Larman, 2002), ou conforme Page-Jones (2001), “Uma classe com
baixa (má) coesão apresenta um conjunto de características disparatas.”.
Para um melhor entendimento, no quadro 1 elaborado por Page-Jones (2001),
temos a relação dos elementos que representam a Coesão e Acoplamento de
Classe.
Quadro 1. Inter-relacionamento entre elementos.
PARA:
DE:
Construção de nível-0 (linha código)
Construção de nível-1 (operação)
Construção de nível-2 (classe)
Construção de nível-0 (linha código)
Programação estruturada.
Fan-out de mensagem.
-----------------------
Construção de nível-1 (operação)
Coesão. Acoplamento. -----------------------
Construção de nível-2 (classe)
----------------------- Coesão de classe. Acoplamento de classe.
Fonte: Page-Jones, 2001.
Sobre o quadro 1 pode-se identificar que Coesão de Classe é a ligação de
nível-1 dentro de uma classe (nível-2), ou seja, é a ligação dos métodos dentro de
20
uma classe. O Acoplamento de classe é a ligação de nível-2 entre duas classes, ou
seja, quando uma classe herda alguma característica de outra.
2.3 Métricas
Segundo a IEEE (1998), a finalidade das métricas aplicadas em software é
medir a qualidade do software desenvolvido, ou seja, se o mesmo está de acordo
com os requisitos e atributos do projeto. Apesar do IEEE (1998) indicar que as
métricas podem ser utilizadas em todo ciclo de vida do software, a proposta desse
trabalho é apenas para a fase inicial, mais especificamente nos diagramas UML.
Foi definido que seria na fase inicial, pois é nela que são elaborados os
diagramas UML. Segundo Genero, Piattini, Manso e Cantone (2003), Yi e Wu
(2004), Genero, Piattini e Calero (2002), Genero, Piatini e Manso (2004), quanto
mais cedo é descoberto um problema no designe de um projeto de software, melhor
será a qualidade do mesmo e também menor será o custo de manutenção.
Existem métricas que são aplicadas ao código fonte (GENERO, PIATTINI e
CALERO 2002 e GENERO, PIATTINI e MANSO 2004), mas as mesmas são
aplicadas na fase de desenvolvimento do software, o que foge ao escopo desse
trabalho, que é auxiliar o gerente de projeto a avaliar os diagramas UML ainda na
fase inicial de projetos.
A aplicação de métricas para auxílio ao gerente de projeto não é apenas para
medir a qualidade do diagrama, mas também visa à melhoria na qualidade do
software, bem como o aumento da produtividade da equipe de desenvolvimento
(Bhatti, 2005).
Para a aplicação do estudo, foram selecionadas as métricas CK-suite
(Chidamber e Kemerer, 1994) e ora denominado Métricas Genero (Genero, Piattini e
Calero, 2002). As métricas propostas nesses artigos focam os diagramas UML, mais
21
especificamente os diagramas de classe, e também suas características como o
Acoplamento e a Coesão, que são as principais características de qualidade.
As métricas desses artigos também verificam as relações dos diagramas UML
que são herança, dependência, associação e agregação, entre outras
características.
2.4 Estado da Arte
Conforme já foi citado, esse estudo foi baseado na pesquisa de diversos
artigos científicos, dos quais o quadro 2 apresenta os artigos selecionados, e
estudados, e suas principais características. As características foram determinadas
assim:
a) diagrama UML - O artigo deve ter claramente que uma métrica foi aplicada
em algum diagrama UML e definido qual o diagrama;
b) métrica - Deve ter alguma métrica de estudo no artigo, preferencialmente em
UML;
c) técnica - Como foi aplicada a métrica ao diagrama;
d) resultado - O que a métrica contribuiu;
e) escopo - Onde o autor queria chegar.
22
Quadro 2. Mapeamento do Estado da Arte
Artigo Diagrama UML Métrica Técnica Resultado Escopo
A Comparison of Metrics for UML Class Diagrams
Métrica aplicada em Diagrama de Classe.
Estudou 6 métricas, Métrica Marchesi, Métrica da Genero, Metrica do In, Metrica do Rufai, Metrica do Zhou e Métrica do Kang.
Aplicou a métrica em projetos em universidades com auxilio de alunos e professores.
Indicou a qualidade dos diagramas de classes e características de cada métrica.
Indicar se, e quais, métricas podem auxiliar na fase de iniciação do projeto.
A UML model consistency verification approach based on meta-modeling formalization
Transformação de qualquer diagrama UML para linguagem CLP.
Verifica inconsistências e restrições através do meta-modelo gerado em CLP dos diagramas UML.
Exemplos de transformação de diagramas UML em CLP.
Propôs um modelo CLP para análise de restrições e consistências dos diagramas UML.
Criar um modelo para verificar qualquer modelo UML, e esse “verificador” deve ser unificado como a UML.
Building UML Class Diagram Maintainability Prediction Models
Métrica aplicada em Diagrama de Classe.
Métricas de tamanho e Métricas de complexidade estrutural.
Aplicou com alunos da Universidade.
As métricas ajudam na fase de iniciação do projeto para os designers.
Indicar se as métricas podem ajudar no diagnóstico antecipado, para ajudar designers na manutenção e elaboração de Diagrama de Classe UML.
Empirical analysis of entropy distance metric for UML class diagrams
Métrica aplicada em Diagrama de Classe.
M. Marchesi e, M. Genero
Comparação e análise das métricas.
Apenas comparações. Auxilio para os designers na fase inicial do desenvolvimento.
Empirical Validation of Class Diagram Metrics
Métrica aplicada em Diagrama de Classe.
NC, ND, NM, NAssoc, NAgg, NGEN, NAggH, NGenH, MaxHAgg, MaxDIT
Comparação e análise das métricas.
As métricas estudadas são bons indicadores de manutenção. Podendo ser melhorado o estudo.
Experimentar as métricas e avaliar as mesmas.
23
Artigo Diagrama UML Métrica Técnica Resultado Escopo
Finding “Early” Indicators of UML Class Diagrams Understandability and Modifiability
Métricas aplicadas em Diagrama de Classe.
Tamanho:
(NC), (NA) e (NM).
Estrutural:
(Nassoc), (Nagg), (Ndep), (Ngen), (NgenH), (NAggH), DIT Máximo (MaxDIT), HAgg máximo (MaxHAgg).
Investigação, através de experimentos se as métricas propostas são boas preditoras para compreensão e manutenção de Diagramas de classe UML.
Existe uma boa possibilidade de construir um modelo e o mesmo ser útil para análise de Designers no ciclo de vida inicial do projeto. Com ressalvas de Briand e Wust que indicam que os diagramas ainda não estão completos nessa fase inicial.
Obter indicadores para compreensibilidade e manutenção dos diagramas de classe, para um diagnóstico antecipado.
Improving the quality of UML models in practice
Diagramas UML. Hipóteses. Elaboração e estudo das hipóteses.
Não indica nenhuma métrica apenas contribuições esperadas.
Formal um conjunto de regras para melhorar a qualidade dos diagramas UML na fase de desenvolvimento dos mesmos.
Metrics to Study Symptoms of Bad Software Designs
Métrica aplicada em Diagrama de Classe.
CK métricas. Aplicação das métricas em um estudo de caso. Obs.: O mesmo não é apresentado no trabalho, somente as análises e resultados.
As métricas aplicadas, visando determinados sintomas, dão uma boa indicação de mau-design.
Explorar sintomas de mau-design, através do estudo das métricas selecionadas.
Measuring OO Design Metrics from UML
Métrica aplicada em Diagrama de Classe, Diagrama de Colaboração e Diagrama de Atividade.
CK métricas, e mais quatro que são Inheritance Coupling (IC), Coupling Between Methods (CBM), Number of Object/Memory Allocation (NOMA) e Average Method Complexity (AMC).
Transformação dos diagramas para o modelo RS(Rational Rose) e posterior aplicação das métricas no modelo estático gerado, em um sistema bancário simplificado.
Acreditam que seu estudo vai sair do estado da prática para o desenho efetivo de métricas e conseqüentemente uma maior utilização de métricas em UML.
Desenvolver uma ferramenta facilitadora baseada em métricas para dar um diagnóstico na fase de iniciação.
24
Artigo Diagrama UML Métrica Técnica Resultado Escopo
Metric-Based Selective Representation of UML Diagrams
Métricas aplicadas em Diagrama de Classe.
Ferramenta IDEA. Aplicação da ferramenta em diversos sistemas e classes diversas.
Acreditam que sua técnica ajuda a entender sistema de uma maneira bottom-up, ou seja, de baixo para cima.
Desenvolver e aplicar uma ferramenta para verificar qualidade de softwares desenvolvidos em Java.
OOA Metrics for the Unified Modeling Language
Métricas aplicadas em Caso de Uso, Pacotes e Diagrama de Classes.
Métricas UC1, UC2, UC3, UC4, CL1, CL2, CL3, CL4, CL5, PK1, PK2, PK3, OA1, OA2, OA3, OA4, OA7.
Aplicadas as métricas em diversos projetos.
Foi gerado um kit de ferramentas que são bons “medidores” da qualidade de um projeto de OO com UML.
Permitir, através das métricas, uma estimativa de esforço, custo e tempo de desenvolvimento, bem como a qualidade da OO.
Fonte: Autoria própria, 2009.
25
Com base na revisão do estado da arte, elaborado e representado pelo quadro
2, cada artigo foi analisado mais profundamente, identificando qual a proposta de
métrica e em que diagrama a mesma era aplicada. Esse estudo serve para
determinar métricas já propostas anteriormente que possam ser aplicadas em um
diagrama UML na fase inicial de um projeto de desenvolvimento de software, pelo
gerente de projeto, ou qualquer stakeholder. Não foram predeterminados critérios de
exclusão ou de seleção das métricas e/ou diagramas UML para os artigos.
Como o gerente de projeto não é necessariamente um analista experiente em
OO, nem um designer em diagramas UML, o trabalho procurou selecionar métricas
com uma base teórica e empírica, e de fácil aplicação. Visando contribuir com o
estudo de métricas, passando de propostas para aplicações efetivas e assim
criando uma validação cada vez mais abrangente, e com os projetos, indicando
como utilizar e analisar as métricas.
O trabalho não tem a pretensão de ser um elo entre estudos acadêmicos e
empresas, mas sim uma contribuição no avanço desses estudos. Assim cada vez
mais as métricas para diagramas UML serão avaliadas e validadas pela comunidade
acadêmica e, quem sabe, comercial.
Com base nesse cenário, seguem as observações realizadas em cada artigo.
No artigo “A Comparison of Metrics for UML Class Diagrams.”, os autores
avaliaram seis métricas já propostas por outros autores e fizeram um comparativo
dos indicativos de cada uma. Não propuseram nenhuma métrica nova.
Em “A UML model consistency verification approach based on meta-modeling
formalization.” a proposta desse trabalho foi a transformação dos diagramas UML
para uma formalização em CLP (Constraint Logic Programming) ou Programação
em Lógica com Restrições. Trabalho interessante, mas ainda em fase de estudos e
de difícil aplicação, necessita de aplicativos para implementação e análise.
O artigo “Building UML Class Diagram Maintainability Prediction Models.”
propõe métricas de estrutura e de tamanho para diagramas de classe, com base
teórica e empírica. É baseado em três outros artigos dos mesmos autores, que
serão citados posteriormente. Artigo muito citado por outros artigos e que servirá de
base para o trabalho atual.
26
Os autores de “Empirical analysis of entropy distance metric for UML class
diagrams.“ fazem uma análise comparativa entre algumas métricas sobre diagramas
de classe, procurando validar cada métrica. Indicam que tem erros e deficiências,
mas existe uma boa possibilidade de construir modelos para diagramas UML
indicando sua manutenção na fase inicial de projetos.
Mesmos autores de “Building UML Class Diagram Maintainability Prediction
Models”, no artigo “Empirical Validation of Class Diagram Metrics.” foram aplicadas
as mesmas métricas do primeiro, e aplicadas utilizando o modelo de experimento
GQM.
Em “Finding “Early” Indicators of UML Class Diagrams Understandability and
Modifiability.” também é citado o artigo “Building UML Class Diagram Maintainability
Prediction Models”, e são os mesmos autores. Trabalho posterior onde são feitas
novas validações empíricas sobre as mesmas métricas e estudas novas hipóteses.
O autor de “Improving the quality of UML models in practice.” define algumas
hipóteses e propõe algumas soluções para cada uma das hipóteses, não propõe
nenhuma métrica efetivamente.
Os autores de “Metrics to Study Symptoms of Bad Software Designs.” aplicam
o conjunto de métricas CK em um estudo de caso, visando explorar e identificar
problemas de mau desenho. Não propõe nenhuma métrica nova, mas validaram a
suíte CK com outra abordagem estatística.
A proposta no artigo “Measuring OO Design Metrics from UML” é a
transformação dos diagramas UML para Rational Rose e aplicação das métricas da
suíte CK e mais quatro para avaliar a complexidade dos diagramas. É proposto
também um algoritmo para o Rational Rose. Não propõe nenhuma nova métrica,
apenas aplica a suíte CK e mais quatro para comparações.
No artigo “Metric-Based Selective Representation of UML Diagrams.” não foi
proposta nenhuma nova métrica, apenas faz experimentos com a ferramenta IDEA,
utilizando inclusive engenharia reversa.
Por fim, a autora de “OOA Metrics for the Unified Modeling Language” propõe
uma série de métricas e procura validar em projetos, além da qualidade de
27
diagramas, procura estimar esforço, custo e tempo, o que gera um formalismo muito
complicado de aplicar sem uma ferramenta de auxilio.
2.5 Considerações sobre o capítulo
Partindo do conhecimento básico e acadêmico de diagramas UML, foi
importante um estudo mais aprofundado, não só para conhecer todos os diagramas,
mas também para conhecer detalhes de sua elaboração. Bem como os padrões de
desenho de software, não por sua estrutura, mas sim por seus conceitos sobre a
OO, que servirão de base para análises das métricas.
Para as métricas poderia ser feito um trabalho a parte, pois existem muitos
trabalhos e muitos autores com diferentes abordagens, mas foi importante para
verificar que as métricas são cada vez mais utilizadas em desenvolvimento de
software.
Com esses conceitos, foi possível um estudo mais qualificado do estado da
arte, e procurando concatenar esses três balizadores para identificar quais artigos
seriam relevantes. Assim, foi possível montar um estado da arte com artigos
científicos, onde todos abordavam o tema do trabalho, sendo que esse estado da
arte é fundamental para o trabalho, pois é dele que foi selecionada a métrica e
diagrama para avaliação, bem como conceitos e idéias de diversos autores.
No estado da arte, o que chamou muito a atenção foram alguns artigos
citados por diversos autores, o que indica ser uma boa referência para escolha de
métricas e diagramas, assim como foi identificado que alguns trabalhos não são
representados apenas em um artigo, mas sim em vários artigos e muito tempo de
estudo, que culminaram em um determinado artigo.
Também tiveram artigos menos relevantes, mas somente com o estudo de
cada um foi possível para chegar a seleção das métricas e diagramas, e sua
aplicação, conforme será visto no próximo capítulo.
28
3. SELEÇÃO E APLICAÇÃO DAS MÉTRICAS
Com base no estado da arte apresentado no capítulo anterior, foram
selecionadas duas métricas, Métrica Genero e Métrica CK, que se destacaram
devido as suas fundamentações teóricas e empíricas, e também pela facilidade de
aplicação nos diagramas e análise dos indicadores.
Após a definição das métricas, foi selecionado um projeto para aplicação e
análise das métricas.
O projeto selecionado foi obtido de uma disciplina do curso de Ciência da
Computação, o projeto Tranex. Sendo que o objetivo principal não é analisar a
qualidade dos diagramas do projeto Tranex. Não obstante, deve-se ressaltar a
importância desse artefato para o trabalho acredita-se que a utilização de projetos
de empresas seria o ideal, mas isso não foi possível.
A primeira métrica, embora apresente características desejáveis,
efetivamente não foi aplicada no projeto devido a particularidades de suas variáveis.
Mas os resultados e conclusões apresentados nesse estudo da Métrica Gênero são
importantes para corroborar a validade da utilização de métricas na fase inicial de
projetos, em diagramas UML.
A segunda métrica selecionada foi aplicada no projeto onde foi possível
verificar sua aplicabilidade e geração de dados estatísticos para análise comparativa
com os indicadores da métrica.
3.1 Projeto
Para a análise e aplicação das métricas selecionadas, se utilizou os diagramas
de classe do projeto Tranex, esse projeto foi desenvolvido por alunos do Centro
Universitário La Salle, UNILASALLE para a disciplina Laboratório de Engenharia de
Software, do sétimo semestre. Foi selecionado um projeto do meio acadêmico,
29
devido à dificuldade de se obter projetos com aplicação comercial em empresas,
mas é importante ressaltar que o projeto selecionado teve uma boa avaliação na
disciplina em que foi apresentado e têm todos os artefatos necessários para um
projeto, principalmente diagramas UML que é o foco desse trabalho.
Figura 1. Diagrama de Classes Projeto Tranex
Fonte: Disciplina de Laboratório de Engenharia de Software, 2009.
30
Essa mesma dificuldade de conseguir dados concretos foi relatada em vários
estudos, incluindo Genero, Piattini e Calero (2002). Certamente quanto mais
projetos industriais forem utilizados para avaliar as métricas mais dados reais serão
obtidos e uma melhor análise das métricas será realizada. Mas é importante
salientar que o foco do estudo de métricas não foi a avaliação de um projeto e sua
aplicação específica, mas sim a análise da concepção de um sistema orientado a
objeto através das métricas Chidamber e Kemerer (1994).
A figura 1 apresenta o esquema de diagramas de classe do projeto Tranex. O
escopo do projeto era o desenvolvimento de um software para controle da logística
de entrega e distribuição de carga, por meio rodoviário, entre filiais de uma empresa.
3.2 Métrica #1 (Métrica Genero)
A primeira métrica que chamou a atenção no estado da arte foi a do artigo
“Building UML Class Diagram Maintainability Prediction Models” onde é feita uma
validação conceitual e empírica da métrica proposta. É importante ressaltar que
esse artigo foi um estudo de três anos, onde foram publicados outros seis artigos
que fizeram parte desse estudo. Dos autores desse artigo, e dos seis que serviram
de base para o estudo, apenas Marcela Genero participou de todos, por isso
passamos a denominar esse métrica de Métrica Genero.
A proposta da métrica Genero é medir os diagramas de classe, para isso foi
criada uma tabela dividida em dois tipos, métricas de tamanho e métricas de
complexidade estrutural, e onze subtipos, conforme quadro 3.
O principal objetivo do artigo de Genero foi investigar através de experimentos,
se as métricas propostas no quadro 3 eram bons indicadores de manutenção nos
diagramas de classe. Se confirmada essa hipótese, essas métricas serão bons
indicadores e decisões poderão ser tomadas ainda na fase de desenho dos
diagramas, melhorando assim a qualidade no desenvolvimento de software.
31
Quadro 3. Métrica Genero
Tipo Métrica Definição da Métrica
Numero de Classes (NC). Número total de classes.
Número de atributos (NA). Número total de atributos. Métrica Tamanho
Número de métodos (NM). Número total de métodos.
Número de associações (NASSOC). O número total de associações.
Número de agregações (NAGG). O número total de relações de agregação (cada um "todo-parte" par de um relacionamento de agregação).
Número de dependências (NDEP). O número total de relações de dependência.
Número de generalizações (NGEN). O número total de relacionamentos de generalização (cada um "pai-filho" par de um relacionamento de generalização).
Número de hierarquias de Generalização (NGENH). Número total de hierarquias de generalização.
Número em hierarquias de Agregação (NAGGH). O total número de hierarquias de agregação (todo-estruturas parte.)
Máximo DIT (MAXDIT). É o valor máximo DIT obtidos para cada classe do diagrama de classe. O valor da DIT uma classe dentro de uma hierarquia de generalização é o caminho mais longo da classe para a raiz da hierarquia.
Métrica Complexidade
Estrutural
Máximo HAGG (MAXHAGG). É o máximo HAGG valor obtido para cada classe do diagrama de classe. O valor HAGG para uma classe dentro de uma hierarquia de agregação é o mais longo caminho da classe para as folhas.
Fonte: Genero, Piatini e Manso (2004).
Para alcançar esse propósito Genero elaborou testes de tempo de
Manutenção, tempo de Entendimento, Exatidão Manutenção e Plenitude
Manutenção. Os testes foram aplicados com alunos de duas universidades,
Universidade de Castilla-La Mancha da Espanha e Universidade de Roma da Itália.
E o principal objetivo desses testes foi coletar os tempos de Manutenção em
diagramas de classe.
Os autores utilizaram o Modelo Multivariado Linear para análise dos
resultados, pois esse modelo considera as relações das variáveis independentes e
dependentes. Nesse artigo os autores consideraram como variáveis independentes
as métricas do quadro 3, e como variáveis dependentes os tempos dos testes de
tempo de Entendimento e o tempo de Modificação.
Utilizando o Modelo Multivariado Linear, os autores testaram e avaliaram cada
variável dependente com as independentes, verificando os resíduos do modelo para
32
validar as hipóteses. Após ajustes estatísticos, e análise de ameaças das validades
Interna Externa, Construção e Conclusão, os autores chegaram a algumas
conclusões interessantes.
Apesar da validação empírica feita nesse artigo de Genero, não foi possível a
aplicação das métricas no projeto Tranex, pelo fato de que o Modelo Multivariado
Linear utilizado para análise usa variáveis independentes e dependentes e no caso
da métrica proposta as variáveis dependentes são os tempos de Manutenção e
Entendimento coletados com alunos de faculdades. Para obter os dados relativos a
tempo de manutenção e entendimento, seria necessária preparação de material
adequado para coleta dos dados, captação de pessoal para realizar os
experimentos, local para realização, entre outros elementos. O tempo de um
semestre é exíguo para a execução dessa coleta, levando em consideração também
que essa preparação exige também uma fundamentação teórica.
Não obstante suas conclusões são positivas no sentido que a aplicação de
métricas em diagramas UML na fase inicial de projetos são bons indicadores para
tomada de decisão, e essas conclusões são importantes conforme será abordado
na seção 3.4 Aplicação das Métricas.
3.3 Métrica #2 (Métrica CK)
A segunda métrica selecionada foi uma suíte de métricas do artigo “A Metrics
Suite for Object Oriented Design”, que apesar de não constar no estado da arte, é
citado em diversos artigos como Genero, Piattini, e Calero (2002), Chahal e Singh
(2009) e Tang e Chen (2002). Também foi considerado para seleção, pois os
autores estabeleceram e justificaram três metas no artigo que são:
a) propor métricas com fundamento teórico;
b) avaliar as métricas com critérios de validade e;
c) apresentar dados empíricos.
33
O foco das métricas também é o diagrama de classes, pois conforme seu
entendimento, independente da metodologia OOD selecionada o diagrama de
classe é o objeto central da OO, Chidamber e Kemerer (1994).
A partir dos conceitos da ontologia de Bunge, onde os autores procuram
relacionar as características de objetos, principalmente atributos e propriedades, e
suas relações; e sobre a Metodologia OOD de Booch que indica etapas e seus
detalhes no design da OO, os autores definem um conjunto de seis métricas, agora
denominadas Métricas CK, conforme quadro 4. Com isso os autores cumprem sua
meta 1.
Depois, foi selecionada uma lista de propriedades desejáveis para avaliação
das métricas propostas, essa lista foi elaborada por E. Weyuker no artigo
“Evaluating software complexity measures.” com seis propriedades, que foram
analisadas com cada métrica do quadro 4. Os autores utilizaram essas propriedades
para avaliar as métricas propostas cumprindo a meta 2, mesmo com críticas de
outros autores como N. E. Fenton no artigo “Software Metrics, A Rigorous
Approach.” e H. Zuse em “Properties of software measures.”. Chidamber e Kemerer
(1994) verificam que as métricas propostas no quadro 4 satisfazem a maioria das
propriedades estabelecidas.
Para cumprir a meta 3, os autores conseguiram com uma organização dois
projetos, um com 634 classes e desenvolvido em C++, e um segundo projeto com
participação de mais de trinta engenheiros envolvidos e 1459 classes, desenvolvido
em SmallTalk. Apesar dos projetos terem linguagens de programação diferente, isso
não afeta as métricas propostas, pois as mesmas são aplicadas aos diagramas de
classe, e não ao código fonte.
Quadro 4. Métricas CK
Nome Métrica Definição da Métrica
Weighted Methods Per Class (WMC) Numero de métodos ponderados por Classes.
Depth of Inheritance Tree (DIT) Profundidade de herança da arvore.
Number of Children (NOC) Número de filhos. Número de subclasses imediatas subordinadas a uma classe na classe hierarquia.
Coupling between object classes (CBO) Acoplamento entre objeto de classes.
Response For a Class (RFC) Resposta para uma classe.
Lack of Cohesion in Methods (LCOM) Falta de coesão em métodos.
Fonte: Autoria própria, 2009.
34
3.4 Aplicação das Métricas
Conforme já mencionado a primeira métrica selecionada, a Métrica Genero,
não foi aplicada no projeto Tranex. Inicialmente essa métrica foi selecionada para
aplicação no projeto, porém durante o estudo da mesma foi verificado que não teria
validade devido ao fato que as variáveis dependentes para utilização do Modelo
Multivariado Linear, selecionado pelos autores, são os tempos de manutenção e
entendimento dos diagramas de classe. Principalmente por falta de material humano
e tempo para preparação de material adequado para coleta dos dados. Mesmo com
dados de 50 alunos Genero, Piattini e Cantone (2003), concluem que o Modelo
Multivariado Linear pode não ser preciso devido ao tamanho dessa amostra ser
pequena.
Porém as conclusões apresentadas nesse estudo são relevantes, no que diz
respeito a aplicação de métricas na fase inicial de projetos. Das suas conclusões é
importante ressaltar que Genero, Piattini e Cantone (2003) concluem também que
os tempos de Compreensão e Manutenção têm relação com as métricas de
Tamanhos e Estruturais, conforme quadro 3. Isso serve de embasamento para
aplicação da segunda métrica selecionada, a Métrica CK.
Apesar da Métrica CK não abordar suas métricas com a divisão de tamanho e
estrutura, pode-se fazer a seguinte subdivisão do quadro 4:
a) métricas de tamanho: WMC, NOC;
b) métricas de estrutura: DIT, CBO, RFC, LCOM.
Após análise dos diagramas de classe do projeto Tranex, aplicando as
definições de Chidamber e Kemerer (1994), os valores absolutos para a Métrica CK,
ficaram representados conforme quadro 5, onde C1 a C14 são as classes.
Uma ressalva sobre a métrica RFC é que para identificar esses métodos temos
dois caminhos, ou o método já foi implementado o que não é o foco do trabalho, ou
o diagrama de seqüência especifica essas relações, o que não tem no projeto
35
Tranex. Conforme Chidamber e Kemerer (1994) RFC é o conjunto de métodos de
uma classe que podem dar resposta a uma mensagem recebida pela classe. Essa
resposta pode ser para os objetos da classe ou para outras classes, com isso essa
métrica é uma medida dos atributos do objeto e também uma medida da
comunicação entre classes. Portanto conclue-se que a métrica RFC poderia ser
dividida em duas métricas. Então são considerados todos os métodos da classe
como RFC, independente de ser privado, publico ou protegido.
A métrica LCOM é a coesão interna da classe, sendo que essa característica
só pode ser identificada com a implementação da classe, o que também não é o
foco do trabalho, portanto essa variável não foi tratada nas análises.
As demais métricas do quadro 4 são captadas do diagrama Tranex da figura 1,
conforme segue:
1- As classes ficam assim denominadas:
C1: Componentes
C2: Forms
C3: FormSistema
C4: FormRotas
C5: FormDestinos
C6: FormUsuarios
C7: FormUsuarios
C8: controle
C9: sistema
C10: Rotas
C11: Destinos
C12: entregas
C13: usuario
C14: DAO
36
2- Métrica WMC, é a quantidade de métodos que uma classe tem. Como
exemplo, analisando a figura 1 temos a classe C1 que possue 3 métodos que
são getTextBox, getSelectElement e button. Para ilustrar, na figura 2 segue a
classe C1, ela é dividida em três retângulos, onde o primeiro é o nome da
classe, o segundo tem os atributos e o terceiro os métodos. Para as demais
classes, basta seguir o mesmo padrão.
Figura 2. Classe C1 (Projeto Tranex)
Fonte: Disciplina de Laboratório de Engenharia de Software, 2009.
3- Métrica DIT, é a profundidade da classe no diagrama, contando a quantas
classes está ligada até a raiz. No caso do diagrama da figura 1, a raiz é a
classe C1, nesse caso seu DIT é zero.
4- Métrica NOC, é o número de classes ligadas diretamente a uma classe,
abaixo dela. No caso da classe C1 seu NOC é 1, pois abaixo dela está
somente a classe C2, já para a classe C2 seu NOC é 5, pois abaixo tem as
classes C3 a C7.
5- Métrica CBO, é a quantidade de classes em que uma classe está acoplada,
ou seja, usa ou dispõe de um método. Nesse caso tem que haver herança
entre as classes, ou fornece ou herda o método, o número CBO de cada
classe são todas as classes ligadas a uma classe por associação ou
dependência. No caso da classe C1 é 1.
Quadro 5. Valores Métrica CK do Projeto Tranex Classes C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14
Métrica WMC 3 4 4 3 3 3 3 3 2 8 3 5 10 2 DIT 0 1 2 2 2 2 2 3 4 4 4 4 4 5 NOC 1 5 1 1 1 1 1 5 1 1 1 1 1 0 CBO 1 1 1 1 1 1 1 10 1 1 1 1 1 5 RFC 3 4 3 3 3 3 3 3 2 8 3 5 10 2 LCOM - - - - - - - - - - - - - -
Fonte: Autoria própria, 2009.
37
Depois de apurados os valores absolutos foi aplicado o cálculo de correlação
de Pearson e Spearman, conforme tabelas 1 e 2.
A correlação de Pearson é utilizada para analisar o conjunto de Métricas CK
por Chahal e Singh (2009) e a correlação de Spearman por Chidamber e Kemerer
(1994). Correlação, segundo Crespo (2009), é “Quando duas variáveis estão ligadas
por uma relação estatística,...”. As correlações procuram indicar relações de duas
variáveis de uma mesma população. Essa indicação é demonstrada por um índice
entre 1 e -1, onde 1 indica uma relação perfeita e positiva, -1 uma relação perfeita e
negativa e zero quando não há correlação entre as variáveis, ou seja, são
independentes (CRESPO 2009). Na tabela 3 são apresentados os níveis de
correlação e seus significados.
Tabela 3. Níveis de Correlação Coeficiente Descrição + 0,60 a 1,00 Correlação positiva forte. Para 1,00 é perfeita. + 0,30 a 0,59 Correlação positiva fraca. + 0,01 a 0,29 Correlação positiva muito fraca. 0,00 Nenhuma Correlação - 0,01 a 0,29 Correlação negativa muito fraca. - 0,30 a 0,59 Correlação negativa fraca. - 0,60 a 1,00 Correlação negativa forte. Para -1,00 é perfeita.
Fonte: Autoria própria, 2009.
Para aplicação dos cálculos de Pearson e Spearman, inicialmente foi utilizado
o software PASW Statistics versão 18 de teste da empresa SPSS. Como o tempo
de teste foi de apenas 21 dias e a empresa não prorroga esse prazo, foi utilizado o
plugin StatistiXL para o Microsoft Excel.
Como a correlação deve ser entre duas variáveis, foi considerado cada
conjunto de métricas do quadro 5 como uma variável, e cada métrica foi comparada
com as demais, na busca de achar uma relação significativa para o projeto Tranex.
As tabelas 1 e 2 apresentam os valores obtidos dos cálculos de Pearson e
Spearman, no cruzamento de cada métrica com as demais. Como exemplo da
correlação de Pearson, o cruzamento dos valores da métrica WMC do quadro 5,
com os valores da métrica CBO apresenta um valor de -0,207, o que é uma
correlação negativa e muito fraca.
38
Tabela 1. Correlação de Pearson (Projeto Tranex) WMC DIT NOC CBO RFC LCOM
WMC 1,000 DIT 0,260 1,000
NOC -0,045 -0,576 1,000 CBO -0,207 0,000 -0,184 1,000 RFC 1,000 0,356 0,268 -0,122 1,000
LCOM ------- ------- ------- ------- ------- 1,000
Fonte: Autoria própria, 2009.
Tabela 2. Correlação de Spearman (Projeto Tranex) WMC DIT NOC CBO RFC LCOM
WMC 1,000 DIT 0,952 1,000
NOC 0,236 0,192 1,000 CBO 0,564 0,048 0,575 1,000 RFC 0,000 0,952 0,236 0,564 1,000
LCOM ------- ------- ------- ------- ------- 1,000
Fonte: Autoria própria, 2009.
Assim, analisando os resultados das tabelas 1 e 2, verifica-se que as variáveis
que tem uma correlação significativa no projeto Tranex são:
a) para Pearson: WMC x RFC;
b) para Spearman: WMC x DIT, DIT x RFC.
Com esses dados podem-se fazer duas análises, a primeira intuitiva, conforme
sugere Chahal e Singh (2009), e a segunda através de uma função linear
verificando o diagrama de dispersão (CRESPO 2009).
Para a correlação de Pearson nas variáveis WMC x RFC, não é necessário
elaborar o diagrama de dispersão, pois se pode verificar pelo quadro 5 que os
valores são iguais, o que implicará em uma correlação perfeita e um diagrama
também perfeito.
Já nos diagramas para a correlação de Spearman, entre as métricas WMC x
DIT e DIT x RFC, apesar da correlação ser forte os diagramas apresentam uma
dispersão, indicando que não há relação significativa, ou seja, para cada par de
variáveis WMC x DIT e DIT x RFC não existe uma relação estatística relevante,
conforme figuras 3 e 4 respectivamente.
39
Figura 3. Diagrama de Dispersão (WMC x DIT)
Correlação Spearman
0123456
0 2 4 6 8 10 12
WMC
DIT
Fonte: Autoria própria, 2009.
Figura 4. Diagrama de Dispersão (DIT x RFC)
Correlação Spearman
02468
1012
0 1 2 3 4 5 6
DIT
RF
C
Fonte: Autoria própria, 2009.
Para a análise intuitiva será utilizada o quadro 6 conforme sugere Chahal e
Singh (2009). Na última coluna do quadro 6, o grau de correlação indica sintoma de
mau desenho, onde seus autores usam a o termo +vê para correlação positiva e –vê
para correlação negativa.
40
Quadro 6. Noções intuitivas sobre as propriedades de desenho orientado a objeto.
No. Noção Intuitiva Métricas Tipo de correlação, indicando sintomas de mau desenho.
1. Quanto maior é o tamanho de uma classe, menor será a coesão.
WMC, LCOM +ve
2. Classes profundas na hierarquia são especializadas, fazendo apenas uma tarefa de cada vez, então a coesão é maior.
DIT, LCOM +ve
3. Tendo em mente duas primeiras hipóteses, as classes profundas na hierarquia são de tamanho pequeno.
WMC, DIT +ve
4. Quanto maior é o tamanho de uma classe, mais responsabilidades, maior serão as referências de outras classes.
WMC, CBO, & RFC
+ve
5. Número de subclasses está mais perto do topo da hierarquia.
NOC, DIT -ve
6. Um grande número de filhos implica que a classe atende a requisitos mais diversificados de forma que a coesão será baixa.
NOC, LCOM +ve
Fonte: Chahal e Singh (2009).
Com base na tabela 3, podemos verificar que, conforme a noção número 3, o
projeto Tranex pode ter um problema de desenho, pois a correlação entre WMC e
DIT é forte, o que não é desejado. Sobre essa noção, verificando a figura 1, pode-se
notar que a profundidade das classes C9 a C13 é alta comparada com o número de
métodos das mesmas, o que indica que talvez tenha que ter uma classe na camada
de controle com métodos comuns a essas classes. Certamente que para esse caso
especificamente deve prevalecer a opinião de um especialista.
Com referência a tabela 3, no projeto Tranex não há indícios de má concepção
para as noções 1, 2, 4, 5 e 6 do quadro 6. O que não indica necessariamente que o
diagrama de classes está perfeito e que não terá nenhuma manutenção na fase de
desenvolvimento.
41
3.5 Considerações sobre o capítulo
Uma das maiores dificuldades do trabalho foi a captação de projetos de
desenvolvimento de software reais de empresas. Essa dificuldade também foi
expressa por alguns autores dos artigos estudados. Mas foi considerado que o
projeto não é o foco principal do trabalho, ele é um artefato importante para o
estudo, mas não o foco principal, que são as métricas selecionadas com base no
estado da arte.
Certamente a análise apenas do projeto Tranex não nos dá um parecer final
sobre as métricas, mais projetos e preferencialmente de empresas devem ser
analisados com as métricas propostas nesse trabalho. Mas, pode-se verificar que,
das métricas selecionadas, uma foi muito importante para o embasamento,
ratificando a idéia que podem ser utilizadas métricas em diagramas UML e a
segunda que foi efetivamente aplicada no projeto Tranex.
Por fim os experimentos realizados foram positivos no sentido de que a
utilização de métricas para diagramas UML são bons indicadores de mau desenho,
utilizando recursos estatísticos proposto pelos autores selecionados, e pode-se
chegar a algumas conclusões com relação aos questionamentos feitos nesse
trabalho.
42
4. CONCLUSÃO
Durante a pesquisa e primeira avaliação dos artigos sobre métricas e UML,
ficou claro que a análise de desenvolvimento de software utilizando métricas é
bastante antigo, anterior mesmo a Orientação a Objeto. Isso indica que a utilização
de métricas na área da computação já está bastante avançada, inclusive na área de
Gerência de Projetos muitas métricas são utilizadas, não obstante tem muito terreno
pela frente para ser explorado e percorrido.
Além dos estudos de métricas e sua aplicação em diagramas, técnicas de
aplicação e padrões estão sendo criados e aprimorados constantemente como, por
exemplo, IEEE (1998). Esse padrão da IEEE nos remete a outro aspecto,
fundamental para o trabalho, que é o objetivo final dessas métricas. As métricas têm
como objetivo a melhoria da qualidade do software a ser desenvolvido.
A busca dessa melhoria, aliada ao grande crescimento do paradigma da OO
em projetos em desenvolvimento de software, fez com que os pesquisadores
começassem a medir cada vez mais cedo o software, não apenas depois de pronto,
mas também no início de sua concepção e durante o desenvolvimento.
Porém, após o mapeamento do estado da arte, pode-se verificar que existem
poucos estudos sobre métricas na fase inicial de desenvolvimento, mais
especificamente em diagramas UML.
As métricas propostas tiveram validação conceitual, todas bem
fundamentadas, mas a validação empírica ocorreu com diagramas de projetos
prontos ou diagramas elaborados apenas para estudo.
Sobre o aspecto técnico, o conjunto de Métricas Genero foi um estudo de três
anos com publicação de diversos artigos e muita validação empírica, porém sua
aplicação prática é bastante difícil. Primeiro porque os autores escreveram diversos
artigos com diferentes abordagens, deixando bastante fragmentadas as métricas.
Segundo, porque os autores ainda estão pesquisando quais métricas podem ser
utilizadas para medir diagramas UML.
43
Para aplicação efetiva das métricas a suíte CK foi a que se apresentou melhor
para aplicação e com base teórica. Sobre a aplicação da suíte de métricas CK,
pode-se destacar três aspectos:
a) as métricas propostas são relevantes e de fácil captação no diagrama UML,
o que facilita sua aplicação. A única ressalva é a variável LCOM que é
preciso de implementação para poder coletar seu valor;
b) tanto essa suíte como as demais métricas propostas não indicam pré-
requisitos para utilização das mesmas, como por exemplo, a métrica LCOM
que necessita do diagrama de classe implementado, ou então a métrica
RFC que precisa do diagrama de seqüência;
c) a relação entre as variáveis da métrica, e a maneira estatística de calcular e
observar são relativamente fáceis de aplicar, claro que com ajuda de alguma
ferramenta como Microsoft Excel ou um software de estatística como o
PASW.
Depois da análise das métricas selecionas e aplicação em um projeto, pode-
se afirmar que a utilização de métricas são bons indicativos de má concepção de
diagramas de classe UML, o que pode gerar manutenção na fase de
desenvolvimento. Assim, esses indícios podem ser verificados ainda na fase inicial
do projeto. Com esse trabalho procurou-se contribuir não só na analise das métricas
já existentes, como fornecer mais uma avaliação e sua aplicabilidade em projetos.
Foi procurado também mostrar como é sua aplicação, desde a coleta dos
dados até a aplicação e análise, o que não ficou claro em muitos dos artigos
estudados, como o alto grau de formalismo matemático de alguns artigos o que
inviabiliza sua aplicação.
Um aspecto que não foi abordado pelos pesquisadores estudados, e que foi
tratado superficialmente nesse trabalho, diz respeito à questão do tratamento ou
soluções para os indicadores apresentados. No caso dos pesquisadores não foi
encontrado indício do porque não ter esse aspecto, para esse trabalho, seria
necessário um tempo maior para estudo de artigos e outras bibliografias sobre
manutenção e elaboração de diagramas em projetos com OO, ou ainda a opinião de
um especialista.
44
5. TRABALHOS FUTUROS
Durante a realização desse trabalho surgiram diversas idéias sobre novos
trabalhos para o tema de métricas em diagramas UML. Mas, são relacionadas às
idéias que seguem na mesma linha e que possam contribuir para o assunto.
Seguindo a premissa dos experimentos feitos por Genero, et. al (2003), onde
participaram alunos de uma universidade, seria interessante introduzir o assunto de
métricas para diagramas UML em uma disciplina do Curso de Ciência da
Computação, como a disciplina de Engenharia de Software ou Laboratório de
Engenharia de Software, para captar os resultados com os alunos e analisar as
métricas e seus resultados. Através da aplicação das métricas em projetos
acadêmicos, criando pré-requisitos para utilização das mesmas.
Desenvolver um plugin para uma linguagem onde é feito o desenho da UML,
como Eclipse, Jude, etc. e que esse plugin possa captar as informações
automaticamente do diagrama a ser selecionado e posteriormente que possa ser
exportado para XML. A partir desse arquivo XML, criar um software, ou explorar
algum como o SPSS, para importar essas informações para aplicação da métrica.
Seria importante que esse software possuísse mais de uma métrica para
análise, assim um comparativo entre diversas métricas poderiam apresentar
diferentes perspectivas.
Um passo importante seria validar essas informações com empresas em
projetos de produção. Para um aluno captar esse tipo de informação é bastante
difícil, terá que haver uma parceria entre empresas e a universidade.
Como já comentado, também seria importante a elaboração de um conjunto de
soluções para cada situação dos indicadores das métricas, não que elas devam ser
seguidas a risca, mas como tem o indicador do que pode estar errado, deve ter um
caminho ou indicação do que pode ser feito. Mas sempre deve prevalecer a opinião
de especialistas. Também poderia ser criado um sistema especialista para essas
soluções, mas isso nos remete a outra área da ciência da computação que é a
Inteligência Artificial.
45
Por fim, seria interessante que os pesquisadores começassem a traçar um
caminho na direção de uma métrica e um diagrama, procurando chegar a um
consenso e todos trabalharem nesse sentido para tornar as métricas aplicáveis em
empresas e não somente no meio acadêmico.
46
REFERÊNCIAS
BEZERRA, E. Princípios de análise e projeto de sistemas com UML . Rio de Janeiro: Elsevier, 2002. 9. reimpressão. ISBN: 85-352-1032-6.
BHATTI, S. N. Why quality? : ISO 9126 software quality metrics (Functionality) support by UML suite. ACM SIGSOFT Software Engineering Notes 30(2): 1-5.
CHAHAL, K.; SINGH, H. Metrics to study symptoms of bad software designs . ACM SIGSOFT Software Engineering Notes, v.34 n.1, January 2009.
CHIDAMBER, S.; KEMERER, C. A Metrics Suite for Object Oriented Design . IEEE Transactions on Software Engineering, 20(6), 1994, pp. 476-493.
CRESPO, A. A. Estatística Fácil . 19. ed. São Paulo: Saraiva, 2009.
DEBNATH, N.; RIESCO, D.; MONTEJANO, G.; UZAL, R.; BAIGORRIA, L.;DASSO, A.; FUNES, A. A Technique based on the OMG Metamodel and OCL for the definition of Object Oriented Metrics applied to UM L models – The 3rd
ACS/IEEE International Conference on Computer Systems and Applications. (AICCSA-05) . Cairo. Egypt. January 3-6, 2005. ISBN: 0-7803-8735-X. IEEE Catalog Number: 05EX949 . Library of Congress Number: 2004110879.
FERREIRA, A.B.H. Mini Aurélio : o dicionário da língua portuguesa. 7. ed. Curitiba: Positivo, 2008. 896 p.
FOWLER, M. Refatoração: aperfeiçoando o projeto de código existente. Porto Alegre: Bookman, 2004. 365 p. ISBN 8536303956.
GAMMA, E. et al. Padrões de Projeto : Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman. 2000.
GENERO, M.; PIATINI, M.; MANSO, E. Finding "early" indicators of UML class diagrams understandability and modifiability . Proceedings of International Symposium on Empirical Software Engineering. 207-216. 2004.
47
GENERO, M.; PIATTINi, M.; CALERO, C. Empirical validation of class diagram metrics . In Proceedings of 2002 International Symposium on Empirical Software Engineering. Nara, Japan, October 2002. pp.195–203.
GENERO, M.; PIATTINI, M.; MANSO, M.; CANTONE, G. Building UML class diagram maintainability prediction models based on early metrics . In Proceedings of 9th International Software Metrics Symposium. Sydney, Australia, September 2003. pp.263-275.
INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. Standard for a Software Quality Metrics Methodology . New York, United States. Disponível em: http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fstamp%2Fstamp.jsp%3Ftp%3D%26isnumber%3D6079%26arnumber%3D237006&authDecision=-203.
KOLLMANN, R.; GOGOLLA, M. Metric-Based Selective Representation of UML Diagrams. Proceedings of the 6th European Conference on Software Maintenance and Reengineering. p.89-98, March 11-13.
LANGE, C. F. J. Improving the quality of UML models in practice. Proceeding of the 28th International Conference on Software Engineering (pp. 993-996 ). Shanghai. China ACM Press. Disponível em: http://doi.acm.org/10. 145/1134285.1134472. 2006.
LARMAN, C. Utilizando UML e Padrões : Uma Introdução à Análise e ao Projeto Orientados a Objetos. Porto Alegre: Bookman, 2002.
MALGOUYRES, H.; MOTET, G. A UML model consistency verification approach based on meta-modeling formalization . Proceedings of the 2006 ACM symposium on Applied computing. April 23-27. 2006. Dijon. France.
MARCHESI, M. OOA metrics for the Unified Modeling Language . In Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering. IEEE Computer Society Press. Los Alamitos. CA. 1998.
OBJECT MANAGEMENT GROUP. http://www.omg.org acessado em 27/03/2009.
PAGE-JONES, M. Fundamentos do desenho orientado a objeto com UML . São Paulo: Makron Books. 2001. 462 p. il.; 24 cm. ISBN: 8534612439.
PMBOOK 2004. Um Guia do Conjunto de Conhecimentos em Gerenciamen to de Projetos . s.l. : Project Management Institute. Inc. 2004. ISBN: 1-930699-74-3.
48
PRESSMAN, R.S. Software engineering: a practitioner's approach . 6th ed. New York: McGraw-Hill, 2005. XXXII, 880 p.: il.; 24 cm. (McGraw-Hill series in computer science) ISBN: 0072853182
SOMMERVILLE, I. Engenharia de software ; tradução: Maurício de Andrade 6. ed. São Paulo : Addison-Wesley. 2003. XIV. 592 p.: il.; 28 cm. ISBN: 8588639076
SPIEGEL, M.R. Probabilidade e estatística . São Paulo: Pearson Education do Brasil. 2003.
TANG, M.H.; CHEN, M.H. Measuring OO design metrics from UML . In: International Conference on The Unified Modeling Language. Dresden. Germany (September 30 - October 4 2002).
TONSIG, S.L. Engenharia de Software : Análise e Projeto de sistemas. São Paulo: Futura. 2003.
WAINER, J. Métodos de Pesquisa Quantitativa e Qualitativa para a Ciência da Computação . Jornadas de Atualização em Informática. SBC. 2007.
YI, T.; WU, F. Empirical analysis of entropy distance metric for U ML class diagrams . ACM SIGSOFT Software Engineering Notes 29(5): 1-6. 2004.
YI, T.; WU, F; GAN, C. A Comparison of Metrics for UML Class Diagrams . ACM SIGSOFT Software Engineering Notes. Volume: 29. Number 5 Pg. 1-6 September. 2004.
