Object-oriented design CSE 432: Object-Oriented Software Engineering.

16
Object-oriented design CSE 432: Object-Oriented Software Engineering

Transcript of Object-oriented design CSE 432: Object-Oriented Software Engineering.

Page 1: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Object-oriented design

CSE 432: Object-Oriented Software Engineering

Page 2: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Goals of OO analysis (quick review) What are the two main goals of OO analysis?

1) Understand the customer’s requirements

2) Describe problem domain as a set of classes and relationships

What techniques have we studied for the 1st goal? Develop a requirements specification Describe scenarios of use in user’s language as use cases

What techniques have we studied for the 2nd goal? CRC cards discover classes and run simulations UML class diagrams represent classes & relationships Sequence diagrams model dynamic behavior of a system

Page 3: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Goals of OO design OO design develops the analysis into a blueprint of a solution

Where does the “blueprint” metaphor come from? OO design starts by fleshing the class diagrams

Coad & Nicola call this "the continuum of representation principle: use a single underlying representation, from problem domain to OOA to OOD to OOP," i.e., class diagrams

Reworks and adds detail to class diagrams, e.g., attribute types, visibility (public/private), additional constraints

Looks for opportunities for reuse Addresses performance issues, both for system and users Designs UI, database, networking, as needed Designs ADT to describe the semantics of classes in more detail Develops unit test plans based on class diagrams and ADT design

Page 4: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Four activities of design (Coad) 1) Improve domain analysis: reuse and performance

OOA focuses primarily on the describing problem domain itself OOD reexamines the domain with an eye to practical concerns Reuse: factor out common code in abstract classes Performance tradeoffs: efficiency vs. effectiveness

2) Human interaction: encapsulates user interface HIC knows how to present data, not how to compute it Separation of concerns principle: Keep problem domain classes distinct from

human interaction classes. Why? Loose coupling facilitates software reuse and maintenance An example: the Smalltalk Model-View-Controller framework:

model is the problem domain view is the human interface (windows that view the problem domain objects) controller is the mouse or keyboard input, also interacting with P.D. objects

C++ Interviews is two part framework: subject (problem domain) & views (UI)

Page 5: Object-oriented design CSE 432: Object-Oriented Software Engineering.

How does this design illustratethe separation of concerns principle?

Page 6: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Four activities of design (continued) 3) Task management

Multi‑tasking and concurrency considerations How does separation of concerns apply here? Examples?

4) Data management Storage and retrieval of external data Database design (relational or object-oriented) Or database interface (JDBC, CORBA) How does separation of concerns apply here?

Page 7: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Reworking the class diagram

Add new relations implied in classes Inverse operations (e.g., undo/redo, getData/setData) Factor complex behaviors out as classes themselves If only difference between subclasses is presentation of data,

use a service Should we derive HexCount, BinaryCount, OctCount from Count? Rather, add a service, asBase, to present data in different bases

Distinguish client (has-a) and inheritance (is-a) relations Misuse of multiple inheritance is when a derived class is

"composed of" several parent classes I.e., class AIRPLANE has parents WINGS, ENGINE, TAIL) But the behavior of AIRPLANE is not just the sum of its parts Bjarne Stroustrup's heuristic: "can it have two?"

Then it's a containment, or has-a relation

Page 8: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Reworking the class diagram (continued) Heuristic: use inheritance to extend existing classes

E.g., ComplexMatrix adapts Array or OrderedCltn But avoid adapting parents for the sake of their heirs

(open‑closed principle) Generalize common behaviors in abstract classes

E.g., Mouse, Tablet and Keyboard can all inherit behavior from an abstract class, InputDevice

Use multiple inheritance for compound classes TeachingAssistant inherits from both Instructor and Student Window as a compound of Rectangle (graphical behaviors)

and Tree (hierarchical behaviors) Note: many OO languages don’t support multiple inh.

Page 9: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Classes as active state machines Consider whether a class should keep track of its own internal state

Example from Bertrand Meyer: first cut design of LINKED_LIST classclass LINKABLE[T] ‑‑linkable cells feature value:T; right: LINKABLE[T]; ‑‑next cell

‑‑routines to change_value, change_right end; class LINKEDLIST[T] feature

nb_elements: INTEGER; first_element: LINKABLE[T]; value(i:INTEGER):T is ‑‑value of i‑th element; loop until it reaches the ith element

insert(i:INTEGER; val:T); ‑‑loop until it reaches ith element, then insert val delete(i:INTEGER); ‑‑loop until it reaches ith element, then delete it

Problems with first‑cut? Getting the loops right is tricky (loops are error‑prone) Redundancy: the same loop logic recurs in all these routines

Reuse leads to inefficiency: suppose I want a routine search Find an element then replace it: I'll do the loop twice! Need some way to keep track of the position I found! Could return the LINKABLE cell found, but this would ruin encapsulation

Page 10: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Classes as active state machines (cont.) Instead, view LINKED_LIST as a machine with an internal state

Internal state is information stored as attributes of an object

What have we added to represent internal state? Cursor: current position in the list search(item) routine moves the cursor until it finds item insert and delete operate on the element pointed at by cursor How does this simplify the code of insert, delete, etc.? Client has a new view of LINKED_LIST objects: l.search(item); ‑‑find item in l if not offright then delete end; ‑‑delete LINKABLE at cursor Other routines move cursor: l.back; l.forth

Page 11: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Key idea for OOD: data structures can be active

Active structures have internal states, which change Routines manipulate the object's state

What other classes could be designed this way? Files, random number generators, tokenizers, ... Class as state machine view may not be obvious

during analysis A good reason for redesign!

Page 12: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Case Study: Full‑Screen Entry Systems Straightforward data processing application:

menu‑driven data entry (see overhead) Each menu comes with a panel of information & lets user

choose next action Interaction during a airline reservation session Enquiry on flights, information & possible new states

Meyer shows different ways to solve problem goto flow (50's), functional decomposition (70's) OO design (90's): improves reusability and extensibility

Page 13: Object-oriented design CSE 432: Object-Oriented Software Engineering.

State diagrams in UML States in ovals, transitions as arrows

Transitions labels have three optional parts: Event [Guard] / Action

Item Received is an event, /get first item is an action, [Not all items checked] is a guard

State may also label activities, e.g., do/check item Actions, associated with transitions, occur quickly

and aren’t interruptible Activities, associated with states, can take longer and are

interruptible Definition of “quickly” depends on the kind of system,

e.g., real-time vs. info system

Page 14: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Super-states

Example shows a super-state of three states Can draw a single transition to and from a super-state How does this notation make things a bit clearer?

Concurrency in state diagrams Dashed line indicates that an order is in two different

states, e.g. Checking & Authorizing When order leaves concurrent states, it’s in a single state:

Canceled, Delivered or Rejected When should you create UML state diagrams?

Page 15: Object-oriented design CSE 432: Object-Oriented Software Engineering.

UML package diagrams

UML packages for higher level structure (Coad’s subjects) Denoted by box with smaller box on top

Note dependency arrows A dependency indicates that changes to one element may cause

changes to the other Packages can be grouped in higher-order packages

Packages may include packages Common package as <<global>> means all packages in system have

dependency to this one General package marked {abstract} means this package is an

interface, with subtypes Heuristic: divide classes into packages; analyze dependencies;

refactor to reduce dependencies

Page 16: Object-oriented design CSE 432: Object-Oriented Software Engineering.

Design process procedures Conduct peer reviews at every stage of process

CRC cards: run simulations to discover missing responsibilities Conduct peer review of class diagrams: does it cover the domain? Explain design, looking for opportunities for iterative redesign Contract design: peer review ADTs or assertions Test design: review plans for unit and acceptance testing

Plan testing on a per class basis Write system and unit test plan descriptions as part of class design Unit test all public member functions Test for valid, invalid and boundary cases System testing follows thorough class testing See Junit tool for automated test generation support