described in alternative ways within the language. Con-
sequently, most practitioners prefer to use a subset of
the UML, rather than the full language.
To understand the different diagrams of the UML,
you can categorize the diagrams after what they sup-
port. Below the diagrams are listed as supporting re-
quirements, structural, communication or behavioral
work. For details of the diagrams, see Rational Software
[2000], Fowler and Scott [1999], and Larman [1998].
The Use Case diagram
The Use Case diagram shows the interaction be-
tween a user (human or other) and a software system.
This is basically a dependency relation where the user
depends on the system. The Use Case diagram primar-
ily supports requirements work.
The Class diagram
The Class diagram is basically an enhanced entity-
relationship diagram where the entities are classes with
name, attributes and actions. A “software class” can
then be seen as a “template” from which instances are
created to implement the software. The diagram in-
cludes several kinds of relations such as generalization,
association, and aggregation. The diagram can be used
for conceptual modeling, for specification and for docu-
menting a software solution. The Class diagram primar-
ily supports structural work.
The Sequence diagram
Message sequence charts have a long tradition for
visualizing the interaction between concurrent proc-
esses communicating by way of messages. These charts
are included in the UML as Sequence diagrams. The
Sequence diagram supports communication.
The Collaboration diagram
The Collaboration diagram resembles Structured
Analysis diagrams with its “boxes and arrows”. It basi-
cally contains the same information as the Sequence
diagram, which is why it also supports communication.
The Component diagram
The Component diagram shows dependencies be-
tween components and can also be drawn to show
aggregation (components included in other compo-
nents). It supports modeling of system structures, show-
ing how the different components in a system depend
on each other.
The Package diagram
The Package diagram shows dependencies between
major system components. Consequently, it is an alter-
native for modeling of system structures.
The State diagram
The State diagram is well proven to visualize behav-
ior. It is used to model behavior within a system com-
ponent.
The Activity diagram
The Activity diagram is an enhancement of the well-
proven flow chart. Like the State diagram it can be used
to visualize behavior.
The Deployment diagram
The Deployment diagram shows how different soft-
ware objects are distributed on hardware nodes. Conse-
quently, it is used to supplement structural descriptions.
The listing above shows some of the richness of the
UML. It is obvious that definition of a simple SEML
from the UML requires that you limit the UML to a
subset of the language, possibly with some extensions,
wherever the UML does not completely meet the re-
quirements for an SEML. To find the right subset, you
must first return to the basics of Systems Engineering.
3. BACK TO BASICS
The first concern in system modeling is to find a nota-
tion to model the system’s architectural structure. You
must then decide on how to relate the different structural
elements to each other. Some alternatives are:
• Aggregation with the main relation being “con-
tained in”. Used in “Structured Analysis” [De-
Marco, 1979].
• Inheritance with the main relation being “is de-
rived from.” Supported by the UML Class dia-
gram.
• Communication, with the main relations being
“sends to,” “receives from,” and “invokes.” Used
in “Structured Analysis” and SADT with the
IDEF0 notation [Marca and McGowen, 2000].
• Dependency with the main relation being “de-
pends on.” Supported by the UML Component
and Class diagrams with the Component diagram
being the simplest since it contains only system
components (objects) and their dependencies.
Since you need to model not only system compo-
nents, but also abstractions such as Missions and Abili-
ties, and since you want to keep the modeling notation
simple, the obvious choice, within the UML, is the
Component diagram.
Figure 1 shows a system outlined as a UML compo-
nent diagram with components (objects) on different
214 ÖGREN