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

Slides:



Advertisements
Similar presentations
Construction process lasts until coding and testing is completed consists of design and implementation reasons for this phase –analysis model is not sufficiently.
Advertisements

© Janice Regan, CMPT 102, Sept CMPT 102 Introduction to Scientific Computer Programming The software development method algorithms.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Chapter 3 Data Abstraction: The Walls. © 2005 Pearson Addison-Wesley. All rights reserved3-2 Abstract Data Types Modularity –Keeps the complexity of a.
1 Chapter 11 Structured Types, Data Abstraction and Classes Dale/Weems/Headington.
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Chapter 1 Principles of Programming and Software Engineering.
Software Lifecycle A series of steps through which a software product progresses Lifetimes vary from days to months to years Consists of –people –overall.
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Chapter 8: I/O Streams and Data Files. In this chapter, you will learn about: – I/O file stream objects and functions – Reading and writing character-based.
About the Presentations The presentations cover the objectives found in the opening of each chapter. All chapter objectives are listed in the beginning.
Objectives Explain the purpose and objectives of object- oriented design Develop design class diagrams Develop interaction diagrams based on the principles.
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
Lesson-21Process Modeling Define systems modeling and differentiate between logical and physical system models. Define process modeling and explain its.
C++ fundamentals.
The chapter will address the following questions:
Introduction To System Analysis and design
 2003 Prentice Hall, Inc. All rights reserved. 1 Introduction to Classes and Objects Outline Introduction Classes, Objects, Member Functions and Data.
Chapter 11: Inheritance and Composition. Objectives In this chapter, you will: – Learn about inheritance – Learn about derived and base classes – Redefine.
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 12 Object-Oriented.
MT311 Java Application Development and Programming Languages Li Tak Sing( 李德成 )
An Object-Oriented Approach to Programming Logic and Design
An Introduction to Software Architecture
School of Computer Science & Information Technology G6DICP - Lecture 22 The Theory of Object Oriented Programming.
Ch:10 Component Level Design Unit 4. What is Component? A component is a modular building block for computer software Because components reside within.
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
Vector Application : A UML Example © Dr. David A. Workman School of EE and CS University of Central Florida Feb. 8, 2001.
Engineering H192 - Computer Programming The Ohio State University Gateway Engineering Education Coalition Lect 24P. 1Winter Quarter C++ Lecture 24.
SE: CHAPTER 7 Writing The Program
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Systems Analysis and Design in a Changing World, 3rd Edition
1 Introduction to Software Engineering Lecture 1.
CSC480 Software Engineering Lecture 11 September 30, 2002.
Lab2 C++ Warmup: Pet Applicatioin Cop 4331 and EEL4884 © Dr. David A. Workman School of EE and Computer Science University of Central Florida February.
Data Structures Using C++ 2E1 Inheritance An “is-a” relationship –Example: “every employee is a person” Allows new class creation from existing classes.
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.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Introduction to c++ programming - object oriented programming concepts - Structured Vs OOP. Classes and objects - class definition - Objects - class scope.
CSCI 1100/1202 April 1-3, Program Development The creation of software involves four basic activities: –establishing the requirements –creating.
Data Structures and Algorithms Dr. Tehseen Zia Assistant Professor Dept. Computer Science and IT University of Sargodha Lecture 1.
Midterm Study Guide COP 4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of EE and Computer Science University of Central.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Software Engineering and Object-Oriented Design Topics: Solutions Modules Key Programming Issues Development Methods Object-Oriented Principles.
Software Design Concepts and Principles COP 4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of EE and Computer Science.
Data Design and Implementation. Definitions Atomic or primitive type A data type whose elements are single, non-decomposable data items Composite type.
Introduction to the Object-oriented Data Protocol © Dr. David Workman COP4331 School of EE and CS February 4, 2010.
Chapter 11: Inheritance and Composition. Introduction Two common ways to relate two classes in a meaningful way are: – Inheritance (“is-a” relationship)
Chapter 2 Principles of Programming and Software Engineering.
Principles of Programming. Achieving an Object-Oriented Design  Abstraction and Information Hiding  Object-Oriented Design  Functional Decomposition.
1 n Object Oriented Programming. 2 Introduction n procedure-oriented programming consists of writing a list of instructions and organizing these instructions.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
1 Chapter 12 Classes and Abstraction. 2 Chapter 12 Topics Meaning of an Abstract Data Type Declaring and Using a class Data Type Using Separate Specification.
Chapter 12 Classes and Abstraction
Data Abstraction: The Walls
SOFTWARE DESIGN AND ARCHITECTURE
Data Abstraction: The Walls
11.1 The Concept of Abstraction
Object Oriented Concepts -I
Object-Orientated Programming
Copyright © 2003 Pearson Education, Inc.
An Introduction to Software Architecture
Chapter 11: Inheritance and Composition
Applying Use Cases (Chapters 25,26)
Design Yaodong Bi.
Software Development Process Using UML Recap
Presentation transcript:

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

(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.

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.

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

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

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) (1) throws exception (2) writes to (3) reads from Problem Mgr writes instances to reads instances from 1 1 Manages Intances of AppError

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

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.

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.

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

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.

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

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

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.