THE OBJECT-ORIENTED DESIGN WORKFLOWInterfaces & Subsystems

Use Case ModelRequirements

Analysis Model

Design Model

DeploymentModel

Implementation

Analysis

Design

Implementation

Test

specified by

Test Model

realized by

distributed by

implemented by

verified by

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

Primary Unified Process Models

Deployment

* From Unified Software Development Process [Jacobson, Booch, & Rumbaugh, 1999]

Design Workflow Responsibilities

ComponentEngineer

Interface

responsible for

DesignSubsytem

DesignClass

Interfaces

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 subsystems.

Interfaces (contd)

Each operation in an interface must have:– the complete operation signature (name, types of all parameters, and

return type);– the semantics of the operation - this can be recorded as text or

pseudocode;– optionally, a stereotype, and sets of constraints and tagged values.

Interfaces may not have:– attributes;– 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 interface

Interfaces – Notations 1

+activate()()+deactivate()()

Zone

+activate()()+deactivate()()

Sensor

Operations are polymorphic

“Class” Style Notation

*1

Use the “class” notation when you need to show the operations on the model

+activate()+deactivate()

«interface»Activate

Interfaces – Notations 2

+activate()()+deactivate()()

Zone

+activate()()+deactivate()()

Sensor*1

Activate

“Lollipop” Style Notation

Use the shorthand “lollipop” notation when you just want to show the interface without operations

Interfaces – Key to Component-based Development (CBD)

CBD is about constructing software from plug-in parts.

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 called print(g:Graphics)

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 implement Print

Customer

Order

Printer

Print

<<uses>>

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

GUI

BusinessLogic

CustomerManager AccountManager

<<subsystem>>

<<subsystem>>

Finding Interfaces

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 an interface.

– 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 class.

– 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 stable parts.

– 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.

Interfaces Conclusion

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.

Subsystems

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 classes.

Subsystem Example - Layers

Database

<<subsystem>>

Customer

<<subsystem>>

Product

<<subsystem>>

Order

<<subsystem>>

GUI

<<subsystem>>

Presentation

Business Logic

Data Access/Utility