Architectural Modeling

Interface

An interface is a collection of operations that are

used to specify a service of a class or a component.
Graphically, an interface is rendered as a circle
 Names
• The name of the interface must be unique within its enclosing package
• Every interface must have a name that distinguishes it from other
interfaces.
• A name is a textual string. It has two types :
– Simple name
– Path name
• Name alone is known as a simple name, a path name is the interface
name prefixed by the name of the package
 Operations

An interface is a named collection of operations used

to specify a service of a class or of a component.
• Interfaces are unlike classes, as they do not specify
any structure , nor do they specify any
[Link] a class, an interface may have
any number of operations.
These operations may be adorned with visibility
properties, stereotypes, and constraints etc.
 Operations
• The purpose of an interface, is to provide a clear
separation of what each operation does and how
those operations are meant to work together.
• To understand the current model, you can render an
interface as a stereotyped class, listing its operations
in the appropriate compartment.
 Relationships

• Similar to a class, an interface may participate in

generalization, association, and dependency relationships.
Also, an interface may participate in realization relationships.
• Realization is defined as a semantic relationship between two
classifiers in which one classifier specifies a contract that
another classifier guarantees to carry out.
• A class may realize many interfaces.
 Relationships
• An element realizes an interface in two ways.
– Simple form
– Expanded form
• The simple form interface and its realization relationship are
rendered as a lollipop sticking off to one side of a class or component.
• The expanded form interface render as a stereotyped class, which
allows you to visualize its operations and other properties.
• A realization relationship is rendered as a dashed directed line with a
large open arrowhead pointing to the interface.
• This notation is a cross between generalization and dependency.
Relationships
 Roles

• Each interface represents a role that the object

plays.
• A role, names a behavior of an entity participating
in a particular context.
• Stated another way, a role is the face that an
abstraction presents to the world.
 Packages
A package is a general-purpose mechanism for organizing
elements into groups. Graphically, a package is rendered
as a tabbed folder.
You can group model elements in packages for the
following reasons:
Organize the model elements so that the model is
easier to understand
Model the architecture of your system by using
packages to represent the various layers or subsystems
Every package must have a name that distinguishes it
from other packages.
 Owned Elements

A package may own other elements, including

classes, interfaces, components, nodes,
collaborations, use cases, diagrams, and even other
packages
Owning is a composite relationship, which means
that the element is declared in the package.
If the package is destroyed, the element is
destroyed.
Every element is uniquely owned by exactly one
package.
 Owned Elements

• A package forms a namespace, which means that

elements of the same kind must be named uniquely
within the context of its enclosing package.
• Different kinds of elements may have the same
name within a package.
• Packages may own other packages.
 Visibility

Like a class, the package also have visibility control

of the elements
An element owned by a package is public(+), which
means that it is visible to the contents of any package
that imports the element's enclosing package.
Protected(#) elements can only be seen by children
Private(-) elements cannot be seen outside the
package in which they are declared.
 Importing and Exporting
A in one package and B in another package, both
packages sitting side by side.
A and B are both declared as public parts of their
respective packages.
If A's package imports B's package, A can now see B,
although B cannot see A.
Importing grants a one-way permission for the
elements in one package to access the elements in another
package.
In the UML, an import relationship as a dependency
adorned with the stereotype import.
The public parts of a package are called its exports.
Importing and Exporting
 Generalization
• There are two kinds of relationships between packages:
– Import
If element import is public, the imported element will be added to
the namespace and made visible outside the package
Keyword «import» indicates public element import.
– Access
If element import is private, the imported element will be added to
the namespace but will not be visible outside the namespace.
Keyword «access» indicates private element import.
 Generalization example

• The package GUI is shown to export two classes (Window and

Form) and one protected class (EventHandler)
• The package WindowsGUI inherits from GUI, so it includes
the classes GUI::Window and GUI::EventHandler.
• In addition, WindowsGUI overrides one class (Form) and adds
a new one (VBForm).
 Instances
An instance is a concrete manifestation of an abstraction to
which a set of operations can be applied and which has a state
that stores the effects of the operations.
Graphically, an instance is rendered by underlining its name.
Abstractions and Instances
Most instances you'll model with the UML will be instances of
classes although you can have instances of other things, such
as components, nodes, use cases, and associations
In the UML, an instance is easily distinguishable from an
abstraction. To indicate an instance, you underline its name.
Names
• Every instance must have a name that distinguishes it from other instances
within its context. Typically, an object lives within the context of an operation, a
component, or a node.
• A name is a textual string. That name alone is known as a simple name. or it may
be a path name
Operations
• The operations you can perform on an object are declared in the object's
abstraction For example, if the class Transaction defines the operation commit,
then given the instance t : Transaction, you can write expressions such as
[Link]()
State
• An object also has state. An object's state is dynamic.
• It's possible to show the changing state of an object by showing it multiple times
in the same interaction diagram, but with each occurrence representing a
different state.
• When you operate on an object, you typically change its state;
Named Instances
 Process and Threads

• An active object is an object that owns a process or thread and

can initiate control activity.
• An active class is a class whose instances are active objects.
• A process is a heavyweight flow that can execute concurrently
with other processes.
• A thread is a lightweight flow that can execute concurrently
with other threads within the same process.
• Graphically, an active class is rendered as a rectangle with
thick lines.
• Processes and threads are rendered as stereotyped active
classes
 Active Class

Active classes are kinds of classes, so have all the usual

compartments for class name, attributes, and operations. Active
classes often receive signals, which you typically enumerate in an
extra compartment.
 Flow of Control

In a sequential system, there is one flow of control. This

means that only one thing , can take place at a time.
A control is rooted at the beginning of the program and
operations are dispatched one after another
In a concurrent system, there is more than one flow of
control that is, more than one thing can take place at a
time.
There are multiple simultaneous flows of control, each
rooted at the head of an independent process or a
thread.
 Classes and Events
An active class represents an independent flow of
control, whereas a plain class embodies no such flow.
The plain classes are implicitly called passive because
they cannot independently initiate control activity.
By modeling concurrent systems with active objects, you
give a name to each independent flow of control.
When an active object is created, the associated flow
of control is started;
when the active object is destroyed, the associated
flow of control is terminated.
An active objects may appear wherever passive objects
appear
 Standard Elements

The UML defines two standard stereotypes that apply

to active classes.
1. Process : Specifies a heavyweight flow that can
execute concurrently with other processes
2. Thread : Specifies a lightweight flow that can
execute concurrently with other threads within the
same process
 Communication
When objects collaborate with one another, they interact
by passing messages from one to the other.
In a system with both active and passive objects, there are
four possible combinations of interaction :
1. A message may be passed from one passive object to
another
2. A message may be passed from one active object to
another
3. A message may be passed from active object to a
passive object
4. A message may be passed from passive object to a n
active object
 Time and Space
• A timing mark is a denotation for the time at which an event
occurs.
• Graphically, a timing mark is formed as an expression from the
name given to the message.
• A time expression is an expression that evaluates to an
absolute or relative value of time.
• A timing constraint is a semantic statement about the relative
or absolute value of time.
• Graphically, a timing constraint is rendered as for any
constraint. That is, a string enclosed by brackets and generally
connected to an element by a dependency relationship.
• Events including time events
Time
 Space

• Location is the placement of a component on a node.

• Graphically, location is rendered as a tagged value.
That is, a string enclosed by brackets and placed
below an element's name, or as the nesting of
components inside nodes.
 Space

Reference:
1. Booch, Grady. The unified modeling language user
guide. Pearson Education India, 2005.