Скачать презентацию CSE 230 Chapter 4 Software Design Prof Steven
a8f0f03ca9c699d1e29311b7f451953e.ppt
- Количество слайдов: 74
CSE 230 Chapter 4: Software Design Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269 -2155 steve@engr. uconn. edu http: //www. engr. uconn. edu/~stev e (860) 486 – 4818 (860) 486 – 3719 (office) CH 4. 1
CSE 230 Outline m m m What is Software Design? What is Modularization? q How Can a System Be Decomposed Into Modules? q What is a Module’s Interface? q What are the Main Relationships Among Modules? q What are Software Design Techniques/Information Hiding? q What are Different Types of Modules? Emerging Software Design Concerns q OO and UML q Distributed Software q Client-Server Architectures q Middleware and Service-Oriented Architectures q All Will be Covered in Separate Lectures (web) CH 4. 2
What is Software Design? m CSE 230 m m m Design is the Process of Converting System Requirements into a Completed Product Software Design is the Output of Process that q Decomposes System into Parts q Assigns Responsibilities to Each Part q Insure Parts fit Together to Achieve a Global Goal Design Refers to Both an Activity and the Result of the Activity Design is an Iterative Activity q Start from Initial Point q Evolve and Iterate by Adding Features/Capabilities q Reach a Steady State Based on … Ø Design Objectives/Goals Ø Customer’s Input/Feedback CH 4. 3
What is Software Design? m CSE 230 Software is Increasingly Refined and Elaborated Until Detailed Enough to Support Implementation q System is Separated into Modules (Components, Packages, Classes, etc. ) q Top-Down Decomposition Ø Large Modules (Components, Packages, Classes) are Decomposed into Smaller Ones Ø Smaller Ones Implement Larger Ones Ø Larger Ones Composed of Smaller Ones q Bottom-Up Decomposition Ø Lower Level Modules are Defined First Ø These Modules Combined to Form Larger Ones m Either TD or BU – Can Achieve the Same Result CH 4. 4
Examples of TD and BU Design CSE 230 CH 4. 5
What is Software Design? m CSE 230 Software Design is q Activity That Bridges Between Requirements and Implementation of Software q Activity That Gives A Structure To The Artifact Ø A Requirements Spec. Document Must Be Designed Ø Given a Structure that Makes It Easy To Understand Evolve m Software Design Activity q Defined as System Decomposition into Modules q Produces a Software Design Document Ø Describes System Decomposition Into Modules q Often a Software Architecture is Produced Prior To a Software Design CH 4. 6
What is a Software Architecture? m CSE 230 Software Architecture q Gross Organization of the System To Be Defined q Description Includes Description of Ø Main Components of A System Ø Relationships Among Those Components Ø Rationale for Decomposition Into its Components Ø Constraints That Must Be Respected By Any Design of The Components Guides the Development of the Design What are Some Sample Architectures? q m CH 4. 7
CSE 230 High-Tech Supermarket System (HTSS) m m m Automate the Functions and Actions q Cashiers and Inventory Updates q User Friendly Grocery Item Locator q Fast-Track Deli Orderer q Inventory Control User System Interfaces q Cash Register/UPC Scanner q GUI for Inventory Control q Shopper Interfaces Locator and Orderer q Deli Interface for Deli Workers We’ll Introduce and Utilize Throughout Course CH 4. 8
The HTSS Software Architecture CSE 230 SDO IL IL IL EDO SDO EDO Payment CR CR IL: CR: IC: DO: Item Locator Cash Register Invent. Control Deli Orderer for Shopper/Employee Item IC Order IC Non-Local Client Int. Credit. Card. DB Inventory Control Item. DB Global Server Item. DB Local Server ATM-Ban. KDB Order. DB Supplier. DB CH 4. 9
Business Process Model DB CSE 230 DB Historical Completed Records Applications Licensing DB Supervisor Review Scanner DB Licensing Division Scanning Operator Stored Images Licensing Division Printer Data Entry Operator DB Basic Information Entered New Licenses New Appointments FOI Letters (Request Information, etc. ) CH 4. 10
Two Important Goals m CSE 230 m Goal 1: Design for Change (Parnas) q Designers Tend to Concentrate on Current Needs q Special Effort to Anticipate Future Changes q Design for Likely Changes –Not All Possible Ones q Consider Future Versions and Capabilities q Remember >60% Cost is Maintenance for Both Fixing Problems and Adding New Features q Think about … Goal 2: Product Families (Parnas) q Think of Current System Under Design as a Member of Program Family q Not Simply Supermarket System, but Inventory Control for Any Business q Plan for Tomorrow’s Products CH 4. 11
Frequent Types of Changes m CSE 230 m m Algorithms (CSE 259) q Replace Inefficient Sorting Algorithm with a More Efficient One q From Bubble Sort to Merge Sort to Quick Sort q Choice Made Based on Characteristics of Data Change of Data Representation q From Array to Linked List to Doubly Linked List q From Binary Tree to Threaded Tree (See Example) q 17% Of Maintenance Costs Attributed To Data Representation Changes (Lientz And Swanson, 1980) Change in Data Representation May be a Result of a Change in Algorithm and Vice Versa CH 4. 12
CSE 230 Examples … CH 4. 13
Other Types of Changes m CSE 230 m m m Change Of Underlying Abstract Machine q New Release of Operating System q New Optimizing Compiler q New Version Of DBMS Change Of Peripheral Devices q Embedded, Avionics, Mobile Devices, etc. q Changes as a Result of Technology Improvements Change Of "Social" Environment q Change in Insurance Laws q New Way to Use Cell/Mobile Devices q EURO vs. National Currency in EU Change Due To Development Process (Transform Prototype into Product) CH 4. 14
CSE 230 Product Families m Different Versions Of The Same System q Family of Mobile Phones Ø Members of Family May Differ in Network Standards, End-user Interaction Languages, … q A Facility Reservation System Ø For Hotels: Reserve Rooms, Restaurant, Conference Space, …, Equipment (Video Beamers, Overhead Projectors, …) Ø For University: Many Functionalities are Similar, Some Are Different (Facilities May Be Free or Not) q Inventory Control Ø Supermarket: UPCs, Track, Stock, Sell, Purchase, … Ø Auto Parts: Same Ø Amazon: Same CH 4. 15
Design Objectives for Program Families m CSE 230 m Design Entire Family as One System, Not Each Individual Member of Family Separately Design for Today and Tomorrow q Understand Short Term Ø What is Today’s Product? Features? Ø What are the Deadlines? Deliverables q Factor in Long Term Ø Plan for Tomorrow’s Product Ø What are Future Related Products of Company? Ø Design to Consider these Future Products Ø Ease of Building Future Solutions m What is Available Today for Families? q OO: Components and Inheritance q Source Code Control/Version Management CH 4. 16
Sequential Completion: A Graphical View CSE 230 Requirements 1 1 1 intermediate design 2 2 final product 2 Version 1 3 4 6 4 4 Version 1 Version 2 3 5 5 7 Version 3 Version 2 CH 4. 17
What is Modularization? m CSE 230 m Modularization Leverages Off of Software Architectural Ideas q SW Architectures Decompose System into Interacting Components (Previous Examples) q Typically, These Components Exist as Independent Interacting Programs on Hardware Platforms q Modularization Explores the Decomposition of These Components into Interacting Modules Module: q Well-defined Component of Software System q Part of System that Provides Set of Services To Other Modules Ø Services are Computational Elements Available for Use by Other Modules Ø Modules Publish Services and Import Services CH 4. 18
Example of Modularization m CSE 230 m Recall the Cash Register Component of HTSS CR Contains Modules q UPC Scanner q Record Item Sold Ø Reduce Inventory Ø Add to Receipt Ø Add to Profile on Customer q Payment Ø Coupons Ø Cash/Debit/Credit Receipt These Modules Interact with One Another and HTSS Components q m CH 4. 19
What are Key Modularization Concepts? m CSE 230 m What is Tracked for Various Modules? q UPC Scanner, Record Item Sold, Payment, Receipt Interface: Exported for Use by Other Modules q UPC Scanner Exports Ø Scan Function Returns UPC Code, Item Name, Price q Item. DB Exports Ø Item. Query Function Returns Name, Price given UPC Imported for Use by Specific Module q UPC Scanner Imports Ø Item. Query Function of Item. DB q Payment Imports Ø Functions of Credit. Card and ATMBank. DB Exports CH 4. 20
What Does this Represent? m CSE 230 The Client/Server Paradigm! UPC Scanner Client Imports from Item. DB And Other Modules m m m USES Item. DB Server Exports for use by UPC Scanner and Other Modules UPC Scanner – Client that Requests Services Item. DB – Server that Provides Services Establishes Contract Between Modules! CH 4. 21
Another Example of Modules m CSE 230 m Consider an OS with: q File System, Disk I/O Subsystem, DBMS q Network Server, GUI, Compilers, Desktop Tools From Everyday User Perspective: File System GUI m DBMS Desktop Tools From Software Engineer Perspective: File System DBMS GUI Desktop Tools Compilers Network Server Disk I/O Subsystem CH 4. 22
CSE 230 Impact of Modularization m m m Pervasive Throughout Software and Computing Client/Server/Import/Export/USES have Contexts q OO/Java – Client/Server Classes, Public Interfaces (Export), Import XX. * (Import), … q Web-Based Setting – Client/Server Applications, Clients Use (Import) Services, Servers Provide Services (Export) q Middleware – JINI, CORBA, . NET At Design/Conceptual Level, We Must Understand: q What Does Each Module Provide (Export)? q What Does Each Module Need (Import)? q What Does Each Module Hide (Implementation)? q How to Modules Depend on One Another (Uses, Is_Component_Of, and Comprises Relations) CH 4. 23
Modules and Relations m CSE 230 m m Let S be a Set of Modules S = {M 1, M 2, . . . , Mn} A Binary Relation r on S is a subset of S x S for Defining Relations Among Modules If Mi and Mj are in S,
Relations m CSE 230 m Relations can be Represented as Graphs A Hierarchy (Lattice) is a DAG (directed acyclic graph) a graph a DAG CH 4. 25
Recall The USES Relation m CSE 230 m X uses Y q X Requires the Correct Operation of Y q X can Access (Import) Subset of Services Exported by Y through its Interface q X Depends on Y to Provide its Services q X is a client of Y; Y is a server to X and Others Desirable Property - USES should be a Hierarchy q Makes Software Easier to Understand Ø We Can Proceed From Leaf Nodes (Who Do Not Use Others) Upwards Build and Test With Cycles, Build and Test Must Occur After all Modules in the Cycle are Coded With Hierarchy – Separation of Concerns q m m CH 4. 26
Hierarchy m CSE 230 m m Organizes the Modular Structure through Levels of Abstraction Each Level defines an Abstract (Virtual) Machine for the Next Level, and can be Defined Precisely q Mi has level 0 if no Mj exists s. t. Mi r Mj q Let k be the maximum level of all nodes Mj s. t. Mi r Mj. Then Mi has level k+1 In Hierarchy: q Fan-Out is Outgoing Edges of a Module q Fan-In is the Incoming Edges from Other Modules q Low Fan-In, High-Fan Out Preferable – Why? Ø Coupling and Cohesion! CH 4. 27
Relations Between Modules m CSE 230 m m m Relations Can Describe the Dependencies that Exist Among Modules w. r. t. Composition X IS_COMPONENT_OF Y q Bottom-Up Composition q Y consists of Several Modules, of which one is X B COMPRISES A q Top-Down Composition q Inverse of IS_COMPONENT_OF MS, i={Mk|Mk S Mk IS_COMPONENT_OF Mi} we say that MS, i IMPLEMENTS Mi CH 4. 28
Graphically: CSE 230 M M M 8 9 7 M 5 M 2 M 3 M 6 M 4 M 1 (IS_COMPONENT_OF) M 1 M 2 M M M 8 9 7 M 5 M 4 M 3 M 6 (COMPRISES) Each Forms a Hierarchy (DAG) CH 4. 29
Interface, Implementation, and Hiding m CSE 230 m m m In Support of Relations (Uses, Is_Component_Of, and Comprises), Modules Share Vehicle of Sharing: Interface q Set of Services (Operations) Module Can Perform q Subset is Exported for Use by Other Modules q Module Imports Services from Other Modules Internally, Module Implements Its Services Separation of Concerns: q Differentiates Between the Exported Services Ø Operations and Their Signatures Ø Signature: Name, Parameters and Types, Return q Hidden Implementation that Realizes Services CH 4. 30
Interface, Implementation, and Hiding m CSE 230 When a Module X Uses a Particular Module Y, X Only Needs Y’s Interface, Not its Implementation q Interface is a Contract Between X and Y q Client Modules Rely on this Unchanging Interface q Akin to: Ø Class Depending on Public Interface of another Class Ø Web App (Browser) Depending on the Interface of a Web Server Changes Strongly Discouraged (Deprecated APIs) Module Y’s Implementation May be Composition of Other Modules or Actual Code q Code Changes to Implementation Allowed as Long as Exported Interface Remains Unchanged q Additions to Interface Allowed q m CH 4. 31
CSE 230 Examples of Modules MODULE Table MODULE Buffer Procedure Insert; Procedure Find; Procedure Enter; Procedure Leave; const nul; Const Limit; Var tab, avail; … Procedure bodies … initialization Const maxbuf; Var size, front, …; Procedure succ; … Procedure bodies; … initialization CH 4. 32
CSE 230 Implementation of Modules definition MODULE Table; export qualified insert, find; procedure insert (x: integer): boolean; procedure find (x: integrer): boolean; end table. implementation MODULE Table; // Data structures (e. g. , list, array) to // hold elements of table procedure insert (x: integer): boolean; //implementation of insert end insert; procedure find (x: integrer): boolean; //implementation of find end find; begin //initialization of data structure for table end; end table. CH 4. 33
CSE 230 Interface vs. Implementation m To Understand Nature of USES, we Need to Know What a Used Module Exports Through Its Interface q Client Imports Resources Exported by Its Servers q Modules Implement Exported Resources q Implementation Hidden From Clients interface is like the tip of the iceberg CH 4. 34
Designing Module Interfaces m CSE 230 What Goes in the Public Interface of Module X? q Convey to Client Services Provided by X q Too Much Information in Interface Increases Overall System Complexity q Including Internal Implementation Detail May Cause Implementation change to Affect Interface q Not Enough Information Ø Module X Not Used Correctly or at All m Prototyping Process - Once an interface is defined q Implementation can be Done Ø First Quickly and Potentially Inefficiently to Allow Interface Users to Try and See if All Services Available Ø Progressively turned into the Final Version q Initial Prototype that Evolves into Final Product CH 4. 35
Designing Module Interfaces m CSE 230 m How is Evolution Supported? Similar to OO! q Module’s Abstract Interface hides Implementation q Implementation can Change (Array to List) without Impacting Interfaces q Interface can be Extended as Long as Prior Services still Work q Module’s Final Implementation can be Delayed Key Issue: q Identify Module Features Most Likely to Change q Isolate those Features in Implementation CH 4. 36
CSE 230 Designing Module Interfaces m m m Interface Must Insulate Users for All Possible Changes Policy Changes Must Also be Encapsulated q Suppose List of Mailing Labels q Printing List in Alphabetical Order – Interface q Whether the List is Kept Sorted, Sorted then Printed, etc. – Hidden Implementation Policies May be Separated From Mechanisms q Mechanism - Ability to Suspend and Resume Tasks in Concurrent System q Policy - How Do We Select Next Task To Resume? Ø Different Scheduling Policies are Available Ø They May Be Hidden to Clients Ø They Can Be Encapsulated as Module Secrets CH 4. 37
Design Notations for Modules m CSE 230 m m m Notations allow Designs to be Described Precisely q At Design Level, English is too Ambiguous to Fully Describe Software Design q Like a Notation that can Facilitate Transition to Implementation (Writing Code) q Still no Acceptable Standard Notations can be Textual or Graphic We Illustrate two Sample Notations q TDN (Textual Design Notation) q GDN (Graphical Design Notation) We Briefly Discuss the Notations Provided by UML CH 4. 38
TDN m CSE 230 m TDN is Loosely Based on Ada – Similarities to Other Languages as Well Three Parts q Interface Description Ø What is Exported (Variables, Operations, Types, etc. ) Ø Comments to Describe Protocols, Exported Resource, Other Restrictions (e. g. , Time Availability of Service) q Uses Ø Names of Other Modules that are Used q Implementation Ø Description Ø List of Internal Components via Is_Composed_Of CH 4. 39
CSE 230 An Example in TDN m m Client Views Export Portions Only TDN Must Support Consistency and Completeness q R and T must be Defined to Implement X q Y and Z must be Available (Import) CH 4. 40
CSE 230 An Example in TDN - Continued m Notes: q Exporting of Structure (K) and Type (B) in Module R q Uses Indicates all Dependencies Among Modules CH 4. 41
Another Example: Compiler module COMPILER exports procedure MINI (PROG: in file of char; CODE: out file of char); CSE 230 MINI is called to compile the program stored in PROG and produce the object code in file CODE implementation A conventional compiler implementation. ANALYZER performs both lexical and syntactic analysis and produces an abstract tree, as well as entries in the symbol table; CODE_GENERATOR generates code starting from the abstract tree and information stored in the symbol table. MAIN acts as a job coordinator. and is composed of ANALYZER, SYMBOL_TABLE, ABSTRACT_TREE_HANDLER, CODE_GENERATOR, MAIN end COMPILER CH 4. 42
CSE 230 Other Compiler Modules module MAIN uses ANALYZER, CODE_GENERATOR exports procedure MINI (PROG: in file of char; CODE: out file of char); … end MAIN module ANALYZER uses SYMBOL_TABLE, ABSTRACT_TREE_HANDLER exports procedure ANALYZE (SOURCE: in file of char); SOURCE is analyzed; an abstract tree is produced by using the services provided by the tree handler, and recognized entities, with their attributes, are stored in the symbol table. . end ANALYZER CH 4. 43
Other Compiler Modules CSE 230 module CODE_GENERATOR uses SYMBOL_TABLE, ABSTRACT_TREE_HANDLER exports procedure CODE (OBJECT: out file of char); The abstract tree is traversed by using the operations exported by the ABSTRACT_TREE_HANDLER and accessing the information stored in the symbol table in order to generate code in the output file. … end CODE_GENERATOR CH 4. 44
CSE 230 GDN m m Graphical Notations are Easier to Read & Understand CSE is Dominated by Graphical Notations: q ER, DFDs, Petri Nets, FSM, etc… q UML and its 13 Diagrams (UML 2. 0). CH 4. 45
X's Decomposition CSE 230 CH 4. 46
Standard Categories of Modules m CSE 230 Functional Modules q Traditional Form Of Modularization q Provide A Procedural Abstraction q Encapsulate An Algorithm Ø Sorting Module, Fast Fourier Transform Module, … m Libraries q A Group Of Related Procedural Abstractions Ø Mathematical Libraries Ø Implemented By Routines Of Programming Languages m Common Pools Of Data q Data Shared By Different Modules Ø Configuration Constants Ø The COMMON FORTRAN Construct CH 4. 47
Abstract Objects m CSE 230 Abstract Objects q Objects Manipulated via Interface Functions q Data Structure Hidden From Clients q Maintains a State Ø Two Identical Calls May Produce Different Results Ø Library: Two Identical Calls Produce Same Results m Example q Stack of Integers q Interface: Push, Pop operations q Implementation: Array or Linked List q Two Successive Pops on Full Stack May Return Two Different Values CH 4. 48
CSE 230 Abstract Data Types (ADT) m ADT is Module Describes a Set of Behavior From Which Specific Instances can be Generated q Set of Operations to Manipulate Instances q Encapsulate the Implementation indicates that details of the data structure are hidden to clients CH 4. 49
ADTs m CSE 230 m ADTs at Implementation Level: q Correspond to Java and C++ Classes q May also be Implemented by Ada Private Types and Modula-2 Opaque Types May Add Notational Details to Specify if Certain built -in operations are Available by Default on Instance Objects of the ADT q : = to Assign an ADT Instance to Variable q = to Compare Two ADT Instances CH 4. 50
CSE 230 Another ADT Example m m Model Cars Waiting for Gas (in our Future? ) How is FIFO_CARS Used? q Assumes Existence of CARS Module module FIFO_CARS uses CARS exports type QUEUE : ? ; procedure ENQUEUE (Q: in out QUEUE ; C: in CARS); procedure DEQUEUE (Q: in out QUEUE ; C: out CARS); function IS_EMPTY (Q: in QUEUE) : BOOLEAN; function LENGTH (Q: in QUEUE) : NATURAL; procedure MERGE (Q 1, Q 2 : in QUEUE ; Q : out QUEUE); This is an abstract data-type module representing queues of cars, handled in a strict FIFO way; queues are not assignable or checkable for equality, since “: =” and “=” are not exported. … end FIFO_CARS CH 4. 51
Generic Modules m CSE 230 m Many Applications Employ the Same Abstraction (Module) in Different Contexts q Stack of Integers, Strings, Employees, etc. Generic Module q Single Abstract Description that is Paramterizable by Type (Integer, String, CAR, etc. ) q Shared Interface and Single Implementation q Once Tested, Provides Stability and Consistency for Usage by Entire Software Team q Reduces the Impact of Changes (From Array to Linked List – all Benefit) q Highly Reusable CH 4. 52
Generic Modules m CSE 230 Note the Parameterization by T generic module GENERIC_STACK_2. . . exports procedure PUSH (VAL : in T); procedure POP_2 (VAL 1, VAL 2 : out T); … end GENERIC_STACK_2 m Instantiation as: module INTEGER_STACK_2 is GENERIC_STACK_2 (INTEGER) m Support for Generic Modules: q Templates in C++ q Interface Inheritance in Java CH 4. 53
Design for Change m CSE 230 m In Practice, there Must be Programming Techniques that Allow for Changes without Need to Recompile Configuration Constants q Factoring Constant Values into Symbolic Constants is a Common Implementation Practice Ø #define in C Ø #define Max. Speed 5600 q Java/C++, Define System_Constant Class: Ø DB Port, Name, Internet Location, etc. Ø System Constants and Identifiers Ø All are Stored in ASCII File on Local Machine Ø Start Up Create Instance of System_Constant Ø Load Instance from File Ø Change File – No Need to Recompile CH 4. 54
Design for Change m Conditional Compilation in C, C++ (C#? ) . . source fragment common to all versions. . . # ifdef hardware-1. . . source fragment for hardware 1. . . # endif #ifdef hardware-2. . . source fragment for hardware 2. . . # endif CSE 230 m Software Generation q Compilers (Lex, Yacc) Automatically Regenerate Code when Change in Specification q GUI Construction Tools Allow Drag and Drop for GUI Components and Generate Code CH 4. 55
Stepwise Refinement m CSE 230 m m A Systematic, Iterative Program Design Technique that May Lead to Software that is Hard to Evolve At Each Step, Problem P Decomposed Into q Sequence of Sub-problems: P 1; P 2; …Pn q A Selection: If (Cond) Then P 1 Else P 2 q An Iteration: While (Cond) Do_something Utilizes a Natural langauge Like Description Overall Problem is represented by Rewriting Each Subproblem into the Overall Structure Intended for Programming-in-the-Small (or for Programming Individual Methods) CH 4. 56
Selection Sort CSE 230 Step 1 let n be the length of the array a to be sorted; i : = 1 ; while i < n loop find the smallest of ai. . . an, and exchange it with the element at position i; i : = i + 1; end loop; CH 4. 57
CSE 230 Selection Sort Step 2 let n be the length of the array a to be sorted; i : = 1 ; while i < n loop j : = n; while j > i loop if a(i) > a(j) then interchange the elements at positions j and i ; end if; j : = j - 1; end loop; i : = i + 1; end loop; CH 4. 58
CSE 230 Selection Sort Step 3 let n be the length of the array a to be sorted; i : = 1 ; while i < n loop j : = n; while j > i loop if a(i) > a(j) then x : = a(i); a(i) : = a(j); a(j) : = x; end if; j : = j - 1; end loop; i : = i + 1; end loop; CH 4. 59
CSE 230 Decomposition Tree m Stepwise Refinement Process May be Depicted by a Decomposition Tree (DT) q Root Labeled By Name of Top Problem q Subproblem Nodes Labeled as Children of Parent Node Corresponding To Problem q Children From Left To Right Represent Sequential Order Of Execution q If and While Nodes Denoted By Suitable Decoration CH 4. 60
CSE 230 Example Step 1 P; P problem to solve Step 2 P 1; P 2; P 3; P decomposed into sequence Step 3 P 1; while C loop P 2, 1; P 2 decomposed into a loop end loop; P 3; Step 4 P 1; while C loop if C 1 then P 2, 1 decomposed into selection P 2, 1, 1; else P 2, 1, 2; end if; end loop; P 3; CH 4. 61
Corresponding DT CSE 230 CH 4. 62
Stepwise Refinement m CSE 230 m m Stepwise Refinement a Programming Technique, Not a Modularization Technique When Used to Decompose System Into Modules q Tends to Analyze Problems In Isolation, Not Recognizing Commonalities q Does Not Stress Information Hiding q Does Not Consider Generalization Across Subproblems q Top Level Function Not Clearly Identifiable No Attention Paid to Data (Decomposes Functions) Enforces Premature Commitment To Control Flow Structures Among Modules However, Code Written with Stepwise Refinement is Clear and Easily Understood CH 4. 63
CSE 230 Another Example with Various Techniques Consider a Program Analyzer First – Stepwise Refinement m m Step 1 Recognize a program stored in a given file f; Step 2 correct : = true; analyze f according to the language definition; if correct then print message "program correct"; else print message "program incorrect"; end if; CH 4. 64
CSE 230 Stepwise Refinement (Continued) Step 3 correct : = true; perform lexical analysis: store program as token sequence in file ft and symbol table in file fs, and set error_in_lexical_phase accordingly; if error_in_lexical_phase then correct : = false; else perform syntactic analysis and set Boolean variable error_in_syntactic_phase accordingly: if error_in_syntactic_phase then correct : = false; end if; if correct then else end if; print message "program correct"; print message "program incorrect"; CH 4. 65
What is the Problem with This Solution? m CSE 230 m m Step 3 Differentiates Between Lexical and Syntax Analysis q Lexical Analysis First on the Entire Program q If Successful, then Syntax Analysis Thus – it is a Two Pass Solution q If First Pass Fails, Second Pass Not Checked q Lexical Failure Means no Syntax Check Suppose we Want to Switch to a Process Driven by Syntax Analysis q Syntax Analyzer Requests a Token from Lexical Analyzer q Parsing and Lexical Analysis in Single Pass q Everything Changes!!! CH 4. 66
An Alternative Design via Modules m CSE 230 m m Module CHAR_HOLDER q Hides Physical Representation of Input File q Exports Operation to Access Source File on A Character-by-Character Basis Module SCANNER q Hides Details of Lexical Structure of the Language q Exports Operation to Provide Next Token Module PARSER q Hides Data Structure Used To Perform Syntactic Analysis (Abstract Object PARSER) CH 4. 67
CSE 230 Top-Down vs. Bottom-up m m m Information Hiding Proceeds Bottom-up Iterated Application of IS_COMPOSED_OF Proceeds Top-Down q Stepwise Refinement is Intrinsically Top-down Which One Is Best? q In Practice, People Proceed in Both Directions Ø Yo-yo Design Goes Back and Forth Between Both q Organizing Documentation as a Top-down Flow May Be Useful For Reading Purposes, Even If The Process Followed Was Not Top-down CH 4. 68
CSE 230 Handling Anomalies m m Defensive Design – Plan For Failure as Part of Design A Module is Anomalous if it Fails to Provide the Service As Expected and as Specified in is Interface An Exception MUST Be Raised When Anomalous State is Recognized If Anomaly is Detected … q Module M Should Fail and Raise an Exception if Ø One Of Its Clients Does Not Satisfy the Required Protocol For Invoking One Of M’s Services Ø M Does Not Satisfy the Required Protocol When Using One Of Its Servers, and the Server Fails Ø Hardware Generated Exception (Division By Zero) CH 4. 69
CSE 230 What A Module Can Do Before Failing m Before Failing, Modules May try to Recover From Anomaly by Executing Some Exception Handler (EH) q Local Piece of Code that tries to Recover From Anomaly (If Successful, Module Doesn’t Fail) q Or May Simply Do Cleanup of State and Let the Module Fail, Signaling an Exception to Its Client CH 4. 70
Case Study – MIDI Compiler m CSE 230 m Block Structured Prog. Language that Needs a Symbol Table Module for Block Static Nesting Version 1 of the Symbol Table CH 4. 71
CSE 230 Problem with Version 1 m m m Version 1 is Not Robust Defensive Design should be Applied Exceptions Must be Raised in Numerous Cases: q INSERT: Insertion Cannot Be Done Because Identifier with Same Name Already Exists in Current Scope q RETRIEVE And LEVEL: Identifier with Specified Name Not Visible q ENTER_SCOPE: Maximum Nesting Depth Exceeded q EXIT_SCOPE: No Matching Block Entry Exists CH 4. 72
Generic List Management Module CSE 230 CH 4. 73
CSE 230 Chapter 4 - Summary m m Jump to OO Design Slides … Other Upcoming Topics Include: q Software Specification (Chapter 5) that Includes: Ø Classic Techniques: Data-Flow Diagrams, Entity. Relationship Diagrams, Finite State Machines, Petri. Nets, etc. Ø UML (Ghezzi and Web Page) Ø Writing Specifications – What are They and What do They Contain? q q Software Architectures Service-Oriented Architectures/Middleware CH 4. 74