1 CS 501 Spring 2006

CS 501: Software Engineering

Lecture 17

Object Oriented Design 3

2 CS 501 Spring 2006

Administration

Third presentation and report next week

Sign up now.

3 CS 501 Spring 2006

Quiz 3

A Mail Order System manages orders received by a mail order company. Most orders are received by mail and are input into the system for over-night processing. In addition, during the daytime, customers may call by telephone to a customer service clerk who records orders, which are also processed over-night. During the over-night processing, payments received are recorded and bills are sent out to customers.

Question 1: System Design

(a) What is a suitable architectural style for the Mail Order System?

(b) Draw an overview diagram of the system architecture using UML notation.

4 CS 501 Spring 2006

Quiz 3, Question 1Architectural Style: Master File Update

Master file update

Data input and validation

Mailing and reports

Customer services

telephone orders

data check

mail orders

From lecture 14, slide 5

Red parts of the diagram are optional

5 CS 501 Spring 2006

Quiz 3, Question 2

Question 2: Errors

(a) When orders are received by mail it is possible for the customer to supply an incorrect part number. How would you identify these errors and handle them?

(b)When orders are called in by telephone it is possible for the customer to supply an incorrect part number. How would you identify these errors and handle them?

In designing the system architecture the goal is to minimize staff costs while giving good service to customers.

6 CS 501 Spring 2006

Quiz 3, Question 2Errors in mail orders

Master file update

Data input and validation

Mailing and reports

data check

mail orders

7 CS 501 Spring 2006

Quiz 3, Question 2Errors in mail orders

1. Data entry clerk types in data from mail order.

2. Before submitting order it is checked against master file for valid parts numbers, prices, etc.

3. If there is an error that the clerk cannot correct, an error transaction is created.

4. The master file update creates a report on all transactions for each customer, which is passed to the mailing subsystem.

5. Customer receives mail that identifies the error.

No staff time is needed except for data entry clerk.

8 CS 501 Spring 2006

Quiz 3, Question 2Error in telephone order

Master file update

Customer services

telephone orders

9 CS 501 Spring 2006

Quiz 3, Question 2Errors in telephone order

1. Customer service clerk interviews customer and types in order while on the telephone.

2. While talking to the customer, the error is checked against the master file for valid parts numbers, prices, etc.

3. The clerk reads the order back to the customer, indicating any errors.

4. The customer corrects errors and agrees to the order.

5. The customer service subsystem creates an order transaction and passes it to the data input subsystem.

No staff time is needed except for customer service clerk.

10 CS 501 Spring 2006

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

11 CS 501 Spring 2006

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.

12 CS 501 Spring 2006

State Diagram: Notation

State diagram for class Book in a library system

not borrowable

returned()

returned()

borrowable

borrowed()[not last copy]

borrowed()[last copy]

guard expression

13 CS 501 Spring 2006

Notation for Classes and Objects

Classes Objects

AnyClass

attribute1attribute2

operation1()operation2()

AnyClass

or

anObject:AnyClass

:AnyClass

anObject

The names of objects are underlined.

or

or

14 CS 501 Spring 2006

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.

15 CS 501 Spring 2006

Interaction: Bouncing Ball Diagrams

Example: execution of http://www.cs.cornell.edu/

Client Server(s)

domain name service

TCP connection

HTTP get

16 CS 501 Spring 2006

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.

17 CS 501 Spring 2006

Actions on Objects

call

return

send

create

destroy

returnCopy(c)

okToBorrow() local

status

notifyReturn(b) asynchronous signal

<<create>>

<<destroy>>stereotypes

18 CS 501 Spring 2006

Sequence Diagram: Borrow Copy of a Book

BookBorrower

libMem: LibraryMember

theCopy:Copy

theBook:Book

borrow(theCopy)okToBorrow

borrowborrow

19 CS 501 Spring 2006

Sequence Diagram: Change in Cornell Program

Cornellian

:MEngStudent

1 : getName()

sequence numbers added to messages

:PhDStudent

1.1 : name

2: <<create>> PhDStudent(name)

3: <<destroy>>

20 CS 501 Spring 2006

Sequence Diagram: Painting Mechanism

:Thread :Toolkit :ComponentPeer target:HelloWorld

runrun callbackLoop

handleExpose

paint

21 CS 501 Spring 2006

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.

22 CS 501 Spring 2006

Activity Diagram: Notation

Release work order

Assign tasks

Reschedule[materials not ready]

[materials ready]guard expression

branch

23 CS 501 Spring 2006

Activity Diagram: Parallel Activities

Decompress

Stream audioStream video

fork

join

start state

stop state

24 CS 501 Spring 2006

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 CS 501 Spring 2006

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 CS 501 Spring 2006

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 CS 501 Spring 2006

Software Reuse Examples (Tools)

Standard functions• mathematical methods• formatting

User interface

• toolkits (e.g. Quickdraw)• class libraries, (e.g., Swing)

28 CS 501 Spring 2006

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 CS 501 Spring 2006

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.

30 CS 501 Spring 2006

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.

31 CS 501 Spring 2006

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.

32 CS 501 Spring 2006

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.

33 CS 501 Spring 2006

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

34 CS 501 Spring 2006

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

35 CS 501 Spring 2006

Design for Reuse: Implementation and Specification Inheritance

Implementation Inheritance

Developers reuse code quickly by subclassing an existing class and refining its behavior. Is not good for reuse.

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.

36 CS 501 Spring 2006

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.

37 CS 501 Spring 2006

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 implementation inheritance that should be used when reuse is anticipated.

The discussion of design for reuse draws from the book by Bruegge

and Dutoit in the readings.*