CS 5150 Software Engineering

1. CS 5150 Software Engineering Lecture 16 Object Oriented Design 2

2. Administration Progress reports • Weekly progress report is due tomorrow. • Next week is mid-semester break. No progress report is needed, but we will be reading email if you have questions.

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

4. Notation: Active Class EventManager eventlist suspend() flush() An active classis 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.

5. 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

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

7. Notation: Interaction display An interaction is a behavior that comprises a set of messagesexchanged among a set of objects within a particular context to accomplish a specific purpose.

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

9. Sequence Diagram: Borrow Copy of a Book libMem: LibraryMember theBook:Book BookBorrower theCopy:Copy borrow(theCopy) okToBorrow borrow borrow

10. Sequence Diagram: Change in Cornell Program :MEngStudent Cornellian 1 : getName() 1.1 : name 2: <<create>> PhDStudent(name) :PhDStudent 3: <<destroy>> sequence numbers added to messages

11. Sequence Diagram: Painting Mechanism :Thread :Toolkit :ComponentPeer target:HelloWorld run run callbackLoop handleExpose paint

12. Other Diagrams in UML • Activity diagram: shows the flow from activity to activity within a system (flow chart diagram). •Statechart diagram:models a state machine • Component diagram: shows the organization and dependencies among a set of components. • Deployment diagram: shows the configuration of processing nodes and the components that live on them.

13. Activity Diagram: Notation Release work order Reschedule Assign tasks branch [materials not ready] [materials ready] guard expression

14. Activity Diagram: Parallel Activities Decompress Stream audio Stream video start state fork join stop state

15. Statechart Diagram: Notation Waiting A state machine is a behavior that specifies the sequence of states an object or an interaction goes through during its lifetime in response to events.

16. Statechart Diagram: Notation returned() returned() not borrowable borrowable borrowed()[last copy] guard expression borrowed()[not last copy] State diagram for class Book in a library system

17. Statechart Diagram: Example from Lecture 10 using UML Notation [Select field] [Enter] [Enter] [lock off] [Start] Beam on Patients Fields Setup Ready [Stop] [lock on] [Select patient]

18. Software Reuse Better software at lower cost Potential benefits of reuse: • Reduce 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

19. Software Reuse: Examples Software developers rely heavily on software components provided by others System software • device drivers • file systems • exception handling • network protocols Subsystems • database management systems • firewalls • web servers

20. Software Reuse Examples (Tools) Standard functions • mathematical methods • formatting User interface • toolkits (e.g. Quickdraw for the original Macintosh) • class libraries, (e.g., Swing for Java)

21. Design for Reuse 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.

22. Design for Reuse 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.

23. Design for Reuse 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.

24. Design for Reuse 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.

25. 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

26. 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

27. 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 Design for Reuse: Inheritance and Abstract Classes

28. 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. Design for Reuse: Specification Inheritance

29. 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. Design for Reuse: Specification Inheritance

30. 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 implementation inheritance that should be used when reuse is anticipated. Design for Reuse: Delegation For a discussion of design for reuse see the book by Bruegge and Dutoit in the readings. *