Transaction-Typed Points TTPoints
version: 1.0 Technical Report
RA-8/2011 Mirosław Ochodek
Institute of Computing Science Poznan University of Technology
Project operated within the Foundation for Polish Science Ventures Programme co-financed by
the EU European Regional Development Fund.
c
2011 Mirosław Ochodek, Poznan University of Technology All rights reserved
Last changed 2013-07-08
Abstract
Report presents the overview of the procedure of measuring functional size of soft- ware system with Transaction-Typed Points (TTPoints). The size measurement is done based on functional requirements presented in the form of use cases.
Functional size measurement with the TTPoints method is done on the level of so-
called use-case transaction. The size of each transaction is measured based on the type
of transaction, the number of actors co-operating with the system under measurement,
and the number of domain objects that are processed within transaction.
Contents
Contents iv
1 Introduction 1
2 Overview of the Method 2
2.1 Determination of measurement objectives . . . . 2
2.2 Characterization of the concept to be measured . . . . 2
2.3 Meta-model of the method . . . . 2
2.4 Measurement method application . . . . 3
3 Identification of Domain Objects 5 3.1 Relationships between domain objects . . . . 6
3.1.1 Aggregation 6, 3.1.2 Composition 6, 3.1.3 Generalization 6 3.2 Deriving domain model from use cases . . . . 6
3.2.1 Finding candidates for domain objects 7, 3.2.2 Unifying duplicated terms 8, 3.2.3 Domain objects and their properties 8, 3.2.4 Lists, sets, and col- lections 10, 3.2.5 Investigate non-explicit relationships 10, 3.2.6 Investigate additional associations (optional) 10 4 Identification of Use-Case Transactions 11 4.1 Create (C) . . . . 12
4.2 Transfer (T) . . . . 13
4.3 Retrieve (R) . . . . 14
4.4 Dynamic Retrieve (DR) . . . . 15
4.5 Asynchronous Retrieve (AR) . . . . 15
4.6 Update (U) . . . . 16
4.7 Change State (CS) . . . . 17
4.8 Link (L) . . . . 18
4.9 Delete (D) . . . . 19
4.10 Delete Link (DL) . . . . 21
4.11 Complex Internal Activity (CIA) . . . . 21
4.12 Check Object (CO) . . . . 22
Contents
5 Calculate Functional Size and Report Results 24
6 Example of TTPoints Application 26
Bibliography 27
CHAPTER 1
Introduction
Report presents the overview of the procedure of measuring functional size of software system with Transaction-Typed Points (TTPoints) [ONK11]. The size measurement is done based on functional requirements presented in the form of use cases.
The document is indented to be read mainly by the users of the TTPoints method and generally people responsible for measurement in organizations.
This report contains some content from the author’s Ph.D. thesis entitled “Empirical Examination of Use Case Points.” [Och11] and the Technical Report RA-04/10 [Och10].
The report is organized as follows. In Chapter 2 the overview of the TTPoints method
is presented. It contains definitions of the main concepts to be measured, the meta-model
of the measure, and overview of the method’s procedure. In the following Chapters 3, 4,
and 5 the selected steps of the method are presented in details. Finally in Chapter 6, a
simple example of the method usage is presented.
CHAPTER 2
Overview of the Method
2.1 D ETERMINATION OF MEASUREMENT OBJECTIVES
The purpose of the designed method is to measure functional size of a software system at the level of use-case transaction from the user perspective. The method should mitigate the problems observed in the design of the Use Case Points method (UCP) [ONK11].
The main intent of the proposed measurement method is to support effort estimation based on functional requirements expressed in a form of use cases.
2.2 C HARACTERIZATION OF THE CONCEPT TO BE MEASURED
The concept to be measured is the functional size of software application, which is de- fined in ISO/IEC 14143-1 [ISO07] as “a size of the software derived by quantifying the Functional User Requirements.”
The central concept in the designed measurement method is the concept of semantic use-case transaction—as it is described in Chapter ?? (use-case transaction is a representa- tion of Functional User Requirements).
The three sub-concepts that seem to influence the complexity of a single semantic trans- action are the number of actions necessary to be performed by actors in order to satisfy the functional requirements defined for the transaction; the number of actors interacting within the transaction; and the number of domain objects that are processed by the trans- action.
2.3 M ETA - MODEL OF THE METHOD
The meta-model of the TTPoints measurement method is presented in Figure 2.1. The model assumes that functional requirements are defined as a set of use cases (each consists of one or more use-case transactions), actors, and domain objects.
Use-case transaction is a base functional component (BFC) of the proposed measurement
method. Such transaction has its semantic-type, which implies the number of core actions.
2.4. Measurement method application
In addition, each transaction processes a number of domain objects, and involves one or more actors that cooperate with the system under measurement. External actors and the actor representing software under development (SuD) determine the boundary of an appli- cation, which is a conceptual interface between the SuD and its users.
Functional Requirements
Use Case
Actor / SuD
Domain object
Use-case transaction Semantic type
(core actions)
defined as
consists of
has
processes cooperates within
1..*
1..*
1..*
1..*
1..*
1..*
1..*
1..*
1..*
1..*
Figure 2.1: The meta-model illustrating the relationships across the concepts and sub- concepts selected to characterize functional size of a system.
2.4 M EASUREMENT METHOD APPLICATION
The process of applying the TTPoints method to the functional size measurement of a software system consists of the following steps:
1. Gather software requirements documentation. One has to collect documents describing use cases, defined for the system under measurement. If a software specification document does not contain use cases, one can try to identify semantic use-case trans- actions by analyzing the functional requirements of the system in any other form (e.g., if a requirement states that “the system should enable adding articles,” it can be considered as a single create transaction).
2. Identify actors. Identification of actors is a straightforward task, because each use-case model should have an explicitly defined list of actors. In addition, one should also distinguish external actors from the actors representing SuD.
3. Identify domain objects. Domain objects have to be identified according to the rules
presented in Chapter 3. Attention should paid to (in)dependency of domain objects.
2.4. Measurement method application
4. Identify transactions and determine their uniqueness. Use-case transactions have to be identified using the manual or automatic methods of transaction-identification based on semantic transaction-types as presented in Chapter 4.
5. Calculate functional size and report results. Finally, functional size of the system has to
be calculated as presented in Chapter 5.
CHAPTER 3
Identification of Domain Objects
In order to calculate the value of TTPoints, one has to determine the number of do- main objects that are processes within each transaction. This is a straightforward task if a complete domain model is available, containing all domain objects, their properties, and relationships between the objects. Unfortunately, in most of the cases such model is not available at initial stages of the projects, when the TTPoints method is intended to be used.
Therefore in this chapter, we will present guidelines on how to derive the necessary infor- mation about the domain model, based on a set of use cases.
A domain model is usually presented using UML class diagrams. Each domain object (domain class) is represented as a UML class. An example of a simple domain model is presented in Figure 3.1.
Title Proceedings
Author Title
Abstract Paper
Editor Name
Surname E-mail Affiliation
Person
Content Section
1..*
1 1..*
1
1..*
1
1..*
1..*
1
2 3
4 5
Figure 3.1: An example of a domain model presented using the UML class diagram (class
with ¬ and without attributes, aggregation ® , composition ¯ , generalization ° ).
3.1. Relationships between domain objects
3.1 R ELATIONSHIPS BETWEEN DOMAIN OBJECTS
Before we can proceed to describe the procedure of deriving a partial domain model that could be used to measure the size of the system with the TTPoints method, we have to define three relationships between domain objects: aggregation, composition, and gen- eralization.
3.1.1 Aggregation
In domain modeling, an aggregation relation represents semantic relation called meronymy (i.e., a whole / part relationship). For instance, according to the domain model of the conference management system presented in Figure 3.1, each Paper has one or more Authors.
The aggregation is a special case of association relationship in UML. It is represented by a solid line with a hollow diamond as a terminal adornment at the aggregate end of the association line [OMG10].
3.1.2 Composition
In UML, a composite aggregation is defined as “a stronger form of aggregation that re- quires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it” [OMG10]. In domain modeling it still represents meronymy, however, the object which is a meronym loses its meaning without the object being a holonym in that relation. For instance, according to the domain model presented in Figure 3.1, a Section is a part of a Paper. (Composition relationship implies that a section cannot exist without a paper.)
The composition is represented in UML by a solid line with a filled diamond as a ter- minal adornment at the aggregate end of the association line [OMG10].
3.1.3 Generalization
Generalization relation is used in domain modeling to present linguistic relation called hyponymy (i.e., is-a relationship). An example of this relation is presented in Figure 3.1 between the business object Person and the objects Author and Editor. It would imply that both Author and Editor are a “kind of” People.
A generalization between domain objects is shown in UML as a line with a hollow triangle drawn from the specialized business object to the more general one [OMG10].
3.2 D ERIVING DOMAIN MODEL FROM USE CASES
Even though, a complete domain model might not be available, some of the informa- tion about domain objects and relationship between them could be revealed based on the analysis of use cases. For instance, if we analyze the use case presented in Figure 3.2, we could identify an object called “paper.” We could also came to the conclusion that each author is associated with many papers.
Building a complete domain model by analyzing a set of use cases would be very dif-
ficult, or even impossible due to the incompleteness of information. Therefore, we will
3.2. Deriving domain model from use cases
UC1: Submit a paper Level: User
Primary actor: Author Main scenario:
1. Author chooses the option to submit a paper.
2. System presents the submission form.
3. Author provides necessary information about the paper.
4. System informs Author that the paper was submitted.
Alternative scenarios and extensions:
1.A. Author would like to re-submit a paper.
1.A.1. Author chooses the option to re-submit one of his/her papers.
1.A.2. System presents a list of Author's papers.
1.A.3. Author chooses the paper and the option to re-submit the paper.
1.A.4. Go to step 2.
Exceptions:
3.A. Not all required data was provided.
3.A.1. System displays the error message.
3.A.2. Go to step 2.
Figure 3.2: Use case documented as structured text.
focus on presenting an expert-driven approach (partially automatic) to build a sufficient model that could be used to measure the size of a system with TTPoints.
3.2.1 Finding candidates for domain objects
The first step of the procedure is to find nouns that could potential be identified as domain objects. This step can be done automatically by using the natural language pro- cessing (NLP) tools and techniques.
The process of such analysis is as follows. Each step of use case is tokenized and split to sentences. The PoS tagger is used to determine part of speech of each word. Finally, a grammar parser, e.g., Stanford English grammar parser [dMMM06], is used to identify dependencies within sentences, e.g., subjects, predicates, objects etc.
As a result one would obtain a list of noun phrases (NP), each representing an object in the sentence (“object" in the sense of grammatical dependencies). If a noun phrase represent enumeration of n objects it should be split to n separate noun phrases (e.g., “lists of articles and books” should be split to “list of articles” and “list of books”). The identified nouns (objects) could refer to different types of entities, e.g.:
• Domain object candidates — a NP can represent a domain object, e.g., in Figure 3.3 this would be the object “paper”.
• Names of actions – a NP can represent option that is chosen by the Actor, e.g., in Figure 3.3 this would be the options: “submit a paper” and “re-submit a paper”.
• Screens — a NP can refer to a screen that is displayed by the system, e.g., in Figure 3.3
this would be the “submission form”. There is a problem in interpreting screens,
because some of them can represent domain objects – therefore should be counted in
3.2. Deriving domain model from use cases
UC1: Submit a paper Level: User
Primary actor: Author Main scenario:
1. Author chooses the option to submit a paper.
2. System presents the submission form.
3. Author provides necessary information about the paper.
4. System informs Author that the paper was submitted.
Alternative scenarios and extensions:
1.A. Author would like to re-submit a paper.
1.A.1. Author chooses the option to re-submit one of his/her papers.
1.A.2. System presents a list of Author's papers.
1.A.3. Author chooses the paper and the option to re-submit the paper.
1.A.4. Go to step 2.
Exceptions:
3.A. Not all required data was provided.
3.A.1. System displays the error message.
3.A.2. Go to step 2.
option to submit a paper necessary information about the paper
paper
option to re-submit one of his/her papers
option to re-submit the paper
required data error message submission form
list of Author's papers paper
Figure 3.3: Domain object candidates in use case.
TTPoints as objects. Unfortunately, they can also present screens not related directly to certain domain objects, e.q., administrator panel.
• GUI details — use cases should not present details of the graphical user interface (GUI) [Coc01], however, some authors can provide such information in description of use cases, e.g., “User clicks the add button.”
• Other — there could be additional objects that are ambiguous or not meaningful from the domain model perspective. There could also refer to constant elements of the system, e.g., messages. For instance, in Figure 3.3 there are objects “required data” and “error message.”
Therefore, the goal of the analysis is to identify all domain object candidates and op- tionally investigate screen definitions (if available) to either find additional candidates or identify screens that correspond to domain objects.
3.2.2 Unifying duplicated terms
During this stage, one should investigate whether a list of identified domain-object candidates do not contain duplicates (synonyms) of the same terms. If a duplicated term is found it should be reduced to a single “name”. (If possible, the synonyms should be also stored.)
3.2.3 Domain objects and their properties
The first problem when trying to identify domain objects based on noun phrases is that
one has to decide whether a noun is a domain object or a property of other domain ob-
ject. The problem is illustrated in Figure 3.4. The object Person can have properties: name,
surname, e-mail, and affiliation. However, it is also possible to treat those properties as
3.2. Deriving domain model from use cases
Name Surname E-mail Affiliation
Person
Name
Surname
Affiliation Person
?
Figure 3.4: Domain object and its properties or domain object and composition.
separate objects from which Person object is composed. The decision about whether a candidate-object should be treated as a domain object or a property depends on the busi- ness context.
In order to decide whether a candidate object should be classified as a domain object or a property, one should answer the following questions:
1. Is the potential object identifiable by the user in the domain of the problem? If not, it is not a domain object.
2. Does the candidate object have at least one meaningful property? If it does not have a single, meaningful property, it is probably a property itself. For example, let us consider a candidate object “name” – does it have any properties? The answer is no!
Therefore, we should treat it as a candidate for being a property.
3. Is the candidate object part of a goal of a use case? If the candidate object is a part of a use-case title it is probably a domain object [Lia03].
4. Does NP consist of two nouns [LDP04] (e.g, article title)? If there are two objects, it is highly probable that the first one is a domain object (in “article title” it would be
“article”). The second one is for sure part of the first one, however, it could be either its property or its part (according to composition relationship).
As a result of initial analysis, one should assign noun phrases representing candidate objects to three sets:
• O — is a set containing domain objects.
• P — is a set containing potential properties.
• OP — is a set containing NPs for which it was not decided whether they represent domain objects or their properties.
For each property in set P find domain objects in set O to which it belongs (a single
property can belong to many objects). Then, try to map each property from the set P to
potential domain objects in the set OP . If such mapping is possible, add the NP from the
set OP to the set O (and remove it from the set OP ). Moreover, try to map each NP from
the set OP as a property of each object in the same set. Again, if such mapping is possible
add the NP being property to set P , and NP being a domain object to the set O (remove
3.2. Deriving domain model from use cases
both NPs from the set OP ). Finally, try to map each remaining object from the set OP as a property of any domain object in set O.
3.2.4 Lists, sets, and collections
Investigate explicit compound objects, i.e., list of X, set of X, collection of X etc. (where X is a domain object in the sets O and OP ). The main problem is to decide whether a com- pound object is a composition or an aggregation of objects X. This has to be determined by an expert.
3.2.5 Investigate non-explicit relationships
The following step is one of the most difficult and requires domain knowledge. Unfor- tunately, some of the relationships could not be identified based only on the NPs. (How- ever, some of them can be identified by analyzing associations between domain objects in certain contexts, e.g., “user adds a section to the paper” would suggest that paper ag- gregates or is composed of sections.) Therefore, an expert has to analyze existing model and identify all aggregations, compositions, and generalizations relationships that have not been identified so far.
In addition, one should check whether some of the objects are referring to the same objects in different context, e.g., registration and authentication data are actually the same, but they could differ depending on the context—registration versus authentication.
3.2.6 Investigate additional associations (optional)
Finally, a domain expert could search for additional associations. It is not necessary in
the context of functional size measurements with TTPoints, however, it can be helpful to
identify the “Link” type of transactions.
CHAPTER 4
Identification of Use-Case Transactions
The most important step of the TTPoints method is the identification of use-case trans- actions, which is done using the semantic transaction-types. The identification process can be performed manually or automatically using the method presented in [OAJN11].
In the TTPoints method, a definition of use-case transaction by Diev [Die06] is followed, which states that use-case transaction has to satisfy two conditions:
• UCT-C1. Use-case transaction is the smallest unit of activity that is meaningful from the actor’s point of view.
• UCT-C2. Use-case transaction is self-contained and leaves the business of the appli- cation being sized in a consistent state.
There are 12 semantic types of such transactions, presented in Figure 4.1. Each transac- tion has a given number of so-called core actions that are crucial for preserving the meaning of the transaction, and additional actions that are less important or even optional.
When determining the type of transaction one should remember to assign the most accurate sub-type of semantic type (e.g., update => change state). If there are many types of transactions that could be assigned to a given transaction (and it is not possible to state which is the main intent of the use case), and they are not the sub-types of each other, one should assign the type with the highest number of core actions.
For the purpose of counting TTPoints one should also consider uniqueness of each transaction. A transaction is unique if there is no other transaction that:
• has the same semantic type;
• has the same actors participating in,
• processes the domain objects of the same domain classes,
Transactions that are not unique and are not recognized by the user as distinct func-
tionality are rejected from the further analysis.
4.1. Create (C)
There are also implied transactions [IFP10]. An implied transaction can appear when one transaction invoke another, independent transaction. Such transaction has to fulfill all the requirements for the transaction to be included to the calculation of TTPoints measure, i.e., be identified as a separate, closed functionality and be unique.
Semantic transaction types
Create Update
Change State
Delete
Delete Link Asynchronous Retrieve
Dynamic Retrieve Retrieve
Link Transfer
Complex Internal Activity
Check Object
Figure 4.1: Semantic transaction-types.
In the following Sections 4.1–4.12, a catalogue of semantic transaction-types is pre- sented. Each semantic type of transaction is described by presenting its primary intent, typical flow of actions, a set of core actions, and a simple example.
4.1 C REATE (C)
Create transaction is one of the most commonly appearing transaction in the require- Create transaction
ments specifications of data-intensive systems. The primary intent of such transaction is to add an instance of a domain object to the system. The data used to create the object has to be provided by the actor that initiates the operation.
Primary intent: create a new instance of a domain object.
Typical flow of actions:
• Request action (choice of option) — this type of transaction is usually initiated by the actor that chooses an option to create a new instance of a domain object.
• Provision action — the actor provides necessary information regarding the new in- stance of the domain object.
• Request action (confirmation) — the system might ask the actor to confirm the oper- ation of creating the instance of the domain object.
• Validation action — the system might validate the data provided by the actor.
• System internal stage change action (store) — the system stores the instance of the domain object.
• Presentation action — a response message is presented to the actor.
Core actions:
! Provision action — it is not possible to create an object without providing the input
data.
4.2. Transfer (T)
Example: An example of a create transaction is presented in Figure 4.2. The presented use case consists of a single transaction, which goal is to add a comment to the system.
UC1: Add a comment Level: User
Primary actor: User Main scenario:
1. User chooses an option to add a comment.
2. System asks for the comment.
3. User provides the content of the comment.
4. System presents information that the comment was added.
Alternative scenarios and extensions:
Exceptions:
3.A. The content of the comment was not provided.
3.A.1. System displays an error message.
3.A.2. Go to step 2.
core action (provision action) request (choice of option)
presentation action
validation
Figure 4.2: An example of a use case with a create transaction.
4.2 T RANSFER (T)
Transfer transaction is a specific sub-type of create transaction. As a result of perform- Transfer transaction
ing the transfer transaction, a domain object is added to the system (the goal is the same as in the case of create transaction). The main difference in comparison to create transaction is that the input data does not have to come from the actor initiating the operation.
After the transfer operation is invoked, the data is exchanged between two or more actors (including the system under development). As a result the transferred objects that were maintained by external actors are also maintained by the system under development.
Primary intent: transfer domain objects from one actor to another one. After the objects are transferred they are managed by the receiver.
Typical flow of actions:
• Request action (choice of option) — typically, the actor that initiates the operation chooses an option to transfer some domain objects.
• Provision action (choice of object) — the initiating actor chooses domain objects to be transferred (for the “import operation” these objects should belong to external actors; for the export operation these objects should belong to the actor representing the system under development).
• Request action (confirmation) — the system may ask the actor to confirm the transfer operation.
• Presentation or transfer action — the domain objects are transferred either from the external actor to the SuD actor (“import operation”) or from the SuD actor to the external actors (“export operation”).
• System internal stage change action (store) — the receiver stores the the domain ob-
jects.
4.3. Retrieve (R)
• Presentation action — a response message is presented to the actor initiating the transfer operation.
Core actions:
! Provision (choice of domain object) — the actor has to select the domain objects to be transferred.
! Presentation or transfer action — the selected domain objects have to be transferred between actors. In a use-case scenario, it can be expressed either by presenting the data to the receiver, or by transfer action, which typically has the following pattern:
“<Actor X> transfers <domain object> to <Actor Y>.”
Example: An example of the transfer transaction is presented in Figure 4.3. The use case describes how an administrator of the Cinema Ticket System (CTS) can import movies from the Movies catalogue (some external actor). After movies are imported from the catalogue they are managed by the CTS system (e.g., tickets prices are defined later on).
UC2: Import descriptions of the movies to the Cinema Ticket System (CTS) Level: User
Primary actor: Administrator Secondary actors: Movies catalogue Main scenario:
1. Administrator chooses an option to import descriptions of the movies.
2. CTS asks Movies catalogue to provide a list of available movies.
3. Administrator chooses movies to be imported.
4. Movies catalogue sends descriptions of the movies to the CTS.
5. CTS stores information about the movies.
6. CTS informs Administrator that the movies were imported.
Alternative scenarios and extensions:
Exceptions:
4.A. Import operation failed.
4.A.1. System informs about the error during the import.
4.A.2. Use case finishes.
core action (choice of domain object)
core action (presentation or transfer action)
Figure 4.3: An example of a use case with a transfer transaction.
4.3 R ETRIEVE (R)
The goal of retrieve transaction is to provide a requested domain object to the actor Retrieve transaction
initiating the operation.
Primary intent: retrieve stored domain objects.
Typical flow of actions:
• Request action (choice of option) — this type of transaction is usually initiated by an actor that chooses an option to view a domain object.
• Presentation action — a response with the requested data is presented.
Core actions:
! Presentation action — a domain object has to be presented to the actor.
4.4. Dynamic Retrieve (DR)
Example: In the example of the retrieve transaction presented in Figure 4.4, the main intent of the primary actor is to read the comments.
UC3: Read comments Level: User
Primary actor: User Main scenario:
1. User chooses the option to view comments.
2. System presents the list of comments.
Alternative scenarios and extensions:
Exceptions:
core action (presentation) request (choice of option)
Figure 4.4: An example of a use case with a retrieve transaction.
4.4 D YNAMIC R ETRIEVE (DR)
The goal of dynamic-retrieve transaction is to provide the requested domain object(s) Dynamic retrieve transaction
that matches a dynamically specified criteria. The dynamically specified criteria are pro- vided explicitly by the actor. If search criteria are built-into the definition of a screen, the operation is treated as a regular retrieve transaction (e.g., a screen that presents all accepted applications—the query is built into the screen).
Primary intent: retrieve stored domain objects that matches dynamically-defined criteria.
Typical flow of actions:
• Request (choice of option) — this type of transaction is usually initiated by the actor that chooses an option to look for a domain object that satisfies certain criteria.
• Provision action — the actor provides the search criteria.
• Presentation action — the domain object(s) that matches the criteria is presented to the actor.
Core actions:
! Provision action — the actor has to provide the search criteria.
! Presentation action — a response (a domain object or a message) has to be presented to the actor.
Example: In the example of the dynamic-retrieve transaction presented in Figure 4.5, the primary actor would like to find and read an article that matches a given criteria.
4.5 A SYNCHRONOUS R ETRIEVE (AR)
The goal of asynchronous-retrieve transaction is to provide the data to the actor, how- Asynchronous retrieve transaction
ever, the data is not provided as a direct response. The data are accessed by the recipient later on.
Primary intent: retrieve stored domain objects for the later access by an external actor (retrieve is deferred in time).
Typical flow of actions:
4.6. Update (U)
UC4: Find an article Level: User
Primary actor: User Main scenario:
1. User chooses the option to find an article.
2. System ask the User to provide search criteria.
3. User provides search criteria.
4. System presents a list of articles that match the criteria.
Alternative scenarios and extensions:
Exceptions:
core action (provision) request (choice of option)
core action (presentation)
Figure 4.5: An example of a use case with a dynamic-retrieve transaction.
• Request action (choice of option) — this type of transaction is usually initiated by the actor (sender) that chooses an option to view a domain object later on, or to send an object to other actors (recipients), so they can view it later.
• Provision action — optionally some additional data can be provided by the sender (e.g., some comments to the message).
• Transfer action — the domain object is transferred to the recipient.
• Presentation action — a confirmation of delivery can be presented to the sender.
Core actions:
! Transfer action — the domain object has to be transferred to the recipient.
Example: In the example of the asynchronous-retrieve transaction presented in Figure 4.6, the primary actor would like to send an article as a newsletter.
UC5: Send a newsletter Level: User
Primary actor: Sender Secondary actors: Receiver Main scenario:
1. Sender chooses an article to be sent as a newsletter and the option to send it.
2. System sends the e-mail with the article to all receivers subscribed to the newsletter.
3. Receiver uses his/her e-mail client to view the newsletter message.
Alternative scenarios and extensions:
Exceptions:
core action (transfer) request (choice of option)
the object is not presented as a direct response
Figure 4.6: An example of a use case with an asynchronous-retrieve transaction.
4.6 U PDATE (U)
It is one of the most frequently occurring types of transactions (as it is one of the four Update transaction
CRUD transactions). The goal of an update transaction is to modify an instance of a do- main object.
Primary intent: modify an instance of a domain object.
4.7. Change State (CS)
Typical flow of actions:
• Request action (choice of option) — this type of transaction is usually initiated by the actor that chooses an option to modify a domain object.
• Presentation action — the system asks the actor to provide modified data of the object (update transaction can also be preceded by a retrieve transaction that presents the object).
• Provision action — the actor modifies the domain object.
• Request action (confirmation) — sometimes the system asks the actor to confirm the operation.
• Validation action — the system usually validates the data provided by the actor be- fore the modified version of the object is stored.
• System internal stage change action (store) — the system stores the modified version of the domain object.
• Presentation action — a response message is presented to the actor. For instance, the message that the object has been modified, or the modified version of the domain object itself.
Core actions:
! Provision action — it is not possible to modify a domain object without providing the data.
Example: An example of the update transaction is presented in Figure 4.7. The primary actor would like to modify an existing article. The update transaction is preceded by a retrieve transaction.
UC6: Edit an article Level: User
Primary actor: Author Main scenario:
1. Author chooses an article.
2. System presents the content of the article.
3. Author chooses the edit option.
4. System ask the Author to modify the article.
5. Author updates the article and confirms the operation.
6. System confirms modification of the article and presents its new version.
Alternative scenarios and extensions:
Exceptions:
5.A. Not all required data was provided.
5.A.1. System displays an error message.
5.A.2. Go to step 4.
core action (provision) request (choice of option)
presentation action validation
retrieve update
Figure 4.7: An example of a use case with an update transaction.
4.7 C HANGE S TATE (CS)
It is a special case of update transaction. Its goal is also to modify an instance of a do- Change state
transaction
4.8. Link (L)
main object. However, the changes that are made to the object affect its behavior in the system (as perceived from the user perspective). For instance, in a typical content manage- ment systems each article that is added to the system is not visible to the users until the editor changes its state from draft to published.
Primary intent: alter an instance of a domain object in order to influence its behavior in the system. For instance, an article in the CMS system needs to be published in order to be visible to all users.
Typical flow of actions:
• Provision action (choice of domain object) — typically a domain object, which state is going to be changed is selected by the actor.
• Request (choice of option) — the actor chooses an option to change the state of the domain object.
• System internal stage change — the system changes the state of the object.
• Presentation action — a response message is presented to the actor. For instance, a message that the state of the object was changed.
Core actions:
! Provision action — it is not possible to alter the state of an object without providing the input data.
Example: An example of the change-state transaction is presented in Figure 4.8. The pri- mary actor “Clerk" is processing applications. Firstly, the pending applications are re- trieved. This is an example of retrieve transaction (assuming that the viewing pending application is a meaningful goal of its own). Then, the actor chooses one of the applica- tions to be processed. This task is performed manually, outside of the system. Finally, Clerk changes the status of the application to “processed.”
UC7: Process application Level: User
Primary actor: Clerk Main scenario:
1. Clerk chooses an option to view pending applications.
2. System presents all the pending applications.
3. Clerk chooses the application that he/she wants to process.
4. Clerk processes the application (outside the system).
5. Clerk marks the application as processed.
6. System changes the status of the application to "processed."
7. System informs that the status of the application was changed.
Alternative scenarios and extensions:
Exceptions:
core action (provision)
system internal state change presentation action
retrieve change state provision (choice of domain object)
Figure 4.8: An example of a use case with a change of state transaction.
4.8 L INK (L)
The goal of this type of transaction is to associate instances of domain objects. However, Link
transaction
4.9. Delete (D)
these objects cannot be a part of the same composite.
∗An occurrence of the composition relationship between two domain objects o
iand o
jimplies that the object o
jis an attribute entity [IFP10] of the object o
i(o
jcannot exist independently). Therefore, the object o
jcould be transformed to a set of attributes of the object o
i.
The link transaction can exist on its own, when the operation of associating domain objects constitutes a meaningful goal for the actor on its own, or it can be a part of cre- ate or update transaction. If the linkage is done between objects belonging to the same composite, the transaction should be treated as a regular update.
Primary intent: associate two or more objects that are not a composite.
Typical flow of actions:
• Request action (choice of option) — typically the initiating actor chooses an option to associate domain objects.
• Provision action (choice of domain object) — the actor has to choose the domain object and all the other domain objects that are supposed to be associated with the first one.
• Request action (choice of option) — the actor has to initiate the linkage operation by choosing a proper option.
• Provision action — optionally an object containing additional information regarding the association might be created.
• Request action (confirmation) — the system may ask for the confirmation.
• System internal stage change action (store) — the system stores the association be- tween the domain objects.
• Presentation action — a response message is presented to the actor.
Core actions:
! Provision action (choice of domain object) — the actor has to select the first domain object.
! Provision action (choice of domain object) — the actor has to select the other domain object(s) to be associated with the first one.
Example: An example of the link transaction is presented in Figure 4.9. The primary actor
“Storekeeper” would like to assign products to shops were the products are available.
4.9 D ELETE (D)
The primary intent of delete transaction is to remove an existing domain object. Delete transaction
Primary intent: remove an instance of a domain object from the system.
Typical flow of actions:
• Provision action (choice of domain object) — the object to be removed is indicated. It can also be done by preceding retrieve transaction.
• Request action (choice of option) — the actor chooses an option to remove the do- main object.
∗
The composition relationship between domain objects is explained in Chapter 3.
4.9. Delete (D)
UC8: Assign products to shops Level: User
Primary actor: Storekeeper Main scenario:
1. Storekeeper chooses the products and the option to choose the shops where the products are available.
2. System presents a list of shops.
3. Storekeeper chooses the shops.
4. Storekeeper chooses the option to associate the products and shops.
5. System presents the products and the shops where the products can be purchased.
Alternative scenarios and extensions:
Exceptions:
core actions (choice of domain objects to be associated)
request (choice of option)
presentation action
Figure 4.9: An example of a use case with a link transaction.
• Request action (confirmation) — the system might ask the actor to confirm the oper- ation.
• System internal stage change action (remove) — the system removes the domain object.
• Presentation action — a response message is presented to the actor.
Core actions:
! Provision / request action (choice of domain object and option) — the actor provides the identifier of the object with the intent to remove it from the system. Alternatively the preceding retrieve transaction is used to indicate the object. This operation is followed by the choice of an option to remove the previously retrieved object.
Example: An example of a delete transaction is presented in Figure 4.10. The primary actor would like to delete an existing article. The delete transaction is preceded by the retrieve transaction, which indicates the object which is going to be removed from the system.
UC9: Delete an article Level: User
Primary actor: Author Main scenario:
1. Author chooses an article.
2. System presents the content of the article.
3. Author chooses the option to remove the article.
4. System asks Author to confirm removing the article.
5. Author confirms the operation.
6. System removes the article and informs the user about that fact.
Alternative scenarios and extensions:
Exceptions:
core action (request)
request (confirmation action)
presentation action system internal state change
retrieve delete
Figure 4.10: An example of a use case with a delete transaction.
4.10. Delete Link (DL)
4.10 D ELETE L INK (DL)
It is a special case of delete transaction. Instead of domain objects, the association Delete link transaction
between a set of domain objects is removed.
Primary intent: remove an association between domain objects.
Typical flow of actions:
• Provision action (choice of domain object) — the association to be removed is indi- cated.
• Request action (choice of option) — the actor chooses an option to remove association between domain objects.
• Request (confirmation action) — sometimes the system asks the actor to confirm the operation.
• System internal stage change (remove action) — the system removes the association between the objects.
• Presentation action — a response message is presented to the actor.
Core actions:
! Provision / request action (choice of domain object and option) — an actor chooses to remove the association between the domain objects. Such objects are usually in- dicated by a preceding retrieve transactions. Another possibility is that the actor indicates the object representing association with the intent of removing it from the system.
Example: An example of a delete-link transaction is presented in Figure 4.11. The primary actor would like to remove the association between the product and shops.
UC10: Remove association between products and shops Level: User
Primary actor: Storekeeper Main scenario:
1. Storekeeper chooses a product.
2. System presents the information about the product.
3. Storekeeper indicates the shops where the product is no longer available.
4. System removes the association between the product and shops.
5. System presents the updated information about the product.
Alternative scenarios and extensions:
Exceptions:
core action (provision)
presentation action
system internal state change retrieve delete link
Figure 4.11: An example of a use case with a delete-link transaction.
4.11 C OMPLEX I NTERNAL A CTIVITY (CIA)
The primary intent of CIA transaction is to invoke a complex processing and provide the results to the actor. This type of transaction is difficult to identify, because the com-
plexity of the business logic is usually not visible in use-case descriptions [AAR02]. Complex internal
21
4.12. Check Object (CO)
Primary intent: invoke a complex operation performed by the system (e.g., invoke a com- plex algorithm).
Typical flow of actions:
• Request action (choice of option) — typically an actor chooses an option to invoke the operation that involves complex processing.
• Provision action — the actor provides some additional parameters regarding the pro- cessing (it could be either a set of existing domain objects or a special algorithm-input object).
• Request action (confirmation) — the system may ask for the confirmation.
• System internal action (processing) — the system processes the input data (typically a set of domain objects).
• Presentation action — the results of processing are presented to the actor.
Core actions:
! Provision action — the actor has to determine the input of the processing.
! System internal processing action or request action (choice of option) — the intention of invoking a complex internal activity is either expressed by choosing an option (the actor chooses to invoke the processing) or directly by using the system internal processing action.
Example: An example of a CIA transaction is presented in Figure 4.12. The primary actor would like to solve a differential equation numerically.
UC11: Solve differential equation Level: User
Primary actor: User Main scenario:
1. User chooses the option to solve differential equation.
2. System asks for the equation to solve.
3. User provides the equation and confirms the operation.
4. System solves the equation.
5. System presents the solution of the equation.
Alternative scenarios and extensions:
Exceptions:
core action (provision)
core action
(intention of processing)
Figure 4.12: An example of a use case with a complex-internal-activity transaction.
4.12 C HECK O BJECT (CO)
The primary intent of check-object transaction is to validate a domain object against Check object transaction
some business rules. Transactions of this type are rarely observed, because the validation of data is usually included to other transactions, e.g., create, update, transfer (validation is not a primary intent in that case).
Primary intent: validate the data against some specified rules.
Typical flow of actions:
4.12. Check Object (CO)
• Request action (choice of option) — typically, an actor chooses an option to initiate the processing.
• Provision action (choice of domain object) — a domain object to be validated is pro- vided.
• Request action (confirmation) — sometimes the system asks the actor to confirm the operation.
• Validation action — the system validates the data provided by the actor.
• Presentation action — a response message is presented to the actor.
Core actions:
! Validation action — the system validates the data provided by the actor.
Example: An example of a check-object transaction is presented in Figure 4.13. It shows a typical example of the CO transaction which is the login to the system. The only goal of this operation is to check whether the username and password provided by the actor match the data stored by the system.
UC12: Login Level: User Primary actor: User Main scenario:
1. User chooses the option to login to the system.
2. System asks for credentials.
3. User provides the credentials.
4. System verifies the credentials.
5. System welcomes the user.
Alternative scenarios and extensions:
Exceptions:
4.A. Wrong username or password provided.
4.A.1. System informs about the wrong username or password.
4.A.2. Back to step 2.
core action (validation)
Figure 4.13: An example of a use case with a check-object transaction.
CHAPTER 5
Calculate Functional Size and Report Results
The functional size of a use-case transaction, expressed in the number of TTPoints, is defined as a product of the number of core actions, domain objects, and actors interacting with the SuD within the transaction. The functional size of an application is calculated according to Equation 5.1. (It can be measured for the whole system or any sub-set of its transactions.)
Functional_Size =
n
X
i=1
Core_Actions
i× Objects
i× Actors
i(5.1)
where
• n is the number of semantic transactions within the scope of the count;
• Core_Actions
iis the number of core actions of the i-th transaction (see Figure 5.1);
• Objects
iis the number of meaningful (independent) domain objects processed by the i -th transaction;
• Actors
iis the number of actors in the i-th transaction which cooperate with the sys- tem under development.
When calculating the functional size of a single transaction, one should consider only independent domain objects. Multiple instances of the same domain-object class should be counted as a single object.
When counting the number of actors, if there are two or more actors within the scope of a single transaction that are in generalization / specialization relationship, count only one actor for both of them.
The unit of the introduced FSM measure is called TTPoints. A typical transaction has
the functional size equal to 1 TTPoint (1 core action, 1 domain object, and 1 actor inter-
acting with the SuD). TTPoints measures functional size of a use-case transaction in thee-
Semantic transaction types
Create Update
Change State
Delete
Delete Link Asynchronous Retrieve
Dynamic Retrieve Retrieve
Link Transfer
Complex Internal Activity
Check Object
1 1 1 1 2 1
2 2
2 1 1 1
Figure 5.1: Semantic transaction-types with the number of core actions.
dimensions, therefore by analogy to the concept of physical volume, it can be interpreted
as a volume of use-case transaction.
CHAPTER 6
Example of TTPoints Application
An example of applying the TTPoints method to the measurement of the functional size of a single use case is presented in Figure 6.1.
UC1: Add a product category Level: User
Primary actor: Administrator Main scenario:
1. Administrator chooses an option to browse defined categories of products.
2. System presents all defined categories.
3. Administrator chooses an option to add a new category.
4. System asks for the data concerning the new category.
5. Administrator enters the data and confirms the operation.
6. System informs that the new category was added.
Alternative scenarios and extensions:
6.A. Administrator would like to associate the new category with some of the existing categories.
6.A.1. Administrator selects categories that are related to the added category and chooses the option to associate them.
6.A.2. System confirms that categories are now associated Exceptions:
5.A. Not all required data was provided 5.A.1. System informs about missing data.
5.A.2. Go back to step 4.
The TTPoints method:
1. Gather software requirements documentation.
- UC1: Add a product category 2. Identify actors
- Administrator
- System (it represents the system under development) 3. Identify domain objects
- category of products (new category, added category, existing category) 4. Identify transactions and determine their uniqueness
Retrieve (core actions = 1) - is unique Create (core actions = 1) - is unique Link (core actions = 2) - is unique 5. Calculate functional size
2 1
3
2
1 2 3
FunctionalSize = (1 x 1 x 1) + (1 x 1 x 1) + (2 x 1 x 1) = 4 TTPoints
