CS 151: Object-Oriented Design October 15 Class Meeting Department of Computer Science San Jose State University Fall 2013 Instructor: Ron Mak mak

CS 151: Object-Oriented DesignOctober 15 Class Meeting

Department of Computer ScienceSan Jose State University

Fall 2013Instructor: Ron Mak

www.cs.sjsu.edu/~mak

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

2

In-Class Team Exercise: UML Class Diagram

Draw a UML class diagram that captures all of these facts: A university has several departments. Each department has a department chair. Each department teaches several courses. Two of the departments are computer science (CS)

and computer engineering (CMPE). The computer science department teaches the courses

CS 101, CS 102, and CS 103. The computer engineering department teaches the courses

CMPE 101 and CMPE 102. CS 102, CS 103, and CMPE 102 are also online. Each course has a professor, a number of students,

and possibly a graduate student T.A. People have home addresses.



3

An Exercise Solution

University Address

Chair

«interface»Graduate

Person

CS 101

CS 102

CS 103

CMPE 101

CMPE 102

ComputerEngineering

ComputerScience

Department1..n

Course1..n

Student

Professor

1..n

TA0..1

«interface»Online



4

What Lessons Did We Learn?

“Factor out” common properties and put them into superclasses. Examples: Department, Course, Person Many of these classes should be abstract

(not shown in the suggested solution). But not all: Student

Use marker interfaces to “tag” certain classes that are in different hierarchies. Examples: Online, Graduate

“May have” or “possibly have” means the multiplicity starts with 0. Example: A course possibly has a TA.



5

Review: Model-View-Controller Architecture

The user interacts with the controller (via buttons, menus, etc.) to send it commands.

The commands may tell the controller to modify the view directly, or the controller may alter the state of the model.

The altered model causes the view to update how it displays the model’s data.

The user reacts to changes in the view by interacting with the controller to send it new commands._

The user never manipulates the model directly,

only through the controller.



6

Model-View-Controller Example

alter state

update update

CONTROLLER

MODEL

VIEW #1 VIEW #2

User

send command

There can be multiple views of the same model. Each view updates after the model changes.



7

The Observer Design Pattern

Context An object (the “subject”) generates “events”. One or more other objects (the “observers”) want to be notified

whenever an event occurs.

Solution The subject manages

(attaches and detaches) a collection of observer objects.

Each observer object is instantiated from a class that implements the Observer interface.

Whenever an event occurs, the subject object notifies each observer object by calling the notify() interface method.

From: Object-Oriented Design & Patterns, John Wiley & Sons, 2006.



8

The Observer Design Pattern

Therefore, in the MVC architecture, each time the model object (subject) changes (an event), it notifies each of its view objects (observers).

Where have we already seen another example of the observer design pattern? What happens when you click a button in a GUI? The actionPerformed() method of each ActionListener

object that is attached to the button is called. What are the subject, event, observer, and notification

method? Subject = button

Event = button clickObserver = action listenerNotify method = actionPerformed()



9

Quiz #42013Oct15



10

Review for the Midterm

What it means for software to be well-designed.

Achieving good design via an iterative process.

Encapsulate parts of the design that will change. Refactoring.

Iterative and incremental development. Mini-waterfall per iteration.

Functional specification Functional requirements Nonfunctional requirements Stated and implied requirements



11


Use cases UML use case diagram Use case description

Where do classes come from?

Class responsibilities and relationships CRC cards

_



12


UML class diagram Relationships Multiplicities Aggregation vs. composition

UML sequence diagram

UML state diagram_



13


Javadoc

Designing good classes Example: Day class

Factory method design pattern

Importance of encapsulation_



14


Accessors and mutators

Side effects

Mutable and immutable classes Final fields

How good is an interface?_



15


Programming by contract Preconditions Postconditions Invariants Assertions

Unit testing JUnit

Regression testing

Design patterns_



16


Coding to the interface

Java interfaces Marker interfaces

Polymorphism

Comparable interface type Comparator interface type

Anonymous classes_



17


JFrame class JButton class JTextField class

Button actions_



18


Inversion of control

Java Timer class

Graphics context Shape interface Animation

Interface as a contract

Strategy design pattern

Dynamic class loading



19


Swing development support in NetBeans

Model-view-controller architecture

Observer design pattern_

Documents

CS 151: Object-Oriented Design October 15 Class Meeting Department of Computer Science San Jose State University Fall 2013 Instructor: Ron Mak mak