Download Real-World Modeling in UML

Real-World Modeling in UML
Jakob Axelsson
Volvo Technological Development Corporation
SE-412 88 Göteborg, SWEDEN
Phone: +46 31 772 43 89
Fax: +46 31 772 40 86
E-mail: [email protected]
Abstract
Description languages that are used to capture the essential properties of embedded computer systems must also
allow a description of the system’s environment, which consists of a number of physical objects. The reason is that
the environment is the ultimate source of all requirements on the system. However, most such languages, including
the object-oriented ones, are not well equipped to describe the continuous-time relationships that exist in the real
world. This paper shows how the Unified Modeling Language can be extended to include such modeling, thereby
improving the design of embedded systems described in the same language. Two realistic examples are elaborated
to show the practical usefulness of the results. The technique is also relevant to the area of systems engineering,
which often deals with multi-disciplinary system development.
Keywords: Physical modeling, object-oriented models, UML, embedded systems, systems engineering
1/10
1. Introduction
Most complex technical systems rely on the use of embedded real-time computers to control and monitor their
operation. Products range from simple controllers of slow processes, running on cheap processors, to distributed
systems built from dozens of powerful computers, controlling safety critical devices such as automobiles, aircrafts,
and nuclear powerplants. It is well known that the complexity of such embedded systems has to be mastered
through the use of rigorous development methods, allowing the designers to assess the quality of the solution
throughout the various stages of the development. Over the years, various methods have been proposed, and
currently there is a lot of interest in object-oriented (OO) techniques. This is not strange, since the OO methods are
based on "natural" concepts, such as objects, relations, states, and events, that are easily distinguishable in the real
world. They also have the benefit of being well suited for reusability, by organising hierarchical libraries of
standard components that can be connected to form a complex system. Many OO languages have been proposed,
but lately, an effort has been made to standardise the notation, resulting in the Unified Modeling Language (UML)
[6].
The OO methods originally aimed at general software development, thus focusing on the description of the
software inside the system and the interaction with external (human) users. However, embedded systems primarily
interact with an external physical environment in order to control or monitor it, and as every control engineer
knows, information about the physical environment is crucial in the design of the embedded system. Therefore, the
typical control engineer spends a substantial amount of time in modeling the environment, using laws of physics,
or models based on empirical data. The models are based on differential equations that describe how the values of
variables evolve dynamically over time.
The environment is also important from a system safety perspective. It has been shown, e.g. in [5], that the two
most important safety hazards are misunderstandings in the requirements specification and in the interface to the
rest of the system. A thorough modeling of the system and its environment helps improve these two aspects. Since
the embedded system and the environment form a whole, it would be beneficial to model them together in one
complete model, and from the standpoint of the embedded system developer, it would be best to use a notation such
as UML which has already been proven in this field rather than to invent a totally new language. However, UML
does at first glance not lend itself well to the modeling of physical processes, since it is based on a discrete dynamic
model where the system changes state as a result of events, whereas the external world changes state continuously.
The semantics of UML is intended to mimic the calculations performed by software executing on an underlying
digital hardware, but in the physical world there is no concept of calculations. Nevertheless, after a closer
examination it turns out that UML indeed contains the necessary elements and extension mechanisms needed to
use it also for continuous modeling, and the prime contribution of this paper is to show how it can be done. By thus
allowing the control engineers and software engineers to use the same models, much redundant work is avoided
and sources of misunderstanding are removed, thus leading to faster development and higher quality.
In the next section, it is described what characteristics an object-oriented modeling language should have in order
to be suitable for continuous-time models. In Section 3, an overview is given of those parts of UML that are needed
in the paper. In Section 4, an adaption of UML to physical modeling is described, which provides the desired
features using a small number of extensions expressed in the mechanisms provided in the language, and in the
following section, the notation is illustrated by two examples. In Section 6, it is briefly discussed what tool support
is needed to make the language suitable for practicing engineers, and in Section 7, some related work is described.
Finally, in the last section the conclusions are summarised.
2. Requirements on modeling languages
The purpose of a modeling language is to support the system developers throughout the process from initial
specification to finished product, and enable them at various stages to make predictions about the final system’s
characteristics, in particular related to its functionality and performance. Therefore, for embedded systems the
following features are required of a modeling language:
•
Since the system is closely related to its environment, which is usually physical, it must support modeling of
continuous behaviours.
•
The internal parts are mostly logical, thus the system must be able to support discrete behaviours as well,
including behaviours where the structure changes dynamically, as may be the case for software.
2/10
•
It must support the engineers through-out the development process, and must thus support both informal
modeling, e.g. using scenarios, and mathematical modeling.
•
It should allow efficient modeling, in the sense of short time to construct models, in order to reduce lead
times, and must therefore support reuse of models.
As argued in [9], today’s most common method for modeling physical systems, using data flow block diagrams,
have problems meeting several of these needs. Although there are extensions which allow the addition of finitestate machines, the structure remains fixed and reuse is difficult due to the unnatural causality introduced in the
models.
On the other hand, the object-oriented modeling languages, such as UML, meet all these requirements, except for
that concerned with the physical modeling. It thus seems natural to investigate the possibilities of extending this
language, rather than inventing new ones. To be more specific, the following features need to be added:
1. Continuous variables. Variables whose values’ are changing continuously as functions of time are used to
represent the current state of the physical system.
2. Equations. Equations that relate the variables to each other, thereby describing the dynamic behaviour of the
system.
3. Time and derivatives. The physical laws that need to be described by the equations are mostly differential
equations, and therefore a way of referring to the current time and to the derivative of expressions is needed.
4. Modes. Realistic physical systems have different modes, i.e. they behave differently depending on whether
certain variables have values in specific ranges. Ways of describing the modes, the relations that hold in each
of them, and the transitions between them, are needed.
5. Composition. To construct large models, convenient ways of composing models of parts into a whole are
needed. The parts should be possible to organize in hierarchies that can be collected in modeling libraries.
Preferably, mathematical relationsships that are required to specify how the connections are made, such as
Kirchoff’s laws, should not have to be restated every time two model elements are connected.
3. Overview of UML
In this section, an overview of UML is given. The language is intended to cover the full development process of
software, and thus contains a large number of concepts used to express different facets of a system. Therefore, the
discussion here is limited to those concepts that are needed to understand the rest of the paper, and the reader is
referred to e.g. [6] for information about the rest of the language. UML is mostly a graphical notation, and the
symbols are shown in the examples that illustrate the proposed extensions.
3.1. Objects and classes
The fundamental concept of object-oriented methods is the object. An object consists of a set of attributes, or
variables, which describe its internal state, and a set of operations that the object can perform, e.g. to update or
query the state, or perform calculations. An object is an instance of a class, which can be thought of as a set of
objects with similar properties, i.e. the same attribute and operation names, and the information about the properties
is normally provided at the class level. At a given time, there may be several instances of a given class, and the
instances may have different attribute values.
Classes are shown as boxes with the name inside it. Alternatively, the box may be divided into three compartments,
containing the class name, the attributes, and the operations, respectively. Objects are also shown as boxes, with
the difference that the object name is underlined to show that it is an instance, rather than a class.
3.2. Relations
It is possible to define links between objects, that allow objects to refer to each other, e.g. to invoke an operation
in a related object. The links between objects are instances of relations between the corresponding classes. There
3/10
are both general associations, which have no special meaning (shown by a line between the objects); aggregations,
indicating that an object is part of another object (shown by a line with a diamond attached to the end connected
to the "owning" class); and generalization, which describes a relationship between classes similar to the subset
relationship between sets (shown by a hollow arrow head attached to the end near the more general class). The class
that is generalized can be thought of as inheriting the features of the generalizing class, thereby allowing
information to be reused. It is possible to add a role name to the association, indicating by what name an object
refers to the other object in the relation, i.e. the attribute a of the class related by the role r is referred to by the name
r.a.
3.3. State machines
To each class, a state machine may be attached, which shows the dynamic behaviour of the class’s objects. States
are shown as ovals, and transitions as arrows between them. The transitions of the state machines are triggered by
events, which cause the transition to occur. An event may e.g. be the invokation of a class’s operation, or some
condition, expressed in terms of the attributes, being fulfilled.
3.4. Extension mechanisms
The notations provided in UML are general, and may be used for any kind of system. However, in certain domains
it may be necessary to add extensions to the language to improve the understandability of the models. It is possible
to add constraints which limit e.g. the way relationships may be formed, or the value of attributes. Constraints are
written inside {...} in a box attached to the model element to which it applies. New semantic information may be
added through the use of stereotypes, which are basically annotations to modeling elements, but which also have
semantic information connected to them. For instance, all classes that are of a certain stereotype could have a
semantic addition that they may only be related to other classes with the same stereotype. Stereotypes are indicated
by writing their names inside «...».
4. Adapting UML
In this section, we describe an extension to UML, that allows us to model physical systems. The goal is to make as
few additions as possible to the language, while still fulfilling the requirements described in Section 2. Preferably,
the additions should be made using UML’s mechanism for extensions, as described above.
4.1. Continuous variables
A basic requirement is that the extension should be able to handle continuous variables, that model properties of
the physical system. Further, we wish to couple the variables to the objects whose state they describe. Therefore,
the natural solution is to use ordinary real-valued attributes in UML, and make the somewhat liberal assumption
that a real number is really a real, in the mathematical sense, and not a limited precision floating point number, as
in most computer implementations.
4.2. Equations
It should be possible to use equations to relate different variables to each other. The meaning of such an equation
would be to express an invariant between the variables, i.e. a relationship between their values which holds under
all circumstances. Incidently, the concept of invariants is fundamental to computer science, although it is mostly
used to express logical relations, and therefore UML has already incorporated the stereotype «invariant», which is
attached to constraints of different modeling elements such as classes. Again, we interprete the concept liberally,
assuming that the variables involved in the invariant are not only altered in discrete steps, but may change
continuously.
4.3. Time and derivatives
There is a need to refer to the current time, e.g. in order to describe functions that vary over time in a certain way.
UML incorporates the notion of time, in the sense that events may be created at a certain time, but this refers to a
clock in the system which generates discrete events. For our purpose, we do not wish to involve any notion of clock,
and therefore a pre-defined global continuous variable, called time, is introduced to denote the current time.
4/10
A related problem is the derivative of an expression. Since UML does not have any notion of continuous change,
it consequently does not include the mathematical concept of derivation, and we therefore need to introduce an
operator der(x), which denotes the derivative of the expression x with respect to time.
4.4. Modes
Often, a realistic system is not totally continuous, but may operate in a number of different modes. In each mode,
a different set of equations is used to describe the behaviour of the system. Mode changes occur as the result of
events, e.g. that a variable passes a certain limit. Modes correspond closely to the notion of states in UML, and the
mode changes to transitions between states. The equations that govern the behaviour in a mode can be described
by an invariant on a particular state, and the full set of equations for the object while in a certain state is the
invariants of the class plus the invariants of the current state.
Interestingly, UML already contains an event type, called "change event", which occurs when a certain expression
becomes true, and the notation is e.g. when(x > 10 or y < 0). In fact, UML acknowledges that this kind of event
could actually imply the need to continuously check the variables in the when-expression, which is exactly what
we intend.
4.5. Composition
The concepts introduced so far are sufficient to allow the modeling of physical systems. However, to ease the
construction of complex models, and increase the ability to describe reusable components, improved ways of
composing models are needed. In particular, the interfaces between objects and the connection of interfaces are of
interest.
The solution we propose is to introduce the concept of ports, which are interface points of a class. Ports themselves
are objects with the stereotype «port». To improve the graphics, the icon
is introduced for ports.
To form connections, ports of different objects are linked to each other, and the link has the stereotype «connect».
We only allow connecting ports to each other using links with the stereotype «connect», and since this is the only
use of this stereotype, we usually let the stereotype on the link be implicit. The port objects contain variables which
are related to the corresponding variables of the ports they are connected to. A special kind of variable, with the
stereotype «flow», is introduced to model flows of e.g. current och matter. The introduction of these stereotypes
allow us to implicitly generate the necessary invariants to make the connections mathematically correct, thereby
reducing the effort to build large models.
4.6. Semantics of composition
By taking the reflexive, symmetric, and transitive closure of all links with the stereotype «connect», an equivalence
relation is formed over the set of all «port» objects in the model. The equivalence classes of this relation show
which ports are logically connected.
The following semantics hold for the stereotypes «port», «flow», and «connect»:
•
A «port» is part of at least one other object via a link which is not of the stereotype «connect».
•
A link with the stereotype «connect» only involves objects that are of the stereotype «port».
•
Port objects in the same equivalence class must be of the same class, and thus contain the same variables.
•
For all variables which do not have the stereotype «flow» of all port objects in the same equivalence class, a
set of invariant conditions is added which assures that the variables of each object in the same equivalence
class all have identical values.
•
For all variables which have the stereotype «flow» of all port objects in the same equivalence class, an
invariant is added which assures that all such variables of objects in the same equivalence class sum to 0.
5/10
pin1
«invariant»
{pin1.current +
pin2.current = 0}
{abstract}
ElectricalComponent
«port»
ElectricalPin
pin2
voltage
«flow» current
Resistor
resistance
«invariant»
{pin2.voltage - pin1.voltage
= resistance * pin1.current}
Figure 1. Model of electrical components.
5. Examples
To illustrate the use of the UML extension, we introduce two small examples. The first is from the domain of
electronics, and is mainly included to illustrate the semantics of composition. The second example is a more
complex system, and its purpose is to illustrate a multi-domain model with both continuous and discrete behaviour.
Some practical aspects of modeling are also discussed at the end of the section.
5.1. Example 1: electrical components
The first example is a model of ordinary electrical components, as illustrated in Figure 1. The model contains a
class ElectricalComponent, which captures common behaviour of electronic components. The class is abstract,
meaning that its description is incomplete, and it is therefore not meaningful to instantiate it. However, it serves as
a basis for defining concrete subclasses. An electrical component has two ports, pin1 and pin2, of the class
ElectricalPin, which has two attributes: its voltage and its current, where the current is a flow variable. The common
characteristic of all electrical components, which is expressed by an invariant on the class, is that the flow into the
component must be equal to the flow out of it. A special kind of component is the Resistor, which is modelled as
a subclass of electrical component. It has the attribute resistance, and an invariant which expresses Ohm’s law.
Note that Resistor inherits both the relations and invariant of ElectricalComponent. Other component types, such
as capacitors and inductors, may also be modelled as subclasses of ElectricalComponent, which shows the power
of inheritance.
Figure 2 shows an instance of the model, where three resistor objects, R1, R2, and R3, are connected together by
connecting their pins. As explained in Section 4.6, the equivalence class corresponding to the connection in the
figure consists of R1.pin2, R2.pin1, and R3.pin1. The equations which assure that all the voltages are equal at the
connection are R1.pin2.voltage = R2.pin1.voltage and R1.pin2.voltage = R3.pin1.voltage. To assure that the same
amount of current flows into the connection as out of it, the equation R1.pin2.current + R2.pin1.current +
R3.pin1.current = 0 is needed. These invariants correspond to Kirchoff’s laws, and it should be noted that they are
automatically derived from the semantics of the port concept. (For other domains, similar laws apply, which makes
the use of ports very powerful.)
pin1
R2: Resistor
pin1
R1: Resistor
pin2
pin2
pin1
Figure 2. Example of composition.
6/10
R3: Resistor
pin2
m: Motor
speed
pin
c: Controller
Operator
torqueConstant = 0.01
momentOfInertia = 0.001
rotorResistance = 0.5
rotorInductance = 0.05
axle
axle1
g: GearBox
l: Load
momentOfInertia = 10
axle
axle2
forwardRatio = 100
reverseRatio = 50
Figure 3. Overview of the example system.
5.2. Example 2: a multi-domain system
The second example consists of a controller for an electrical motor which drives a certain load via a gearbox
(similar to the example in [9]). The situation is intended to be similar to the early stages of development of the
controller, i.e. the capture of requirements and interfaces. A human operator is included who gives a set point for
the speed to the controller, which controls the engine speed to give the desired speed for the load. The operator may
also command the controller to change the gear to reverse. Figure 3 gives an overview of the system, showing the
four components, the operator, and the links between them. Note that the port icons are used to depict the physical
interfaces of the motor, gearbox, and load, i.e. the mechanical axles and electrical pin. The link associating the
controller with the gearbox and load are of a general kind, since at this stage we have not yet decided how the
interfaces will be implemented in detail. The diagram shows objects, rather than classes, since this describes a
certain system instance. The components also indicate the values of certain parameters, which are modelled as
attributes of the objects.
The model is refined by providing the definitions of the classes, shown in Figure 4. The ElectricalPin is reused from
the previous example, and MechanicalAxle is introduced as a port modeling a rotating axle, with the variables
angularVelocity and torque. The motor, load, and gearbox contain variables representing the characteristics of the
component, and invariants are attached to the classes to describe the physical laws that govern their behaviour.
The invariant of the gearbox is expressed in terms of the auxiliary variable currentRatio, whose value depends on
the direction of movement. The state machine in Figure 5 shows the details of the gearbox. The object responds to
two operations, forwardGear and reverseGear, which cause transitions, i.e. mode changes, to take place in the state
machine, thereby changing the behaviour since a new invariant will determine the current ratio. (Of course, this
model is very simplistic, since it allows an instantaneous gear change while the axles are rotating.)
5.3. Discussion
The modeling described in the second example would be typical for an initial system development phase, where
the objective is to specify the controller. The equations in the model can be used by a control engineer to determine
what information is available from the environment, and help him find a suitable control strategy and parameters,
but it also helps clarifying other relations between the controller and the environment. As an example, it may be
undesirable to perform gear shifts at angular velocities above a certain value, due to risk of damaging the
equipment. The model clearly indicates that the gearbox does not prevent this itself, and a requirement therefore
has to be put on the controller to ensure that a gear shift command from the operator is not performed unless it is
safe.
Another benefit is that it provides a common vocabulary, which can be used by the system engineers, control
engineers, software engineers, etc. that participate in the project. As the work proceeds to lower levels, each part
of the system can be refined by expanding their internal parts, i.e. replacing the invariants with a number of
7/10
«invariant»
Load
{momentOfInertia * der(axle.angularVelocity) =
axle.torque}
momentOfInertia
axle
Motor
«port»
ElectricalPin
«port»
MechanicalAxle
torqueConstant
momentOfInertia
rotorResistance
rotorInductance
pin
voltage
«flow» current
axle
angularVelocity
torque
axle1
«invariant»
axle2
GearBox
{momentOfInertia * der(axle.angularVelocity) =
torqueConstant * pin.current - axle.torque and
rotorInductance * der(pin.current) +
rotorResistance * pin.current =
pin.voltage - torqueConstant * axle.angularVelocity}
forwardRatio
reverseRatio
currentRatio
forwardGear()
reverseGear()
«invariant»
{axle1.angularVelocity = currentRatio *
axle2.angularVelocity and
axle2.torque = currentRatio * axle1.torque}
Figure 4. The classes of the physical components.
interconnected parts with their own invariants. Likewise, the controller may be refined showing the internal
software objects, to verify such things as real-time scheduling.
In practice, all of the components in the environment of this example would probably be provided in pre-defined
libraries, thereby greatly reducing the time to develop the model. By using inheritance, many different models
could be provided, with the same external interface but different internal characteristics.
6. Tool support
Currently, there are several UML tools on the market, that support both modeling (i.e. drawing the diagrams),
simulation, and generation of software code. Usually, only a certain subset of the language is allowed. Some tools
reverseGear()
Forward
Reverse
forwardGear()
«invariant»
{currentRatio = forwardRatio}
«invariant»
{currentRatio = -reverseRatio}
Figure 5. State machine for the class GearBox.
8/10
assist in verifying the model, e.g. to check that all names are correctly spelled and follow the semantic rules of the
language. Naturally, there are no tools on the market that support the extensions introduced in this paper. To adapt
a tool to the extensions, the following features are desirable:
•
The possibility to simulate the system. This would require that all equations of the system are extracted, and
fed into a differential equation solver.
•
Analysis functions. For instance, it would be desirable to analyze such things as stability and responses to
changes in input signals, to support the development of controllers.
•
Semantic checks. This would include a verification that the conditions introduced for the new stereotypes are
fulfilled, and that sufficiently many equations are generated for all modes of the system. Also, it would be
useful to allow scientific units to be attached to variables, and perform a type check to see that the units are
correct in all equations.
Even though the expressiveness of the extended language already motivates its use, the full potential is not reached
before such tools become available.
7. Related work
Suggestions have been made on how to use UML for embedded systems, e.g. in [1], but they typically focus on
how to handle the internal organisation of the system, i.e. what tasks should execute and how they should be
scheduled. However, these are issues resolved in the detailed design, and their solution depends on how the
requirements are stated. For real-time systems, the distinguishing requirements are the timing constraints, and they
are the driving force behind design decisions such as the scheduling. Timing constraints are a direct consequence
of the dynamics of the environment, hence being able to express timing constraints is of little help if they are not
based on correct requirements. Other formalisms, e.g. SDL [2] and ROOM [8], suffer from the same limitations as
basic UML.
Several object-oriented languages for modeling of physical systems have been proposed. Currently, international
efforts are under way in defining the language Modelica [3], which has been a source of inspiration for this work
and which contains most of the concepts included in the UML extension. In particular, the constructs we propose
related to composition directly follow the solution in Modelica. The language also has the notion of scientific units,
as discussed in the previous section. However, Modelica does not contain good support for modeling the internal
software of the system, which is a requirement for the developer of embedded applications. Also, the language is
totally new, which could be a hindrance for its acceptance, whereas our proposal is a small extension of an existing
and widely used language.
Another international effort is VHDL-AMS [4], which is an extension of the VHDL language for modeling digital
circuits to also handle analogue ones. Although it is primarily intended for electronics design, the same underlying
mathematical concepts (a mixture of discrete events triggering state machines and continuous processes expressed
as differential equations) are used as in other physical models. However, VHDL lacks some of the important
concepts of OO languages, most notably inheritance.
It can be expected that many simulation packages will support input descriptions expressed in Modelica and
VHDL-AMS, and a feasible solution to providing simulation capabilities to the proposed UML extension could be
to generate code from the UML model to one of these languages.
8. Conclusions and future development
In this paper, we have attempted to solve the problem of finding a modeling language that could support the
development of embedded real-time systems, with focus on control functionality. Such a language must allow the
user to model a physical environment which is best described by differential equations involving continuous
variables. It must also allow the embedded system, which is usually a discrete software program, to be modelled.
The solution we propose is to make a very modest extension to UML to allow continuous models. Mostly, the
features we need are already in the language, if one is sufficiently open-minded. In summary, our proposal is:
•
To add the notion of time and derivation, der(x).
9/10
•
To interprete attributes as continuously changing variables, and invariants with respect to classes and states
as equations of such variables.
•
To introduce stereotypes for ports, flows, and connections, to facilitate the construction of large models.
To make full use of the language, tools are needed to support simulation and analysis. We are therefore developing
a demonstrator which translates UML models from the tool Rational Rose to Modelica, allowing them to be
simulated in the tool Dymola.
Although our initial motivation for this work was to support the development of embedded systems, we see wider
use of the results. In particular, the area of Systems Engineering requires better modeling practices. In [7], an
interesting approach is taken to use object-oriented modeling for this purpose, which could easily be adapted to
UML notation. However, since Systems Engineering is usually concerned with problems involving many scientific
disciplines, the need for a mixture of discrete and continuous models is almost inevitable, and the use of our
notation would therefore increase the power of the models significantly. It can also be used outside engineering,
e.g. to structure models of large economical systems, as they are built on a similar mathematical foundation.
References
[1] Douglass, B. P. Real-Time UML. Addison-Wesley, 1998.
[2] Ellsberg, J., D. Hogrefe, and A. Sarma. SDL: Formal Object-oriented Language for Communicating Systems.
Prentice Hall, 1997.
[3] Fritzson, P. and V. Engelson. Modelica - A Unified Object-Oriented Language for System Modeling and
Simulation. Proc. 12th European Conference on Object-Oriented Programming, 1998.
[4] IEEE. Analogue and Mixed Signal Extensions to VHDL. IEEE Standard 1076.1, 1999.
[5] Lutz, R. Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems. Proc. IEEE
International Symposium on Requirements Engineering, 1992.
[6] Rumbaugh, J., I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. AddisonWesley, 1999.
[7] Oliver, D. W., T. P. Kelliher, and J. G Keegan, Jr. Engineering Complex Systems with Models and Objects.
McGraw-Hill, 1997.
[8] Selic, B., G. Gullekson, J. McGee, and I. Engelberg. ROOM: An Object-Oriented Methodology for
Developing Real-Time Systems. Proc. 5th International Workshop on Computer-Aided Software Engineering,
1992.
[9] Åström, K. J., H. Elmqvist, and S. E. Mattson. Evolution of Continuous-Time Modeling and Simulation. Proc.
12th European Simulation Multiconference, 1998.
10/10