Post on 21-Jan-2016
Chapter 19: Interfaces and Components
[Arlow and Neustadt, 2005]
University of Nevada, RenoDepartment of Computer Science & Engineering
Outline
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
1 Introduction
Chapter 19 roadmap, Fig. 19.1 [Arlow & Neustadt, 2005]
4
1 Introduction
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]
2 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
5Interfaces and Components
2 Interfaces
Interface features that need to be realized, Table 19.1 [Arlow & Neustadt 2005]
6Interfaces and Components
2 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
7Interfaces and Components
2 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
8Interfaces and Components
2 Interfaces
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
9Interfaces and Components
2 Interfaces
Fig. 19.5 [Arlow & Neustadt 2005] shows an example of an assembled
system
10
Interfaces and Components
2 Interfaces
Interfaces in Java: thecollection classes, Fig. 19.6 [Arlow & Neustadt 2005]
11
Interfaces and Components
3 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
12
Interfaces and Components
3 Interface realization vs. inheritance
Adding non-borrowable items such as journal needs further modelingFig. 19.8 [Arlow & Neustadt 2005]
13
Interfaces and Components
3 Interface realization vs. inheritance
A more elegant solution is shown in Fig. 19.9 [Arlow & Neustadt 2005]
14
Interfaces and Components
3 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 and inheritances
15
Interfaces and Components
4 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
16
Interfaces and Components
4 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
4 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
4 Components
Component stereotypes, Table 19.2 [Arlow & Neustadt 2005]
5 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]
20
Interfaces and Components
6 Finding Interfaces
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
7 Architecture and the layering pattern
8 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
24
Interfaces and Components