1. Comparison of Design Styles (Part II) Case Study: 2D Geometry Solver COP4331 OO Processes for Software Development © Dr. David A. Workman March 17, 2009

2. (c) Dr. David A. Workman2 Problem Statement Vector Application The 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.

3. March 17, 2009(c) Dr. David A. Workman3 Vector Abstraction Specification Requirements 1.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.

4. March 17, 2009(c) Dr. David A. Workman4 Use Case Model Vector Application System Specify Input File Specify Output File Read Problem Instance Write Problem Instance & Solution Compute Problem Solution * Application User « initiates » « includes » Ascii Input File Ascii Output File

5. March 17, 2009(c) Dr. David A. Workman5 Communication Diagram finMgr foutMgr App Control SystemIO ProblemMgr Problem Input Stream Output Stream Line Vector User

6. March 17, 2009(c) Dr. David A. Workman6 Class Diagram: Analysis Model std cin cout fin: ifstream fout: ofstream vectorspace VectorError Vector (1) IOMgmt InMgrIOError OutMgr (1) problemspace Problem ProblemErrorLine vectorapp (1) creates acquires streams and provides to (2) (3) 2 1 2 (1) throws exception (2) writes to (3) reads from Problem Mgr writes instances to reads instances from 1 1 Manages Intances of AppError

7. March 17, 2009(c) Dr. David A. Workman7 Mapping: Analysis Classes iomgmt cin cout SystemIO finMgrfoutMgr App Control ProblemMgr IOError InMgrOutMgr Fin: ifstream Problem Fout: ofstream Line Problem LineVector 2 vectorspace VectorError Input File Output Vector vectorapp ProblemMgr

8. March 17, 2009(c) Dr. David A. Workman8 Rationale: Analysis Model Package Definition Packages should be defined to encapsulate potentially autonomous subsystems or reusable components. In this problem there are four packages: a)problemspace: this package encapsulates the following application classes: VectorApp, ProblemMgr, Problem, Line, ProblemError. VectorApp is the main control class, ProblemMgr is the problem control class, Problem and Line are Entity classes, and ProblemError is an exception class. b)vectorspace: this package encapsulates the abstraction for 2D vectors and consists of the following classes: Vector and VectorError. Vector is an Entity class and VectorError is an exception class. c)IOMgmt: this package encapsulates the user interface classes necessary to create or initialize ascii input and output files used by an application. It consists of the following classes: InMgr, OutMgr, and IOError. InMgr and OutMgr are Boundary & Control classes, while IOError is an Exception classes. d)std: this is a library package provided access to boundary classes iostream, ios, ostream and boundary objects cin and cout. It also encapsulates ascii file boundary classes: ifstream and ofstream.

9. March 17, 2009(c) Dr. David A. Workman9 Rationale: Analysis Model IOMgmt was defined as a package for two reasons: (a)Many applications use ascii file IO. Such applications frequently require use cases for interacting with the user to obtain file names. InMgr encapsulates the use case for obtaining and opening an ascii input file stream – if this is not possible, an IOError exception is thrown to the client code. Similarly, OutMgr encapsulates the use case for obtaining and creating an ascii output file. Again, if this is not possible, an IOError exception is thrown to the client. Two independent classes are defined to give the client the flexibility of invoking one or both of these use cases in any order. (b)The vector application only calls for ascii file IO. However, other applications may require these same use cases implemented using GUI dialogue objects. By packaging these use cases, the developer can either add new classes to support GUI interaction or modifying the existing classes to change the style of interface – the former approach would be the preferred design choice.

10. March 17, 2009(c) Dr. David A. Workman10 Rationale: Analysis Model vectorspace was defined as a package for one primary reason: Many applications may require a 2D vector abstraction. This anticipates future reusability. problemspace This package is the default package and contains all the classes that are necessary to satisfy the problem-specific requirements. VectorApp: this is the main control function (object) and defines the primary execution entry point and control thread. Its primary responsibility is to acquire and distribute necessary application resources (two file stream objects) to the ProblemMgr – this control object responsible for managing the processing steps necessary to acquire and make ready the application resources. ProblemMgr: this is a control object that manages the computation necessary to parse each problem instance in the input file, to solve each problem instance, and to produce the required application output to the output file. It encapsulates the design decision relating to the how problem instances are created and how the corresponding solutions are generated. see notes

11. March 17, 2009(c) Dr. David A. Workman11 Rationale: Analysis Model problemspace (continued) Line: this entity class is an abstraction of a line in 2D space. It is designed as a composition of 2 vectors (points), and therefore its implementation reuses the vector abstraction. –Line also encapsulates the two methods necessary to solve each problem instance, that is, find the intersection of two lines and the distance of a vector (point) to a given line. These are natural and logical operations for line objects. –The line abstraction also encapsulates the knowledge about how a line object is to be represented on ascii file objects. –Line also hides the knowledge about its representation as two vector components. Problem: this is an entity class that encapsulates the data for a single problem instance. –Problem is composed of 2 lines and 1 vector. –Problem encapsulates how the problem components are arranged on the input file. –Problem encapsulates how the problem solution is to be presented on the output file. –Problem manages the computation necessary to produce the solution and to handle errors that might arise in reading problem data and computing the solution. ProblemError: this is an exception class providing data about the causes of exceptional conditions arising during problem IO and problem solving.

12. March 17, 2009(c) Dr. David A. Workman12 Class Specifications : Ideal Design main finMgr: InMgr foutMgr: OutMgr Interact with user to obtain the names of the input and output files. Open the input file to ensure it exists. Create the output file. (Control Object) Problem L1Id: string L2Id: string PtId: string L1, L2: Vector Pt: Vector Extract( InStream ); Insert( OutStream ); Solve( OutStream); Inputs and outputs instance of this class. Encapsulates format details on external io media. Entity Class ofstream Boundary Classes cincout Boundary Objects Vector x,y : Real; Extract( InStream ); Insert( OutStream ); CartX(): Real; CartY(): Real; Mag(): Real; UnitOf(): Vector Add( Vector ): Vector Sub(Vector ): Vector Mul( Real ): Vector Dot( Vector ): Real Cross( Vector): Real Inputs and outputs instance of this class. Encapsulates format details on external io media. Supports operations on vectors. Entity Class Line Anchor: Vector Direction: Vector /UnitDir: Vector Extract( InStream ) Insert( OutStream ) AnchorIs(): Vector DirectionIs(): Vector Entity Class Inputs and outputs instance of this class. Encapsulates format details on external io media. ifstream

13. March 17, 2009(c) Dr. David A. Workman13 Class Specifications : Ideal Design ProblemMgr P : Problem Probcount: Integer Constructor( Fin: InStream, Fout: OutStream ); Determines the order in which Problem instances are created and solved. Control Class ProblemError ErrorMsg: String throw() Defines application specific exceptional conditions raised during execution. Exception Class

14. March 17, 2009(c) Dr. David A. Workman14 Summary Design Principles & Lessons to Learn –Abstraction: procedural and data Procedural abstraction encapsulates a computation and typically takes parameters that provide variability needed to support a broad range of application contexts. Data abstractions encapsulate data and operations specific to that encapsulated data. –Encapsulation: organize related design features and decisions into separate and independently manageable modules. Modules should have a public interface and a private implementation component. The public interface presents an abstract view of the module’s purpose and functional capabilities (includes its name). The implementation hides details about how the abstraction is realized. –Information Hiding: details about representation of data and implementation of methods should be hidden from client modules. To be most effective requires support from the implementation language. –Reusability: computations that are repeatedly used in the same application and/or have potential for reuse in other applications should be captured in generalized [parameterized] modules using abstraction techniques. –Control Distribution: control flow should be organized around use cases (well-defined functions visible to, and understood by, system users). “Functions” encapsulate computations that manipulate objects independent of their representation, while “methods” encapsulate computations that define or depend on an object’s representation.