Next: 2.2 Physical Nodes
Up: 2. Concepts of ION
Previous: 2. Concepts of ION
Subsections
Class diagrams describe the static structure of an Object-Oriented
system primarily in terms of classes and relationships between them.
Beside classes and relationships, class diagrams in ION support the
concept of module to group classes.
ION supports six different types of classes: basic (standard)
classes, abstract classes, generic classes, persistent classes, active
classes and protected classes. Basic, abstract and
generic class mean the same as in UML.
- A persistent class is for objects that are stored between
different executions of the same program. A class for
persistent objects is represented using a drum icon.
- An active class has an independent thread of control. It
is represented with a thread icon.
- A protected class uses a synchronisation protocol to
control concurrent invocation of its methods. ION assumes the
existence of a library of protection protocols for mutual
exclusion; reader_writer, reader_writer with priority,
priority, cyclic execution, guarded methods, undefined protocol
etc. To use a synchronisation protocol, a subclass is defined
inheriting the required protection protocol. As a shorthand,
the required protocol may be depicted by a special icon in the
class icon.
In UML there is no equivalent to a persistent or protected class.
Similar to an active class an active object may be described in a
Collaboration Diagram ([RAT97a, P. 82]).
There is no construct in ION to model a public, private or protected
method. Both UML and ION lack the means to depict the final,
native, synchronised, transient and volatile modifiers used in Java.
All these keywords merit an explanation.
final:
- If the modifier final is applied to a variable it means that the
variable has a constant value. Final methods are those which
cannot be overridden. Final classes are those which cannot be
extended or subclassed (these classes are called sealed
in the dylan language, see [Sha92]).
-
native:
- This is a modifier that indicates that the method is implemented
elsewhere in some platform dependent way.
-
synchronized:
The synchronized keyword is a statement that marks a critical
section of code. The same keyword can also be used as a
modifier for class or instance methods. It indicates that the
method modifies the internal state of the class or the internal
state of an instance of the class in a way that is not
thread-safe. Before running a synchronized class method, Java obtains a lock on the class to ensure that no other threads can
modify the class concurrently. Before running a synchronized
instance method, Java obtains a lock on the instance that
invoked the method, ensuring that no other thread can modify the
object at the same time.
-
transient:
- This keyword is not yet implemented but may be applied to
instance variables in order to indicate that the variable is not
part of the persistent state of the object.
-
volatile:
- This modifier may be applied to variables in order to specify
that the variable changes asynchronously (e.g. it may be a
memory-mapped variable, a register variable, etc.).
An important aspect of the static structure of a program is its
organisation in terms of modules. ION supports the description of
various types of modules including files, directories (and directory
structures) and logical modules. Modules of any kind can be related
using the import relationship. This indicates that one module uses
(i.e. depends upon) information declared in the visible part of
another module.
The module structure of a program may be superimposed on the class
structure by rectangles surrounding the entities which contain them
([AI95, P. 24]). A simple rectangle without an addition
represents a logical module in the target language. A rectangle with
a dog ear corner indicates that the module is a file. A small folder
tag indicates a directory.
A module can be represented by a Package in UML. But, a
package is not restricted to classes. It can be used to group all
kinds of modeling elements in UML. There are no means to model
logical, file or directory packages as in ION. An overview over the
elements described so far is given in table 1.
ION supports three types of relationships between classes:
clientship relationships, inheritance relationships and generic
instantiation.
A clientship relationship exists when one object -the client,
manipulates (or uses) another object- the server, usually by calling
its methods. Clientship relationships come in several flavours and
are used to implement many of the different abstract relationships
identified in problem-oriented notations (e.g. part-of, has, uses,
association, aggregation, set membership, acquaintance etc.).
In ION, a clientship is always unidirectional and depicted by a
directed arrow. ION supports different kinds of clientships,
designated to give a precise description of the implementation details
of the relation.
-
-
Attached/Detached:
- If the client holds the actual value of the server, the
clientship is called attached, if the client holds a
reference to the server it is called detached.
-
Permanent/Transient:
- If the client holds the reference in its main data structure,
i.e. as an instance variable, the clientship is called
permanent. If the reference is passed as a parameter of
the method call or stored in a local variable then the
clientship is called transient.
-
Proper/Intimate:
- A clientship is called proper if the client has access
only to the public methods of the server. If the client can
access the internal methods, the clientship is called
intimate (e.g. in C++ this can be achieved by declaring
the client a friend of the server).
-
Direct/Indirect:
- If the client accesses the server via another server object, the
clientship is called indirect; otherwise direct.
A clientship may have more than one of these attributes and there may
be multiple clientships between classes.
To all these clientships, it is possible to attach additional
information using annotations. ION supports three kinds of
annotations.
- A procurement annotation distinguishes between a
exported, imported and local server.
- A call annotation can be used to indicate which methods
are called and what parameters are passed.
- A reference annotation can be used to identify the
name(s) a client object uses to refer to the server.
In UML a client relationship is called an association. An
association is a bidirectional semantic connection among instances
([RAT97b, P. 34]). Most of the information about an association
is attached to the association role. An association role is the face
that a type plays in an association ([RAT97b, P. 34]). The
possible attachments to an association role are multiplicity,
ordering, qualifier, navigability, aggregation indicator and a role
name (see [RAT97a, P. 38ff] for a detailed description). The
navigability denotes the direction of an association and is an
adornment to the association role. In UML, the direction may be
omitted.
In addition to association, UML supports more kinds of relationships.
- An aggregation is an association that denotes a
Whole/Part relationship. The aggregated instance may be
shared ([RAT97b, P. 37ff]).
- A composite aggregation is a strong aggregation. The
whole represents an abstraction over the aggregated parts. The
aggregated instances may not be shared.
- A dependency is a unidirectional using relationship from
a source to a target ([RAT97b, P. 4]).
- A refinement is a relationship between two descriptions
of the same thing at different levels of abstraction ([RAT97b, P. 31 ff]).
An inheritance relationship indicates that one class, the subclass,
reuses a part of another class, the superclass. Inheritance typically
corresponds to the concept of specialisation/generalisation in
problem-oriented notations. In ION, it is possible to describe
different kinds of inheritance. A subclass may be type compatible or
not type compatible with the superclass. In the latter case, it is not
a strict is-a relationship. A subclass may inherit from more than one
superclass (multiple inheritance). An inheritance relationship may be
annotated by the name of the methods that are concreted or redefined
by the subclass. At last, using a break symbol indirect inheritance
may be depicted.
An inheritance relationship is called Generalisation in UML.
An instance of the subtype must be substitutable for an instance of
the supertype ([RAT97b, P.36]). Additional semantics as multiple
inheritance can be permitted by semantic variation points
([RAT97b, P. 53]).
A generic class is one with one or more unbound parameters. The icon
is the same as for the normal class except that the boundary is
dashed. From a generic class, no objects can be instantiated.
Instead, a concrete class must be defined giving the actual
parameters. This is called generic instantiation. A generic
instantiation relationship is depicted by a dashed line. Optional,
the name(s) of the actual parameter(s) can be attached.
In UML, a generic class is called parameterised class
(template). The concrete class is defined by giving a bound
element to denote the substituted parameters ([RAT97a, P. 2]).
The concepts of relationship in ION and UML, described so far, are
compared in table 2.
![\begin{table}
\center
\begin{tabular}[t]{\vert l\vert l\vert l\vert l\vert} \hli...
...ation & annotations\\ \hline
\par\end{tabular}\caption{Relationships}\end{table}](img3.gif)
