5 Basic Models
5.1 Devs Model
A devs class has basic methods for handling time information
(last time, next time), output message, and port information such as input
ports and output ports.
timetype tL, tN;
message *output;
set *inports, *outports;
devs *parent;
Since this class provides many services needed in devs environment,
numerous methods are defined to provide polymorphism for the children classes.
The inject method is useful to send input to specific models. The make_content
method creates the content for message.
inject(char *p, entity *val);
inject(char *p, entity *val, timetype e);
inject_address (char * p, addrclass * addr, entity * val, timetype
e);
make_content(char *p, entity *val);
5.2 Atomicbase and Atomic Models
An atomicbase model has a simulation engine for atomic models, and
also has the sigma variable. An atomic model which inherits from class
atomicbase includes the phase variable. In million cell models,
when we don't need a phase variable, we can use atomicbase model.
The following methods handle sigma and phase variables.
hold_in(timetype sigma);
hold_in(phasetype phase, timetype sigma);
passivate();
passivate_in (phasetype phase);
5.3 Cellbase and Cell Models
Cellbase and cell classes have an address data structure
as an attribute. They are used to represent large numbers of similar models
called cells which communicate with each other in the same, uniform manner,
such as in cellular spaces. Coupling information is applied all the cells
in the same way. For example, the coupling "out" port to "in"
port applies any time one cell sends to another. These models use methods
handling the address to recognize source and destination.
addrclass my_location;
make_content_address(char *p, addrclass *addr, entity *val);
5.4 Coupled Models
Coupled models is the major class which embodies the hierarchical
model composition constructs of the DEVS formalism. Digraph models,
block models, and digcell models are specializations which
enable specification of coupled models in specific ways. A coupled
model is defined by specifying its component models, called its components,
and the coupling relations which establish the desired communication links.
A coupled model tells how to couple several component models
together to form a new model. It can itself be employed as a component
in a larger coupled model, thus giving rise to hierarchical construction.
A coupled model contains the following information:
-
the set of components
-
the set of input ports through which external events are received.
-
the set of output ports through which external events are sent
-
the external input, external output, and internal coupling
5.4.1 Instance Variables
Instance variables in coupled models are defined as follows and
are initialized by the constructor:
set *components;
couprel *Coupling; //couprel is derived from class relation
set *imminents;
function *comp_map;
Components
Figure
14 Components data structure
The components variable keeps component information. In Figure
14, the coupled model (ef-m) has 3 components: genr,
proc, and transd. To add compoments we use "add_component";
ef-m->add_component(genr);
ef-m->add_component(proc);
ef-m->add_component(transd);
Coupling
As the Coupling variable holds an instance of relation (derived
class, couprel), each pair has a set of source and destination pairs to
keep the coupling relationships among a coupled model and its components.
Figure 15 represents the data structure for the Coupling variable. The
source part, the first two columns, keeps the source (ef-m) followed
by port ("start" or "stop") of the source object. The destination
part, remaining two columns, consists of the destination (genr)
and port ("in" or "end") of the destination object.
Figure 15 coupling
data structure
External input coupling couples the input ports of a coupled
model to the input ports of its components. Likewise, external output coupling
couples the output ports of the components to output ports of the coupled
model. Internal coupling couples output ports of components to input ports
of other components. We use "add_coupling" to provide coupling information;
add_coupling (ef-m, start, genr, in);
add_coupling (ef-m, stop, genr, end);
Comp_map
Comp_map, shown in Figure 16, is a function having (component, unique_id)
pairs. Unique_id is assigned to each component in the coupled model
so that its mailbox has unique integer id.
Imminents
The imminents variable keeps the information of the components in which
next output events should occur. To get the imminent information, the coupled
model asks which of the components have the next global event time (Figure
13).
Figure 16 comp_map
structure
5.4.2 Convert_input()
When messages come into the system from outside, the destination of the
messages must be changed every time they descend down the hierarchical
instances in the model. Convert_input() uses the external input coupling
(in which the external input of the coupled model goes to external
input of the components). An input port of a coupled model can be
connected to one or more input ports of the components. Using the information
in the coupling relation, convert_input() translates the destination
object and port name to those of each related component (Figure 17).
Figure 17 Convert
Input Function of Coupled model