1 cs 501 spring 2005 cs 501: software engineering lecture 16 object oriented design 2

35
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

Post on 22-Dec-2015

216 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

1 CS 501 Spring 2005

CS 501: Software Engineering

Lecture 16

Object Oriented Design 2

Page 2: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

2 CS 501 Spring 2005

Administration

Page 3: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

3 CS 501 Spring 2005

Candidate Classes: Solution Classes

Application classes and solution classes:

Application classes represent application concepts. Noun identification is an effective technique to generate candidate application classes.

Solution classes represent system concepts, e.g., user interface objects, databases, etc.

Page 4: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

4 CS 501 Spring 2005

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.

Page 5: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

5 CS 501 Spring 2005

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.

Page 6: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

6 CS 501 Spring 2005

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.

Page 7: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

7 CS 501 Spring 2005

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

Page 8: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

8 CS 501 Spring 2005

Exam Question: Observations about the Candidate Classes

WeatherMap is a DigitizedMapis 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?

Page 9: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

9 CS 501 Spring 2005

Exam Question: Attributes and Operations

WeatherStation

locationmetereologicalData

collectData()getSummary()

WeatherMap

locationdate-timegeographicDataweather

gatherData()printMap()DigitizedMap

locationgeographicData

printMap()

Or should MetereologicalData be a separate object?

Page 10: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

10 CS 501 Spring 2005

Exam Question: Class Diagram

DigitizedMap

1...*1

WeatherStation

locationmetereologicalData

collectData()getSummary()

WeatherMap

locationdate-timegeographicDataweather

gatherData()printMap()

summary

Page 11: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

11 CS 501 Spring 2005

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

Page 12: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

12 CS 501 Spring 2005

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.

State diagrams can be used for both requirements specification and for program design.

Page 13: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

13 CS 501 Spring 2005

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

Page 14: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

14 CS 501 Spring 2005

State Transition Diagram

Patients Fields Setup ReadyBeam

on

Enter Enter Start

Stop

Select field

Select patient(lock on)

(lock off)

Page 15: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

15 CS 501 Spring 2005

Interaction: Bouncing Ball Diagrams

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

Client Server(s)

domain name service

TCP connection

HTTP get

Page 16: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

16 CS 501 Spring 2005

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

Page 17: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

17 CS 501 Spring 2005

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.

Page 18: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

18 CS 501 Spring 2005

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.

Page 19: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

19 CS 501 Spring 2005

Actions on Objects

call

return

send

create

destroy

returnCopy(c)

okToBorrow() local

status

notifyReturn(b) asynchronous signal

<<create>>

<<destroy>>stereotypes

Page 20: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

20 CS 501 Spring 2005

Sequence Diagram: Borrow Copy of a Book

BookBorrower

libMem: LibraryMember

theCopy:Copy

theBook:Book

borrow(theCopy)okToBorrow

borrowborrow

Page 21: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

21 CS 501 Spring 2005

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

Page 22: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

22 CS 501 Spring 2005

Sequence Diagram: Painting Mechanism

:Thread :Toolkit :ComponentPeer target:HelloWorld

runrun callbackLoop

handleExpose

paint

Page 23: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

23 CS 501 Spring 2005

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.

Page 24: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

24 CS 501 Spring 2005

Activity Diagram (Flowchart)

Release work order

Assign tasks

Reschedule[materials not ready]

[materials ready]guard expression

branch

Activity diagrams can be used for both requirements specification and for program design.

Page 25: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

25 CS 501 Spring 2005

Activity Diagram: Parallel Activities

Decompress

Stream audioStream video

fork

join

start state

stop state

Page 26: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

26 CS 501 Spring 2005

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

The discussion of design for reuse draws from the book by Bruegge and Dutoit in the readings.

Page 27: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

27 CS 501 Spring 2005

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

Page 28: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

28 CS 501 Spring 2005

Software Reuse Examples (Tools)

Standard functions• mathematical methods• formatting

User interface

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

Page 29: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

29 CS 501 Spring 2005

Software Reuse (Application Packages)

An 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

Page 30: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

30 CS 501 Spring 2005

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

Page 31: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

31 CS 501 Spring 2005

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

Page 32: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

32 CS 501 Spring 2005

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.

Page 33: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

33 CS 501 Spring 2005

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.

Page 34: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

34 CS 501 Spring 2005

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.

Page 35: 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2

35 CS 501 Spring 2005

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.

*