1. CS 501: Software Engineering
Lecture 17
Object Oriented Design 2

2. Administration Second presentation and report next week Sign up.
Quiz 3
Thursday.

3. 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
• Collaboration diagrams: structural organization of
objects that send and receive messages
Activity diagram: flow chart showing flow of control from activity to activity
Statechart diagram: models a state machine

4. Notation: Statechart diagrams
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.

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

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

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

8. Interaction: Bouncing Ball Diagrams
Example: execution of
domain name service
TCP connection
HTTP get
Client Server(s)

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

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

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

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

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

14. Other Diagrams in UML
• Activity diagram is a statechart diagram that shows the flow from activity to activity within a system.
• 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.

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

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

17. An Exam Question: Object Oriented Design
A system generates weather maps using data collected from unattended weather stations. Each weather station collects meteorological data and produces summaries of the data. On request, it sends the summary information to an area computer. The area computer uses a database of digitized maps to generate a set of local weather maps.

18. Exam Question: Noun Identification
A system generates weather maps using data collected from unattended weather stations. Each weather station collects meteorological data and produces summaries of the data. On request, it sends the summary information to an area computer. The area computer uses a database of digitized maps to generate a set of local weather maps.

19. Exam Question: Candidate Classes
System general term
WeatherMap
Data same as MeteorologicalData
WeatherStation is this a general term?
MeteorologicalData how does this relate to WeatherStation?
DataSummary how does this relate to MeteorologicalData?
AreaComputer hardware
Database general term
DigitizedMap

20. Exam Question: Observations about the Candidate Classes
WeatherMap is a DigitizedMap
is derived from 1...* DataSummary
WeatherStation has a set of MeteorologicalData
MeteorologicalData
DataSummary is derived from MeteorologicalData
DigitizedMap
Can Meteorological Data be an attribute of WeatherStation?
Can DataSummary be combined with WeatherMap?

21. Exam Question: Attributes and Operations
WeatherStation
location
metereologicalData
collectData()
getSummary()
WeatherMap
location
date-time
geographicData
weather
gatherData()
printMap()
DigitizedMap
location
geographicData
printMap()
Or should MetereologicalData be a separate object?

22. Exam Question: Class Diagram
DigitizedMap
WeatherStation
location
metereologicalData
collectData()
getSummary()
WeatherMap
location
date-time
geographicData
weather
gatherData()
printMap() 1
1...*
summary

23. Solution Objects Application objects and solution objects:
Application objects represent application concepts. Solution objects represent system concepts, e.g., user interface objects, databases, etc.
The discussion of design for reuse draws from the book by Bruegge and Dutoit in the readings.

24. From Candidate Classes to Completed Design
Methods used to move to final design:
Reuse: Wherever possible use existing components, or class libraries. They may need modification.
Restructuring: Change the design to improve, understandability, maintainability, etc. Techniques include merging similar classes, splitting complex classes, etc.
Optimization: Ensure that the system meets anticipated performance requirements, e.g., by changed algorithms or restructuring.
Completion: Fill all gaps, specify interfaces, etc.

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

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

27. Software Reuse Examples (Tools)
Standard functions
• mathematical methods
• formatting
User interface
• toolkits (e.g. Quickdraw)
• class libraries, (e.g., Swing)

28. Software Reuse (Application Packages)
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

29. Reuse and Object Oriented Languages
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

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

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

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

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

34. Reuse Techniques Implementation inheritance:
Reuse of code by subclassing an existing class and modifying its behavior.
Specification inheritance:
Subclasses are subtypes of their superclass. Objects of the subclass can be substituted for any object of the superclass type.
Delegation:
Implementation of an operation by sending a message to another class.

35. Design Patterns Design patterns:
E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994

36. Design Pattern
Design patterns are template designs that can be used in a
variety of systems.
• Name. [Some of the names used by Gamma, et al. are becoming standard software terminology.]
• Problem description. Describes when the pattern might be used, often in terms of modifiability and extensibility.
• Solution. Expressed in terms of classes and interfaces.
• Consequences. Trade-offs and alternatives.

37. Example: Adapter Design Pattern
Problem description:
Convert the user interface of a legacy class into a different interface expected by the client, so that the client and the legacy class can work together without changes.
Example: How do you use a web browser to access an existing
information retrieval system?
This problem often occurs during a transitional period, when
the long-term plan is to phase out the legacy system.

38. Adapter Design Pattern: Class Diagram
Client
abstract class
ClientInterface
Request()
LegacyClass
ExistingRequest()
Adapter
Request()
delegation
inheritance

39. Adapter Design Pattern: Consequences
The following consequences apply whenever the Adapter
design pattern in used.
• Client and LegacyClass work together without modification of either.
• Adapter works with LegacyClass and all of its subclasses.
• A new Adapter needs to be written if Client is replaced by a subclass.