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 software 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 socalled 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 collections 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 iv
Contents 5 Calculate Functional Size and Report Results 24 6 Example of TTPoints Application 26 Bibliography 27 v
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. 1
CHAPTER 2 Overview of the Method 2.1 DETERMINATION 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 CHARACTERIZATION OF THE CONCEPT TO BE MEASURED The concept to be measured is the functional size of software application, which is defined 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 representation of Functional User Requirements). The three sub-concepts that seem to influence the complexity of a single semantic transaction 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 transaction. 2.3 META-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
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 application, which is a conceptual interface between the SuD and its users. Functional Requirements Semantic type (core actions) 1..* has defined as 1..* Use Case consists of 1..* 1..* Use-case transaction 1..* 1..* 1..* Actor / SuD 1..* cooperates within processes 1..* Domain object 1..* Figure 2.1: The meta-model illustrating the relationships across the concepts and subconcepts selected to characterize functional size of a system. 2.4 MEASUREMENT 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 transactions 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. 3
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. 4
CHAPTER 3 Identification of Domain Objects In order to calculate the value of TTPoints, one has to determine the number of domain 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 information 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. Section Paper Title Abstract 1 Author Person Name Surname E-mail Affiliation 1 1..* 1 3 4 5 1..* 1..* Editor 2 Content 1 1..* 1..* Proceedings Title Figure 3.1: An example of a domain model presented using the UML class diagram (class with 1 and without 2 attributes, aggregation 3, composition 4, generalization 5). 5
3.1. Relationships between domain objects 3.1 RELATIONSHIPS 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 generalization. 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 requires 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 terminal 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 DERIVING DOMAIN MODEL FROM USE CASES Even though, a complete domain model might not be available, some of the information 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 difficult, or even impossible due to the incompleteness of information. Therefore, we will 6
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 processing (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 7
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. paper option to submit a paper submission form necessary information about the paper paper option to re-submit one of his/her papers list of Author's papers option to re-submit the paper required data error message 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 optionally 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 object. 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 8
3.2. Deriving domain model from use cases Name Person Name Surname E-mail Affiliation? Person Surname E-mail Affiliation 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 business 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 9
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 compound 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. Unfortunately, some of the relationships could not be identified based only on the NPs. (However, 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 aggregates 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. 10
CHAPTER 4 Identification of Use-Case Transactions The most important step of the TTPoints method is the identification of use-case transactions, 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 application being sized in a consistent state. There are 12 semantic types of such transactions, presented in Figure 4.1. Each transaction 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 functionality are rejected from the further analysis. 11
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 Delete Retrieve Complex Internal Activity Check Object Transfer Link Change State Delete Link Asynchronous Retrieve Dynamic Retrieve Figure 4.1: Semantic transaction-types. In the following Sections 4.1 4.12, a catalogue of semantic transaction-types is presented. 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 CREATE (C) Create transaction is one of the most commonly appearing transaction in the requirements 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 instance of the domain object. Request action (confirmation) the system might ask the actor to confirm the operation 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. Create transaction 12
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 request (choice of option) Main scenario: 1. User chooses an option to add a comment. 2. System asks for the comment. core action (provision action) 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. presentation action validation Figure 4.2: An example of a use case with a create transaction. 4.2 TRANSFER (T) Transfer transaction is a specific sub-type of create transaction. As a result of perform- 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 objects. Transfer transaction 13
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 RETRIEVE (R) The goal of retrieve transaction is to provide a requested domain object to the actor 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. Retrieve transaction Core actions:! Presentation action a domain object has to be presented to the actor. 14
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: request (choice of option) core action (presentation) Exceptions: Figure 4.4: An example of a use case with a retrieve transaction. 4.4 DYNAMIC RETRIEVE (DR) The goal of dynamic-retrieve transaction is to provide the requested domain object(s) that matches a dynamically specified criteria. The dynamically specified criteria are provided 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. Dynamic retrieve transaction 4.5 ASYNCHRONOUS RETRIEVE (AR) The goal of asynchronous-retrieve transaction is to provide the data to the actor, however, 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: Asynchronous retrieve transaction 15
4.6. Update (U) UC4: Find an article Level: User Primary actor: User request (choice of option) Main scenario: 1. User chooses the option to find an article. 2. System ask the User to provide search criteria. core action (provision) 3. User provides search criteria. 4. System presents a list of articles that match the criteria. Alternative scenarios and extensions: Exceptions: 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 request (choice of option) 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: core action (transfer) Exceptions: 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 UPDATE (U) It is one of the most frequently occurring types of transactions (as it is one of the four CRUD transactions). The goal of an update transaction is to modify an instance of a domain object. Primary intent: modify an instance of a domain object. Update transaction 16
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 before 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. request (choice of option) update 4. System ask the Author to modify the article. 5. Author updates the article and confirms the operation. core action (provision) 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. presentation action validation retrieve Figure 4.7: An example of a use case with an update transaction. 4.7 CHANGE STATE (CS) It is a special case of update transaction. Its goal is also to modify an instance of a do- 17 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 management 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 primary actor Clerk" is processing applications. Firstly, the pending applications are retrieved. 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 applications 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 provision (choice of domain object) Primary actor: Clerk Main scenario: 1. Clerk chooses an option to view pending applications. 2. System presents all the pending applications. retrieve 3. Clerk chooses the application that he/she wants to process. change state 4. Clerk processes the application (outside the system). 5. Clerk marks the application as processed. core action (provision) 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: system internal state change Exceptions: presentation action Figure 4.8: An example of a use case with a change of state transaction. 4.8 LINK (L) The goal of this type of transaction is to associate instances of domain objects. However, 18 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 i and o j implies that the object o j is an attribute entity [IFP10] of the object o i (o j cannot exist independently). Therefore, the object o j could 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 create 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 between 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 DELETE (D) The primary intent of delete transaction is to remove an existing domain object. 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 domain object. Delete transaction The composition relationship between domain objects is explained in Chapter 3. 19
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: request (choice of option) core actions (choice of domain objects to be associated) 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 operation. 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. delete 4. System asks Author to confirm removing the article. 5. Author confirms the operation. request (confirmation action) 6. System removes the article and informs the user about that fact. Alternative scenarios and extensions: Exceptions: core action (request) system internal state change presentation action retrieve Figure 4.10: An example of a use case with a delete transaction. 20
4.10. Delete Link (DL) 4.10 DELETE LINK (DL) It is a special case of delete transaction. Instead of domain objects, the association Delete link between a set of domain objects is removed. transaction Primary intent: remove an association between domain objects. Typical flow of actions: Provision action (choice of domain object) the association to be removed is indicated. 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 indicated 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. core action (provision) retrieve 3. Storekeeper indicates the shops where the product is no longer available. delete link 4. System removes the association between the product and shops. 5. System presents the updated information about the product. system internal state change Alternative scenarios and extensions: presentation action Exceptions: Figure 4.11: An example of a use case with a delete-link transaction. 4.11 COMPLEX INTERNAL ACTIVITY (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 complexity of the business logic is usually not visible in use-case descriptions [AAR02]. 21 Complex internal activity transaction
4.12. Check Object (CO) Primary intent: invoke a complex operation performed by the system (e.g., invoke a complex 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 processing (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 CHECK OBJECT (CO) The primary intent of check-object transaction is to validate a domain object against 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: Check object transaction 22
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 provided. 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. core action (validation) 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. Figure 4.13: An example of a use case with a check-object transaction. 23
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 = where n Core_Actions i Objects i Actors i (5.1) i=1 n is the number of semantic transactions within the scope of the count; Core_Actions i is the number of core actions of the i-th transaction (see Figure 5.1); Objects i is the number of meaningful (independent) domain objects processed by the i-th transaction; Actors i is the number of actors in the i-th transaction which cooperate with the system 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 interacting with the SuD). TTPoints measures functional size of a use-case transaction in thee- 24
Semantic transaction types Create Update Delete Retrieve 1 1 1 1 Complex Internal Activity 2 Check Object 1 Transfer Link Change State Delete Link Asynchronous Retrieve 2 2 1 1 1 Dynamic Retrieve 2 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. 25
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. 1 2 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 3 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. 2 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 1 Retrieve (core actions = 1) - is unique 2 Create (core actions = 1) - is unique 3 Link (core actions = 2) - is unique 5. Calculate functional size FunctionalSize = (1 x 1 x 1) + (1 x 1 x 1) + (2 x 1 x 1) = 4 TTPoints Figure 6.1: An example presenting the application of the TTPoints method. 26
Bibliography [AAR02] B. Anda, E. Angelvik, and K. Ribu. Improving estimation practices by applying use case models. In PROFES, volume 2559 of Lecture Notes in Computer Science, pages 383 397. Springer, 2002. [Coc01] A. Cockburn. Writing Effective Use Cases. Addison-Wesley Boston, 2001. [Die06] S. Diev. Software estimation in the maintenance context. ACM SIGSOFT Software Engineering Notes, 31(2):1 8, 2006. [dmmm06] Marie-Catherine de Marneffe, B. MacCartney, and Ch. D. Manning. Generating typed dependency parses from phrase structure parses. In Proceedings of the EACL workshop on Linguistically Interpreted Corpora (LINC), 2006. [IFP10] IFPUG. IFPUG 4.3.1 Function Point Counting Practices Manual, 2010. [ISO07] ISO/IEC. Information technology Software measurement Functional size measurement Part 1: Definition of concepts, 2007. [LDP04] K. Li, RG Dewar, and RJ Pooley. Requirements capture in natural language problem statements. Technical Report HW-MACS-TR-0023, Heriot Watt University, 2004. [Lia03] Y. Liang. From use cases to classes: a way of building object model with UML. Information and Software Technology, 45(2):83 93, 2003. [OAJN11] Mirosław Ochodek, Bartosz Alchimowicz, Jakub Jurkiewicz, and Jerzy Nawrocki. Improving the reliability of transaction identification in use cases. Information and Software Technology, 53(8):885 897, 2011. [Och10] Mirosław Ochodek. RA 04/10: Constructing Partial Domain-Models for Functional Size Measurement with TTPoints. Technical report, Poznan University of Technology, Institute of Computing Science, 2010. [Och11] Mirosław Ochodek. Empirical Examination of Use Case Points. PhD thesis, Poznań University of Technology, Poznań, Poland, 2011. [OMG10] OMG. OMG Unified Modeling Language TM (OMG UML), superstructure, version 2.3, May 2010. [ONK11] M. Ochodek, J. Nawrocki, and K. Kwarciak. Simplifying effort estimation based on Use Case Points. Information and Software Technology, 53(3):200 213, 2011. 27