![](bg3.png)
dent objects (the commands). These patterns pro-
vide the required level of flexibility, since they im-
pose no constraints over command subscription to
threads, number of commands, concurrency scheme,
etc. The roles defined by these two patterns are
realized by the classes Activity Processor and
State Activity, respectively. (see Figure 1).
Another key aspect, related to AD4, is to provide
an OO implementation of the timed automata compat-
ible with the selected patterns for concurrency con-
trol, in order to integrate it in the scheme defined by
the aforementioned COMMAND PROCESSOR pattern.
It is also an aspect that has a great influence on the
whole design, since timed automata model the behav-
ior of the components. We decided that both regions
and states should be treated homogeneously, and thus
we selected a simplified versions of the COMPOSITE
pattern. The timed automata is managed following the
METHODS FOR STATES pattern (Buschmann et al.,
2007a), and the instances of the classes represent-
ing it are stored in a hash table. The roles defined
by this pattern are realized by the classes State,
Hierarchical State, Region and Leaf State.
Each activity associated to a state of the timed
automata is implemented as an object, following
again the COMMAND pattern, represented by the class
State Activity. In this way, activities can be allo-
cated to any command processor. This constitutes the
link between concurrency control and timed automata
implementation, since activities play roles in both
patterns. The distinction between states and regions
led us to define two hierarchies of State Activity,
which were implemented following the STRATEGY
pattern: those associated to leaf states (represented
by the root class Leaf Activity), and those activ-
ities associated to regions (represented by the class
Hierarchical Activity). The latter is aimed at
managing the region states and transitions, and thus is
provided as part of MinFr. The formers, are related
to (i) the activities defined in the V
3
CMM models,
represented by Native Activity subclasses, and
(ii) activities to manage the flow of data and control
among component through their ports.
3 TEMPORAL BEHAVIOR
ANALYSIS
From MinFr instantiation model, obtained from the
V
3
CMM components application model, we proceed
to the generation of a third model, called the deploy-
ment model. With the deployment and MinFr model
can be generated a Cheddar analysis model and the
application code. The transformation that generates
the application code creates instances of framework’s
classes that are necessary for building components
and generates the skeleton of the activities that must
be completed by the programmer. The deployment
model describes how it will distribute the source ap-
plication into two parts: compute nodes and concur-
rent processes.
Once set up and completed the model of applica-
tion deployment, we proceed to generate the Ched-
dar analysis model. Due to the XML format used by
the analysis tool, it has been developed a model to
text transformation using Xtend to generate the file
with the information necessary to carry out the anal-
ysis. The deployment model explicitly defines the
threads (Threads), which correspond directly to ac-
tivities in the Cheddar model(Tasks). The model to
text transformation estimates the period of each one
of these threads as the greatest common divisor of
all the periods of all region activities assigned to the
thread. Each MinFr thread behaves as an cyclic ex-
ecutive and, therefore, it is possible to assign regions
with different periods to the same thread.
Shared resources are not explicitly defined in the
deployment model, but it is possible to determine
which are potentially shared resources. The can-
didates for shared resources between threads are:
events, ports and port connections. Events can be
accessed by the activities and transitions, ports can
be accessed by the activities, transitions, and the up-
date region activity of each component and connec-
tion ports can be accessed by the update region of
each component. To determine whether a resource is
shared by more than one thread, it is necessary to an-
alyze MinFr model to determine what resources each
thread accesses.
The transformation from the V
3
CMM model to
MinFr model adds a number of extra items that are
necessary to define some details of the application
execution. It should be noted the additional region
that is added to each component and is responsible
for managing the ports and communication between
components. Compliance with the requirements of
MinFr, implementation of the code that manages the
operation of it should be under the control of the de-
veloper. Therefore, the developer must also allocate
these additional regions to the threads, like any other
region of the application. In the case of the update
region, determining the resources to be shared is per-
formed in a similar manner, taking into account that
in this case the update region has access to all ports
and ports connections that the component contains.
Thus it is possible to identify candidates for shared
resources. Shared resources will only be those that
are accessed from different threads.
AFrameworkforDevelopingComponent-basedApplicationswithTemporalAnalysisCapabilities
317