1. CS 240, Prof. Sarwar Slide 1 CS 240: Software Project Fall 2003 Sections 1 & 2 Dr. Badrul M. Sarwar San Jose State University Lecture #13

2. CS 240, Prof. Sarwar Slide 2 Agenda l Software Reuse:  Design Frameworks  Application families  Design patterns  Basics  Model-view-controller  Types  Example

3. CS 240, Prof. Sarwar Slide 3 Types of Reuse l Library or Toolkit (function level) l Application framework l COTS reuse l Application family l Design patterns

4. CS 240, Prof. Sarwar Slide 4 Reuse: Library or Toolkit l Set of reusable routines l Examples:  Scientific software  GUI class library or toolkit l The user is responsible for the control logic (white in figure)

5. CS 240, Prof. Sarwar Slide 5 Application Framework l Control logic of the design is reused l “Hot spots” (white in figure)  Application specific components l Faster than reusing toolkit l More of design is reused l The logic is usually harder to design than the operations l Example: a set of classes controlling an ATM. Designers need to supply only objects specific to the banking services

6. CS 240, Prof. Sarwar Slide 6 Application frameworks l Early proponents of OOD suggested that objects were the most appropriate abstractions for reuse but those are too fine-grained. l Frameworks are a sub-system design made up of a collection of abstract and concrete classes and the interfaces between them (coarser grained) l The sub-system is implemented by adding components to fill in parts of the design and by instantiating the abstract classes in the framework l Frameworks are moderately large entities that can be reused

7. CS 240, Prof. Sarwar Slide 7 Framework classes l Three classes of frameworks l System infrastructure frameworks  Support the development of system infrastructures such as communications, user interfaces and compilers. Ex. GUI frameworks l Middleware integration frameworks  Standards and classes that support component communication and information exchange. Ex. CORBA, COM/DCOM, Java Beans l Enterprise application frameworks  Support the development of specific types of application such as telecommunications or financial systems

8. CS 240, Prof. Sarwar Slide 8 Extending frameworks l As the name suggests, frameworks are generic and are extended to create a more specific application or sub- system l Extending the framework involves  Adding concrete classes that inherit operations from abstract classes in the framework  Adding methods that are called in response to events that are recognised by the framework l Problem with frameworks is their complexity and the time it takes to use them effectively

9. CS 240, Prof. Sarwar Slide 9 COTS product reuse l COTS - Commercial Off-The-Shelf systems l COTS systems are usually complete application systems that offer an API (Application Programming Interface) l Building large systems by integrating COTS systems is now a viable development strategy for some types of system such as E-commerce systems

10. CS 240, Prof. Sarwar Slide 10 COTS system integration problems l Lack of control over functionality and performance  COTS systems may be less effective than they appear l Problems with COTS system inter-operability  Different COTS systems may make different assumptions that means integration is difficult (one study shows using four different COTS, resulted in five times as much effort and four times as much time) l No control over system evolution  COTS vendors, not system users control evolution l Support from COTS vendors  COTS vendors may not offer support over the lifetime of the product

11. CS 240, Prof. Sarwar Slide 11 Component development for reuse l Components for reuse may be specially constructed by generalising existing components l Component reusability  Should reflect stable domain abstractions  Should hide state representation  Should be as independent as possible  Should publish exceptions through the component interface l There is a trade-off between reusability and usability.  The more general the interface, the greater the reusability but it is then more complex and hence less usable

12. CS 240, Prof. Sarwar Slide 12 Application families l An application family or product line is a related set of applications that has a common, domain-specific architecture l The common core of the application family is reused each time a new application is required l Each specific application is specialised in some way

13. CS 240, Prof. Sarwar Slide 13 Application family specialisation l Platform specialisation  Different versions of the application are developed for different platforms l Configuration specialisation  Different versions of the application are created to handle different peripheral devices l Functional specialisation  Different versions of the application are created for customers with different requirements

14. CS 240, Prof. Sarwar Slide 14 A resource management system architecture of a system for inventory management

15. CS 240, Prof. Sarwar Slide 15 Inventory management systems l Resource database  Maintains details of the things that are being managed l I/O descriptions  Describes the structures in the resource database and input and output formats that are used l Query level  Provides functions implementing queries over the resources l Access interfaces  A user interface and an application programming interface

16. CS 240, Prof. Sarwar Slide 16 Application family architectures l Architectures must be structured in such a way to separate different sub-systems and to allow them to be modified l The architecture should also separate entities and their descriptions and the higher levels in the system access entities through descriptions rather than directly

17. CS 240, Prof. Sarwar Slide 17 A library system

18. CS 240, Prof. Sarwar Slide 18 Library system l The resources being managed are the books in the library l Additional domain-specific functionality (issue, borrow, etc.) must be added for this application

19. CS 240, Prof. Sarwar Slide 19 Family member development

20. CS 240, Prof. Sarwar Slide 20 Family member development l Elicit stakeholder requirements  Use existing family member as a prototype l Choose closest-fit family member  Find the family member that best meets the requirements l Re-negotiate requirements  Adapt requirements as necessary to capabilities of the software l Adapt existing system  Develop new modules and make changes for family member l Deliver new family member  Document key features for further member development

21. CS 240, Prof. Sarwar Slide 21 Design Patterns l Often, we design and build systems that are similar in some respects to the systems we built before.  e.g., we may design and build a series of applications that have similar functionalities but run in different environments.  We want to take advantage of the commonalities among systems, so that we don’t develop each one from scratch l A popular way of identifying the commonalities is to look for “design patterns”. then we can reuse the patterns, as well as the code, tests, and documentation related to them, when we build the next system.

22. CS 240, Prof. Sarwar Slide 22 Design Pattern l A solution to a general design problem l In the form of a set of interacting classes l The classes need to be customized (white in figure)

23. CS 240, Prof. Sarwar Slide 23 Ex.: Model-view controller pattern l A widely used system infrastructure framework for GUI design l Allows for multiple presentations of an object and separate interactions with these presentations l MVC framework involves the instantiation of a number of patterns  Model: a set of classes that contain the stored information  View: a set of classes that implement the UI  Controller: controls the interaction between the UI and the stored data

24. CS 240, Prof. Sarwar Slide 24 Model-view controller View Model Controller

25. CS 240, Prof. Sarwar Slide 25 Design Patterns: Background l From objects and inheritance to design patterns  Application objects and solution objects  We’ve seen domain objects (application objects) that are relevant to the system and Solution objects--components that are not associated with the application domain e.g., UI, Middleware, data store objects

26. CS 240, Prof. Sarwar Slide 26 Problems with Inheritance Hashtable put (key, element) get (key): object containsKey (key): boolean containsValue(element): boolean MySet put (key, element) containsValue(element): boolean class MySet extends Hashtable { //constructors void put (Object element) { if (!containsKey (element)) { put (element, this); } boolean containsValue (Object element) { return containsKey(element); } //other methods }

27. CS 240, Prof. Sarwar Slide 27 Problems:  containsKey() checks if the specified object exists as a key in the hash table  containsValue() checks if the specified object exists as an entry in the hash table l But in the previous implementation containsValue() has the same behavior as the containsKey–counterintuitive. l Even worse, it makes it difficult to change the internal representation of MySet in future. For instance, if we want to implement MySet using list instead of hash table then all invocations to containsKey() would be invalid l Problem: inheritance introduces a strong coupling along the inheritance hierarchy l It is useful when the hierarchy represents a taxonomy e.g. Image and GIFImage, but in other cases it introduces unwanted coupling.

28. CS 240, Prof. Sarwar Slide 28 Solution: use of delegation Hashtable put (key, element) get (key): object containsKey (key): boolean containsValue(element): boolean MySet put (key, element) containsValue(element): boolean class MySet { private Hashtable table; MySet() { table = HashTable(); } void put (Object element) { if (!containsValue (element)) { table.put (element, this); } boolean containsValue (Object element) { return table.containsKey(element); } //other methods } table 1 1

29. CS 240, Prof. Sarwar Slide 29 More on Inheritance l Implementation inheritance and Specification inheritance  The se of inheritance for the sole purpose of reusing code is called the implementation inheritance. For example, a Set object can be inherited from a HashTable object. On the other hand, the classification of concepts into type hierarchies is called specification inheritance

30. CS 240, Prof. Sarwar Slide 30 Design Patterns: Background l Delegation:  Delegation is an alternative to inheritance that should be used when reuse is desired  A class is said to delegate to another class if it implements an operation by resending a message to another class  Delegation makes it explicit the dependencies between the reused class and the new class  It’s a preferable mechanism to implement inheritance as it doesn’t interfere with existing components and leads to more robust code l However, when to use delegation or inheritance is not always clear and requires some experience and judgment of the developer l Design patterns  are template solutions that developers have refined over time to solve a range of recurring problems  These are composed of a small number of classes that, through delegation and inheritance provide a robust and modifiable solution

31. CS 240, Prof. Sarwar Slide 31 Design patterns l A design pattern is a way of reusing abstract knowledge about a problem and its solution l A pattern is a description of the problem and the essence of its solution l It should be sufficiently abstract to be reused in different settings l Patterns often rely on object characteristics such as inheritance and polymorphism

32. CS 240, Prof. Sarwar Slide 32 Design Pattern elements l Name  A meaningful and unique pattern identifier l Problem description  describes the situations in which the patter can be used l Solution description  Not a concrete design but a template for a design solution that can be instantiated in different ways. It is a set of collaboration classes and interfaces l Consequences  The results and trade-offs of applying the pattern

33. CS 240, Prof. Sarwar Slide 33 Selecting Design Patterns and Components l System design and Object design with reuse introduce a strange paradox:  system design: the goal is to build a stable structure to deal with complexity; we build strong walls between subsystems  object design: we also want to allow flexibility to deal with changes and reuse; we design our objects to be modifiable and extensible l To solve this conflict: we need to anticipate changes and design for it so that it can handle:  New vendor or new technology  New implementation  New views  New complexity of the application domain  Errors

34. CS 240, Prof. Sarwar Slide 34 Types of Design Patterns l Here are a few Design Patterns that are widely used:  Adapter Design Pattern  Bridge Design Pattern  Strategy Design Pattern  Abstract Factory Design Pattern  Command Design Pattern  Composite Design Pattern

35. CS 240, Prof. Sarwar Slide 35 Adapter Design Patterns l Anticipated changes: New vendor, new technology, new implementation l Encapsulates a piece of legacy code that was not designed to work with the system l It also limits the impact of substituting the piece of legacy code for a different component.

36. CS 240, Prof. Sarwar Slide 36 Bridge Design Patterns l Anticipated changes: New vendor, new technology, new implementation l Decouples the interface of a class from its implementation l It serves the same purpose of an Adapter pattern except that the developer is not constrained by an existing component

37. CS 240, Prof. Sarwar Slide 37 Strategy Design Patterns l Anticipated changes: New vendor, new technology, new implementation l Decouples an algorithm from its implementation l It serves the same purpose of an Adapter and bridge patterns except that the encapsulated unit is a behavior

38. CS 240, Prof. Sarwar Slide 38 Abstract Factory Design Patterns l Anticipated changes: New vendor, new technology l Encapsulates the creation of families of related objects l It shields the client from the creation process and prevents the use of objects from different (incompatible) families

39. CS 240, Prof. Sarwar Slide 39 Abstract Factory Pattern l Abstract classes and abstract (virtual) methods l The interfaces between the client and the generator are abstract l The application program is uncoupled from the specific operating system

40. CS 240, Prof. Sarwar Slide 40 Command Design Patterns l Anticipated changes: New functionality l Decouples the objects responsible for command processing from the commands themselves l It protects these objects from changes due to new functionality

41. CS 240, Prof. Sarwar Slide 41 Composite Design Patterns l Anticipated changes: New complexity o the application domain l Encapsulates hierarchies by providing a common superclass for aggregate and leaf nodes. l New types of leafs can be added without modifying existing code.

42. CS 240, Prof. Sarwar Slide 42 The Observer pattern l Name  Observer l Description  Separates the display of object state from the object itself l Problem description  Used when multiple displays of state are needed l Solution description  See slide with UML description l Consequences  Optimisations to enhance display performance are impractical

43. CS 240, Prof. Sarwar Slide 43 The Observer pattern