+ All Categories
Home > Documents > 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

Date post: 18-Jan-2018
Category:
Upload: barbara-knight
View: 216 times
Download: 0 times
Share this document with a friend
Description:
3 CS 501 Spring 2003 The Waterfall Model Requirements Analysis System design Unit & Integration Testing System Testing Operation & Maintenance Program design Coding Acceptance Testing Requirements Design Implementation
40
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I
Transcript
Page 1: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

1 CS 501 Spring 2003

CS 501: Software Engineering

Lecture 17

Object Oriented Design I

Page 2: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

2 CS 501 Spring 2003

Administration

New syllabus

Quiz 4 on Thursday, April 3 (no lecture)

Lecture 23 on Wednesday April 16 (evening)

Second presentation and report next week

Sign up. Assignment will be posted shortly

Quiz 3

Collect after class

Page 3: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

3 CS 501 Spring 2003

The Waterfall Model

Requirements Analysis

System design

Unit & Integration Testing

System Testing

Operation & Maintenance

Program design

Coding

Acceptance Testing

Requirements

Design

Implementation

Page 4: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

4 CS 501 Spring 2003

Program Design

The task of program design is to represent the software system functions in a form that can be transformed into one or more executable programs.

Given a system architecture, the program design specifies:

• computers and networks• programs, components, packages, classes and class

hierarchies• interfaces, protocols• security mechanisms, operational procedures

Page 5: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

5 CS 501 Spring 2003

The Importance of Modeling

• A model is a simplification of reality.

• We build models so that we can better understand the system we are developing.

• We build models of complex system because we cannot comprehend such a system in its entirety.

Models can be informal or formal. The more complex the project the more valuable a formal model becomes.

BRJ

Page 6: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

6 CS 501 Spring 2003

Principles of Modeling

• The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.

• Every model can be expressed at different levels of precision.

• The best models are connected to reality.

• No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models.

BRJ

Page 7: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

7 CS 501 Spring 2003

The Unified Modeling Language

UML is a standard language for modeling software systems

• Serves as a bridge between the requirements specification and the implementation.

• Provides a means to specify and document the design of a software system.

• Is process and programming language independent.

• Is particularly suited to object-oriented program development.

Page 8: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

8 CS 501 Spring 2003

Useful Texts

Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999.

Grady Booch, Object-Oriented Analysis and Design with Applications, second edition. Benjamin/Cummings 1994.

Rob Pooley, Perdita Stevens, Using UML Software Engineering with Objects and Components. Addison-Wesley 1999.

Page 9: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

9 CS 501 Spring 2003

Rational Rose

Rational Rose is a system for creating and managing UML diagrams.

It is available for all Computer Science Department computers, but you may have to install it.

See: http://adm/Software/purify_install.htm for installation instructions.

See: http://www.rational.com/products/index.jsp for information about the system.

Page 10: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

10 CS 501 Spring 2003

Diagrams in UML

A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships).

• Class diagram shows a set of classes, interfaces, and collaborations with their relationships.

• Object diagram shows a set of objects and their relationships.

• Use case diagram shows a set of use cases and actors (a special kind of class) and their relationships.

Page 11: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

11 CS 501 Spring 2003

Diagrams in UML (continued)

Interaction diagram shows an interaction, consisting of a set of objects and the relationships, including the messages that may be dispatched among them.

=> A sequence diagram emphasizes the time ordering.

=> A collaboration diagram emphasizes the structural organization of the objects that send and receive messages.

Page 12: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

12 CS 501 Spring 2003

Diagrams in UML (continued)

• Statechart diagram shows a state machine consisting of states, transitions, events, and activities.

• 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 13: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

13 CS 501 Spring 2003

Class

Window

originsize

open()close()move()display()

name

attributes

operations

A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.

Page 14: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

14 CS 501 Spring 2003

Class Diagrams

Window

originsize

open()close()move()display()

name

attributes

operations

A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.

Page 15: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

15 CS 501 Spring 2003

The "Hello, World" Example

import java.awt.Graphics;class HelloWorld extends java.applet.Applet { public void paint (Graphics g) { g.drawString ("Hello, World!", 10, 10); }}

Example from: BJR

Page 16: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

16 CS 501 Spring 2003

The HelloWorld Example

HelloWorld

paint()

class

name

operations

Page 17: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

17 CS 501 Spring 2003

Annotation

return copy of self

A note is a symbol for rendering constraints and comments attached to an element or a collection of elements.

Page 18: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

18 CS 501 Spring 2003

Abstraction for HelloWorld

HelloWorld

paint() g.drawString ("HelloWorld", 0, 10)"

class

name

operations

annotation

Page 19: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

19 CS 501 Spring 2003

Notation: Relationships

A dependency is a semantic relationship between two things in which a change to one may effect the semantics of the other.

0..1 *employer employee

An association is a structural relationship that describes a set of links, a link being a connection among objects.

Page 20: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

20 CS 501 Spring 2003

Relationships

Parking

Parking Space

location

is_available()

1

0 ... 1

Page 21: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

21 CS 501 Spring 2003

Notation: Relationships (continued)

A generalization is a specialization/generalization relationship is which objects of the specialized element (child) are substitutable for objects of the generalized element (parent).

child parent

A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.

Page 22: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

22 CS 501 Spring 2003

Generalization

Applet

HelloWorld

paint() Graphics

generalization

dependency

Note that the Applet and Graphics classes are shown elided.

Page 23: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

23 CS 501 Spring 2003

Notation: Interface

An interface is a collection of operations that specify a service of a class or component, i.e., the externally visible behavior of that element.

ISpelling

Page 24: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

24 CS 501 Spring 2003

Class Inheritance Diagram

Object

Component

Container

Panel

Applet

HelloWorld

ImageObserver

interface

Page 25: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

25 CS 501 Spring 2003

Modeling Classes

Given a real-life system, how do you decide what classes to use?

• What terms do the users and implementers use to describe the system? They are candidates for classes.

• Is each candidate class crisply defined?

• For each class, what is its set of responsibilities? Are the responsibilities evenly balanced among the classes?

• What attributes and operations does each class need to carry out its responsibilities?

Page 26: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

26 CS 501 Spring 2003

Noun Identification: A Library Example

The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals.

The system must keep track of when books and journals are borrowed and returned and enforce the rules.

Page 27: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

27 CS 501 Spring 2003

Noun Identification: A Library Example

The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals.

The system must keep track of when books and journals are borrowed and returned and enforce the rules.

Page 28: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

28 CS 501 Spring 2003

Candidate Classes

Library the name of the systemBookJournalCopyShortTermLoan eventLibraryMemberWeek measureMemberOfLibrary repeatItem book or journalTime abstract termMemberOfStaffSystem general termRule general term

Page 29: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

29 CS 501 Spring 2003

Relations between Classes

Book is an ItemJournal is an ItemCopy is a copy of a BookLibraryMemberItemMemberOfStaff is a LibraryMember

Is Item needed?

Page 30: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

30 CS 501 Spring 2003

Operations

LibraryMember borrows Copy

LibraryMember returns Copy

MemberOfStaff borrows Journal

MemberOfStaff returns Journal

Item not needed yet.

Page 31: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

31 CS 501 Spring 2003

Class Diagram

MemberOfStaff

BookCopyJournal is a copy of

1..* 1

LibraryMember

1

0..*0..12

1

on loanon loan

Page 32: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

32 CS 501 Spring 2003

Rough Sketch: Wholesale System

A wholesale merchant supplies retail stores from stocks of goods in a warehouse.

What classes would you use to model this business?

Page 33: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

33 CS 501 Spring 2003

Rough Sketch: Wholesale System

RetailStore

Warehouse

Order

Invoice

Product

Shipment

Merchant

Page 34: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

34 CS 501 Spring 2003

Rough Sketch: Wholesale System

Warehouse

Order

Invoice

Product

MerchantRetailStore

nameaddresscontactInfofinancialInfo

Shipment

Responsibilities-track status of shipped products

Reversal

damaged()return()wrongItem()

responsibility (text field)

Page 35: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

35 CS 501 Spring 2003

Expanding a Class: Modeling Financial Information

RetailStore

Transaction1 *association

Invoice

PaymentWhich class is responsible for the financial records for a store?

Page 36: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

36 CS 501 Spring 2003

Modeling Invoice

Shipment

Invoice

invoiceNumber

+goodsShipped()-sendInvoice()

goodsShipped

PartsListadornments+ public- private

RetailStore???

invoiceRecord

Page 37: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

37 CS 501 Spring 2003

Lessons Learned

Design is empirical. There is no single correct design. During the design process:

• Eliding: Elements are hidden to simplify the diagram

• Incomplete: Elements may be missing.

• Inconsistency: The model may not be consistent

The diagram is not the whole design. Diagrams must be backed up with specifications.

Page 38: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

38 CS 501 Spring 2003

Levels of Abstraction

The complexity of a model depends on its level of abstraction:

• High-levels of abstraction show the overall system.

• Low-levels of abstraction are needed for implementation.

Two approaches:

• Model entire system at same level of abstraction, but present diagrams with different levels of detail.

• Model parts of system at different levels of abstraction.

Page 39: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

39 CS 501 Spring 2003

Notation: Grouping

A package is a general-purpose mechanism for organizing elements into groups.

Business rules

Page 40: 1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.

40 CS 501 Spring 2003

Packaging Classes

applet

awt

lang

HelloWorld

java

Graphics

package


Recommended