comparison of design styles (part i) case study: 2d geometry solver cop 4331 oo processes for...

24
Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer Science and Electrical Engineering March 17, 2009

Upload: brianna-antonia-rich

Post on 13-Jan-2016

214 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

Comparison of Design Styles

(Part I)Case Study: 2D Geometry Solver

COP 4331

OO Processes for Software Development

© Dr. David A. Workman

School of Computer Science and Electrical Engineering

March 17, 2009

Page 2: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

2

Problem Statement

Vector ApplicationThe system shall provide the capability to:

1. Read one or more instances of the problem data from an external ascii file specified by the user at runtime. An instance of the problem data shall include the description of two lines and a point in Real 2D space. Each line shall be composed of two cartesian vectors defining respectively, a point on the line, and the positive direction of the line. The single point shall be defined by a cartesian vector. It is assumed that a vector is a mathematical object with origin at (0,0) and terminus at some point (x,y) in the Real cartesian plane. Each line and the point shall have alphanumeric identifiers that will be used primarily for output purposes.

2. For each problem instance in the input file, compute the following:(a) The point of intersection of the two lines, if the lines are not parallel.(b) Alternatively, output a message stating that the given lines are “parallel” and non-intersecting, or “co-linear” and intersecting at every point on both lines.(c) For each line, compute the distance of the given point from that line.

3. For each problem instance in the input file, write to an ascii output file, also specified by the user at runtime, the following information:(a) An echo of the problem data with both lines and point properly identified.(b) The point of intersection of the two lines, or an appropriate message.(c) For each line (identified properly) output the distance of the given point.

The system shall correctly process test input files provided by the client.The developer shall use a specification of the vector abstraction provided by the

client, and shall deliver a reusable implementation of this abstraction.

Page 3: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

3

Vector Abstraction Specification

Requirements1. The name shall be Vector.

2. A vector shall have a representation using Cartesian coordinates and using Polar coordinates.

3. The following operations shall be supported:– A constructor using Cartesian coordinates

– A conversion to Polar coordinates

– Projection functions for each Cartesian axis.

– A Magnitude function

– A Unitization function (computes a unit vector in the same direction)

– A Negation funtion

– A Dot product function

– A Cross product function

– A Add and Difference function

– A Scalar product function

– An Insertion operation for writing an vector image to an ascii file

– An Extraction operation for parsing a vector image input from an ascii file.

– A conversion to an ascii string (same format as Insertion and Extraction).

4. The vector abstraction shall raise a VectorException error for any illegal or undefined vector operations. Such an exception shall identify the operation and the reason for the error.

Page 4: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

4

Vector Abstraction Example

2D Geometry SolverApplication

Problem 1

Problem 2

Problem n

ASCII InputFile

ASCII OutputFile

Solution 1

Solution 2

Solution n

2D VectorAbstraction

USER

Page 5: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

5

Vector Application: Requirements

Y

X

(a, b) =

a

b

head point

(0, 0)tail point

V

A vector can be represented as a pair(a, b) denoting respectively the X and Y

coordinates of the point in 2-spacedefining the head of a vector with tail

at the origin (0, 0).

r

r a b Sin b r Cos a r

a r

b r

2 2 1 1

- 2 2

= )

( / ) ( / )

sin( )

cos(

= (r, )

A vector can also be represented as apair (r, ), where r is the length or magnitude of the vector and is the

angular measure of its direction.

Page 6: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

6

Vector Application: Requirements

 

(x x y y1 2 1 2 , )

(x x y y1 2 1 2 , )

x x y y V V1 2 1 2 1 2 2 1 | || |cos( )

x y y x V V1 2 1 2 1 2 2 1 | || |sin( )

Operation Expression Definition

Unitize Unit(V1) (x1/r1, y1/r1) = Polar(1.0, 1)

Magnitude |V1|

r1 =

Addition V1 + V2

Subtraction V1 - V2

Dot Product V1 V2

Cross Product V1 V2

Scalar Product cV1 = V1c ( cx1, cy1)

Rotation c @ V1 rotate( r1, (1+c) mod 2)

Negation - V1 ( -x1, -y2) = Polar(r1, -1) = Polar(r1, 2-1)

x y12

12

Page 7: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

7

Vector Application: Requirements

Line Equation:

where is a vector defining a point

on the line and is a unit vector

defining the direction of the line

(that is, parallel to the line).

L x A x U

A

U

( )

Y

X

A x U (x > 0)

x U (x < 0)

U

L x( )

L x( )

Y

X

A

U

Line Equation: L x A x U( )

L x( )

Q

P

V

Page 8: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

8

The Problem: Obstacle Avoidance

G

W

T

Current path corridor

V

Target Object (T)

Obstructing Object (G)

Moving Object (W)

The problem is depicted in the figure. An object, W, is inmotion traveling in a direction and speed defined by velocityvector, V. This vector has been defined to create a futurerendezvous with some Target object, T. At some point in time W discovers that some object, G, is obstructing its path.That is, if W continues in its current direction, it will eventuallycollide with G. W must alter its direction (and possibly speed)to avoid G with the least impact on the total distance it musttravel to avoid the obstruction, G.

All objects in the scenario are modeled by circles of uniformradius, r.

Vector diagram satisfy the following relationships:G = T + DT = W + DW.|DT| ≥ 3r|DW| ≥ 3r

We assume no two objects are closer that 3r.

DT

DW

Page 9: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

9

The Solution

The Solution involves computing the geometry of two possiblepaths around the obstructing object G. These paths are depicted in the diagram to the right. Each path has a turning point (P1 and P2) that is defined by the intersection of two lines, one defined by a clear path to the Target, one defined by a clear path from the Waiter, each tangential to the obstructing object.

The alternative clear paths available to the Waiter are characterized by a unit vector in a direction obtained by rotating the vector DW by an angle ± α. Similarly, the alternative clear paths to the Target are obtained by rotating the vector DT through an angle ± β.

The two complete clear path from W to T bypassing G are:(a) traveling in direction A- to turning point P1 and then traveling in direction –B+ to the Target, T. (b) traveling in direction A+ to turning point P2 and then traveling in direction –B- to the Target, T.

The desired path is the one for which |Pk – W| is a minimum, where k {1,2}.

The next slide gives solution details.

G

W

Turing Point (P1)

T

Turing Point (P2)- α

α

β- β

A-

A+

B-

B+

Page 10: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

10

Solution Details

)(

)( c where

,)(P is lines two theseofon intersecti The

)(

)(

)()()(

)()(B ,

2

)()()(

)()(A ,

2

1

1

-1

BA

BWT

AcWcL

BzTzL

AzWzL

DunitCosSin

SinCos

D

rCos

DunitCosSin

SinCos

D

rCos

A

B

A

TT

WW

G

W

Turing Point (P1)

T

- α

β

A-

B+

LA

LB

Y

X

A x U (x > 0)

x U (x < 0)

U

Line Equation:

where is a vector defining a point

on the line and is a unit vector

defining the direction of the line

(that is, parallel to the line).

L x A x U

A

U

( )

L x( )

L x( )

DT

DW

Page 11: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

11

Data Flow Specification

Solve2D-Geometry

Problems

InputFile

OutputFile

Probleminstances

Solutioninstances

Prompt & Error messages

Filenames

Context Diagram(Level 0)

Define theSystem Context

AndExternal Interfaces

User

Page 12: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

12

Data Flow Specification

1.0 GetFile

Names

InputFile

OutputFile

Probleminstance

Solutioninstances

Prompt messages

Filenames

Solve 2D-Line Problems(Level 1 Decomposition)

2.0 OpenInputFile

3.0 InitializeOutput

File

Input File Name

Output File Name

Error Message

Error Message

File SystemData

File SystemData

4.0 ReadProblemInstance

5.0 ComputeSolution

6.0 WriteSolutionInstance

Problem Data

Solution Data

Refine theSystem Functional

Specificationone Level

See notesview

Page 13: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

13

Functional Design

MainControl

OpenInputFile

GetFile

Name

CreateOutput

File

File NameKeyboard

Display

OutputFile Name

InputFile Name

Input File Object (IFO)

OutputFile Object

(OfO)

FilePrompts& Errors

InputFile

OutputFile

ReadProblemInstance

ComputeSolution

WriteSolutionInstance

ProblemSpecification

ProblemDescription,Line Intersection,Description.Point-to-LineDistances

L1L2P

L1: LineL2: LineP : Vector (point)XP: Intersection PointXM: Intersection MessageD1: Distance to L1D2: Distance to L2

XP, XM, D1, D2

XP, XM, D1, D2

L1, L2, P

Unitize

Mag Dot

Cross Diff

Sum

ScalarMult

Vectorsand/or Scalars

Vectorsor Scalars

See notesview

IFO

OFO

Page 14: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

14

Functional -

Vectorapp.c

typedefstruct vec

{ double x,y;}Vector

#includes:<stdio.h><math.h><string.h>

double Mag( Vector *X );double Cross(Vector *X, Vector *Y);double Dot(Vector *X, Vector *Y);Vector *Unitof( Vector *v );Vector *Diff(Vector *X, Vector *Y);Vector *Sum (Vector *X, Vector *Y);Vector *ScalarMult (double c, Vector *X);

main () {/* 1: open input file. 2: create output file. 3: problem processing loop 4: close files}

3.1 read and parse line #1 write line #1 to output3.2 read and parse line #2 write line #2 to output3.3 read and parse point write point to output3.4 compute point of intersection write intersection point to output3.5 compute distance to line #13.6 compute distance to line #2 write distance of point to each line.

Problem processing loop/* read description of line 1 */fgets(line,80,fin);/* parse line 1 (A1, D1)*/sscanf(line," ( %lf , %lf ) ( %lf , %lf )",&A1.x, &A1.y, &D1.x,&D1.y);if( feof(fin) ){ printf("\n Error in Problem instance # %d\n",count); fclose(fin); fclose(fout); exit(1);}

double z1,z2;Vector *X1, *X2;/* Compute intersection point */z1 = Cross(Diff(&A2,&A1),U2)/Cross(U1,U2);z2 = Cross(Diff(&A1,&A2),U2)/Cross(U2,U1);X1 = Sum(&A1,ScalarMult(z1,U1));X2 = Sum(&A2,ScalarMult(z2,U2));

Page 15: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

15

Functional- Design• Decomposition Style: Functional

– Physical Modules: 1 file– Logical Modules: 8 functions

• Abstractions: – Language Defined: File– Program Defined: Vector

• Data Encapsulation: None

• Information Hiding: Limited– The Vector type is public (-)– The client (main) accesses the internal components of Vector instances (-)– The internal view of Vector (polar vs. cartesian) is hidden in the functions that

manipulate vectors (+). The client does not assume or exploit the internal view of Vector (+).

• OO-Ness: Limited– Variables denoting specific instances of type Vector are used in a manner consistent

with an object view. (+)– Memory allocated to Vector instances is not reclaimed at the end of their lifetime (-).

• Reusability: Only at the program/application level.

Distribution of Control:All control is encapsulated in the client(application).

Page 16: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

16

Functional +

Vectorapp.c

#include:vector.h

#includes:<stdio.h><math.h><string.h>

typedef struct vec { double x,y; } Vector;typedef struct vec* VECPTR;/* Cartesian view */double Cartx(VECPTR V);double Carty(VECPTR V);VECPTR Cartesian( double x, double y);VECPTR Getcart(FILE *fin);/* View independent operations */double Cross(VECPTR X, VECPTR Y);double Dot(VECPTR X, VECPTR Y);VECPTR Unitof( VECPTR v );VECPTR Diff(VECPTR X, VECPTR Y);VECPTR Sum (VECPTR X, VECPTR Y);VECPTR ScalarMult (double c, VECPTR X);void Putvector(FILE *fout, VECPTR V);void Reclaim( VECPTR V);

main () {/* 1: open input file. 2: create output file. 3: problem processing loop 4: close files}

3.1 read and parse line #1 write line #1 to output3.2 read and parse line #2 write line #2 to output3.3 read and parse point write point to output3.4 compute point of intersection write intersection point to output3.5 compute distance to line #13.6 compute distance to line #2 write distance of point to each line.

Problem processing loop

vector.h

vector.c

#include “vector.h”/* implementation of vector operations */

/****parse line 1 (A1, D1)***** /if((A1 = Getcart(fin)) == NULL){ printf("\n Error in Problem # %d\n",count); fclose(fin); fclose(fout); exit(1);};/* similar code to read in D1 */

/* output problem data : line 1*/fprintf(fout, ”A1 = “); Putvector( fout, A1 );fprintf(fout,”, D1 = “); Putvector( fout, D1); fprintf(fout, “\n”);

Page 17: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

17

Functional+ Design• Decomposition Style: Functional

– Physical Modules: 3 files ( Application, Vector header, Vector implementation)

– Logical Modules: 16 functions

• Abstractions: – Language Defined: File– Program Defined: Vector

( methods added supporting two external views, IO, and memory mgmt )

• Data Encapsulation: Vector Abstraction

• Information Hiding: Almost Complete for Vector abstraction– The Vector type is public (-)– The client (main) does not access any internal components of Vector instances (+)– The internal view of Vector (polar vs. cartesian) is completely hidden in the functions that

manipulate vectors (+). The client does not assume or exploit the internal view of Vector (+).

• OO-Ness: Limited– Variables denoting specific instances of type Vector are used in a manner consistent with

an object view. (+)– Memory allocated to Vector instances is reclaimed at the end of their useful lifetime (+).– More opportunities for abstraction, encapsulation, and information hiding exist(-).

• Reusability: The Vector abstraction is highly reusable.

Distribution of Control:Some control has been beenEncapsulated in the Vectorabstraction. Specifically, theparsing of Vectors on inputand the formatting of Vectorson output.

Page 18: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

18

OO Design Introduction

Vector Application: Line Intersection Solver

DefineInput File

DefineOutput File

SolveProblemInstances

Use Case Diagram

* *

Mathematician

Input File

Output File

«includes»

«includes»

Page 19: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

19

OO Design Introduction

Analysis Model (Collaboration Diagram)

In-stream

Out-stream

Vector

User-Interface

Problem-Manager

* *1: prompt

2: file name

3: file ids

4a: open stream

4b: create stream

5b: parse instance

7b: output instance

5a: create instances

6: manipulate instances

7a: output problem

data

Page 20: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

20

OO Design IntroductionDesign Model (Class Diagram)

* *

ProblemMgr

fin: ifstreamfout: ofstreamfinid, foutid: stringA1, D1, U1: VectorA2, D2, U2: VectorP: VectorX1, X2: VectorQ1, Q2: Vectord1, d2: double

ProblemMgr();

ifstream

Filename: stringifstream();Open();Close();Eof();>> ();

ofstream

Filename: string

ofstream();Open();Close();<< ();

Vector

Double: x,y

Vector();Vector( double, double);Mag();Unitof();Cross( Vector );Dot( Vector );Sum( Vector );Diff( Vector );ScalarMult( double );Getcart( ifstream );Putvector( ofstream );

Reads problem Instances from

Writes solution Instances to

Represents probleminstances as

User

Provides filenames to

Page 21: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

21

OO Design IntroductionUser ProblemMgr fin: ifstream fout: ofstream

Prompt for input file name.

finidOpen( finid )

Prompt for output file name.

foutid Open( foutid )

:Vector

A1.Getcart(fin)>>*

token

Repeated for VectorsD1, A2,D2 and P.<< Problem No.

A1.Putvector(fout)

Repeated for VectorsD1, A2,D2 and P.

Repeated for eachProblemInstance.

Design Model (Sequence Diagram)

Page 22: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

22

OO -

vectorapp.cpp

#includevector.h

#includes:<stdio.h><math.h><string.h>

main () {/* 1: open input file. 2: create output file. 3: problem processing loop 4: close files}

3.1 read and parse line #1 write line #1 to output3.2 read and parse line #2 write line #2 to output3.3 read and parse point write point to output3.4 compute point of intersection write intersection point to output3.5 compute distance to line #13.6 compute distance to line #2 write distance of point to each line.

Problem processing loop

vector.h

class Vector { public: // operations private: // data};

try{ //********parse problem data description A1.Getcart(fin); D1.Getcart(fin); A2.Getcart(fin); D2.Getcart(fin); P.Getcart(fin);}catch(string e){ cout << "Vector io exception raised: " << e << " in Problem instance " << count << endl; return 1;}

vector.cpp

#include “vector.h”/* implementation of vector class */

//***echo problem data */ fout << endl << "Line 1: A1 = "; A1.Putvector(fout); fout << " D1 = "; D1.Putvector(fout); fout << endl;

Page 23: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

23

OO -

class Vector {public:/* Polar view */ double Mag(); double Angle(); Vector Polar(double radius, double angle); Vector Getpolar(ifstream &fin);/* Cartesian (internal) view */ double Cartx(); //Inspector double Carty(); //Inspector Vector(); //Constructor (default) Vector( double xcoord, double ycoord); //Constructor ~Vector(); //Destructor Vector Getcart(ifstream &fin);/* View independent operations */ double Cross(Vector Y); double Dot(Vector Y); Vector Unitof(); Vector Diff(Vector Y); Vector Sum (Vector Y); Vector ScalarMult (double c); void Putvector(ofstream &fout);private: double x,y;};

vector.h

Page 24: Comparison of Design Styles (Part I) Case Study: 2D Geometry Solver COP 4331 OO Processes for Software Development © Dr. David A. Workman School of Computer

March 17, 2009 COP 4232 (C) Dr. David A. Workman

24

OO- Design

• Decomposition Style: Object OrientedEvery component is an object or a class of objects. Even though ProblemMgr

serves the same purpose as the “client function” in the Functional+ style, it is still designed as an object (class with one instance ) and consequently it is more reusable and more secure.

– Physical Modules: 3 (vectorapp.cpp, vector.h, vector.cpp)– Logical Modules: 2 ( problem manager, vector class )

• Abstractions: – Language defined: Ifstream, Ofstream– Program defined: Vector

• Data Encapsulation: Vector Class

• Information Hiding: Complete for Vector abstraction– The Vector type is private (+)– The client (main) cannot access any internal components of Vector instances (+)– The internal view of Vector (polar vs. cartesian) is completely hidden in the class that defines vectors (+).

The client cannot exploit the internal view of Vector (+).

• OO-Ness: More than Functional+ – Variables are now full-fledged class instances (objects).– Dynamic memory management is (mostly) automated by the language.

• Reusability: Vector class is broadly reusable, and because of the inheritance mechanism supported by C++,

potential reusability is fully supported by the language (this is not true with the Functional+ --- no support for subtyping or class extension).

Distribution of Control:Essentially the same degreeof control distribution as waspresent in Functional+.