n
March 11, 1998
Abstract
The embedded real-time software systems encountered in applications such
as telecommunications, aerospace, and defense typically tend to be large and
extremely complex. It is crucial in such systems that the software is designed with a
sound architecture. A good architecture not only simplifies construction of the initial
system, but even more importantly, readily accommodates changes forced by a
steady stream of new requirements. In this paper, we describe a set of constructs that
facilitate the design of software architectures in this domain. The constructs, derived
from field-proven concepts originally defined in the ROOM modeling language, are
specified using the Unified Modeling Language (UML) standard. In particular, we
show how these architectural constructs can be derived from more general UML
modeling concepts by using the powerful extensibility mechanisms of UML. 2
04/08/98
1.

Introduction
We apply the Unified Modeling Language (UML [2], [3]) to describe a set of
constructs suitable for modeling an important category of real-time software systems.
They are derived from the set of concepts initially defined in the ROOM modeling
language [1].
1.1

The Application Domain
The one common feature of all real-time software systems is timeliness; that
is, the requirement to respond correctly to inputs within acceptable time intervals.
However, this ostensibly simple property characterizes a vast spectrum of very
different types of systems ranging from purely time-driven to purely event-driven
systems, from soft real-time systems to hard real-time systems, and so on. Over time,
each of these categories of systems has developed its own idioms, design patterns,
and modeling styles that collectively capture the distilled experience of many projects.
In this document we focus on a major category of real-time systems that are
characterized as complex, event-driven, and, potentially, distributed. Such systems
are most frequently encountered in telecommunications, aerospace, defense, and
automatic control applications. The size and complexity of these systems demand a
considerable initial development effort, typically involving large development teams,
that is followed by an extended period of evolutionary growth. During this time new
requirements are identified and the system is modified incrementally to meet them.
Under such circumstances an overriding concern is the architecture of the
software. This refers to the essential structural and behavioral framework on which all
other aspects of the system depend. This is the software equivalent of the load-
bearing frames in buildings any changes to this foundation necessitates complex
and costly changes to substantial parts of the system. Therefore, a well-designed
architecture is not only one that simplifies construction of the initial system, but more
importantly, one that easily accommodates changes forced by new system
requirements.
To facilitate the design of good architectures, it is extremely useful to capture
the proven architectural design patterns of the domain as first-class modeling
constructs. This is why ROOM, among other things, incorporates concepts that
constitute a domain-specific architectural definition language. These constructs have
been in use for over a decade and have proven their effectiveness across hundreds of
diverse large-scale industrial projects. We have found that this domain-specific usage
can be cleanly implemented using the general-purpose UML.
1.2

The Use of UML
As noted earlier, UML was used to capture these constructs. We found it very
well suited to this purpose so that no new UML modeling concepts were needed. The
standard UML tailoring mechanisms based on stereotypes, tagged values, and
constraints were used to great effect. For example, the central actor concept of
ROOM is captured by the �capsule� stereotype a specialization of the general UML
concept of a class. This stereotype adds additional domain-specific semantics onto
the various aspects that are associated with a UML class (e.g., state machines, 3
04/08/98
collaborations). The stereotype facility provides a simple shorthand way of referring to
the collection of well-formedness rules that specify these semantics.
In effect, the modeling constructs described in this document represent a
type of library of applied UML concepts intended primarily for use in modeling the
architectures of complex real-time systems. They are used in combination with all the
other UML modeling concepts and diagrams to provide a comprehensive modeling
toolset.
1.3

Acknowledgements
We would like to express our gratitude to Grady Booch and Ivar Jacobson
who reviewed drafts of this document and provided valuable feedback and many
helpful suggestions on optimal ways to render these constructs in UML. 4
04/08/98
2.

Modeling Constructs and Notation
In this section we examine the most important modeling constructs used for
representing complex real-time systems and also describe how they are captured and
rendered using UML. The constructs can be partitioned into two major groups:
constructs for modeling structure and constructs for modeling behavior.
2.1

Modeling Structure
The structure of a system identifies the entities that are to be modeled and
the relationships between them (e.g., communication relationships, containment
relationships). UML provides two fundamental complementary diagram types for
capturing the logical structure of systems: class diagrams and collaboration diagrams.
Class diagrams capture universal relationships among classes those relationships
that exist among instances of the classes in all contexts.

Collaboration diagrams
capture relationships that exist only within a particular context a pattern of usage for
a particular purpose that is not inherent in the class itself. Collaboration diagrams
therefore include a distinction between the usage of different instances of the same
class, a distinction captured in the concept of role. In the modeling approach
described here, there is a strong emphasis on using UML collaboration diagrams to
explicitly represent the interconnections between architectural entities. Typically, the
complete specification of the structure of a complex real-time system is obtained
through a combination of class and collaboration diagrams.
Specifically, we define three principal constructs for modeling structure: capsules ports connectors
Capsules correspond to the ROOM concept of actors. They are complex,
physical, possibly distributed architectural objects that interact with their surroundings
through one or more signal-based
1
boundary objects
2
called ports. A port is a physical
part of the implementation of a capsule that mediates the interaction of the capsule
with the outside world it is an object that implements a specific interface. Each port
of a capsule plays a particular role in a collaboration that the capsule has with other
objects. To capture the complex semantics of these interactions, ports are associated
with a protocol that defines the valid flow of information (signals) between connected
ports of capsules. In a sense, a protocol captures the contractual obligations that exist
between capsules. Protocols are discussed in more detail in the section dealing with
behavior (2.2.1). By forcing capsules to communicate solely through ports, it is
possible to fully de-couple their internal implementations from any direct knowledge
about the environment. This makes them highly reusable.

1
In distributed systems where one cannot generally assume shared address spaces, signal-based interactions are
more appropriate than operation-based interactions. Note that, in UML, signal-based interactions can model both
synchronous and asynchronous communications.
2
The term boundary object is used in the same sense as in the UML Extension for Objectory Process for
Software Engineering[4]; that is, an object that lies on the periphery of a system, but within it. Ports represent a
particular type of boundary object. 5
04/08/98
Connectors, which correspond to ROOM bindings, are abstract views of
signal-based communication channels that interconnect two or more ports. The ports
bound by a connection must play mutually complementary but compatible roles in a
protocol. In collaboration diagrams, they are represented by association roles that
interconnect the appropriate ports. If we abstract away the ports from this picture,
connectors really capture the key communication relationships between capsules.
These relationships have architectural significance since they identify which capsules
can affect each other through direct communication. Ports are included to allow the
encapsulation of capsules under the principles of information hiding and separation of
concerns.
The functionality of simple capsules is realized directly by the state machine
associated with the capsule. More complex capsules combine the state machine with
an internal network of collaborating sub-capsules joined by connectors. These sub-
capsules are capsules in their own right, and can themselves be decomposed into
sub-capsules. This type of decomposition can be carried to whatever depth is
necessary, allowing modeling of arbitrarily complex structures with just this basic set
of structural modeling constructs. The state machine (which is optional for composite
capsules), the sub-capsules, and their connections network represent parts of the
implementation of the capsule and are hidden from