FPA applied to UML/Use cases

Version 1.0
www.nesma.nl

PUBLICATION OF THE NETHERLANDS SOFTWARE METRICS USERS ASSOCIATION

ISBN: 978-90-76258-24-9

Copyright NESMA 2008. All rights reserved. Netherlands software metrics users association (NESMA). No part of this publication may be reproduced or made public in any way or in any form, without prior written consent by the NESMA. After having been granted permission, the title page of the document that includes (parts of) this document must contain the following text: This work contains material from FPA applied to UML/Use Cases. Permission for publication has been granted by the NESMA.

Table of Contents 1 Introduction .................................................................................................................... 4 1.1 How this document came about ............................................................................. 4 1.2 Target audience ..................................................................................................... 5 1.3 How to use this document ...................................................................................... 5 1.4 Disclaimer .............................................................................................................. 5 1.5 Bibliography ........................................................................................................... 5 UML and the main points for FPA................................................................................... 6 2.1 Introduction ............................................................................................................ 6 2.2 Requirements for specifications ............................................................................. 6 2.3 UML diagrams and FPA ......................................................................................... 7 Use case model ............................................................................................................. 9 3.1 Introduction ............................................................................................................ 9 3.2 Use case diagrams ................................................................................................ 9 3.3 Use case and actor ...............................................................................................10 3.4 Use Case description ............................................................................................10 3.5 Granularity of Use cases .......................................................................................11 3.6 Relationships between Use cases ........................................................................13 3.6.1 Include relationships .........................................................................................13 3.6.2 Extend relationships ..........................................................................................13 3.7 Storyboards ..........................................................................................................14 3.8 Application of FPA guidelines................................................................................14 Class model ..................................................................................................................16 4.1 Introduction ...........................................................................................................16 4.2 Class model ..........................................................................................................16 4.2.1 Association........................................................................................................17 4.2.2 Aggregation.......................................................................................................18 4.2.3 Composition ......................................................................................................18 4.2.4 Generalization ...................................................................................................18 4.3 Preliminary steps before counting .........................................................................19 4.3.1 Behaviour and persistence ................................................................................19 4.3.2 Stereotypes .......................................................................................................20 4.4 Application of FPA guidelines................................................................................21 4.4.1 Determine the code data ...................................................................................21 4.4.2 Key to key entities without attributes .................................................................21 4.4.3 Key to key entities with attributes ......................................................................22 4.4.4 Entity independence and dependence by instance relationships .......................22 Glossary ........................................................................................................................25

1 Introduction
FPA (Function Point Analysis) was conceived and developed to be independent of design methods; it is a challenge to apply FPA in new design environments. This document has been written to help, and offers a basic guideline for mapping the terms used in information systems that have been modelled and documented using UML (Unified Modelling Language) and the terms that are used by FPA. In actual practice, for experienced counters of function points, few differences will be encountered between counting functions in a traditional environment and counting functions in UML. The largest difference is the terminology, hierarchy, and consistency of the documentation. This guide adheres to the FPA guidelines certified by the ISO, as documented in [NESMA, IFPUG] and can be used by both methods. The steps set out in this guideline are aimed mainly at using the Class model and Use case model in the application of FPA counting practices.

1.1 How this document came about

The NESMA convened a SIG (Special Interest Group) with the following task: The creation of a document as a foundation for the mapping of Use Case/UML documentation and terminology to FPA (in accordance with NESMA version 2.2). The guideline is primarily meant for the estimated function point count. This document basically discusses how to determine user functions (data files and user transactions) for easily doing an estimated function point count. This does not preclude doing an indicative or detailed count, if the documentation contains a sufficient level of detail.

This guideline is the result of work done by the following persons: Peter Bink, Capgemini Hans van den Brink, Centric Information engineering Robert Louwers, ABN AMRO William Maas, Info Support Jolijn Onvlee, Onvlee Opleidingen & Advies Rogier Oudshoorn, Capgemini Richard Sweer, Finidy Wim Visser, Capgemini

Draft versions of this document were reviewed in two rounds by the governing board of the NESMA, the members of the working group Counting Practices, as well as FPA and UML experts of the following companies: Getronics Pink Roccade, Sogeti, Equens, ABN AMRO, QSM, Atos Origin, and Capgemini. A future task will be developing a case study.

1.2 Target audience

At the conception of this document, it was assumed that the reader would be familiar with both FPA and its associated terminology and UML. It is not necessary to be an expert in these areas; only a basic knowledge is a requirement. The document is intended for FP analysts who are faced with a design of an information system that is documented using UML. For this reason, we explain the basic models for carrying out an FPA, as well as giving a short explanation of the UML terminology. In this document, no explanation of the FPA terminology is given; for this we refer to the FPA counting practices guideline.

1.3 How to use this document

In chapter 2 we first of all indicate which UML products can be used for determining the number of function points. In Chapter 3 we discuss the Use case model and how to determine the transactional functions (paragraph 3.8). In chapter 4 we start with an explanation of the Class model and then show how to apply the counting practices for data functions to it (paragraph 4.4). Chapter 5 is a glossary of the terms used in this document.

1.4 Disclaimer
The application of FPA as described in this publication was tried and tested at several companies and in several projects. The NESMA cannot claim that this method is scientifically sound. Additional research and practical use are necessary to validate the guideline. With this guide FPA applied to UML/Use cases, the NESMA wants to promote the consistent application of FPA in other environments. The NESMA cannot be held responsible for the use of this guideline, nor for the results obtained through the application of this guideline. The NESMA welcomes and appreciates all comments and additions for further improvement. These can be sent directly to the NESMA (office@nesma.nl).

1.5 Bibliography
Thomas Fetcke, Alain Abran, Tho Hau-Nguyen, Mapping the OO-Jacobson approach into Function Point Analysis, 1998 Alistair CockBurn, Writing Effective Use cases, Addison-Wesley, 2001. M. Fowler, UML Distilled / A Brief Guide to the Standard Object Modelling Language, 2005. Philippe Kruchten, The Rational Unified Process - An Introduction, 2nd Ed., AddisonWesley, 2000. NESMA, Definities and counting practices voor de toepassing van Functiepuntanalyse, versie 2.2, 2004, [NESMA]. Oudshoorn, Rogier C.A., Application of Functional Size Measurement on Requirements in UML (thesis Twente university), 2005. This document can be downloaded by members of the NESMA from the Internet site (www.nesma.nl). IFPUG, Function Point Counting Practices Manual, release 4.2, 2004 [IFPUG] NESMA, FPAi: Application of function point analysis in the first phases of system development. A practical handbook, version 2.0, 2003

2 UML and the main points for FPA

2.1 Introduction
In this chapter, in accordance with the requirements for specifications needed for making a particular count, a match will be made with the diagrams available within UML. In function point analysis, the quantity of information processing that an information system offers the user is measured and expressed by the unit Function point. The technical implementation of that information system must remain outside of our consideration. We are only concerned with the logical view. The technology used by that information system has no influence on the determined number of function points. This also applies to the design method and techniques that are used. The use of UML to describe a system has no influence on the functional realisation of the information system, at least not from the users perspective. Current FPA guidelines are generally placed within the framework of a traditional, linear waterfall development scenario (for example, SDM), but are also applicable within modern iterative methods such as RUP (Rational Unified Process). In modern iterative development environments too, there is interest in determining project productivity, cost, and manpower in advance. The difference lies mainly in the moment -or moments- during development when a function point count can be done. In a traditional scenario the number of function points can be determined on the basis of an approved functional design. In an iterative scenario this is not the case. An information system is achieved iteratively. Determining the number of function points must also happen iteratively. It is conceivable that somewhere along the route, a part of the total number of function points can be determined fully in detail, and will be more or less definite, whereas for other parts of the information system (to be specified and developed further in future iterations) no more than an estimated or even indicative count is feasible. RUP falls outside the further scope of this guideline, which is mainly concerned with the modelling tool UML.

2.2 Requirements for specifications

According to FPA requirements, the following specifications must be available for an indicative count: 1. A model of the business activities. 2. The estimated requirements for the information system to be realized. 3. Specifications of the external requirements of the information system to be realized. 4. Requirements with respect to the technical characteristics. 5. An overall data model.

The following specifications must be available for an estimated count: 1. A (structure) model showing the logical data files and their internal relationships. 2. An indication where the specified logical data files will be maintained: either by the information system that is to be counted or by another information system. 3. A model that shows the system functions with their incoming and outgoing information flows. 4. The information flows going to and from the functions of the information system and its external surroundings. The following specifications must be available for a detailed count: 1. A model with all logical data files and their internal relationships. 2. The record types and data element types of the logical data files. 3. An indication where the specified logical data files will be maintained: either by the information system that is to be counted or by another information system. 4. A model that shows the system functions with their incoming and outgoing information flows and per function the logical data files as well as all support functions (help functions, etc.) 5. A detailed description of (incoming and outgoing) information flows of the information system at the level of data element types. These requirements have been worked out in the table below, focusing on the aim of the requirement in FPA. # Requirements for a specification 1 The (Structure) model 2 Distinguish the data element types and the record types in the data model 3 An indication of which information system maintains the data 4 A model that describes the behaviour of the information system 5 A detailed specification of the flow of data element types and their validations FPA aim To specify the data files To determine the complexity of the data files To determine if a data file is an ILF or an EIF To specify the transactional functions To determine the complexity transactional functions of the

These requirements can be subdivided in two groups: Structure (requirement 1, 2 & 3) Behaviour (requirement 4 & 5)

2.3 UML diagrams and FPA

UML diagrams visualize either behaviour or structure. For this reason, to count from a functional design in UML, all that is needed is simply a diagram that specifies the structure and a diagram that specifies behaviour. To be able to get a good counting result, the above requirements must be worked out in the diagrams. Worked out in the table of possible combinations below, several combinations of diagrams can be used. FPA can be applied to every combination of diagrams that together describe both structure and behaviour. An important characteristic of UML is granularity; UML diagrams can be applied at several detail levels. Although this is useful from an engineering point of view (a model is developed further as the project progresses - it supports working iteratively), for FPA this is awkward. Superficially, it is not immediately clear what level of detail a diagram has.

The table below, indicates which diagrams are possible in UML for every detail level. Increasing detail in a level gives more possibilities.
Detail level FPA Indicative Behaviour or structure? Behaviour Structure Estimated Behaviour Diagram High-level Use case diagram High-level Class diagram Expanded Use case diagram Use case Description Activity diagram Interaction Overview diagram State machine diagram System-level Sequence diagram System-level Collaboration diagram Class diagram Use case diagram Use case Description Activity diagram Interaction Overview diagram Sequence diagram Collaboration diagram Class diagram Describes Actors, system and high level functions Overall information need Actors, system, and functions Actions in a Use case Actions in a Use case Actions in a Use case Actions in a Use case Actions in a Use case Actions in a Use case Information need Actors, system, and functions Actions in a Use case Actions in a scenario Actions in a scenario Actions in a scenario Actions in a scenario Detailed information need

Detailed

Structure Behaviour

Structure

In actual practice, a Use case model (both diagram and descriptions) and a Class model are nearly always available. This combination is very well suited for carrying out FPA (both indicative and estimated). For doing a detailed count, the Sequence diagram is especially suited for determining the complexity of the transactional functions. In the following chapters, a further explanation of the Use case model and the Class model is given, with respect to the application of the FPA guidelines. We do not explicitly discuss determining the complexity of the user functions. By applying FPA guidelines, one can of course, come to a detailed count.

3 Use case model

3.1 Introduction
In this chapter, we describe how the FPA guidelines for counting user functions can be applied to the Use case model. This concerns both the Use case diagram and the Use case description. As indicated in paragraph 2.2, the requirements for specifications for doing an FPA fall broadly into two categories: structure and behaviour. The Use case diagrams together with the Use case descriptions must give sufficient insight into the behaviour of an information system. The most important components are the Use case descriptions, which are necessary for determining the number of user functions. Beside the Use case diagrams and the Use case descriptions in this chapter, we also discuss the usefulness of Storyboards. Although Storyboards are not an official UML diagram, in actual practice they often contain additional information for determining the number of user functions.

3.2 Use case diagrams

A Use case diagram visualizes the separate Use cases, the actors, and the relationships between these components. A Use case diagram is part of UML, but just like the other components of UML, is never mandatory. In actual practice, however, this diagram is frequently made and offers for FPA a good overview of the information system and its external environment, in other words, the application boundaries. In the following example of a Use case diagram, there are three actors: Manager, salesman, and customer system.

Update customers

Analyze risks
include

Customer system

Price agreement
include

Credit score

Salesman Document the agreement

<<extend>>

Formulate credit policy

Customer inquiry Manager

Figure 3.1: An example of a Use case diagram

An organization will generally have a large number of salesmen. Within the context of the information system, however, they all perform the same role.

3.3 Use case and actor

UML gives the following definition of the term Use Case: The specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system. Use cases are a means of describing the requirements of an information system from the point of view of the so-called actor. An actor is defined in UML as A role played by a user or any other system that interacts with the subject. Actors initiate the Use cases. It is possible for one actor to initiate several Use cases. The other way around also applies in that a Use case can be initiated by several actors. In many cases an actor is a natural person. An actor can be also an information system, where the Use case describes an interaction between two or more systems. In FPA the term user plays an essential role when determining user functions. The term user within FPA guidelines is defined as follows: The persons and/or organizations that use or will use the information system to be counted. This includes: the end-users, the functional administrators, and the operators. The owner and/or his delegated representatives, who determine the requirements and wishes determined in the specifications. These requirements and wishes can be the result of requirements from end users for example, but also a result of government or legal regulations. Other information systems that use data or functions of the information system to be counted. The term Actor within UML coincides with the term User in FPA counting practices. Use cases represent the behaviour of the information system perceptible to the actors. In each Use case a unit of functionality is specified that produces usefulness or added value for the actors concerned. A defining characteristic of a Use case is that it describes the (desired) functionality of an information system in relationship to the outside world. UML defines it as: Use cases define the offered behaviour of the subject without reference to its internal structure.

3.4 Use Case description

The description of a Use case generally includes several so-called scenarios. A scenario (also called a flow) is a series of steps that describe the interaction between an actor and an information system. When we take an online web shop as an example, we could have the scenario buy a product:
The customer scrolls through the catalogue and places the desired articles in the shopping cart. When the customer wants to pay, he or she enters the necessary shipping information and enters the credit card details. The information system checks if the credit card number is valid, confirms the purchase immediately, and sends a confirmation per e-mail to the customer.

This scenario describes one of the possible series of interactions (flows) that can be carried out. In the above scenario it is also possible that the customer has not given the correct credit card number, which causes the transaction to be cancelled. This event will be described in a separate scenario. These scenarios all have in common that they support the same basic objective of a user. In general a Use case has one everything goes well scenario (basic flow or happy flow) and one or more alternative flows (alternate flows) that describe what can go wrong and how a user can achieve his goal in a different way.

10

In a Use case, the everything goes well scenario is described as a series of numbered steps (Use case steps). The alternatives are then described as variations of these steps (see the example below).
Buying a product 1. The customer scrolls through the catalogue and selects the article that he/she wants to buy. 2. Customer proceeds to the checkout. 3. Customer enters the necessary shipping information (address, express or normal delivery). 4. Information system presents all the product information, including price and shipping information. 5. Customer enters his credit card number. 6. Information system validates the credit card number. 7. Information system immediately confirms the purchase. 8. Information system confirms the purchase by sending an email to the customer. Alternative Failed validation of the credit card number In step 6 the information system cannot validate the credit card number. The Information system offers the customer the possibility of entering the credit card number again. Alternative Returning customer 3a.The information system shows the current shipping information, the price of the product, and the last four digits of the credit card number. 3b.The customer accepts these standard items or modifies them. Continue with step 6 of the main scenario.

The above example has been described in an interactive manner. The user performs an action, the information system responds, the user performs a following action to which the information system responds, etc., etc. This way of describing things, which indeed reflects the perceptible behaviour of the information system from the outside, is used a lot. Nevertheless, UML does not dictate this standard. Therefore, although the contents of a Use case description always concern (a part of) the functionality of the application, with regard to form and level of detail Use Case descriptions can differ from one another quite a lot. In the literature, several different templates of Use case descriptions exist, each with its own explanation of the different elements of the Use case. Among and within projects, Use case descriptions can vary widely in content and level of detail throughout the development cycle. This is the result of an iterative way of working. Thus it can occur that steps are described without detail; for example: The front office staff enters the customer info., or in greater detail: The front office staff enters the customer first name, last name, address, and street number, and selects the city. In actual practice the less detailed style is more common. When counting, make sure that all functionality is described. When in doubt ask the systems analyst if the description is complete.

3.5 Granularity of Use cases

As stated earlier, Use cases describe the desired functionality of the information system. Since FPA determines the functional scope of an information system, Use cases are particularly well suited for counting function points. When applying FPA to Use cases however, the divergent levels of detail with which Use cases are written (the granularity) is a cumbersome point. The definition of UML quoted earlier also does not give a definite answer for determining the level of detail of a Use case. In actual practice one thus sees that Use cases differ in granularity. For FPA this is a fundamental point because the whole system of FPA is based on the term elementary process.

11

A process is an elementary process for FPA if two conditions are met: The process is the smallest unit of activity that is meaningful to the user. The process is self-contained and leaves the business of the application in a consistent state. Some examples can clarify this: Use cases are often written in the Update object style. An example of this would be Update customer. The Happy flow could then be Customer inquiry and the alternative flows in this Use case could then be Add customer, Modify customer, and Remove customer. In this case there is only one Use case (Update customer) but in accordance with the counting practices manual, four transactional functions must be counted (1 external inquiry and 3 external input functions). In other words: the Use case is written on a higher level than an elementary process (according to FPA guidelines). The other extreme is a Use case model in which the transactional functions are decomposed into all kinds of partial operations, each of which is then described in its own separate Use case. An example is the transactional function Place an order (for FPA this would be one external input) that has been split into the following Use cases: Validate customer, Validate article, Add order line, Calculate shipping date, and Confirm order. In between these two alternatives lies the meaningful way of modelling Use cases according to the OTOPOP principle (one time- one place- one person, or unity of time, place, and operation). This level comes closest to the idea of the elementary process that forms the basis for the FPA transactional functions. But this does not guarantee a one to one relationship. In actual practice, combinations of granularity can also occur. Another classification of detail levels for distinguishing Use cases is proposed by Cockburn. He distinguishes the following levels: Summary level. Use cases at this level are especially intended to clarify the objectives of the information system for the organization. At this level, business processes are described in terms of Use cases (Business Use case) or groupings of adjoining Use cases (like a classification in subsystems). This level is too abstract for counting transactional functions. An example of a Use case at this level would be Process claim at an insurance company. User goals. This level corresponds with the traditional term business activity. Within the aforementioned Use case Process claim we can, for example, distinguish the following Use cases: Initiate claim, Assess claim, Authorize payment. Sub functions. These are often the reused parts of an elementary process. Examples within the aforementioned Use cases could be: Look up claim, Look up policy, Look up policyholder, Add claim adjustment. Recognizing the FPA transactional functions in Use cases therefore consists of carefully applying the definitions from FPA guidelines. The function point analyst must first of all determine the level of detail that has been used to document the different Use cases. Only then is it possible to determine the transactional functions by analyzing the Use cases (in the same way as this is done in traditionally documented systems).

12

3.6 Relationships between Use cases

In addition to the relationships between actors and Use cases, there are also several types of mutual relationships between Use cases.

3.6.1 Include relationships

We talk about an include relationship when a specific type of behaviour occurs in several Use cases but is only described once. In figure 3.1 this relationship is used. Both Analyze risks and Price agreement use an evaluation of an agreement, namely Credit score. Since both Use cases use exactly the same evaluation process, this evaluation process is described in the separate Use case Credit score. An Included Use case can be both an elementary process (in accordance with FPA guidelines) or a component of one. An example would be a pick list in which the contents of a data file (not code data) are presented to make a selection. According to the guidelines, this transactional function must be counted. If it concerns a standard validation that is used in several places in the information system however (and for that reason is documented separately), then it must not be counted as a separate user function.

3.6.2 Extend relationships

Another type of relationship is called an extend. An extended Use case extends the functionality of another Use case. To make use of this certain extension points must have been declared in the original (base) Use case. The extending Use case can only add extra behaviour at these extension points (see figure 3.2).

Buy a product
Returning customer
<<extend>> Payment details Credit score

Extension points
Payment details Credit score

Figure 3.2: Extend relationship

Here too, the function point analyst must decide from case to case if a separate user operation can be distinguished or not. For example in a library, the Use case Lend out book will be present, but also Extend lending period that will have an extend relationship with Lend out book. Analysis of the Use Case descriptions must then provide an answer to the question if this situation describes a function that is used several times but should only be counted once.

13

3.7 Storyboards
Besides Use cases, Storyboards are also frequently present. A Storyboard is a visual presentation of the menus, screens, and screen transitions and navigation. In addition Storyboards are used for screen design and give insight into which attributes are shown on which screen and in which way. Whether data is presented in list form or as dropdown components can be especially important for the count. Storyboards are not part of UML but are commonly used in actual practice.

3.8 Application of FPA guidelines

When applying the FPA guidelines, points of interest for determining the transactional functions are given below: An elementary process is an integral unit of work for the user. Use cases are not always recognized or described at this level. The following situations can occur: The Use case describes part of an elementary process. This occurs especially in so-called include Use cases. The Use case describes an elementary process, for example Add customer. The Use case includes several elementary processes, for example Update customer that includes the external input functions Add customer, Modify customer, and Delete customer. The Use case describes a complete business process with several elementary processes (these Use cases are often called Business Use cases). The Use case diagram gives insight into the boundaries of the information system and is therefore an aid for determining the scope and the system boundary. In addition to looking at the All is well scenario, also read the alternative flows to determine the transactional functions. Alternative scenarios come in two types: On the one hand it could only have bearing on an error situation. In this case there will usually be no mention of additional user functions. On the other hand it could have bearing on additional steps that the actor carries out. In this case then, there could be additional user functions if there is talk of another logical process and an integral unit of work. In addition to the basic Use case, also examine the extend and include" Use cases. Possibly additional transactional functions are described there. Attention must be paid to avoid counting the same function twice. If an include Use case can be carried out independently (the user can start the task separately), the user functions are then counted separately. If the include Use case cannot be carried out separately then it is counted as a component of the calling Use case. In addition to the basic Use case also examine the Storyboards or screen prints. Storyboards can be an aid to determine if additional transactional functions are used, for example presenting and selecting from a list or drop down list. This additional user operation must be counted as an additional transactional function. Pay attention to be sure the list does not consist of code data. It must then not be counted. Use cases can also frequently contain search arguments. The Use case then generally has the structure: search, select, and carry out action (for example modifying the data). In this example it concerns an external inquiry and an external input. Possibly the search argument can be a combination of several unique search arguments, we then count several external inquiries.

14

Be careful that the Use case is not concerned with maintaining code data. This must not be counted. If the actor is another information system then we distinguish an interface. Pay attention in this situation if all user functions have been described. These are frequently described in other documents, for example an interface description.

15

4 Class model
4.1 Introduction
In this chapter, we describe how FPA guidelines for counting the data model can be applied to the Class model that has been made using OO principles1. In particular, it concerns the application of the counting practices related to inferring both types of files from a standardized data model. The distinction between ILFs and EIFs is the same in an OO environment as it is in a traditional environment. Also the specific guidelines concerning ILFs and EIFs can be applied without hesitation when counting in an OO environment. The vital point is: how can the data files be inferred in a correct manner based on the OO Class model. This chapter is set up as follows: in paragraph 4.2, a short explanation is given of the Class model, with emphasis on explaining the different relationships. In paragraph 4.3, some preliminary steps are described that must be carried out before applying the regular counting practices. In paragraph 4.4, the actual application of FPA guidelines is explained.

4.2 Class model

The manner of graphically representing a Class model in UML is the so-called Classdiagram. In this paragraph we briefly describe what is minimally necessary to be able read and interpret a Class-diagram that has been set up in accordance with UML specifications. The UML specifications concerning Class-diagrams are much broader than can be treated in this brief guideline. We refer you to the large amount of available literature in this area. A Class is the definition (description) of the attributes and the operations (so-called methods) of similar objects. An object is the actual representation of Class (compare the distinction between entity and occurrence (or: entity type and entity)). Objects are also indicated as instances and are a representation of both concrete and abstract things from the real world. For example, the Class Bank account has the following instances:
Rabobank account 34.52.28.31 0 ABN-AMRO account 57.38.23.029 Postbank account 1983647

In object-oriented models, Classes and objects and their relationships form the basic elements. A Class-diagram is a graphic representation of the relationships between Classes and objects and shows their internal consistency. Extensive Class-diagrams are divided into packages. Be careful not to count Classes twice. In a Class-diagram a Class is represented as a rectangle divided into three parts (compartments), separated by horizontal lines. The upper part contains the name of the Class, the middle part a list of attributes, and the bottom part a list of methods. Depending on what is being modelled and the perspective from which it is being modelled, the different compartments will be shown. In Business modelling only the name compartment will usually be shown in a Class-diagram of a Class.

Generally, hybrid situations are found where traditionally set up data models are documented as class diagrams.

16

Bank account <id> bank account nr.: Num <9> Account type: String <6> Amount: Num <15> DepositAmount(Amount): RemitAmount(Amount): ShowBalance():Amount or:

Bank account

As stated earlier, the Class-diagram also shows the relationships between Classes. UML recognizes the following Class/object relationships: Association Aggregation Composition Generalization The first three relationships are known as object relationships. These relationships manifest themselves at the level of the individual objects. Therefore such relationships also indicate multiplicity (cardinality). On the other hand, generalization relationships are Classrelationships. It is thus not possible to indicate Class-relationship multiplicities.

4.2.1 Association
An association is a structural relationship between objects. An example is the relationship between customer and order. Within the Class-diagram, association is the simplest type of relationship. Just as in a traditional entity relationship diagram, the cardinality and optionality must also be shown for associations. In a Class-diagram this is indicated by using the socalled multiplicity, in the example below, a 1 to many relationship. This is an example of a mandatory relationship on both sides. customer

1 1..* order

A multiplicity that is indicated as: 1 - to - 0* is the same as a 1 to many relationship with the optionality on the many side.

17

4.2.2 Aggregation
Aggregation relationships are a particular form of association relationship. An aggregation is a whole part relationship between an aggregate object and component objects. Key words here are: consists of or is part of. An example of such a relationship is given below:

Team

0..1 0..*
Player

An aggregate object does not cease to exist when its component objects (players) are removed. Conversely, if the aggregate object (team) is removed, the component objects will continue to exist. Notice that in terms of cardinality and optionality the above multiplicity corresponds to a mutually optional 1 to many relationship.

4.2.3 Composition
A composition relationship is a more extreme form of an aggregation. It also is a whole-part relationship but: a part can belong only to one whole. In a composition relationship, multiplicity on the whole side is always 1. A composition has clear rules concerning the creation and deletion of part objects. If the whole object is removed then also the part objects expire.

Order

1 1..*
Order line

In the above example an order line object is always part of the same order object, and is completely dependent on it.

4.2.4 Generalization
Generalization works differently from the other relationships. Generalization is a relationship between Classes, not between Objects. By means of generalization a Class inherits characteristics from a superior so-called Super class. This means that, looking at the example below, a car is also a (type of) motor vehicle. A car has all the characteristics (both attributes and methods) of a motor vehicle.

18

Generalization is represented in UML as follows:

Motor vehicle

Car

Truck

or:

Motor vehicle

Car

Truck

These Classes inherit from each other. This means that a car (subclass) inherits all characteristics of a motor vehicle (Super class), and then adds its own characteristics. A car is then a specialization of a motor vehicle. The name of the super class car is always in Italics. This indicates that this Class is abstract, i.e. no objects of the Class motor vehicle exist; the real objects belong to the Class Car or to the Class Truck.

4.3 Preliminary steps before counting

4.3.1 Behaviour and persistence
A Class model has a broader meaning and range then a traditional data model. Although at first sight Class seems analogous to Entity in a data model, upon closer inspection it appears that behavioural aspects are also modelled in a Class model. For in OO, both data and behaviour of an object are modelled. Before applying the FPA guidelines it is necessary to first remove the classes without attributes, except in the case of Class-relationships (Generalization). Classes without attributes only contain behaviour and not permanently maintained (persistent) data. You could call this preliminary step: removing the non-persistent Classes. The aim here is only identifying the ILFs/EIFs and not identifying the user operations. When counting, only those Classes are relevant that contain persistent, i.e. permanent or maintainable data. The reason that we dont immediately remove the Classes without attributes in Classrelations (thus by generalization), lies in the fact that subclasses which apparently have no attributes, can inherit these from Super classes. Deciding whether such classes should not be counted as data files is postponed until the generalization relationships are evaluated.

19

Explanation: This rule has its origin in the definition: it concerns permanent data. An example of a Class that describes only behaviour is the Class Catalogue from a warehouse company. In the example below this Class only has methods, not attributes.

Catalogue

showPriceListPerCategory( ) findProduct( )

Furthermore, Classes without attributes can occur in a Class model as subclasses that have been modelled because of specific behavioural aspects (methods). In reality these are not Classes without attributes, because in fact they inherit the attributes of the Super classes. Use the following guidelines: Classes that only describe behaviour and only have instance-relationships with other classes (association, aggregation, and composition) can be removed forthwith. For the time being, let the classes remain that only describe behaviour and only have Class relationships with other Classes (generalization relationships). We will deal with these Classes when we discuss the handling of generalization relationships. After applying this rule we are left with a Class model that: contains only permanent data. includes only those classes that (also) have attributes.

4.3.2 Stereotypes
In UML the possibility exists of indicating a so-called stereotype for model elements. This can be used to explain the meaning of a UML-symbol in more detail (in this case the Classsymbol) concerning a specific application of that symbol. A Stereotype is indicated as: <<stereotype>> in the upper compartment of the class-symbol. In this context the Classsymbol is especially suited as a representation of a data collection. In other words: the classes most appropriate for FPA are the classes of the stereotype <<entity>>. A Class model can also contain stereotypes, such as interface-classes and control-classes. These are mainly technical constructions. When these types of other stereotypes occur in a Class model, then only the entity classes are relevant for the function point analyst. If these stereotypes do not occur in the Classdiagram, then we may assume in general, that it only concerns entity-classes, unless it is perfectly clear from their labels, that it concerns technical implementations.

20

4.4 Application of FPA guidelines

In this paragraph we explain how FPA guidelines are applied to the data model. The well known four steps from the guidelines are applied, namely: 1. Determine which entity types are code data. 2. Determine the key to key entities without attributes. 3. Determine the key to key entities with attributes. 4. Investigate the nature of the relationships.

4.4.1 Determine the code data

In a Class diagram (potential) code data is frequently difficult to recognize easily. Use the guidelines given below. In a Class model, possible code data could be modelled as enumerations (such as reference tables). An example of an enumeration is the Class shown below of a library system where the members have been classified in categories.

<<enumeration>>

MemberType
Juvenile Adult Senior citizen Student Researcher

Note: if these tables are not maintained, then they must not be counted. If Code data has not been modelled in the Class model, then look: if ranges of values for attributes are updated/maintained at additional documentation such as storyboards and screens possibly, there could be code data there. For the rest, we can apply the ordinary FPA guidelines, for example:

Country
<<id>> code: String <3> Name: String <40>

4.4.2 Key to key entities without attributes

In the Class model, the counterparts of key to key entities in a traditional standardized data model are the so-called Association-Classes. In their pure form, that is, without attributes, these do not occur in a Class model, which of course, does not contain foreign keys.

21

4.4.3 Key to key entities with attributes

In a Class model, Association-Classes are only modelled if there are also attributes. Such Classes are treated in a similar manner as the other Classes.

Project
ProjectName ProjectStartDate ProjectEndDate

Employee
EmployeeNaam EmployeeAddress EmployeeDateOfBirth

ProjectParticipation
JoinProjectDate LeaveProjectDate

4.4.4 Entity independence and dependence by instance relationships

The next step is assessing the instance relationships for entity independence and entity dependence. A Class diagram has the following instance relationships: association aggregation composition generalization These relations are handled successively: Association An association is a structural relationship between objects. An example is the relationship between customer and order. Within the Class diagram, the association is the simplest type of relationship. Use the following guideline: If both sides of the multiplicity have a 1 (mandatory relationship), then count the two Classes together as 1 ILF. If both sides of the multiplicity have a 0, then count the two Classes as 2 ILFs. If the multiplicity has a 0 on only one side, then use the so-called delete-rule for determining the entity independence or entity dependence.

22

Aggregation This concerns a part-whole relationship. An example of such a relationship is given below.
Team

0..1 0..*
Player

Here too, assess the multiplicities If both sides of the multiplicity have a 1 (mandatory relationship), then count the two Classes together as 1 ILF. If both sides of the multiplicity have a 0, then count the two Classes as 2 ILFs. If the multiplicity has a 0 on only one side, then use the so-called delete-rule for determining the entity independence or entity dependence. Composition For the composition the situation is somewhat different. This is also a part-whole relationship, but: A part can only belong to one whole. By a composition relationship, the multiplicity on the side of the whole is always 1. A composition has clear rules concerning the life-cycle, both at creation and at deletion. In terms of function point analysis, we speak of total entity dependence.

Order

1 1..*
Order line

With a composition, entity dependence must always be assumed, therefore the two Classes must be counted together as 1 ILF.

23

Generalization Subclasses are modelled using super and subclasses. These are represented in the following way:

Motor vehicle

Car

Truck

or:

Motor vehicle

Car

Truck

Assess these relationships in the same way as assessing the super and subclasses (specializations and generalizations) in a traditional data model. Therefore in general: When there are differences between the subclasses, examine if there is different behaviour within the information system (thus specific transactional functions for the different subclasses). Ascertain on this basis whether they must be counted separately. Inquire by the user if the super and subclasses are living terms for him. Sometimes such constructions are typical analysis constructions. In that case 1 ILF must be counted. Count 1 ILF if: the user sees it as 1 Class, or the Class is treated as 1 Class in the Use case(s). Count more than one ILF if: the user sees the subclasses as n different Classes. the Classes are treated as different classes in the Use case(s), (for example several maintenance Use cases).

24

5 Glossary
Actor Something or someone that supplies a stimulus to the system. An actor cannot be controlled by the system and is defined as being outside the system. Actor corresponds to the FPA term user. Aggregation (relationship) Aggregation represents the relationship between a concept (as a whole) containing other concepts (as parts). It can also be described as a has-a relationship. Association (relationship) An association is a structural relationship that specifies how concepts are connected to another. It can connect two concepts (binary association) or more than two concepts (n-ary association). Class A description of a group of objects with equal properties and common behaviour, relationships, and semantics. Class diagram A graphical representation of an information system showing the classes and the relationships between them. A Class diagram is static; it shows which components have interaction but not what happens during that interaction. Code data An entity type that has a secondary function in the information system, such as entity types with constants, texts, or decodes, and which is maintainable (either by the information system that is being counted or by another information system). Composition (relationship) A way to combine simple objects or data types into more complex ones (whole-part relationship), but where the part only belongs to one whole and specific rules apply to creation and deletion. Contrast to Aggregation. Conceptual data model Defines which data is modelled in an information system, how this data is structured, and what is the links are between the data. Data model Describes how the data in an information system is structured.

25

Delete rule When determining if there is entity dependence or entity independence, the following question must be asked: what happens to the optional side of the relationship (in this case B) if we want to delete the non-optional side of the relationship (in this case A), which has Bs joined to it? We must decide between two essential situations: 1. Deleting A is permitted, and in the same action all the joined Bs are deleted. (Eventually after receiving confirmation of the message that deleting A will also delete all the Bs.) 2. Deleting A is not permitted, as long as there are still Bs joined to A. In situation (1) Bs obviously have no significant meaning for the business outside of their relationship to A. In situation (2) however, this is obviously not the case. Before an A can be deleted, either all the Bs must be deleted, or joined to another A first. In situation (1), B is entity-dependent with respect to A, in situation (2), entity-independent. Detailed function point count The most precise type of count. All specifications needed for FPA are available in detail. This means the transactional functions are specified at the level of referred logical data files and data-element-types, and the logical data files at the level of record types and data-elementtypes. Elementary process A function is an elementary process if it meets two conditions: It is the smallest unit of activity that is meaningful to the user. After implementation of the function the information system is in a consistent state. Extend (relationship) A generalization relationship where an extending use case continues the behaviour of a base use case. The extending use case accomplishes this by conceptually inserting additional action sequences into the base use case sequence. The base use case must have defined extension points. The extending use case can only add activity at these extension points. Estimated function point count A function point count where the number of functions per type of user function (transactional functions and logical data files) is determined, but for the complexity a default value is used: average for the transactional functions and low for the logical data files. Generalization (relationship) See Inheritance. Granularity The level of detail (of a UML diagram). Happy flow The shortest route to a desired or requested result. It is therefore the basic or normal flow. Include (relationship) A relationship between Use cases in which behaviour in different Use cases is the same, but this behaviour is only modelled once. Indicative function point count Gives an indication of the order of magnitude of an information system or project, exclusively using only a conceptual data model.

26

Inheritance A relationship between classes having a parent-child structure. The child (subclass) inherits all properties of its parent (superclass). Because the child can add its own properties to its inherited behaviour, this relationship is called specialization from the child perspective. On the other hand, the parent specifies the common behaviour of all its children. From the perspective of the parent, this relationship is called a generalization. Information system A system for collecting, keeping, maintaining and presenting data by means of a computer; FPA is only concerned with the automated part of the information system. Interaction Overview diagram A diagram showing the sequence of operations and the exchange of data within a modelled system. Object A unique instance of Class. Package A mechanism for grouping modelling elements, usually Classes. RUP [Rational Unified Process] A Systems development method that is often used with OO systems development. Sequence diagram Shows the interaction between objects. The flow of time is central to the sequence diagram. Storyboard A visual presentation of menus, screens, screen flows, and screen transitions. (A story in comic book form). Specialization See Inheritance. System boundary The conceptual boundary between the information system to be counted and its surroundings (other information systems, users). UML [Unified Modelling Language] A graphical language devised by Grady Booch, James Rumbaugh, and Ivar Jacobson to describe information systems. Use case An interaction between an actor and an application to accomplish a certain goal for the actor. Use cases describe the functionality of an information system from the users perspective, and can exist in different levels of detail (granularity). Use case description The textual description of a Use case, usually written in the order in which the operations take place (flow of events). Use case diagram The Use case diagram is a graphical depiction of actors, Use cases and their internal relationships within the context of an information system.

27

User functions Within function point analysis (FPA) five types of user functions are recognized: Internal logical data file (ILF) External Interface file (EIF) External Input (EI) External Output (EO) External Inquery (EQ) User operation An elementary process. Within FPA we distinguish: input, output, and inquery.

28