TOWARDS A UML EXTENSION
FOR HLA FEDERATION DESIGN
Okan Topçu, Halit Oğuztüzün
Department of Computer Engineering
Middle East Technical University
06531 Ankara, Turkey
otopcu@ceng.metu.edu.tr, oguztuzun@ceng.metu.edu.tr
Keywords:
Distributed Simulation, Federation Design and
Development, HLA, FEDEP, UML, OMT
ABSTRACT
This
paper
presents
a
metamodel
extension/profile to UML (Unified Modeling
Language) for HLA (High Level Architecture)
object model design. This is regarded an initial
step to lay the semantic groundwork for a visual
notation for federation design and development.
The overall objective is to provide well-founded
tool support for all aspects of federation design
and development, including the HLA Interface
Specification areas.
1. INTRODUCTION
Guidance in the process of developing HLA
federations is provided by the Federation
Development and Execution Process (FEDEP)
model (DMSO 1999). The FEDEP model
identifies the basic steps in the development of a
federation, though it does not prescribe a single
way of constructing an HLA federation. FEDEP
is decomposed into six primary process areas:
federation objective definition, conceptual model
development, federation design, federation
development, federation integration and test, and
execution and preparation of results. By the end
of the development phase, the FOMs (Federation
Object Models) and SOMs (Simulation Object
Models) are documented by using OMT
components in tabular form.
Understanding
and
communicating
the
architecture of a federation by using tables or
text can be difficult. There is a need to depict the
federation design graphically, which will aid
easier comprehension for complex federations. In
this regard, UML provides a sound basis for
specifying,
constructing,
visualizing
and
documenting all the artifacts of a softwareintensive system. UML is chosen for the visual
representation of federation design because it is
generic and extensible, so it can be tailored to the
needs of a particular application domain.
The envisioned extension for UML addresses key
activities in the federation design and
development stages of FEDEP. A seamless
integration of a federation conceptual model into
these subsequent steps is also a part of the vision.
Constructing the Conceptual Model of Mission
Space (CMMS) by using UML seems a viable
choice as this activity essentially consists in
object modeling. This should facilitate continuity
in FEDEP by utilizing the power of UML. A
notation based on UML would form a sound
basis for tool construction. This paper starts
laying the groundwork to realize this vision by
proposing a UML profile for HLA object model
design.
The usage of the term federation design in this
paper is meant to cover both federation design
and federation development in the sense of the
FEDEP model.
2. REQUIREMENTS FOR A UML
EXTENSION/PROFILE FOR HLA
OBJECT MODEL DESIGN
For building a distributed simulation system, the
analysis and design of individual simulations
(federates) is only part of the issue. The design of
virtual environment (federation), which is shared
and maintained by these federates, should also be
considered carefully. In fact, FEDEP addresses
specifically the latter issue. Therefore designing a
distributed simulation application starts at the
architectural level; in HLA domain, this is part of
Conference on Simulation Methods and Applications, Orlando, 2000
the federation design. Although the proposed and
envisioned extensions particularly address the
design and development steps of a federation, it
is worth noting that the prior step, namely,
Federation Conceptual Model development can
also take advantage of UML.
Two steps need to be taken in object model
design:
1. Constructing federation design diagrams
based on the federation conceptual model.
2. Mapping design diagrams into OMT tables.
Although the first step needs ingenuity by the
designer, the second step can be fully automated.
Federation design diagrams can be constructed in
a UML extension for HLA federation design.
Such an extension must address the following
issues in regards to object model design.
 Differences between the notion of an object
in the Object Oriented Analysis and Design
(OOAD) paradigm and that in the HLA
object model should be accommodated.
In the OOAD literature, an object is defined
as a software encapsulation of data (state)
and behavior (methods) with an identity. In
HLA, objects are defined by characteristics
that are exchanged between federates (the
visible portion of state) during execution.
Behavior is generated by the federates rather
than directly by objects. HLA has two types
of classes: object-classes, which are
comprised of attributes of simulation
entities, and interaction classes which are
comprised of parameters related to
interactions (analogous to events in the
sense of discrete event simulation).
accuracy, accuracy condition, and routing
space.
 P/S (Publish/Subscribe) characteristics of
HLA classes should be designated (related to
Data Declaration Management).
In federation design, it is essential to make
the interests and capabilities of a federate
known to the other federates in a federation.
The publish/subscribe pattern forms the basis
of the model of communication proposed by
HLA. Therefore it is useful to express the
interests and capabilities of the federates by
using UML diagrams. These diagrams
should also cover the following points.
 Routing space definitions should be handled
(related to Data Distribution Management).
 The differences between FOM and SOM
should be accounted for. FOM has certain
constraints in addition to the SOM wellformedness rules as defined by OMT
specification.
 User defined data types (e.g., enumerated
and complex (record) types) should be
supported.
Federation design process can be supported by a
CASE tool based on a well-founded modeling
language, such as UML. Figure 2 depicts
federation design from a tool-oriented view. The
tool should facilitate for designers to sketch the
federation design diagrams using the UML
extension and produce data in Data Interchange
Format (DIF) defined by DMSO (DoD 1998).
 Characteristics of object-classes should be
designated, e.g., whether they are (P)
Publishable or (S) Subscribable or (N)
Neither.
 Characteristics of interaction-classes should
be designated. Possibilities are: (I) Initiates,
(S) Senses, (R) Reacts, (N) Neither initiates
nor senses or reacts.
 Attribute
characteristics
should
be
designated: cardinality, units, resolution,
accuracy, accuracy condition, routing space,
update type, update condition, (U)
Updateable or (R) Reflectable.
 Parameter
characteristics
should
be
designated: cardinality, units, resolution,
Figure-2 Tools in Federation Design.
Conference on Simulation Methods and Applications, Orlando, 2000
3. UML EXTENSION/PROFILE
FOR HLA FEDERATION DESIGN
3.1 Introduction
A UML profile provides mechanisms for
applying and specializing the standard UML
Metamodel for a particular environment or
domain. A UML Profile consists of a predefined
set of Stereotypes, Tagged Values, Constraints,
and notation icons (OMG 1999).
This section introduces a UML Profile for HLA
federation design, defined in terms of the UML’s
extensibility
mechanisms,
particularly
Stereotypes and Constraints, to lay the semantic
groundwork for a visual notation for HLA
federation design. Federation design is based on
a representation of the real world domain of
interest in terms of the HLA object model. A
visual notation and associated tools for
federation design as a whole, and for OMT
components, in particular, should facilitate
tractability and understandability for complex
and large-scale federation designs. To this end, a
UML profile for HLA federation design is
developed, specifically addressing HLA Object
Model Template. Some other design issues
Metamodel Class
Model
Model
Package
Model
Model
Package
Classifier
HLAClass
HLAClass
Component
Association
Association
Association
Attribute
HLAAttribute
HLAAttribute
Enumerated
Enumerated
Enumerated
Enumerated
Enumerated
related to HLA Interface Specification (RTI
services) are also mentioned.
The proposed extension to UML is not meant to
supplant the standard tabular format of HLA
OMT. On the contrary, OMT provides a semantic
basis for the extensions. In fact, the aim in this
section is to define a visual layer on top of OMT
and to support tool development for HLA
federation design. The UML profile presented in
this paper covers the OMT Core Package. It
handles the contents of the following OMT
components: Object Class Structure Table,
Interaction Class Structure Table, Attribute Table
and Parameter Table. The OMT components
which specifically serve documentation purposes,
namely, the Object Model Identification Table
and FOM/SOM Lexicon are omitted from this
presentation, as their treatment is straightforward.
As Data Distribution Management issues are not
addressed in this paper, Routing Space Table is
also left out. The style of presentation is adopted
from the UML Specification (OMG 1999).
3.2 Summary Of Profile
Table 1 lists the stereotypes defined by this
profile.
Table-1 Stereotypes
Stereotype Name
Federation Design (FD) Model
Object Model
Services
FOM
SOM
OMT Core
HLAClass
ObjectClass
InteractionClass
Federate
Mask
Publish
Subscribe
HLAAttribute
ObjectAttribute
InteractionParameter
PSKind
ISRKind
URKind
TAKind
UpdateKind
Conference on Simulation Methods and Applications, Orlando, 2000
3.2.1 Tagged Values: This profile does not
introduce any new tagged values
3.2.3 Prerequisite Profiles: This profile requires
no other profiles to the UML for its definition.
3.2.2 Constraints: When OMT Core Package is
in the SOM model no constraints other than
package constraints are imposed. However when
OMT Core Package is in the FOM model, FOM
constraints also apply. Elementary constraints
can be formally expressed in Object Constraint
Language (OCL) for the sake of precision.
3.3 Stereotypes And Notation
3.3.1 Model and Package Stereotypes: UML
profile for HLA federation design comprises
several related models. The complexity of the
UML profile is managed by organizing it into
sub-models and packages as depicted in the
Figure3.
Figure-3 Models and packages of UML extension for HLA federation design
Federation Design (FD) Model
Federation Design Model contains the elements
to define a visual layer on top of HLA OMT and
to form a basis for tool development for HLA
federation design. FD Model contains Object
Model and Services stereotypes.
they are included in the OMTCore Package for
the completeness of presentation.
Object Model
Object Model represents the HLA OMT. It
includes the FOM and SOM sub-models.
Services Model
FOM
Contains the models for HLA federation design
pertaining to HLA interface specification and
related management services of RTI, namely,
Federation Management, Data Declaration
Management, Object Management, Time
Management, Ownership Management and Data
Distribution Management. The Services is not
covered in this paper. The publish and subscribe
associations could be part of the Services as well;
FOM is a model to describe of all shared
information between federates essential to a
particular federation. It includes the OMTCore
package.
SOM
Describes the capabilities of a federate that can
be offered to potential federations. It includes the
OMT Core Package.
Conference on Simulation Methods and Applications, Orlando, 2000
OMT Core
Contains the base elements defined in the HLA
Object Model Template specification, namely,
HLAClass,
ObjectClass,
InteractionClass,
federate,
Mask,
ObjectAttribute,
InteractionParameter,
PSKind,
ISRKind,
URKind, TAKind, UpdateKind stereotypes.
3.3.2 Classifier, Attribute, and Component
Stereotypes: The abstract syntax for the base
stereotypes for the UML profile for HLA
federation
design,
namely,
HLAClass,
ObjectClass, InteractionClass, HLAAttribute,
ObjectAttribute and InteractionParameter, is
described in graphical notation in the figure 4.
For detailed explanation of possible attribute
values the reader should consult (DoD 1998).
Figure-4 Base stereotypes for the UML profile
HLAClass
ObjectClass
An HLAClass is a base class for HLA objects
that are defined entirely by the identifying
characteristics (attributes) that can be exchanged
between federates during execution, while the
behaviors and operations that affect the values of
HLA object attributes are kept resident in the
federates. It is an abstract class and no graphical
icon is needed.
Object classes generally describe the physical
things that are going to be simulated (e.g., tanks,
ships, etc.).
Attributes:
introduced.
No
additional
attributes
are
Attributes:
PS
specifies information on publication and
subscription capabilities of object
classes. The type of the PS attribute is
PSKind, which is also introduced by this
profile. Possibilities:
 Publishable (P).
 Subscribable (S).
 Both
publishable
and
subscribable (PS).
 Neither
publishable
nor
subscribable (N)
Conference on Simulation Methods and Applications, Orlando, 2000
sequences. Cardinalities of multi-dimensional
arrays shall include the sizes of every dimension
listed.
Notation:
units
the unit (e.g., m, km, kg) used for the
attribute values.
resolution
the smallest resolvable value separating
attribute values that can be discriminated.
Figure-5 ObjectClass notation
InteractionClass
An interaction class is a type of interactions,
which represent transitory exchange of
information among federates. Interaction
instances can be specific events, such as
communications, collisions.
Attributes:
ISR
Four basic categories shall be used to
indicate capabilities with respect to a
given type of interaction:
 Initiates (I).
 Senses (S).
 Reacts (R).
 Neither initiates, senses, or
reacts (N).
The other values are combinations,
namely IS, IR. The type of the attribute
is ISRKind.
accuracy
the maximum deviation of the attribute
value from its intended value in the federate or
federation.
accuracyCondition
conditions required for the given accuracy
to hold in a given federation execution.
routingSpace
the routing space name for the attributes.
Associations:
type
the classifier whose instances are possible
values of the attribute. Must be a Class (userdefined datatype) or Datatype.
ObjectAttribute
Each class of simulation domain objects shall be
characterized by a fixed set of attributes.
Notation:
Attributes:
updateType
the update policy for the attribute. The
type of the updateType stereotype is
UpdateKind. Its possible values are
static, periodic, and conditional.
Figure-6 InteractionClass Notation
HLAAttribute
HLAAttribute stereotype is an abstract class for
ObjectAttribute
and
InteractionParameter
classes. It serves classification purposes.
Attributes:
cardinality
the size of an array or sequence. A
designation of 1+ allow for unbounded
updateCondition
The condition for attribute updates (see
the well-formedness rules).
TA
whether the attribute is transferable or
acceptable. The values (type is
TAKind):
 Transferable (T).
 Acceptable (A).
 Both
transferable and
acceptable (TA).
 Not
transferable
or
acceptable (N).
Conference on Simulation Methods and Applications, Orlando, 2000
UR
whether the attribute is updateable or
reflectable. Possible values:
 Updateable (U).
 Reflectable (R).
 Both
updateable
and
reflectable (UR).
Syntax and Notation:
The syntax used for describing the
ObjectAttribute stereotype takes the
form:
[UR][TA]
Attribute_name:
Attribute_Type
[updateType,updateCondition][other
attributes]
In practice, for the sake of simplicity the
diagrams can hide the attribute
information by using the notation: “ “,
called attribute information icon. The
tools can be configured to show the
attribute information while navigating
over this icon as shown in the figure 7.
Figure-7 ObjectAttribute stereotype syntax and notation
InteractionParameter
InteractionParameter is a named datum
associated with a class of interactions. Most
interaction classes will be characterized
according to a list of one or more
InteractionParameters.
Attributes:
No additional attributes are introduced.
Syntax and Notation:
The syntax used for describing the
ObjectAttribute stereotype takes the
form:
Parameter_name
:
[other attributes]
Parameter_Type
Regarding the utility of
“
“,
parameter information icon, shown in
figure 8, the same remarks as in figure 7
apply.
Figure-8 InteractionParameter syntax and notation
Federate
Federate is a member of an HLA federation. It is
a binary software code (executable) that
simulates an entity, e.g., a vehicle. Multiplicity
can be applied to the federate stereotype.
Notation:
The recurring oval shapes describe multiplicity
information that specifies the number of
federates that participates in federation.
Figure-9 Federate stereotype
Conference on Simulation Methods and Applications, Orlando, 2000
about when an instance of this class
or one of its subclasses is generated
or updated during federation
execution.
3.3.3 Association Stereotypes:
Mask
A Mask association is used to mask the attributes
that are irrelevant in the derived class. All the
base class methods will be also masked.
Notation:
Attributes:
attribute_list_of_base_class
the list of attributes that will not be
inherited from the base class.
Notation:
Figure-11 Subscribe stereotype
3.3.5 Data Type Stereotypes:
PSKind
Figure-10 Mask stereotype
Publish
A publish association between HLAClass and
federate stereotypes indicates that the federate is
capable of generating of the instances of the
HLAClass. Publish association is a one-way
relation.
Attributes:
attribute_list
the list of attributes, which will be
generated and updated during
federation execution.
An enumeration that denotes the information on
publication and subscription capabilities of an
object class. Its enumerands are P, S, PS, and N
(explained in ObjectClass stereotype).
ISRKind
An enumeration that indicates the type of
interaction. Its enumerands are I, S, R, IS, IR, N
(explained in InteractionClass stereotype).
URKind
An enumeration to identify the permissions for a
federate in terms of attribute updating and
reflection. Its enumerands are U, R, and UR
(explained in ObjectAttribute stereotype).
Notation:
TAKind
An enumeration that identifies the transfer
characteristics of an attribute. Its enumerands are
T, A, TA, N (explained in ObjectAttribute
stereotype).
updateKind
Figure-11 Publish stereotype
An enumeration that identifies the update policies
for an attribute. Its enumerands are static,
periodic and conditional.
Subscribe
Subscribe is a one-way relation from HLAClass
to federate and it is used for declaring the
federate interests in the HLAClass.
Attributes:
attribute_list
the list of attributes that a
subscriber federate will be notified
3.4 Well-Formedness Rules
The set of rules presented here is not meant to be
complete. In particular, the constraints related to
DIF meta-data consistency (DoD 1998) have not
been formalized in OCL.
Conference on Simulation Methods and Applications, Orlando, 2000
HLAClass
[1] The value of the visibility attribute, derived
from the Feature element, is fixed as PUBLIC.
Context HLAClass inv:
self.visibility = #PUBLIC
[2]
The hierarchy between HLAClasses
(objectClass or InteractionClass) shall be
represented by single inheritance.
(Multiple inheritance is not allowed).
HLAClass.supertypes->size=1
HLAAttribute
[1] User-defined attribute names should be
different from those of the base attribute types.
userType.allsupertypes -> includes
(HLAClass) implies
userType.allsupertypes -> forall (q
| q.attributes ->
intersection
(userType.attributes).empty)
InteractionParameter
[1] All the InteractionParameters that reside in
the same InteractionClass shall have the same
routingSpace value.
InteractionClass.attributes ->
forall (a1,a2| a1.routingSpace =
a2.routingSpace)
fd.name.substring(fd.name.size-2,
fd.name.size) = ‘Fd’
Publish/Subscribe
See Table 2 for valid association stereotype
combinations.
FOM
[1] The PS attribute designations for an
ObjectClass in a FOM shall be taken from the
restricted set {S, PS, N}.
context FOM::ObjectClass
inv:self.PS <> #P
[2] InteractionClass specified in a FOM may
choose appropriate ISR attribute designations
with the exception of the singular {I} value.
context FOM::InteractionClass inv:
self.ISR <> #I
[3] All attributes of an ObjectClass in a FOM
should be both updateable and reflectable. (In
other words, the value of an UR attribute of an
ObjectClass must be {UR}).
FOM::UserType.allsupertypes ->
includes (ObjectClass) implies
FOM::UserType.attributes -> forall
(a | a.UR = #UR)
[4] In a FOM, the valid values for TA attribute of
an ObjectClass are from the set {TA, N}.
Federate
[1] Federate names shall be ended with the “Fd”
suffix (e.g., shipFd, restaurantFd).
context FOM::ObjectClass inv:
Set {#TA,#N} -> includes
(self.ISR).
context fd: Federate inv:
Table-2 Valid Relation Combinations
4. CONCLUSIONS
Motivated by the need for a well-founded visual
notation for federation design, this paper presents
a roadmap for a UML extension to support HLA
federation design and development, and takes the
initial step by providing a visual notation for
HLA object model design.
The proposed extension to UML is not meant to
supplant
the
tabular
format
of
Conference on Simulation Methods and Applications, Orlando, 2000
HLA OMT; on the contrary, the OMT standard
constitutes a semantic basis for the proposed
profile. The aim is to define a visual layer on top
of OMT and to guide tool development for HLA
federation design.
Future Work:
 The specification and development of a
UML extension for federation design
including the six management areas of HLA
Interface Specification.

The design and implementation of a CASE
tool for supporting the design and mapping
process that can be used in conjunction with
Object Model Development Tool (OMDT)
or a similar tool.
ACKNOWLEDGEMENT
The authors would like to thank Ilkay Altıntaş
for her help with OCL.
REFERENCES
Defense Modeling and Simulation Office
(DMSO). 1999. “HLA Federation Development
and Execution Process (FEDEP) Model, version
1.5”, 8 December 1999
Object Management Group (OMG). 1999. “OMG
Unified Modeling Language Specification,
version 1.3”, June 1999
U.S. Department of Defense (DoD). 1998. “Draft
Standard for Modeling & Simulation High Level
Architecture-Object Model Template”, IEEE
P1516.2, February 1998
AUTHOR BIOGRAPHIES
Ltjg. Okan Topçu is a Navy officer in Turkish
Navy and He is pursuing a PhD. degree in
Computer Engineering from Middle East
Technical University, Ankara, Turkey. Topcu
graduated from Turkish Naval Academy in 1993
in Computer Engineering Department and he
received M.S. degree in Computer Engineering
from METU in 1999. His last assignment is in the
Turkish General Staff as a network administrator.
Halit Oğuztüzün is an assistant professor in the
Department of Computer Engineering of the
Middle East Technical University, Ankara,
Turkey. He received B.S. and M.S. degrees in
Computer Engineering from METU in 1982 and
1984, and PhD in Computer Science from the
University of Iowa, Iowa City, IA in 1991. He is
also affiliated with the Modeling and Simulation
Laboratory
(MODSIMLAB)
at
METU.
Conference on Simulation Methods and Applications, Orlando, 2000