The Consistency Verification Between Uml Activity

Published Date: 02 Nov 2017

and Component Diagrams:

INTRODUCTION

UML has been established as a standard notation to model software during the various phases of the software development life cycle. Thanks to its various diagrams, UML provides for a multi-view representation of both user functional requirements and system structure and dynamic behavior. Nonetheless, the diversity of UML diagrams can introduce inconsistencies among the various diagrams representing the same system. Evidently, these inconsistencies may lead to errors, high development costs, and potentially software failures.

To detect UML diagram inconsistencies, several approaches have been proposed either based on meta-modeling (Chong, 1999), or based on the adoption of formal methods (Sengupta, 2008). The first category of approaches examines only the syntactic constraints among the UML concepts; the second category relies on the semantic constraints among the UML concepts and requires a certain level of expertise in the formal method used. In addition, none of them provides for a means both to detect potential inconsistencies and to estimate "characteristics" of one diagram from another already elaborated. Such a means can be offered through a measurement method. In this paper, we illustrate the feasibility of such an approach by using the functional size of software.

In the software measurement literature, to measure the functional size of software applications, five measurements methods were recognized as standards: IFPUG (ISO, 2009), MKII (ISO, 2002), NESMA (ISO, 2005), FiSMA (ISO, 2008), and COSMIC (ISO, 2009). The main advantage of functional size measurement (FSM) is to quantify software from a user's view point independently of any quality and technical criteria. In addition, compared to other international measurement methods, COSMIC is designed to be applicable to any type of software. These advantages motivated several researchers to investigate the use of COSMIC to determine the functional size of UML-diagrams. These proposals focused on use case diagram (Sellami, 2009), (Lavazza, 2009), (Berg, 2005), (Azzouz, 2004), (Bévo, 1999), the sequence diagram (Sellami, 2009), (Lavazza, 2009), (Azzouz, 2004), (Bévo, 1999), activity diagram (Berg, 2005), class diagram (Sellami, 2009), (Lavazza, 2009), (Bévo, 1999), and component diagram (Lind, 2011), (Lavazza, 2009). Except for (Sellami, 2009) and recently (Lind, 2011), these proposals treated UML diagrams in an isolated way. In addition, the UML-Activity Diagram (UML-AD) has not been explored in detail, despite its importance in representing behavioral aspects of software. Similarly, the UML-Component Diagram (UML-CD) has not been treated in spite of its advantage to component reuse especially in the development of complex applications.

This paper has a two-fold contribution. First, it completes our previous work using COSMIC FSM to measure UML-AD and UML-CD. Secondly, it proposes a heuristic that provides for both verifying the consistency of these diagrams in terms of functional size, and estimating a bound on the functional size of one diagram from a developed diagram.

The remainder of this paper is organized as follows: Section 2 presents an overview of the COSMIC method and studies dealing with FSM of UML diagrams. Section 3 and 4 present, respectively, the proposed measurement procedure required for measuring the functional size of UML-AD and UML-CD. Section 5, first, defines some correspondence rules between UML-AD and UML-CD ensuring the consistency between these diagrams; secondly, it illustrates the application of these measurement procedures by using the "Rice Cooker" case study (COSMIC Group, 2008). Finally, Section 6 summarizes the presented work and some suggestions for further works.

RELATED WORKS

Overview of COSMIC FSM

COSMIC have been widely used in order to measure software functional size, which is derived by quantifying the Functional User Requirements (FUR) (ISO, 1998). FUR is a sub-set of the user requirements, that explains what the software have to do to satisfy users needs. COSMIC is developed to overcome limitations of initial FSM methods such as Function Point Analysis. It is designed to be used to measure functional size of real-time software, business application software, etc. It has been accepted as an international standard ISO/IEC 19761 since 2003. The COSMIC measurement procedure includes three phases: measurement strategy, mapping, and the measurement.

As it can be seen in Figure 1, COSMIC covers four types of data movement (Entry, Exit, Read, and Write). The exchange of data across the boundary between users and software components causes an Entry data movement type (E: from a functional user to the functional process), or an Exit data movement type (X: from a functional process to the functional user). On the other hand, the exchange of data between storage hardware and software component causes a Read data movement type (R: from a persistent storage to the functional process), or a Write data movement type (W: from a functional process to the persistent storage).

C:\Users\MERIAM\Desktop\Capture.PNG

Figure : Different data movement types in COSMIC

In the COSMIC measurement phase, every data movement is assigned to 1 CFP (Cosmic Function Point). Software functional size is provided by adding all data movements identified for every functional process (ISO, 2009).

COSMIC for UML

Among the researchers that studied the use of COSMIC to measure functional size of UML, (Bévo, 1999) investigated the mapping between concepts of COSMIC 2.0 and those of UML 1.0. Their investigation was presented through the FSM of a building access system modeled with the use case, sequence and class diagrams. Being presented through an example, it lacked the coverage of some concepts like the triggering event which enduces one CFP. This study reports the issue of identifying the appropriate UML concepts to represent the COSMIC functional process, and then identifying the appropriate level of granularity.

(Azzouz, 2004) also treated the UML use case, sequence and class diagrams. They proposed an automated functional size measurement procedure of these diagrams when developed according to the Rational Unified Process. Their tool, COSMIC-RUP, is integrated in Rational Rose. It was ued to measure the functional size of two case studies "Rice Cooker" (COSMIC Group, 2008) and "Valve Control" (COSMIC Group, 2006). However, the results obtained by COSMIC-RUP tool differ from (1 CFP) compared to those obtained by a manual calculation for each case study. Furthermore, the proposed measurement procedure does not account for the "system layers" concept which is important to identify functional process.

On the other hand, (Berg, 2005) showed that UML can be used to present FUR at four levels of refinement: Goal-level requirements, Domain-level requirements, Product-level requirements, Design-level requirements. In every level, they assume that particular UML diagrams are used to model the software. In addition, (Berg, 2005) also showed that the functional size can be determined using measurement methods such as Function Point Analysis (FPA) and COSMIC-Full Function Points (COSMIC-FFP) in the third level. In this level, they used the use case diagram, activity diagram and class diagram. The proposed measurement approach is illustrated through a case study (The Hotel Case). Despite being the only study treating UML-AD to model the behavioral view of software, the provided measurement approach did not investiage several details of UML-AD.

(Lavazza, 2009) studied the functional size measurement of the UML use case, sequence, and component diagrams by using COSMIC. Similar to the previous works, their measurement process relies on a mapping of the COSMIC concepts onto the UML diagram concepts. It was illustrated through the FSM of the "Rice Cooker" real time software. However, the UML-AD of the "Rice Cooker" as not measured despite its usefulness in representing system details and interactions between the system and its actors.

Unlike the above works, (Sellami, 2009) considered that the semantic link between the various UML diagrams of a system model must be respected in any measurement process. They presented an approach to measure the functional size of the UML use case diagrams. In this work, the functional size of the use case diagram is used as a reference measurement for the sequence and class diagrams. To overcome the high level of abstraction of the use case diagrams, the authors used an intuitive documentation of the use cases proposed by (Ali, 2006) The produced measurement can then be used to verify the consistency of the the use case diagram with the the functional size of the sequence diagrams. The proposed approach was verified using a business application (ALLOC).

Also exploring the semantic links among UML diagrams, (Lind, 2011) developed a tool "CompSize" to provide the functional size of the component diagram. For this, they extended UML-CD to represent necessary information. Their measurement process defines data movements independently of the software boundary, which may lead to incorrect results.

In summary, as shown in Table 1, most of the researches proposed mappings between COSMIC concepts and some UML diagrams. None of these studies considered all COSMIC concepts. In addition, further work is needed to explore the semantic links among UML diagrams to provide for a confrontation/estimation/consistency verification between the different diagrams modeling a system.

Table 1 : Summary of the proposals mapping COSMIC on UML

COSMIC concepts

(Lind,

2011)

(Sellami, 2009)

(Lavazza, 2009)

(Berg,

2005)

(Azzouz, 2004)

(Bévo, 1999)

Application border boundary

Component

Use cases

Sequence

Use Cases

Component

Use Cases

Use Cases

Use Cases

System layers

Component

None

None

None

None

None

Functional User

Component

Use Cases

Sequence

Use Cases

Component

Use Cases

Use Cases

Use Cases

Triggering event

None

Use Cases

Component

Activity

Sequence

Scenario

Data group

None

None

Component

Class

Class

Class

Class

Data attribute

None

None

None

None

Class

Class

Functional Process

Component

Use Cases

Sequence

Sequence

Use Cases

Activity

Use Cases

Use Cases

Data Movement

Component

Use Cases

Sequence

Class

Sequence

Activity

Sequence

None

MEASUring UML-AD

Modeling rules

To model an UML-AD that can be measured using COSMIC, we present 12 modeling rules. These rules are inspired from "good design practices" and are intended to eliminate certain inconstancies. The first three rules (R1, R2 and R3) are required to be applied at the functional level. The remaining rules (R4 to R12) are used at the dynamic level.

R1: Represent all system processes and the relationship between them at the functional-level.

R2: Any component or user that interacts in the realization of a process is considered as an actor in the UML-AD.

R3: If the activity requires incoming information or a condition that must be satisfied, it is considered as a pre-condition.

R4: Each functional process will be represented by an activity diagram.

R5: Each external actor (system user) is represented by a partition.

R6: Any internal actor is represented by a partition.

R7: All actions performed by the same actor are grouped in the same partition.

R8: Any action requires retrieved or written data from/to a persistent storage; it must be associated to an object node that contains the data to be used.

R9: Avoid the transitions between the actors and the system when they are intended to indicate a possible end of the functional process (failure or success).

R10: Every guard condition is considered as a trigger event of its corresponding action.

R11: Action data recovery and action of writing data are differentiated by the direction of the transition.

R12: If the action requires incoming information that must be satisfied, it is considered as a pre-condition.

Note that it is required to distinguish between external actor's partition and system’s partition (internal actor). This distinction can be indicated by a description of the actor's attribute.

Mapping COSMIC on UML-AD

Measuring the functional size of an UML-AD needs to define the mapping between COSMIC concepts and those of UML-AD. As listed in Table 2, the mapping deals with the identification of functional processes, data groups and data attributes.

FSM measurement formulas

In the functional level, an UML-AD (A) consists of a set of activities. Each activity is a functional process.

(1)

where:

FSM (A): functional size of the UML-AD (A).

n: the number of activities in (A) (1st level).

FSM (ai): functional size of the activity ai (2nd level).

In the dynamic level, an activity ai consists of a set of actions act ij. According to (Knieke, 2008) in this level, an activity is made by at least one action, an end node and an initial node.

Table 2: Mapping of COSMIC on UML-AD

Concepts of COSMIC V.3.0.1

UML-AD concepts

Functional User

Actor who interacts with the system

Boundary

Conceptual line between the system partition and actor partition

Functional Process

An executable activity node presented in the first level

Triggering Event

Pre-condition of an activity

Guard condition in a decision or a fusion node

Pre-condition of an action

Persistent Storage

Object node: Storage

Transient data group

Object node: Pins

Entry

An incoming data (from actor partition to system partition)

Exit

An outgoing data (from system partition to actor partition)

Read

Read access from an object node

Write

Write access to an object node

The functional size of an activity ai is given by:

(2)

where:

FSM (ai): functional size of the activity ai.

m: is the number of actions actij of the activity ai (2nd level).

FSM (actij): functional size of the action actij of the activity ai (2nd level). (3).

FSMcond (Precond ai): functional size of the pre-condition of the activity ai. (4).

The functional size of an action actij is given by:

(3)

where:

(4)

(5)

If an action is preceded by a decision or a fusion node, then the guard condition is considered as a trigger event. It is necessary to add 1 CFP to action's size.

(6)

When the end of an action in an Actor partition causes the execution of an action in a System partition, then the control flow corresponds to an Entry data movement. However, if the end of an action in a System partition causes the execution of an action in an Actor partition, then the control flow corresponds to an Exit data movement.

(7)

MEASURing UML-CD

Mapping COSMIC on UML-CD

Table 3 shows the mapping between concepts of COSMIC and those of UML-CD.

Table 3: Mapping between concepts of COSMIC and those of UML-CD

Concepts of COSMIC V.3.0.1

UML-CD concepts

Functional User

External entity directly connected with the system components.

Boundary

Frontier between external components and system components.

Functional Process

Operation in a system interface invoked directly by an external entity.

Triggering Event

Classes: physical components.

Persistent Storage

Data across the system boundary, interface's operations or parameter's operations.

Transient data group

Set of operations, in one or more interfaces, carrying out a process.

Entry

Operations in a required interface directly connected to the system.

Exit

Operations in a provided interface directly connected to the system.

Read

Get type operation in a system component.

Write

Set type operation in a system component.

FSM measurement formulas

Data movements in an UML-CD are represented by interface's operations across the boundary, and operations in a system component. The functional size of the UML-CD (C) is given by:

(8)

where:

FSM (C): functional size of the UML-CD (C).

FSM (Si): functional size of operations in a system component.

n: number of the system components.

FSM (Ij): functional size of required and provided interfaces.

m: number of the interfaces required and provided in (C).

The functional size of operations in a system component is given by:

(9)

where:

FSM (Si): functional size of operations in a system component.

y: number of operations in a component system. (i=1,...n)

FSMop (Opij): functional size of the operation Opij. (1CFP)

The functional size of required and provided interfaces is given by:

(10)

where:

FSM (Ij): functional size of required and provided interfaces.

k: number of operations in the interface Ij. (j=1,...m)

FSMop (Opji): functional size of the operation Opji.

Correspondence between UML-AD and UML-CD

Equation (11) can be used to verify the conformity between a UML-AD and a UML-CD in terms of COSMIC FSM:

(11)

The UML-AD is composed of at least one actor and a system, an initial node, an end node, and a set of actions. In the second level of abstraction, a UML-AD represents a functional process. Based on COSMIC concepts, a functional process is composed of two data movement (Entry and Exit or Write). Therefore, the FSM of a UML-AD is at least equal to 2 CFP, i.e. (FSM (A) ≥ 2 CFP). In the other hand, the FSM of an UML-CD is always less than the FSM of an UML-AD. Hence, FSM of an UML-CD is at least equal to 2 CFP. The maximum size of an UML-CD depends on the size of the UML-AD.

Equation (11) gives a confrontation means of both diagrams in terms of COSMIC FSM. Besides this high-level FSM boundary confrontation, we propose the following five rules to ensure the consistency in terms of COMIC FSM between UML-AD and UML-CD:

ConfR1: Any partition representing an actor in UML-AD is a component in the UML-CD.

ConfR2: Any action in a partition is represented by a method in an interface.

ConfR3: Input/output pins in the UML-AD correspond to the input/output parameter's operations in the UML-CD.

ConfR4: Object nodes in UML-AD are represented by class’s components in UML-CD.

ConfR5: Pre and post-conditions of an action in UML-AD correspond to pre and post-conditions of an operation in UML-CD.

Example: the Rice Cooker

To illustrate the application of the proposed FSM formula, we use the real time software application "Rice Cooker" case study. The FURs of this case study are described in (COSMIC Group, 2008). The question is how to determine the functional size of the three functional processes (FP1: Set Target Temperature, FP2: Adjust Temperature and FP3: Lamp Control) as described in (COSMIC Group, 2008). These processes are triggered by three events which are respectively:

Signal 30s: Every 30s software controller selects a new target temperature.

Signal 5s: Every 5s software controller must compare between the target temperature and actual temperature to control the heater.

Tick (elapsed): Every 1s the timer must issue the elapsed time since button START is turned on.

Figure 2 shows the activity diagram of the "Rice Cooker" application at a high level of abstraction.

Figure 2: UML-AD of the "Rice Cooker" application (high level of abstraction)

Figure 3 illustrate the UML-AD of the functional process "Set Target Temperature".

Figure 3: UML-AD of the "Set Target Temperature"

Table 3 presents in detail the measurement results of the UML-AD for the functional process (FP1). Due to space limitation, we will present only the measurement results for the others (FP2, FP3). Based on the component diagram of the "Rice Cooker" in (Lavazza, 2009), which includes three components and five interfaces, we will present the FSM results of the related UML-CD in Table 4.

Functional Process

Application of measurement formulas

(UML-AD)

FP1

FSM (FP1) = FSMcond(Signal 30s) +

(2)

FSMcond(Signal 30s)

(4)

FSM act1j =

(3)

(4)

(5)

(7)

FSM(Receive signal 30s) + FSM(Get cooking mode) + FSM(Get elapsed time) + FSM(Provide elapsed time) + FSM(Get cooking temp) + FSM(Set target temperature)

FP2

FSM (FP2) = FSMcond(Signal 5s) +

(2)

FP3

FSM (FP3) = FSMcond(Signal 1s) +

(2)

Total

(1)

Table 3: Measurement results (Activity diagram of the "Rice Cooker")

Table 4 : Measurements results (UML-CD of the "Rice Cooker")

Application of measurement formulas

(UML-CD)

FSM (C) =

(8)

FSM () = = FSM (GetMode(): Cooking_mode) + FSM (SetMode(mode:Cooking_mode))

(9)

FSM () = = FSM (GetCookingTemp (time: Integer, mode: Cooking_mode): Integer)

(9)

FSM () = = FSM (SetTargetTemp(temp)) + FSM (GetTargetTemp():Integer)

(9)

= = FSM (Signal 30()) + FSM (Signal 5()) + FSM (Tick(elapsed))

(10)

=

= FSM (ReadTemp () : Integer)

(10)

= = FSM (HeaterOn())

(10)

= = FSM (HeaterOff())

(10)

= = FSM (On())

(10)

According to equation (11), it can be ensured that the UML-AD design is conformed to the UML-CD design. In addition, assuming that the consistency rules are satisfied, the FSM difference between the UML-CD (12 CFP) and the UML-AD (14 CFP) can be justified by the difference in the levels of abstraction. Since UML-AD represents software at a detailed level of abstraction and UML-CD represents software at a high-level of abstraction, UML-CD cannot represent all software details as well as UML-AD. Looking closely, in the UML-AD FP2, the extra CFP is due to the guard conditions which are not represented in the UML-CD.

Compared to existing works, our measurement results are consistent with those of (Lavazza, 2009) and ensure the correctness of our measurement procedures. Albeit, it can appear that there are some distinctions in the FSM results. For instance, 14 CFP is obtained to UML-AD and 12 CFP to UML-CD of the "Rice Cooker" case study, while the FSM of the same case study obtained by (Lavazza, 2009) is equal to 11 CFP. This value is provided according to the identification of data movement involved in functional processes. It is independent of UML diagrams.

It can be observed that for UML-AD, there is an extra of 3 CFP for three "Exits". Because of the FP1 that contain the transition "Get elapsed time", it should be considered as a data movement type "Exit". However, (Lavazza, 2009) ignored this data movement. In FP2, the extra 2 CFP is due to: (i) the guard conditions which haven't been explored by (Lavazza, 2009) for both actions "Start heater" and "Stop heater". They considered the command "HeaterOn and HeaterOff" as 1 data movement "Exit". And, (ii) the action "Get Actual Temperature" was not identified by (Lavazza, 2009) since they considered the "Actual Temperature" to be returned by "Temperature Sensor" following the demand of "Software Controller".

For the UML-CD, the extra 1 CFP is due to the operation "SetMode(mod:Cooking_mode)". Indeed, this operation corresponds to another functional process (stop cooking). If we take into account the ‘scope’ according to COSMIC method, this operation will not be considered. In addition, our measuring scope is limited by the three functional processes (Set Target Temperature, Adjust Temperature and Lamp Control).

CONCLUSION

Applying COSMIC FSM method in design phase for checking consistency between activity diagram (UML-AD) and components diagram (UML-CD) is the main purpose of this paper. Functional size measurement procedures for UML-AD and UML-CD have been presented. These procedures have been defined based on the mapping between COSMIC concepts and those of UML diagrams concepts. We have proposed a measurement interval that it can be used as a guideline by designers and developers to verify consistency between UML-AD and UML-CD and identify modeling errors. We have also proposed a set of modeling rules to ensure the consistency between those diagrams. Finally, we have illustrated the proposed measurement procedures by using the "Rice Cooker" case study, and analyzed our measurement results with those of (Lavazza, 2009).

Further works including the use of measurement results of UML-AD and UML-CD should be investigated. These measures can also be helpful to software managers and leaders to complete their project within the scheduled dates. The proposed formulas need to be applied on more large case studies to ensure the quality of measurement results. Finally, implementation is also required not only to find faster the FSM of each UML diagram, but also alert users (developers, designers, etc.) with the presence of any modeling errors in the design phase.