Slide 1

A Metric Suite for Object Oriented DesignShyam R. Chidamber and Chris F. KemererAri WibisonoBambang AdhiAchmad RohmanOutlineContributionResearch ProbelmsTheoritical CriticismOO design and development.Objective 1) to propose metrics that are constructed with a firm basis in theoretical concepts in measurement and the ontology of objects, and which incorporate the experiences of professional software developers;2) evaluate the proposed metrics against established criteria for validity, and3) present empirical data from commercial projects to illustrate the characteristics of these metrics on real applications, and suggest ways in which these metrics may be used7Theory Base for OO Metrics1. Identification of Classes (and Objects): In this step, key abstractions in the problem space are identified and labeled as potential classes and objects. Identif) the Semantics of Classes (and Objects): In this step, the meaning of the classes and objects identified in the previous step is established, this includes definition of the life-cycles of each object from creation to destruction.2.IdentifyRelationships Between Classes (and Objects): In this step, class and object interactions, such as patterns of inheritance among classes and pattems of visibility among objects and classes (what classes and objects should be able to see each other) are identified.3.Implementation of Classes (and Objects): In this step, detailed intemal views are constructed, including definitions of methods and their various behaviors. 8Measurement Theory BaseAn object oriented design can be conceptualized as a relational system, which is defined by Roberts as an ordered tuple consisting of a set of elements, a set of relations and a set of binary operations9Empirical Data CollectionSoftware Dev OrganizationSite A is a software vendor that uses OOD in theirdevelopment work and has a collection of different C++class libraries. Metrics data from 634 classes from two C++class libraries that are used in the design of graphical userinterfaces (GUI) were collected. Both these libraries were usedin different product applications for rapid prototyping anddevelopment of windows, icons and mouse-based interfaces.Reuse across different applications was one of the primarydesign objectives of these libraries. These typically wereused at Site A in conjunction with other C++ librariesand traditional C-language programs in the development ofsoftware sold to UNIX workstation users.Site B is a semiconductor manufacturer and uses theSmalltalk programming language for developing flexiblemachine control and manufacturing systems. Metrics werecollected on the class libraries used in the implementation ofa computer aided manufacturing system for the production ofVLSI circuits. Over 30 engineers worked on this application,after extensive training and experience with object orientationand the Smalltalk environment.11ResultsMetric 1 : Weighted Method Per Class

Theoretical Basis: WMC relates directly to Bunge's definitionof complexity of a thing, since methods are properties ofobject classes and complexity is determined by the cardinalityof its set of properties. The number of methods is, therefore,a measure of class definition as well as being attributes of aclass, since attributes correspond to proper tie^.'^13Character Graphics

Matrix 1 : Weight Method per ClassCase Study : Character GraphicsNumber of Class Observed : 8Number of Method Observed : 59

How TO ObserveDCyclomatic complexity

Weight Method per Class (Statistics)ClassWMCTool.java1ShapeList.java30Screen.java13DrawingPackage.java19Cshape.java10Crect.java15Ccircle.java20TextBox.java13Total WMC12118Weight Method per Class (Character Graphics)WMC ResultCyclomatic ComplexityTestabilityUnderstandability(SATC 1995)Matrix 3 : Depth of Inheritance TreeDIT 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 predictDeeper trees indicate greater design complexity Matrix 2 : Depth of inheritance TreeClassDITTool.java0ShapeList.java0Screen.java0DrawingPackage.java0Cshape.java0.75Crect.java0Ccircle.java0TextBox.java0Total DIT0,7522Matrix 2 : Depth of inheritance Tree23Matrix 3 : Number of ChildrenNOC 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 ClassNOCTool.java0ShapeList.java0Screen.java0DrawingPackage.java0Cshape.java3Crect.java0Ccircle.java0TextBox.java0Total NOC0,75Median0Standard Deviasi1.06Min;Max0;325Matrix 4 : Class between objectsCBO 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 decreasesHigh 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 objectsClassCBOTool.java1ShapeList.java2Screen.java1DrawingPackage.java3Cshape.java4Crect.java1Ccircle.java1TextBox.java1Total COB14Median1Standard Deviasi1.16Min;Max1;427Matrix 4 : Class between objects28Metric 5: Response For a Class (RFC)29Metric 5: Response For a Class (RFC)Jika sebuah class terdiri atas banyak method, besar kemungkinan kompleksitas dari class semakin tinggiDan 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 lokalTidak 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 testerResponse For a Class (RFC)If a class consist of a large number of methods it is likely that the complexity of the class is high. And if a large number of methods can be invoked in response to a message received by an object of that class it is likely that the maintenance and testing becomes complicated. Shyam R. Chidamber and Chris F. Kemerer proposed in 1991 [3] the response for a class metric to measure the number of local methods and the number of methods called by the local methods.There is no specific threshold value on the RFC metric evolved. But in [3] Chidamber and Kemerer suggest that the greater the value of the RFC, the greater the level of understanding required on the part of the tester.DefinitionRFC = |RS| where RS is the response set for the class, given byRS = {M} Uall i {Ri}where {Ri} = set of methods called by method i and{M} = set of all methods in the class [7].To illustrate this definition consider the following example:A::f1() calls B::f2()A::f2() calls C::f1()A::f3() calls A::f4()A::f4() calls no methodThen 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}and RFC = 6

30Metric 5: Response For a Class (RFC)DefinisiRFC = |RS| dimana RS adalah himpunan respons untuk class yang diberikanRS = {M} Uall i {Ri}dimana {Ri} = himpunan method-method yang dipanggil oleh method i dan{M} = himpunan semua method-method dalam classIlustrasi definisi di atas : A::f1() memanggil B::f2()A::f2() memanggil C::f1()A::f3() memanggil A::f4()A::f4() tidak memanggil method lainThen 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

31Metric 5: Response For a Class (RFC)ClassRFCTool.java3ShapeList.java20Screen.java8DrawingPackage.java19Cshape.java45Crect.java16Ccircle.java19TextBox.java17Total RFC14732Metric 5: Response For a Class (RFC)33Metric 6: Lack of Cohesion in Methods (LCOM)1. Kekompakan metode dalam kelas yang diinginkan, karena mempromosikan enkapsulasi.2. Kurangnya kohesi menyiratkan mungkin kelas harus dibagi menjadi dua atau lebih subclass.3. Setiap ukuran disparateness metode membantu mengidentifikasi kelemahan dalam desain kelas.4. Kohesi rendah meningkatkan kerumitan, sehingga meningkatkan kemungkinan kesalahan selama proses pembangunan.

KEUNTUNGAN PRINSIP ENCAPSULATION (ENKAPSULASI) Enkapsulasi adalah bagaimana kita membungkus data dan method yang menyusun kelas sehingga kelas dapat dipandang sebagai suatu modul. Disini juga menentukan tingkat aksesibilitas dari masing-masing data dan method serta menyembunyikan detail implementasinya dari dunia luar ( data,method,kelas, interface, atau package lain yang mungkin berinteraksi dengan modul tersebut ).

Keuntungan menerapkan prinsip enkapsulasi :a. Bersifat Independen, dapat digunakan pada bagian manapun pada prograb. Bersifat Transparan, bila kita melakukan modifikasi pada suatu model, maka perubahan juga akan dirasakan juga oleh bagian program yang menggunakan modul tersebut.c. Menghindari efek di luar perencanaan

Modul hanya akan berinteraksi dengan bagian program lainnya melalui veriabel-variabel input/output yang telah didefinisikan sebelumnya, sehingga akan mereduksi kemungkiann adanya hasil imbas pemrosesan yang diluar perencanaan semula.

34Metric 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 1991Metriks LCOM adalah nilai ketidaksamaan method-method dalam sebuah classNilai 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.Metric 6: Lack of Cohesion in Methods (LCOM)Definisi Chidamber-KemererTerdapat 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 = 0Definisi himpunan yang tidak berisisan yang diusulkan Chidamber-Kemerer sepertinya ambigu dan kemudian didefinisikan ulang oleh Li dan Henry.

To illustrate these two different definitions consider the following example:Given a class C and its variables a, b, c and d the following methods are present:Method W accesses variables {a, b}.Method X accesses variable {c}.Method Y accesses no variables.Method Z accesses {b, d}.Using the Li and Henry definition of the LCOM metric (LCOM*), the disjoint sets of methods, where any two methods in the same set share at least one local instance variable, would be:{W, Z}, {X}, {Y}The result is three different sets and thus the LCOM value is 3.Using the definition proposed by Chidamber and Kemerer to calculate LCOM:W X = W Y = W Z = {b}X Y = X Z = Y Z = P = 5, the intersections whose result is . Q = 1, the intersections whose result is not .LCOM = |P| - |Q| = 5 1 = 4.

36Metric 6: Lack of Cohesion in Methods (LCOM)Definisi Li-HenryLCOM* = 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 positifTo illustrate these two different definitions consider the following example:Given a class C and its variables a, b, c and d the following methods are present:Method W accesses variables {a, b}.Method X accesses variable {c}.Method Y accesses no variables.Method Z accesses {b, d}.Using the Li and Henry definition of the LCOM metric (LCOM*), the disjoint sets of methods, where any two methods in the same set share at least one local instance variable, would be:{W, Z}, {X}, {Y}The result is three different sets and thus the LCOM value is 3.Using the definition proposed by Chidamber and Kemerer to calculate LCOM:W X = W Y = W Z = {b}X Y = X Z = Y Z = P = 5, the intersections whose result is . Q = 1, the intersections whose result is not .LCOM = |P| - |Q| = 5 1 = 4.

37Metric 6: Lack of Cohesion in Methods (LCOM)ClassLCOMTool.java0ShapeList.java0Screen.java0DrawingPackage.java1Cshape.java24Crect.java0Ccircle.java0TextBox.java0Total RFC2538Metric 6: Lack of Cohesion in Methods (LCOM)39ReferenceChidamber S.R., Kemerer, C.F.: "A metrics suite for object-oriented Design", IEEE Transactions on SW Engineering, Vol. 20, No.6, June 1994Fabrizio Riguzzi:"A Survey of Software Metrics", Universit degli Studi di Bologna, July 1996Lionel Briand, Khaled El Emam, Sandro Morasca :"On the Application of Measurement Theory in Software Engineering",International Software Engineering Research Network technical report #ISERN-95-04Magnus Andersson, Patrik Vestergren : "Object-Oriented Design Quality Metrics", Uppsala Masters Theses in Computer Science 276, 2004-06-07, ISSN 1100-1836, Information Technology Computing Science Department Uppsala University Sweden

ReferenceThe Project Managers Guide to Software Engineerings Best Practice, Mark J. Christensen and Richard H. Thayer, IEEE Computer Society PressNorman Fenton:"Software Measurement: A Necessary Scientific Basis", IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL. 20, NO. 3, MARCH I994 I99Everald E. Mills : Software Metrics, SEI Curriculum Module SEI-CM-12-1.1, Software Engineering Institute, Carnegie Mellon University, December 1988Goal-Question-Metrics files on the internet

ConclusionPada 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.

ConclusionDalam 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.

ConclusionClearly, future or further research are designed to further investigate these apparent differences seem necessary.