Chapter 2.1 Program Design and Documentation

Summary System/Program specifications System/Program design –Top-down & Bottom-up design –Object Oriented design Tools for system/program documentation –Decision tables –Control-flow & Nassi-Shneiderman diagrams –Data-flow diagrams –State diagrams –Unified Modeling Language

Summary System/Program specifications System/Program design –Top-down & Bottom-up design –Object Oriented design Tools for system/program documentation –Decision tables –Control-flow & Nassi-Shneiderman diagrams –Data-flow diagrams –State diagrams –Unified Modeling Language

System/Program specifications What should the system/program do ? Formally: –Set of all possible inputs {I} –Set of all possible outputs {O} –Function mapping all elements of {I} into elements of {O} Possible for simple and small programs Unfeasible for large scale systems

The effort of Specifying Interactions with other programs Number of users Only the author Many, NoneMany

System/Program specifications Specifications for large scale systems ? 1Make reasonable set of specifications 2REPEAT 2.1 Build prototype 2.2 Evaluate prototype 2.3 Update specifications UNTIL satisfaction of (potential) users 3Write down final specifications

Summary System/Program specifications System/Program design –Top-down & Bottom-up design –Object Oriented design Tools for system/program documentation –Decision tables –Control-flow & Nassi-Shneiderman diagrams –Data-flow diagrams –State diagrams –Unified Modeling Language

The Cost of Software for large systems During design and coding efforts should be made to reduce the cost of debugging and maintenance

Summary System/Program specifications System/Program design –Top-down & Bottom-up design –Object Oriented design Tools for system/program documentation –Decision tables –Control-flow & Nassi-Shneiderman diagrams –Data-flow diagrams –State diagrams –Unified Modeling Language

Design Methods Top-down design: From global to detail –Decompose the problem in simpler subproblems –Further decompose subproblems –UNTIL all subproblems have trivial solutions Bottom-up design: From detail to global –Solve some small problems that might be useful for solving the big problem –Use the partial solutions for assembling a global solution

Example : Repairing a flat tire Specifications : –Given : A car with a flat tire –Wanted : Instructions for fixing it Strategy choice : –Wait with a smile until somebody fixes it … –Call a repair service >Try to repair yourself

WHAT IS A PROGRAM ? PROGRAM = Description of data + Actions to perform upon these data

Repairing a flat tire “Data” and Actions “Data” –Car, Defective wheel, Spare wheel, Tools. Actions –All that need to be done with the Car, the Defective wheel, the Spare wheel and the Tools in order to solve the problem.

Repairing a flat tire Top level design of actions Inspect the spare wheel If available and in good condition, –Then, repair yourself –Else, you will need to call help

Repairing a flat tire Refinement of “repair yourself” Fetch the tools Fetch the spare wheel Exchange defective and spare wheels Store defective wheel Store tools

Repairing a flat tire Refinement of “tools” Tools : –Jack : device to lift a car –Wrench : device to loose or fasten bolts

Repairing a flat tire Refinement of “Exchange defective and spare wheels” REPEAT loose one bolt with wrench UNTIL all bolts loose; Lift car with Jack; REPEAT remove one bolt UNTIL all bolts removed; Remove defective wheel; Put spare wheel in place; REPEAT replace one bolt UNTIL all bolts in place; Lower car with Jack; REPEAT fasten one bolt with wrench UNTIL all bolts fastened;

Summary System/Program specifications System/Program design –Top-down & Bottom-up design –Object Oriented design Tools for system/program documentation –Decision tables –Control-flow & Nassi-Shneiderman diagrams –Data-flow diagrams –State diagrams –Unified Modeling Language

Object oriented Design Problem : –If a data item is slightly changed, the entire program needs to be checked. Solution : –Group data with description of all actions that can be performed upon such data –Access data exclusively through the actions predefined for these data Object = data + actions to access it.

Repairing a flat tire Object-oriented style Instance of the object : MyJack Possible actions : Fetch Inspect Store Lift a car Lower a car Object Jack =

Summary System/Program specifications System/Program design –Top-down & Bottom-up design –Object Oriented design Tools for system/program documentation –Decision tables –Control-flow & Nassi-Shneiderman diagrams –Data-flow diagrams –State diagrams –Unified Modeling Language

Repairing a flat tire Decision Table Spare Wheel Tools Available & OK No good tools available OKNot OK Repair yourself Get Help Try to borrow tools

Summary System/Program specifications System/Program design –Top-down & Bottom-up design –Object Oriented design Tools for system/program documentation –Decision tables –Control-flow & Nassi-Shneiderman diagrams –Data-flow diagrams –State diagrams –Unified Modeling Language

Repairing a flat tire Top-level Controlflowchart Spare Wheel OK ? Get Help Repair yourself No Yes

Repairing a flat tire Refinement of “repair yourself” Spare Wheel OK ? Get Help Repair yourself NoYes Get Tools Get Spare Wheel Change Wheel Store Bad Wheel Store Tools

Repairing a flat tire Refinement of “Get Tools” Tools present & OK ? Tools present & OK ? Pick up the Tools Try borrowing Tools NoYes Got Tools or Tired ? Yes No Help Needed !!!

Repairing a flat tire Adapted refinement of “Get Tools” Tools present & OK ? Pick up the Tools Try borrowing Tools NoYes Got Tools or Tired ? Yes No

Repairing a flat tire Improved top-level design Spare Wheel OK ? NoYes Tools OK ? Fetch Tools Yes No Get Help Repair yourself

Selection Statement No selector = a ? Tasks to be done if selector = A Yes No selector = b ? Tasks to be done if selector = B Yes No selector = c ? Tasks to be done if selector = C Yes Tasks to be done if no criteria OK

Selection Statement selector Tasks to be done if selector = A selector = a Tasks to be done if no criteria OK selector # a selector # b selector # c Tasks to be done if selector = B Tasks to be done if selector = C selector = bselector = c selector

Iteration Statement Termination Test Initialization Loopbody, part 1 Loopbody, part 2 Continue Finish

Iteration Statement Initialisation Loopbody Part 1 Loopbody Part 2 Termination Condition

Repairing a flat tire Spare Wheel ? Not OK OK Get Help Fetch Tools Tools ? Get Help Repair Yourself Not OK OK Tools present & OK ? YesNo Get your own tools Try to borrow tools Until You got tools OR you are tired Get spare wheel Change wheel Store bad wheel Return tools

Summary System/Program specifications System/Program design –Top-down & Bottom-up design –Object Oriented design Tools for system/program documentation –Decision tables –Control-flow & Nassi-Shneiderman diagrams –Data-flow diagrams –State diagrams –Unified Modeling Language

Data-flow Diagrams Bad Wheel Tools Spare Wheel FETCHED STORED MOUNTED STORED REMOVED

Summary System/Program specifications System/Program design –Top-down & Bottom-up design –Object Oriented design Tools for system/program documentation –Decision tables –Control-flow & Nassi-Shneiderman diagrams –Data-flow diagrams –State diagrams –Unified Modeling Language

State Diagrams Flat tire problem Driving Flat tire Need help Good spare wheel Repairing Try borrow tools Puncture No good Spare wheel Successful help No success Spare wheel OK Done No tools Tools OK Success

State Diagrams Electronic lock First digit entered Waiting 1st digit Testing key Waiting 2nd digit Waiting 3rd digit Second digit entered Third digit entered Wrong Key Opening door Good Key Spontaneous transition

Summary System/Program specifications System/Program design –Top-down & Bottom-up design –Object Oriented design Tools for system/program documentation –Decision tables –Control-flow & Nassi-Shneiderman diagrams –Data-flow diagrams –State diagrams –Unified Modeling Language

Unified Modeling Language Tool for supporting / documenting object oriented designs Applicable to the –Organizational level –System level –Program level Set of different diagrams, including –Class diagrams (= objects and their static relations) –Interaction diagrams –Activity diagrams (= extended control flow diagrams) –State diagrams –Deployment diagrams