22
1 CS 426 Senior Projects Chapter 19: Interfaces and Components [Arlow & Neustadt 2005] February 28, 2008

1 CS 426 Senior Projects Chapter 19: Interfaces and Components [Arlow & Neustadt 2005] February 28, 2008

  • View
    218

  • Download
    0

Embed Size (px)

Citation preview

11

CS 426Senior Projects

Chapter 19: Interfaces and Components

[Arlow & Neustadt 2005]

February 28, 2008

22

Outline

Interfaces and subsystems:IntroductionInterfacesInterface realization vs. inheritance ComponentsSubsystemsFinding interfacesThe layering patternAdvantages and disadvantages of interfaces

33

Introduction

Chapter 17 roadmap, Fig. 19.1 [Arlow & Neustadt, 2005]

44

Introduction Designing a subsystem is concerned with breaking a

system up into subsystems (as independent as possible)

Interactions between subsystems are mediated by interfaces. Fig. 19.2 [Arlow & Neustadt, 2005]

55

Interfaces

An interface specifies a named set of public features

It defines a contract to be implemented by a classifier

In other words, an interface defines a service offered by a class, component, or system

It also separates specification from implementation

An interface cannot be instantiated Anything that realizes an interface (e.g., a class) must accept and agree by the contract defined by the interface

66

Interfaces Interfaces allow “design to a contract” as compared to “design to an implementation” supported by classes

This provides a high degree of flexibility Modern software architectures are based on the concept of “service”, supported by interfaces

The attributes and operations of an interface should be fully specified, with: Complete operation signature The semantics of the operation (text or pseudocode) Name and type of the attributes Any operation or attribute stereotypes, constraints, tagged values

77

Interfaces The set of interfaces realized by a classifier is

known as provided interfaces, with UML syntax (two styles) shown in Fig. 19.3 [Arlow & Neustadt 2005]

Note that the two different notations for the realization relationship

88

Interfaces The set of interfaces needed by a classifier for

its operations are called required interfaces, with UML syntax shown in Fig. 19.4 [Arlow & Neustadt 2005]

Note that the two different notations for the dependency relationship, with the socket symbol in the right-hand side

99

Interfaces Fig. 19.5 [Arlow & Neustadt 2005] shows an example

of an assembled system

1010

Interfaces

Interfaces in Java: the

collection classes, Fig. 19.6

[Arlow & Neustadt 2005]

1111

Interface realization vs. inheritance

Interface: “realizes contract specified by”

Inheritance: “is a” Both can generate

polymorphism Fig. 19.7 [Arlow &

Neustadt 2005] shows an inheritance-based solution

1212

Interface realization vs. inheritance

Adding non-borrowable items such as journal needs further modelingFig. 19.8 [Arlow & Neustadt 2005]

1313

Interface realization vs. inheritance

A more elegant solution is shown in Fig. 19.9 [Arlow & Neustadt 2005]

1414

Interface realization vs. inheritance

Still better is to combine inheritance and interfaces, Fig. 19.10 [Arlow & Neustadt 2005] . Advantages: every item in the Library is a LibraryItem; borrowability concept factored out; fewer classes; simpler inheritance hierrachy; fewer compositions/inheritances

1515

Interfaces and component-based development

Interfaces are key elements for component-based development (CBD)

They allow addition of “plug-in” parts (with varied implementations) without changing the specification

Both with components and subsystems, interfaces support low coupling and provide high architectural flexibility

1616

Components A component is a modular part of the system that

encapsulates its contents and whose manifestation is replaceable within its environment

It acts as a black box whose external behavior is completely defined by its interfaces (provided and required); hence, it can be replaced by any other component that supports the same protocol

Fig. 19.15 [Arlow & Neustadt 2005] shows the UML notation

1717

Components Components may depend on other components To decouple components, always mediate the

dependency with interfaces, Fig. 19.17 [Arlow & Neustadt 2005]

1818

ComponentsComponent stereotypes, Table 19.2 [Arlow & Neustadt

2005]

1919

Subsystems

A subsystem is a component that acts as unit of decomposition for a larger system

Interfaces connect subsystems to create a system architecture

Subsystems are used to: Separate design concerns Represent large-grained components

Wrap legacy systems A system example is shown in Fig.

19.19 [Arlow & Neustadt 2005]

2020

Finding Interfaces

Techniques for finding interfaces in a designed system or subsystem:Challenge each associationChallenge each message sentFactor out groups of operations reusable elsewhereFactor out sets of operations that repeat in classes

Factor out sets of attributes that repeat in classes

Look at classes that have similar roles in the system

Consider future extensions

2121

Architecture and the layering pattern

Fig. 19.20 [Arlow & Neustadt 2005]

2222

Advantages and disadvantages of interfaces

Designing with interfaces increases flexibility and extensibility

Also, using interfaces supports low coupling by reducing the number of dependencies between classes, subsystems and components

With interfaces, a model can be neatly separated in cohesive subsystems

Drawbacks of interfaces relate to added complexity and increased performance costs

As a guideline, use interfaces for the more “fluid” parts of the system and dispense of them for the more stable parts of the system