14 ooad uml-19

Object-Oriented Analysis and Design Using UML
Objectives

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

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


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


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



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.



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.


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


Evolution 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


Calculating 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)


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



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)


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



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



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.


Demo: 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


Demo: 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


Demo: 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.


Measuring 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


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


Measuring 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


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



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.



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.


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


Summary

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


Summary (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.


14 ooad uml-19

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à 14 ooad uml-19

Similaire à 14 ooad uml-19 (20)

Plus de Niit Care

Plus de Niit Care (20)

Dernier

Dernier (20)

14 ooad uml-19

Notes de l'éditeur