Apostila - Engenharia de Software - Métricas - Conceitos

1
Engenhar i a de Sof t w ar e
Or i ent ada a Obj et os
Aval i a o da Qual i dade:
medi ndo o pr odut o
Guilherme H. Travassos
Programa de Engenharia de Sistemas e Computao
ght@cos.ufrj.br
http://www.cos.ufrj.br/~ght
COPPE
UFRJ
Copyright by G. H. Travassos COPPE/UFRJ - 2001
Engenhar i a de Sof t w ar e OO
Bibliografia
[Pfleeger00]
Shari Lawrence Pfleeger; Software Engineering: Theory and Practice, Second Edition, Prentice Hall, 2000
Chapter 6
[Travassos et all01]
Travassos, G.H., Shull, F. and Carver, J .; Working with UML: A Software Design Process Based on
Inspections for the Unified Modeling Language, in Advances in Computers, vol. 54, Academic Press,
2001
Chidamber, S.R. and Kemerer, C. F.; A Metrics Suite for Object Oriented Design, IEEE Transactions on
Software Engineering, vol.20, no6, J une 1994.
Basili, Victor R.; Briand, Lionel and Melo, Walcelio; A validation of Object-Oriented design metrics,
Technical Report, Univ. of Maryland, Dep. Of Computer Science, CS-TR-3443, May, 1995
W. Lie and S. Henry (1993). Object-oriented metrics that predict maintainability, J ournal of Systems and
Software. 23(2):111-122.
Travassos, G. H. and Andrade, R. S., Combining Metrics, Principles and Guidelines for Object Oriented
Design, Workshop on Quantitative Approaches on Object Oriented Software Engineering, ECOOP99,
Lisbon, Portugal, 1999 (http://www.esw.inesc.pt/ftp/pub/esw/mood/ecoop99/)
2
Medi o do Pr odut o
Modelos de Software e Medidas: Escopo
Precisamos definir modelos para
Ajudar a entender o que estamos fazendo
Fornecer uma base para definir objetivos
Fornecer uma base para medio
Precisamos modelos de:
pessoas, i.e., cliente, gerente, desenvolvedor
processos, i.e., um ciclo de vida, mtodo, tcnica
produtos, o sistema,um componente, um plano de teste
Precisamos estudar as interaes entre estes modelos
Qual o efeito da modificao de um processo no produto?
Precisamos associar mtricas a estes modelos
Como medir processo?
Medi o do Pr odut o
Modelos de Software e Medidas
O que podemos medir?
Dados sobre recursos:
Esforo por atividade, fase, tipo de pessoal, tempo de computao, tempo
de desenvolvimento
Dados sobre alteraes/defeitos:
Alteraes e defeitos de acordo com diferentes esquemas de classificao
Dados sobre processo:
Definio do processo, Conformidade com o processo, compreenso do
domnio
Dados sobre produto:
Caractersticas do produto
Lgicas, i.e., domnio de aplicao, funo
Fsicas, i.e., tamanho, estrutura
Operacional, i.e., confiabilidade
I nformao de uso e contexto, i.e., mtodo de projeto utilizado
3
Medi o do Pr odut o
Recursos
modelos de custo locais, modelos de alocao de recursos
Modificaes e Defeitos
modelos de predio de defeitos, tipos de defeitos esperados para a aplicao
Progresso do Produto
tamanho de produto atual vs. esperado, acesso a bibliotecas, excesso de tempo
Processos
modelo de processo para Cleanroom, modelo de processo para OO
Avaliaes de Mtodos e Tcnicas
melhor mtodo para encontrar falhas em interface
Produtos
compomentes genricos Ada para simulao de rbita de satlites
Qualidade
modelos de confiabilidade, modelos de facilidade de alterao
Lies Aprendidas
riscos associados com desenvolvimento C++
Medi o do Pr odut o
Modelos de Software e Medidas: Perspectivas
De que ponto de vista estamos medindo?
Existe uma variedade de pontos de vista que determinam o que medimos
Gerenciamento
Cliente
Usurio
Organizao
Desenvolvedor
Por que estamos medindo?
Existem vrias razes para medir que ajudam a definir o que medimos, i.e.:
Caracterizao e Compreenso
Identificao (Assessment) e Avaliao
Predio e Controle
Motivao e Prescrio
Melhoria
4
Medi o do Pr odut o
Caracterizar
Descrever e diferenciar processos e produtos de software
Construir modelos descritivos e baselines
Compreender
Explicar associaes/dependncias entre processos e produtos
Descobrir relacionamentos causais
Analisar modelos
Avaliar
Identificar a realizao dos objetivos de qualidade
Identificar o impacto da tecnologia nos produtos
Comparar modelos
Predizer
Estimar a qualidade esperado do produto e consumo de recursos no
projeto
Construir modelos de predio
Motivar
Descrever o que precisamos fazer para controlar e gerenciar o software
Construir modelos prescritivos
Medi o do Pr odut o
O que podemos fazer com as medidas?
Criar uma memria corporativa baselines/modelos de prticas
correntes
quanto um novo projeto ir custar?
Determinar os pontos fortes e fracos do processo corrente e
produto
certos tipos de erros sempre ocorrem?
Desenvolver critrios (razes) para adoo/ refinamento de
tcnicas
que tcnicas reduziro os problemas, modificando as baselines?
I dentificar o impacto das tcnicas
aplicar testes funcionais reduz certas classes de erro?
Avaliar a qualidade do processo/ produto
estamos aplicando inspees adequadamente?
qual a confiabilidade do produto aps a entrega?
5
Medi o do Pr odut o
Contribuindo para:
Planejar o desenvolvimento do software e o processo de manuteno de
forma que
Recursos adequados estejam disponveis quando necessrios
Anlise de custo/benefcio e identificao de riscos possam ser executadas
Monitorar o processo para prevenir ou reduzir dificuldades quando ainda
possvel
Controlar o processo atravs de aes corretivas ou preventivas baseadas na
anlise quantitativa
Avaliar a eficincia das fases e atividades de desenvolvimento ou processo
de manuteno baseado em informao objetiva
Refinar os processos de desenvolvimento e manuteno
Medi o do Pr odut o
Modelos de Software e Medidas [Basili99]
Vises de Mtricas de Software
Existem vrias maneiras de se discutir mtricas:
Nvel de preciso, e.g., objetiva, subjetiva
Escalas de medio , e.g., nominal, ordinal, intervalo, razo
Objeto de medio, e.g., processo ou produto
Mtrica Objetiva:
Uma medida absoluta extrada do produto ou do processo
Usualmente representada num intervalo ou escala razo
Exemplos: tempo de desenvolvimento, nmero de linhas de cdigo, nmero
de erros ou modificaes
Mtrica Subjetiva:
Uma estimativa de extenso ou grau de aplicao de alguma tcnica
Uma classificao ou qualificao do problema ou experincia
Normalmente feita numa escala nominal ou ordinal
Exemplos: qualidade do uso de um mtodo ou tcnica, experincia dos
programadores na aplicao ou processo
6
Medi o do Pr odut o
Vises de Mtricas de Software
Escalas de Medio
Escala
Nominal
Ordinal
Intervalo
Razo
Operaes Bsicas
Determinao de igualdade
Determinao de maior ou menor
Determinao de igualdade de
intervalos ou diferenas
Determinao de igualdade de
razes
Exemplos Tpicos
reas de aplicao
Tipos de defeitos
Nvel de treinamento ou
compreenso
Datas de calendrio
Linhas de cdigo
Nmero de defeitos
Complexidade do cdigo
Medi o do Pr odut o
Mtricas para qualquer produto engenheirado so governadas pelas
caractersticas do produto
Assim como para software convencional, mtricas OO objetivam:
Melhor compreender a qualidade do produto
I dentificar a eficincia do processo
Melhorar a qualidade do trabalho sendo realizado
O que faz um produto de software OO ser diferente de um software
convencional?
Como medimos a qualidade de um sistema OO?
Que caractersticas do modelo de projeto podem ser identificadas para
determinar se um sistema ser fcil de implementar, ameno de ser testado,
simples de modificar, e mais importante, ser aceito pelos usurios?
7
Engenheirando produtos de software convencionais
Soluo est centrada na funo ou nos dados
Utiliza algoritmos, procedimentos (com diferentes notaes ao longo do
ciclo de vida) e organizao de dados para descrever o problema e
organizar a informao
Basicamente, mdulos organizam a arquitetura do software
Tecnologia de estruturao da informao (modelo relacional, por exemplo)
determina como a informao ser armazenada e avaliada.
Medi c o do Pr odut o
Medi o do Pr odut o
Engenheirando produtos de software convencionais
Decomposio funcional (desenvolvimento estruturado) e algumas
mtricas possveis
a
b
c d
e f
1
2
3
Program a
do while X
call b;
call c;
call d
end while;
Subroutine c
call e;
if y then call f
end;
Especificao
Projeto I mplementao
Pontos por funo
Pginas de documentao
Linhas de cdigo estimadas
Tempo (calendrio)
...
Coeso
Acoplamento
Complexidade
Nmero de Mdulos
...
Complexidade Ciclomtica
Teoria de Halstead
Linhas de cdigo
Ligaes de Dados
...
Testes
Cobertura
Confiabilidade
...
8
Medi o do Pr odut o
Paradigma Orientado a Objetos:
Significa organizar o software como uma coleo de objetos discretos
que incorporam conjuntamente a estrutura dos dados e
comportamento
caractersticas:
identidade
abstrao
classificao
encapsulamento
herana
polimorfismo
persistncia
Medi o de Sof t w ar e OO
Modelos e Mtricas: Algumas definies
Acoplamento
Intuitivamente, refere-se ao grau de interdependncia entre diferentes
pedaos de um projeto
Desde que objetos de uma mesma classe possuem as mesmas
propriedades, duas classes esto acopladas quando mtodos declarados numa
classe utilizam mtodos ou variveis de instncia de outra classe.
Coeso
Intuitivamente, refere-se consistncia interna dos pedaos de um
projeto
O grau de similaridade de mtodos pode ser visto como o maior aspecto
de coesividade das classes/objetos. Se uma classe/objeto tem diferentes
mtodos executando diferentes operaes para um mesmo conjunto de
variveis de instncia, a classe coesa.
9
Modelos e Mtricas
Tamanho (descrio de requisitos, projeto de alto e baixo nvel)
Lorenz e Kidd [Lorenz94]
Nmero de descrio de cenrios (use-cases) (NSS)
Diretamente relacionada ao tamanho da aplicao e ao nmero de casos de teste
Nmero de classes chave (classes de domnio) (NKC)
Relacionada com o projeto de alto nvel e o montante de esforo necessrio para
implementar o sistema e a reutilizao necessria
Nmero de classes de suporte (NSC)
Referente ao projeto de baixo nvel e o montante de esforo necessrio para
implementar o sistema e a reutilizao necessria
Nmero mdio de classes de suporte por classe chave (ANSC)
Nmero de subsistemas (NSUB)
Modelos e Mtricas
Tamanho da Classe (CS)
Nmero total de operaes + nmero de atributos (ambos
incluindo caractersticas herdadas)
Nmero de operaes especializadas por uma subclasse(NOO)
Nmero de operaes acrescentadas por uma sub classe (NOA)
Indce de Especializao(SI)
SI = [NOO x nvel] / (Mtodos Totais da Classe)
10
Modelos e Mtricas
Fase
Mtrica
Descrio
Requisitos
Projeto
Alto
Nvel
Projeto
Baixo
Nvel
Codificao Testes
NSS

NKC

NSC

ANSC

NSUB

CS

NOO

NOA

SI

Modelos e Mtricas
maintenance services
Parking services
Gas services
Gas ordering
system
Parts ordering
system
Controlling inventory
Owner
accounting services
Customer
CC System
Printer system
billing
The Gas Station problem
Requirements:
1 A customer has the option to be billed automatically at
the time of purchase (gas, car maintenance or parking
spots) or to be sent a monthly paper bill. Customers can
pay via cash, credit card or personal check. Gas Station
services have a fixed price (gas: US$ 1.09 gallon, car
maintenance: US$ 150.00 and parking spot: US$ 5.00 per
day). The tax is 5% added to the final price of the
purchase. Sometimes, the Gas Station owner can define
discounts to those prices.
2 The system has to track bills on a month-to-month
basis and the services performed by the gas station on a
day-to-day basis. The results of this tracking can be
reported to the owner upon request.
3 The gas station owner can use the system to control
inventory. The system will either warn of low inventory or
automatically order new parts and gas.
...
NSS = 6
11
Modelos e Mtricas
periodic messages
Part
part_code
discount rate
car maintenance
price = 150.00
price()
0..* 0..*
gas
min_quantity = 100
current_quantity
price = 1.09
refuel
gallons : float = 0.0
price()
parking
price : float = 5.00
message
text : Strings
CC system
(from External Systems)
parking spot
place : Strings
is_available()
next_available()
1
0..1
1
0..1
parts ordering system
gas ordering system
gas station
name : Strings
gasstation code : int
dormant_accounts()
1..*
1
1..*
1
inventory
order_gas()
order_part()
product
min_quantity : float
current_quantity : float
price : float 1
1..*
1
1..*
services
discount rate : float = 0.0
price()
Customer
name : Strings
address : Strings
SSN : Strings
birthday : DateTime
account_number : long
create_customers()
create_a_customer()
Purchase
date : DateTime
tax : float = 0.05
price()
taxes()
1..*
0..*
1..*
0..*
1 0..* 1 0..*
warning letters
bill
issue date : DateTime
payment date : DateTime
price()
taxes()
customer()
list_purchases()
1..*
1
1..*
1
Min Max
NKC 17 17
CS 1 7
NOO 0 1
NOA 0 0
SI 0 1
Modelos e Mtricas
Produto(projeto de alto e baixo nvel)
Chidamber e Kemerer Metrics Suite [Chidamber94]
Mtodos Pesados por Classe(WMC)
Profundidade de Herana (DI T)
Nmero de Filhos (NOC)
Acoplamento entre Objetos (CBO)
Resposta de uma classe(RFC)
Perda de Coeso em Mtodos (LCOM)
Fase
Mtrica
Projeto
Alto
Nvel
Projeto
Baixo
Nvel
Codificao Testes
WMC

DIT

NOC

CBO

RFC

LCOM

12
Modelos e Mtricas
Produto
Mtodos Pesados por Classe(WMC)
Considere uma classe C
1
, com mtodos M
1
,, M
n
que so definidos pela classe. Faa
c
1
,,c
n
ser a complexidade dos mtodos. Ento:
Se todas as complexidades dos mtodos so consideradas ser 1, ento WMC = n, o nmero
de mtodos.
Pontos de Vista:
1) Nmero de mtodos e a complexidade de mtodos relacionam-se com quanto tempo e
esforo so necessrios para desenvolver e manter a classe
2) Quanto maior o nmero de mtodos numa classe, maior o potencial de impacto nos
filhos, desde que os filhos herdam os mtodos da classe
3) Classes com grande nmero de mtodos tendem a ser mais especficas da aplicao,
limitando sua possibilidade de reutilizao

= =
= =
n
i
i c WMC
1
Modelos e Mtricas
Produto
Profundidade de Herana(DIT)
Profundidade de herana da classe a mtrica DIT para a classe. Em casos
envolvendo mltipla herana, a DIT ser a extenso mxima do n at a
raiz da rvore.
Pontos de vista:
1) Quanto mais profunda uma classe est na hierarquia, maior o nmero de mtodos que
provavelmente herdar, fazendo ser mais difcil predizer seu comportamento.
2) rvores profundas constituem maior complexidade de projeto, desde que mais mtodos
e classes esto envolvidos.
3) Quanto mais profunda est uma classe particular na hierarquia, maior o potencial de
reutilizao dos mtodos herdados.
13
Modelos e Mtricas
Produto
Nmero de filhos (NOC)
NOC = nmero de sub classes imediatas e subordinadas a uma classe na
hierarquia
Pontos de Vista:
1) Maior o nmero de filhos, maior a reutilizao, desde que herana uma forma de
reutilizao
2) Maior o nmero de filhos, maior a probabilidade de abstrao imprpria para a classe
pai. Se uma classe tem um grande nmero de filhos, isto pode provocar uso
inadequado da especializao.
3) O nmero de filhos d uma idia da potencial influncia que uma classe tem no
projeto. Se uma classe tem um grande nmero de filhos, isto pode requerer mais
teste dos mtodos desta classe.
Modelos e Mtricas
Produto
Acoplamento entre Objetos (CBO)
CBO para uma classe a contagem do nmero de outras classes para as
quais ela est acoplada (associada)
Pontos de vista:
1) Acoplamento excessivo entre classes/objetos prejudicial ao projeto modular e
previne a reutilizao. Quanto mais independente uma classe, mais fcil ser sua
reutilizao em outra aplicao.
2) Em ordem de aumentar a modularidade e promover o encapsulamento,o
acoplamento entre objetos deve ser mantido no mnimo possvel. Quanto maior o
nmero de acoplamenos, maior sensibilidade a trocas em outras partes do projeto, e
por isto a manuteno se torna mais difcil.
3) Uma medida de acoplamento til para determinar quo provavelmente complexo
ser o teste de vrias partes do projeto. Quanto maior o acoplamento entre objetos,
mais rigoroso o teste precisa ser.
14
Modelos e Mtricas
Produto
Resposta para uma classe(RFC)
O conjunto de respostas para uma classe o conjunto de mtodos que podem
potencialmente ser executados em resposta a uma mensagem recebida por um
objeto da classe.
RFC = | RS| onde RS a reposta para a classe.
RS = {M} Uall I {Ri}
onde {Ri} = conjunto de mtodos chamados pelo mtodo I e
{M} = conjunto de todos os mtodos da classe
Pontos de Vista:
1) Se um grande nmero de mtodos podem ser chamados em resposta a uma
mensagem , o teste e depurao da classe se torna mais complicado desde que
requer um grande nvel de compreenso por parte do testador.
2) Quanto maior o nmero de mtodos que podem ser chamados para uma classe,
maior a complexidade da classe.
3) O valor de pior caso para possveis respostas apoiar na alocao apropriada do
tempo/esforo para testes
Modelos e Mtricas
Produto
Perda de Coeso em Mtodos (LCOM)
Considere uma classe C1 com n mtodos M
1
,M
2
,,M
n
. Faa {I
j
} = conjunto de
variveis de instncia usadas pelo mtodo M
i
.
Pontos de Vista:
1) Coeso de mtodos dentro de uma classe desejvel, desde que promove o
encapsulamento
2) Perda de coeso implica que classes provalmente deveriam ser divididas em duas ou
mais classes ou subclasses
3) Qualquer medida de inadequao de mtodos contribui para identificar problemas
no projeto das classes
4) Baixa coeso aumenta a complexidade, com isto aumentando a probabilidade de
erros durante o processo de desenvolvimento.
otherwise
. let then are sets all If . and
Let . sets such are There
0
0 0 0
0
1
1
= =
> > = =
= = = =
= = = =
LCOM
|Q| , i f |P| |P| - |Q| LCOM
P } },...,{I {I n } I I ) | , I {(I Q
} I )|I , I {(I P } },...,{I {I n
n j i j i
j i j i n
15
Modelos e Mtricas
Produto
Lie e Henry [Lie93]
Mtricas validadas atravs do estudo do nmero de modificaes
executadas em dois sistemas comerciais implementaddos com um
dialeto Ada OO
Adiciona duas mtricas ao conjunto proposto por Chidamber e
Kemerer:
Acoplamento de Passagem de Mensagem (MPC): calculado como o
nmero de declaraes de envio definido na classe
Acoplamento de Abstrao de Dados (DAC): calculado como o nmero de
tipos abstratos de dados usados na classe medida e definidos em outra
classe do sistema
Modelo foi adequado para predizer o tamanho das modificaes nas
classes durante a fase de manuteno
Modelos e Mtricas
Basili, Briand e Melo [Basili95]
Baseado em Chidamber e Kemerer, empiricamente validaram a
adequabilidade destas mtricas para predio da probabilidade de
identificar classes sujeitas a falha em softwares baseados em C++
Ajustaram levemente algumas das mtricas para capturar algumas das
caractersticas de C++ (as mtricas no so independentes da linguagem)
WMC: todos os mtodos tem
complexidade 1 e operadores
friend no so contados
DIT: mede o nmero de
ancestrais de uma classe
CBO: uma classe est acoplada a outra se
utiliza suas funes membro e/ou variveis
de instncia
RFC: nmero de funes diretamente
chamadas por funes membro ou operadores
da classe
LCOM: nmero de pares de funes membro sem variveis de instncia compartilhadas,
menos o nmero de pares de funes membro com variveis de instncia
compartilhadas. Assume valor 0 se a subtrao negativa.
NOC: nmero de descendentes
diretos para cada classe
16
Modelos e Mtricas
Pontos de vista Basili, Briand e Melo :
WMC: uma classe com significativamente
mais funes membro que seus pares
mais complexa, em consequncia sendo
mais propensa a falhas
DIT: sistemas OO bem projetados so
aqueles estruturados como florestas de
classes, ao invs daqueles
estruturados como uma grande
estrutura de herana
CBO: classes fortemente acopladas
so mais propensas a falha que classes
fracamente acopladas
RFC: quanto maior a resposta de uma
classe, maior a complexidade da classe, e
mais propensa a falha e dificil de modificar
LCOM: uma classe com baixa coeso entre seus mtodos sugere um projeto no
apropriado (i.e., o encapsulamento de objetos de programa e funes membro no
relacionadas que no deveriam estar juntos), provvel de ser propenso a falha.
NOC: classes com grande nmero de
filhos so difceis de modificar e
usualmente requerem mais teste porque
a classe potencialmente afeta todos os
seus filhos
Modelos e Mtricas
Anlise das Distribuies:
Mtricas OO baseadas em 180 classes:
DIT indica que hierarquias de herana so de
alguma forma planas e NOC que classes tem,
em geral, poucos filhos. Classes parecem ter
alta coeso (LCOM perto de 0)
17
Modelos e Mtricas
resultados relativos a probabilidade de identificao de falhas numa
classe durante a fase de teste:
WMC: quanto maior WMC, maior a
probabilidade de identificao de
falha
DIT: quanto maior DIT, maior a
falhas
CBO: mais significante para classes
de IU que para classes de BD (no foi
encontrada explicao satisfatria para
as diferenas nos padres entre estes
tipos de classe)
RFC: quanto maior RFC, maior a
falhas
LCOM: no significante
NOC: quanto maior o NOC, menor a
falhas
Modelos e Mtricas
(alto nvel)
bill
price()
taxes()
customer()
list_purchases()
warning letters
periodic messages message
text : Strings
1..*
1
1..*
1
Purchase
date : DateTime
tax : float = 0.05
price()
taxes()
Customer
name : Strings
address : Strings
SSN : Strings
birthday : DateTime
account_number : long
create_customers()
create_a_customer()
1 0..* 1 0..*
1..* 1..*
0..* 0..*
Bill Purchase Warning
Letters
Periodic
Messages
Message Customer
WMC 4 2 0 0 0 2
NOC 0 0 0 0 2 0
DIT 0 0 1 1 0 0
RFC -- -- -- -- -- --
CBO 2 4 2 1 1 2
LCOM -- -- -- -- -- --
18
Modelos e Mtricas
(baixo nvel)
Bill Purchase Warning
Letters
Window Ok
button
Textbox
WMC 4 2 0 1 0 0
NOC 0 0 0 0 0 0
DIT 0 0 1 1 0 0
RFC -- -- -- -- -- --
CBO 3 4 2 3 1 1
LCOM -- -- -- -- -- --
1..*
11
1..*
warning letters
bill
price()
taxes()
customer()
list_purchases()
Window
size
width
customer_name
issue_date
total
purchases
show_bill()
textbox
Ok_button
1..*
0..* 0..*
1..*
1
0..*
Purchase
date : DateTime
tax : float = 0.05
price()
taxes()
1
Modelos e Mtricas
Outras Mtricas possveis
Tamanho mdio do Servio (OS
avg
)
O nmero de mensagens envolvidas num servio
Nmero mdio de parmetros por operao (NP
avg
)
Complexidade da Operao (OC)
Pode ser calculado usando qualquer das mtricas de complexidade
propostas para software convencional
Percentagem pblica e protegida (PAP)
Acesso pblico aos membros de dados (PAD)
Nmero de Classes Raiz (NOR)
Mostra o nmero de hierarquias de classe que existem no sistema. Valores
grandes devem ser evitados.
Fan in (FIN)
FIN > 1 indica mltipla herana
19
Modelos e Mtricas
Customer
GasStation Parking Spot Purchase Parking
Parking Use
Case
1: Parking()
3: parking_at(place)
2: next_available()
4: new_purchase(customer, parking,date, place)
there is an
available
5: new_parking(customer, place)
Min Max
OS 5 5
NP 0 4
Class name: refuel
Category: Service
External Documents:
Export Control: Public
Cardinality: n
Hierarchy:
Superclasses: services
Associations:
<no rolename> : gas in association <unnamed>
Public Interface:
Operations:
price
Private Interface:
Attributes:
gallons
price = 1.09
Implementation:
Attributes:
gallons
price = 1.09
State machine: No
Concurrency: Sequential
Persistence: Transient
Operation name: price
Public member of:refuel
Documentation:
// Calculates the final price of the fuel
Preconditions:
gallons > 0
Object diagram: (Unspecified)
Semantics:
final_price = gallons * price
Object diagram: (Unspecified)
Concurrency: Sequential
Value
CS 4
PAD 0
PAP 0
20
Model
Metric
Use
Cases
Class
Diagrams
Interaction
Diagrams
Class
Descriptions
State
Diagrams
Package
Diagrams
Deployment
Diagrams
NSS

NKC

NSC

ANSC

NSUB

CS

NOO

NOA

SI

Modelos x Mtricas:
Onde medir/visualizar mtricas OO
Model
Metric
Use
Cases
Class
Diagrams
Interaction
Diagrams
Class
Descriptions
State
Diagrams
Package
Diagrams
Deployment
Diagrams
WMC
DIT
NOC
CBO
RFC
LCOM
Model
Metric
Use
Cases
Class
Diagrams
Interaction
Diagrams
Class
Descriptions
State
Diagrams
Package
Diagrams
Deployment
Diagrams
OSavg
NP
avg
OC
PAP
PAD
NOR
FIN
Modelos x Mtricas:
Onde medir/visualizar mtricas OO
21
Modelos de Software e Medidas: Automao
Que aspectos da medio podem ser automatizados?
Existe uma variedade de ferramentas disponveis comercialmente que
geram vrias mtricas de cdigo para uma variedade de linguagems
Exemplos: Code Metric Tools such as Analysis of Complexity Tool (ACT) and
BattleMap (McCabe&Associates) and Logiscope (Verilog)
Existem vrios ambientes de medio que vo alm das mtricas de cdigo
e suportam vrias funes de gerenciamento. Estes utilizam dados
histricos do ambiente ou de outros ambientes.
Exemplos: SPQR AND Checkpoint (Software Productivity Research, I nc.) and
PADS (Quantitative Software Management, I nc.)
Modelos de Software e Medidas: Aplicao
Qual o estado da prtica?
Muitas companhias possuem programas de medio em escala completa,
no apenas no nvel de projeto mas a nvel de diviso e corporao.
Tipicamente, as mais avanadas utilizam algum tipo de infraestrutura ou
modelo.
Exemplos:
HP utilizando uma verso preliminar do GQM
Motorola empregando GQM e Quality Improvement Paradigm
NEC empregandoSQMAT, uma melhoria sobre SQM, ePlan-Do-Check-Act
AT&T utilizando QFD, adaptado para software
22
Como desenvolvedores utilizam mtricas OO:
Avaliando qualidade do software
Compreendendo o processo de projeto
Identificando problemas no produto
Melhorando solues
Adquirindo conhecimento de projeto
Por exemplo
Utilizando mtricas para avaliar complexidade estrutural OO
Abordagem aplicada a dois domnios de aplicao diferentes :
Software Telecomunicaes (C++)
Ambientes de Desenvolvimento de Software(Eiffel)
Utilizando mtricas para avaliar a complexidade estrutural OO [Travassos99]
Desenvolvedores podem combinar:
Heursticas aplicadas para reduzir a complexidade do software durante atividades
de projeto (Diretrizes para reduzir a complexidade de projeto OO )
Conhecimento sobre experincias de desenvolvimento (Princpios de Projeto OO)
Mtricas para caracterizar como as soluces foram projetadas.
G1 Classes Restructuring Guideline
(set of 10 procedures)
G2 Adapter Class Guideline
G3 Bridge Class Guideline
G4 Facade Class Guideline
G5 Multiple Inheritance Elimination
Guideline
G6 Large Hierarchies Redefinition
Guideline
Heursticas
M1 DIT
M2 NOC
M4 Coupling
M5 Class Size
M6 Number of Multiple Inheritance
M11 Number of Abstract Classes
Mtricas
23
Utilizando mtricas para avaliar a complexidade estrutural OO [Travassos99]
P1 Few Interfaces Principle : All module (class) should communicate with as
few others as possible.
P2 Small Interfaces Principle: If any two modules (classes) communicate at
all, they should exchange as little information as possible.
P3 Explicit Interfaces Principle: Whenever two modules (classes) A and B
communicate, this must be obvious from the text of A or B or both.
P4 Information Hiding Principle: All information about a module (class) should
be private to the module (class) unless it is specifically declared public.
P5 The Open-Closed Principle: Software entities (classes, modules, etc.)
should be open for extension but closed for modification.
P6 The Liskov Substitution Principle: It is only when derived types are
completely substitutable for their base types that functions with use those
base types can be reused with impunity, and the derived types can be
changed with impunity.
P7 The Dependency Inversion Principle: Details should depend on
abstractions. Abstractions should not depend on details. High level policies
should not depend on low-level implementations; rather both should depend
on abstractions.
P8 The Interface Segregation Principle: Clients should not be forced to
depend on interfaces that they do not use.
Princpios
P1 P2 P3 P4 P5 P6 P7 P8
G1 M3, M7,
M9, M10,
M12
M8 M14 M14 M1, M2,
M3, M6,
M11
M1, M2,
M6
M M1 1, , M M2 2, ,
M M1 11 1
M1, M2,
M4, M5
G2 M13 M5
G3 M11
G4 M3 M3
G5 M3 M3, M6
G6 M3 M1, M2,
M3
M1, M2 M M1 1, , M M2 2 M1, M2,
M4
Relao entre Diretrizes, Princpios e Mtricas
24
Metrics
Repository
Metrics
Table
Visualization Tool
Graphical
Functions
Statistical
Functions
Mathematical
Functions
OO CASE TOOL
CASE Tool
Extensibility
Interface
Case Tool
Scripting
Reverse
Engineering
Language
Scripts
C++
Source
Code
Fi xed_Rat e Loan
r i sk( )
pr i nci pal _r emai ni ng( )
Var i abl e_Rat e Loan
pr i nci pal _ r e ma i n i n g : n u mb e r
r i sk( )
pr i nci pal _r emai ng( )
Lender
n a me : t e x t
id : text
c ont ac t : t ex t
p h o n e_ n u mb e r : n u mb e r
Bor r ower
n a me : t e x t
id : number
r i s k : n u mb e r
st at us : t ext
r i sk( )
s e t_s t at us _good( )
s e t_st at us_l at e( )
s e t_st at us_def aul t ( )
bor r ower _st at us( )
s e t_st at us( )
Bundle
act i ve t i me per i od : dat e
p r o f i t : n u mb e r
e s t i ma t e d r i s k : n u mb e r
t ot al : number
l o a n a n a l y s t : i d_number
di s c ount _ r a t e : n u mb e r
i n v e s t o r_ n a m e : t e x t
date _ s o l d : d a t e
r i sk( )
calculate _pr of i t ( )
c os t ( )
Loan Ar r anger
rec _mont hl y_r epor t ( )
i n v _r equest ( )
gener at e r epor t s( )
identify _r epor t _f or mat ( )
ver i f y_r epor t ( )
look _f or _a_l ender ( )
look _f or _a_l oan( )
identify _l oan_by_cr i t er i a( )
ma n u a l l y _sel ect _l oans( )
opt i mi z e_bundl e( )
calculate _new_bundl e( )
identify _asked_report ()
aggr egat e_bundl es()
aggr egat e_l oans( )
aggr egat e_bor r ower s ( )
aggr egat e_l ender s( )
format _r epor t ( )
show _r epor t ( )
Loan
amount : number
i nt er est r at e : number
set t l ement dat a : dat e
t er m : dat e
st at us : t ext
original _ v a l u e : n u mb e r
pr i nci pal _or i gi nal : number
r i sk( )
s e t _st at us_def aul t ( )
s e t _st at us_l at e( )
s e t _s t at us _good( )
di s c ount _r at e( )
bor r ower s( )
pr i nci pal _r emai ni ng( )
1
1 ..*
1
1 ..*
1 ..*
1 ..*
1 ..*
1 ..*
1 ..*
0. . 1
1 ..*
0. . 1
Principles,
Guidelines
Automatizando esta abordagem
**
** Legend: A: Attribute, B: Behavior,
** IA: Inherited Attribute, IB: Inherited Behavior,
** TA: Total Attributes, TB: Total Behavior,
** DIT: Hierarchical Level, NOC: Number of Children
**
** Normal NOC for this model...........: 3
** Number of leaf classes..............: 130
** Number of Non-Hierarquical Classes..: 11
** Number of Abstract Classes..........: 33
** Number of Classes...................: 163
**
Parent Class Name A B IA IB AT BT DIT NOC
Shapes 1 2 0 0 1 2 0 13
Node 2 0 3 4 5 4 1 9
Window 7 0 1 0 8 0 1 8
KnowledgeWindow 0 2 8 0 8 2 2 8
Arcs 2 1 3 4 5 5 1 7
Knowledge 6 4 0 0 6 4 0 6
PullDownMenu 8 9 4 0 12 9 1 5
GUIresoruces 1 0 0 0 1 0 0 5
SDEFramework 0 1 1 0 1 1 2 5
InternalTool 1 1 0 0 1 1 0 4
KnowledgeREpresenta
tion
0 0 8 0 8 0 2 4
GeneralWindows 6 2 15 10 21 12 1 4
Editor 1 0 0 0 1 0 0 3
ToolWindow 0 0 1 1 1 1 3 3
GeneralMenus 0 0 8 0 8 0 2 3
SDEWindow 0 0 21 12 21 12 2 3
Medi o de
Sof t w ar e OO
Uma tabela de mtricas
produzida com
ferramentas CASE
25
TABA Project Model - NOC
0
2
4
6
8
10
12
14
W
i
n
d
o
w

T
o
o
l
S
S
A
T
o
o
l

S
D
E
W
i
.
.
.
P
o
p
U
p
.
.
.
N
o
d
e

M
e
n
u

K
n
o
w
l
e
.
.
.
G
U
I
r
e
s
o
.
.
.
F
r
a
m
e
w
o
r
k

D
e
s
c
r
i
p
t
i
v
e

Parent Class Name
N
O
C
Visualizao da Mtrica

Apostila - Engenharia de Software - Métricas - Conceitos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila - Engenharia de Software - Métricas - Conceitos

Enviado por

Direitos autorais:

Formatos disponíveis

1

Você também pode gostar