1. Chapter 4: Software Design
Prof. Steven A. Demurjian
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT
(860) 486 – 4818
(860) 486 – 3719 (office)

2. Outline What is Software Design? What is Modularization?
How Can a System Be Decomposed Into Modules?
What is a Module’s Interface?
What are the Main Relationships Among Modules?
What are Software Design Techniques/Information Hiding?
What are Different Types of Modules?
Emerging Software Design Concerns
OO and UML
Distributed Software
Client-Server Architectures
Middleware and Service-Oriented Architectures
All Will be Covered in Separate Lectures (web)

3. What is Software Design?
Design is the Process of Converting System Requirements into a Completed Product
Software Design is the Output of Process that
Decomposes System into Parts
Assigns Responsibilities to Each Part
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
Start from Initial Point
Evolve and Iterate by Adding Features/Capabilities
Reach a Steady State Based on …
Design Objectives/Goals
Customer’s Input/Feedback

4. What is Software Design?
Software is Increasingly Refined and Elaborated Until Detailed Enough to Support Implementation
System is Separated into Modules (Components, Packages, Classes, etc.)
Top-Down Decomposition
Large Modules (Components, Packages, Classes) are Decomposed into Smaller Ones
Smaller Ones Implement Larger Ones
Larger Ones Composed of Smaller Ones
Bottom-Up Decomposition
Lower Level Modules are Defined First
These Modules Combined to Form Larger Ones
Either TD or BU – Can Achieve the Same Result

5. Examples of TD and BU Design

6. What is Software Design?
Software Design is
Activity That Bridges Between Requirements and Implementation of Software
Activity That Gives A Structure To The Artifact
A Requirements Spec. Document Must Be Designed
Given a Structure that Makes It Easy To Understand and Evolve
Software Design Activity
Defined as System Decomposition into Modules
Produces a Software Design Document
Describes System Decomposition Into Modules
Often a Software Architecture is Produced Prior To a Software Design

7. What is a Software Architecture?
Gross Organization of the System To Be Defined
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?

8. High-Tech Supermarket System (HTSS)
Automate the Functions and Actions
Cashiers and Inventory Updates
User Friendly Grocery Item Locator
Fast-Track Deli Orderer
Inventory Control
User System Interfaces
Cash Register/UPC Scanner
GUI for Inventory Control
Shopper Interfaces Locator and Orderer
Deli Interface for Deli Workers
We’ll Introduce and Utilize Throughout Course

9. The HTSS Software Architecture
SDO
EDO IL
Item
SDO
EDO IL
ItemDB
Local
Server IL
Payment CR CR IC
Order CR
Non-Local
Client Int. IC CR
IL: Item Locator
CreditCardDB
CR: Cash Register
Inventory
Control
IC: Invent. Control
ATM-BanKDB
DO: Deli Orderer for
Shopper/Employee
ItemDB
Global
Server
OrderDB
SupplierDB

10. Business Process Model
Scanner
Licensing
Division
Scanning
Operator
Stored
Images
Basic
Information
Entered DB
Completed
Applications
Historical
Records
Printer
New Licenses
New Appointments
FOI
Letters (Request
Information, etc.)
Licensing Division
Data Entry Operator
Supervisor
Review

11. Two Important Goals Goal 1: Design for Change (Parnas)
Designers Tend to Concentrate on Current Needs
Special Effort to Anticipate Future Changes
Design for Likely Changes –Not All Possible Ones
Consider Future Versions and Capabilities
Remember >60% Cost is Maintenance for Both Fixing Problems and Adding New Features
Think about …
Goal 2: Product Families (Parnas)
Think of Current System Under Design as a Member of Program Family
Not Simply Supermarket System, but Inventory Control for Any Business
Plan for Tomorrow’s Products

12. Frequent Types of Changes
Algorithms (CSE259)
Replace Inefficient Sorting Algorithm with a More Efficient One
From Bubble Sort to Merge Sort to Quick Sort
Choice Made Based on Characteristics of Data
Change of Data Representation
From Array to Linked List to Doubly Linked List
From Binary Tree to Threaded Tree (See Example)
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

13. Examples …

14. Other Types of Changes Change Of Underlying Abstract Machine
New Release of Operating System
New Optimizing Compiler
New Version Of DBMS
Change Of Peripheral Devices
Embedded, Avionics, Mobile Devices, etc.
Changes as a Result of Technology Improvements
Change Of "Social" Environment
Change in Insurance Laws
New Way to Use Cell/Mobile Devices
EURO vs. National Currency in EU
Change Due To Development Process (Transform Prototype into Product)

15. Product Families Different Versions Of The Same System
Family of Mobile Phones
Members of Family May Differ in Network Standards, End-user Interaction Languages, …
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)
Inventory Control
Supermarket: UPCs, Track, Stock, Sell, Purchase, …
Auto Parts: Same
Amazon: Same

16. Design Objectives for Program Families
Design Entire Family as One System, Not Each Individual Member of Family Separately
Design for Today and Tomorrow
Understand Short Term
What is Today’s Product? Features?
What are the Deadlines? Deliverables
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
What is Available Today for Families?
OO: Components and Inheritance
Source Code Control/Version Management

17. Sequential Completion: A Graphical View
Requirements 1 2 3
Version 1 4
Requirements 1 2 3
Version 2 5
Version 1
Requirements 1
intermediate
design 2 4
final
product 3
Version 1 4 6 5 7
Version 3
Version 2

18. What is Modularization?
Modularization Leverages Off of Software Architectural Ideas
SW Architectures Decompose System into Interacting Components (Previous Examples)
Typically, These Components Exist as Independent Interacting Programs on Hardware Platforms
Modularization Explores the Decomposition of These Components into Interacting Modules
Module:
Well-defined Component of Software System
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

19. Example of Modularization
Recall the Cash Register Component of HTSS
CR Contains Modules
UPC Scanner
Record Item Sold
Reduce Inventory
Add to Receipt
Add to Profile on Customer
Payment
Coupons
Cash/Debit/Credit
Receipt
These Modules Interact with One Another and HTSS Components

20. What are Key Modularization Concepts?
What is Tracked for Various Modules?
UPC Scanner, Record Item Sold, Payment, Receipt
Interface: Exported for Use by Other Modules
UPC Scanner Exports
Scan Function Returns UPC Code, Item Name, Price
ItemDB Exports
ItemQuery Function Returns Name, Price given UPC
Imported for Use by Specific Module
UPC Scanner Imports
ItemQuery Function of ItemDB
Payment Imports
Functions of CreditCard and ATMBankDB Exports

21. What Does this Represent?
The Client/Server Paradigm!
UPC Scanner – Client that Requests Services
ItemDB – Server that Provides Services
Establishes Contract Between Modules!
UPC Scanner
ItemDB
USES
Client
Server
Imports from ItemDB
And Other Modules
Exports for use by
UPC Scanner and
Other Modules

22. Another Example of Modules
Consider an OS with:
File System, Disk I/O Subsystem, DBMS
Network Server, GUI, Compilers, Desktop Tools
From Everyday User Perspective:
From Software Engineer Perspective:
File System
DBMS
GUI
Desktop Tools
File System
DBMS
GUI
Desktop Tools
Compilers
Network Server
Disk I/O Subsystem

23. Impact of Modularization
Pervasive Throughout Software and Computing
Client/Server/Import/Export/USES have Contexts
OO/Java – Client/Server Classes, Public Interfaces (Export), Import XX.XX.* (Import), …
Web-Based Setting – Client/Server Applications, Clients Use (Import) Services, Servers Provide Services (Export)
Middleware – JINI, CORBA, .NET
At Design/Conceptual Level, We Must Understand:
What Does Each Module Provide (Export)?
What Does Each Module Need (Import)?
What Does Each Module Hide (Implementation)?
How to Modules Depend on One Another (Uses, Is_Component_Of, and Comprises Relations)

24. Modules and Relations Let S be a Set of Modules
S = {M1, M2, . . ., 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, <Mi, Mj>  r can be written as Mi r Mj
Transitive Closure r+ of r
Mi r+ Mj iff
Mi r Mj or  Mk in S s.t. Mi r Mk and Mk r+ Mj
The Relation r Forms a hierarchy iff there are no Two Elements Mi, Mj s.t. Mi r+ Mj  Mj r+ Mi

25. Relations Relations can be Represented as Graphs
A Hierarchy (Lattice) is a DAG (directed acyclic graph)
a graph
a DAG

26. Recall The USES Relation
X uses Y
X Requires the Correct Operation of Y
X can Access (Import) Subset of Services Exported by Y through its Interface
X Depends on Y to Provide its Services
X is a client of Y; Y is a server to X and Others
Desirable Property - USES should be a Hierarchy
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

27. Hierarchy
Organizes the Modular Structure through Levels of Abstraction
Each Level defines an Abstract (Virtual) Machine for the Next Level, and can be Defined Precisely
Mi has level 0 if no Mj exists s.t. Mi r Mj
Let k be the maximum level of all nodes Mj s.t. Mi r Mj. Then Mi has level k+1
In Hierarchy:
Fan-Out is Outgoing Edges of a Module
Fan-In is the Incoming Edges from Other Modules
Low Fan-In, High-Fan Out Preferable – Why?
Coupling and Cohesion!

28. Relations Between Modules
Relations Can Describe the Dependencies that Exist Among Modules w.r.t. Composition
X IS_COMPONENT_OF Y
Bottom-Up Composition
Y consists of Several Modules, of which one is X
B COMPRISES A
Top-Down Composition
Inverse of IS_COMPONENT_OF
MS,i={Mk|MkSMk IS_COMPONENT_OF Mi}
we say that MS,i IMPLEMENTS Mi

29. Graphically: Each Forms a Hierarchy (DAG) M 1 2 4 5 6 7 8 9 3
(IS_COMPONENT_OF)
(COMPRISES)
Each Forms a Hierarchy (DAG)

30. Interface, Implementation, and Hiding
In Support of Relations (Uses, Is_Component_Of, and Comprises), Modules Share
Vehicle of Sharing: Interface
Set of Services (Operations) Module Can Perform
Subset is Exported for Use by Other Modules
Module Imports Services from Other Modules
Internally, Module Implements Its Services
Separation of Concerns:
Differentiates Between the Exported Services
Operations and Their Signatures
Signature: Name, Parameters and Types, Return
Hidden Implementation that Realizes Services

31. Interface, Implementation, and Hiding
When a Module X Uses a Particular Module Y, X Only Needs Y’s Interface, Not its Implementation
Interface is a Contract Between X and Y
Client Modules Rely on this Unchanging Interface
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
Code Changes to Implementation Allowed as Long as Exported Interface Remains Unchanged
Additions to Interface Allowed

32. Examples of Modules MODULE Table MODULE Buffer Procedure Insert;
Procedure Find;
Const Limit;
Var tab, avail; …
Procedure bodies
initialization
Procedure Enter;
Procedure Leave; const nul;
Const maxbuf;
Var size, front, …;
Procedure succ; …
Procedure bodies;
initialization

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

34. Interface vs. Implementation
To Understand Nature of USES, we Need to Know What a Used Module Exports Through Its Interface
Client Imports Resources Exported by Its Servers
Modules Implement Exported Resources
Implementation Hidden From Clients
interface is like the tip of the iceberg

35. Designing Module Interfaces
What Goes in the Public Interface of Module X?
Convey to Client Services Provided by X
Too Much Information in Interface Increases Overall System Complexity
Including Internal Implementation Detail May Cause Implementation change to Affect Interface
Not Enough Information
Module X Not Used Correctly or at All
Prototyping Process - Once an interface is defined
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
Initial Prototype that Evolves into Final Product

36. Designing Module Interfaces
How is Evolution Supported? Similar to OO!
Module’s Abstract Interface hides Implementation
Implementation can Change (Array to List) without Impacting Interfaces
Interface can be Extended as Long as Prior Services still Work
Module’s Final Implementation can be Delayed
Key Issue:
Identify Module Features Most Likely to Change
Isolate those Features in Implementation

37. Designing Module Interfaces
Interface Must Insulate Users for All Possible Changes
Policy Changes Must Also be Encapsulated
Suppose List of Mailing Labels
Printing List in Alphabetical Order – Interface
Whether the List is Kept Sorted, Sorted then Printed, etc. – Hidden Implementation
Policies May be Separated From Mechanisms
Mechanism - Ability to Suspend and Resume Tasks in Concurrent System
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

38. Design Notations for Modules
Notations allow Designs to be Described Precisely
At Design Level, English is too Ambiguous to Fully Describe Software Design
Like a Notation that can Facilitate Transition to Implementation (Writing Code)
Still no Acceptable Standard
Notations can be Textual or Graphic
We Illustrate two Sample Notations
TDN (Textual Design Notation)
GDN (Graphical Design Notation)
We Briefly Discuss the Notations Provided by UML

39. TDN
TDN is Loosely Based on Ada – Similarities to Other Languages as Well
Three Parts
Interface Description
What is Exported (Variables, Operations, Types, etc.)
Comments to Describe Protocols, Exported Resource, Other Restrictions (e.g., Time Availability of Service)
Uses
Names of Other Modules that are Used
Implementation
Description
List of Internal Components via Is_Composed_Of

40. An Example in TDN Client Views Export Portions Only
TDN Must Support Consistency and Completeness
R and T must be Defined to Implement X
Y and Z must be Available (Import)

41. An Example in TDN - Continued
Notes:
Exporting of Structure (K) and Type (B) in Module R
Uses Indicates all Dependencies Among Modules

42. Another Example: Compiler
module COMPILER
exports procedure MINI (PROG: in file of char;
CODE: out file of char);
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

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

44. Other Compiler Modules
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

45. GDN Graphical Notations are Easier to Read & Understand
CSE is Dominated by Graphical Notations:
ER, DFDs, Petri Nets, FSM, etc…
UML and its 13 Diagrams (UML 2.0).

46. X's Decomposition

47. Standard Categories of Modules
Functional Modules
Traditional Form Of Modularization
Provide A Procedural Abstraction
Encapsulate An Algorithm
Sorting Module, Fast Fourier Transform Module, …
Libraries
A Group Of Related Procedural Abstractions
Mathematical Libraries
Implemented By Routines Of Programming Languages
Common Pools Of Data
Data Shared By Different Modules
Configuration Constants
The COMMON FORTRAN Construct

48. Abstract Objects Abstract Objects
Objects Manipulated via Interface Functions
Data Structure Hidden From Clients
Maintains a State
Two Identical Calls May Produce Different Results
Library: Two Identical Calls Produce Same Results
Example
Stack of Integers
Interface: Push, Pop operations
Implementation: Array or Linked List
Two Successive Pops on Full Stack May Return Two Different Values

49. Abstract Data Types (ADT)
ADT is Module Describes a Set of Behavior From Which Specific Instances can be Generated
Set of Operations to Manipulate Instances
Encapsulate the Implementation
indicates that details of the
data structure are hidden
to clients

50. ADTs ADTs at Implementation Level: Correspond to Java and C++ Classes
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
:= to Assign an ADT Instance to Variable
= to Compare Two ADT Instances

51. Another ADT Example Model Cars Waiting for Gas (in our Future?)
How is FIFO_CARS Used?
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 (Q1, Q2 : 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

52. Generic Modules
Many Applications Employ the Same Abstraction (Module) in Different Contexts
Stack of Integers, Strings, Employees, etc.
Generic Module
Single Abstract Description that is Paramterizable by Type (Integer, String, CAR, etc.)
Shared Interface and Single Implementation
Once Tested, Provides Stability and Consistency for Usage by Entire Software Team
Reduces the Impact of Changes (From Array to Linked List – all Benefit)
Highly Reusable

53. Generic Modules Note the Parameterization by T Instantiation as:
module INTEGER_STACK_2 is GENERIC_STACK_2 (INTEGER)
Support for Generic Modules:
Templates in C++
Interface Inheritance in Java
generic module GENERIC_STACK_2
. . .
exports
procedure PUSH (VAL : in T);
procedure POP_2 (VAL1, VAL2 : out T); …
end GENERIC_STACK_2

54. Design for Change
In Practice, there Must be Programming Techniques that Allow for Changes without Need to Recompile
Configuration Constants
Factoring Constant Values into Symbolic Constants is a Common Implementation Practice
#define in C
#define MaxSpeed 5600
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

55. Design for Change 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 ...
Software Generation
Compiler Compilers (Lex, Yacc) Automatically Regenerate Code when Change in Specification
GUI Construction Tools Allow Drag and Drop for GUI Components and Generate Code

56. Stepwise Refinement
A Systematic, Iterative Program Design Technique that May Lead to Software that is Hard to Evolve
At Each Step, Problem P Decomposed Into
Sequence of Sub-problems: P1; P2; …Pn
A Selection: If (Cond) Then P1 Else P2
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)

57. Selection Sort Step 1 let n be the length of the array a to be sorted;
while i < n loop
find the smallest of ai .. .an, and exchange
it with the element at position i;
i := i + 1;
end loop;

58. Selection Sort Step 2 let n be the length of the array a to be sorted;
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;

59. Selection Sort Step 3 let n be the length of the array a to be sorted;
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;

60. Decomposition Tree
Stepwise Refinement Process May be Depicted by a Decomposition Tree (DT)
Root Labeled By Name of Top Problem
Subproblem Nodes Labeled as Children of Parent Node Corresponding To Problem
Children From Left To Right Represent Sequential Order Of Execution
If and While Nodes Denoted By Suitable Decoration

61. Example Step 1 P; P problem to solve Step 2
P1; P2; P3; P decomposed into sequence
Step 3
P1;
while C loop
P2,1; P2 decomposed into a loop
end loop;
P3;
Step 4
if C1 then P2,1 decomposed into selection
P2,1,1;
else
P2,1,2;
end if;

62. Corresponding DT

63. Stepwise Refinement
Stepwise Refinement a Programming Technique, Not a Modularization Technique
When Used to Decompose System Into Modules
Tends to Analyze Problems In Isolation, Not Recognizing Commonalities
Does Not Stress Information Hiding
Does Not Consider Generalization Across Subproblems
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

64. Another Example with Various Techniques
Consider a Program Analyzer
First – Stepwise Refinement
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;

65. 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
end if;
if correct then
print message "program correct";
print message "program incorrect";

66. What is the Problem with This Solution?
Step 3 Differentiates Between Lexical and Syntax Analysis
Lexical Analysis First on the Entire Program
If Successful, then Syntax Analysis
Thus – it is a Two Pass Solution
If First Pass Fails, Second Pass Not Checked
Lexical Failure Means no Syntax Check
Suppose we Want to Switch to a Process Driven by Syntax Analysis
Syntax Analyzer Requests a Token from Lexical Analyzer
Parsing and Lexical Analysis in Single Pass
Everything Changes!!!

67. An Alternative Design via Modules
Module CHAR_HOLDER
Hides Physical Representation of Input File
Exports Operation to Access Source File on A Character-by-Character Basis
Module SCANNER
Hides Details of Lexical Structure of the Language
Exports Operation to Provide Next Token
Module PARSER
Hides Data Structure Used To Perform Syntactic Analysis (Abstract Object PARSER)

68. Top-Down vs. Bottom-up Information Hiding Proceeds Bottom-up
Iterated Application of IS_COMPOSED_OF Proceeds Top-Down
Stepwise Refinement is Intrinsically Top-down
Which One Is Best?
In Practice, People Proceed in Both Directions
Yo-yo Design Goes Back and Forth Between Both
Organizing Documentation as a Top-down Flow May Be Useful For Reading Purposes, Even If The Process Followed Was Not Top-down

69. Handling Anomalies
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 …
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)

70. What A Module Can Do Before Failing
Before Failing, Modules May try to Recover From Anomaly by Executing Some Exception Handler (EH)
Local Piece of Code that tries to Recover From Anomaly (If Successful, Module Doesn’t Fail)
Or May Simply Do Cleanup of State and Let the Module Fail, Signaling an Exception to Its Client

71. Case Study – MIDI Compiler
Block Structured Prog. Language that Needs a Symbol Table Module for Block Static Nesting
Version 1 of the Symbol Table

72. Problem with Version 1 Version 1 is Not Robust
Defensive Design should be Applied
Exceptions Must be Raised in Numerous Cases:
INSERT: Insertion Cannot Be Done Because Identifier with Same Name Already Exists in Current Scope
RETRIEVE And LEVEL: Identifier with Specified Name Not Visible
ENTER_SCOPE: Maximum Nesting Depth Exceeded
EXIT_SCOPE: No Matching Block Entry Exists

73. Generic List Management Module

74. Chapter 4 - Summary Jump to OO Design Slides …
Other Upcoming Topics Include:
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?
Software Architectures
Service-Oriented Architectures/Middleware