Interfaces & Subsystems
Primary Unified Process Models
Requirements Use Case Model
Analysis Analysis Model
Design Design Model
Deployment implemented by
Design Workflow Responsibilities
Design Design Interface
An interface specifies a named set of operations.
The key idea behind interfaces is to separate the
specification of functionality (the interface) from its
implementation by a classifier such as a class or
subsystem. The interface defines the contract that
is implemented by the classifier.
Interfaces become architecturally very important in
design, as they provide the “plugs and sockets” that
allow you to connect your design subsystem
together without connecting specific classes in those
Each operation in an interface must have:
– the complete operation signature (name, types of all parameters, and
– the semantics of the operation - this can be recorded as text or
– optionally, a stereotype, and sets of constraints and tagged values.
Interfaces may not have:
– operation implementation;
– relationships navigable from the interface to anything else.
– never specifies any kind of implementation
Once the interface is defined, then everything else in the
system that needs the interface service will simply realize this
Interfaces – Notations 1
“Class” Style Notation
Operations are «interface»
Zone 1 * Sensor
Use the “class” notation when
you need to show the
operations on the model
Interfaces – Notations 2
“Lollipop” Style Notation
Zone * Sensor
Use the shorthand “lollipop”
notation when you just want to
show the interface without
Interfaces – Key to Component-based Development (CBD)
CBD is about constructing software from plug-in
You must design interfaces if you want “plug-and-
play” software components where you can plug new
implementations at will.
Interfaces allow you to connect things together
without introducing coupling to specific classes
Interfaces Example - Printer
The Printer class knows how to print anything that
implements the Print interface.
This interface defines a single abstract polymorphic method
This method must be implemented by all classes that
implement Print. Notice that the Printer class is completely
decoupled and independent of the actual classes that
Interfaces Between Subsystems
You can use interfaces very effectively with subsystems
GUI subsystem only knows about the CustomerManager and
AccountManager interfaces – not anything about the
workings of the subsystem <<subsystem>>
When you have designed a system or part of a system, it is worth
examining the model to try and find some interfaces.
Do the following:
– Challenge each association - look at each one and ask the question, “Should
this association really be a particular class of objects, or should it be more
flexible that this?” If you decide that the association really needs to be more
flexible than it would be if it were tied to a particular class, then consider using
– Challenge each message send - look at each one and ask the question,
“Should this message send really be to objects of just one class, or should it
be more flexible than this?” If it should be more general (i.e. if you can think
of cases where the same message could be sent to objects of other classes)
then consider using an interface.
– Factor out groups of operations that might be reusable in more than one
– Look for classes that play the same role in the system - the role may indicate
a possible interface.
– Look for possibilities for future expansion. Sometimes, with just a little
forethought, you can design systems that can be expanded easily in the
future. The key question is, “In the future, will other classes need to be added
to the system?” If the answer is yes, try to define one or more interfaces that
will define the protocol for adding these new classes.
Interfaces - Advantages
When you design with classes, you are constraining the
design to specific implementations. But when you design
with interfaces, you are instead designing to contracts that
may be realized by many different implementations.
Designing to contracts frees the model (and ultimately the
system) from implementation dependencies and therefore
increases its flexibility and extensibility.
Designing with interfaces allows you to reduce the number of
dependencies between classes, subsystems, and
components and hence begins to give control over the
amount of coupling in a model. In a real sense, coupling is
the worst enemy of the object developer, as highly coupled
systems are hard to understand, maintain, and evolve.
Appropriate use of interfaces can help to reduce coupling and
to separate the model into cohesive subsystems.
Interfaces - Disadvantages
There are drawbacks in using interfaces.
– Generally speaking, whenever you make something more flexible you
make it more complex. When you design with interfaces, you are
looking for a trade-off between flexibility and complexity.
– There is often a performance cost to flexibility, but this is usually a
minor consideration compared to the increase in complexity.
When you design a system you are trying to capture a very
definite set of business semantics in software. Some of
these semantics are fluid and change quite rapidly, while
others are relatively stable.
– You need flexibility to help deal with the fluid aspects, but can simplify
systems by dispensing with a certain amount of flexibility for the more
– In a way, this is one of the secrets of good OOAD - identifying the
fluid and stable parts of a system and modeling each accordingly.
A very powerful use of interfaces is to provide the ability to
plug things in to systems.
One of the ways to make systems flexible and resilient to
change is to design the system such that extensions can be
plugged in easily.
Interfaces are the key to this.
If you can design systems around interfaces, then
associations and message sends are not longer tied to
objects of a particular class but instead are tied to a specific
interface. This makes it much easier to add new classes to a
system, as the interfaces define the protocols that the new
classes must support in order to plug in seamlessly.
What are subsystems?
– A subsystem is a package stereotyped <<subsystem>>. You use subsystems
in both design and implementation. These are known as design subsystems
and implementation subsystems.
Design subsystems contain:
– design classes and interfaces;
– use case realizations;
– other subsystems;
– specification elements such as use cases.
Subsystems are used to:
– separate design concepts;
– represent large-grained components;
– wrap legacy systems
Design subsystems are how you begin to “componentize” your model.
You break the analysis packages into one or more design subsystems
and also introduce new design subsystems that only contain artifacts from
the solution domain, such as database access classes or communications
Subsystem Example - Layers
<<subsystem>> <<subsystem>> <<subsystem>>
Order Customer Product
Data Access/Utility <<subsystem>>