Chapter 19: Interfaces and Components [Arlow and Neustadt, 2005] University of Nevada, Reno Department 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 2 Interfaces and Components

3  Chapter 19 roadmap, Fig [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 [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 5 Interfaces and Components

 Interface features that need to be realized, Table 19.1 [Arlow & Neustadt 2005] 6 Interfaces 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 7 Interfaces and Components

 The set of interfaces realized by a classifier is known as provided interfaces, with UML syntax (two styles) shown in Fig [Arlow & Neustadt 2005]  Note that the two different notations for the realization relationship 8 Interfaces and Components

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

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

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

 Interface: “realizes contract specified by”  Inheritance: “is a”  Both can generate polymorphism  Fig [Arlow & Neustadt 2005] shows an inheritance- based solution 12 Interfaces and Components

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

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

 Still better is to combine inheritance and interfaces, Fig [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 [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 [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 [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