Towards an accurate functional size measurement procedure for conceptual models in an MDA environment

Data & Knowledge Engineering 69 (2010) 472–490

Contents lists available at ScienceDirect

Data & Knowledge Engineering

journal homepage: www.elsevier .com/ locate/datak

Towards an accurate functional size measurement procedurefor conceptual models in an MDA environment

Beatriz Marín a,*, Oscar Pastor a, Alain Abran b

a Centro de Investigación en Métodos de Producción de Software, Universidad Politécnica Valencia, Camino de Vera s/n, 46022 Valencia, Spainb Department of Software Engineering and Information Technology, École de technologie supérieure, Université du Québec, 1100 Notre-Dame Ouest,Montréal, Québec, Canada H3C 1K3

a r t i c l e i n f o

Article history:Received 13 October 2008Received in revised form 27 December 2009Accepted 5 January 2010Available online 21 January 2010

Keywords:Conceptual modelingObject orientationFunctional size measurementCOSMICMDA

0169-023X/$ - see front matter � 2010 Elsevier B.Vdoi:10.1016/j.datak.2010.01.001

* Corresponding author. Tel.: +34 96 387 73 50; fE-mail addresses: [email protected] (B. Marín

1 The functional user requirements are defined in thpractices and procedures that the software must per

a b s t r a c t

The accurate measurement of the functional size of applications that are automaticallygenerated in MDA environments is a challenge for the software development industry. Thispaper introduces the OO-Method COSMIC Function Points (OOmCFP) procedure, which hasbeen systematically designed to measure the functional size of object-oriented applica-tions generated from their conceptual models by means of model transformations. TheOOmCFP procedure is structured in three phases: a strategy phase, a mapping phase,and a measurement phase. Finally, a case study is presented to illustrate the use ofOOmCFP, as well as an analysis of the results obtained.

� 2010 Elsevier B.V. All rights reserved.

1. Introduction

The MDA [50,51] approach separates application and business logic from the platform technology, allowing code gener-ation by means of model transformations. In such MDA contexts, the software production processes are based on conceptualmodels that are used as inputs to the code generation process. These conceptual models must have the required semanticformalization to specify all the functionality of the generated application and to avoid different interpretations for the samemodel. The adoption of MDA-based technology has presented new challenges, such as the capability of measuring the size ofthe products generated in the early phases of the software development.

The Functional Size is defined as the size of the software that is derived by quantifying the functional user requirements1

[32]. The functional size measurement (FSM) was defined in the late 1970’s mainly through the Function Point Analysis (FPA)proposal [9]; later, FPA was adapted to object-oriented models aligned with the UML standard [41,61–63]. However, these FPA-based approaches present limitations for the measurement of the functional size of conceptual models in MDA environments.Even though we found approaches that measure the functional size in MDA environments in the literature [4,1], these ap-proaches are also FPA-based and have limitations, too. One such limitation is that FPA approaches only allow the measurementof the functionality that the human user sees, ignoring all the functionality that is needed for the correct operation of the appli-cation (which must be built by the developer, even though it is not seen by the human user). Another significant limitation isthat the size of any elementary process (an elementary unit of functional user requirements [32]) within a model is limited to

. All rights reserved.

ax: +34 96 387 73 59.), [email protected] (O. Pastor), [email protected] (A. Abran).

e ISO 14143-1 as a sub-set of the user requirements. The functional user requirements represent the userform to fulfil the users’ needs. They exclude Quality Requirements and any Technical Requirements.

http://dx.doi.org/10.1016/j.datak.2010.01.001

mailto:[email protected]



http://www.sciencedirect.com/science/journal/0169023X

http://www.elsevier.com/locate/datak

B. Marín et al. / Data & Knowledge Engineering 69 (2010) 472–490 473

only three intervals of classifications for DET (Data Element Types), RET (Record Element Types) or FTR (File Types Referenced).These intervals assign a specific functional size for the elementary process in the complexity tables of IFPUG FPA [27,28]. There-fore, the functional size of a model will not vary even if some elementary processes have a very large number of DET, RET or FTR[21,39,40].

To overcome the limitations of the initial design of the FPA measurement method, the COSMIC measurement method [7]was defined in the late 1990s as the second generation of the functional size measurement method. It has been adopted as aninternational standard: ISO 19761 [34]. One of the advantages of COSMIC over FPA is that it allows the measurement of thefunctional size from different points of view, for instance, the functionality that the users see and the functionality that thedeveloper has to build. Another advantage is that COSMIC uses a mathematical function that is not limited by maximumvalues to measure the size of conceptual models. This mathematical function aggregates the functional size of the functionalprocesses (an elementary unit of functional user requirements [5]) that are specified in the conceptual models. This helps tobetter distinguish the size of large conceptual models. Another advantage of COSMIC is that it allows the measurement ofapplications that are generated in layers, which permits the measurement of the whole application or the measurementof each layer of the application.

Currently, there are some approaches that apply COSMIC for the purpose of estimating the functional size of future soft-ware applications from high-level specifications [36,23]. As the functionality to be measured using these proposals is notsufficiently detailed to generate the final application automatically in MDA environments, some FSM procedures have beendesigned to measure the functional size of the application from its conceptual models, such as Diab’s proposal [16] and Poels’proposal [57]. Both FSM procedures were defined by establishing a mapping between the COSMIC concepts and the prim-itives of the Real-Time Object Oriented Modeling (ROOM) specification [59] or the primitives of the MERODE conceptualmodels [15], respectively. The Diab and Poels proposals are based on conceptual models that allow the generation of theapplications, but that do not allow the generation of fully working applications from these conceptual models. This generatesa traceability problem between the generated application and the conceptual model. Moreover, the conceptual models ofthese proposals do not have enough expressiveness for the total specification of the application in an abstract way. Therefore,these procedures do not allow the accurate2 [30] measure of the functional size of the applications generated from the con-ceptual models.

To avoid this problem, we have selected the OO-Method approach [54]. This approach is an object-oriented method thatis based on model transformations. It provides the semantic formalization needed to define complete and unambiguous con-ceptual models, allowing the automatic generation of software products using an MDA-based technology. Although presen-tation and interaction modeling is accepted to constitute an essential part of any software development method, it isremarkable that most of the current model-based approaches do not include an explicit presentation model. OO-Methoddoes this, and, consequently, a complete view of the software product to be built from the model is provided at the concep-tual level. This method has been implemented in a suite of industrial tools by the company CARE Technologies [13] (a soft-ware development company). Currently, CARE Technologies has a procedure to measure the functional size of conceptualmodels [4], but this procedure is limited to the IFPUG FPA with the limitations explained above.

In general, the Functional Size of applications is used to successfully apply prediction models [4,63], such as effort andbudget models. In an MDA context, the effort of programming the applications is substituted by a modeling effort. Thus,in this context, dealing with the cost of the applications should mean dealing with how to measure cost from the involvedmodels. Therefore, it is very important to know the accurate functional size of the conceptual models that are built withthese MDA-based approaches since this functional size is necessary to adjust the budget in order to estimate the cost ofthe software product that is generated automatically.

In addition, since the functional size measurement is independent of the technological platform, it allows the generationof indicators in early stages of the software development cycle. Thus, knowing the accurate functional size of software fromthe conceptual models is critical for evaluating risks and for obtaining early project indicators (such as productivity). More-over, given that a functional size measurement procedure analyzes all the elements of the conceptual model that fulfil thefunctional user requirements, the measurement procedure can be used as a very valuable tool to identify defects in the con-ceptual models.

The contribution of this work is the systematic design and application of an FSM procedure that measures the accuratesize of the generated applications from their conceptual models. Thus, this paper presents the OOmCFP proposal, which is aprocedure based on COSMIC to measure the functional size of the OO-Method applications from their conceptual models.The holistic view of the OO-Method conceptual model (including the structure of the system, the behavior, the interactionbetween the users and the system, and the interaction among the components of the system) allows OOmCFP to take intoaccount all the functionality of the generated applications, including the functionality related to the presentation featuresthat other measurement procedures do not consider. Therefore, we infer that OOmCFP contributes substantially to improv-ing the measurement of applications generated from conceptual models.

The rest of the paper is organized as follows: Section 2 presents the main concepts of the COSMIC measurement method,the related work, the OO-Method approach, and a process model for software measurement. Section 3 presents the design of

2 The accuracy of measurement is defined in the International Vocabulary of Basic and General Terms in Metrology (VIM) as closeness of agreement betweena quantity value obtained by measurement and the true value of the measurand.

474 B. Marín et al. / Data & Knowledge Engineering 69 (2010) 472–490

the OOmCFP procedure, and Section 4 presents the application of OOmCFP. Finally, Section 5 presents an analysis on the re-sults achieved, and Section 6 presents some conclusions and suggestions for further work.

2. Background and related work

Since the objective of this paper is to present a measurement procedure based on the COSMIC measurement method, inthe following sub-sections, we present the COSMIC measurement method, the related work, a brief explanation of the OO-Method approach, and a process model for software measurement.

2.1. The COSMIC measurement method

In 1997, St-Pierre et al. [60] defined the Full Function Points (FFP) method for the measurement of control systems, real-time systems, and embedded systems. This measurement procedure obtains the functional size of an application by means ofthe identification of functional processes and data movements that occur in these processes. The data movements are: Entryto the functional process, Exit from the functional process, Read the database, and Write the database. When all the datamovements have been identified, they are aggregated to obtain the functional size of each functional process.

Later, in 1999 the Common Software Measurement International Consortium (COSMIC) published the 2.0 version of theCOSMIC-FFP measurement method [6]. Since some modifications were performed to the 2.0 version of COSMIC-FFP, the 2.1version was published in 2001 [7] and the 2.2 version was published in 2003 [8]. This version was recognized as the ISO/IEC19761 standard [34]. In 2007, a new version of COSMIC was published [5]. This last version aggregates a phase for the def-inition of the measurement strategy. Thus, the application of the last version of the COSMIC measurement method [5] in-cludes three phases: the strategy phase, the mapping phase, and the measurement phase (see Fig. 1).

In the strategy phase, the purpose of the measurement exercise must be defined to explain why it is necessary to measureand what the measurement result will be used for. Next, the scope of the measurement must be defined in order to select theset of user functional requirements that will be included in the measurement task. Then, the functional users of the appli-cation to be measured must be identified. The functional users are the types of users that send (or receive) data to (from) thefunctional processes of a piece of software. This phase also includes the identification of the boundary, which is a conceptualinterface between the functional user and the piece of software that will be measured. Finally, the level of granularity of thedescription of a piece of software to be measured is identified.

In the mapping phase, the functional processes must be identified (i.e., the elementary components of a set of functionaluser requirements). Every functional process is triggered by a data movement from the functional user, and the functionalprocess is completed when it has executed all the data movements required for the triggering event. It should be kept in

Fig. 1. Phases and activities in the COSMIC measurement method version 3.0.


mind that a triggering event is an event that causes a functional user of the piece of software to initiate one or more func-tional processes. Next, the data groups must be identified. This is a set of data attributes that are distinct, non-empty, non-ordered, non-redundant, and that participate in a functional process. Finally, the identification of the data attributes, whichcomprise the smallest part of information of a data group, is optional.

In the measurement phase, the data movements (Entry, Exit, Read and Write) for every functional process must be iden-tified. When all the data movements of the functional process are identified, the measurement function for the functionalprocess must be applied. This is a mathematical function that assigns 1 CFP (COSMIC Function Point) to each data movementof the functional process. Then, after all the functional processes are measured, the measurement results are aggregated toobtain the functional size of the piece of software that has been measured.

2.2. Related work

Many functional size measurement procedures have been developed for applying the COSMIC measurement method toparticular methods of software production.

The proposals of Bévo et al. [12], Jenner [36], Azzouz and Abran [10], Habela et al. [24], and Levesque et al. [42] allow themeasurement of the functional size of Management Information Systems (MIS) using UML models. As is well known, theUML models do not allow the specification of all the functionality of the final application and can also have consistencyand ambiguity problems [11,19,53].

The proposals of Condori-Fernández et al. [14] and Grau and Franch [23] allow the measurement of the functional size ofMIS using requirements models. Both proposals have been defined systematically. However, the requirements models do nothave enough expressiveness to specify all the functionality of the final application.

The proposals of Diab et al. [16] and Nagano and Ajisaka [48] allow the measurement of the functional size of real-timeapplications. Diab’s proposal measures the functional size of ROOM specifications that are used by the Rational Rose RealTime (RRRT) tool for the design and specification of real-time systems. In Nagano’s proposal, the measurement of the func-tional size is performed in real-time applications that are specified using xUML [45]. These proposals do not allow the spec-ification of the presentation of the applications in an abstract way, so the functional size obtained does not accuratelyrepresent the functional size of the final applications. In addition, both proposals are defined for the real-time systems do-main, which is a different domain application with respect to the MIS domain on which we focus.

The proposal of Poels [57,58] allows the measurement of the functional size of MIS that has been specified using MERODEconceptual models. This proposal does not use conceptual models with enough expressiveness to specify all the functionalityof the final application in the conceptual model since the MERODE models do not allow the specification of the presentationof the final application at a conceptual level [46]. In addition, the applications generated from MERODE models are restrictedto a specific platform technology because MERODE uses the AndroMDA tool to specify the presentation of the applicationand to generate the final application in Java code. Therefore, the functional size obtained by the Poels proposal does not rep-resent the accurate functional size of the generated applications.

In summary, none of the proposals for measurement procedures based on COSMIC allows the accurate measurement ofthe functional size of MIS applications in the conceptual model. Moreover, none of them take into account the newer version3.0 of COSMIC [5]. The main limitation of the approaches presented above comes from the lack of expressiveness of the con-ceptual model. For this reason, we have selected the OO-Method approach, which is presented in the following section.

2.3. The OO-Method approach: a development method

OO-Method is an object-oriented method that allows the automatic generation of software from conceptual models. Todo that, the OO-Method approach uses a graphical language based on UML and a formal language named OASIS [55]. Thismethod is supported by the compiler of OO-Method conceptual models, which is implemented in the OlivaNova Suite [13].

The OO-Method model compiler generates applications according to a three-tier software architecture: one tier for theclient component, which contains the graphical interface; one tier for the server component, which contains the businessrules and the connections to the database; and one tier for the database component, which contains the persistence aspectsof the applications.

The software production process in OO-Method is represented by three models:

� The Requirements Model [17,29], which specifies the system requirements using a set of techniques such as the MissionStatement, the Functions Refinement Tree, the Use Case Model, and the Sequence Diagram Model.

� The Conceptual Model, which captures the static and dynamic properties of the functional requirements of the system bymeans of an Object Model, a Dynamic Model, and a Functional Model. The conceptual model also allows the specificationof the user interfaces in an abstract way through the Presentation Model. With all of these models, the conceptual modelhas all the details needed for the generation of software applications that correspond to the OO-Method domain (MISapplications). The complete definition of the elements of the conceptual model of OO-Method is described in detail in [56].

� The Execution Model [22], which allows the transition from the problem space (represented by the conceptual model) tothe solution space (the corresponding software product). This model fixes the mappings between conceptual primitivesand their corresponding software representations in a target software development environment.


The standard IEEE 830 [26] describes a set of characteristics that must be taken into account for a good specification of thesoftware (i.e., unambiguous, complete, verifiable, consistent, modifiable, traceable, and usable during the development andmaintenance phase). Given that the OO-Method conceptual model allows the generation of fully working applicationsthrough model transformations of a MDA-based technology, we can infer that the OO-Method conceptual model is a goodspecification for the OO-Method applications because it achieves the characteristics of the standard IEEE 830. For example,the generated application is traceable from the conceptual model; the conceptual model is consistent because the same cri-teria are always used to generate the applications from the OO-Method conceptual model; the conceptual model is notambiguous because the OO-Method conceptual model has a formal language for the specification of the constraints of thesystem; and the conceptual model is editable because it is supported by a tool that permits changes in the model. Thus, sincethe OO-Method conceptual model is a good specification for the OO-Method applications according to the standard IEEE 830,it facilitates: the measurement of functional size in early stages of the software development; the accuracy of the measure-ment results; the re-generation of the application; and the automated re-measurement of the functional size when a mea-surement feature is available.

In this work, we need only focus on the Conceptual Model, which has the artifacts that are required to measure the func-tional size through the corresponding measurement process. For a better understanding of the OOmCFP measurement pro-cedure, the models that compose the OO-Method Conceptual Model are briefly described.

2.3.1. The OO-Method object modelThis model describes the static part of the system. The object model allows the specification of classes, attributes, derived

attributes, events, transactions, operations, preconditions, integrity constraints, agents, and relationships between classes.The main concepts of the object model are well known because they are the same as those used in the UML class diagram[52]. However, these concepts are briefly explained in the following paragraphs.

The main conceptual primitive of the object model is the class. A class describes a set of objects that share thesame specifications of characteristics, constraints, and semantics. A class can have attributes, services, integrity con-straints and relationships with other classes. The attributes of a class represents characteristics of this class. The attri-butes of a class can also be derived attributes, which obtain their value from the values of other attributes orconstants. The integrity constraints are expressions of a semantic condition that must be preserved in every valid stateof an object.

The services of a class are basic components that are associated with the specification of the behavior of a class. The ser-vices can be events, transactions or operations. The events are indivisible atomic services, which can assign a value to anattribute. The transactions are a sequence of events or other transactions that have two ways to end the execution: eitherall involved services are correctly executed, or none of the services are executed. Finally, the operations are a sequence ofevents, transitions or other operations, which are executed sequentially independently of whether or not the involved ser-vices have been executed correctly. The services can have preconditions that limit their execution because the preconditionsare conditions that must be true for the execution of a service.

The agents are active classes that can access specific attributes of the classes of the model and can execute specific ser-vices of the classes of the model. Finally, the relationships between classes can be the following: agent (that represent whichobject can activate which services); association; aggregation; composition; and specialization.

2.3.2. The OO-Method dynamic modelThe OO-Method dynamic model is comprised of two diagrams: the state transition diagram and the object interaction

diagram. The state transition diagram defines the valid lives of the objects that belong to a class. This diagram has the fol-lowing conceptual constructs: initial state, final state, intermediate states, and transitions. Most of the concepts of this dia-gram are the same as those used in the UML state transition diagram [52]. Nevertheless, these concepts are briefly explainedin the following paragraph.

The initial state represents the state that objects are in immediately before they are created. The final state represents thestate that objects are in immediately after they are destroyed. And, the intermediate states represent different situations thatan object of a class may find itself in at any point during its life. The intermediate states have incoming and outgoing tran-sitions, which represent a change of the state of an object. The transitions are activated by an agent that executes a serviceand can also have a condition to execute the service when it is required.

The object interaction diagram defines the interactions among the objects of the system. To do this, the triggers ofthe classes of the system and the global transactions or operations of the system are defined. The triggers are definedin a specific class. Each trigger is composed by a trigger condition and a service to be executed after a successful exe-cution of a service that activates the trigger. The triggers can be executed for: (1) the same object that has been usedto activate the trigger, (2) a particular object of the class, (3) several objects of the class, or (4) all the objects of theclass. Each trigger service is executed in the background and is hidden from the user, who does not know the result ofthe execution (either success or failure).

The global transactions and operations are sequences of services, like the transactions and operations of the object model.The global services can involve services of any class of the system. Usually, these services are defined when it is necessary toexecute services of objects that are not related.


2.3.3. The OO-Method functional modelThe functional model of the OO-Method approach allows the specification of the effects that the execution of an event has

over the value of the attributes of the class that owns the event. The functional model uses valuations to assign values to thecorresponding attributes. The valuations can have preconditions. These preconditions and the effect of the valuation must bespecified by means of well-formed, first-order logic formulas that are defined using the OASIS language.

The change that a valuation produces in the value of an attribute is classified into three different categories: state, car-dinal, and situation. The state category implies that the change of the value of an attribute depends only on the effect spec-ified in the valuation for the event, and it does not depend on the value in the previous state. The cardinal category increases,decreases, or initializes the numeric-type attributes. The situation category implies that the valuation effect is applied only ifthe value of the attribute is equal to a predefined value specified as the current value of the attribute.

2.3.4. The OO-Method presentation modelIn order to specify the interaction between the users of an application and the system, the OO-Method approach allows

the specification of views in the object model. A view corresponds to a set of interfaces, which are the communication pointbetween agents and classes of the OO-Method object model. When the views of a system have been defined, the presentationmodel of each view must be specified.

The presentation model allows the specification of the graphical user interface of an application in an abstract way [47].To do this, the presentation model has a set of abstract presentation patterns that are organized hierarchically in three levels:access structure, interaction units, and auxiliary patterns. The first level allows the specification of the system access struc-ture. In this level, the set of entry options that each user of the application will have available is specified by means of a hier-archy action tree (HAT).

Based on the menu-like view provided by the first level, the second level allows the specification of the interaction unitsof the system. The interaction units are groups of functionality that allow the users of the application to interact with thesystem. Thus, the interaction units of the presentation model represent entry-points for the application, and they can be:

� A Service Interaction Unit (SIU). This interaction unit represents the interaction between a user of the application and theexecution of a system service. In other words, the SIUs do the following: allow the users of the application to enter thevalues for the arguments of a service; execute the service; and offer to the users the feedback of the results of the execu-tion of the service.

� A Population Interaction Unit (PIU). This interaction unit represents the interaction with the system that deals with thepresentation of a set of instances of a class. In a PIU, an instance can be selected, and the corresponding set of actionsand/or navigations for the selected instance are offered to the user.

� An Instance Interaction Unit (IIU). This interaction unit represents the interaction with an object of the system. In an IIU, aswell as in a PIU, the corresponding set of actions and/or navigations for the instance are offered to the user.

� A Master Detail Interaction Unit (MDIU). This interaction unit represents the interaction with the system through a com-posite interaction unit. A MDIU corresponds to the joining of a master interaction unit (which can be an IIU or a PIU) and adetail interaction unit (which can be a set of IIUs or PIUs).

The third level of the presentation model allows the specification of the auxiliary patterns that characterize lower leveldetails about the behavior of the interaction units. Each auxiliary pattern has its own scope that states the context in which itcan be applied. These auxiliary patterns are:

� The entry pattern, which is used to indicate that the user can enter values for the arguments of the SIUs.� The defined selection pattern, which is used to specify a list of specific values to be selected by the user.� The arguments grouping pattern, which is used to group a set of arguments of the SIUs in order to facilitate the user inter-

action with the system.� The arguments dependency pattern, which is used to define dependencies among the values of the arguments of a service.

To do this, Event-Condition-Action (ECA) rules are defined for each argument of the service. The ECA rules have the fol-lowing semantics: when an interface event occurs in an argument of a service (i.e., the user enters a value), an action isperformed if a given condition is satisfied. .

� The arguments preload pattern, which is used to define a set of objects that can be selected as arguments of a SIU.� The introduction pattern, which is used to define masks for the introduction of values by the user.� The filter pattern, which allows a restricted search of objects for a Population Interaction Unit. A filter can have data-val-

ued variables and object-valued variables. These variables can have a defined default value, a related PIU to select thevalue of the object-valued variables, and pre-charge capabilities for the values of the object-valued arguments.

� The order criteria pattern, which allows the objects of a PIU to be ordered. This pattern consists of the ascendant/descen-dant order over the values of the attributes of the objects presented in the PIU.

� The display set pattern, which is used to specify which attributes of a class or its related classes will be shown to the userin a PIU or an IIU.

� The navigation pattern, which allows the navigation from an interaction unit to another interaction unit.


� The action pattern, which allows the execution of services by joining and activating the corresponding SIUs by means ofactions.

� The navigational filtering pattern, which allows the navigation to related objects to be restricted using a filter condition.� The initialization of arguments pattern, which allows the argument of a SIU to be initialized when it is accessed directly

from another SIU.� The conditional navigation pattern, which allows the navigation from a SIU to other interaction units, depending on the

execution result (success or failure) of the SIU.

2.4. A software measurement process model

The process model for software measurement proposed by Jacquet and Abran [35] has been used in the development ofother functional size measurement procedures, such as [4,1,14,23]. This process model is comprised of four steps: design of ameasurement method, application of the measurement method rules, measurement results analysis, and exploitation of themeasurement results.

In the first step, the concept to be measured and the rules to measure this concept must been defined. This step is dividedinto four sub-steps to complete the design of the measurement method: definition of the objectives, characterization of theconcept to be measured, selection of the metamodel, and definition of the numerical assignment rules.

In the second step, the designed measurement method must be applied to the software or a piece of the software. Thisstep is divided into three sub-steps: software documentation gathering, construction of the software model, and assignmentof the numerical rules.

In the third step, the measurement result obtained in the second step must be documented and audited. This step is di-vided into two sub-steps: presentation of the measurement results and the audit of the results. In the fourth step, the resultsobtained from the application of the method are used in different ways, for instance in quality models, in estimation pro-cesses, in productivity models, etc.

3. Design of a measurement procedure

In this section, we explain every sub-step of the design of the OO-Method COSMIC Function Points (OOmCFP) measurementprocedure using Jacquet’s software measurement process model explained above.

3.1. Definition of the objectives

The objective is to design a procedure for measuring the accurate functional size of software applications that are gen-erated using a MDA-based approach from object-oriented conceptual models developed with OO-Method. This measure-ment procedure must be defined in accordance with the COSMIC functional size measurement method.

3.2. Characterization of the concept to be measured

The input artifacts used to measure the functional size of the OO-Method applications are the conceptual modelsthat are used to generate these applications. Therefore, the entity to be measured by the OOmCFP measurement pro-cedure will be an OO-Method conceptual model, and the attribute to be measured will be the functional size, which isdefined by the ISO/IEC 14143-1 standard [32] as the size of software derived by quantifying the functional userrequirements. These functional user requirements represent a sub-set of the user requirements that specifies whatmust be done by an application, excluding its technological features and non-functional characteristics (i.e., perfor-mance, security, etc.).

3.3. Selection of the metamodel

A metamodel is a structural definition of the model elements with their properties, and their relationships witheach other. A metamodel for an FSM provides the basis for the design of the measurement rules that identify andmeasure the elements contained in the metamodel. Fig. 2 shows the COSMIC metamodel, which illustrates the infor-mation that should be represented by the software artifact to be measured. This metamodel was designed from theCOSMIC measurement manual version 3.0 [5]. We selected this metamodel for the design of OOmCFP because ofthe simplicity of the metamodel in quantifying functional size without being limited by maximum values (as occursin IFPUG FPA).

As Fig. 2 shows, the scope of the measurement is determined by the purpose of the measurement. The purpose and thescope define the set of pieces of the software that will be measured and the level of detail of each piece of software (gran-ularity level). Each measurand is focused on a set of objects of interest that can be either physical or conceptual and that arerelated to data groups. Every data group has a set of attributes. Also, every data group participates in one or more data move-ments, which can be an entry data movement (E), an exit data movement (X), a read data movement (R), or a write datamovement (W). Two or more data movements occur in a functional process that belongs to a piece of software of the layer

Fig. 2. Metamodel of COSMIC.


to be measured. Each layer of the piece of software is associated to one operative software environment. Finally, every func-tional process is triggered by triggering events carried out by the functional user. The functional users are the users3 [32] of thepieces of software that have been measured and are separated by a boundary from the pieces of software. For a measurement ofa multilayer application, the functionality that must be built by the developer is very important because it allows the size of theapplication to be accurately determined.

The OOmCFP measurement procedure has been developed in accordance with the COSMIC measurement method [5]. Forthis reason, the OOmCFP procedure is structured using three phases: the strategy phase, the mapping phase, and the mea-surement phase. The strategy phase addresses the four key parameters of software functional size measurement that mustbe considered before actually starting to measure, namely the purpose of the measurement, the scope of the measurement,the identification of functional users, and the level of granularity that should be measured. Determining these parametershelps to address the questions of ‘Which size should be measured?’ or, for an existing measurement, ‘How should we inter-pret this measurement?’ The mapping phase presents the rules to identify the functional processes, data groups, and dataattributes in the software specification (i.e., in the conceptual model) depending on the parameters defined in the strategyphase. The measurement phase presents the rules to identify and measure the data movements that occur between the func-tional users and the functional processes. The boundary between the COSMIC phases is determined by the purpose that eachphase has. Since we also follow the process model defined by Jacquet and Abran [35] to develop the OOmCFP procedure, wehave determined that there is no direct correlation between the activities defined in the process model and the phases of theCOSMIC measurement method. For this reason, we present the strategy phase and the mapping phase in the selection of themetamodel activity. We separate the measurement phase into two parts: the identification of the data movements that ispresented as part of the mapping phase in the selection of the metamodel activity and the rest of the measurement phasethat is presented in the definition of the numerical assignment rules activity.

3.3.1. The strategy phaseThe strategy phase is a relevant phase in the measurement procedure. In this phase, the purpose, the scope, and the level

of granularity must be determined. The functional users and the boundaries must also be identified in this phase.The purpose of the measurement in OOmCFP (which determines why the measurement is necessary and what the mea-

surement result will be used for) is defined as measuring the accurate functional size of the OO-Method applications gen-erated in an MDA environment from the involved conceptual models. As in the specific case of CARE Technologies

3 The user is defined in the ISO 14143-1 as any person that specifies Functional User Requirements and/or any person or thing that communicates or interactswith the software at any time. Also, the ISO 14143-1 clarifies that thing includes software applications, animals, sensors, other hardware, etc.

Fig. 3. Functional users, pieces of software, and layers of an OO-Method application.


company [13], this functional size will be used to estimate the cost of the OO-Method applications that are specifically gen-erated by the OlivaNova Suite. Although the code of the OO-Method applications is generated automatically, it is importantto note that the effort of programming is substituted by a modeling effort. Thus, for the applications generated in an MDAenvironment, dealing with the cost means dealing with how to measure cost from the involved models. With the OOmCFPmeasurement procedure, companies can use the functional size measured from the models to adjust the budget in order toprorate the cost of the software product development. CARE Technologies, which has implemented the tools that support theOO-Method approach, based its business model on functional size to calculate the cost of the generated applications, pro-rating the cost of the development and improvement of the tools between the generated applications.

The scope of the measurement defines a set of functional user requirements that will be included in a measurement exer-cise. As stated in Section 3.1, the OOmCFP uses the OO-Method conceptual model as the input artifact for the measurementof the functional size of applications generated in MDA environments. This conceptual model formally and unambiguouslyspecifies the functional requirements of the applications independently of the technological characteristics that the gener-ated applications will have. The applications generated using the OO-Method approach have a direct correspondence withthe involved conceptual model. Thus, these applications do not need manual changes for their correct operation becausetheir complete specification is performed at an abstract level in the conceptual model. For this reason, the scope of the mea-surement in OOmCFP is the OO-Method conceptual model, which is comprised of four models (Object, Dynamic, Functional,and Presentation), which allow a fully working software application to be generated.

Once the scope of the measurement has been determined, it is important to identify the layers, the pieces of software, andthe peer components that make up the applications. In order to correctly identify the architecture of the applications, wehave used the definitions of layer,4 piece of software,5 and peer component6 presented in the COSMIC Measurement Manual[5]. Since the OO-Method software applications are generated according to a three-tier software architecture, we distinguishthree layers: a client layer, which contains the graphical user interface; a server layer, which contains the business logic ofthe application; and a database layer, which contains the persistence of the applications. In each layer of an OO-Method appli-cation, there is a piece of software that can interchange data with the pieces of software of the other layers. Thus, we distinguish,respectively, three pieces of software in an OO-Method application: the client piece of software, the server piece of software,and the database piece of software. Fig. 3 illustrates the pieces of software and layers of an OO-Method application.

The granularity level is the level of detail that the pieces of software included in the measurement must have. Since themeasurement will be performed in conceptual models that must be valid to generate the final applications in an MDA envi-ronment, the granularity level is a low level because all the details in the OO-Method conceptual model are needed to auto-matically generate the applications.

4 A layer is a partition resulting from the functional division of a software architecture that together with hardware forms a whole computer system, where:layers are organized in a hierarchy; there is only one layer at each level in the hierarchy; there is a ‘superior/subordinate’ hierarchical dependency between thefunctional services provided by the software of the layers; and the software of a layer that interchanges data with other layers interprets only the part of thedata that interchanged.

5 A piece of software is the part of the software that is implemented in each layer.6 When two or more parts of the software are implemented in the same layer and collaborate to respond to a functional user requirement, these pieces of

software are considered as peer components.


Since the functional users are the types of users that send (or receive) data to (from) the functional processes of a piece ofsoftware, in the OO-Method applications, it is possible to identify the users and the pieces of software of an application asfunctional users. Therefore, functional users of the OO-Method applications are the human users, the client component of thesoftware, the server component of the software, and the legacy views (see Fig. 3).

The users of the OO-Method applications are represented in the conceptual model as agent classes of the object model(see the definition of agents in Section 2.3). These users are generally human users that send or receive data to the clientlayer of the software. From now on, we refer to this type of users as the ‘human functional user’. This user is a functionaluser of the client layer of the software and is separated by a boundary from the client layer of the software.

The client component of the software is a functional user that sends and receives data to (from) the server piece of soft-ware. We refer to this type of user as the ‘client functional user’. This user is a functional user of the server layer of the soft-ware and is separated by a boundary from the server layer of the software.

The server component of the software sends and receives data to (from) the client layer of the software and the databaselayer of the software. We refer to this type of user as the ‘server functional user’. This user is a functional user for both layersof the software: the client layer and the database layer. The server functional user is separated by a boundary from the clientlayer of the software, and by a boundary from the database layer of the software.

The OO-Method conceptual model allows the definition of legacy views (which are classes implemented in other systems)as well as the definition of their relationships with the classes of the system. These legacy views represent functional users ofthe OO-Method applications and are separated by a boundary from the server layer of the software. We refer to this type ofuser as the ‘legacy functional user’.

3.3.2. The mapping phaseSince our objective is to measure the OO-Method conceptual model, a mapping between the concepts used in COSMIC

and the concepts used in the OO-Method conceptual model for measuring the functional size must be defined. This is prob-ably the most important contribution presented in this work: how to relate COSMIC primitives with OO-Method conceptualmodeling constructs.

In general terms, a functional process corresponds to a set of Functional User Requirements comprising a unique, cohesive,and independently executable set of data movements. A functional process starts with an entry data movement carried outby a functional user given that an event (triggering event) has happened. A functional process ends when all the data move-ments needed to generate the answer to this event have been executed.

In the context of OOmCFP, the ‘human functional user’ carries out the triggering events that occur in the real world. Thisfunctional user starts the functional processes that occur in the client layer of the application. In this layer, the functional pro-cesses are represented by the interaction units of the OO-Method presentation model that can be directly accessed by the‘human functional user’. These interaction units correspond to the direct successors of the hierarchy action tree (HAT) ofthe presentation model of the OO-Method conceptual model. Therefore, every child of the HAT will be one functional pro-cess, representing either a selection of a given class population (a Population Interaction Unit (PIU)), an execution of a service(a Service Interaction Unit (SIU)), or more complex interaction units (such as a Master Detail Interaction Unit (MDIU)). Nev-ertheless, in addition to the interaction units, it is important to identify the elements that compose the interaction unit, sincethey are also relevant to the measurement of the functional size. Table 1 shows the elements that can be contained in theseinteraction units. More details of the OO-Method presentation model can be found in Section 2.3.

The ‘client functional user’ activates triggering events that occur in the interaction units of the presentation model of theOO-Method conceptual model. The ‘client functional user’ starts functional processes, which are the actions that carry out theserver layer of the software in response to the triggering events that occur in the client layer of the software. To identify theelements that are contained in the functional processes of the server layer, it is necessary to identify the actions that thislayer can perform in response to the triggering events carried out by the interactions units of the client layer. These trigger-ing events are the following:

� The Instance Interaction Units (IIU) require from the server layer the values of the attributes that compose a display set,the execution of a service, or the default values of the arguments of a service.

� The Population Interaction Units (PIU) require from the server layer the values of the attributes that compose a display set,the values of the filter variables that have a defined default value, the execution of a service, or the default values of thearguments of a service.

� The Master Detail Interaction Units (MDIU) are comprised of combinations of IIUs or PIUs. Therefore, they require from theserver layer the information that the IIUs or the PIUs require.

Table 1Presentation elements contained in the interaction units.

Interaction unit Contained elements

Population Interaction Unit (PIU) Display set, filter, order criteria, action, navigationService Interaction Unit (SIU) Arguments, conditional navigationMaster Detail Interaction Unit (MDIU) Master, detail

Fig. 4. Data movements between the users and layers of an OO-Method application.


� The Service Interaction Units (SIU) require from the server layer the default values of the arguments of a service, the valuesof the derived attributes used in a service, and the initialization of arguments. SIUs also require from the server layer theexecution of the following: services associated to the interaction units, dependency rules of the arguments, valuations,conditional navigation for the success or failure cases of the execution of the service, navigational filtering, validationof the preconditions of the service, check of the integrity constraints, triggers activated by the service, or the change ofstate of an object by means of the transitions of a service.

The ‘server functional user’ carries out the triggering events that occur in the server layer of the software. The ‘server func-tional user’ starts functional processes, which are the actions that the database layer carries out in response to the triggeringevents of the server layer, and the actions that the client layer carries out in response to triggering events of the server layerof the software. For the database layer, the ‘server functional user’ starts functional processes that add, edit, and delete thepersistent information of the system. On the other hand, the ‘server functional user’ starts functional processes in the clientlayer that deliver information, for instance, by means of the display set or the error messages.

The ‘legacy functional user’ activates triggering events that occur in the legacy system. The ‘legacy functional user’ startsfunctional processes, which are the actions that the server layer of the software carries out to interact with the legacy system.

The data groups correspond to a set of different attributes that describe an object of interest. The object of interest cor-responds to physical objects, conceptual objects, or even parts of conceptual objects. Taking into account that the OOmCFPuses the OO-Method conceptual model to measure the functional size, the data groups are the classes of the object model ofthe OO-Method conceptual model that participate in a functional process. Of course, identified data groups always corre-spond to a conceptual object of interest. Nevertheless, when a class is part of an inheritance hierarchy, the father class cor-responds to a data group, and when the child class has different attributes than the father, it will correspond to another datagroup.

The data attributes correspond to the smallest pieces of information of a data group. In the context of OOmCFP, the dataattributes of a data group correspond to the attributes of the classes that have been identified as a data group.

With regard to the identification of data movements, every functional process has a set of data movements that can be en-try data movements (E), exit data movements (X), read data movements (R) or write data movements (W). Each single datamovement must move a single data group. Fig. 4 shows the data movements that could occur in the OO-Method applications.All the mapping rules for the data movements are structured with a concept of the COSMIC measurement method, a conceptof the OO-Method approach, and the cardinalities that associate these concepts. In summary, we have defined 65 mappingrules for the data movements that can be visualized in the measurement guide of OOmCFP.7 These mapping rules detect thedata movements of all the functionality needed for the correct operation of the generated application, which is built by themodel compiler of the MDA environment.

7 http://oomethod.dsic.upv.es/labs/images/OOmCFP/guide.pdf.

http://oomethod.dsic.upv.es/labs/images/OOmCFP/guide.pdf


An entry data movement is a movement that moves one data group from a functional user across the boundary into thefunctional process where it is required. In the OOmCFP measurement procedure, we have determined 27 mapping rules: fourare for entry data movements that take place between the human functional user and the functional processes that occur inthe client layer; five are for entry data movements that take place between the server functional user and the functional pro-cesses that occur in the client layer; four are for entry data movements that take place between the client functional user andthe functional processes that occur in the server layer; and 14 are for entry data movements that take place between thelegacy functional user and the functional processes that occur in the server layer. For instance, the following mapping rulewas defined to detect the data movement that occurs when the functional user enters a value for an object-valued variable ofa filter of a PIU:

� Mapping Rule 2: 1 entry data movement for each different object-valued variable that is associated to a filter of a PIU thatparticipates in a functional process.

An exit data movement is a movement that moves a data group from a functional process across the boundary to the func-tional user that requires it. Thus, we have determined 15 mapping rules for the exit data movements: five are for exit datamovements that take place from the functional processes that occur in the client layer to the human functional user; four arefor exit data movements that take place from the functional processes that occur in the client layer to the server functionaluser; five are for exit data movements that take place from the functional processes that occur in the server layer to the clientfunctional user; and one is for exit data movements that take place from the functional processes that occur in the serverlayer to the legacy functional user. For instance, the following mapping rule was defined to detect the data movement thatoccurs when the PIU of the client layer that contains a filter with object-valued variables exits the value of the object-valuedvariables to the server functional user:

� Mapping Rule 16: 1 exit data movement for each different object-valued variable that is associated to a filter of a PIU thatparticipates in a functional process.

A read data movement is a movement that moves a data group from the persistence storage that is in contact with thefunctional process that requires it. For the OO-Method applications, only the server layer of the software can read the per-sistence storage. Therefore, we defined 20 mapping rules for read data movements that take place from the functional pro-cesses that occur in the server layer of the software to the database layer of the software. For instance, the following mappingrule was defined to detect the data movements that occur when the filter formula uses values, such as attributes of the classthat contains the filter, which must be recovered from the database:

� Mapping Rule 33: 1 read data movement for each different class that is used in the filter formula of a filter of a PIU thatparticipates in a functional process.

A write data movement is a movement that moves a data group from a functional process to the persistence storage. In theOO-Method applications, only the sever component of the software can write to the persistence storage. Thus, we have de-fined three mapping rules for the write data movements that take place from the functional processes that occur in the ser-ver layer of the software to the database layer of the software. For instance, the following mapping rule was defined to detectthe write data movement that occurs when a functional process of the server layer destroys an object:

� Mapping Rule 50: 1 write data movement for the class that contains a destroy event or a destroy transaction related to aSIU that participates in a functional process.

3.4. Definition of the numerical assignment rules (The measurement phase)

The measurement rules are the rules that assign a numerical value to the data movements that take place between thefunctional users and the pieces of software of an OO-Method application: this numerical value represents the functional sizeof the generated software application.

Table 2Measurement rules of OOmCFP.

Description Formula

Functional size of a functional process: Aggregation of all the data movements that occur in thisfunctional process

SizeFunctionalProcess ¼Pn

i¼1DataMovementi

Functional size of a layer: Aggregation of the functional size of all the functional processes that occurin this layer

SizeLayer ¼Pn

i¼1SizeFunctionalProcessi

Functional size of an OO-Method application: Aggregation of the functional size of all the layers thatcompose this application

SizeOOMethodApplication ¼Pn

i¼1SizeLayeri


According to the COSMIC functional size measurement method, each data movement will be assigned one size unit, whichis referred to as 1 CFP (COSMIC Function Point). In the OOmCFP, the measurement function is identical to the COSMIC mea-surement function. That is, OOmCFP assigns 1 CFP to each data movement. To measure the functional size of a functionalprocess, a layer, and an OO-Method application, we have defined the measurement rules presented in Table 2.

4. Application of the measurement procedure

In the following sub-sections, we illustrate the application of OOmCFP to the rent-a-car system following the sub-stepsdefined in the Jacquet’s process model for software measurement explained in Section 2.4.

4.1. Software documentation gathering

The documents that should be gathered to apply OOmCFP to an OO-Method application are the object, dynamic, func-tional, and presentation models, that is to say, the OO-Method conceptual model. This conceptual model has all the detailsneeded for the generation of the fully working OO-Method application.

Fig. 5. Object model of a rent-a-car system.


The mission statement for a rent-a-car system is: ‘‘To allow the administrator to access the register of client vehicle rent-als in a location of a specific country. The vehicles can be cars or minibuses, and each vehicle has a group, which correspondsto the size of each vehicle. The group of each vehicle is used to calculate the rental price of the vehicle”. Fig. 5 shows theobject model of the OO-Method conceptual model for the rent-a-car system for this mission statement.

The functional model of the OO-Method conceptual model for the rent-a-car system captures the semantics associated tothe changes of state due to event execution. For instance, the event change-rent of the class Rent assigns a value to the attri-bute rate.

The dynamic model of the OO-Method conceptual model of the rent-a-car system represents the valid lives of the objectsof the classes shown in Fig. 5. This model is created automatically from the object model, specifying the services that changethe state of the objects and the possible states that these objects could have.

The information of the rent-a-car system is presented to the user of the application by a menu of options that are modeledby means of a hierarchy action tree (HAT) in the presentation model. For the rent-a-car system, the options of the menu arefive groups of registers called Population Interaction Units (PIU), which group instances of the classes of the object model.Fig. 6 shows the HAT of the rent-a-car system.

For each PIU defined in the menu of the rent-a-car system, the attributes, the actions, the navigations, and the filters con-tained in the interaction unit are specified. When all the models of the OO-Method conceptual model are specified, it is pos-sible to verify the conceptual model and generate the final application from that model. Hence, the conceptual model of therent-a-car system would be the documentation needed to apply the OOmCFP measurement procedure.

4.2. Construction of the COSMIC software model

The construction of the COSMIC software model for OOmCFP is performed by means of the mapping between COSMIC andOO-Method detailed in Section 3.3. Thus, in this sub-step, all the elements that will be measured are identified.

4.2.1. The strategy phaseThe purpose of applying OOmCFP is to measure the functional size of the rent-a-car application that is specifically gen-

erated by the OlivaNova Suite. The scope of this purpose is the rent-a-car OO-Method conceptual model that specifies therent-a-car application in an abstract way. The granularity level is low because all the details are available and needed forthe generation of the rent-a-car application.

Table 3Data groups, data attributes, and layer of the functional processes of the rent-a-car application.

Functional process Data groups Layer Data attributes

PIU_RentsDetails Rent Client, Server Id_Rent, deliveryDate, returnDate, priceClient Client, Server id_Client, clientNameVehicle Client, Server id_Vehicle, units, vehicleModel, rateLocation Client, Server id_Location, address, city, is_airportVehicleGroup Client, Server id_VehicleGroup, groupDescription, valueAdministrator Server id_Administrator

PIU_Vehicle Vehicle Client, Server id_Vehicle, units, vehicleModel, rateVehicleGroup Client, Server id_VehicleGroup, groupDescription, valueAdministrator Server id_Administrator

PIU_Car_Rates Car Client, Server Id_Car, air_conditioning, doors, transmission, fuel,hasCentralLockingSystem, has Airbags, HP, licenseNumber, hasCDPlayer

Vehicle Client, Server id_Vehicle, units, vehicleModel, rateAdministrator Server id_Administrator

PIU_Minibus_Rate Minibus Client, Server Id_Minibus, airConditio, passengersVehicle Client, Server id_Vehicle, units, vehicleModel, rateAdministrator Server id_Administrator

PIU_Location Location Client, Server id_Location, addres, city, is_airportCountry Client, Server id_Country, valueAdministrator Server id_Administrator

Fig. 6. Menu specified in the presentation model of a rent-a-car system.


The pieces of software of the rent-a-car application are the client component, the server component, and the databasecomponent. Each component of an OO-Method application is built for a particular software environment (for instance,the client component will be built with C#, ASP or JSP). Since the rent-a-car system uses ASP for the client component,EJB for the server component, and SQL for the database component, every component of the application is also one layerof the software application.

The functional users of the rent-a-car application are the users and the components of the application. The Administratorclass of Fig. 5 is a functional user because it is an agent and the instances of this class can execute all the services of the appli-cation. In addition, the client component of the rent-a-car system is a functional user because it is a user of the server com-ponent of the application. Moreover, the server component of the rent-a-car system is a functional user because it is a user ofthe client component and the database component of the rent-a-car system.

Between every functional user of the rent-a-car application and its components there exists a boundary: a boundary be-tween the administrator and the client component, a boundary between the client and the server components, and a bound-ary between the server and the database components.

4.2.2. The mapping phaseThe administrator carries out triggering events that occur in the real world, for instance, the registration of the rentals. To

register a rental in the system, the administrator starts a set of functional processes. To identify the functional process, weuse Rule 4 of the measurement guide,7 which specifies that the direct children of the hierarchy action tree (HAT) of the pre-sentation model are functional processes of the application. Therefore, the functional processes are: PIU_RentsDetails,PIU_Vehicle, PIU_Car_Rates, PIU_Minibus_Rate, and PIU_Location (see Fig. 6).

The client functional user of the rent-a-car system starts the functional processes of the server layer that are actions thatthe server layer carries out in response to the petitions of the client functional user. For example, the server layer does thefollowing: reads values from the database to show them to the administrator in a Population Interaction Unit (PIU); executesthe formula of the services that are executed by the actions of a PIU; evaluates the preconditions of the services that are exe-cuted in the default value formula of the variables of a filter of a PIU; etc. For simplicity, the set of the actions that the serverlayer performs in response to the petitions of the client functional user will receive the same name as the functional pro-cesses that occur in the client layer: PIU_RentsDetails, PIU_Vehicle, PIU_Car_Rates, PIU_Minibus_Rate, and PIU_Location.

Using Rule 9 of the measurement guide,7 we identify the data groups of the rent-a-car system. This rule specifies that thedata groups of each functional process are the classes that participate in this functional process. Table 3 shows the functionalprocesses, the data groups that participate in each functional process indicating the layer where the data group participates,and the attributes of each data group.

The data movements identified for every functional process in the client and server layers of the rent-a-car system aredetailed in Table 4.

4.3. The measurement phase: assignment of numerical rules

In the sub-step of the assignment of numerical rules, 1 CFP (COSMIC Function Point) is assigned to each data movementidentified in the previous sub-step (Section 4.2). Therefore, the aggregation of the identified data movements will determinethe functional size of each functional process. The column Total of Table 4 shows the functional size of the functional pro-cesses of the rent-a-car system in the client and in the server layers, respectively.

The functional size of the client and the server layer of the rent-a-car system can be obtained by applying the measure-ment rule for the layers over the functional size of each functional process of the rent-a-car system. For the client layer, wehave obtained 51 CFP; for the server layer, we have obtained 44 CFP. Finally, applying the measurement rule for the OO-Method application, the functional size obtained for the rent-a-car system is 95 CFP.

5. General analysis

In this paper, we have presented OOmCFP, which is an FSM procedure for applications that are generated from object-oriented conceptual models in MDA environments. This procedure was designed in accordance with the COSMIC standard

Table 4Data movements of the rent-a-car application for each functional process identified.

Functional process Client (CFP) Server (CFP)

Entry Exit Total Entry Exit Read Write Total

PIU_RentsDetails 11 9 20 8 3 3 3 17PIU_Vehicle 12 12 24 8 4 2 5 19PIU_Car_Rates 1 1 2 0 1 1 0 2PIU_Minibus_Rate 1 1 2 0 1 1 0 2PIU_Location 2 1 3 0 2 2 0 4


method, which is an FSM method that allows the measurement of each layer of an application as well as the whole appli-cation. This is in contrast to other FSM standard methods that only allow the measurement of the whole application.

The OOmCFP procedure has been designed to obtain accurate measures of the application that is generated from the con-ceptual models. This is feasible because we have selected a conceptual model that has enough semantic expressiveness tospecify all the functionality of the final application. Therefore, the measures obtained are accurate because all the data move-ments that occur in the final application could be traceable to the conceptual model. Assuming that the conceptual model isof high quality (that is, the conceptual model is correct and complete), the OOmCFP could be completely automated, provid-ing the measurement results in a few minutes using minimal resources. Obviously, if the conceptual model has incorrectinformation or missing information, the application cannot be generated and the measures obtained cannot be traceable.In this case, the measurement procedure could be used to detect defects in the conceptual models.

OOmCFP has been systematically designed applying a set of steps of a software measurement process model. Since thereis not consensus in the concepts and terminology used in the software measurement field, the concepts and terminologyused in the design of OOmCFP have been carefully selected from the ISO VIM [30], ISO 14143 series [32,33] and ISO19761 [34]. There exist some proposals defined to harmonize these concepts and provide a consistent terminology, suchas the software measurement ontology (SMO) [20] and a framework for software measurement [25]. Both, the SMO andthe framework are mainly based in the ISO VIM concepts. The SMO is comprised of four sub-ontologies: (1) software mea-surement characterization and objectives, (2) software measures, (3) measurement, and (4) measurement approaches.OOmCFP is aligned with the first three sub-ontologies because it uses the term ‘measure’ instead of ‘metric’, it uses the ‘unitof measurement’ and ‘measurement result’ concepts, and it defines the ‘entity’ and the ‘attribute’ to be measured. The mea-surement approach sub-ontology classifies a measurement approach in ‘measurement method’, ‘measurement function’, and‘analysis model’. We not agree with this classification because a measurement method can have a measurement functiondefined, as the COSMIC measurement method. For this reason, OOmCFP is not aligned with the measurement approachsub-ontology of SMO. The framework for measurement methods defines a set of concepts and terminology for the designand verification of the measurement methods. These concepts are similar to the concepts of the SMO, for instance the frame-work defines the concepts of measure, measurement result, unit of measurement, entity, and attribute. Thus, OOmCFP isaligned with the terms and concepts defined in the framework. In contrast to the SMO, the framework defines a classificationfor measurement methods and measurement procedures. OOmCFP is characterized by this classification. The framework alsodefines the life cycle of the measurement methods: design, application, and exploitation. In this article, we are covering thetwo first phases of the measurement life cycle of OOmCFP.

In the design of OOmCFP, we have identified a set of mapping rules that allow the relevant primitives of the OO-Methodconceptual model to be selected according to the COSMIC concepts. Moreover, a set of measurement rules has been defined toobtain the functional size of each software layer identified. Even though OOmCFP has been designed to be used specifically inthe OO-Method context, many conceptual constructs of the OO-Method conceptual model can be found in other object-ori-ented methods. Moreover, the main modeling constructs used by OO-Method are basic constructs that have UML represen-tation support. That is why the OOmCFP procedure could be generalized to other object-oriented development methods andthe presented results can be applied to any UML-based method where those primitives are present (for instance [18,38,49]).

To illustrate the application of OOmCFP procedure, we have manually measured the functional size of a rent-a-car system,obtaining 95 COSMIC Function Points. However, we can identify some validation threats for the results obtained; for in-stance, one threat is the natural variation in human performance because a human may erroneously identify the data move-ments that occur in an application (duplicates, omissions, etc.). To avoid this validation threat for the results obtained, wehave implemented a prototype that automates the measurement procedure [44]. Another validation threat for the resultsobtained is that these measurement results came from a measurement procedure that was instantiated by a single person.To avoid this threat, a pilot study has been carried out with 12 students, and the measurement results of the students werecompared with the results obtained previously [43].

In order to evaluate the accuracy of the OOmCFP measurement procedure (related to the closeness to the ‘true value’),precise measures must first be obtained. In the ISO 5725 standard [31], precision is defined as the closeness of agreementof test results. To evaluate the precision of measures, the ISO 5725 presents the formulae for calculating the repeatability8

[33] and the reproducibility9 [33] of the measures. The results of the pilot study confirm the reproducibility of the measures,and the results obtained by the prototype confirm the repeatability of the measures. Therefore, we can state that OOmCFP ob-tains precise measures. However, this does not imply that OOmCFP obtains accuracy measures because other factors can influ-ence the measurement (for instance, the use of models that do not completely specify the final application).

Given that the OO-Method conceptual model allows the complete specification of the final applications in an abstractway, we compare the measurement of six conceptual models using OOmCFP with the measures of the respective generatedapplications that were obtained directly applying the COSMIC measurement method by three experts. These OO-Methodconceptual models represent the functionality of the following systems: invoice, rent-a-car, camping, publishing, photogra-phy agency, and expense report. The first three conceptual models were fully measured, obtaining a functional size of 108

8 The repeatability is defined in the ISO/IEC 14143-3 as the closeness of the agreement between the results of successive measurements of the samemeasurand carried out under the same conditions.

9 The reproducibility is defined in the ISO/IEC 14143-3 as the closeness of the agreement between the results of measurements of the same measurandcarried out under changed conditions.


CFP, 95 CFP, and 456 CFP, respectively. The remaining three conceptual models were used to measure some of the functionalprocesses: user management (32 CFP) and publishing service (9 CFP) for the publishing conceptual model; the assignment ofthe request (20 CFP) and the creation of an article (18 CFP) for the photography agency conceptual model; and expense man-agement (72 CFP) and payment (48 CFP) for the expense report conceptual model. The results obtained are very close to themeasures obtained by the experts (the ‘true value’). However, in order to state that OOmCFP obtains accurate measurements,we need to perform more empirical studies.

6. Conclusion

In this paper, we have demonstrated the applicability of the COSMIC standard method as an accurate measure of the func-tional size of object-oriented applications generated in MDA environments. We have demonstrated this applicability bydefining an FSM procedure, named OOmCFP, which allows the measurement of functional size from the conceptual modelsthat specify the generated applications.

In MDA environments, the applications are generated by means of model transformations. Therefore, the conceptualmodels must have the required semantic formalization to specify all the functionality of the generated application. For thisreason, all the data movements that can occur in the generated applications can be identified in the conceptual model.

The OOmCFP procedure is currently focused on a single MDA environment (OO-Method). Nevertheless, it is important toremark that the model that the OO-Method used is based on conceptual primitives that are well known and well covered bythe UML notation. In fact, any model-driven development approach that is built using UML diagrams could potentially ben-efit from the ideas and results presented in the paper. It is our belief that the contributions of our work can be easily pro-jected to those MDA-based approaches. Thus, the major contribution of this work is the methodology for preparing thespecifications of an FSM procedure that performs accurate measurement in the conceptual models of an MDA method.

A suggestion for future work is the definition of a validation methodology that supports the specification of FSM proceduresthat are defined to measure applications generated in MDA environments. This validation methodology must focus on both the-oretical and empirical validations. Some issues that must be considered in the validation methodology are explained in [4].

Further work also includes the improvement of the prototype developed to implement an industrial tool that automatesOOmCFP as well as empirical studies to evaluate the reproducibility and the repeatability of OOmCFP according to the ISO5725 standard [31]. We use this standard in contrast to other studies [2,3] that are based on the Kemerer equation [37] be-cause this equation uses the average, which is not correct if the results of the measurements are not homogeneous.

References

[1] S. Abrahão, E. Mendes, J. Gomez, E. Insfrán, A model-driven measurement procedure for sizing Web applications: design, automation and validation, in:ACM/IEEE 10th International Conference On Model Driven Engineering Languages and Systems (MoDELS), 2007, pp. 467–481.

[2] S. Abrahão, G. Poels, Experimental evaluation of an object-oriented Function Point Measurement procedure, Information and Software Technology 49(4) (2007) 366–380.

[3] S. Abrahão, G. Poels, A family of experiments to evaluate a functional size measurement procedure for Web applications, Journal of Systems andSoftware 82 (2009) 253–269.

[4] S. Abrahão, G. Poels, O. Pastor, A functional size measurement method for object-oriented conceptual schemas: design and evaluation issues, Journal ofSoftware and System Modeling 5 (1) (2006) 48–71.

[5] A. Abran, J. Desharnais, A. Lesterhuis, B. Londeix, R. Meli, P. Morris, S. Oligny, M. O’Neil, T. Rollo, G. Rule, L. Santillo, C. Symons, H. Toivonen, The COSMICFunctional Size Measurement Method – Version 3.0, 2007.

[6] A. Abran, J. Desharnais, S. Oligny, D. St-Pierre, C. Symons, COSMIC-FFP Measurement Manual – Version 2.0, 1999.[7] A. Abran, J. Desharnais, S. Oligny, D. St-Pierre, C. Symons, COSMIC-FFP Measurement Manual – Version 2.1, 2001.[8] A. Abran, J.M. Desharnais, S. Oligny, D. St-Pierre, C. Symons, COSMIC-FFP Measurement Manual – Version 2.2, The COSMIC Implementation Guide for

ISO/IEC 19761, 2003.[9] A. Albrecht: Measuring Application Development Productivity, IBM Applications Development Symposium, 1979, pp. 83–92.

[10] S. Azzouz, A. Abran, A proposed measurement role in the Rational Unified Process (RUP) and its implementation with ISO 19761: COSMIC FFP, SoftwareMeasurement European Forum (SMEF), 2004, pp. 1–12.

[11] K. Berkenkötter, Reliable UML models and profiles, Electronic Notes in Theoretical Computer Science 217 (2008) 203–220.[12] V. Bévo, G. Lévesque, A. Abran, Application de la méthode FFP à partir d’une spécification selon la notation UML: compte rendu des premiers essais

d’application et questions, in: Ninth International Workshop on Software Measurement (IWSM), 1999, pp. 230–242.[13] CARE-Technologies: Web site <http://www.care-t.com/>. Last accessed January 2010.[14] N. Condori-Fernández, S. Abrahão, O. Pastor, On the estimation of software functional size from requirements specifications, Journal of Computer

Science and Technology 22 (3) (2007) 358–370.[15] G. Dedene, M. Snoeck, M.E.R.O.DE.: a model-driven entity-relationship object-oriented development method, ACM SIGSOFT Software Engineering

Notes 19 (3) (1994) 51–61.[16] H. Diab, M. Frappier, R. St-Denis, Formalizing COSMIC-FFP using ROOM, in: ACS/IEEE International Conference on Computer Systems and Applications

(AICCSA), 2001, pp. 312–318.[17] I. Diaz, J. Sanchez, O. Pastor, Metamorfosis: Un marco para el análisis de requisitos funcionales. Workshop on Requirements Engineering (WER), 2005,

pp. 233–244.[18] T. Fink, M. Koch, K. Pauls, An MDA approach to Access Control Specifications using MOF and UML profiles, Electronic Notes in Theoretical Computer

Science 142 (2006) 161–179.[19] R.B. France, S. Ghosh, T. Dinh-Trong, A. Solberg, Model-driven development using UML 2.0: promises and pitfalls, IEEE Computer 39 (2) (2006) 59–66.[20] F. García, M.F. Bertoa, C. Calero, A. Vallecillo, F. Ruíz, M. Piattini, M. Genero, Towards a consistent terminology for software measurement, Information

and Software Technology 48 (8) (2006) 631–644.[21] G. Giachetti, B. Marín, N. Condori-Fernández, J.C. Molina, Updating OO-Method Function Points, in: Sixth IEEE International Conference on the Quality

of Information and Communications Technology (QUATIC 2007), 2007, pp. 55–64.

http://www.care-t.com/


[22] J. Gómez, E. Insfrán, V. Pelechano, O. Pastor, The Execution Model: a component-based architecture to generate software components from conceptualmodels, Workshop on Component-based Information Systems Engineering, 1998.

[23] G. Grau, X. Franch, Using the PRiM method to Evaluate Requirements Model with COSMIC-FFP. International Conference on Software Process andProduct Measurement (IWSM-MENSURA), 2007, pp. 110–120.

[24] P. Habela, E. Glowacki, T. Serafinski, K. Subieta, Adapting use case model for COSMIC-FFP based measurement, in: 15th International Workshop onSoftware Measurement (IWSM), 2005, pp. 195–207.

[25] N. Habra, A. Abran, M. Lopez, A. Sellami, A framework for the design and verification of software measurement methods, Journal of Systems andSoftware 81 (5) (2008) 633–648.

[26] IEEE: IEEE 830 Guide to Software Requirements Specifications, 1984.[27] IFPUG: Function Point Counting Practices Manual Release 4.1, 1999.[28] IFPUG: International Function Point Users Group Web Site <www.ifpug.org>. Last accessed January 2010.[29] E. Insfrán, O. Pastor, R. Wieringa, Requirements engineering-based conceptual modelling, Journal Requirements Engineering (RE) (2002) 61–72.[30] ISO: International Vocabulary of Basic and General Terms in Metrology (VIM), 2004.[31] ISO: ISO 5725-2 – Accuracy (trueness and precision) of Measurements Methods and Results – Part 2: Basic Method for the Determination of the

Repeatability and Reproducibility of a Standard Measurement Method, 1994.[32] ISO: ISO/IEC 14143-1 – Information Technology – Software Measurement – Functional Size Measurement – Part 1: Definition of Concepts, 1998.[33] ISO: ISO/IEC 14143-3 – Information Technology –Software Measurement – Functional Size Measurement –Verification of Functional Size

Measurement Methods, 2003.[34] ISO/IEC: ISO/IEC 19761, Software Engineering – COSMIC-FFP – A Functional Size Measurement Method, 2003.[35] J.P. Jacquet, A. Abran, From software metrics to software measurement methods: a process model, in: Third International Standard Symposium and

Forum on Software Engineering Standards (ISESS), 1997, pp. 1–12.[36] M.S. Jenner, COSMIC-FFP and UML: estimation of the Size of a System Specified in UML – Problems of Granularity, in: Fourth European Conference Soft.

Measurement and ICT Control, 2001, pp. 173–184.[37] C.F. Kemerer, Reliability of Function Points Measurement, Communications of the ACM 36 (2) (1993) 85–97.[38] D.-K. Kim, R. France, S. Ghosh, A UML-based language for specifying domain-specific patterns, Journal of Visual Languages and Computing 15 (3-4)

(2004) 265–289.[39] B. Kitchenham, Counterpoint: the problem with function points, IEEE Software Status Report 14 (2) (1997) 29–31.[40] T. Kralj, I. Rozman, M. Hericko, A. Zivkovic, Improved standard FPA method—resolving problems with upper boundaries in the rating complexity

process, Journal of Systems and Software 77 (2) (2005) 81–90.[41] A. Lehne, Experience report: function points counting of object-oriented analysis and design based on the OOram method, in: Conference on Object-

Oriented Programming Systems, Languages, and Applications (OOPSLA), 1997.[42] G. Levesque, V. Bevo, D.T. Cao, Estimating software size with UML models, in: C3S2E Conference, 2008, pp. 81–87.[43] B. Marín, N. Condori-Fernández, O. Pastor, Towards a method for evaluating the precision of software measures, in: Eighth International Conference on

Quality Software (QSIC), IEEE Computer Society Press, 2008, pp. 305–310.[44] B. Marín, G. Giachetti, O. Pastor, Automating the measurement of functional size of conceptual models in an MDA environment, Product-Focused

Software Process Improvement (PROFES), LNCS, Springer, 2008, pp. 215–229.[45] S. Mellor, J. Balcer, Executable UML: A Foundation for Model-Driven Architecture, Addison Wesley, 2002.[46] MERODE: Web site <http://merode.econ.kuleuven.ac.be/cgintro.aspx>.[47] P. Molina, Especificación de interfaz de usuario: De los requisitos a la generación automática, Universidad Politécnica de Valencia, Valencia, España, 2003.[48] S. Nagano, T. Ajisaka, Functional metrics using COSMIC-FFP for object-oriented real-time systems, in: 13th International Workshop on Software

Measurement (IWSM), 2003, pp. 1–7.[49] A. Olivé, R. Raventós, Modeling events as entities in object-oriented conceptual modeling languages, Data and Knowledge Engineering 58 (3) (2006) 243–262.[50] OMG: MDA Guide Version 1.0.1, 2003.[51] OMG: MDA Web site <http://www.omg.org/mda/>. Last accessed January 2010.[52] OMG: UML 2.1.2 <Superstructure Specification>, 2007.[53] A.L. Opdahl, B. Henderson-Sellers, A Unified Modelling Language without referential redundancy, Data and Knowledge Engineering 55 (3) (2005) 277–300.[54] O. Pastor, J. Gómez, E. Insfrán, V. Pelechano, The OO-Method approach for information systems modelling: from object-oriented conceptual modeling

to automated programming, Information Systems 26 (7) (2001) 507–534.[55] O. Pastor, F. Hayes, S. Bear, OASIS: an object-oriented specification language, in: International Conference on Advanced Information Systems

Engineering (CAiSE), 1992, pp. 348–363.[56] O. Pastor, J.C. Molina, Model-Driven Architecture in Practice: A Software Production Environment Based on Conceptual Modeling, Springer, New York, 2007.[57] G. Poels, A functional size measurement method for event-based object-oriented enterprise models, in: International Conference on Enterprise Inf.

Systems (ICEIS), 2002, pp. 667–675.[58] G. Poels, Functional size measurement of multi-layer object-oriented conceptual models, Lecture Notes in Computer Science, vol. 2817, Springer,

Berlin/Heidelberg, 2003. pp. 334–345.[59] B. Selic, G. Gullekson, P.T. Ward, Real-Time Object Oriented Modelling, Wiley, 1994.[60] D. St-Pierre, M. Maya, A. Abran, J.-M. Desharnais, P. Bourque, Full Function Points: Counting Practices Manual, 1997.[61] H. Tavares, A. Carvalho, J. Castro, Medicao de Pontos por Funcao a partir da Especificacao de Requisitos, Workshop on Requirements Engieneering

(WER), 2002, pp. 278–298.[62] T. Uemura, S. Kusumoto, K. Inoue, Function Point Measurement tool for UML design specification, in: Fifth IEEE International Software Metrics

Symposium (METRICS), 1999, pp. 62–71.[63] A. Zivkovic, I. Rozman, M. Hericko, Automated software size estimation based on function points using UML models, Information and Software

Technology 47 (13) (2005) 881–890.

Beatriz Marín is a researcher and Ph.D. student of the Centro de Investigación en Métodos de Producción de Software (PROS) at
the Universidad Politécnica de Valencia (Spain). She received her degree in Informatics Engineering from Pontificia UniversidadCatólica de Valparaíso (Chile) in 2003 and her M.Sc. in Software Engineering, Formal Methods and Information Systems fromUniversidad Politécnica de Valencia (Spain) in 2008. She has more than 5 years of industrial experience in Tuxpan (Chile)working in the development of information systems as well as project leader. She also has experience in teaching in universityenvironments. Her research interests include software functional size measurement, software quality, quality of conceptualmodels, empirical software engineering, Model-Driven Development and Model-Driven Architecture.
http://www.ifpug.org

http://merode.econ.kuleuven.ac.be/cgintro.aspx

http://www.omg.org/mda/

Oscar Pastor is a Professor and the Director of the Centro de Investigación en Métodos de Producción de Software (PROS) at theUniversidad Politécnica de Valencia (Spain). He received his Ph.D. in 1992. He was a researcher at HP Labs, Bristol, UK. He has
published more than 200 research papers in conference proceedings, journals and books, received numerous research grantsfrom public institutions and private industry, and been keynote speaker at several conferences and workshops. Chair of the ERSteering Committee, and member of the SC of conferences as CAiSE, ICWE, CIbSE or RCIS, his research activities focus onconceptual modeling, Web engineering, requirements engineering, information systems, and model-based software production.He created the object-oriented, formal specification language OASIS and the corresponding software production method OO-METHOD. He led the research and development underlying CARE Technologies that was formed in 1996 by the UniversidadPolitécnica de Valencia and Consoft S.A. CARE Technologies has created an advanced MDA-based Conceptual Model Compilercalled OlivaNova, a tool that produces a final software product starting from a conceptual schema that represents systemrequirements. He is currently leading a multidisciplinary project linking Information Systems and Bioinformatics notions,oriented to designing and implementing tools for Conceptual Modeling-based interpretation of the Human Genome
information.


Alain Abran is a Professor and the Director of the Software Engineering Research Laboratory at the École de TechnologieSupérieure (ETS) – Université du Québec (Montréal, Canada). He received his Ph.D. in Electrical and Computer Engineering(1994) from École Polytechnique de Montréal (Canada) and master degrees in Management Sciences (1974) and ElectricalEngineering (1975) from University of Ottawa. He has over 15 years of experience in teaching in a university environment aswell as more than 20 years of industry experience in information systems development and software engineering. His researchinterests include software productivity and estimation models, software engineering foundations, software quality, softwarefunctional size measurement, software risk management and software maintenance management. Dr. Abran is currently a co-editor of the Guide to the Software Engineering Body of Knowledge project and the chairman of the Common Software Mea-surement International Consortium (COSMIC).

Documents

Towards an accurate functional size measurement procedure for conceptual models in an MDA environment