Measurement Metrics for Object Oriented Design

A METRIC SUITE FOR OBJECT

ORIENTED DESIGN

Shyam R. Chidamber and Chris F. Kemerer

Ari Wibisono

Bambang Adhi

Achmad Rohman

OUTLINEIntroduction

Research Problems

Theory Based

Case Study (Character Graphics)

CONTRIBUTION

Contribution

Development and empirical validation

of a set of theoretically-

grounded metrics of 00 design

Brief Summary of software metric

evaluation criteria

Presents the metrics, their

analytical evaluation, the

empirical data and a managerial interpretation

RESEARCH PROBELMS

THEORITICAL CRITICISM

Theoretical

• Metrics need to be constructed with a stronger degree of theoretical and mathematical rigor.

OO DESIGN AND DEVELOPMENT.

OBJECTIVE

1 •Propose metrics

2 •Evaluate proposed metrics

3 •Present emperical data

THEORY BASE FOR OO METRICS

Identification of Classes

Identify the Semantics

Identify Relationship

Between Classes

Implementation of

Classes

MEASUREMENT THEORY BASE

EMPIRICAL DATA COLLECTION

Where

• From this software development organization has used OOD

Who

• Highly experienced• team of software engineers

What

• The large projects over the past five years

SOFTWARE DEV ORGANIZATION

Site A

software vendor that uses OOD

C++ Programming (GUI)

C Class Libraries

Metrics data from 634 classes

Site B

semiconductor manufacturer

Smalltalk programming language

Class libraries

Metrics data from 1459 classes

RESULTSMetric 1: Weighted

Methods Per Class (WMC)

Metric 2: Depth of Inheritance

Tree (DIT)

Metric 3: Number of

Children (NOC)

Metric 4: Coupling

between object classes (CBO)

Metric 5: Response For a Class (UFC)

Metric 6: Lack of Cohesion in

Methods (LCOM)

METRIC 1 : WEIGHTED METHOD PER CLASS

CHARACTER GRAPHICS

MATRIX 1 : WEIGHT METHOD PER CLASSCase Study : Character GraphicsNumber of Class Observed : 8Number of Method Observed : 59

HOW TO OBSERVED

Using Cyclomatic Complexity (McCabe)

How many test case to be tested in the method

Graph Representation

V (G) = e – n + 2 (Rosenberg 1998)

• v(G) cylomatic complexity graf G.• e is a number of edges on graf G• n is a number of nodes on graf G.

V(G) = P + 1

• Predicate node (Boolean repersentation 2 Outgoing Edges)

CYCLOMATIC COMPLEXITY

WEIGHT METHOD PER CLASS (STATISTICS)

Class WMCTool.java 1

ShapeList.java 30

Screen.java 13

DrawingPackage.java 19

Cshape.java 10

Crect.java 15

Ccircle.java 20

TextBox.java 13

Total WMC 121

WEIGHT METHOD PER CLASS (CHARACTER GRAPHICS)

1 s/d 5 6 s/d 10 11 s/d 15

16 s/d 20

21 s/d 25

26 s/d 30

31 s/d 35

0

0.5

1

1.5

2

2.5

3

3.5

4

Weight Method per Class

WMC Value

Number of Classes

WMC RESULT Cyclomatic Complexity

TestabilityUnderstandability (SATC 1995)

MATRIX 3 : DEPTH OF INHERITANCE TREE DIT is the maximum length from a node

to the root (base class) Viewpoints: Lower level subclasses inherit a number of

methods making behavior harder to predict Deeper trees indicate greater design

complexity

MATRIX 2 : DEPTH OF INHERITANCE TREE

Class DITTool.java 0

ShapeList.java 0

Screen.java 0


Cshape.java 0.75

Crect.java 0

Ccircle.java 0

TextBox.java 0

Total DIT 0,75

MATRIX 2 : DEPTH OF INHERITANCE TREE

1 s/d 5 6 s/d 10 11 s/d 15 16 s/d 20 21 s/d 25 26 s/d 30 31 s/d 350

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Depth Of Inheritance Tree

DIT Value

MATRIX 3 : NUMBER OF CHILDREN

NOC is the number of subclasses immediately subordinate to a class

Viewpoints: As NOC grows, reuse increases - but the abstraction may

be diluted

Depth is generally better than breadth in class hierarchy, since it promotes reuse of methods through inheritance

Classes higher up in the hierarchy should have more sub-classes then those lower down

NOC gives an idea of the potential influence a class has on the design: classes with large number of children may require more testing

MATRIX 3 : NUMBER OF CHILDREN

Class NOCTool.java 0

ShapeList.java 0

Screen.java 0


Cshape.java 3

Crect.java 0

Ccircle.java 0

TextBox.java 0

Total NOC 0,75

Median 0Standard Deviasi 1.06

Min;Max 0;3

MATRIX 4 : CLASS BETWEEN OBJECTS CBO is the number of collaborations

between two classes (fan-out of a class C)the number of other classes that are

referenced in the class C (a reference to another class, A, is an reference to a method or a data member of class A)

Viewpoints: As collaboration increases reuse decreases High fan-outs represent class coupling to other

classes/objects and thus are undesirable High fan-ins represent good object designs and high level

of reuse Not possible to maintain high fan-in and low fan outs

across the entire system

MATRIX 4 : CLASS BETWEEN OBJECTS

Class CBOTool.java 1

ShapeList.java 2

Screen.java 1


Cshape.java 4

Crect.java 1

Ccircle.java 1

TextBox.java 1

Total COB 14

Median 1Standard Deviasi 1.16

Min;Max 1;4

MATRIX 4 : CLASS BETWEEN OBJECTS

1 s/d 5 6 s/d 10 11 s/d 15 16 s/d 20 21 s/d 25 26 s/d 30 31 s/d 350

1

2

3

4

5

6

7

8

Class Between Object

CBO Value

METRIC 5: RESPONSE FOR A CLASS (RFC)


Jika sebuah class terdiri atas banyak method, besar kemungkinan kompleksitas dari class semakin tinggi

Dan jika banyak method dapat dipanggil untuk merespons pesan yang diterima oleh sebuah obyek dari suatu class besar kemungkinan pemeliharaan dan testing menjadi lebih kompleks.

Respons untuk metriks class bertujuan untuk mengukur banyaknya method lokal dan banyaknya method yang dipanggil oleh method lokal

Tidak terdapat nilai threshold spesifik pada metriks RFC. Namun Chidamber and Kemerer menyarankan semakin besar nilai RFC, semakin besar level pemahaman yang diperlukan sebagai bagian dari tester


Definisi RFC = |RS| dimana RS adalah himpunan respons untuk class

yang diberikan RS = {M} Uall i {Ri} dimana {Ri} = himpunan method-method yang dipanggil

oleh method i dan {M} = himpunan semua method-method dalam class Ilustrasi definisi di atas : A::f1() memanggil B::f2() A::f2() memanggil C::f1() A::f3() memanggil A::f4() A::f4() tidak memanggil method lain Then RS = {A::f1, A::f2, A::f3, A::f4} U {B::f2} U {C::f1} U

{A::f4} = {A::f1, A::f2, A::f3, A::f4, B::f2, C::f1} sehingga RFC = 6


Class RFCTool.java 3

ShapeList.java 20

Screen.java 8


Cshape.java 45

Crect.java 16

Ccircle.java 19

TextBox.java 17

Total RFC 147


1 s/d 5 6 s/d 10 11 s/d 15 16 s/d 20 21 s/d 25 26 s/d 30 31 s/d 350

1

2

3

4

5

6

7

Response for Class

RFC Value

METRIC 6: LACK OF COHESION IN METHODS (LCOM)


Cohesion sebuah class adalah karakteristik seberapa dekat method-method lokal terhubung dengan variabel-variabel lokal dalam sebuah class. S.R Chidamber and C.F Kemerer adalah yang pertama mendefiniskan metriks LCOM pada 1991

Metriks LCOM adalah nilai ketidaksamaan method-method dalam sebuah class

Nilai LCOM yang tinggi dalam sebuah class mengindikasikan lebih baik jika class tersebut dipecah menjadi dua atau lebih sub-class. Hal ini karena class tersebut mungkin terlalu banyak mempunyai tugas untuk dilakukan sehingga akan lebih baik untuk menggunakan obyek yang lebih spesifik.


Definisi Chidamber-Kemerer Terdapat sebuah class C1 dengan n method M1, M2,

…, Mn. Dengan {Ij} = himpunan variabel instance yang digunakan oleh method Mi. Terdapat sebanyak n himpunan {I1}, …, {In}. Dengan P = {(Ii, Ij) | Ii ∩ Ij = ø} dan Q = {(Ii, Ij) | Ii ∩ Ij ≠ ø}. Jika semua himpunan n {I1}, …, {In} adalah ø maka kemudian P = ø.

LCOM = |P| - |Q|, if |P| > |Q|. Otherwise LCOM = 0 Definisi himpunan yang tidak berisisan yang

diusulkan Chidamber-Kemerer sepertinya ambigu dan kemudian didefinisikan ulang oleh Li dan Henry.


Definisi Li-Henry LCOM* = banyaknya himpunan tidak beririsan

dari method-method lokal; tidak ada dua himpunan beririsan; sembarang dari dua method dalam himpunan yang sama yang sharing sedikitnya satu lokal variabel instance; dari 0 sampai N; dimana N bernilai integer positif


Class LCOMTool.java 0

ShapeList.java 0

Screen.java 0


Cshape.java 24

Crect.java 0

Ccircle.java 0

TextBox.java 0

Total RFC 25


1 s/d 5 6 s/d 10 11 s/d 15 16 s/d 20 21 s/d 25 26 s/d 30 31 s/d 350

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Lack Of Cohesion of Method

LCOM Value

REFERENCE Chidamber S.R., Kemerer, C.F.: "A metrics suite for

object-oriented Design", IEEE Transactions on SW Engineering, Vol. 20, No.6, June 1994

Fabrizio Riguzzi:"A Survey of Software Metrics", Università degli Studi di Bologna, July 1996

Lionel Briand, Khaled El Emam, Sandro Morasca :"On the Application of Measurement Theory in Software Engineering",International Software Engineering Research Network technical report #ISERN-95-04

Magnus Andersson, Patrik Vestergren : "Object-Oriented Design Quality Metrics", Uppsala Master’s Theses in Computer Science 276, 2004-06-07, ISSN 1100-1836, Information Technology Computing Science Department Uppsala University Sweden

REFERENCE The Project Manager’s Guide to Software

Engineering’s Best Practice, Mark J. Christensen and Richard H. Thayer, IEEE Computer Society Press

Norman Fenton:"Software Measurement: A Necessary Scientific Basis", IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL. 20, NO. 3, MARCH I994 I99

Everald E. Mills : “ Software Metrics”, SEI Curriculum Module SEI-CM-12-1.1, Software Engineering Institute, Carnegie Mellon University, December 1988

Goal-Question-Metrics files on the internet

CONCLUSION Pada penelitian ini telah dikembangkan

dan diimplentasikan sejumlah software metrik untuk OO desain.Metrik ini berdasarkan teori pengukuran dan juga merefleksikan viewpoint dari pengalaman pengembang software OO.

CONCLUSION Dalam pengevaluasian metrik ini

dengan mencocokan dengan kriteria standar, hal yang dicocokan yaitu : Memiliki sejumlah properti yang diinginkan.

Menyarankan beberapa cara di mana pendekatan OO mungkin berbeda dalam hal fitur desain yang diinginkan atau diperlukan dari pendekatan tradisional.

CONCLUSION Clearly, future or further research are

designed to further investigate these apparent differences seem necessary.

Measurement Metrics for Object Oriented Design

Education

Transcript of Measurement Metrics for Object Oriented Design