Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 19: Interfaces and Components [Arlow and Neustadt, 2005] University of Nevada, Reno Department of Computer Science & Engineering.

Similar presentations


Presentation on theme: "Chapter 19: Interfaces and Components [Arlow and Neustadt, 2005] University of Nevada, Reno Department of Computer Science & Engineering."— Presentation transcript:

1 Chapter 19: Interfaces and Components [Arlow and Neustadt, 2005] University of Nevada, Reno Department of Computer Science & Engineering

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

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

4 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]

5  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 5 Interfaces and Components

6  Interface features that need to be realized, Table 19.1 [Arlow & Neustadt 2005] 6 Interfaces and Components

7  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 7 Interfaces and Components

8  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 8 Interfaces and Components

9  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 9 Interfaces and Components

10  Fig. 19.5 [Arlow & Neustadt 2005] shows an example of an assembled system 10 Interfaces and Components

11 Interfaces in Java: the collection classes, Fig. 19.6 [Arlow & Neustadt 2005] 11 Interfaces and Components

12  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

13  Adding non-borrowable items such as journal needs further modeling Fig. 19.8 [Arlow & Neustadt 2005] 13 Interfaces and Components

14  A more elegant solution is shown in Fig. 19.9 [Arlow & Neustadt 2005] 14 Interfaces and Components

15  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

16  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

17  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

18  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 19 Component stereotypes, Table 19.2 [Arlow & Neustadt 2005]

20  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

21  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 22

23 23

24  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


Download ppt "Chapter 19: Interfaces and Components [Arlow and Neustadt, 2005] University of Nevada, Reno Department of Computer Science & Engineering."

Similar presentations


Ads by Google