Verification of UML Dynamic Specifications using Simulation-based
Timing Analysis
Sherif M. Yacoub, Alaa Ibrahim, and Hany H. Ammar
Khalid Lateef
Dept. of Computer Science and Electrical Engineering,
West Virginia University
Morgantown, WV26506-6109
{yacoub, ibrahim, ammar}@csee.wvu.edu
Averstar Inc.,
NASA IV&V Facility
100-University Drive, Fairmont, WV 26554
Khalid.Lateef@ivv.nasa.gov
Keywords: Timing Analysis, Verification and Validation, and the Unified Modeling Language.
Abstract
The Unified Modeling Language (UML) is the
result of the unification process of earlier object
oriented models and notations. Independent
verification and validation (IV&V) tasks, as applied
to UML specifications, enable early detection of
analysis and design flaws prior to implementation.
In this paper, we address an important IV&V task
that we perform on UML models, which is timing
analysis of UML dynamic specifications. We
discuss an approach for automatic generation of
timing diagrams from the simulation logs obtained
from simulating UML specifications. We develop
four timing analysis methods, namely; concurrencybased, environmental-interactions, timeouts-based,
and performance-based timing analysis methods. We
show results from applying the proposed timing
analysis methods to an illustrative example, a
pacemaker specification.
1. Introduction
Unified Modeling Language is becoming a
widely accepted industrial standard for modeling
software systems. The software development
industry is bracing this modeling language for
requirement analysis and the subsequent phases of
software development lifecycle. As a result,
Independent Verification and Validation (IV&V)
teams need to devise methods for evaluating UML
artifacts supplied by the developer teams. At present
mostly manual methods are being used to perform
analysis of UML models. Given the size and
complexity of the large software systems, the
manual efforts are time-consuming, tedious and
error prone.
IV&V teams being much smaller than
development teams must use efficient techniques to
perform their analysis. IV&V analysis can be
categorized as static or dynamic. Static analysis
helps IV&V teams in reviewing the structure of
UML models and generating metrics such as class
size, the size of hierarchy, and complexity measures.
The complex dynamic behavior of many
applications, especially real-time applications,
motivates a shift in interest from traditional static
analysis to dynamic analysis. Dynamic analysis is
performed to analyze the behavior of objects as
expected at run time.
In this paper, we discuss timing analysis as an
important IV&V task for real-time systems.
Temporal IV&V, timing analysis, and timing
diagrams are not part of UML v1.3 specifications,
however, it is necessary to verify and validate timing
constraints and to study the dynamic aspects of
UML models.
Although UML is a rich analysis and design
modeling language, it does not define how to study
the dynamic aspects of the models through
simulation; a capability that is required to monitor
the expected run-time behavior of software systems.
The Real-Time Object Oriented Modeling (ROOM)
[5] is introduced to study the dynamic aspects of
applications modeled as concurrently executing
objects with complex dynamic behavior. ROOM
models are intended for simulating the application
execution scenarios and complex object behavior.
Dynamic analysis can be conducted on executable
OO design models such as ROOM models, and
hence the dynamic behavior of applications can be
verified and assessed. Executable design models are
used to simulate real time applications and deduce
their real-time properties such as deadlines and
scheduling. The same models can be used to analyze
timing constraints prior to detailed implementation.
Verification can be conducted at various
development phases. Early verification of software
specification and analysis artifacts is encouraged
before large investment is made in development. We
perceive that verification and validation of UML
specifications can be done at an early development
phase - prior to implementation - using scenarios
and simulation models. To serve the dynamic
simulation and verification process of UML models,
Rational
Software
(www.rational.com),
the
originator of UML, is collaborating with ObjecTime
Limited (www.ObjecTime.com), the originator of
ROOM, on the definition of UML for Real-Time
[2]; an application of UML optimized for real-time
embedded software development. As a result of this
initiative, UML models and ROOM models are
integrated in one modeling and simulation
environment [4]. For this paper, we are interested in
verification and validation of UML specifications
through simulation of UML models using simulation
tool-support [4, 3].
In this paper, we define four timing analysis
methods that we can perform to verify and validate
UML timing specifications. We also describe the
procedure to perform the proposed timing analysis
methods on UML artifacts. We automated the
generation of timing diagrams from the log files
produced from simulating UML specifications. We
applied the timing analysis techniques that we
developed to a pacemaker example. We found some
timing problems in the UML models of the
pacemaker and we documented the results.
Section 2 discussed the proposed timing analysis
approach and methods. In section 3, we show some
results from applying the proposed approach to the
pacemaker example. Finally we conclude the paper
and discuss future research agenda in section 4.
2. The Timing Analysis Approach
The approach that we take is to simulate UML
specifications. Based on simulation logs, we develop
analysis methods and techniques to perform
verification of timing constraints.
2.1
The Proposed Approach
The following figure describes the overall
approach that we propose for timing analysis of
UML specifications.
Analyst
Simulation
Settings
(Timers, etc.)
UML
Simulation
Environment
Inspection
• Viewing
Macro
Simulation
Logs
Log Analysis
Tool
Timing
Diagram
UML
Model
• ObjecTime tool
• Text File
• Rose Real Time tool
• MS Excel
• Processing
Macro
• Formatted
Excel charts
Figure 1 A high level view of the proposed timing analysis
approach
The IV&V task is to verify timing constraints in a
UML model for a specific application. The analyst
adjusts simulation settings for a particular scenario
and simulates the UML model in a given simulation
environment to produce simulation logs for that
particular scenario. We developed a log analysis tool
that processes the log file and produces timing
diagrams. Through inspection of timing diagrams,
the analyst determines if there is any violation in a
particular timing constraint. As an example:
 we used ObjecTime tool [3] as the simulation
environment,
 the log file is a text file containing all objects,
state changes, and the simulation time of any
state change,
 the log analysis tool is Microsoft Excel and a
Visual Basic Macro that we developed,
 the state diagrams are charts showing each
object as a series of changing states in time.
2.2
Automatic generation of Timing Diagrams
First, we generate a log file from simulating the
UML model for specific execution scenario. We use
MS Excel to recognize the textual log file. We
developed two Visual Basic macros within MS
Excel environment. First, the processing macro,
which recognizes all executed objects and all their
involved states, generates numeric distinct codes for
all involved states in each object, adjusts values to
enforce continuos vertical and horizontal line
representation of state changes, configures x-axis as
time series of epochs, y-axis as state codes, and each
object as a series, and automatically generates Excel
chart for each simulation run. The second macro is
the viewing macro, which enables the analyst to
zoom in and out of the timing diagram.
Purpose: Analyze the effect of inefficient
implementation of state activities and actions.
2.3
 Augment the model with delays in the execution
of entry, exit, and activity code segments of all
states involved in each scenario.
Timing Analysis Methods
Using the previous automated generation of
timing diagrams, the analyst can inspect the timing
diagrams to verify that timing constraints are met.
Moreover, the analyst can deploy several timing
analysis methods to study the effect of delays in
transmission or processing of messages. The
following figure summarizes four timing analysis
methods that we developed to verify UML
specifications. We discuss each of the proposed
methods using a Focus/Purpose/Method template.
Timing
Method
Analysis
Focus
Purpose
Links
between
objects
(components)
Study the
delays of
messages
objects
Objects
(components)
Study the effect
implementation
efficiency
Timeouts-based
Objects
(components)
Study effect of various
timeout values.
EnvironmentInteractions
External
Environment
Study effect of delays in
recognizing hardware
events
Concurrency-based
Performance-based
effect of
delivering
between
of
Concurrency-based Timing Analysis:
Focus: Architecture connectors (links between
objects)
Purpose: Analyze the effect of delays in delivering
messages from one component (object) to another.
Method:
 Augment the model with delays over connectors
involved in each scenario.
 Generate timing diagrams for each simulation run.
 Inspect timing diagrams to study the effects of
these delays on model behavior and required
deadlines.
2.3.2
Performance-based Timing Analysis
Focus: Architecture components (objects)
 Generate timing diagrams for each simulation run.
 Inspect timing diagrams to study the effect of
these delays on model behavior and required
deadlines.
2.3.3
Timeouts-based Timing Analysis
Focus: Architecture components (objects)
Purpose: Analyze the effect of timeout values of all
user defined timers in the model.
Figure 2 Timing Analysis Methods
2.3.1
Method:
Method:
 Vary the values of timers used in each scenario.
 Generate timing diagrams for each simulation run.
 Inspect timing diagrams to study the effect of
these variations on model behavior and required
deadlines.
2.3.4
Environmental-Interactions
Analysis
Timing
Focus: Interactions with the environment including
hardware devices and sensors.
Purpose: Analyze the effect of delay in sensing
environmental events, caused by external systems
and/or event recognition software (outside system
boundaries).
Method:
 Augment the model with delays in sensing
hardware events.
 Produce timing diagrams for each simulation run.
 Inspect timing diagrams to study the effect of
these delays on model behavior and required
deadlines.
3. An Example: A Pacemaker
We have selected a case study of a pacemaker
device [1, pp177] to discuss the applicability of the
proposed timing analysis methods. The pacemaker is
a critical real-time application. An error in the
software operation of the device can cause loss of
the patient’s life. Therefore, it is necessary to model
its design in an executable form to validate the
timing and deadline constraints. We have used
ObjecTime simulation environment [3] and ROOM
models [5] to model and gather simulation statistics.
A cardiac pacemaker is an implanted device that
assists cardiac functions when the underlying
pathologies make the intrinsic heartbeats low. The
pacemaker runs in either a programming mode or in
one of operational modes. During programming, the
programmer specifies the type of the operation mode
in which the device will work. The operation mode
depends on whether the Atrium (A), Ventricle (V),
or both are being monitored or paced. The
programmer also specifies whether the pacing is
inhibit(I), triggered(T), or dual(D). For the purpose
of this paper, we limit our discussion to the AVI
operation mode. In this mode, the Atrial portion (A)
of the heart is paced (shocked), the Ventricular
portion (V) of the heart is sensed (monitored), and
the Atrial is only paced when a Ventricular sense
does not occur; i.e., inhibited (I). Figure 3 shows the
pacemaker design model using a ROOM actor
diagram. The pacemaker consists of the following
actors (objects or components):
Reed_Switch (RS): A magnetically activated
switch that must be closed before programming the
device. The switch is used to avoid accidental
programming by electric noise.
Coil_Driver (CD): Receives/sends pulses from/to
the device programmer. These pulses are counted
and then interpreted as a bit of value zero or one.
These bits are then grouped into bytes and sent to
the communication gnome. Positive and negative
acknowledgments as well as programming bits are
sent back to the programmer.
Communication_Gnome (CG): Receives bytes
from the coil driver, verifies these bytes as
commands, and sends the commands to the
Ventricular and Atrial models.
Ventricular_Model (VT) and Atrial_Model (AR):
These two actors are similar in operation. They both
could pace the heart and/or sense heartbeats. The
AVI mode, chosen to be simulated, is a complicated
mode as it requires coordination between the Atrial
and Ventricular models. Once the pacemaker is
programmed the magnet is removed from the
Reed_Switch.
The
Atrial_Model
and
Ventricular_Model communicate together without
further intervention. Only battery decay or some
medical maintenance reasons force reprogramming.
The behavior of each of the actors (objects) is
modeled by a statechart which are not shown here
for space limitations.
As mentioned earlier, a pacemaker can be
programmed to operate in one of several modes
depending on which part of the heart is to be sensed
and which part is to be paced. The analysis of the
device operation defines several scenarios. We only
used the AVI_Operation scenario for timing analysis
purposes. In this scenario, the Ventricular_Model
monitors the heart. When a heart beat is not sensed,
the Artial_Model paces the heart and a refractory
period is then in effect.
As an example of applying the proposed timing
analysis approach to the pacemaker, we consider an
example from concurrency-based timing analysis
(results shown in figure 4):
Focus: We insert a delay on the link between the
Atrial and Ventricular components (10 epochs is
shown)
Result: In case of more than one unsensed
consecutive heart beats, the next heart beat overlaps
with the generated paces.
Reason: Due to message delay, the refractory
time for the Atrial increased by at least 20 epochs
and the Pacing is delayed from expected by 10
epochs, thus the start of the waiting state was
delayed by at least 30 epochs.
Note: We observed that queuing of messages
occurs for delays larger than 20 epochs.
Figure 3 Actor diagram for the pacemaker example
G ra p h S t a rt :
G ra p h N a m e :
S e rie s 1 :
C omm ents :
X a xis la b e l S te p : 2 0
7000
G ra p h E n d : 8 5 0 0
C o n c u rre n c y b a s e d a n a ly s is . A ll m e s s a ge s b e t w e e n t h e A t ria l a n d t h e V e n t ric u la r m o d e ls a re d e la y e d b y 1 0 e p o c h s
V E N T R IC U LA R _ M O D E L
A T R IA L_ M O D E L
h e He a r t
S e rie s 2 :
S e rie s 3 :
In c a s e o f m o re t h a n on e u n s e n s e d c o n s e c u t ive he a rt b e e t s , t h e n e x t h e a rt b e e t o ve rla p s w it h t h e g e n e ra t e d p a c e s t h a t a s w e ll, in c a s e o f
d e la y s 5 0 e p o c h s o r a b o ve , a re le s s t h an t h e c o rre s p o n d in g u n s e n s e d b e e t s in n u m b e r. In a n al y z in g t h e m e s s a g e e x c h a n g e o n t h e s e q u e n c e
d ia g ra m s ve rs u s t h e t im in g d ia g ra m , it is n o t ic e d th a t t h e re fra c t o ry t im e fo r t h e A t ria l is in cr e a s e d b y a t le a s t 2 0 e p o c h s a n d t h e P a c in g is
d e lay e d fro m e x p e c t e d b y 1 0 e p o c h s , t h u s t h e w a it in g s t a t e s t a rt s d e la y e d b y a t le a s t 3 0 e p o c h s . A s w e ll Q u e u in g o f m e s s a g e s o c cu rs fo r
d e la y s lar g e r t h a n 2 0 e p o c h s .
1 2
Atrial
P a c in g
1 1
W a it in g
1 0
R e fra c t in g
9
8
Ventrical
P a c in g
7
W a it in g
6
R e fra c t in g
5
4
Heart
3
P u ls e
2
W a it in g
1
2
6
0
795
798
802
6
8
791
2
4
788
849
0
785
8
6
781
846
2
778
4
8
774
842
4
771
0
0
768
839
6
764
6
2
761
836
8
757
2
4
754
832
0
751
8
6
747
829
2
744
4
8
740
825
4
737
0
0
734
822
6
730
6
2
727
819
8
723
2
4
720
8
0
717
815
6
713
812
2
710
4
8
706
808
4
703
805
0
700
0
Tim e in e p o c h s
Figure 4 A timing diagram for the AVI scenario generated from the processing tool for the case of 10 epoch delay over the
link between the Atrial and Ventrical components.
4. Conclusion and Future Work
In this paper, we automated the process of
generating timing diagrams from simulation log file,
we proposed a simulation based temporal IV&V
methodology, and we defined four timing analysis
methods.
As part of the future work, we plan to:
 Investigate techniques to automatically check the
violation of constraints/rules from simulating
UML models. We perceive that we can develop an
observer component that runs within the
simulation environment, monitors variables,
controls sub simulations runs, and checks for
violations of timing constraints.
 Develop a technique to select scenarios,
components, and connectors to which we apply
the proposed timing analysis approach.
5. References
[1] B. Douglass, "Real-Time UML : Developing Efficient
Objects for Embedded Systems", Addison-Wesley, 1998
[2] A. Lyons. UML for Real-Time Overview. ObjecTime,
Ltd.,White
Paper,
http://www.ObjecTime.com/otl/technical/
[3] ObjecTime User Guide. ObjecTime Ltd., Kanata,
Ontario, Canada, 1998.
[4] Rational, Inc.
Rational Rose RealTime.
http://www.rational.com/products/rosert/ index.jtmpl
[5] B. Selic, B., G. Gullekson, and P. Ward, “Real-Time
Object Oriented Modeling”, John Wiley & Sons, Inc.
1994