Interfaces and Components

Chapter 19 [Arlow and Neustadt, 2005]

CS 425Software Engineering

University of Nevada, RenoDepartment of Computer Science & Engineering

Interfaces and subsystems: Introduction Interfaces Interface realization vs. inheritance Components Subsystems Finding interfaces The layering pattern Advantages and disadvantages of interfaces

2Interfaces and Components

3

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

4

Designing large software applications 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]

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

5Interfaces and Components

Interface features that need to be realized, Table 19.1 [Arlow & Neustadt 2005]

6Interfaces and Components

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

7Interfaces and Components

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

8Interfaces and Components

The set of interfaces needed by a classifier for its operations are called required interfaces, as 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

9March 9, 2010 Interfaces and Components

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

system

10

Interfaces and Components

Interfaces in Java: thecollection classes, Fig. 19.6 [Arlow & Neustadt 2005]

11

Interfaces and Components

Interface: “realizes contract specified by”

Inheritance: “is a” Both can generate

polymorphism Fig. 19.7 [Arlow & Neustadt

2005] shows an inheritance-based solution

12

Interfaces and Components

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

13

Interfaces and Components

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

14

Interfaces and Components

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 and inheritances

15

Interfaces and Components

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

16

Interfaces and 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 behaviour 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

17

Interfaces and Components

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

interfaces, Fig. 19.17 [Arlow & Neustadt 2005]

18

Interfaces and Components

19

Component stereotypes, Table 19.2 [Arlow & Neustadt 2005]

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]

20

Interfaces and Components

Techniques for finding interfaces in a system or subsystem: Challenge each association Challenge each message sent Factor out groups of operations reusable elsewhere Factor 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

21

Interfaces and Components

22

23

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

24

Interfaces and Components