Vector Application : A UML Example © Dr. David A. Workman School of EE and CS University of Central Florida Feb. 8, 2001

February 8, 2001(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.

February 8, 2001(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.

February 8, 2001(c) Dr. David A. Workman4 Use Case Diagram Vector Application System Specify Input File Specify Output File Read Problem Instance Write Problem Instance & Solution Compute Problem Solution * Application User « initiates » « uses » « includes » Ascii Input File Ascii Output File

February 8, 2001(c) Dr. David A. Workman5 Collaboration Diagram InputPrepMgr OutputPrepMgr App Control SystemIO ProblemMgr Problem Input File Output File Line Vector

February 8, 2001(c) Dr. David A. Workman6 Class Diagram: Ideal Design VectorApp ProblemMgr SysINSysOUT Fin: BufferedReader Problem 1 Fout: PrintStream opens  reads instances from  creates & manages   (3) 2 ProblemError (4)   writes solution to 1..* filehandling InputError InputPrepMgr OutputError OutputPrepMgr creates  vectorspace VectorException Line 2 acquires and provides files to  (1)throws exception (2)implements (3)writes to (4)reads from (1) (2) Vector CartImp PolarImp (1) (2) creates (3)   (3) (3)  (4)  2

February 8, 2001(c) Dr. David A. Workman7 Design Rationale Package Definition Packages should be defined to encapsulate potentially autonomous subsystems or reusable components. In this problem there are four packages: a)vectorapplication: this package encapsulates the following application classes: VectorApp, ProblemMgr, Problem, Line, ProblemError. VectorApp is the main control class, ProblemMgr is a 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: CartImp, PolarImp, and VectorException; the package has a generic interface unit called Vector. CartImp is an Entity class implementing Vector using Cartesian coordinates of 2D vectors, while PolarImp is an Entity class implementing Vector using polar coordinates. VectorException is an exception class. c)filehandling: 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: InputPrepMgr, OutputPrepMgr, InputError, OutputError. InputPrepMgr and OutputPrepMgr are Control classes, while InputError and OutputError are Exception classes. d)java.io: this is a library package provided access to boundary class System and boundary objects System.in(SysIN) and System.out (SysOUT). It also encapsulates ascii file boundary classes: BufferedReader, PrintStream, File, InputStreamReader, FileOutputStream.

February 8, 2001(c) Dr. David A. Workman8 Design Rationale filehandling 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. InputPrepMgr encapsulates the use case for obtaining and opening an ascii input file – if this is not possible, InputError exception is thrown to the client code. Similarly, OutputPrepMgr encapsulates the use case for obtaining and creating an ascii output file. Again, if this is not possible, an OutputError 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 a particular order. (b)The current application only calls for ascii file IO. However, other applications may require these same use cases implemented using GUI dialogue window. 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.

February 8, 2001(c) Dr. David A. Workman9 Design Rationale vectorspace was defined as a package for one primary reason: Many applications may require a 2D vector abstraction. Thus the reason was for future reusability. An abstract interface was defined because at least two obvious implementations of 2D vectors should be provided to any application: one using cartesian coordinates and one using polar coordinates. vectorapplication This package is the default package and contains all the classes that are necessary to satisfy the application-specific requirements. VectorApp: this is the main class and defines the primary execution entry point and control thread. Its primary responsibility is to acquire and distribute necessary application resources (two file objects) to the ProblemMgr – the control object responsible for managing the processing steps necessary to fulfill application requirements. 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. see notes

February 8, 2001(c) Dr. David A. Workman10 Design Rationale vectorapplication (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 (two views: point + direction OR two points. 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.