A Language for Simulation: Bringing Separation of Concerns to the Front

Abstract

. The complexity arising in simulation problems usually requires mixed modeling techniques to tackle them. Different simulation languages and tools have been proposed, but the complexity rate in real problems often goes faster than the solutions. Using object-oriented principles, current approaches support a functional decomposition of the problems. Besides that, there are views that not necessarily align with the functional components of the system, such as different modeling techniques, concurrency, scheduling and optimization. The way these aspects affect software artifacts, as the simulation example presented states, usually produces a messed design. As a result, good properties that any simulation system should enforce regardless of specific modeling techniques, such as reusability and adaptability, become fairly restricted. We argue that simulation domains needs usually specific separation of concerns. A framework supporting the aspect-oriented paradigm can provide a clear separa...

Full text

Page 1

1
A Language for Simulation:
Bringing Separation of Concerns to the Front
J. Andrés Díaz Pace1, Mohamed E. Fayad2 and Marcelo R. Campo1

1ISISTAN Research Institute, Facultad de Ciencias Exactas,
Universidad Nacional del Centro de la Provincia de Buenos Aires
Paraje Arroyo Seco, 7000 Tandil (Argentina)
Email: { adiaz , mcampo } @exa.unicen.edu.ar

2Computer Science and Engineering Department,
University of Nebraska, Lincoln (USA)
108 Ferguson Hall, P.O.Box 880 115, Lincoln, NE 68588-0115
Email: fayad@cse.unl.edu
Abstract. The complexity arising in simulation problems usually requires mixed modeling techniques to tackle them.
Different simulation languages and tools have been proposed, but the complexity rate in real problems often goes faster
than the solutions. Using object-oriented principles, current approaches support a functional decomposition of the
problems. Besides that, there are views that not necessarily align with the functional components of the system, such as
different modeling techniques, concurrency, scheduling and optimization. The way these aspects affect software
artifacts, as the simulation example presented states, usually produces a messed design. As a result, good properties that
any simulation system should enforce regardless of specific modeling techniques, such as reusability and adaptability,
become fairly restricted. We argue that simulation domains needs usually specific separation of concerns. A framework
supporting the aspect-oriented paradigm can provide a clear separation of concerns for these tangled situations.
1. Introduction
Simulation models allow to analyze the behavior of a given system and draw some inferences or predictions
of such study. In fact, the application of simulation techniques to engineering problems is constantly
increasing because of their potential advantages. The complexity arising in such problems usually requires
mixed modeling techniques to tackle them [Cubert97, Zeigler76]. For instances: differential calculus,
probabilistic methods, discrete-event simulation, finite state machines, and so on. Specific simulation tools
have been proposed to model systems involving concerns of different kinds. Unfortunately, the complexity
rate in real problems often goes faster than the solutions. From the early Simula experiences [Vaucher99],
object-oriented technologies have been attached to simulation, and most of the environments and languages
for simulation argue this foundation. Using object-oriented principles, current approaches support a
functional decomposition of a problem: it is broken into sub-problems that can be addressed relatively
independently. The availability of some modular unit of functionality (component) is the basis of these
designs.
Besides that, simulation often comprises properties that not necessarily align with the functional
components of the system. These views come with the notion of aspects, as system properties that tend to cut
across functional components [Kickzales97, Lopes97]. In this context, simulation domains need specific
separation of concerns. For instances: synchronization (many simulation environments implements
concurrency, trying to provide a more direct way of modeling real systems), scheduling (for example, in
discrete-event based simulations), optimizations (because performance is a desired property in simulation),
distribution (for example, using web-based simulation), or different models to describe a given system. The
way in which these factors affect software artifacts usually produces a messed design. The tangling code
increases the dependencies between the functional components, thus making the source code difficult to
develop, understand and evolve. As a result, good properties that any simulation system should enforce
regardless of specific modeling techniques, such as reusability and adaptability, become fairly restricted.
The paper presents an example based on the simulation of a thermic control system, showing how aspects
related to mathematical models, concurrency, scheduling and optimizations, are scattered across the
architecture. Furthermore, a framework-based approach is suggested to deal with this issue. Finally, we
discuss the pending challenging aspects where achieving a good separation of concerns can be useful for
simulation domains.

Page 2

2
2. A simulation example
A simulation example is described, where we can distinguish three different views of the same problem:
basic functionality, mathematical and concurrency issues. The result of this composition derives in a tangled
code, with several aspects hardly embedded in the design. The example is based on a thermic control system
with a classical closed control loop, involving non-functional requirements like reusability, maintainability
and extensibility. The real system is somewhat more complex of course, however, this simplified version is
interesting enough to capture many of the hard situations arising in simulation software regarding to aspects.
In order to provide a clear picture of the problem, we first will present the views separately, then the
complete design will be described, and right after we will comment the main drawbacks of this example.
2.1. A thermic control system
Suppose we have a building with rooms requiring specific temperatures, and a network consisting of heaters,
pipes and a boiler. Figure 1 shows a diagram of such thermic control system. The boiler is the heat source,
and it generates a heat flow that is distributed through the circuit. Each heater has a valve (with a regulation
mechanism) to transfer part of this heat flow to the rooms until they reach the selected temperatures. Each
room has predefined dimensions, materials and convection properties. The heaters store information about
size, radiation area, and convection properties. The user can set up the desired temperature for a room, and
when the current temperature in the room is lower than this value, a control action is activated asking a
certain heat amount to the boiler.




















Fig. 1. Diagram of the thermic control system and the closed loop
2.2. Basic functionality
A smart object diagram modeling the main components in the system is shown in Figure 2. This design
allows us to implement each component relatively independent from the others, and captures the basic
functionality involved in the control loop. A brief description outlining the system includes:
•=
Room: This class updates its heat value according to the heat received from its heaters, and asks for more heat to the
boiler if detects a difference between the current and the desired temperature. Basically, the user only should
provide a specific implementation for the updateTemperature(), updateHeat() and heatRequired() methods, and
take the outside temperature into account in this computation. Information about room dimensions is also included.
•=
HeatPropagator: This class represents entities able to be connected with other entities, transmitting a certain heat
among them. An implementation of the transferredHeat() method is required.
•=
HeatCircuit: It maintains a collection of HeatPropagator elements in some order.
Variables
Ti: Current temperature in room i
To: External temperature
Qi: Heat value in room i
qi: Heat value in heater I
qri: Heat transferred from the heater i to the room
qT:Total heat produced in boiler
pi: Threshold valve in heater i
(a) qr5
Heater 1
Boiler
Heater 2
Heater 4
Heater 3
Heater 5
Room 1
Room 2
Room 3
(a) qr1
(a) qr2
(a) qr3
(a) qr4
(c) qT
(b) qask1
(b) qask3
(b) qask2
heater
To
qi
Qi
Ti
pi
qT
boiler
room
pipeline
outside
house
heat net
qi, qri

Page 3

3
•=
Pipe: This HeatPropagator subclass defines a connective to effectively transfer heat from the boiler to a heater or
from a heater to another. The transferredHeat() method calculates the propagated heat according to the pipe
dimensions (for example, a direct proportion with the length).
Outside: It represents the external environment and stores a given temperature. The modifyTemperature() method is
responsible to implement variations on that external temperature.
Boiler: This HeatPropagator subclass can be asked for heat requirements, and it determines how much heat is
distributed through the HeatCircuit and the values of the valves in the heaters. It overrides the propagate() method
to define this behavior. In addition, the user should specify an implementation for the generateHeat() method.
Heater: This HeatPropagator subclass is responsible of transmit a given heat value to its associated rooms. To
achieve this transference, it stores data related with its dimension and a threshold valve. The propagate() method is
overridden to include this extension. The user should provide the functionality for the roomHeat() method.
•=
•=
•=






















Fig. 2. Object model for the thermic control system
2.3. Mathematical issues
To simulate this thermic control system, a quite simple mathematical model is introduced describing the heat
flow between the different components. It is depicted in Figure 3. The model relates certain variables in the
system using a set of temporal differential equations, and also includes some constant values in the equations.
It is not our intention be focused on the mathematical background behinds this model, but instead concentrate
in how this view affect our previous design.
The mathematical model imposes now, new relationships between the components of the object model:
each heater needs to know the temperature of its associated room, each room knows the temperatures of its
neighbors, and the boiler is able to set heater valves during its computation. In our example, the equations
were distributed assigning equations (1) and (2) to the Room class, equations (3) and (4) to the Heater class,
and equation (5) to the Boiler class.
It is important to note that the chosen model is only one of the alternatives, and other approaches
involving or not mathematical equations are possible, such as state machines or probabilistic models.


addHeat(double q) {
qi = q;
}
run() {
Qi = updateHead(qi);
Ti = updateTemperature(Qi,qi);
control();
}
control() {
if ( (T*i - Ti) >= e ) {
qask = heatRequired(Qi,T*i,Ti,To);
boiler.requestHeat(qask,heaters);
}
}
propagate() {
heat = transferredHeat(qi);
next.addHeat(heat);
}
run() {
propagate();
}
Pipe
dimensions : Dimension
propagate() {
super.propagate();
qroom = roomHeat(qi);
room.addHeat(qroom);
}
propagate {
qT = generateHeat();
setValves(Vector)
next.addHeat(qT);
}
run() {
To = modifyTemperature(To);
}
Outside
To : double
modifyTemperature (double) : double
run ()
heat source
heat requester
1..* 1..*
Room
Ti : double
Qi : double
qi : double
T*i : double
dimensions : Dimension
heaters : Vector
boiler : Boiler
outside : Outside
addHeat (double)
updateHeat (double) : double
updateTemperature (double, double) : double
heatRequired (double, double, double, double) : double
control ()
run ()
heat supplier
0..*0..*
Boiler
qT : double
heaters : Vector
requestHeat (double, Vector)
generateHeat () : double
setValves (Vector)
propagate ()
Heater
room : Room
dimensions : Dimension
pi : double
roomHeat (double) : double
propagate ()
next
HeatCircuit
elements : HeatPropagator
1..* 1..*
HeatPropagator
next : HeatPropagator
qi : double
addHeat (double)
propagateHeat ()
transferredHeat (double) : double
run ()

Page 4

4
2.4. Concurrency issues
To specify how the simulation will run, a natural modeling comprises implementing the components as
independent threads. All the components perform their own computations collaborating in the evolution of
the simulation. This situation implies taking synchronization and scheduling issues into account. For
instance, we need to synchronize communication between heaters and rooms regarding to heat transference,
or valve manipulations in the heaters because race conditions might arise if the boiler try to use them.
Synchronization code is scattered across several classes. Interestingly, these synchronization features also
depend of the different relationships among variables defined by the mathematical model.
dT
R

Equation (1) represents the thermic balance for each room. Ri is a
thermic constant for the room, and Qi is the total heat.
Equation (2) estimates Qi using the heat transference among the room
and each of its neighbors (including the outside). Ai is a convective
constant.
Equation (3) defines the thermic balance for each heater. Hi is a
thermic constant.
Equation (4) estimates qri on the basis of the heat transference between
the heater and the room. The parameter pi represents the threshold
valve, and ai is a convective constant.
Equation (5) models the heat variation in each heater according to the
total heat (qT) generated in the boiler. Again, pi is the threshold valve,
and Ki represents the heat delay from the boiler to the heater.
(1)
∈
i
−=∗
heaters
ii
i
i
Qq
dt
(2)
∈
j
−∗+−∗=
neighbors
jiiiii
TTATTAQ
)()(
0

(3)
rii
i
i
qq
dt
dt
H
−=∗

(4)
)(
fiii ri
Ttapq
−∗∗=

(5)
ii
i
i
qqTp
dt
dq
K
−∗=∗

Fig. 3. Mathematical model describing heat flow
In order to make our simulation more realistic (and to avoid a large number of threads running
simultaneously), we might want that comparisons in the rooms and heat generation in the boiler will be
performed according with a predefined frequency. Implementing this idea introduces new scheduling aspects
into the code, and also a kind of clock component is required to notify rooms and boiler.
2.5. The complete picture
The combination of all the aspects mentioned above has turned our initial design in the code listed in Figure
4. Of course, this is a simplified example and it is not difficult to deal with the relatively small amount of
tangling existent in the code. But we can appreciate how in real programs the complexity due to such tangling
quickly expands to become a major obstacle regarding to maintenance and reusability.
This apparently harmless example brings to the front several considerations:
•=
Functionality is mixed together with simulation modeling techniques. Based on some physical knowledge
we have proposed a set of relationships to model the example (differential equations) that is embedded in
our design, along with the numerical method chosen to solve that equation set. But these assumptions
might be modified in the future, and we can foresee that even small changes can lead us to important
reengineering efforts. Provide a way to clearly map equations or other kind of models to an object model
is not a straightforward task at all.
•=
Encapsulation is degraded. Any specific modeling technique introduces some bindings between
components affecting the internal state of the objects. Although an observer-observable pattern might be
implemented to manage these dependencies, usually this solution only offers a way around, because the
relationships can be quite tangled and expose internal implementation details. This process often results
in an intricate design.
•=
Performance and optimizations. Because of the repetitive calculations usually performed by different
entities, the simulation does not address optimization issues. An efficient solution for the equations is
possible (using for example, Runge-Kutta methods), but we need to resign some object-oriented benefits
towards a procedural style with this option. Figure 5 shows an alternative calculus schema taking
optimization into account. Moreover, the concurrent model to execute the simulation adds an undesired
swarm of synchronization statements into the code.

Page 5

5


















Fig. 4. Resulting Boiler class (with tangled code)
























Fig. 5. Calculus schema involving optimized computation
As the code sample exemplifies, the weak point in current simulation technologies (languages,
environments, kernels, etc.) is that they require a manual programming of the different aspects. It results in
these views being spread throughout the architecture.
3. A framework-based approach
Some approaches exists to express each of the system aspects of concern in a separate form of system
functionality, and they then automatically combine (weaving) those separate descriptions into a final form.
We believe that a framework seems to be a good solution to the problem, because it can provide several open
class Boiler extends HeatPropagator {
// Instance variables –-
private double
private double
private Vector
qT;
qrooms;
heaters;
private Object qroomsLock = new Object[0];
// Instance methods --
public void requestHeat(double q,Vector h) {
synchronized (qroomsLock) {
qrooms = qrooms + q;
...
heaters.addAll(h);
}
}
protected propagate() {
qT = this.generateHeat();
next.addHeat(qT);
}
protected double transferredHeat() {
synchronized (qLock) {
...
}
}
protected double generateHeat() {
synchronized (qroomsLock) {
Vector valves;
...
for (Enumeration e = heaters.elements();
e.hasMoreElements(); ) {
Heater heater = (Heater)(e.nextElement());
...
valves.add(h.getValve());
}
...
double q;
q = MathPackage.RungeKutta(qi,qrooms,qT,...);
...
for (Enumeration e = heaters.elements();
e.hasMoreElements(); ) {
Heater heater = (Heater)(e.nextElement());
...
h.setValve(valves.elementAt(i));
}
return (q);
}
}
} // End Boiler

Gray code corresponds to tangled code due to concurrency aspects.
Underlined code corresponds to tangled code due to mathematical aspects.
(1) Propagate
qT through the
connection
(2) Integrate
thermic balance
equations (heaters)
(4) Integrate
thermic balance
equations (rooms)
(3) Calculate q
(transferred)
(5) Comparate
T* against T
(6) Solve boiler
equations
(requests)
qT
qheater
theater
q
T
qasked
p
dt: time step
T*, T(t=0), qT(t = 0), p(t = 0) are initial values for the simulation.
Gray boxes represent numerical integrators for our equation sets.
This schema works with the following cycle:
(1) The qT value of the last iteration (or the initial value at the
beginning) is sent to all the heaters in the connection. Each
heater takes a portion of this heat (qheater).
(2) Using the previous qheater (and other additional data), an
integration module solves simultaneously the equation set
for all the heaters (thermic balance), and calculates a
temperature in each heater (theater).
(3) The heat transferred from the heaters to their rooms is
calculated using theater and the last room temperature (T).
This heat (q) will be the input for the two next integrations
in the cycle.
(4) An integration module solves simultaneously the equation
set for all the rooms (thermic balance), and the current
temperature in each room is obtained (T). Since each room
equation needs also the temperature of its neighbor rooms,
this optimized computation is a better method than a
separated computation because it avoids repetitive calculus
in each room.
(5) Each room performs a comparison against its current and
desired temperature, and can ask for more heat (qasked).
(6) The boiler uses qasked and current heat in each room (q) as
inputs to calculate a new value for qT, and sets the heater
valves (p). The cycle starts again.

Page 6

6
mechanisms to support new features, and developers are not restricted to the constructs of a specific
language.
Most of the existent frameworks for simulation rely in a given modeling technique (state charts, block
diagrams or discrete-event based kernels) as underlying support, and applications are built on top using that
facilities. Some of them also present some kind of hierarchical modeling [Cubert97]. Even when these tools
can be useful in some contexts, developers are forced to think in a predefined modeling technique to fit their
abstract conception of a problem, not allowing consider other views at the same time. We argue that any
simulation process should start with a conceptual model intuitively clear to the developer, and then a smooth
transition to convert this to a simulation program. Our goal is to develop a general framework [Fayad99] as
the language for simulation, providing a common programming model to specify simulations and combine
different aspects cleanly. The preliminary work on the AOP Mediator framework [Constantinides99a,
Constantinides99b] is an encouraging research in this line.
4. Discussion
The analyzed example shows how even a simple mathematical model and some concurrent issues impacts on
an object-oriented design, and reduces reusability and scalability in a significant factor. Regardless the major
goals of the object-oriented paradigm such as abstraction, modularity and reuse, the paradigm is inadequate
to address a complete separation of concerns. Furthermore, simulation field needs specific aspects to be
separated for different purposes: modeling techniques, scheduling of events, concurrency, distribution,
performance, and so on. We claim that a good separation of concerns should be considered a discipline for
general programming (complementing the object-oriented approach), rather than a novel technique to address
a given range of applications. Relying on this rationale and collecting the vast existent experience in the
simulation field, we believe that an open language for simulation needs to think beyond, and provide an
adaptable framework supporting the right modularization at the right time. We have described the problem,
tackle it is the next challenge.

Acknowledgments: Thanks to Alejandro Clausse for his generous help with the mathematical model for the
thermic control system presented in the paper.
References
[Zeigler76]
[Cubert97]
Zeigler, B.: Theory of Modelling and Simulation. Wiley and Sons, New York, 1976.
Cubert, R., and Fishwick, P.: MOOSE: An Object-Oriented Multimodeling and Simulation
Application Framework. Submitted to Simulation, June 1997.
Kickzales, G., Lamping, J., Mendhekar, A., Maeda, C., Videira Lopes, C., Loingtier, J., and
Irwin, J.: Aspect-Oriented Programming. Proceedings of the European Conference on Object-
Oriented Programming (ECOOP), Finlad. Springer-Verlag LNCS 1241. June 1997.
Videira Lopez, C.: D, a language framework for distributed programming. Ph.D. Thesis.
Graduate School of the College of Computer Science. Norheastern University. Boston,
Massachusetts, 1997.
Constantinides, C., Bader, A., and Elrad, T.: A framework to address a two-dimensional
composition of concerns. Position paper to the Object-Oriented Programming, Systems,
Languages and Applications (OOSPLA’99). First Workshop on Multi-Dimensional Separation
of Concerns in Object-Oriented Systems. 1999
Constantinides, C., Bader, A., Elrad, T., and Netinant, P.: Composition of concerns. Position
paper to the Object-Oriented Programming, Systems, Languages and Applications
(OOSPLA’99). First Workshop on Accomplishing Software Stability. Denver, Colorado,
November,1999
Fayad, M., Schmidth, D., and Johnson, R.: Building application frameworks: Object-Oriented
foundations of framework design. Wiley and Sons, New York, September, 1999.
Vaucher, J. and Magnusson, B.: Simula frameworks: the early experiences. A Chapter in
"Building Application Frameworks: Object Oriented Foundations of Framework Design" Eds:
M. E. Fayad, D. C. Schmidt, R. E. Johnson, Wiley & Sons, ISBN 0-471-24875-4, 1999.
[Kickzales97]
[Lopes97]
[Constantinides99a]
[Constantinides99b]
[Fayad99]
[Vaucher99]