Estimating Software Size with UML Models Ghislain Levesque, Valery Bevo UQAM, Canada De Tran Cao University of Cantho, Vietnam.

Estimating Software Size with UML Models

Ghislain Levesque, Valery Bevo

UQAM, Canada

De Tran Cao

University of Cantho, Vietnam

AGENDA

• INTRODUCTION

• MEASURING WITH COSMIC-FFP and UML V. 1.4

• INCORPORATING DATA MANIPULATION with UML V. 2.0

• DISCUSSION OF RESULTS

• CONCLUSION

INTRODUCTION

• Why do we measure software size ?• How can we measure software size ?• What are the techniques and methods ?• Do the result take into account the tools

used to develop the software ?• Are there tools that automate this process?• What was the evolution of Function Points

Methods?

Evolution of Function Points Method

AGENDA

• INTRODUCTION




• CONCLUSION

MEASURING WITH COSMIC-FFP and UML V. 1.4

• COSMIC-FFP software model

Functional UserRequirements

Software

FunctionalProcess Type

Sub-Process Types

Data MovementType

Data ManipulationType

MEASURING WITH COSMIC-FFP and UML V. 1.4 : Rice Cooker

• Use cases diagram

Cook

Select cooking mode

Timer

Set targetTemperature

Control indicatorlamps

Control heater

Temparature SensorHeater

Warming Indicator Lamp

Cooking Indicator Lamp


• Sequence diagram - Select Cooking Mode

CookRice Cooker

SystemStorage

Selected cookingmode (1E)

Selected cookingmode (1W)


• Sequence diagram - Set target temperature

TimerRice Cooker

SystemStorage

Every 30s signal(elapsed time) (1E)

Cooking mode (1R)

Target temperature(1W)


• Sequence diagram - Control Heater

TimerRice Cooker

SystemStorage

Every 5s signal (1E)

Heather’s status (on/off signal) (1X)

Targettemperature (1R)

TemparetureSensor

Heather

Actual temperature(1E)


• Sequence diagram - Control Indicator Lamps Timer

RiceCookingSystem

Storage

Cooking status (warming indicator ON/OFFsignal) (1X)

Cooking status (cooking indicator ON/OFF signal) (1X)

CookingIndicatorLamp

WarningIndicatorLamp

Every 30s signal(elapsed time) (1E)

Cooking mode (1R)


• Results:– COSMIC case study v. 2.1 : 12 CFSU (function

points)

– UML v. 1.4 : 13 messages– Difference : two control lamp objects instead of

one that receive their own messages

AGENDA

• INTRODUCTION




• CONCLUSION

INCORPORATING DATA MANIPULATION with UML V. 2.0

• Analyze-triangle specification in narrative text

• The analyze triangle process accepts values A, B and C that represent the side dimensions of triangle. The process tests the dimension values to determine whether all values are positive. If a negative value is encountered, an error message is produced. The process evaluates valid input data to determine whether the dimensions define a valid triangle and if so, what type of triangle- equilateral, isosceles or scalene – is implied by the dimensions. The type is the output.

Analysetriangle

Side dimensionsof triangle

Errormessages

Type oftriangle


• According to COSMIC-FFP, the size of this software is :– One entry : side dimensions– Two exits : error message and type of triangle– Total : 3 CFSU (function points)


• According COSMIC-FFP and UML v. 1.4, the size of this software is three messages :

UserTriangleSystem

Dimensions

Enter 3dimensions (1 E)

Validate

Return errormessage (1 X)

Return triangletype (1 X)

or


READ Side dimensions

Any dimension isnegative

Largestdimension < the sum

of others

Three sidesare equal

Two sidesare equal

Error message

No triangle

Type isequilateral

Type isisoceles

Type isscalene

No

Yes

No

Yes

Yes

YesNo

No

Flowchart showing the 5 cases to test


: User: Triangle

System: Dimensions

Enter 3 dimensions (1 E)

[a or b or c < 0]

Return error message (1 X)

opt

[largest < sum of others]

Return “no triangle” (1 X)

alt

else [3 sides equal]Return “triangle type is

equilateral” (1 X)

else [2 sides equal]Return “triangle type is

isosceles” (1 X)

elseReturn “triangle type is

scalene” (1 X)


• According to UML v. 2.0, there are 6 messages exchanged

• So estimating the size by the number of messages exchanged would mean that this software has 6 function points.

AGENDA

• INTRODUCTION




• CONCLUSION

DISCUSSION OF RESULTS

• By modeling software in Actor-Object sequence diagram according to UML v. 1.4, it is possible to obtain an equivalent software size estimation to COSMIC-FFP by counting the number of messages exchanged


• Going further and modeling software by UML v. 2.0 Actor-Object sequence diagram, it is possible to take into account data movements and data manipulation to size this software by counting the number of messages exchanged.


• By modeling software in UML sequence diagram, and counting the number of messages involved, it is possible to get 3 types of measures:– Actor-System– Actor-Object (UML v. 1.4)– Actor-Object (UML v. 2.0)

• which corresponds to stepwise refinement of requirements and models

• These results should then be tested at large with a sample of projects to model productivity

AGENDA

• INTRODUCTION




• CONCLUSION

CONCLUSION

• UML is a standard notation to model software• If those results are confirmed at large, the size

could be determined at each step of the development process with more precision

• The count would be provided by case tools• The software engineers would get the size directly

by modeling the software and counting messages; he could forget about function point methods.

Contact

• Ghislain Levesque and Valery Bevo – University of Quebec at Montreal

Dept.of Computer ScienceP.O. Box 8888, Station C.V., [email protected]

– [email protected]

• De Tran Cao – University of Cantho CICT, Vietnam – [email protected]

mailto:[email protected]





Estimating Software Size with UML Models Ghislain Levesque, Valery Bevo UQAM, Canada De Tran Cao University of Cantho, Vietnam.

Documents

cosmic ffp

uml sequence diagram

vietnam slide

productivity slide

cfsu function points

modeling software

uml models ghislain

actorsystem actorobject