Looking for a Tutor Near You?

Post Learning Requirement »
x

Choose Country Code

x

Direction

x

Ask a Question

x

x
x
For better view click here
x
Hire a Tutor
DISCOVER

PPT On Software Engineering

Loading...

Published in: Software Engineering
42 Views

Topic about the software engineering.

Depesh S / Ludhiana

1 year of teaching experience

Qualification: UG

Teaches: C / C++, Python Programming, Java Script

Contact this Tutor
  1. Function-Oriented Software Design (continued) Lecture 6 Prof. R. Mall Dept. of CSE, 11 T, Kharagpur
  2. Example 3: Trading-House Automation System (TAS) . A large trading house wants us to develop a software: - To automate book keeping activities associated with its business. . It has many regular customers: Who place orders for various kinds of commodities.
  3. Example 3: Trading-House Automation System (TAS) . The trading house maintains names and addresses of its regular customers. . Each customer is assigned a unique customer identification number (CIN). . As per current practice when a customer places order: - The accounts department first checks the credit-worthiness of the customer.
  4. Example: Trading-House Automation System (TAS) . The credit worthiness of a customer is determined: By analyzing the history of his payments to the bills sent to him in the past. . If a customer is not credit-worthy: - His orders are not processed any further - An appropriate order rejection message is generated for the customer.
  5. Example: Trading-House Automation System (TAS) . If a customer is credit-worthy: - Items he/she has ordered are checked against the list of items the trading house deals with. . The items that the trading house does not deal with: - Are not processed any further - An appropriate message for the customer for these items is generated.
  6. Example: Trading-House Automation System (TAS) . The items in a customer's order that the trading house deals with: Are checked for availability in inventory. . If the items are available in the inventory in desired quantities: A bill with the forwarding address of the customer is printed. - A material issue slip is printed.
  7. Example: Trading-House Automation System (TAS) . The customer can produce the material issue slip at the store house: - Take delivery of the items. - Inventory data adjusted to reflect the sale to the customer.
  8. Example: Trading-House Automation System (TAS) . If an ordered item is not available in the inventory in sufficient quantity: - To be able to fulfill pending orders store details in a "pending-order" file : . out-of-stock items along with quantity ordered. . customer identification number
  9. Example: Trading-House Automation System (TAS) . The purchase department: - would periodically issue commands to generate indents. . When generate indents command is issued: - The system should examine the "pending- orderl file - Determine the orders that are pending - Total quantity required for each of the items.
  10. Example: Trading-House Automation System (TAS) . TAS should find out the addresses of the vendors who supply the required items: - Examine the file containing vendor details (their address, items they supply etc.) -Print out indents to those vendors. 10
  11. Example: Trading-House Automation System (TAS) . TAS should also answers managerial queries: - Statistics of different items sold over any given period of time - Corresponding quantity sold and the price realized. 11
  12. Context Diagram que anager Istics order respo ustomer Trading- House - Automation- System e indent Gene te -inden Purchase- Departmen 12
  13. Level 1 DFD Customer-history Accept- Customer-file order Vendor-list Indent-request Indents order 0.1 Accepted- der andle- indent- request 0.4 Item-file inventory Process- order 0.2 pending-order quer statisti Handle- query 0.3 Sales-statistics ial-issue-slip 13
  14. Example: Data Dictionary response: [bill + material-issue-slip, reject-message] query: period / * query from manager regarding sales statistics*/ period: [date+date,month,year,day] date: year + month + day year: integer month: integer day: integer order: customer-id + {items + quantity)* accepted-order: order / * ordered items available in inventory */ reject-message: order + message / * rejection message * / pending-orders: customer-id + {items+quantity)* customer-address: name+house#+street#+city+pin 14
  15. Example : item-name: string house#: string street#: string city: string pin: integer customer-id: integer Data Dictionary bill: (item + quantity + price)* + total-amount + customer-address material-issue-slip: message + item + quantity + customer-address message: string statistics: {item + quantity + price }* sales-statistics: {statistics)* quantity: integer 15
  16. Observation • From the examples, -Observe that DFDs help create: . Data model . Function model 16
  17. Observation . As a DFD is refined into greater levels of detail: - The analyst performs an implicit functional decomposition. - At the same time, refinements of data takes place. 17
  18. Guidelines For Constructing DFbs . Context diagram should represent the system as a single bubble: - Many beginners commit the mistake of drawing more than one bubble in the context diagram. 18
  19. Guidelines For Constructin DFbs . All external entities s ould be represented in the context diagram: - External entities should not appear at any other level of DFD. . Only 3 to 7 bubbles per diagram should be allowed: - Each bubble should be decomposed to between 3 and 7 bubbles. 19
  20. Guidelines For Constructing DFbs . A common mistake committed by many beginners: - Attempting to represent control information in a DFD. -e.g. tryinq to represent the order in which different functions are executed. 20
  21. Guidelines Fo Constructing bfbs . A DFD does not represent control information: When or in what order different functions (processes) are invoked - The conditions under which different functions are invoked are not represented. - For example, a function might invoke one function or another depending on some condition. - Many beginners try to represent this aspect by drawing an arrow between the corresponding bubbles. 21
  22. Example- 1 . Check the input value: If the input value is less than -1000 or greater than +1000 generate an error message - otherwise search for the number num er Gener essag ate Error numb nu [found,not-foundl Searc 22
  23. Guidelines For Constructing DFDs . If a bubble A invokes either bubble B or bubble C depending on some conditions: - represent the data that flows from bubble A to bubble B and bubbles A to C - not the conditions depending on which a process is invoked. 23
  24. Example-2 . A function accepts the book name to be searched from the user . If the entered book name is not a valid book name - Generates an error message, . If the book name is valid, - Searches the book name in databas . Good-book- Get-book name Print-err message ook-name Search- book Boo -details Error- 24
  25. Guidelines For Constructing DFbs . All functions of the system must be captured in the DFD model: - No function specified in the SRS document should be overlooked. . Only those functions specified in the SRS document should be represented: - Do not assume extra functionality of the system not specified by the SRS document. 25
  26. Commonly Made Errors . Unbalanced DFDs . Forgetting to mention the names of the data flows . Unrepresented functions or data . External entities appearing at higher level DFDs . Trying to represent control aspects . Context diagram having more than one bubble . A bubble decomposed into too many bubbles in the next level . Terminating decomposition too early . Nouns used in naming bubbles 26
  27. Shortcomings of the DFD Model . DFD models suffer from several shortcomings: DFDs leave ample scope to be imprecise. - In a DFD model, we infer about the function performed by a bubble from its label. A label may not capture all the functionality of a bubble. 27
  28. Shortcomings of the DFD Model . For example, a bubble named find-book position has only intuitive meaning: - Does not specify several things: . What happens when some input information is missing or is incorrect. . Does not convey anything regarding what happens when book is not found . or what happens if there are books by different authors with the same book title. 28
  29. Shortcomings of the DFD Model . Control information is not represented: - For instance, order in which inputs are consumed and outputs are produced is not specified. Customer-history Item-file Customer-file order Accept -order Accepte orders inventory Process- order 29
  30. Shortcomings of the DFD Model . A DFD does not specify synchronization aspects: - For instance, the DFD in TAS example does not specify: . Whether process-order may wait until the accept-order produces data . Whether accept-order and handle-order may proceed simultaneously with some buffering mechanism between them. 30
  31. TAS: Level 1 DFD Customer-history Customer-file order Accept -order Accepte ————acders Vendor-list Item-file inventory Process- order andle indent- request query statistic Handle- query Sales- Indent-re ue Indents pending-order 31
  32. Shortcomings of the DFD Model . The way decomposition is carried out to arrive at the successive levels of a DFD is subjective. The ultimate level to which decomposition is carried out is subjective: Depends on the choice and judgement of the analyst. . Even for the same problem, - Several alternative DFD representations are possible: Many times it is not possible to say which DFD representation is superior or preferable. 32
  33. Shortcomings of the DFD Model . DFD technique does not provide: Any clear guidance as to how exactly one should go about decomposing a function: - One has to use subjective judgement to carry out decomposition. . Structured analysis techniques do not specify when to stop a decomposition process: - To what length decomposition needs to be carried out. 33
  34. Extending DFD Technique to Real-Time Systems . For real-time systems (systems having time bounds on their actions), Essential to model control flow and events. Widely accepted technique: Ward and Mellor technique. . A type of process (bubbles) that handles only control flows is introduced. . These processes are represented using dashed circles. 34
  35. Structured Design The aim of structured design - Transform the results of structured analysis (i.e., a DFD representation) into a structure chart. . A structure chart represents the software architecture: - Various modules making up the system, Module dependency (i.e. which module calls which other modules), - Parameters passed among different modules. 35
  36. Structure Chart . Structure chart representation - Easily implementable using programming languages. . Main focus of a structure chart: Define the module structure of a software, - Interaction among different modules, - Procedural aspects (e.g, how a particular functionality is achieved) are not represented. 36
  37. Basic Building Blocks of Structure Chart . Rectangular box: - A rectangular box represents a module. - Annotated with the name of the module it represents. Process-order 37
  38. Arrows . An arrow between two modules implies: During execution control is passed from one module to the other in the direction of the arrow. Process-order root Handle-indent Handle-query 38
  39. Data Flow Arrows . Data flow arrows represent: Data passing from one module to another in the direction of the arrow. root rder Process-order 39
  40. Library Modules . Library modules represent frequently called modules: A rectangle with double side edges. - Simplifies drawing when a module is called by several modules. Quick-sort
  41. Selection . The diamond symbol represents: - One module of several modules connected to the diamond symbol is invoked depending on some condition. Process-order root Handle-indent Handle-query 41
  42. Repetition . A loop around control flow arrows denotes that the concerned modules are invoked repeatedly. Process-order root Handle-indent Handle-query 42
  43. Structure Chart . There is only one module at the top: the root module. . There is at most one control relationship between any two modules: - if module A invokes module B, Module B cannot invoke module A. . The main reason behind this restriction: - consider modules in a structure chart to be arranged in layers or levels. 43
  44. Structure Chart . The principle of abstraction: - does not allow lower-level modules to invoke higher-level modules: - But, two higher-level modules can invoke the same lower-level module.
  45. Example root ms Valid-number Get-good-data —RValid-nu bers Compute-solution a 1 ate- a Get-data ms Display-solution 45
  46. u6!seq PD8
  47. Shortcomings of Structure Chart . By looking at a structure chart: - we can not say whether a module calls another module just once or many times. . Also, by looking at a structure chart: - we can not tell the order in which the different modules are invoked. 47
  48. Flow Chart (Aside) We are all familiar with the flow chart representations: - Flow chart is a convenient technique to represent the flow of control in a system. if(c - 100) p:20 else p: 80 while(p>20) print(student mark) dummv yes no no 48
  49. Flow Chart versus Structure Chart . A structure chart differs from a flow chart in three principal ways: - It is difficult to identify modules of a software from its flow chart representation. Data interchange among the modules is not represented in a flow chart. - Sequential ordering of tasks inherent in a flow chart is suppressed in a structure chart. 49
  50. Transformation of a DFD Model into Structure Chart . Two strategies exist to guide transformation of a DFD into a structure chart: Transform Analysis Transaction Analysis 50
  51. Transform Analysis . The first step in transform analysis: -Divide the DFD into 3 parts: . input, . logical processing, . output. 51
  52. Transform Analysis . Input portion in the DFD: - processes which convert input data from physical to logical form. - e.g. read characters from the terminal and store in internal tables or lists. . Each input portion: - called an afferent branch. - Possible to have more than one afferent branch in a DFD. 52
  53. Transform Analysis . Output portion of a DFD: - transforms output data from logical form to physical form. . e.g., from list or array into output characters. - Each output portion: . called an efferent branch. . The remaining portions of a DFD - called central transform 53
  54. Transform Analysis . Derive structure chart by drawing one functional component for: - the central transform, -each afferent branch, - each efferent branch. 54
  55. Transform Analysis . Identifying the highest level input and output transforms: - requires experience and skill. . Some guidelines: - Trace the inputs until a bubble is found whose output cannot be deduced from the inputs alone. - Processes which validate input are not central transforms. - Processes which sort input or filter data from it are. 55
  56. Transform Analysis . First level of structure chart: - Draw a box for each input and output units - A box for the central transform. . Next, refine the structure chart: - Add subfunctions required by each high-level module. Many levels of modules may required to be added. 56
  57. Factoring . The process of breaking functional components into subcomponents. . Factoring includes adding: - Read and write modules, - Error-handling modules, - Initialization and termination modules, etc. . Finally check: - Whether all bubbles have been mapped to modules. 57
  58. Example 1 : RMS Calculating Software Data- items user Compute- RMS esult Context Diagram 58
  59. Example 1 : RMS Calculating Software . From a cursory analysis of the problem description, - easy to see that the system needs to perform: . accept the input numbers from the user, . validate the numbers, . calculate the root mean square of the input numbers, . display the result. 59
  60. Example atax items 1: RMS Calculating Software • •tiüfribäS" ead- numbers 0.1 Display 0.4 sult ••eFi•or alidate numbers 0.2 . Valid - umbers ompute rms 0.3 60
  61. Example 1 : RMS Calculating Software . By observing the level 1 DFD: - Identify read-number and validate-number bubbles as the afferent branch - Display as the efferent branch. 61
  62. Example 1 : RMS Calculating Software root Valid-number ms bers Get-good-data ompute-solution Display-solution a 1 ae- Get-data data 62
  63. Example 2: Tic-Tac-Toe Computer Game . As soon as either of the human player or the computer wins, - A message congratulating the winner should be displayed. . If neither player manages to get three consecutive marks along a straight line, And all the squares on the board are filled up, Then the game is drawn. . The computer always tries to win a game. 63
  64. Context Diagram for Example display 2 Tic-tac- toe software move Human Player 64
  65. Level 1 DFD move alidate- move Display- I board oar Play- move sult Check- winner 65
  66. Structure Chart root Get-good-move Compute-game a 1 ae- et-move move lay-move Display ec - winner 66
  67. Transaction Analysis . Useful for designing transaction processing programs. - Transform-centered systems: . Characterized by similar processing steps for every data item processed by input, process, and output bubbles. - Transaction-driven systems, . One of several possible paths through the DFD is traversed depending upon the input data value. 67
  68. Transaction Analysis . Transaction: - Any input data value that triggers an action: - For example, selected menu options might trigger different functions. Represented by a tag identifying its type. . Transaction analysis uses this tag to divide the system into: - Several transaction modules - One transaction-center module.
  69. 69 SUD,.u S!SAIDUD Z ad.q SUDJ4 UO!pDSUDJ1 ad'O SUD,.14
  70. Level 1 Customer-history DFD for TAS em- 1 e Customer-file order Vendor-list Indent-request Indents Accept- order Accepted- der andle- indent- request inventory Process- order pending-order query statistics Handle- query Sales-statistics 70
  71. Structure Chart order Handle-order ccep -or e Get-order root query + inden Handle-indent rocess- order Handle-query 71
  72. Summary . We first discussed structured analysis of a larger problem. . We defined some general guidelines - for constructing a satisfactory DFD model. . The DFD model though simple and useful - does have several short comings. . We then started discussing structured design. 72
  73. Summary . Aim of structured design: - Transform a DFD representation into a structure chart. . Structure chart represents: Module structure - Interaction among different modules, - Procedural aspects are not represented. 73
  74. Summary . Structured design provides two strategies to transform a DFD into a structure chart: Transform Analysis - Transaction Analysis 74
  75. Summary . We Discussed three examples of structured design. . It takes a lot of practice to become a good software designer: - Please try to solve all the problems listed in your assignment sheet, Not only the ones you are expected to submit. 75

Need a Tutor or Coaching Class?

Post an enquiry and get instant responses from qualified and experienced tutors.

Post Requirement

Related PPTs

Upload PPTs

If you have your own PowerPoint Presentations which you think can benefit others, please upload on LearnPick. For each approved PPT you will get 100 Credit Points and 100 Activity Score which will increase your profile visibility.

Upload Now
Home > PowerPoint Slides > PPT On Software Engineering