UML diagram legend & glossary

[Joseph Baran <joebaran@extol.com>]

To the RR team:

In the Tokyo meeting, the RR team invited the QR team for a preliminary 
review of the RR documents.

One of the comments made at that time was that the use of UML diagrams 
should be made more understandable for the benefit of those (such as 
myself!) who have not exactly been immersed in UML.

I understand that the use of UML in the specs is simply that of a 
documentation convention, and I think it serves the purpose well. As I said 
in Tokyo, sometimes a picture is really worth a thousand words. However, 
some participants have continued to be concerned about the use of UML in 
ebXML specs, even if only as a documentation method.

As a minimum, a "legend" of diagram notation, and a glossary of 
UML-specific terminology could go a long way towards resolving those 
concerns.

Attached below is my attempt at providing these. There is a small .gif 
image showing the notational conventions used in a UML class diagram, and a 
subset of the Glossary from the UML 1.3 spec. The editing of the Glossary 
is simply my own (perhaps biased) attempt at shortening it, retaining the 
terms which appear (at least to me) to be frequently used and/or frequently 
misunderstood.

Perhaps the inclusion of something such as these as an appendix would be 
appropriate - or maybe they really belong in the overall ebXML Glossary. In 
any case, they should (IMHO) be _somewhere_ in the ebXML documents if UML 
notation is to be used in the ebXML documents.

Joe Baran

Attachments:

"gif" of Class Diagram notation:

 

Excerpt from UML spec glossary (in RTF form):

 
Plain text copy (for the RTF-challenged):

UMLGlossary.rtf

Excerpted from the Glossary of:

OMG Unified Modeling Language Specification Version 1.3 March 2000
Copyright © 2000, Object Management Group (and others...)



Notation Conventions

The entries in the glossary usually begin with a lowercase letter. An initial uppercase
letter is used when a word is usually capitalized in standard practice. Acronyms are all
capitalized, unless they traditionally appear in all lowercase.

When one or more words in a multi-word term is enclosed in brackets, it indicates that
those words are optional when referring to the term. For example, use case [class] may
be referred to as simply use case.

The following conventions are used in this glossary:
• Contrast: <term>
Refers to a term that has an opposed or substantively different meaning.

• See: <term>
Refers to a related term that has a similar, but not synonymous meaning.

• Synonym: <term>
Indicates that the term has the same meaning as another term, which is referenced.

• Acronym: <term>
Indicates that the term is an acronym. The reader is usually referred to the spelled-out
term for the definition, unless the spelled-out term is rarely used.



Glossary terms:

aggregate [class] A class that represents the “whole” in an aggregation
(whole-part) relationship. See: aggregation.

aggregation A special form of association that specifies a whole-part
relationship between the aggregate (whole) and a
component part. See: composition.

association The semantic relationship between two or more
classifiers that specifies connections among their
instances.

association class A model element that has both association and class
properties. An association class can be seen as an
association that also has class properties, or as a class
that also has association properties.

association end The endpoint of an association, which connects the
association to a classifier.

attribute A feature within a classifier that describes a range of
values that instances of the classifier may hold.

cardinality The number of elements in a set. Contrast:
multiplicity.

class A description of a set of objects that share the same
attributes, operations, methods, relationships, and
semantics. A class may use a set of interfaces to
specify collections of operations it provides to its
environment. See: interface.

classifier A mechanism that describes behavioral and structural
features. Classifiers include interfaces, classes,
datatypes, and components.

class diagram A diagram that shows a collection of declarative
(static) model elements, such as classes, types, and
their contents and relationships.

composite [class] A class that is related to one or more classes by a
composition relationship. See: composition.

composite aggregation
Synonym: composition.

composition A form of aggregation association with strong
ownership and coincident lifetime as part of the
whole. Parts with non-fixed multiplicity may be
created after the composite itself, but once created
they live and die with it (i.e., they share lifetimes).
Such parts can also be explicitly removed before the
death of the composite. Composition may be
recursive. Synonym: composite aggregation.

dependency A relationship between two modeling elements, in
which a change to one modeling element (the
independent element) will affect the other modeling
element (the dependent element).

diagram A graphical presentation of a collection of model
elements, most often rendered as a connected graph of
arcs (relationships) and vertices (other model
elements). UML supports the following diagrams:
class diagram, object diagram, use case diagram,
sequence diagram, collaboration diagram, state
diagram, activity diagram, component diagram, and
deployment diagram.

generalization A taxonomic relationship between a more general
element and a more specific element. The more
specific element is fully consistent with the more
general element and contains additional information.
An instance of the more specific element may be used
where the more general element is allowed. See:
inheritance.

implementation A definition of how something is constructed or
computed. For example, a class is an implementation
of a type, a method is an implementation of an
operation.

implementation inheritance
The inheritance of the implementation of a more
specific element. Includes inheritance of the interface.
Contrast: interface inheritance.

inheritance The mechanism by which more specific elements
incorporate structure and behavior of more general
elements related by behavior. See generalization.

instance An entity to which a set of operations can be applied
and which has a state that stores the effects of the
operations. See: object.

interface A named set of operations that characterize the
behavior of an element.

interface inheritance The inheritance of the interface of a more specific
element. Does not include inheritance of the
implementation. Contrast: implementation
inheritance.

message A specification of the conveyance of information from
one instance to another, with the expectation that
activity will ensue. A message may specify the raising
of a signal or the call of an operation.

metaclass A class whose instances are classes. Metaclasses are
typically used to construct metamodels.

meta-metamodel A model that defines the language for expressing a
metamodel. The relationship between a meta-metamodel
and a metamodel is analogous to the
relationship between a metamodel and a model.

metamodel A model that defines the language for expressing a
model.
metaobject A generic term for all metaentities in a metamodeling
language. For example, metatypes, metaclasses,
metaattributes, and metaassociations.

method The implementation of an operation. It specifies the
algorithm or procedure associated with an operation.

model
An abstraction of a physical system, with a certain
purpose.. See: physical system.

multiplicity A specification of the range of allowable cardinalities
that a set may assume. Multiplicity specifications may
be given for roles within associations, parts within
composites, repetitions, and other purposes.
Essentially a multiplicity is a (possibly infinite) subset
of the non-negative integers. Contrast: cardinality.

object An entity with a well-defined boundary and identity
that encapsulates state and behavior. State is
represented by attributes and relationships, behavior is
represented by operations, methods, and state
machines. An object is an instance of a class. See:
class, instance.

object diagram A diagram that encompasses objects and their
relationships at a point in time. An object diagram
may be considered a special case of a class diagram
or a collaboration diagram. See: class diagram,
collaboration diagram.

sequence diagram A diagram that shows object interactions arranged in
time sequence. In particular, it shows the objects
participating in the interaction and the sequence of
messages exchanged. Unlike a collaboration diagram,
a sequence diagram includes time sequences but does
not include object relationships. A sequence diagram
can exist in a generic form (describes all possible
scenarios) and in an instance form (describes one
actual scenario). Sequence diagrams and collaboration
diagrams express similar information, but show it in
different ways. See: collaboration diagram.

use case [class] The specification of a sequence of actions, including
variants, that a system (or other entity) can perform,
interacting with actors of the system. See: use case
instances.

use case diagram A diagram that shows the relationships among actors
and use cases within a system.

use case instance The performance of a sequence of actions being
specified in a use case. An instance of a use case. See:
use case class.

use case model A model that describes a system’s functional
requirements in terms of use cases.