32
1 RNDS: Class analysis RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

  • View
    221

  • Download
    3

Embed Size (px)

Citation preview

Page 1: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

1

RNDS: Class analysisRNDS: Class analysis

CS 236700: Software Design

Winter 2004-2005/T4

Page 2: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

2

Reminder: Homework bonus programReminder: Homework bonus program Report a bug Report a programming challenge

Page 3: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

3

RNDS: The story so farRNDS: The story so far Problem description SRS

Use case model

SDD Class design Sequence, Collaboration, Deployment Detailed class design

Coding Design patterns

Page 4: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

4

The missionThe mission

Identify key classesIdentify key classes

Identifying a class = defining its responsibility/concern/role Ideally, responsibility is not shared Choosing the classes is a critical issue - will influence the future

Just like the interaction children at the kindergarten Defining responsibility requires thinking about the methods

But, we will try not to define methods at this stage

Page 5: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

5

The processThe process

1.Identify objects2.Identify corresponding classes 3.Refinements

1.Identify objects2.Identify corresponding classes 3.Refinements

Page 6: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

6

A partial list with overlaps Nouns in the of description Algorithms (verbs)

May be classes, not just methodsThen an “er” suffix is added (Painter)

Recurring services VectorOfInts, StringIterator

Complex servicesDatabases, Sockets, Concurrency

Functions which accept the same formal arguments A process made up of an ordered sequence of actions An “initialize-do” process A “mode” behavior

Several polymorphic classes, one for each mode

Looking for classes (1/2)Looking for classes (1/2)

Assuming that most developers

think in procedural terms

Page 7: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

7

A partial list with overlaps (cont’d) Stateful behavior GUI entities:

Concrete components: panels, lists, labels, …Logical components: “screen”

Highly popular library services String, System.out

All sorts of Values Distinguish between values of identical type but different

roles Standard toolkit

Log, assertion, Message box, program configuration

Looking for classes (2/2)Looking for classes (2/2)

Page 8: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

8

Some class issues (1/2)Some class issues (1/2) Interface principle

Design for interface “I will write a Hash-table class” – implementation “I will write a Dictionary class” - interface

The interface of a class is not just the public methods/fieldsA TreeIterator class is part of the interface of class Tree

Choose the smallest interface

Page 9: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

9

Some class issues (2/2)Some class issues (2/2) Is-a vs. has-a

A square is also a rectangle A Square class cannot support all operations of a Rectangle

class=> A Square class cannot be a sub-class of Rectangle

In RNDSShould WP be a sub-class of Location?Should SWP be a sub-class of WP?

Naming: nouns only

Page 10: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

10

Compiler helping the developer (1/4)Compiler helping the developer (1/4)

int read(float nums[], int count) { int i, j = 0; for(i = 0; i < count; ++i) { scanf(“%f“, nums + j); if(nums[j] >= 0) ++j; } return j;}

void compute(float nums[], int count) { int i; for(i = 0; i < count; ++i) nums[i] = sqrt(nums[i]);}

int main(int argc, char* argv[]) { float nums[20]; int n = 20;

read(nums, n); compute(nums, 20); return 0;}

int read(float nums[], int count) { int i, j = 0; for(i = 0; i < count; ++i) { scanf(“%f“, nums + j); if(nums[j] >= 0) ++j; } return j;}

void compute(float nums[], int count) { int i; for(i = 0; i < count; ++i) nums[i] = sqrt(nums[i]);}

int main(int argc, char* argv[]) { float nums[20]; int n = 20;

read(nums, n); compute(nums, 20); return 0;}

Murphy’s rule: “If a function can be misused, the developer will eventually misuse it”

This C program is error-prone

The author intended that the return value of read() will be passed to compute()

There is no way to force him to do so

This is a dangerous world, with no one to protect the poor developer…

The object-oriented world is much safer.

How can we make it safe (in C) ?

Will this program terminate properly?

Page 11: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

11

Compiler helping the developer (2/4)Compiler helping the developer (2/4)

import java.io.*; import java.math.*;

public class SquareRoots{ private double[] nums_ = new double[20]; private int count_ = 0;

public SquareRoots() throws Excepetion { BufferedReader r = new BufferedReader(new InputStreamReader(System.in));

for(int i = 0; i < nums_.length; ++i) { nums_[count_] = Double.valueOf(r.readLine()); if(nums_[count_] >= 0) count_ += 1; } }

public void compute() { for(int i = 0; i < count_; ++i) nums_[i] = Math.sqrt(nums_[i]); }

public static void main(String[] args) throws Exception { SquareRoots sr = new SquareRoots(); sr.compute(); }}

import java.io.*; import java.math.*;

public class SquareRoots{ private double[] nums_ = new double[20]; private int count_ = 0;

public SquareRoots() throws Excepetion { BufferedReader r = new BufferedReader(new InputStreamReader(System.in));

for(int i = 0; i < nums_.length; ++i) { nums_[count_] = Double.valueOf(r.readLine()); if(nums_[count_] >= 0) count_ += 1; } }

public void compute() { for(int i = 0; i < count_; ++i) nums_[i] = Math.sqrt(nums_[i]); }

public static void main(String[] args) throws Exception { SquareRoots sr = new SquareRoots(); sr.compute(); }}

Page 12: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

12

Compiler helping the developer (3/4)Compiler helping the developer (3/4) The difference: C vs. OOP

In CThere’s no encapsulationCompile time entities (structs) are not used as often as

classes=> compiler assistance is much less common

In OOPMethods are operations which the developer attaches to

dataTwo types may hold the same type of data but have

different operationsA wise developer creates a world of classes where it is

difficult/impossible to invoke the wrong method

Page 13: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

13

Compiler helping the developer (4/4)Compiler helping the developer (4/4)

Summary (compiler helping the developer) By creating compile-time entities (classes) one can convert

run-time errors to compile-time errors Compiler errors are our friends! A rich population of classes Beware of population explosion: If the population is too

complex the developer makes wrong design decisions

Page 14: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

14

Cross-cutting concerns (1/2)Cross-cutting concerns (1/2) Some services are relevant to some/all parts of the program

E.g.: Error handling, Output formatting Thus, it is possible to come-up with several different decompositions Developer must select one of many possible decompositions This challenge is addressed by AOSD

Aspect Oriented Software Development The AspectJ programming language

Page 15: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

15

Cross-cutting concerns (2/2)Cross-cutting concerns (2/2)

…nonetheless, there is also a third decomposition Suitable for transaction management

Model GUI Logic

Vector of WPs Show WPs New WP: add to vector, show, send to other RNDS

Vector of WPs Show FP Remove WP: remove from vector, show, send to other RNDS

Location swp

Location current

Show directions to SWP

GPS notification: update current, compute new directions, show

Request Interpreter

Execution agent

Output Generator

Get user input, prepare command

Invoke the command,

Produce result

Process the result, update the GUI as necessary

Get updates from CL, prepare command

Here are two possible decompositions of RNDS

Model GUI Logic

Way Points Vector of WPs Show WPs New WP: add to vector, show, send to other RNDS

Flight Plan Vector of WPs Show FP Remove WP: remove from vector, show, send to other RNDS

Navigation Location swp

Location current

Show directions to SWP

GPS notification: update current, compute new directions, show

Page 16: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

16

UI vs. AlgorithmsUI vs. Algorithms Let’s divide a program into two parts

1. User interface (usually: GUI)2. Algorithms

Represent the rules of the domain/market (problem space) Business logic

Make sure the program produces correct results

What can you (the developer) change ? Changes in the UI are a sensitive issue Changes in the algorithms can be made freely (as long as the

produced results are correct)

On the other hand: your boss/client will tell you to modify the UI frequently

People always think of new ways to use existing software Web-interface, thin client, command line, etc…

The way the domain/market behaves rarely changes

Expect your algorithms to be utilized in new ways => Almost always separate the UI from the algorithms in your

decomposition

Page 17: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

17

First step: Identifying objectsFirst step: Identifying objects

The key question: Which objects do you “see” in the RNDS system?

We can take a look at the use case diagram (next slide)…

Page 18: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

18

RNDS: Use case diagramRNDS: Use case diagram

Page 19: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

19

RNDS Objects (1/2)RNDS Objects (1/2)1. CL Controller

2. GPS Controller

3. A collection of all way-points

4. A collection of way-points in the flight-plan

5. Way points (held by the collections)

6. Location (held by a Way Point)

7. Current SWP

8. Navigation model – holds all abovementioned objects

9. Navigation model update – synchronizes the nav. data

Page 20: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

20

RNDS Objects (2/2)RNDS Objects (2/2)10.Visibility state

11.Dispatcher

12.User Request

13.Manager of the WP GUI

14.Manager of the FP GUI

15.Manager of the directions GUI

16.Standard GUI Objects: Two JList objects, several JTextFeilds, …

So, Let’s define possible classes for these objects…

Page 21: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

21

Solving challengesSolving challenges Algorithmic challenges

Consistent Shared Data (CSR) Anything else?

Q: How will we solve the CSR challenge? (Answer: see next slide)

Page 22: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

22

CSRCSR The idea:

Decomposing the shared data into “atoms”: Items Each Item will have a globally unique id

GUID All copies of an item have the same id Thus, a change made to an item in one RNDS, can be correctly

duplicated to the other peers Item deletion is treated as a special case of an item change Each item will hold a 5 cell vector specifying its update number in

each of the RNDS systems When an RNDS system changes an item, it increases the

corresponding update number AKA: Vector Clock => two copies of the same items can be compared to determine

which is the most updated copy If comparison is ambiguous we have a conflict - must be solved

some other way • Human decision• Predefined priority

Page 23: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

23

CSR – example 1CSR – example 1Aircraft 2

Aircraft 4

Data-aK8 0 0 1 0 0Data-aK8 0 0 1 0 0

Data-bK8 0 0 2 0 0 Data-bK8 0 0 2 0 0

Data-cK8 0 0 2 0 1Data-cK8 0 0 2 0 1

Data-dK8 0 0 2 0 2

Data-eK8 0 0 2 0 3

Data-eK8 0 0 2 0 3

Connection establishedComparing

<0,0,2,0,1> with <0,0,2,0,3>

Connection lost

Page 24: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

24

CSR – example 2CSR – example 2Aircraft 2

Aircraft 4

Data-aK8 0 0 1 0 0Data-aK8 0 0 1 0 0

Data-bK8 0 0 2 0 0 Data-bK8 0 0 2 0 0

Data-cK8 0 0 2 0 1Data-cK8 0 0 2 0 1

Data-dK8 0 0 2 0 2

Data-fK8 0 0 2 0 3

Connection establishedComparing

<0,0,3,0,1> with <0,0,2,0,3>

Connection lost

Data-eK8 0 0 3 0 1

Page 25: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

25

CSR: ImplicationsCSR: Implications (Additional RNDS objects):

Item objects Unique Key Vector Clock Data store – a collection of item objects All Navigation data: (flight plan, way-points, …) should

be items/collections of items stored in the data store

Page 26: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

26

RNDS classes – 1RNDS classes – 1stst draft (1/6) draft (1/6) GPS

GpsController The GPS that the system “sees”Hardware independentUpdates the system when the GPS readout is changed

IGpsDevice – An interface describing the functionality provided by the hardware dependent GPS object

GpsDeviceA/B/C.. – implementations of IGpsDevice for specific GPS products

IGpsListener – An interface allowing another object to be notified when the GPS data has changed.

Page 27: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

27

RNDS classes – 1RNDS classes – 1stst draft (2/6) draft (2/6) CL

ClControllerThe CL that the system “sees”Hardware independentAllows an update to be sent/receivedProvides a fair, single-sender protocolProvides send result status – specifying which peers did

not receive the messageNotifies the system when an update is received

IClDevice – An interface describing the functionality provided by the hardware dependent CL object

ClDeviceA/B/C.. – implementations of IClDevice for specific CL products

IClListener – An interface allowing another object to be notified when an update is received.

ISendable – An interface. Represents a single unit of data that can be sent/received

Page 28: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

28

RNDS classes – 1RNDS classes – 1stst draft (3/6) draft (3/6) Navigation info classes

Location – Represents a 3D geographical position

Item – An abstract class representing a shared “piece” of data. Implements the ISendable interface

Key – A globally unique value (GUID) Vector clock ?

Let’s use an array of integers DataStore – Maps a key to an Item.

Supports lookup, add, replace, iteration.

WayPoint – Location + additional description details (name, …). A sub-class of Item

(The objects)• Items• Key• Vector Clock• Data Store• A collection of all way-points• A collection of way-points in

the flight-plan• Way points• Location• Current SWP• Navigation model• Navigation model update

(The objects)• Items• Key• Vector Clock• Data Store• A collection of all way-points• A collection of way-points in

the flight-plan• Way points• Location• Current SWP• Navigation model• Navigation model update

Page 29: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

29

RNDS classes – 1RNDS classes – 1stst draft (4/6) draft (4/6) Navigation info classes (cont’d)

Navigator – Holds the SWP + current GPS readout. Computes distance/heading.

VectorOfWayPoints – An ordered collection of WayPoint objects

WayPointRegistry -All defined way-points. Supports add/remove

FlightPlan – Represents the FP. Supports add/remove/up/down

NavModel – A “packaging” for the flight plan, SWP, WPs

Model update ?An iterator over a collection of

Item

(The objects)• Items• Key• Vector Clock• Data Store• A collection of all way-points• A collection of way-points in

the flight-plan• Way points • Location• Current SWP• Navigation model• Navigation model update

(The objects)• Items• Key• Vector Clock• Data Store• A collection of all way-points• A collection of way-points in

the flight-plan• Way points • Location• Current SWP• Navigation model• Navigation model update

Page 30: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

30

RNDS classes – 1RNDS classes – 1stst draft (5/6) draft (5/6) GUI

IWPGuiManager, IFPGuiManager, IDirectionsGuiManager

- Interfaces for the various parts of the screens StdWPGuiManager, StdFPGuiManager,

StdDirectionsGuiManager – Default implementations of these three Interfaces

Visibility state class ?No – Will be handled internally by the the StdGuiManager…

classes Class GuiManager – A packaging for all the other managers.

Page 31: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

31

RNDS classes – 1RNDS classes – 1stst draft (6/6) draft (6/6) Misc

Dispatcher – a focal point for initiating all use-cases. Creates all top-level objects

User Request class ?No – Each request will have a corresponding method in Dispatcher

Page 32: 1 RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

32

Comparing two classesComparing two classes ISendable vs. Item

Item – An abstract class representing a shared “piece” of data. Implements the ISendable interface

ISendable – An interface. Represents a single unit of data that can be sent/received

Q: Do we really need two different classes? A: No