N24 FPA Applied to UML and Use Cases (v1.0.1)

8/4/2019 N24 FPA Applied to UML and Use Cases (v1.0.1)

1/28

FPA applied to UML/Use cases

Version 1.0

www.nesma.nl

PUBLICATION OF THE NETHERLANDS SOFTWARE METRICS USERS ASSOCIATION


2/28

2

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 ormade public in any way or in any form, without prior written consent by the NESMA. After having been granted permission, thetitle page of the document that includes (parts of) this document must contain the following text: This work contains materialfrom FPA applied to UML/Use Cases. Permission for publication has been granted by the NESMA.


3/28

3

Table of Contents

1 Introduction .................................................................................................................... 41.1 How this document came about ............................................................................. 41.2 Target audience ..................................................................................................... 51.3 How to use this document ...................................................................................... 51.4 Disclaimer .............................................................................................................. 51.5 Bibliography ........................................................................................................... 5

2 UML and the main points for FPA ................................................................................... 62.1 Introduction ............................................................................................................ 62.2 Requirements for specifications ............................................................................. 62.3 UML diagrams and FPA ......................................................................................... 7

3 Use case model ............................................................................................................. 93.1 Introduction ............................................................................................................ 93.2 Use case diagrams ................................................................................................ 93.3 Use case and actor ...............................................................................................103.4 Use Case description ............................................................................................103.5

Granularity of Use cases .......................................................................................11

3.6 Relationships between Use cases ........................................................................13

3.6.1 Include relationships .........................................................................................133.6.2 Extend relationships ..........................................................................................13

3.7 Storyboards ..........................................................................................................143.8 Application of FPA guidelines................................................................................14

4 Class model ..................................................................................................................164.1 Introduction ...........................................................................................................164.2 Class model ..........................................................................................................16

4.2.1 Association........................................................................................................174.2.2 Aggregation .......................................................................................................184.2.3 Composition ......................................................................................................184.2.4 Generalization ...................................................................................................184.3 Preliminary steps before counting .........................................................................194.3.1 Behaviour and persistence ................................................................................194.3.2 Stereotypes .......................................................................................................20

4.4 Application of FPA guidelines................................................................................214.4.1 Determine the code data ...................................................................................214.4.2 Key to key entities without attributes .................................................................214.4.3 Key to key entities with attributes ......................................................................224.4.4 Entity independence and dependence by instance relationships .......................22

5 Glossary ........................................................................................................................25


4/28

4

1 Introduction

FPA (Function Point Analysis) was conceived and developed to be independent of designmethods; 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 termsused in information systems that have been modelled and documented using UML (UnifiedModelling Language) and the terms that are used by FPA. In actual practice, for experiencedcounters of function points, few differences will be encountered between counting functionsin a traditional environment and counting functions in UML. The largest difference is theterminology, 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 casemodel in the application of FPA counting practices.

1.1 How this document came aboutThe 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/UMLdocumentation and terminology to FPA (in accordance with NESMA version 2.2).The guideline is primarily meant for the estimatedfunction point count.

This document basically discusses how to determine user functions (data files and usertransactions) for easily doing an estimated function point count. This does not preclude doingan 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 theNESMA, the members of the working group Counting Practices, as well as FPA and UMLexperts 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.


5/28

5

1.2 Target audienceAt the conception of this document, it was assumed that the reader would be familiar withboth FPA and its associated terminology and UML. It is not necessary to be an expert inthese areas; only a basic knowledge is a requirement.

The document is intended for FP analysts who are faced with a design of an informationsystem that is documented using UML. For this reason, we explain the basic models forcarrying out an FPA, as well as giving a short explanation of the UML terminology. In thisdocument, no explanation of the FPA terminology is given; for this we refer to the FPAcounting practices guideline.

1.3 How to use this documentIn chapter 2 we first of all indicate which UML products can be used for determining thenumber of function points. In Chapter 3 we discuss the Use case model and how todetermine 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 datafunctions to it (paragraph 4.4). Chapter 5 is a glossary of the terms used in this document.

1.4 DisclaimerThe application of FPA as described in this publication was tried and tested at severalcompanies and in several projects. The NESMA cannot claim that this method is scientificallysound. 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 theconsistent application of FPA in other environments. The NESMA cannot be held responsiblefor the use of this guideline, nor for the results obtained through the application of thisguideline.

The NESMA welcomes and appreciates all comments and additions for further improvement.These can be sent directly to the NESMA ([email protected]).

1.5 Bibliography

Thomas Fetcke, Alain Abran, Tho Hau-Nguyen, Mapping the OO-Jacobson approachinto Function Point Analysis, 1998Alistair 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., Addison-

Wesley, 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 Requirementsin UML (thesis Twente university), 2005. This document can be downloaded bymembers 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 systemdevelopment. A practical handbook, version 2.0, 2003
mailto:[email protected]:[email protected]:[email protected]://www.nesma.nl/http://www.nesma.nl/http://www.nesma.nl/http://www.nesma.nl/mailto:[email protected]


6/28

6

2 UML and the main points for FPA

2.1 IntroductionIn this chapter, in accordance with the requirements for specifications needed for making aparticular count, a match will be made with the diagrams available within UML.

In function point analysis, the quantity of information processing that an information systemoffers the user is measured and expressed by the unit Function point. The technicalimplementation of that information system must remain outside of our consideration. We areonly concerned with the logical view. The technology used by that information system has noinfluence on the determined number of function points.

This also applies to the design method and techniques that are used. The use of UML todescribe a system has no influence on the functional realisation of the information system, atleast not from the users perspective.

Current FPA guidelines are generally placed within the framework of a traditional, linearwaterfall development scenario (for example, SDM), but are also applicable within moderniterative methods such as RUP (Rational Unified Process). In modern iterative developmentenvironments too, there is interest in determining project productivity, cost, and manpower inadvance. The difference lies mainly in the moment -or moments- during development when afunction point count can be done. In a traditional scenario the number of function points canbe determined on the basis of an approved functional design. In an iterative scenario this isnot the case. An information system is achieved iteratively. Determining the number offunction points must also happen iteratively. It is conceivable that somewhere along theroute, a part of the total number of function points can be determined fully in detail, and willbe more or less definite, whereas for other parts of the information system (to be specifiedand 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 mainlyconcerned with the modelling tool UML.

2.2 Requirements for specificationsAccording to FPA requirements, the following specifications must be available for anindicative 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.


7/28

7

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 (helpfunctions, etc.)

5. A detailed description of (incoming and outgoing) information flows of the informationsystem at the level of data element types.

These requirements have been worked out in the table below, focusing on the aim of therequirement in FPA.

# Requirements for a specification FPA aim

1 The (Structure) model To specify the data files2 Distinguish the data element types and the

record types in the data modelTo determine the complexity of the datafiles

3 An indication of which information systemmaintains the data

To determine if a data file is an ILF or anEIF

4 A model that describes the behaviour of theinformation system

To specify the transactional functions

5 A detailed specification of the flow of dataelement types and their validations

To determine the complexity of thetransactional functions

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

Behaviour (requirement 4 & 5)

2.3 UML diagrams and FPAUML 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 structureand a diagram that specifies behaviour. To be able to get a good counting result, the aboverequirements must be worked out in the diagrams.

Worked out in the table of possible combinations below, several combinations of diagramscan be used. FPA can be applied to every combination of diagrams that together describeboth structure and behaviour.

An important characteristic of UML is granularity; UML diagrams can be applied at severaldetail levels. Although this is useful from an engineering point of view (a model is developedfurther 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.


8/28

8

The table below, indicates which diagrams are possible in UML for every detail level.Increasing detail in a level gives more possibilities.

Detail levelFPA

Behaviour orstructure?

Diagram Describes

Indicative Behaviour High-level Use casediagram

Actors, system and high levelfunctions

Structure High-level Class diagram Overall information need

Estimated Behaviour Expanded Use casediagram

Actors, system, and functions

Use case Description Actions in a Use case

Activity diagram Actions in a Use case

Interaction Overviewdiagram

Actions in a Use case

State machine diagram Actions in a Use case

System-level Sequencediagram


System-level Collaborationdiagram


Structure Class diagram Information need

Detailed Behaviour Use case diagram Actors, system, and functions

Use case Description Actions in a Use case

Activity diagram Actions in a scenario

Interaction Overviewdiagram

Actions in a scenario

Sequence diagram Actions in a scenario

Collaboration diagram Actions in a scenario

Structure Class diagram Detailed information need

In actual practice, a Use case model (both diagram and descriptions) and a Class model arenearly always available. This combination is very well suited for carrying out FPA (bothindicative and estimated). For doing a detailed count, the Sequence diagram is especiallysuited for determining the complexity of the transactional functions.

In the following chapters, a further explanation of the Use case model and the Class model isgiven, with respect to the application of the FPA guidelines. We do not explicitly discussdetermining the complexity of the user functions. By applying FPA guidelines, one can ofcourse, come to a detailed count.


9/28

9

3 Use case model

3.1 IntroductionIn 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 casedescription. As indicated in paragraph 2.2, the requirements for specifications for doing anFPA fall broadly into two categories: structure and behaviour. The Use case diagramstogether with the Use case descriptions must give sufficient insight into the behaviour of aninformation system. The most important components are the Use case descriptions, whichare necessary for determining the number of user functions. Beside the Use case diagramsand the Use case descriptions in this chapter, we also discuss the usefulness ofStoryboards. Although Storyboards are not an official UML diagram, in actual practice theyoften 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 relationshipsbetween these components. A Use case diagram is part of UML, but just like the othercomponents of UML, is never mandatory. In actual practice, however, this diagram isfrequently made and offers for FPA a good overview of the information system and itsexternal environment, in other words, the application boundaries. In the following example ofa Use case diagram, there are three actors: Manager, salesman, and customer system.

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.

Manager

Formulate creditolic

Update customers

Customer systemAnalyze risks

Price agreement

Document theagreement

Salesman

Credit score

include

include

Customer inquiry


10/28

10

3.3 Use case and actorUML gives the following definition of the term Use Case: The specification of a set ofactions performed by a system, which yields an observable result that is, typically, of valuefor 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 orany other system that interacts with the subject. Actors initiate the Use cases. It is possiblefor one actor to initiate several Use cases. The other way around also applies in that a Usecase can be initiated by several actors. In many cases an actor is a natural person. An actorcan be also an information system, where the Use case describes an interaction betweentwo or more systems.

In FPA the term userplays an essential role when determining user functions.The term userwithin FPA guidelines is defined as follows:

The persons and/or organizations that use or will use the information system to becounted. 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 theresult of requirements from end users for example, but also a result of government orlegal regulations.Other information systems that use data or functions of the information system to becounted.

The term Actorwithin UML coincides with the term Userin FPA counting practices.

Use cases represent the behaviour of the information system perceptible to the actors. Ineach Use case a unit of functionality is specified that produces usefulness or added valuefor 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. UMLdefines it as: Use cases define the offered behaviour of the subject without reference to itsinternal structure.

3.4 Use Case descriptionThe 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 aninformation system. When we take an online web shop as an example, we could have thescenario buy a product:

The customer scrolls through the catalogue and places the desired articles in the shoppingcart. 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 isvalid, confirms the purchase immediately, and sends a confirmation per e-mail to thecustomer.

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


11/28

11

In a Use case, the everything goes well scenario is described as a series of numberedsteps (Use case steps). The alternatives are then described as variations of these steps (seethe example below).

Buying a product1. 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.

AlternativeFailed validation of the credit card numberIn step 6 the information system cannot validate the credit card number. The Information system offersthe customer the possibility of entering the credit card number again.

AlternativeReturning customer3a.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 mainscenario.

The above example has been described in an interactive manner. The user performs anaction, the information system responds, the user performs a following action to which theinformation system responds, etc., etc. This way of describing things, which indeed reflectsthe 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 Usecase description always concern (a part of) the functionality of the application, with regard toform and level of detail Use Case descriptions can differ from one another quite a lot. In theliterature, 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 ofdetail 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 staffenters the customer info., or in greater detail: The front office staff enters the customer firstname, last name, address, and street number, and selects the city. In actual practice theless detailed style is more common. When counting, make sure that all functionality isdescribed. When in doubt ask the systems analyst if the description is complete.

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


12/28

12

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 aconsistent state.

Some examples can clarify this:Use cases are often written in the Update object style. An example of this would beUpdate customer. The Happy flow could then be Customer inquiry and thealternative flows in this Use case could then be Add customer, Modify customer, andRemove customer. In this case there is only one Use case (Update customer) but inaccordance with the counting practices manual, four transactional functions must becounted (1 external inquiry and 3 external input functions). In other words: the Use caseis 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 aredecomposed into all kinds of partial operations, each of which is then described in its ownseparate 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, andConfirm order.

In between these two alternatives lies the meaningful way of modelling Use casesaccording 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 thatforms the basis for the FPA transactional functions. But this does not guarantee a one toone 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 ofthe information system for the organization. At this level, business processes aredescribed in terms of Use cases (Business Use case) or groupings of adjoining Usecases (like a classification in subsystems). This level is too abstract for countingtransactional functions. An example of a Use case at this level would be Process claimat an insurance company.User goals. This level corresponds with the traditional term business activity. Within theaforementioned Use case Process claim we can, for example, distinguish the followingUse 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 uppolicy, Look up policyholder, Add claim adjustment.

Recognizing the FPA transactional functions in Use cases therefore consists of carefullyapplying the definitions from FPA guidelines. The function point analyst must first of alldetermine the level of detail that has been used to document the different Use cases. Onlythen is it possible to determine the transactional functions by analyzing the Use cases (in thesame way as this is done in traditionally documented systems).


13/28

13

3.6 Relationships between Use casesIn addition to the relationships between actors and Use cases, there are also several types ofmutual relationships between Use cases.

3.6.1 Include relationships

We talk about an include relationship when a specific type of behaviour occurs in severalUse cases but is only described once. In figure 3.1 this relationship is used. Both Analyzerisks 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 isdescribed in the separate Use case Credit score.

An Included Use case can be both an elementary process (in accordance with FPAguidelines) or a component of one. An example would be a pick listin which the contents of adata file (not code data) are presented to make a selection. According to the guidelines, thistransactional function must be counted. If it concerns a standard validation that is used inseveral places in the information system however (and for that reason is documentedseparately), 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 thefunctionality of another Use case. To make use of this certain extension points must havebeen declared in the original (base) Use case. The extending Use case can only add extrabehaviour at these extension points (see figure 3.2).

Figure 3.2: Extend relationship

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

Returningcustomer

Buy a product

Extension pointsPayment details

Credit score

Payment details

Credit score


14/28

14

3.7 StoryboardsBesides Use cases, Storyboards are also frequently present. A Storyboard is a visualpresentation of the menus, screens, and screen transitions and navigation. In additionStoryboards 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 dropdowncomponents 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 guidelinesWhen applying the FPA guidelines, points of interest for determining the transactionalfunctions are given below:

An elementary process is an integral unit of work for the user. Use cases are notalways 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 includeUse 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, Modifycustomer, and Delete customer.

The Use case describes a complete business process with several elementaryprocesses (these Use cases are often called Business Use cases).

The Use case diagram gives insight into the boundaries of the information systemand 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 todetermine 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 thereis talk of another logical process and an integral unit of work.

In addition to the basic Use case, also examine the extendand include"Use cases.Possibly additional transactional functions are described there. Attention must be paidto avoid counting the same function twice.If an includeUse case can be carried out independently (the user can start the taskseparately), the user functions are then counted separately. If the includeUse casecannot be carried out separately then it is counted as a component of the calling Usecase.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 useroperation must be counted as an additional transactional function. Pay attention to besure 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 thengenerally has the structure: search, select, and carry out action (for examplemodifying the data). In this example it concerns an external inquiry and an externalinput. Possibly the search argument can be a combination of several unique searcharguments, we then count several external inquiries.


15/28

15

Be careful that the Use case is not concerned with maintaining code data. This mustnot be counted.

If the actor is another information system then we distinguish an interface. Payattention in this situation if all user functions have been described. These arefrequently described in other documents, for example an interface description.


16/28

16

4 Class model

4.1 IntroductionIn 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 bothtypes of files from a standardized data model. The distinction between ILFs and EIFs is thesame in an OO environment as it is in a traditional environment. Also the specific guidelinesconcerning ILFs and EIFs can be applied without hesitation when counting in an OOenvironment.The vital point is: how can the data files be inferred in a correct manner based on the OOClass model.This chapter is set up as follows: in paragraph 4.2, a short explanation is given of the Classmodel, with emphasis on explaining the different relationships. In paragraph 4.3, somepreliminary steps are described that must be carried out before applying the regular countingpractices. In paragraph 4.4, the actual application of FPA guidelines is explained.

4.2 Class modelThe manner of graphically representing a Class model in UML is the so-called Class-diagram. In this paragraph we briefly describe what is minimally necessary to be able readand 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 inthis 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 distinctionbetween 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 accounthas the following instances:

Rabobank account 34.52.28.31 0ABN-AMRO account 57.38.23.029Postbank account 1983647

In object-oriented models, Classes and objects and their relationships form the basicelements. A Class-diagram is a graphic representation of the relationships between Classesand objects and shows their internal consistency. Extensive Class-diagrams are divided intopackages. 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 theClass, the middle part a list of attributes, and the bottom part a list of methods. Depending onwhat is being modelled and the perspective from which it is being modelled, the differentcompartments will be shown. In Business modelling only the name compartment willusually be shown in a Class-diagram of a Class.

1Generally, hybrid situations are found where traditionally set up data models are documented as

class diagrams.


17/28

17

or:

As stated earlier, the Class-diagram also shows the relationships between Classes. UMLrecognizes the following Class/object relationships:

AssociationAggregationCompositionGeneralization

The first three relationships are known as object relationships. These relationships manifestthemselves at the level of the individual objects. Therefore such relationships also indicatemultiplicity (cardinality). On the other hand, generalization relationships are Class-relationships. 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 relationshipbetween customer and order. Within the Class-diagram, association is the simplest type ofrelationship. Just as in a traditional entity relationship diagram, the cardinality and optionalitymust also be shown for associations. In a Class-diagram this is indicated by using the so-called multiplicity, in the example below, a 1 to many relationship. This is an example of amandatory relationship on both sides.

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

customer

order

1

1..*

Bank account

Bank account

bank account nr.: Num Account type: String Amount: Num

DepositAmount(Amount):RemitAmount(Amount):ShowBalance():Amount


18/28

18

4.2.2 Aggregation

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

An aggregate object does not cease to exist when its component objects (players) areremoved. Conversely, if the aggregate object (team) is removed, the component objects willcontinue to exist.Notice that in terms of cardinality and optionality the above multiplicity corresponds to amutually 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-partrelationship but:

a part can belong only to one whole. In a composition relationship, multiplicity on thewhole side is always 1.A composition has clear rules concerning the creation and deletion of part objects. Ifthe whole object is removed then also the part objects expire.

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

4.2.4 Generalization

Generalization works differently from the other relationships. Generalization is a relationshipbetween Classes, not between Objects. By means of generalization a Class inheritscharacteristics 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 (bothattributes and methods) of a motor vehicle.

Order

Order line

1

1..*

Team

Player

0..1

0..*


19/28

19

Generalization is represented in UML as follows:

or:

These Classes inherit from each other. This means that a car (subclass) inherits allcharacteristics 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 isabstract, i.e. no objects of the Class motor vehicle exist; the real objects belong to theClass 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 atfirst 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 andbehaviour of an object are modelled.Before applying the FPA guidelines it is necessary to first remove the classes withoutattributes, except in the case of Class-relationships (Generalization). Classes withoutattributes only contain behaviour and not permanently maintained (persistent) data. Youcould call this preliminary step: removing the non-persistent Classes. The aim here is onlyidentifying the ILFs/EIFs and not identifying the user operations. When counting, only thoseClasses are relevant that contain persistent, i.e. permanent or maintainable data.The reason that we dont immediately remove the Classes without attributes in Class-relations (thus by generalization), lies in the fact that subclasses which apparently have noattributes, can inherit these from Super classes. Deciding whether such classes should notbe counted as data files is postponed until the generalization relationships are evaluated.

Motor vehicle

TruckCar

Motor vehicle

TruckCar


20/28

20

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 awarehouse company. In the example below this Class only has methods, not attributes.

Furthermore, Classes without attributes can occur in a Class model as subclasses that havebeen modelled because of specific behavioural aspects (methods). In reality these are notClasses 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 otherclasses (association, aggregation, and composition) can be removed forthwith.

For the time being, let the classes remain that only describe behaviour and only haveClass relationships with other Classes (generalization relationships). We will deal withthese 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 StereotypesIn UML the possibility exists of indicating a so-called stereotype for model elements. This canbe used to explain the meaning of a UML-symbol in more detail (in this case the Class-symbol) concerning a specific application of that symbol. A Stereotype is indicated as: in the upper compartment of the class-symbol. In this context the Class-symbol is especially suited as a representation of a data collection. In other words: theclasses most appropriate for FPA are the classes of the stereotype . A Classmodel can also contain stereotypes, such as interface-classes and control-classes. Theseare mainly technical constructions.When these types of other stereotypes occur in a Class model, then only the entity classesare relevant for the function point analyst. If these stereotypes do not occur in the Class-

diagram, then we may assume in general, that it only concerns entity-classes, unless it isperfectly clear from their labels, that it concerns technical implementations.

Catalogue

showPriceListPerCategory( )findProduct( )


21/28


22/28

22

4.4.3 Key to key entities with attributes

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

4.4.4 Entity independence and dependence by instance relationships

The next step is assessing the instance relationships for entity independence and entitydependence. A Class diagram has the following instance relationships:

association

aggregationcomposition

generalization

These relations are handled successively:

AssociationAn association is a structural relationship between objects. An example is the relationshipbetween customer and order. Within the Class diagram, the association is the simplesttype 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 fordetermining the entity independence or entity dependence.

Project

ProjectNameProjectStartDateProjectEndDate

Employee

EmployeeNaamEmployeeAddressEmployeeDateOfBirth

ProjectParticipation

JoinProjectDateLeaveProjectDate


23/28

23

AggregationThis concerns a part-whole relationship. An example of such a relationship is givenbelow.

Here too, assess the multiplicitiesIf both sides of the multiplicity have a 1 (mandatory relationship), then count thetwo 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 fordetermining the entity independence or entity dependence.

CompositionFor the composition the situation is somewhat different. This is also a part-wholerelationship, but:

A part can only belong to one whole. By a composition relationship, the multiplicityon the side of the whole is always 1.

A composition has clear rules concerning the life-cycle, both at creation and atdeletion. In terms of function point analysis, we speak of total entity dependence.

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

Order

Order line

1

1..*

Team

Player

0..1

0..*


24/28

24

GeneralizationSubclasses are modelled using super and subclasses. These are represented in thefollowing way:

or:

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 differentbehaviour within the information system (thus specific transactional functions forthe different subclasses). Ascertain on this basis whether they must be countedseparately.Inquire by the user if the super and subclasses are living terms for him.Sometimes such constructions are typical analysis constructions. In that case 1ILF 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 ndifferent Classes.

the Classes are treated as different classes in the Use case(s), (for exampleseveral maintenance Use cases).

Motor vehicle

TruckCar

Motor vehicle

TruckCar


25/28

25

5 Glossary

ActorSomething 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 otherconcepts (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 toanother. It can connect two concepts (binary association) or more than two concepts (n-aryassociation).

ClassA description of a group of objects with equal properties and common behaviour,relationships, and semantics.

Class diagramA graphical representation of an information system showing the classes and therelationships between them. A Class diagram is static; it shows which components haveinteraction but not what happens during that interaction.

Code dataAn entity type that has a secondary function in the information system, such as entity typeswith constants, texts, or decodes, and which is maintainable (either by the informationsystem 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-partrelationship), but where the part only belongs to one whole and specific rules apply tocreation and deletion. Contrast to Aggregation.

Conceptual data modelDefines which data is modelled in an information system, how this data is structured, andwhat is the links are between the data.

Data modelDescribes how the data in an information system is structured.
http://en.wikipedia.org/wiki/Object_associationhttp://en.wikipedia.org/wiki/Object_%28computer_science%29http://en.wikipedia.org/wiki/Data_typehttp://en.wikipedia.org/wiki/Data_typehttp://en.wikipedia.org/wiki/Object_%28computer_science%29http://en.wikipedia.org/wiki/Object_association


26/28

26

Delete ruleWhen determining if there is entity dependence or entity independence, the followingquestion 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), wh ich has Bsjoined 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 deleteall 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 theirrelationship to A.In situation (2) however, this is obviously not the case. Before an A can be deleted, either allthe Bs must be deleted, or joined to another A first. In situation (1), B is entity-dependentwith 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. Thismeans the transactional functions are specified at the level of referred logical data files anddata-element-types, and the logical data files at the level of record types and data-element-types.

Elementary processA 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 additionalaction sequences into the base use case sequence. The base use case must have definedextension points. The extending use case can only add activity at these extension points.

Estimated function point countA function point count where the number of functions per type of user function (transactionalfunctions 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.

GranularityThe level of detail (of a UML diagram).

Happy flowThe 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, butthis behaviour is only modelled once.

Indicative function point countGives an indication of the order of magnitude of an information system or project, exclusivelyusing only a conceptual data model.
http://www.agilemodeling.com/artifacts/systemUseCase.htmhttp://www.agilemodeling.com/artifacts/systemUseCase.htm


27/28

27

InheritanceA relationship between classes having a parent-child structure. The child (subclass) inheritsall properties of its parent (superclass). Because the child can add its own properties to itsinherited 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 theperspective of the parent, this relationship is called a generalization.

Information systemA 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 diagramA diagram showing the sequence of operations and the exchange of data within a modelledsystem.

ObjectA unique instance of Class.

PackageA mechanism for grouping modelling elements, usually Classes.

RUP [Rational Unified Process]A Systems development method that is often used with OO systems development.

Sequence diagramShows the interaction between objects. The flow of time is central to the sequence diagram.

StoryboardA visual presentation of menus, screens, screen flows, and screen transitions. (A story in

comic book form).

SpecializationSee Inheritance.

System boundaryThe conceptual boundary between the information system to be counted and itssurroundings (other information systems, users).

UML [Unified Modelling Language]A graphical language devised by Grady Booch, James Rumbaugh, and Ivar Jacobson todescribe information systems.

Use caseAn 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 descriptionThe textual description of a Use case, usually written in the order in which the operationstake place (flow of events).

Use case diagramThe Use case diagram is a graphical depiction of actors, Use cases and their internalrelationships within the context of an information system.


28/28

User functionsWithin 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 operationAn elementary process. Within FPA we distinguish: input, output, and inquery.

N24 FPA Applied to UML and Use Cases (v1.0.1)

Documents

Transcript of N24 FPA Applied to UML and Use Cases (v1.0.1)