A Quantitative Approach to Software Management And Engineering - Slides | CMSC 735, Study notes of Computer Science

Download A Quantitative Approach to Software Management And Engineering - Slides | CMSC 735 and more Study notes Computer Science in PDF only on Docsity! 1 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil y Part II: OO MEASURES x Object-Oriented Software Measurement • High level design • Low level design • Coding • Testing CMSC 735 A Quantitative Approach to Software Management and Engineering Models and Measures (Product) UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics y Some definitions Coupling Intuitively, it refers to the degree of interdependence between parts of a design Since objects of the same class have the same properties, two classes are coupled when methods declared in one class use methods or instance variables of the other class. Cohesion Intuitively, it refers to the internal consistency within parts of the design The degree of similarity of methods can be viewed as a major aspect of object class cohesiveness. If an object class has different methods performing different operations on the same set of instance variables, the class is cohesive. 2 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics y Size (requirements description,high and low level design) Lorenz and Kidd [Lorenz94] x Number of scenarios (use-cases) scripts (NSS) • directly correlated to the size of the application and to the number of test cases x Number of key classes (domain classes) (NKC) • concerned with high level design and the amount of effort necessary to implement the system and the reuse necessary x Number of support classes (NSC) • concerned with low level design and the amount of effort necessary to implement the system and the reuse necessary x Average number of support classes per key class (ANSC) x Number of subsystems (NSUB) UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics y Size (requirements description,high and low level design) Lorenz and Kidd [Lorenz94] x Class Size (CS) • total number of operations + number the attributes (both including inherited features) x Number of Operations Overridden by a Subclass (NOO) x Number of Operations Added by a subclass (NOA) x Specialization Index (SI) • SI = [NOO x level] / (Total Class methods) 5 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics y Product x Weighted Methods per Class (WMC) Consider a Class C1, with methods M1,…, Mn that are defined in the class. Let c1,…,cn be the complexity of the methods. Then: If all method complexities are considered to be unity, then WMC = n, the number of methods. Viewpoints: 1) number of methods and the complexity of methods correlated with how much time and effort is required to develop and maintain the class 2) the larger the number of methods in a class the greater the potential impact on children, since children 3) Classes with large numbers of methods are likely to be more application specific, limiting the possibility of reuse ∑ = = n i icWMC 1 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics y Product x Depth of Inheritance (DIT) Depth of inheritance of the class is the DIT metric for the class. In cases involving multiple inheritance, the DIT will be the maximum length from node to the root of the tree. Viewpoints: 1) The deeper a class is in the hierarchy, the greater the number of methods it is likely to inherit, making it more complex to predict its behavior 2) Deeper trees constitute greater design complexity, since more methods and classes are involved 3) The deeper a particular class is in the hierarchy, the greater the potential reuse of inherited methods 6 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics y Product x Number of children (NOC) NOC = number of immediate subclasses subordinated to a class in the class hierarchy Viewpoints: 1) Greater the number of children, greater the reuse, since inheritance is a form of reuse 2) Greater the number of children, the greater the likelihood of improper abstraction of the parent class. If a class has a large number of children, it may be a case of misuse of subclassing 3) The number of children gives an idea of the potential influence a class has on the design. If a class has a large number of children, it may require more testing of the methods in that class. UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics y Product x Coupling Between Objects (CBO) CBO for a class is a count of the number of other classes to which is coupled Viewpoints: 1) excessive coupling between object classes is detrimental to modular design and prevents reuse. The more independent a class is, the easier it is to reuse it in another application 2) In order to improve modularity and promote encapsulation, inter-object class couples should be kept to a minimum. The larger the number of couples, the higher the sensitivity to changes in other parts of the design, and therefore maintenance is more difficult 3) A measure of coupling is useful to determine how complex the testing of various parts of a design are likely to be. The higher the inter-object class coupling, the more rigorous the testing needs to be. 7 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics y Product x Response for a class (RFC) The response set of a class is a set of methods that can potentially be executed in response to a message received by an object of that class RFC = |RS| where RS is the response for the class. RS = {M} Uall I {Ri} where {Ri} = set of methods called by method I and {M} = st of all methods in the class Viewpoints: 1) If a large number of methods can be invoked in response to a message, the testing and debugging of the class becomes more complicated since it requires a greater level of understanding required on the part of the tester 2) the larger the number of methods that can be invoked from a class, the greater the complexity of the class 3) A worst case value for possible responses will assist in appropriate allocation of testing time UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics y Product x Lack of Cohesion in Methods (LCOM) Consider a class C1 with n methods M1,M2,…,Mn. Let {Ij} = set of instance variables used by method Mi. Viewpoints: 1) Cohesiveness of methods within a class is desirable, since it promotes encapsulation 2) Lack of cohesion implies classes should be probably be split into two or more subclasses 3) Any measure of disparateness of methods helps identify flaws in the design of classes 4) Low cohesion increases complexity, thereby increasing the likelihood of errors during the development process. otherwise . let then are sets all If . and Let . sets such are There 0 000 0 1 1 = >= =≠= == LCOM |Q|, if |P| |P| - |Q|LCOM P }},...,{I{In} I I) |,I {(IQ } I)|I,I {(IP }},...,{I{In njiji jijin I I 10 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics results regarding to the probability of fault detection in a class during test phases WMC: the larger WMC, the larger the probability of fault detection DIT: the larger the DIT, the larger the probability of defect detection CBO: more significant for UI classes than for DB classes (no satisfactory explanation found for differences in pattern between UI and DB classes) RFC: the larger the RFC, the larger the probability of defect detection LCOM: no significant NOC: the larger the NOC, the lower the probability of defect detection UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement Models and Metrics (high level) bill issue date : DateTime payment date : DateTime price() taxes() customer() list_purchases() warning letters periodic messages message text : Strings 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..* 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 -- -- -- -- -- -- 11 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement Models and Metrics (low level) 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..* 1 warning letters bill issue date : DateTime payment date : DateTime price() taxes() customer() list_purchases() Window size width customer_name issue_date total purchases show_bill() TextBox MOk_button 1..* 0..* 1 0..*Purchase date : DateTime tax : float = 0.05 price() taxes() UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics Some other possible metrics x Average operation Size (OSavg) • the number of messages sent by the operation x Average number of parameters per operation (NPavg) x Operation Complexity (OC) • can be computed using any of the complexity metrics proposed for conventional software x Percent public and protected (PAP) x Public access to data members (PAD) x Number of root classes (NOR) • shows the number of class hierarchies that exist in the system. Large values should be avoid x Fan in (FIN) • FIN > 1 indicates multiple inheritance 12 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Models and Metrics 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 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil 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 Object-Oriented Software Measurement Value CS 4 PAD 0 PAP 0 15 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement y Using metrics to evaluate OO structural complexity [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”. Principles UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil 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 M1,, M2,, M11 M1, M2, M4, M5 G2 M13 M5 G3 M11 G4 M3 M3 G5 M3 M3, M6 G6 M3 M1, M2, M3 M1, M2 M1,, M2 M1, M2, M4 Object-Oriented Software Measurement Guidelines, Principles and Metrics linkage 16 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil 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 Fixed_Rate Loan risk() principal_remaining() Variable_Rate Loan principal _remaining : number risk() principal _remaing() Lender name : text id : text contact : text phone_number : number Borrower name : tex t id : number risk : number status : text r isk() set_status_good() set_status_late() set_status_default() borrower_status() set_status() Bund le active time period : date profit : number estimated risk : number total : number loan analyst : id_number discount_rate : number investor_name : text d a t e_sold : date risk() calculate _profit() cost() Loan Arranger r e c_monthly_report() inv_request() generate reports() identify_report_format() verify _report() look_for_a_lender() look_for_a_loan() identify_loan_by_criteria() manually _select_loans() optimize_bundle() calculate _new_bundle() identify_asked_report() aggregate_bundles() aggregate_loans() aggregate_borrowers()aggregate_lenders() format_report() show_report() Loan amount : number interest rate : number sett lement data : date term : date s ta tus : t ex t original_va lue : number principal_original : number risk() set _status_default() set _status_late() set _status_good() discount_ ra te ( ) borrowers() principal_remaining() 1 1..* 1..* 1..* 1 ..* 0.1 Principles, Guidelines Object-Oriented Software Measurement A set of tools exploring the approach UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil ** ** 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 Object-Oriented Software Measurement A metric table produced with the case tools 17 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Software Measurement TABA Project Model - NOC 0 2 4 6 8 10 12 14 Win dow To ol SS AT ool SD EW i... Po pU p... N ode Me nu Kn ow le... GU Ires o... Fra me wo rk De scr iptiv e Parent Class Name N O C Visualizing the Metrics UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Design Bibliography Fowler97. Martin Fowler and Kendall Scott, UML Distilled: Applying the standard object modeling language, Addison-Wesley, 1997 Booch94. Grady Booch, Object-Oriented Analysis and Design with Applications, The Benjamin/Cummings Publishing Company, Inc, second edition, 1994 Lorenz94. Lorenz, M., and J. Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994 Chidamber94. Chidamber, S.R. and Kemerer, C. F.; A Metrics Suite for Object Oriented Design, IEEE Transactions on Software Engineering, vol.20, no6, June 1994. Basili95. 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 Lie93. W. Lie and S. Henry (1993). Object-oriented metrics that predict maintainability, Journal of Systems and Software. 23(2):111-122. Travassos99 G. H. Travassos, R. S. Andrade, Combining Metrics, Principles and Guidelines for Object Oriented Design, Workshop on Quantitative Approaches on Object Oriented Software Engineering, ECOOP’99, Lisbon, Portugal, 1999 Pressman97 R. S. Pressman, Software Engineering: A Practitioner’s Approach, 4th edition, McGraw Hill, 1997