1. 1 Function-Oriented Software Design (lecture 5)

2. 2 Organization of this Lecture zBrief review of last lecture zIntroduction to function-oriented design zStructured Analysis and Structured Design zData flow diagrams (DFDs) yA major objective of this lecture is that you should be able to develop DFD model for any problem. zExamples zSummary

3. 3 Review of last lecture zLast lecture we started ywith an overview of activities carried out during the software design phase. zWe identified different information that must be produced at the end of the design phase: yso that the design can be easily implemented using a programming language.

4. 4 Review of last lecture zWe characterized the features of a good software design by introducing the concepts: ycohesion, coupling, yfan-in, fan-out, yabstraction, etc. zWe classified different types of cohesion and coupling: yenables us to approximately determine the cohesion and coupling existing in a design.

5. 5 Review of last lecture zThere are two fundamentally different approaches to software design: yfunction-oriented approach yobject-oriented approach zWe looked at the essential philosophy of these two approaches: ythe approaches are not competing but complementary approaches.

6. 6 Introduction zFunction-oriented design techniques are very popular: ycurrently in use in many software development organizations. zFunction-oriented design techniques: ystart with the functional requirements specified in the SRS document.

7. 7 Introduction zDuring the design process: yhigh-level functions are successively decomposed: xinto more detailed functions. yfinally the detailed functions are mapped to a module structure.

8. 8 Introduction zSuccessive decomposition of high-level functions: yinto more detailed functions. yTechnically known as top- down decomposition.

9. 9 Introduction zSA/SD methodology: yhas essential features of several important function-oriented design methodologies --- xif you need to use any specific design methodology later on, xyou can do so easily with small additional effort.

10. 10 SA/SD (Structured Analysis/Structured Design) zSA/SD technique draws heavily from the following methodologies: yConstantine and Yourdon's methodology yHatley and Pirbhai's methodology yGane and Sarson's methodology yDeMarco and Yourdon's methodology zSA/SD technique can be used to perform yhigh-level design.

11. 11 Overview of SA/SD Methodology zSA/SD methodology consists of two distinct activities: yStructured Analysis (SA) yStructured Design (SD) zDuring structured analysis: yfunctional decomposition takes place. zDuring structured design: ymodule structure is formalized.

12. 12 Functional decomposition zEach function is analyzed: yhierarchically decomposed into more detailed functions. ysimultaneous decomposition of high-level data xinto more detailed data.

13. 13 Structured analysis zTransforms a textual problem description into a graphic model. ydone using data flow diagrams (DFDs). yDFDs graphically represent the results of structured analysis.

14. 14 Structured design zAll the functions represented in the DFD: ymapped to a module structure. zThe module structure: yalso called as the software architecture:

15. 15 Detailed Design zSoftware architecture: yrefined through detailed design. yDetailed design can be directly implemented: xusing a conventional programming language.

16. 16 Structured Analysis vs. Structured Design zPurpose of structured analysis : ycapture the detailed structure of the system as the user views it. zPurpose of structured design: yarrive at a form that is suitable for implementation in some programming language.

17. 17 Structured Analysis vs. Structured Design zThe results of structured analysis can be easily understood even by ordinary customers: ydoes not require computer knowledge ydirectly represents customer’s perception of the problem yuses customer’s terminology for naming different functions and data. zThe results of structured analysis can be reviewed by customers: yto check whether it captures all their requirements.

18. 18 Structured Analysis zBased on principles of: yTop-down decomposition approach. yDivide and conquer principle: xeach function is considered individually (i.e. isolated from other functions) xdecompose functions totally disregarding what happens in other functions. yGraphical representation of results using xdata flow diagrams (or bubble charts).

19. 19 Data flow diagrams zDFD is an elegant modelling technique: yuseful not only to represent the results of structured analysis yapplicable to other areas also: xe.g. for showing the flow of documents or items in an organization, zDFD technique is very popular because yit is simple to understand and use.

20. 20 Data flow diagram zDFD is a hierarchical graphical model: yshows the different functions (or processes) of the system and ydata interchange among the processes.

21. 21 DFD Concepts zIt is useful to consider each function as a processing station: yeach function consumes some input data and yproduces some output data.

22. 22 Data Flow Model of a Car Assembly Unit Fit Engine Paint and Test Fit Wheels Fit Doors Chassis Store Door Store Wheel Store Engine Store Car Partly Assembled Car Assembled Car Chassis with Engine

23. 23 Data Flow Diagrams (DFDs) zA DFD model: yuses limited types of symbols. ysimple set of rules yeasy to understand: xit is a hierarchical model.

24. 24 Hierarchical model zHuman mind can easily understand any hierarchical model: yin a hierarchical model: xwe start with a very simple and abstract model of a system, xdetails are slowly introduced through the hierarchies.

25. 25 Hierarchical Model

26. 26 How does the human mind work? (Digression) search store

27. 27 How does the human mind work? (Digression) zShort term memory can hold upto 7 items: yIn Software Engineering the number 7 is called as the magic number. zAn item is any set of related information (called a chunk): yan integer ya character ya word ya story ya picture, etc

28. 28 How does the human mind work? (Digression) zTo store 1,9,6,5 requires 4 item spaces: ybut requires only one storage space when I recognize it as my year of birth. zIt is not surprising that large numbers:: yusually broken down into several 3 or 4 digit numbers ye.g. 61-9266-2948

29. 29 Data Flow Diagrams (DFDs) zPrimitive Symbols Used for Constructing DFDs:

30. 30 External Entity Symbol zRepresented by a rectangle zExternal entities are real physical entities: yinput data to the system or yconsume data produced by the system. ySometimes external entities are called terminator, source, or sink. Librarian

31. 31 Function Symbol zA function such as “search-book” is represented using a circle: yThis symbol is called a process or bubble or transform. yBubbles are annotated with corresponding function names. yFunctions represent some activity: xfunction names should be verbs. search- book

32. 32 Data Flow Symbol zA directed arc or line. yrepresents data flow in the direction of the arrow. yData flow symbols are annotated with names of data they carry. book-name

33. 33 Data Store Symbol zRepresents a logical file: yA logical file can be: x a data structure x a physical file on disk. yEach data store is connected to a process: xby means of a data flow symbol. book-details

34. 34 Data Store Symbol zDirection of data flow arrow: yshows whether data is being read from or written into it. zAn arrow into or out of a data store: yimplicitly represents the entire data of the data store yarrows connecting to a data store need not be annotated with any data name. find-book Books

35. 35 Output Symbol zOutput produced by the system

36. 36 Synchronous operation zIf two bubbles are directly connected by a data flow arrow: ythey are synchronous Data- items Read- numbers 0.1 Validate- numbers 0.2 Valid number number

37. 37 Asynchronous operation zIf two bubbles are connected via a data store: ythey are not synchronous. Data- items Read- numbers 0.1 Validate- numbers 0.2 Valid number numbers

38. 38 Yourdon's vs. Gane Sarson Notations zThe notations that we would be following are closer to the Yourdon's notations zYou may sometimes find notations in books that are slightly different yFor example, the data store may look like a box with one end closed

39. 39 How is Structured Analysis Performed? zInitially represent the software at the most abstract level: ycalled the context diagram. ythe entire system is represented as a single bubble, ythis bubble is labelled according to the main function of the system.

40. 40 Tic-tac-toe: Context Diagram Human Player Tic-tac-toe software display move

41. 41 Context Diagram zA context diagram shows: ydata input to the system, youtput data generated by the system, yexternal entities.

42. 42 Context Diagram zContext diagram captures: yvarious entities external to the system and interacting with it. ydata flow occurring between the system and the external entities. zThe context diagram is also called as the level 0 DFD.

43. 43 Context Diagram zContext diagram yestablishes the context of the system, i.e. yrepresents: xData sources xData sinks.

44. 44 Level 1 DFD zExamine the SRS document: yRepresent each high-level function as a bubble. yRepresent data input to every high-level function. yRepresent data output from every high-level function.

45. 45 Higher level DFDs zEach high-level function is separately decomposed into subfunctions: yidentify the subfunctions of the function yidentify the data input to each subfunction yidentify the data output from each subfunction zThese are represented as DFDs.

46. 46 Decomposition zDecomposition of a bubble: yalso called factoring or exploding. zEach bubble is decomposed to y between 3 to 7 bubbles.

47. 47 Decomposition zToo few bubbles make decomposition superfluous: yif a bubble is decomposed to just one or two bubbles: xthen this decomposition is redundant.

48. 48 Decomposition zToo many bubbles: ymore than 7 bubbles at any level of a DFD ymake the DFD model hard to understand.

49. 49 Decompose how long? zDecomposition of a bubble should be carried on until: ya level at which the function of the bubble can be described using a simple algorithm.

50. 50 Example 1: RMS Calculating Software zConsider a software called RMS calculating software: yreads three integers in the range of -1000 and +1000 yfinds out the root mean square (rms) of the three input numbers ydisplays the result.

51. 51 Example 1: RMS Calculating Software zThe context diagram is simple to develop: yThe system accepts 3 integers from the user yreturns the result to him.

52. 52 Example 1: RMS Calculating Software Compute- RMS 0 User Data- items result Context Diagram

53. 53 Example 1: RMS Calculating Software zFrom a cursory analysis of the problem description: ywe can see that the system needs to perform several things.

54. 54 Example 1: RMS Calculating Software zAccept input numbers from the user: yvalidate the numbers, ycalculate the root mean square of the input numbers ydisplay the result.

55. 55 Example 1: RMS Calculating Software Data- items result Read- numbers 0.1 Validate- numbers 0.2 Compute- rms 0.3 Display 0.4 RMS numbers Valid - numbers error

56. 56 Example 1: RMS Calculating Software Calculate- squared-sum 0.3.1 Calculate- mean 0.3.2 Calculate- root 0.3.3 Valid - numbers Squared- sum RMS Mean- square

57. 57 Example: RMS Calculating Software Square 0.3.1.1 Square 0.3.1.2 Square 0.3.1.3 Sum 0.3.1.4 a b c asq bsq csq Squared-sum

58. 58 Example: RMS Calculating Software zDecomposition is never carried on up to basic instruction level: ya bubble is not decomposed any further: xif it can be represented by a simple set of instructions.

59. 59 Data Dictionary zA DFD is always accompanied by a data dictionary. zA data dictionary lists all data items appearing in a DFD: ydefinition of all composite data items in terms of their component data items. yall data names along with the purpose of data items. zFor example, a data dictionary entry may be: ygrossPay = regularPay+overtimePay

60. 60 Importance of Data Dictionary zProvides all engineers in a project with standard terminology for all data: yA consistent vocabulary for data is very important ydifferent engineers tend to use different terms to refer to the same data, xcauses unnecessary confusion.

61. 61 Importance of Data Dictionary zData dictionary provides the definition of different data: yin terms of their component elements. zFor large systems, ythe data dictionary grows rapidly in size and complexity. yTypical projects can have thousands of data dictionary entries. yIt is extremely difficult to maintain such a dictionary manually.

62. 62 Data Dictionary zCASE (Computer Aided Software Engineering) tools come handy: yCASE tools capture the data items appearing in a DFD automatically to generate the data dictionary.

63. 63 Data Dictionary zCASE tools support queries: yabout definition and usage of data items. zFor example, queries may be made to find: ywhich data item affects which processes, ya process affects which data items, ythe definition and usage of specific data items, etc. zQuery handling is facilitated: y if data dictionary is stored in a relational database management system (RDBMS).

64. 64 Data Definition zComposite data are defined in terms of primitive data items using following operators: z +: denotes composition of data items, e.g ya+b represents data a and b. z[,,,]: represents selection, yi.e. any one of the data items listed inside the square bracket can occur. yFor example, [a,b] represents either a occurs or b occurs.

65. 65 Data Definition z( ): contents inside the bracket represent optional data ywhich may or may not appear. ya+(b) represents either a or a+b occurs. z {}: represents iterative data definition, ye.g. {name}5 represents five name data.

66. 66 Data Definition z{name}* represents y zero or more instances of name data. z= represents equivalence, ye.g. a=b+c means that a represents b and c. z * *: Anything appearing within * * is considered as comment.

67. 67 Data dictionary for RMS Software znumbers=valid-numbers=a+b+c za:integer * input number * zb:integer * input number * zc:integer * input number * zasq:integer zbsq:integer zcsq:integer zsquared-sum: integer zResult=[RMS,error] zRMS: integer * root mean square value* zerror:string * error message*

68. 68 Balancing a DFD zData flowing into or out of a bubble: ymust match the data flows at the next level of DFD. yThis is known as balancing a DFD zIn the level 1 of the DFD, ydata item c flows into the bubble P3 and the data item d and e flow out. zIn the next level, bubble P3 is decomposed. yThe decomposition is balanced as data item c flows into the level 2 diagram and d and e flow out.

69. 69 Balancing a DFD a b e d c c d e c1 d1 e1 Level 1 Level 2

70. 70 Numbering of Bubbles: zNumber the bubbles in a DFD: ynumbers help in uniquely identifying any bubble from its bubble number. zThe bubble at context level: yassigned number 0. zBubbles at level 1: ynumbered 0.1, 0.2, 0.3, etc zWhen a bubble numbered x is decomposed, yits children bubble are numbered x.1, x.2, x.3, etc.

71. 71 Example 2: Tic-Tac-Toe Computer Game zA human player and the computer make alternate moves on a 3 3 square. zA move consists of marking a previously unmarked square. zThe user inputs a number between 1 and 9 to mark a square zWhoever is first to place three consecutive marks along a straight line (i.e., along a row, column, or diagonal) on the square wins.

72. 72 Example: Tic-Tac-Toe Computer Game zAs soon as either of the human player or the computer wins, ya message announcing the winner should be displayed. zIf neither player manages to get three consecutive marks along a straight line, yand all the squares on the board are filled up, ythen the game is drawn. zThe computer always tries to win a game.

73. 73 Context Diagram for Example Human Player Tic-tac-toe software 0 display move

74. 74 Level 1 DFD board Display- board 0.1 Check- winner 0.4 Validate- move 0.2 Play- move 0.3 move result game

75. 75 Data dictionary zDisplay=game + result zmove = integer zboard = {integer}9 zgame = {integer}9 zresult=string

76. 76 Summary zWe discussed a sample function- oriented software design methodology: yStructured Analysis/Structured Design (SA/SD) yincorporates features from some important design methodologies. zSA/SD consists of two parts: ystructured analysis ystructured design.

77. 77 Summary zThe goal of structured analysis: yfunctional decomposition of the system. zResults of structured analysis: yrepresented using Data Flow Diagrams (DFDs). zWe examined why any hierarchical model is easy to understand. yNumber 7 is called the magic number.

78. 78 Summary zDuring structured design, ythe DFD representation is transformed to a structure chart representation. zDFDs are very popular: ybecause it is a very simple technique.

79. 79 Summary zA DFD model: ydifficult to implement using a programming language: ystructure chart representation can be easily implemented using a programming language.

80. 80 Summary zWe discussed structured analysis of two small examples: yRMS calculating software ytic-tac-toe computer game software

81. 81 Summary zSeveral CASE tools are available: ysupport structured analysis and design. ymaintain the data dictionary, ycheck whether DFDs are balanced or not.