Object oriented Full Function Point Analysis: A Model for Real Time Application

(1)

Object oriented Full Function Point Analysis: A

Model for Real Time Application

Sheeba Praveen 1, Dr. Rizwan Beg 2

1_{Dept. CSE,Integral University Lucknow ,U.P.} 2_{Dept .CSE & IT,Integral university Lucknow,U.P.}

1_{er.sheeba.iu@gmail.com} 2_{rizwanbeg@gmail.com}

Abstract- this research work focused on determining the functional size of real time application at early stage. This paper will describe how to estimate the functional size of real time system using OO methodology. In this research we are proposing a Model which is very useful for estimating the size of real time system. And this model is fully based on Object oriented development Methodology due to the adaptation of the Function Point Analysis (FPA) to Object Point Analysis (OPA). This model is for Real Time Application due to that have to take the FFP metric because FFP is best for size measurement of real time system. So the mapping is done in between Full Function Point metrics (FFP) to Object Oriented Function Point metrics (OOFP) and finally we are proposing a new metrics known as OOFFP and the based analysis is known as Object Oriented Full Function Point Analysis (OOFFPA).

Keywords— OOFFPA, OPA, FPA, OO, TFPCP, FFP, OOSE, UML, OOFP, SC, AS, AG, GN/SP, MX, OOMC, OOTC, OOCC, OOUCG, OORCG, OOCECE, OOCECX, OOCICR, OOCICW, OOEI, OOEO, OOEQ, OOILF, OOEIF, OOFC.

I. INTRODUCTION

The size and accuracy of a budget are essential for every project. This research work focused on determining the functional size of Real time application at early stages. This thesis will describe how to estimate the functional size of real time system using object oriented methodology [22].

Estimating different characteristics viz., size, cost, etc. of software during different phases of software development is required to manage the resources effectively. Function points measure can be used as an input to estimate these characteristics of software. The Traditional Function Point Counting Procedure (TFPCP) cannot be used to measure the functionality of an Object Oriented (OO) system. This research work suggests a counting procedure to measure the functionality of an OO system during the design phase from a designers’ perspective. It is adapted from the TFPCP.

This manual presents a measurement technique to extending FP to take into account functional characteristics specific to real-time software which is called Full Function Points (FFP). The main aim of my research is to use all the available information during the OO design phase to estimate Object Oriented Full Function Points (OOFFP) of real time software. The novel feature of this approach is that it considers all the basic concepts of OO systems such as inheritance, aggregation, association and polymorphism.

(2)

II. PROPOSED OOFFPAMODEL

Figure 1. OOFFPA model

In order to calculate the function point from UML diagrams, we use the sequence diagrams and class diagrams. Because these diagrams includes the information about all functions and data manipulated in the system.

III. OBJECT ORIENTED MANAGEMENT FUNCTION COUNT (OOMFC)

A. Object Oriented Function count (OOFC)

Object oriented function counts the Internal and external data requirements called as object oriented Function points (OOFP). Counting OOFPs is a four step process:

1. The object model is analyses to identify the units that are to be counted as logical File 2. The complexity of each logical file and service request is determined

3. Structural items are mapped to complexity level of Low, Average, and High. 4. The values are summed to produce the OOFP.

Classes are generally mapped into logical files, however relationship between classes (Aggregation and generalization/specialization) can sometimes require to count a group of classes as a single Logical File.

Different choices how to deal with aggregation and Generalization/ specialization relationships leads to different ways to identify logical files. Here there are four different choices we identify that are:

1. Single Class(SC):

Count each separate class as a logical file, regardless of its aggregation and inheritance relationship.

Fig.1 SC ILFs 2. Association (AS):

(3)

Fig.2 AS ILFs 3. Aggregation (AG):

Count an entire AG structure as a single logical file, recursively joining lower level aggregations.

Fig.3 AG ILFs 4. Generalization(GN)/Specialization(SP):

Given an Inheritance hierarchy considered as a different logical file, the collection of class compressed in the entire path from root superclass to each leaf subclass.

Fig.4 GN ILFs

5. Mixed (MX): combination of AC, AG/SP, and GN.

(4)

Example:

The counting procedure for each individual class gives the DETs and RETs shown in Figure 7.

The class Binary image has Two DETs (one due to the one data items and one due to the man to-one association with class Face) and one RET (since the class itself is a collection of related data items).

The class Image has one DET due to its two data items, one RET due to the one-to-many aggregation with Face. The Face has one DET and one RET for its own structure.

The class Face Emotion has one DET and Two RETs, one RET due to the one-to-many generalization with emotion and one RET for its own structure.

Each other class has one RET foe its own structure and zero DETs as it has no data items.

Figure7. DET/RET computation for OOLFs on the example system.

Depending on which ILF identification tables with each variant. The value Low is rated as 7 OOFP, according to the IFPUG tables. The highest OOFP count comes when each class is counted as a single ILF. All the other variants have the effect of reducing the OOFP value, as they reduce the number of ILFs. Although there is an increase in DETs/RETs in the merged ILFs, it is not enough to raise the ILF complexity to higher values [15].

Type ILF SR ILF OOFP

SR OOFP

Total OOFP

SC 7 7 (L)

49 49+60 109

AS 6 7 (L)

42 42+60 102

AG 6 7 (L)

42 42+60 102

GN 6 7 (L)

42 42+60 102

MX 4 7 (L)

28 28+60 88

Table 1. Object Oriented Logical Files (OOLFs)

B. Object Oriented Transactional Function Count (OOTC)

(5)

• Object Oriented External input (OOEI): Processes data that come from outside the object oriented software.

• Object Oriented External output (OOEO): Generates data sent outside the object oriented software.

• Object Oriented External inquiry (OOEQ): is a process made up of an input-output combination that results in data retrieval.

Each EI, EO or EQ also has a functional complexity based on the number of data processed. Rule of counting transactional function types are:

In accordance with IFPUG rules, we regard each of the messages, which are exchanged by the object specified as data function in sequence diagrams, as the candidate of transactional function. Then, if a message has no arguments, it means that it doesn’t exchange data and so we determine that it is not a transactional function. At first, in order to count the transactional function from the class and sequence diagrams, we assume the following restrictions:

1. Assume that the sender object sends a message to other object (receiver object) in the sequence diagram. If the receiver object returns meaningful message to the sender one, the reply message must be precisely described in the sequence diagram (According to the definition of the sequence diagrams of the UML, it is not necessary to describe it).

2. Data exchange must be written as the arguments of the messages in the sequence diagram. When an argument of the message whose name is the same as the sender object’s attribute, we recognize the data stored in the argument is simply sent from the sender object.

3. If a message is repeatedly appeared in the sequence diagrams, the arguments and message names must be the same.

For each actor object in the sequence diagrams, we apply the following two steps to count the transactional function types. These steps are based on the fact that function types of the transactional function can be determined by renewal or reference of data functions or comparison of data elements outputted.

(6)

Figure 2. Sequence Diagram of HED

Function Type

Total Functi on

Low Average High Total function type

OOEI 9 6*3 2*4 1*6 32

OOEO 8 6*4 1*5 1*7 26

OOEQ 6 6*3 0*4 0*6 18

+ 76

IV. OBJECT ORIENTED CONTROLE FUNCTION COUNT(OOCC)

A. New control data function types

1. Object Oriented Updated Control Group (OOUCG):

A UCG is a group of control data1 updated by the application being counted. It is identified from a functional perspective2. The control data live for more than one transaction3.

2. Object Oriented Read-Only Control Group (OORCG):

An RCG is a group of control data used, but not updated, by the application being counted. It is identified from a functional perspective. The control data live for more than one transaction [15].

B. Object Oriented New control transactional function types

1. OBJECT EXTERNAL CONTROL ENTRY (OECE):

An ECE is a unique sub-process identified from a functional perspective4. An ECE processes control data coming from outside the application’s boundary. It is the lowest level of decomposition of process acting on one group of data. Consequently, if a process enters two groups of data, there are at least two ECEs. In example 2 section 4.1, one image will be entering for emotion detection to the application (control data cross the application boundary). Since there is one sub-process needed to browse image, therefore 1 ECEs.

2. Object Oriented External Control Exit (OOECX):

An ECX is a unique sub-process identified from a functional perspective. An ECX processes control data going outside the application boundary. It is the lowest level of decomposition of process acting on one group of data. Consequently, if a process exits two groups of data, there are at least two ECXs. In example 2, the sub-

Process that will show the emotion of human (control data sent outside the application boundary) is an ECX.). Since there is one sub-process needed to show emotion, therefore 1 ECX.

3. Object Oriented Internal Control Read (OOICR):

An ICR is a unique sub-process identified from a functional perspective. An ICR reads control data. It is the lowest level of decomposition of process acting on one group of data. Consequently, if a process reads two groups of data, there are at least two ICRs In example 2,7 unique sub-processes need to read different human

(7)

emotions sample (example: happy, sad, normal etc. )at different times for comparison purposes. Therefore, there are 7 ICRs.

4. Object Oriented Internal Control Write (OOICW):

An ICW is a unique sub-process identified from a functional perspective. An ICW writes control data. It is the lowest level of decomposition of process acting on one group of data. Consequently, if a process writes on two groups of data, there are at least two ICWs. In example 2, 15 unique sub-processes need to apply different procedures to detect faces and emotions of human emotions (example: RGB to Binary conversion, apply brazier curve on face etc.) at different times. Therefore, there are15 ICWs [15].

Example:

OOCFC new function types

Description No. of

sub-processes

OOUCG Data updated by the application 8

OORCG Data not updated by the application 10

OOECE Incoming external message 1

OOECX Outgoing external message 1

OOICR Referred attribute in an elementary action 7

OOICW Update attribute in an elementary action 15

Total 42

Table 2. OOCFC

V. CONCLUSION

In this research I am using software development life cycle as a software cost estimation life cycle where I am applying the Full Function Point Metrics on each stages and this technique will help to estimate Size and Cost of Real Time software at each stages of OOSE life cycle. Thus by using OOFFP metrics on OOSE life cycle we can estimate the size of the project which helps to estimate the effort and budget of undeveloped Real Time project.

Refrences

[1] Vol. 2, Issue 3, May-Jun 2012, pp.3052-3056 Software Performance Measurement Metrics and Recitation References

[2] Abran, A., Desharnais, J.-M., Maya, M., St-Pierre, D., & Bourque, P. (1998). Design of Functional Size Measurement for Real-Time Software. Montréal, Université du Québec à Montréal [www document]. URL http://www.lrgl.uqam.ca/publications/pdf/407.pdf

[3] Bohem, R. (1997). Function Point FAQ. Metuchen,USA, Software Composition Technologies, Inc URL http://ourworld.compuserve.com/homepage/softcom/

[4] Desharnais, J.-M. & Morris, P. (1996). Validation Process in Software Engineering: an Example with Function Points. In Forum on Software Engineering Standards (SES‘96), Montreal [www document]..

URL http://www.lrgl.uqam.ca/publications/pdf/104.pdf

[5] Introduction to Function Point Analysis (1998). GIFPA, Issue 2, summer [www document]. URL http://www.gifpa.co.uk/news/News2Web.pdf

(8)

[7] Software Metrics - why bother?.(1998). GIFPA, Issue 1, spring URL http://www.gifpa.co.uk/news/Issue1_ed2.pdf

[8] St-Pierre, D., Maya, M., Abran, A., Desharnais, J.-M. & Oligny, S. (1997a). Full Function Points: Counting Practices Manual. Montréal, Université du Québec à Montréal [www document].

[9] St-Pierre, D., Maya, M., Abran, A., Desharnais, J.-M. & Oligny, S. (1997b). Measuring the functional size of real-time software. Montréal, Université du Québec à Montréal [www document].

[10] Fenton, N. E. & Pfleeger, S. L. (1996). Software Metrics - A Rigorous & Practical Approach. London: International Thomson Computer Press.

[11] Functional Size Measurement for Real-Time Software. Montréal, Université du Québec à J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892, pp.68–73.

[12] An Empirical Validation of Software Quality Metric Suites on Open Source Software for Fault-Proneness Prediction in Object Oriented System I. S. Jacobs and C. P. Bean, “Fine particles, thin films and exchange anisotropy,” in Magnetism, vol. III, G. T. Rado and H. Suhl, Eds. New York: Academic, 1963, pp. 271–350.

[13] Function Point Counting Practices Manual

URLhttp://perun.pmf.uns.ac.rs/old/repository/research/se/functionpoints.pdf [14] United Kingdom Software Metrics Association (UKSMA)

URL http://www.inf.ufpr.br/andrey/ci221/docs/mkiir131.pdf

[15] MK II FUNCTION POINT ANALYSIS COUNTING PRACTICES MANUAL Version 1.3.1

[16] Full Function Points: Counting Practices Manual

URL http://sites.poli.usp.br/d/pmr2490/fp_para_realtime.pdf

[17] Fundamentals of Function Point Analysis By David Longstreet David@SoftwareMetrics.Com URL www.SoftwareMetrics.Com

[18] URL http://en.wikipedia.org/wiki/Function_point

[19] An Evaluation of Function Point Counting Based on Measurement-Oriented Models http://www.bcs.org/upload/pdf/ewic_ea08_paper2.pdf [20] Automated Software Size Estimation based on Function Points using UMLModels

URLhttp://aszt.inf.elte.hu/~gsd/s/cikkek/metrics/sdl/zivkovic_final_revised_v2.pdf

[21] Empirical Software Engineering, 4, 263–287 (1999) °c 1999 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands. URLhttp://faculty.ksu.edu.sa/ghazy/Documents/Emp%20SWE%2099/A%20Function%20Point-Like%20Measure%20for%20Object-Oriented%20Software.pdf

[22] A Function Point-Like Measure for Object-Oriented Software