Function Points FAQs
Logical Files – Identification Guidelines
How should data models be assessed when identifying logical files?
The most useful source of information for identifying logical files is a data model diagram. This diagram may be an Entity-Relationship diagram, a Third Normal Form Data Model, an Entity Class Model, a Network Diagram or other form of data representation.
In FPA, a logical file is a conceptual entity type. A conceptual entity type is made up of one or more entity types from a data model which, together, are considered one logical unit by a user.
The term "entity type" in this section refers to an entity type in a data model in third normal-form. This is the most common form of data model and serves as an example of the principles involved.
The first step in identifying logical files is to determine if a data group should be considered by FPA at all. This depends on data persistence among other things. Persistence of a data group is a characteristic describing how long the data group is retained. Three types of persistence are defined:
Only data groups with a Short or Indefinite persistence are potential FPA logical files.
The following guidelines apply to data entities which have been modelled in third normal-form. The guidelines assist in correctly and repeatably identifying logical files from a data model. The principles involved can also be applied to data modelled using different techniques.
The following method to get from a data model in third normal-form to logical files is based on the method recomended by the Nethelands Software Metrics Association (NESMA) and published in their NESMA Function Point Counting Practices Manual. (For further information refer to http://www.nesma.nl) :
3. Determine which entity types are a "key to key entity" but include other attributes. Note that two situations can arise here as a result:
a. The additional attributes are a result of an implementation or design decision to satisfy a non-functional requirement. (not requested by the user; e.g., a date/time stamp for data recovery purposes) . If the entity only includes these non-functional attributes then they are not counted as data element types and the entity type should be dealt with as indicated in step 2 above.
b. The additional non-key attributes are necessary to satisfy the functional user requirements, in which case, they should be treated as indicated in step 4.
4. Examine the remaining entity types to determine whether they are an independent logical file or make up a logical file with one or more related entity types. Determining factors are:
Both of these concepts are described further below.
After the nature of the relationship(s) has been determined, you can assess how the entity types involved should be considered using the Table 1.
Two entity types, Job and Employee for example, can be connected to each other via a relationship; e.g., "has".
The nature of the relationship determines how many employees can work on a job according to the data model (0, 1, or more) and how many jobs a single employee can work on (0, 1, or more).
Suppose the business rule is that several employees can be used for a job (but at least one), and that a single employee may only work on one job. In such a case we say that the relationship between Job and Employee is 1:N.
If the business rule was that not all employees have to work on a job, the "1-side" of the relationship would be optional, and we would denote the relationship between Job and Employee as (1):N
In other situations, the "N-side" could also be optional: 1:(N) or (1):(N).
Entity independence is the degree to which an entity type is meaningful in and of itself without the presence of other entity types. It can be determined, using the rules below, whether an entity type is independent or not within the context of different situations that depend on optionality and cardinality.
Entity independence in a (1):(N) relationship
If a relationship between two entity types (A and B) is bilaterally optional, it means that the entity types can exist independently. In such a case, FPA sees each entity type as entity independent in regard to each other. Entity types A and B each form a logical file and are included in the FPA count.
Entity dependence in a 1:N relationship
If a relationship between two entity types (A and B) is bilaterally mandatory, it means that each entity type cannot exist without its counterpart; i.e., they cannot exist independently of each other. In this case, FPA sees the entity types as entity dependent. Entity types A and B together form one logical file and are included in the FPA count.
Entity dependence or independence in a 1:(N) relationship
If a relationship between two entity types (A and B) is optional, it means that an A may exist to which no Bs are linked; e.g., as in the 1:(N) relationship between Job and Employee.
In such a situation, the idea of entity independence for entity type B plays a role in FPA. What happens to the optional side of the relationship (in this case B) when we want to delete the non-optional side of the relationship (A) when Bs are still linked to it?
Two essentially different situations are distinguished here:
(1) The deletion of A is allowed and all Bs linked to it are deleted in the same action (possibly after a message requests confirmation in which it is stated that all Bs will be deleted automatically with the deletion of A)
(2) The deletion of A is not allowed as long as Bs are still linked to it
In situation (1), the Bs are apparently not significant to the business unless they are related to an A, whereas in situation (2) they are significant.
Before you are allowed to delete A in the latter case, you will first have to actively delete all the related Bs or link these Bs to another A.
In situation (1) we say that B is entity dependent on A and in situation (2) that B is entity independent of A.
Entity types A and B in the FPA count form one logical file in situation (1), whereas in situation (2) they are each a separate logical file.
In the example citing the relationship between Job and Employee, Employee is normally entity independent, because it is not desirable to have all employee data deleted if the data related to a particular job is deleted.
Entity dependence or independence in a (1):N relationship
The concept of entity independence as it pertains to the relationship between A and B in a (1):N relationship can also be dealt with in a similar way. These kinds of relationships, however, seldom appear in practice. The question you now have to ask yourself is, "what happens to the optional side of the relationship (in this case, A) when we want to delete the final B (the non-optional side of the relationship) linked to A?"
Two essentially different situations are distinguished here as well:
(1) The deletion of a final B linked to A is allowed in which A is also deleted in the same action (possibly after a message requests confirmation in which it is stated that A will be deleted automatically with the deletion of B)
(2) The deletion of B is not allowed as long as A is still linked to B
In situation (1), A is apparently not significant to the business unless it is related to one or more Bs, whereas in situation 2 it is significant.
Before you are allowed to delete the final B in the latter case, you will first have to actively delete the related A, or you must link this A to one or more other Bs.
In situation (1) we say that A is entity dependent on B and in situation (2) A is entity independent of B.
Entity types A and B, in FPA, count as one logical file in situation (1), whereas in situation (2) they each count as a separate logical file.
In the following table, A and B are two entity types (not a code table and not a key-to-key entity from the normalized data model that are connected to each other via a relationship).
RET = Record type
DET = Data element type
In some situations more than two entity types can also form a logical file. In such a case, count the total number of entity types as the number of record types. In the event of a bilateral mandatory (1:1) relationship, one logical file with one record type is usually the rule.