Models and Measures Product - Lecture Slides | CMSC 735, Study notes of Computer Science

Download Models and Measures Product - Lecture Slides | CMSC 735 and more Study notes Computer Science in PDF only on Docsity! 1 CMSC 735 A Quantitative Approach to Software Management and Engineering UFRJ COPPE Brazil Guilherme H. Travassos http://www.cos.ufrj.br/~ght UMCP - CS ESEG Models and Measures (Product) UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Outline y INTRODUCTION x Products Measurement y Part I: OO MODELS x Object-Oriented Paradigm x Engineering Object-Oriented Software x Representing OO Software Products using UML • High-Level Design • Low-Level Design y Part II: OO MEASURES x Object-Oriented Software Measurement • High level design • Low level design • Coding • Testing 2 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil y INTRODUCTION x Products Measurement CMSC 735 A Quantitative Approach to Software Management and Engineering Models and Measures (Product) UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Products Measurement y Metrics for any engineered product are governed by the unique characteristics of the product y As for conventional software, OO metrics aim to: x better understand the quality of the product x assess the effectiveness of the process x improve the quality of work performed What makes an OO product different from a conventional one? How do we measure the quality of an OO system? What characteristics of the design model can be assessed to determine whether the system will be easy to implement, amenable to test, simple to modify, and most important, acceptable to end users? 5 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Paradigm Identity data is organized into discrete, distinguishable entities called objects an object has states and behaviors. A reference (handle) distinguishes different objects UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Paradigm Abstraction How many viewpoints (perspectives) can be used while building a system? Abstractions form a hierarchy! 6 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Paradigm Classification an important OO development activity depends on the abstraction level and the viewpoint (perspective) used by the developer UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Paradigm Classification Objects with the same features (attributes and behaviors) are grouped into a class Each class defines a possibly infinite set of objects 7 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Paradigm Classification Bicycle objects Bicycle class Attributes frame size wheel size gears material Operations shift move repair abstract into Polygon objects abstract into Polygon class Attributes vertices border color fill color Operations draw erase move UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Paradigm Classification Each object is said to be an instance of a class Each object knows its class Each instance keeps its own attributes value (state) but shares attribute names and behaviors (operations) with other instances of the class 10 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Paradigm Polymorphism a specific implementation of an operation for a certain class is called a method an operator may have more than one method implementing it an OOPL automatically elects the correct method to implement an operation based on the name of the operation, carried data (parameters) and object’s class being implemented (method signature) therefore, new classes can be added without changing existing code Doctor name age office attend_patient() Surgeon name age office specialty attend_patient() Family Doctor name age office home address attend_patient() UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Object-Oriented Paradigm Persistence the object state and its behaviors will be saved across the time or space an object existence transcends time and/or space 11 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Engineering Object-Oriented Software OO Software Process Features: y works with the encapsulation of data and behavior into independent units (objects) y uses the same set of semantic constructs to represent the system from the requirements to the application y supports different software life-cycles y stimulates reuse In general, it deals with (but not using a totally sequential approach): y requirements description (textual description and scenarios) y high-Level design y low-Level design y coding y testing UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Engineering Object-Oriented Software High Level Design: y Classes/Objects identification x real world (problem domain) objects definition x attributes and behaviors detailing y Classes/Objects interaction identification x association and aggregation relationships x probably some inheritance relationships Low-Level Design y inserting computational features into the models (user interface, tasks, persistence,…) and some class libraries details (uses a bottom-up approach) y good time to deal with non-functional requirements (performance, security, etc.) y classes contract preparation y starting code 12 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Engineering Object-Oriented Software Coding y translates OO models to some OO programming language y refines hierarchical structures y in some situations, makes some generalization for future use (components) Testing y unit testing y integration testing y system testing y acceptance testing Class hierarchy Class Cluster Subsystem System Unit testing System testing Acceptance testing Integration testing Ab st ra ct io n le ve l Figure 1: O.O. Testing level UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Engineering Object-Oriented Software Representations y Static views: x objects x attributes x behavior x relationships: generalization, aggregation and inheritance y Dynamic views : x communication x control/temporization x states y Restrictions: x in the structure (attribute values, relationship cardinality ) x in the dynamic behavior 15 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil High-Level Design UML Class diagram y captures problem vocabulary y relates everything together y models information in a system y anchors behavior to classes y generates class structure declarations UML Relationships y association x aggregation: is the part-of relationship x composition: the whole salesman 1..* 1 ordered item 1 1..* Customer order sends includes has name : string address : string birthday : date Customer pay_by_cash() 1Class name Attribute:Type = initial Value operation(arg list):return type UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Part part_code price discount rate min_quantity = 2 current_quantity gas ordering system inventory order_gas() order_part() 1..* 1 parts ordering system car maintenance price = 150.00 price() 0..* periodic messages message text Customer name address SSN birthday account_number warning letters bill issue date payment date price() taxes() gas min_quantity = 100 current_quantity 1 1 refuel gallons price = 1.09 price() 1 0..* parking spot place is_available() parking price = 5.00 1 0..1 services discount rate price() Purchase date tax = 0.05 price() taxes() 1..* 1 1 0..* 1..* 0..* gas station dormant_accounts() CC system An example of a class diagram 16 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil High-Level Design A Class Description 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 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil High-Level Design UML Package diagrams y used to break down a large system into smaller and meaningful sets of classes (clusters) y shows the dependency among classes of different packages. A dependency exists between two elements if changes to the definition of one element may cause changes to the other (coupling) x Possible dependencies between two classes: • one class sends a message to another one • one class has another one as part of its data • one class mentions another one to be a parameter to an operation y packaging is a vital technique for large projects: x allows keeping system’s dependencies to a minimum reducing coupling x is particularly useful for testing 17 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil High-Level Design UML Package diagram External Systems Products Customers Service Packaging Gas Station classes car maintenance price = 150.00 price() refuel gallons price = 1.09 price() services discount rate price() parking price = 5.00 parking spot place is_available() 0..1 1 package dependency package contents UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil High-Level Design UML Interaction diagram y used to describe how a functionality can be obtained from the objects y typically, one interaction diagram represents just one use-case y good to represent sequential functions, without much conditional or looping control y two types of interaction diagrams: x sequence diagrams x collaboration diagrams 20 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil High-Level Design UML State diagrams y show possible object states, events that induce the transition from one state to another and possible actions associated to these events y represent the dynamic model view of a simple object, object’s hierarchy or the whole system y Normally, are only prepared for classes whose instances are very dynamic object state ≡ attributes value events ≡ messages UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil High-Level Design UML State diagrams y Notation x state: • means cumulative results of the object behavior/system functionality x transition (event): • some occurrence which can induce an object/system state change authorizing authorized start end state transition state actions: actions can be associated to states conditional transition: some transition will be occur if a condition can be satisfied nesting states: states can be partitioned Authorizing Authorized Purchased Rejected [payment not OK][payment ok] [time <= 7] 21 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil High-Level Design Gas Station states diagrams available not available Customer_request Customer release parking spot place : Strings is_available() next_available()inventory order_gas() order_part() normal stock Low gas Low parts ordering parts ordering gas parts low in stock gas low in stock delivery gas delivery parts UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil High-Level Design UML Activities diagram y can be used to model procedures activity flow y an activity is similar to a state y an event is similar to an transition y decisions can be represented if an activity has more than one event y normally, are associated to states diagrams of several classes activity A activity B start Initial activity activity X end transition activity B activity C activity D decision output A output B The bar shows that one activity can broadcast data to other activities (parallels or not determined activities) 22 UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Low-Level Design y Advantages while using the same notation x developers don’t need to learn/use different constructs and representation x analysis/design transition is an entwining and soft process x it improves reuse, extensibility and readability x the results from the High-level design compose the initial problem domain design that should be modified and extended to satisfy all non-functional requirements UMCP - CS ESEGUFRJ/COPPE CAPES - Brazil Low-Level Design x Problem domain design • model modification: – early projects and coded classes reuse – adjusting supported inheritance level – performance and I/O issues – data management support – low level components – high level design extensions review • Creating/Destroying Objects – defines how each concrete class may create its objects (instantiation) – describes how objects might be destroyed – it’s important to observe the restrictions applied to the class structure to maintain model consistency • Inserting computational features: user interface, task and data management • Decisions regarding deployment and physical software architecture