1. CS 5150 1 CS 5150 Software Engineering Lecture 17 Object Oriented Design 3

2. CS 5150 2 Administration

3. CS 5150 3 Additional Reading Roman Stolper has suggested the following additional reading on design patterns: The book that he mentioned in class: On O'Reilly website: http://oreilly.com/catalog/9780596007126 On Amazon: http://www.amazon.com/First-Design- Patterns-Elisabeth-Freeman/dp/0596007124 Also, a second book: http://www.codersatwork.com/

4. CS 5150 4 Test 3 Question 2 (part) Phase 1. The product database will remain unchanged but the web interface will be replaced by the ordering system. Phase 2. A new product database will be created. For the interface between the ordering system and the product database, select a design pattern that will allow the product database to be replaced in Phase 2 without modifications to the ordering system. Draw a UML class diagram that shows how this design pattern will be used in Phase 1.

5. CS 5150 5 Test 3 Question 2 The Problem OldProductDB Ordering System OldClient Phase2ProductDB The key to this problem is that OldProductDB has a legacy interface, which cannot be changed. The Phase 1 design must accommodate this interface. Future (Phase 2)Legacy System

6. CS 5150 6 Test 3 Question 2 Phase 1: Adapter Design Pattern OderingSystemInterfaceAdapterOldProductDB Ordering System Abstract class shown in italic. This is the interface planned for Phase 2. inheritance

7. CS 5150 7 Test 3 Question 2 The Bridge design pattern is not suitable for wrapping legacy code, because the legacy code does not subclass the ProductDBInterface abstract class. ProductDBInterface Phase2ProductDB OldProductDB Interface planned for Phase 2.

8. CS 5150 8 UML Notation for Classes and Objects ClassesObjects AnyClass attribute1 attribute2 operation1() operation2() AnyClass or anObject:AnyClass :AnyClass anObject The names of objects are underlined. or

9. CS 5150 9 Notation: Active Class EventManager eventlist suspend() flush() An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. When instantiated, the class controls its own execution, rather than being invoked or activated by other objects.

10. CS 5150 10 Modeling Dynamic Aspects of Systems Interaction diagrams: set of objects and their relationships including messages that may be dispatched among them Sequence diagrams: time ordering of messages

11. CS 5150 11 Interaction: Informal Bouncing Ball Diagrams Example: execution of http://www.cs.cornell.edu/ Client Servers domain name service TCP connection HTTP get

12. CS 5150 12 Notation: Interaction display An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose.

13. CS 5150 13 Actions on Objects call return send create object destroy object returnCopy(c) okToBorrow()local status notifyReturn(b)asynchronous signal > stereotypes

14. CS 5150 14 Sequence Diagram: Borrow Copy of a Book BookBorrower libMem: LibraryMember theCopy:Copy theBook:Book borrow(theCopy) okToBorrow borrow In this diagram, time runs downwards

15. CS 5150 15 Sequence Diagram: Change in Cornell Program Cornellian :MEngStudent 1 : getName() sequence numbers added to messages :PhDStudent 1.1 : name 2: > PhDStudent(name) 3: >

16. CS 5150 16 Sequence Diagram: Painting Mechanism :Thread:Toolkit:ComponentPeertarget:HelloWorld run callbackLoop handleExpose paint

17. CS 5150 17 Software Reuse It is often good to vary a program design to reuse existing software. This can lead to better software at lower cost. Potential benefits of reuse Reduced development time and cost Improved reliability of mature components Shared maintenance cost Potential disadvantages of reuse Difficulty in finding appropriate components Components may be a poor fit for application Quality control and security may be unknown

18. CS 5150 18 Software Reuse: Examples System software device drivers file systems exception handling network protocols Subsystems database management systems firewalls web servers

19. CS 5150 19 Software Reuse Examples (Tools) Standard functions mathematical methods formatting User interface toolkits (e.g. Motif graphics toolkit) class libraries, (e.g., Swing for Java)

20. CS 5150 20 Design for Reuse: Application Packages Application package supports a standard application (e.g., payroll) Functionality can be enhanced by: => configuration parameters (e.g., table driven) => extensibility at defined interfaces => custom written source code extensions

21. CS 5150 21 Reuse and Object Oriented Languages: Class Hierarchies Example: Java Java is a relatively straightforward language with a very rich set of class hierarchies. Java programs derive much of their functionality from standard classes Learning and understanding the classes is difficult. Experienced Java programmers can write complex systems quickly Inexperienced Java programmers write inelegant and buggy programs

22. CS 5150 22 Design for Reuse: Inheritance and Abstract Classes Classes can be defined in terms of other classes using inheritance. The generalization class is called the superclass and the specialization is called the subclass. If the inheritance relationship serves only to model shared attributes and operations, i.e., the generalization is not intended to be implemented, the class is called an abstract class

23. CS 5150 23 Design for Reuse: Specification Inheritance Specification Inheritance The classification of concepts into type hierarchies, so that an object from a specified class can be replaced by an object from one of its subclasses. In particular: Pre conditions cannot be strengthened in a subclass. Post conditions cannot be weakened in a subclass.

24. CS 5150 24 Design for Reuse: Specification Inheritance Liskov Substitution Principle (strict inheritance) If an object of type S can be substituted in all the places where an object of type T is expected, then S is a subtype of T. Interpretation The Liskov Substitution Principle means that if all classes are subtypes of their superclasses, all inheritance relationships are specification inheritance relationships. New subclasses of T can be added without modifying the methods of T. This leads to an extensible system.

25. CS 5150 25 Design for Reuse: Delegation Delegation A class is said to delegate to another class if it implements an operation by resending a message to another class. Delegation is an alternative to inheritance that should be used when reuse is anticipated. For a discussion of design for reuse see the book by Bruegge and Dutoit in the readings.

26. CS 5150 26 Reuse: Design for Replacement of Components The software design should anticipate possible changes in the system over its life-cycle. New vendor or new technology Components are replaced because its supplier goes out of business, ceases to provide adequate support, increases its price, etc., or because better software from another sources provides better functionality, support, pricing, etc. This can apply to either open-source or vendor-supplied components.

27. CS 5150 27 Reuse: Design for Replacement of Components New implementation The original implementation may be problematic, e.g., poor performance, inadequate back-up and recovery, difficult to trouble-shoot, or unable to support growth and new features added to the system. Example. The portal nsdl.org was originally implemented using uPortal. This did not support important extensions that were requested and proved awkward to maintain. It was reimplemented using PHP/MySQL.

28. CS 5150 28 Reuse: Design for Replacement of Components Additions to the requirements When a system goes into production, it is usual to reveal both weaknesses and opportunities for extra functionality and enhancement to the user interface design. For example, in a data-intensive system it is almost certain that there will be requests for extra reports and ways of viewing the data. Requests for enhancements are often the sign of a successful system. Clients recognize latent possibilities.

29. CS 5150 29 Reuse: Design for Replacement of Components Changes in the application domain Most application domains change continually, e.g., because of business opportunities, external changes (such as new laws), mergers and take-overs, new groups of users, etc., etc., It is rarely feasible to implement a completely new system when the application domain changes. Therefore existing systems must be modified. This may involve extensive restructuring, but it is important to reuse existing code as much as possible.