Event-driven software systems continuously wait for occurrence of some external or internal events. When such event is received and recognized, the system reacts by performing corresponding computations which may include generation of events that trigger computation in other components. After the event handling operation is complete the system returns to the waiting state for the next event occurrence. The response to the received event depends on the current state of the system and underlying objects and can include a change of state leading to a state transition. The state changes and transitions within a system can be formally analyzed by using functional characteristics of Topological Functioning Model (TFM). TFM captures system functioning specification in the form of topological space consisting of functional features and cause-and-effect (i.e. topological) relations among them and is represented in a form of directed graph. The functional features together with topological relationships contain the necessary information to create State diagram which reflects the state changes within system.
The behavior of an object over time could be surmised by analyzing system use-case
descriptions, activity diagrams, or other software design artifact. To avoid surmising
the state change of objects in system, a State diagram is used [
Despite the presence of UML and a number of software development methods, the
way the software is built still remains surprisingly primitive (by meaning that major
software applications are cancelled, overrun their budgets and schedules, and often
have hazardously bad quality levels when released) [
By having too fuzzy beginning of the software development and lacking a good
structure of it, the elimination of gap between computation independent viewpoint and
the platform independent viewpoint depends much on designers’ personal experience
and knowledge (both viewpoints mentioned in the context of Model Driven
Architecture – MDA [
The purpose of this research is to strengthen the TopUML modeling with formal development of State diagram thus enabling transformation from TFM to it and eliminating the gap between problem domain model and software design (solution) model. Thus the paper is organized into following sections. Section 1 discusses the UML modeling driven methods that supports analysis of object state transitions and composition of corresponding State diagrams. Section 2 explores TopUML modeling and the prerequisites that should be satisfied in order to formally develop State diagrams in strong relevance with the problem domain. This section gives the formal method of developing State diagram based on TFM, i.e., the TFM to State diagram transformation pattern. Section 3 shows an example of using functional characteristics to analyze state changes of objects based on enterprise data synchronization system. Paper is concluded with conclusions of the performed research.
UML is a notation and as such its specification does not contain any guidelines of
software development process (e.g., which diagrams to use in which order). In fact this
is pointed out as one of the UML weaknesses [
According to [
Solution should have a strong architectural vision, and
A well-managed development lifecycle should be used.
Above mentioned three statements regarding application of State diagrams raise a
set of ambiguousness and questions. The Use cases cannot be considered as a complete
problem domain representation and a formal connection between problem domain and
the solution [
How to formally eliminate and overcome the gap between problem domain model and the design models?, and
What are “most important objects” and how to formally identify them? To overcome these issues the TopUML modeling is applied within software development as described in the next section.
State diagrams within Unified software development process [
Business Object-Oriented Modeling (B.O.O.M.) developed by Podeswa [
According to GRASP patterns (General Responsibility Assignment Software
Pattern) introduced by Larman in [
Conceptual modeling described in [
State diagrams within Component based development are used to determine
the threads of control within the system [
The reviewed methods share common viewpoint of the application of State diagrams within software development process:
State diagrams are developed by analyzing Use cases (more precisely: the scenario described by it), One state diagram per class or object, and State diagram should be developed for each most important object within the system.
This section discusses the current state of the art of UML based software development approaches by paying attention on one aspect – support of analysis for object state changes and transitions: • • • • • • • • • • • •
The object state change and transition analysis by using functional characteristics of
problem domain is based on TopUML modeling, which is a model-driven approach
intended to model problem domain and design software systems [
The application of TopUML modeling ensures proper analysis of system
functioning by identifying and analyzing the functioning cycles. By using TopUML the
information of system functioning from TFM can be transferred to design models thus
allowing marking and evaluating the most important objects and components within
system and to assign proper responsibilities to the right objects in a formal way. The
most important objects are the ones that are participating in the main functioning cycle
of the system. The main functional cycle is a directed closed loop that shows the
functionality of system which is essential to its existence. By interrupting the main
functional cycle the system cannot function or even exist. [
In the context of state change analysis of objects the following TopUML modeling activities should be performed: • TFM development (see Section 2.1 below), • Domain model analysis and design (see Section 2.2), and • Object state change and transition analysis (see Section 2.3).
The development of TFM consists of four steps. By completing these steps a TFM representing complete functioning of the problem domain gets developed. Afterwards the TFM is used as a source for development of other diagrams thus overcoming the gap between problem and solution domains. The four steps of TFM development are as follows:
consists of the following activities [
Definition of objects and their properties from the problem domain description; Identification of external systems and partially-dependent systems; and Definition of functional features using verb analysis in the problem domain description, i.e., by finding meaningful verbs.
As a result a set of functional features are defined. Each functional feature Xid is a
unique tuple specifying an action in problem and solution domains [
Xid = <Id, A, Op, R, O, Cl, St, PrCond, PostCond, E, Es, S>, where (1) • Id – identifier of functional feature, • A – action of object O, • Op – operation which will provide functionality defined by action A (can be acquired when the class diagram is synthesized), • R – result of action A (optional), • O – object that receives the result or that is used in action A (for example, a role, a time period, a catalogue, etc.), • Cl – class which will represent object O in static viewpoint of system (can be acquired when the class diagram is synthesized), • St – new state of object O after performing action A (optional), • PrCond – is a set of preconditions (optional), • PostCond – is a set of postconditions (optional), • E – entity responsible for performing action A, • Es – indicates if execution of action A could be automated (i.e., performed without human interaction), and • S – subordination of functional feature (can be internal or external).
At the lowest abstraction level one functional feature describes only one atomic action. Atomic action means that it cannot be further divided into a set of business actions. The functional features are represented as vertices in a directed graph of TFM.
Step 2: Introduction of topology Θ (in other words – creation of topological space) which involves establishing cause-and-effect relations between identified functional features. Cause-and-effect relations are represented as arcs of a directed graph that are oriented from a cause vertex to an effect vertex. Topological space represents the system under consideration together with the environment in which this system exists.
the closure operation over a set of system’s inner functional features [
Step 4: Identification of logical relations between cause-and-effect relationships consists of two steps since there are two kinds of logical relationships – one kind is between arcs that are outgoing from functional features and the other kind is between arcs that are incoming to functional features. Thus the identification of logical relations consists of two actions: 1. Identification of logical relations between cause-and-effect relationships that are outgoing from functional feature, and 2. Identification of logical relations between cause-and-effect relationships that are incoming to functional feature. Logical relation OR between incoming arcs of functional feature 3 Logical relation XOR between outgoing arcs of functional feature 8 2 9
OR 10 XOR 8 3 4 7
AND
Each logical relation consists of two or more cause-and-effect relationships and a relation type. Within TFM can be defined three types of logical relations: • • •
Conjunction (and), Disjunction (or), and
Exclusive disjunction (xor).
An example of TFM consisting of nine functional features, nine topological (i.e., cause-and-effect) relationships and three logical relations is given below in Figure 1.
This section discusses the mappings between elements of TFM and State diagram.
The mappings between standard UML diagrams can be found in various books and
researches, like [
When information from input functional feature is transformed into a state, an initial state is added before this state.
When information from output functional feature is transformed into a state, a final state is added after this state.
If during execution of action specified by functional feature is changed the state of object performing this action then incoming topological relationship defines transition from previous state to the new state.
Each functional feature specifies an atomic business action which later is specified by topological operation in TFM. If functional feature specifies the new state of object, the operation is transformed into the event triggering transition from one state to another.
If current functional feature specifies the new state of object, the operation is transformed into the entry effect of this new state. TFM element Preconditions of functional features (PrCond and PostCond (1)) Logical relationship with type “and” (and partially “or”)
State diagram
element Exit effect Guard condition Fork and Join If descendant functional feature specifies the new state of object, the operation of this descendant functional feature is transformed into the exit effect of current state.
If current functional feature specifies the new state of object, the preconditions of this functional feature are transformed into the guard conditions.
A logical relation in TFM give additional information about execution concurrency of functional features, thus conjunction (and) within State diagram is represented with fork and corresponding join. Disjunction (or) indicates of possible fork and join.
Domain model analysis and design within TopUML modeling is based on the Topological class diagram and consists of the following two steps:
Step 1: Analysis of objects and their communication is based on the TFM
transformation into Communication diagram (in previous researches the Problem
domain objects graph was use instead of Communication diagram [
In order to obtain a Communication diagram, it is necessary to check if each functional feature of the TFM reflects only one type of object. If some of functional feature reflects more than one type of object then it is needed to decompose it to the level where one functional feature uses only one type of objects. If TFM has been successfully checked it can be transformed into Communication diagram. The first step in transformation is to merge functional features with objects of the same type in one lifeline (the lifeline represents the class attribute of the functional feature). While merging functional features into lifelines the relationships with other lifelines should be retained (if there is more than one topological relationship then only one link is added between lifelines). Actors to Communication diagram are added from the input functional features.
For a better understanding of TFM to Communication diagram transformation, a small fragment of TFM consisting of two functional features A and B is used (see Figure 2), where A is an input functional feature of TFM and dashed arrows show mappings between elements of TFM and Communication diagram. Fragment of TFM
Fragment of Communication diagram
Step 2: Domain model development by means of Topological class diagram consists of four activities: 1. Adding classes and operations, 2. Adding topological relationships between classes, 3. Identifying attributes, and 4. Refining initial Topological class diagram.
At first the Communication diagram is used for adding classes and operations to the Topological class diagram – lifelines are transformed into classes and messages into operations. The next step is adding topological relationships between classes. Since the notation of Topological class diagram allows variations of topological relationship graphical representation, it is advised to draw only one directed arrow in the same direction between classes (the arrow will show the cause and the effect operations).
After the classes and topological relationships between them have been established
the next step is identification of attributes. This can be achieved by taking into
consideration attributes of the object represented by functional feature. If the functional
feature is well specified the class attribute of it is determined. If the class attribute is
not determined, it can be specified in several ways (e.g. by analyzing functioning
description of the system and searching nouns that represents attributes of the object
[
By transforming Communication diagram an initial Topological class diagram is
obtained (with attributes, operations, and topological relations between classes). A
topological relation shows the control flow within the system. If static relations should
be included (such as associations, generalization, etc.) then initial topological class
diagram should be refined [
Object state change and transition analysis is based on the TFM transformation into a set of State diagrams (see Figure 3). The input of this activity is refined TFM and classes (either from Topological class diagram or lifelines from Communication diagram) and the output of this activity is one State diagram for each class.
Each functional feature specifies an object performing certain action. The count of
obtained State diagrams is denoted by count of distinct objects specified by functional
features. It is advised to analyze state changes of complex or most important objects in
the system [
The first action is to scale down TFM which is performed by removing functional features which does not represent the object under consideration but in the same time retaining cause-and-effect relations. For example, assume that TFM consists of three functional features A, B, and C and are in the following causal chain: A→ B→C. The A and C represent the same object while B represents another object. The resulting (scaled down) TFM is as follows: A→C.
States for each class are obtained from the functional features of refined TFM (functional feature has an attribute that defines the new state of the object). If the execution of functional feature involves the change of the corresponding object’s state, then the state attribute has value, otherwise the value is not set. State transitions are obtained by transforming cause-and-effect relationship between functional features.
The special states (initial state and final state) are added to the obtained State diagram as follows: • The initial state is added before the states that are obtained from the functional features which are the inputs of the downscaled TFM (the ones which has no predecessors), and • The final state is added after the states that are obtained from the functional features which are the outputs of the downscaled TFM (the ones which has no descendants).
The example of transforming generic example of TFM into State diagram is given in Figure 4.
Fragment of TFM Fragment of State diagram
St = «New» O = «CardRequest» State specification: Name = A.St Entry effect = A.Op Exit effect = B.Op
A New
St = «Completed»
O = «CardRequest» C
Completed Transition specification: Source state = A.St Event trigger = B.Op Guard condition = B.PrCond Target state = B.St
State specification: Name = B.St Entry effect = B.Op Exit effect = Ø
Example of object state change and transition analysis by using functional
characteristics of problem domain is based on a case study in which TFM is developed
for enterprise data synchronization system. The enterprise data synchronization system
is developed by applying TopUML modeling and involves creation of TFM, Use case
diagram, Problem domain objects graph (applied instead of Communication diagram),
Topological class diagrams, and Sequence diagrams [
Within the case study have been defined 30 functional features by analyzing functioning of enterprise data synchronization system. Part of defined functional features is given in Table 2 where are included features that specify the new state for object named “Scheduler”. After definition of functional features the topology Θ (cause-and-effect relationships) is identified between those functional features thus creating topological space. In order to get the TFM the closuring operation is applied over the set of internal system functional features. The developed TFM after applying closuring operation is as follows: X={2, 3, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 19, 20, 22, 24, 25, 26, 27, 28, 29}. The resulting graph is given in Figure 5 (a) which shows functional features (vertices), cause-and-effect relationships (arcs between vertices).
The example of object state change analysis in the context of enterprise data synchronization system development case study is performed for the object name “Scheduler”. The functional features specification in Table 2 shows that this object in total has five different states: 1) Reading data, 2) Checking data, 3) Importing, 4) Logging status, and 5) Completing import. The resulting State diagram is given in Figure 5 (b).
Precondition (PrCond) If import should be performed from source data base If data structure is according to specification If import file structure is according to specification If data completed import is
Scheduler Object (O) Scheduler
New state (St)
Reading data Scheduler Scheduler Scheduler Scheduler Scheduler Scheduler Scheduler Scheduler
Reading data
The main goal of this research is to do formal development of State diagram by analyzing functional characteristics of a problem domain. The result of research is method for transforming TFM into State diagram thus eliminating the gap between problem domain model and software design (solution) model.
UML modeling driven methods (like Unified process, B.O.O.M. and patterns based software development) manifests that the State diagrams are developed by analyzing Use cases (more precisely: the scenario described by it), one state diagram per class or object. In fact they say that State diagram should be developed for each most important object within the system. These statements raise a set of ambiguousness and questions. The Use cases cannot be considered as a complete problem domain representation and a formal connection between problem domain and the proposed solution. The application of Use cases to develop diagrams of other types (such as State diagram) depends much on the designers’ personal experience and knowledge.
The elaborated TopUML modeling (including the State diagram development) proposes a way on how to formally overcome the gap between problem domain and solution domain – the first one is represented by TFM which shows the complete functioning of a problem domain and the latter one is obtained by transforming TFM of a problem domain. Moreover the TopUML enables formal identification of the most important objects and classes within system – they are denoted by TFM: functional features that are included into main functional cycle specify these objects and classes. In contrast, the reviewed UML modeling driven methods relies that the designers’ personal experience and knowledge is sufficient to identify most important objects within system. In addition the example described in paper shows State diagram development for the case study in which enterprise data synchronization system has been developed by using TopUML modeling.
This research shows that by adding additional efforts at the very beginning of software development life cycle it is possible to create a model that contains sufficient and accurate information of problem domain. By “sufficient” meaning that this model can be transformed into other diagrams without major re-analysis of problem domain and by “accurate” meaning that the model precisely reflects the functioning and structure of the system.
This work has been supported by the European Social Fund within the project “Support for the implementation of doctoral studies at Riga Technical University”.