14 ooad uml-19

1,349 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,349
On SlideShare
0
From Embeds
0
Number of Embeds
48
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Initiate the session by explaining the session objectives to the students. Tell the students that to ensure the quality of software products, it is important to measure the effectiveness of the software development process at various stages. For this, you need to measure the effectiveness of the process components. In addition, you need to determine the complexity of the design created by using UML artifacts.
  • Explain how to measure a software development process. Explain the dimensions of a process-component.
  • Explain how to measure process components by using the example of the library management system given in the student guide.
  • Explain the concept of weighing factor and then explain how to refine the total unit value.
  • Explain how to obtain the strength of a process-component dimension. Explain the concept of planned productivity and actual productivity. Explain how to calculate the total expected delay in the project by using the example given in the student guide.
  • Explain the concept of adjustment factor. Next, explain how adjustment factor is calculated. Also explain how to calculate the revised time of completion for a successive iteration of a software project.
  • Explain the concept of adjustment factor. Next, explain how adjustment factor is calculated. Also explain how to calculate the revised time of completion for a successive iteration of a software project.
  • Explain the concept of adjustment factor. Next, explain how adjustment factor is calculated. Also explain how to calculate the revised time of completion for a successive iteration of a software project.
  • Explain the concept of adjustment factor. Next, explain how adjustment factor is calculated. Also explain how to calculate the revised time of completion for a successive iteration of a software project.
  • Explain the concept of adjustment factor. Next, explain how adjustment factor is calculated. Also explain how to calculate the revised time of completion for a successive iteration of a software project.
  • Explain the concept of adjustment factor. Next, explain how adjustment factor is calculated. Also explain how to calculate the revised time of completion for a successive iteration of a software project.
  • Explain the concept of adjustment factor. Next, explain how adjustment factor is calculated. Also explain how to calculate the revised time of completion for a successive iteration of a software project.
  • Explain the concept of adjustment factor. Next, explain how adjustment factor is calculated. Also explain how to calculate the revised time of completion for a successive iteration of a software project.
  • Explain the concept of adjustment factor. Next, explain how adjustment factor is calculated. Also explain how to calculate the revised time of completion for a successive iteration of a software project.
  • Tell the students that to determine the quality of a software project, they need to measure the complexity of UML artifacts. Explain what is meant by complexity and explain how to calculate complexity.
  • Explain how to measure the complexity of use case diagrams by using the example of the library management system given in the student guide.
  • Explain how to measure the complexity of use case diagrams by using the example of the library management system given in the student guide.
  • Tell the students that to determine the quality of a software project, they need to measure the complexity of UML artifacts. Explain what is meant by complexity and explain how to calculate complexity.
  • Explain how to measure the complexity of use case diagrams by using the example of the library management system given in the student guide.
  • Explain how to measure the complexity of a class diagram. Also explain the various metrics suites that can be used to measure the complexity of class diagrams.
  • Explain the metrics included in the CK metrics suite by using the examples given in the student guide. Students can calculate the complexity of operations using the software metrics known as cyclomatic complexity. The discussion about this metrics is beyond the scope of this course. Students may refer to page 446 topic 17.4.2 Cyclomatic Complexity of the book, Software Engineering, A Practioner’s Approach, Fifth Edition, by Roger S. Pressman.
  • Explain the metrics included in the MOOD metrics suite by using the examples given in the student guide.
  • Explain the metrics included in the Lorenz and Kidd metrics suite by using the examples given in the student guide.
  • Explain how to measure the complexity of a component diagram. You may discuss with students the Constructive Cost Model (COCOMO) and LOC-Based Estimation model that enables you to estimate the cost and size of the project. COCOMO You use COCOMO to estimate the total effort required to complete a software project successfully. The total effort is the estimate of the number of people required for performing project management and development tasks during the software project life cycle. The unit for estimating the total effort is Person-Month (PM). The effort estimation for a project depends on the type of the software projects. According to COCOMO, there are three types of software projects: Organic: Refers to the projects that require substantial expertise and have flexible requirements. Such projects can be developed by small teams. For example, projects that develop business systems, inventory management systems, and data processing systems are organic projects. Embedded: Refers to the projects that require less expertise, have rigid requirements for interfacing and reliability, and have external constraints. For example, projects that develop real-time systems and large operating systems are embedded projects. Semidetached: Refers to the projects that require medium expertise and have external constraints that are less rigid as compared to that of embedded projects. For example, projects that develop database management systems (DBMS) and large inventory production control systems are semidetached projects. The steps to estimate cost involved in a software project using COCOMO are: <<<<<<<<<<<<INSERT STEPS>>>>>>>>>>>>>> LOC Based Estimation According to Lines of Code (LOC)-based estimation, you need to determine the total number of lines the code to estimate the size of the software project. The lines of code include the executable instructions of the program and exclude the comments. To facilitate the estimation of the lines of code, you can divide the software into modules, which can be further divided into sub modules. The lines of code estimated for each sub module are added to obtain the lines of code for the complete software.
  • Summarize the session by using the summary points given on the slide.
  • Summarize the session by using the summary points given on the slide.
  • 14 ooad uml-19

    1. 1. Object-Oriented Analysis and Design Using UMLObjectives In this session, you will learn to: Measure the process-components of a software development process Measuring a project by using the function point technique Measure the complexity of UML artifacts Ver. 1.0 Slide 1 of 26
    2. 2. Object-Oriented Analysis and Design Using UMLMeasuring Software Development Process To measure a software development process, you need to measure all its process-components. To measure the process-components, you need to measure its dimensions. Like the quality process, the process-component consists of the following dimensions: – Technology: Refers to the output of a process-component. – Methodology: Refers to activities and tasks related to a process-component. – Sociology: Refers to roles in a process-component. Ver. 1.0 Slide 2 of 26
    3. 3. Object-Oriented Analysis and Design Using UMLMeasuring Process-Components To measure all the process-components of a software development process, you need to calculate the total number of roles, activities, output, and tasks. The total number of roles, activities, output, and tasks is also called total unit value. You may need to refine the total unit value in context of a specific environment because the same software can be implemented in various environments. Ver. 1.0 Slide 3 of 26
    4. 4. Object-Oriented Analysis and Design Using UMLMeasuring Process-Components (Contd.) To refine the total unit value, you need to determine: – The number of instances of each dimension of the process-components required in the software development process. – The weighing factors for each dimension of the process-components. The weighing factor for each dimension of process-components depends upon the following: The environment of the software project. The importance of each dimension in the software project. Ver. 1.0 Slide 4 of 26
    5. 5. Object-Oriented Analysis and Design Using UMLMeasuring Process-Components (Contd.) To obtain the strength of the process-component dimensions, you need to multiply the number of instances of the dimensions to their weighing factor. Estimating the number of dimensions of the process-components for each iteration is known as the planned productivity. The actual productivity is determined at the completion of the iteration. To analyze the total expected delay in the project: Calculate the adjustment factor. Calculate revised time required to complete the successive iterations using the adjustment factor. Ver. 1.0 Slide 5 of 26
    6. 6. Object-Oriented Analysis and Design Using UMLMeasuring Process-Components (Contd.) Adjustment factor can be calculated as: Adjustment Factor = Actual productivity / Planned productivity • To calculate the revised time required to complete a successive iteration, you need to divide the planned duration by the adjustment factor. Ver. 1.0 Slide 6 of 26
    7. 7. Object-Oriented Analysis and Design Using UMLMeasuring a Project by Using the Function Point Technique The Function Point (FP) estimation technique is the most popular technique used to estimate the size of a project. This technique breaks systems into smaller components, so they can be better understood and analyzed. FPs are a unit measure for software much like an hour is to measuring time, miles are to measuring distance, or Celsius is to measuring temperature. Ver. 1.0 Slide 7 of 26
    8. 8. Object-Oriented Analysis and Design Using UMLEvolution of FP The FP technique was invented by Albercht of IBM in 1979 and has evolved over the years. The key to identifying the FPs of a software, is to identify the different components that make up a software system. Using the FP technique, the estimation of the total work can be done by counting the total number of: Files Interfaces Inputs Outputs Enquiries Ver. 1.0 Slide 8 of 26
    9. 9. Object-Oriented Analysis and Design Using UMLCalculating FPs Calculating FPs for a project involves the following steps: 1. Determine the type of FP count 2. Identify the scope and application boundary 3. Determine Unadjusted Function Point (UFP) 4. Determine the Value Adjustment Factor (VAF) 5. Calculate the Adjusted Function Point (AFP) Ver. 1.0 Slide 9 of 26
    10. 10. Object-Oriented Analysis and Design Using UMLCalculating FPs (Contd.) Determining the Type of FP Count: The three basic categories of function points based on the type of project are: Development Project FP Count Enhancement Project FP Count Application FP Count Identifying the Scope and Application Boundary: This helps in identifying the components of the proposed system and the system’s references to external components. Ver. 1.0 Slide 10 of 26
    11. 11. Object-Oriented Analysis and Design Using UMLCalculating FPs (Contd.) Determining the UFP: 1. Identify the following two types of information: – Data at rest: Comprises of stored data that is required for processing. – Data in motion: Comprises of transactions that result in movement of data in and out of an application. 2. Based on this information, calculate: – Data FPs: Calculated by measuring the Internal Logical Files (ILFs) and External Interface Files (EIFs) – Together called File Types referenced (FTRs). For each FTR, the following values are measured: – Data Element Types (DETs) – Record Element Types (RETs) – Transaction FPs: These are calculated by measuring the following: External Input (EI) External Enquiry (EQ) External Output (EO) Ver. 1.0 Slide 11 of 26
    12. 12. Object-Oriented Analysis and Design Using UMLCalculating FPs (Contd.) Determining the VAF: VAF is based on General System Characteristics (GSCs). There are 14 GSCs: Data Communication Distributed Processing Performance Objectives Heavily Used Configuration Transaction Rule On-line Update Complex Processing Reusability Installation Ease Operational Ease Multiple Site Use Facility Change Ver. 1.0 Slide 12 of 26
    13. 13. Object-Oriented Analysis and Design Using UMLCalculating FPs (Contd.) To calculate the VAF, you need to: 1. Determine the degree of influence (DI) of each GSC. The DI of a GSC varies from 0 to 5: 0 – Not Present, No Influence 1 – Incidental Influence 2 – Moderate Influence 3 – Average Influence 4 – Significant Influence 5 – String Influence Throughout 2. Add the DIs of the 14 GSCs to obtain the Total Degree of Influence (TDI). 3. Use the following formula to calculate VAF: VAF = TDI ×.01 + 0.65 Ver. 1.0 Slide 13 of 26
    14. 14. Object-Oriented Analysis and Design Using UMLCalculating FPs (Contd.) Calculating the AFP: To calculate AFP, you can use the following formula: AFP = (TUFP + CFP) × VAF Where, CFP is the FP count for conversion functionality. Ver. 1.0 Slide 14 of 26
    15. 15. Object-Oriented Analysis and Design Using UMLDemo: Determining the FP Count Problem Statement Cathy Jones, a project manager at StarMoon Technologies, has to calculate the total FPs for the Inventory Management System project. The following table shows the number of information domains for the different complexities. Information domain Low Medium High User inputs 9 10 5 User outputs 7 6 12 User inquiries 15 9 12 Internal files 12 14 9 External interfaces 10 7 11 Ver. 1.0 Slide 15 of 26
    16. 16. Object-Oriented Analysis and Design Using UMLDemo: Determining the FP Count (Contd.) – The following table lists the fourteen GSCs and their degree of influence. General System Characteristic DI Value Data Communications 5 Distributed Functions 5 Performance 4 Heavily Used Configuration 3 Transaction Rate 4 On-line Data Entry 5 End-user Efficiency 4 On-Line Update 3 Complex Processing 5 Reusability 4 Ver. 1.0 Slide 16 of 26
    17. 17. Object-Oriented Analysis and Design Using UMLDemo: Determining the FP Count (Contd.) – The following table lists the fourteen GSCs and their degree of influence. General System Characteristic DI Value Installation Ease 3 Operational Ease 3 Multiple Sites 4 Facilitates Change 5 – Estimate the size of the inventory management system project by calculating the functional points of the project. Ver. 1.0 Slide 17 of 26
    18. 18. Object-Oriented Analysis and Design Using UMLMeasuring the Complexity of UML Artifacts Complexity refers to the degree of interdependency among the UML artifacts in an object-oriented software system. The complexity of the dynamic components depends upon the complexity of static components. Therefore, you only need to measure the complexity of following static components: Use case diagram Class diagram Component diagram Ver. 1.0 Slide 18 of 26
    19. 19. Object-Oriented Analysis and Design Using UMLMeasuring the Complexity of Use Case Diagrams You measure the complexity of use case diagrams by identifying the number of actors, use cases, and their relationships used in the diagram. You estimate the complexity of a use case in terms of the length of description required to explain the interaction between multiple use cases and actors. The following are the categories of use cases based on the length of their description: – Simple: Refers to the use case whose set of interactions can be described in a single sheet of paper. – Medium: Refers to the use case whose set of interactions can be described in multiple sheets of paper. – Complex: Refers to the use case that shares the extend and include relationships with the other use cases and require multiple sheets of paper. Ver. 1.0 Slide 19 of 26
    20. 20. Object-Oriented Analysis and Design Using UMLMeasuring the Complexity of Class Diagrams You measure the complexity of a class diagram by determining: The size of its classes. The number of relationships among classes. The visibility of attributes of the classes. The visibility of operations of the classes. Complexity of a class diagram also depends upon the number of objects and their relationship. To measure the complexity of a class diagram, you can use the following object-oriented metrics suites: Chidamber and Kemerer (CK) Metrics for Object-Oriented Design (MOOD) Lorenz and Kidd Ver. 1.0 Slide 20 of 26
    21. 21. Object-Oriented Analysis and Design Using UMLMeasuring the Complexity of Class Diagrams (Contd.) In the CK metrics suite, the following class-based design metrics have been proposed for object-oriented systems: – Weighted Methods per Class (WMC): Measure the complexity of a class in terms of the complexity of its operations. – Depth of Inheritance Tree (DIT): Measures the total number of edges in the inheritance tree from its lowest node to its root. – Number of Children (NOC): Measures the number of derived classes associated with a base class. – Response for a Class (RFC): Measures the number of methods in the response set. – Lack of Cohesion in Methods (LCOM): Measures the number of operations that access the same attribute. Ver. 1.0 Slide 21 of 26
    22. 22. Object-Oriented Analysis and Design Using UMLMeasuring the Complexity of Class Diagrams (Contd.) The MOOD metrics suite consists of two metrics that quantitatively measure the characteristics of object-oriented design: – Method Inheritance Factor (MIF): Measures the extent to which a UML class diagram can contain inheritance for accessing operations and attributes of a class. – Coupling Factor (CF): Measures the coupling among classes of a class diagram. Ver. 1.0 Slide 22 of 26
    23. 23. Object-Oriented Analysis and Design Using UMLMeasuring the Complexity of Class Diagrams (Contd.) The Lorenz and Kidd metrics suite consists of three metrics: – Class Size (CS): Measures the size of a class by measuring the total number of operations and attributes encapsulated within the class. – Number of Operations Overridden (NOO): Measures the total number of operations of a base class that a derived class has overridden. – Number of Operations Added (NOA): Measures the total number of operations and attributes that are declared in a derived class and have private visibility. Ver. 1.0 Slide 23 of 26
    24. 24. Object-Oriented Analysis and Design Using UMLMeasuring the Complexity of Component Diagrams Complexity of a component diagram is measured by measuring: Size of the components Processing speed of the components The size of a component diagram depends on: – The number of classes that are realized in the component. – The number of interfaces that share dependency relationship with the component. The processing speed of a component depends on the number of threads supported by the component. Ver. 1.0 Slide 24 of 26
    25. 25. Object-Oriented Analysis and Design Using UMLSummary In this session, you learned that: To measure all the process-components of a software development process, you need to calculate the total number of roles, activities, output, and tasks involved in the software project. The adjustment factor is used to determine the delay in the software project. The FP estimation technique is the most popular technique used to estimate the size of a project. In the FP technique, the estimation of the total work can be done by counting the total number of: Files Interfaces Inputs Outputs Enquiries Ver. 1.0 Slide 25 of 26
    26. 26. Object-Oriented Analysis and Design Using UMLSummary (Contd.) To measure the complexity of UML artifacts, you determine the size and complexity of use case, class, and component diagrams. The CK, MOOD, and Lorenz and Kidd metrics suites measure the size and complexity of a class diagram. The complexity of component diagrams is measured by determining the size and processing speed of components. Ver. 1.0 Slide 26 of 26

    ×