Measuring Function Points from VDM-SL Specifications

Transcription

1 40 1 Measuring Function Points from VDM-SL Specifications Tomoko Miyawaki, Junichi Iijima and Sho Ho Abstract The motivation of this paper is to enhance system development efficiency by integrating system modeling methods and system scale measurement methods. Among system modeling methods, FPM (Function Point Method) has been attracting a lot of attention. In this paper, we first propose a method to measure function points from specifications written with a widely used formal specification language VDM-SL (Vienna Development Method- Specification Language). Then the development of an automatic measurement tool based on this method is introduced. Finally, to demonstrate the effectiveness of our method, measurement of a sample case using the proposed method is examined and discussed. Index Terms Software development, Specification languages I. INTRODUCTION ECENTLY, the concept of highly dependable or highly R reliable systems is attracting attention in service management field. Especially, current network based information systems become large scale and complicated, consequently there is a possibility to have a serious damage in social life when we have a failure in such a system. While Project delay and budget overrun has been a significant problem in software projects. What can we do to develop software and sell it at proper price for its functions? Firstly, we need to model the system to reflect the demand of users correctly; secondly, we must measure the size of the system precisely to estimate the period, cost, and so on. The purpose of this paper is to enhance information system development efficiency by integrating modeling methods and system scale measurement methods. Concretely, we try to devise the measurement method of Function Point (FP hereafter) with VDM-SL (Vienna Development Method Specification Language) specifications. An automatic measurement tool is also developed based on the proposed method. By applying implemented automatic measurement tool to a sample case, advantages and problems of the tool are examined. Manuscript received December 1, Tomoko Miyawaki is a Master Candidate at the Graduate School of Decision Science and Technology, Tokyo Institute of Technology ( miyawaki.t.aa@m.titech.ac.jp). Junichi Iijima is a professor with Graduate School of Decision Science and Technology, Tokyo Institute of Technology (phone: ; fax: ; iijima.j.aa@m.titech.ac.jp). Sho Ho is an assistant professor with Graduate School of Decision Science and Technology, Tokyo Institute of Technology (ho.s.aa@m.titech.ac.jp). II. BACKGROUND AND RELATED WORKS A. Overview of Function Point FP is one of the ways to measure the size of software, proposed by Allan J. Albrecht over 30 years ago[1]. Later, in 1986, IFPUG (International Function Point Users Group)[2] was founded. The guideline for FP method formulated by IFPUG is called IFPUG rule and is adopted as an ISO standard [3]. The IFPUG rule has become a de-facto standard for FP method today. In this research, FP is counted following IFPUG rule. In FPM, functions are identified and enumerated based on the requirement definition from the user's viewpoint. Number of functions is counted to measure the size of the system [4]. As shown in Fig.1, basically, functions counted in FPM can be divided into two types: data function (DF) type and transaction function (TF) type. Data function type is determined from Internal Logical Files (ILF) and External Interface Files (EIF); Transaction Function type is determined from External Inputs (EI), External Outputs (EO) and External Queries (EQ). Once ILF, EIF, EI, EO and EQ items are enumerated, each item is assigned a subjective simplicity rating on a three-point ordinal scale: simple, average, or complex. [5] The rating is based upon DET s (Data Element Type), RET s (Record Element Type) and FTR s (File Type Referenced). A DET is a unique user recognizable, non-recursive field which is dynamic. Elements such as calculated values and confirmation messages are counted as DET; An RET is a user recognizable sub group of data elements within an ILF or an EIF; An FTR is a file type referenced by a transaction. An FTR must also be an ILF or an EI [6]. User External Input (EI) External Output (EO) External Inquiry (EQ) Measured Application Internal Logical File (ILF) Fig.1. Five items of FP Not Measured Application External Interface File (EIF) After rating all ILF, EIF, EI, EO and EQ items, a weight is assigned to each item according to its type and its simplicity

2 40 2 rating. Since there are five types of items and three levels of simplicities, we have 15 different varieties of items. By calculating weight sum of number of items of each variety, we get UFC (unadjusted function point count). Finally, the complexity of the whole system is evaluated and a TCF (technical complexity factor) is calculated based on some properties of the system. By multiplying UFC and TCF, we will get the adjusted function point count [5]. Since TCF is calculated based on some properties which can not be determined from functionality specifications, we limit our research in calculating unadjusted function point count (UFC) from VDM-SL specifications. B. Overview of VDM-SL VDM-SL is a formal specification language used in systems development when the target system requires high reliability. For example, IC card system, air traffic control system and automatic control for vehicle are representative applications. Fig.2 shows a sample VDM-SL specification taken from a text book [7]. The VDM - SL specification describes an address book software. It includes two parts: data definition block and function definition block. There are several basic data types (int, real, char, bool etc.) in VDM-SL. In data definition block, these basic types are built into more complex types using type constructors (enumeration, record, collection and mapping) [8]. For example, in Fig.2, AddressBook is a data type built from two data types, Name and Address, by using mapping type constructor. Hereafter, we call this kind of data types mapping type and call the data type of the domain and range as domain data type and range data type. In Fig.2, domain data type of AddressBook is Name and range data type is Address. types Name = String; Address = String; String = seq of char; AddressBook = map Name to Address; functions AddAddress : Name * Address * AddressBook -> AddressBook AddAddress (name, address, book) == book munion {name -> address} pre name not in set dom(book) ; FindAddress : Name * AddressBook -> Address FindAddress(name, book) == book(name) pre name in set dom(book) ; Fig.2. VDM-SL specification sample In function definition block of a VDM-SL specification, a definition of a function may include a signature, an explicit function definition and pre/post conditions. The signature part shows the data types of the input parameters and the result. For example, in Fig.2, input parameter data types of function AddAddress are Name, Address and AddressBook and result data type is AddressBook. Models expressed in a formal language are applicable to a wide range of analysis techniques including mathematical proof, and much of the benefit of developing a formal model lies in the ability to analyze the model to check that it reflects intuition about the real system it describes. [8] As a wildly used specification language, VDM-SL is supported by a wide range of tools. The VDM-SL Toolbox [9] is one of the tools that support editing, syntax checking and verification of models written with VDM-SL. We use this tool as a model editor in our FP calculating system. C. Related Works Though there are many efforts on automatic calculation of FP, researches on measuring FP from formal specifications are limited. Gramantieri et al. tried to measure FP from ER-DFD, which combined Entity Relationship Diagram (ER Diagram) with Data Flow Diagram (DFD) [10]. In this way, one can count FP visually with ER Diagram and DFD. They also introduced a system that uses ER-DFD as input of a prolog program to automatically calculate FP. While claiming that ER-DFD can be easily checked both by a human or a computer program, Gramantieri et al. also have recognized the necessity of measuring FP from formal specifications and have mentioned about to investigate the counting of FP from other, more formal, specification languages, such as Z. [10] In 1999, Frappier analyzed a set of formal specification languages, classified them into several types and evaluated their adequacy for specifying industrial information systems and for formalizing the function point measure [11]. In Frappier's classification, VDM is a state machine language as well as B, Z and OCL. He pointed out that there is a natural mapping between state machine languages and function points while some parts of the IFPUG function point counting manual (e.g. identification of data components) can not be formalized using state machine languages, because they are subjective [11]. In 2002, Diab, Frappier and St-Denis reported about their research on automatic measurement of FP from the formal specification notation B [12], which is a notation based on set theory and logic developed by Abrial [13]. In Diab el al. s research, functions was successfully counted; however, the measurement of the complexity of functions was left ambiguous. Compared with B, VDM-SL provides more methods to define data types. Varies data types can be integrated into a new data type to deliver a brief and clear specification. Using this feature of VDM-SL, we try to enhance the accuracy in automatic measurement of FP, especially in measurement of the complexity of functions.

3 40 3 III. MEASURING UFP FROM VDM-SL SPECIFICATION A. Seven steps to measure UFP The following is the steps to measure unadjusted FP from VDM-SL specification. 1) Find data function from type definition. 2) Measure DET and RET of data function. 3) Find EI, EO, and EQ. 4) Decide ILF and EIF from data function. 5) Measure DET and FTR of transaction function. 6) Set complexity of each function. 7) Sum all functions FP. B. Notation of Set Theory Now, let us introduce the notation of set theory to use in our measurement method. -- Z : VDM-SL Specification of application to measure FP -- Btypes = {nat, nat1, int, real, bool, char, token} : the set of basic data types -- types(z) : the set of types defined in Z -- functions(z) : the set of functions defined in Z C. Measurement Method 1) Find Data Function Since data function is a group of logically related data, we try to detect data function by examining mapping type data in VDM-SL specification. In a VDM-SL specification, the data type definition block formulates data that will be used in the system. Data function can be detected from this block. In a database, at least one field should be set as unique identifier (primary key) in a table. Once the identifier is specified, the data record would be uniquely identified. The relation between primary key and data record is similar with the relation of domain and range of a mapping type data. We count mapping type data in VDM-SL specification as data functions (DF). Since the domain data type serves as an identifier, mapping type data with the same domain data type are counted as one data function. We define DF as follows: Since mapping type data in VDM-SL specification is associated with RET, the data type of domain and range of a mapping type should be distinguished as DET of the data function in which RET is included. In VDM-SL. a data type S can be composed as a Cartesian product of types T 1,...,T n, written as S :: e1 : T1 e2 : T2 M e n : T n. To define DET, we introduced the concept element: If S is a Cartesian product of types T 1,...,T n, element S = element T1 L element If S is not a Cartesian product type, element ( S ) = { S} If S is a Cartesian product type and S 0 is not, element S S element S element ( ) ( ) ( ) T n ( ) ( ) ( S ) 0 * = 0 Using the above notations, DET is defined as follows: for S DF Ζ, DET (3) ( ) ( S ) = element ( S ) U element ( T ) ( U RET ( S )) ( U = map S to T ) { }. 3) Find EI, EO, and EQ First, we introduce Input Data Set and Output Data Set to define the transaction function. for Signature F : X L Input Data Set : ids Output Data Set : 1 m 1 n, = element = element X Y L Y functions ( F ) ( X 1 ) L element ( X m ) ods functions ( F ) ( Y ) L element ( Y ) 1 n (4) (5) DF = ( S ) { m m ( T )( m = map S to T )}. (1) for mapping type M : map Input Data Set : ids Output Data Set : ods S to T types ( F ) = element ( S ) ( F ) = element ( T ) types, (6) 2) Measure DET and RET DET and RET show the complexity of a data function. So we need to assign them to each DF found in the first step. RET is defined as a user recognizable sub group of data elements. We define RET as follows: for S DF ( Ζ), RET S = U U types Ζ (2) ( ) { ( ) ( T )( U = map S to T )}. A DET is a unique user recognizable, non-recursive field which is dynamic. In VDM-SL specification, mapping types in data type definition could reveal the relation between DETs. Hereafter, for the sake of simplicity, ids or ods are used instead of ids types, ods types, ids functions, and ods functions. An EI is an elementary process that treats data or control information coming from outside the application boundary [4]. For example, functions such as adding, editing or deleting data in a file should be counted as EI. Performing this kind of functions requires data coming from outside the application boundary and certain file/database in the system would be changed by the function. In other words, after performing this kind of function, a new version of a certain file, which contains changed data, should be made. Thus, in the signature part of a

4 40 4 function definition in VDM-SL specification, if a mapping type is used for both parameters and return value, and the domain data type and range data type of that mapping type are included in the parameters, then that function should be distinguished as EI. We define EI as follows: EI = ( Ζ) { F F functions ( Ζ) ( S )( U RET ( S )) (( ids ( U ) ods ( U )) ids ( F ) φ DF ( S ) ids ( F ) ods ( F ) φ )}. An EO is an elementary process that generates data or control information that is sent outside the application boundary [4]. In VDM-SL, all data types except for basic data types should be defined in the data type definition block. Therefore, in the signature part of a function definition, if the data type used for the return value is not defined in the type definition block, then that function should be distinguished as EO. We define EO as follows: EO ( Ζ) = { F F functions ( Ζ) ods ( F ) Btypes φ}. (8) An EQ is an elementary process that retrieves data or control information and sends them outside the application boundary [4]. Unlike EO, EQ send data directly out without processing after the retrieval. There are three kinds of retrievals: searching with an identifier and retrieve one unique data; searching with certain conditions and retrieve one or more data; searching with no condition and retrieve all data. Therefore, in the signature part of a function definition in VDM-SL specification, if a mapping type is used for the parameters and the data type of the domain or range of that mapping type are included in the return value, then that function should be distinguished as EQ. We define EQ as follows: EQ ( Ζ) = { F F functions ( Ζ) ( S DF ( Ζ) )( U RET ( S ))( V ids ( U ) ods ( U )) ( U ids ( F ) ( V ods ( F ) set ( seq ) of V ods ( F )))}. 4) Decide ILF and EIF Each DF should be assigned with a type: ILF or EIF. Internal Logical Files (ILF) are maintained inside the application, while External Interface Files (EIF) are just referred to by the application [4]. We define ILF and EIF as follows: ILF ( Ζ) = { S S DF ( Ζ) ( F EI ( Ζ) )( RET ( S ) ids ( U ) ods ( U ) φ )}. (7) (9) (10) TABLE I. RESULT OF AUTOMATIC MEASUREMENT AND CONVENATIONAL MEASUREMENT RET Function Name Type DET or Simplicity FTR Book EIF 6 1 Simple Publisher EIF 5 1 Simple Member ILF 13 1 Simple Request ILF 20 2 (1) Average (Simple) Store EIF 4 1 Simple Status EIF 3 1 Simple Login Logout Not distinguished (EI) Not distinguished (EI) 3 (2) 1 2 (1) 0 EIF ( Ζ) = { S S DF ( Ζ) ( F function ( Ζ) )( RET ( S ) ids ( U ) φ ) ( F EI ( Ζ) )( RET ( S ) ids ( U ) ods ( U ) = φ )}. Not decided (Simple) Not decided (Simple) Displaying Personal EQ 10 1 Average Changing Password EI 4 1 Average Order EI/EQ (EI) 13 4 Complex Displaying Personal Order EO/EQ (EO) 14 4 Complex Displaying Personal Order (Detail) EQ 18 5 Complex Approving Order Progress EI/EQ (EI) 18 5 Complex Canceling Order EI/EQ (EI) 18 5 Complex Gift EI/EQ (EI) 17 5 Complex Displaying Gifts EQ 6 (7) 4 Complex Displaying Gift s (Detail) EQ 12 5 Complex Searching Member EQ 11 1 Simple Displaying Memger s Imformation EQ 12 1 Simple Registering Member EI 9 1 Simple Changing Member s EI 11 1 Simple Removing Member s EI 1 2 Simple Searching Orders EO/EQ (EO) 18 5 Complex Displaying Order s (Detail) EQ 23 5 Complex Changing Order s EI 6 1 Simple Removing Order s EI 1 1 Simple Introducing Books EQ (EO) 4 2 Simple *1 Results of the automatic measurement that differ from standard values are shown in italic font. *2 Standard values are written in parentheses. (11) 5) Measure DET and FTR EQ is an elementary process that retrieves data or control information and sends them outside the application boundary [4]. We define DET and FTR as follows:

5 40 5 DET FTR ( F ) = { T F functions ( Ζ) ( T Btypes ) ( T ( ids ( F ) ods ( F )) DET ( S ))}. ( F ) = { S F functions ( Ζ) ( U RET ( S ))( U ids ( F ))} (12) (13) 6) Set complexity of each function Once DET, RET and FTR are decided, the simplicity rating for each ILF, EIF, EI, EO and EQ can be calculated, and then FP of each function can be decided. 7) Sum all functions FP Finally, by summing all functions FP, and we will get UFP of the application. IV. AUTOMATIC MEASUREMENT TOOL AND CASE STUDY A. Automatic Measurement Tool Based on the method proposed in chapter III, we implemented an automatic measurement tool in Java. This tool can read and parse a given VDM-SL specification file and measure FP automatically from the specification. Fig.3 shows a screen shot of the tool. include the existing system) with both conventional method and our automatic measurement tool. First, VDM-SL specification was created from the design documents. Then, based on the VDM-SL specification, FP was measured automatically following the procedure explained in Chapter III. FP was also measured manually following the conventional method. Hereafter, results of the conventional measurement is referred as standard values. C. Result of the Case Study We compared the results of the automatic measurement tool with the standard values. TableI shows the result of the comparison. Numbers written in italic are automatic measurement results that differ from the standard values and numbers in parentheses are standard values. In tablei, data functions and transaction functions are separated by a solid line; transaction functions related to applications for costumers and bookstore staffs are separated by a dotted line. We examined carefully the differences between these results and found that all differences can be categorized into five types. 1) function which cannot be distinguished 2) different kind of function 3) less DET 4) more RET 5) functions which have two kinds 1) Function which cannot be distinguished The difference about Login and logout function (line 7,8 in table.i) is type 1. Since these functions change behavior of a system, they should be distinguished as EI. However, in our method, EI is distinguished by its functions related to the "maintenance of EIF", so login and logout function can not be distinguished correctly with our method. 2) Different kind of function The difference about Introducing Books function (line 28 in table.i) is type 2. This function was distinguished as an EQ through it should be an EO. Fig. 3. Automatic measurement tool B. Overview of the Case Study In order to examine the measurement method proposed, we applied our tool to measure the FP of a medium-scale sample project. A system integrator which cooperated with us offered design documents used in an online bookstore system development project. In this project, Web based systems were built and connected to the existing system which manages information about books and publishers. The Web based system allows registered customers to search and order books online. It also provides functions for bookstore staffs to manage order data and customer data. In our case study, we measured FP of the Web based system developed in this project (not 3) Less DET The difference about Login, logout and Displaying Gifts (line 18 in table.i) is type 3. Since login and logout are functions that can not be distinguished with our method, we will put our focus on finding the cause of the difference about Displaying Gifts in the analysis in next section. 4) More RET The difference about Request function (line 4 in table.i) is type 4. The difference between the automatically measured RET and the standard value is not so large. However, the RET influences greatly on the judgment of the simplicity of a data function. So the simplicity of this function is calculated as Average while the standard value is Simple. 5) Functions which have two kinds The difference about order, Displaying Personal Order,

6 40 6 Approving Order Progress, Canceling Order, Gift and Searing Order s function (line11, 12, 14-16, 24 in table.i) is type 5. These functions should be distinguished as EI or EO, but in the automatic measurement, they are distinguished also as EQ. D. Analysis of the Result There are three possible causes of the differences discussed in last section: (Cause for difference of type 1, 2 and 3) Our method referred to only signature of the function definition. (Cause for differences of type 4) The specification is written from the viewpoint of system developers instead of users. (Cause for differences of type 5)Human subjective decision is not reflected in the specification. It is clear that the first cause has the widest influence. In that sense, one important issue in our future work is to find a way to refer to supplementary information other than signature. The influence of the second cause can be reduced by describing from the user's viewpoint as much as possible when making the specification. However, if obsessed with the user's viewpoint too much, specification will become too complicated and that is to put the cart before the horse. As far as the FP is measured automatically from a formal specification, the last cause is unavoidable. In our case study, this drawback appeared in the result that two function types are measured. This problem should be solved by making supplemental subjective judgment to a certain kind of functions. Through the case study, the advantage of this measurement method also became clear. Firstly, we can measure FP without any document except for VDM-SL specification. In case of measuring FP from general system development documents, documents such as requirement definition, database table definition and screen item definition are needed. Secondly, metric related to complexity, especially RET and FTR, can be measured in our method. These metrics can not be measured clearly with automatic measurement tool in previous researches. V. CONCLUSIONS AND FUTURE WORKS In this paper, a method to measure FP from VDM-SL Specifications is proposed. The advantage of this method is its ability of measuring the degree of complexity of functions. In particular, the problem in measuring RET, which is left ambiguous in Diab el al. s research [12], is solved. In this method, RET can be measured without ambiguities by utilizing information included in data type definitions of VDM-SL specification. In addition, FTR, which is hard to measure from the specification document written in natural languages, can also be measured easily with the method. For future works, examination with practical VDM-SL specifications is needed. And the measurement method still needs to be improved. For example, not only signature but also other part of function definition should be referred to in order to obtain more precise result. Also, the target of measurement can be expanded. In addition, the user interface of the automatic measurement tool needs improvements to be put to practical use. REFERENCES [1] Albrecht, A., Measuring Application Development Productivity, Proc. Joint SHARE/GUIDE/IBM Application Development Symposium, pp , 1979 [2] International Function Point Users Group, [Online]. Available: [3] ISO Standard ISO/IEC 20926: 2003, [Online]. Available: csnumber=35582 [4] Kiminobu Kodama, "A Revised edition Practical Function Point Method," JMA Management Center Inc., 2006 [5] Nroman E. Fenton and Shari Lawrence Pfleeger, Software Metrics: A Rigorous & Practical Approach, 2 nd Edition, Course Technology, 1998 [6] David Longstreet, Function Point Training Manual, Longstreet Consulting Inc., [Online]. Available: [7] Keijiro Araki, Xiaojing Zhang, The Theory of Programming Specification, Ohmsha, 2002 [8] Fitzgerald & Larsen, Modeling Systems: Practical Tools and Techniques in Software Development, Cambridge Univ. Press, 1998 [9] VDM information web site, [Online] Available: [10] F. Gramantieri, E. Lamma, P. Mello, and F. Riguzzi, A system for measuring function points from specifications, Technical Report, DEIS-LIA , [11] M. Frappier, An Overview of Formal Specification Languages and their Adequacy for Formalizing the Definition of Function Points, Technical Report, Departement de mathematiques et d informatique, Universite de Sherbrooke, [12] H. Diab, M. Frappier, and R. St-Denis, A formal definition of function points for automated measurement of B specifications, Lecture notes in Computer Science, 2495/2002, pp , [13] J.R.Abrial, The B-Book: Assigning Programs to Meanings, Cambridge University Press, 1996 Tomoko Miyawaki is a Master Candidate at the Graduate School of Decision Science and Technology, Tokyo Institute of Technology. She received a Bachelor of Engineering degree in 2007 from the Department of Industrial Engineering and Management, Tokyo Institute of Technology, Tokyo, Japan. Her research interests include Formal Methods and Software Metrics. Junichi Iijima is a professor at the Graduate School of Decision Science and Technology, Tokyo Institute of Technology. He received a Doctor of Engineering degree in 1982 from the Interdisciplinary Graduate School of Science and Engineering, Tokyo Institute of Technology, Tokyo, Japan. His major interests are Systems Theory, Business Process Modeling, Systems Integration, IT Investment and Management and Data Mining. Sho Ho is an assistant professor at the Graduate School of Decision Science and Technology, Tokyo Institute of Technology. She received a Master of Engineering degree in 1999 from the Graduate School of Decision Science and Technology, Tokyo Institute of Technology, Tokyo, Japan. Her research interests include Component Technology, Web Engineering, and Business Process Modeling.