Functional and Behavioural Modeling

1. Functional and Behavioural Modeling “What is the software supposed to do?” TCS2411 Software Engineering

2. Lecture Objectives • To illustrate the modeling of functional and behavioural characteristics of the problem domain • To describe the elements of data flow diagrams and the associated rules for drawing them correctly • To describe the elements and usage of state transition diagrams TCS2411 Software Engineering

3. Functional Modeling • In understanding the requirements of the software, the functions required by the customer will be identified • All the functions process information in some way in the system • Basically input  process  output • Representation of how information is transformed TCS2411 Software Engineering

4. Data Flow Diagram (DFD) • Graphical representation of functional modeling • In analysis, provide representation of information flow in existing and required system • In design, the DFDs can be decomposed into lower level processes (sub-systems) for implementation TCS2411 Software Engineering

5. Context Diagram Customer Kitchen Customer Order Food Ordering System Receipt Food Order Management Reports Restaurant Manager TCS2411 Software Engineering

6. Level-1 DFD Customer Kitchen Customer Order 1. Process Customer Order Food Order Receipt Inventory Data Goods Sold 2. Update Goods Sold 3. Update Inventory Inventory Record Goods Sold Record 4. Produce Management Reports Inventory Daily Inventory Depletion Amounts Goods Sold Daily Goods Sold Amounts Management Reports Restaurant Manager TCS2411 Software Engineering

7. External Entity • A producer or consumer of information that resides outside the bounds of the system to be modeled • Source - producer of information • Sink - consumer of information • Examples: Customer Supplier Management TCS2411 Software Engineering

8. Process • A transformer of information (a function) that resides within the bounds of the system to be modeled • Examples: 1.Process New Member 2. Student Registration 2.1 Accept Registration Details TCS2411 Software Engineering

9. Data Flow • Data object that flows in the system; the arrowhead indicates the direction of data flow new student record student record TCS2411 Software Engineering

10. Data Store • A repository of data that is to be stored for use by one or more processes • May be as simple as a buffer or queue or as sophisticated as a relational database • Examples: Students Inventory Courses TCS2411 Software Engineering

11. DFD Rules • Process • No process can have only outputs. • No process can have only inputs. • A process has a verb label. TCS2411 Software Engineering

12. DFD Rules • Data Store • Data cannot move directly from one data store to another data store. • Data cannot move directly from an outside source to a data store. • Data cannot move directly to an outside sink from a data store. • A data store has a noun phrase label. TCS2411 Software Engineering

13. DFD Rules • Source/Sink • Data cannot move directly from a source to a sink. It must be moved by a process if the data are of any concern to our system. • A source/sink has a noun phrase label. TCS2411 Software Engineering

14. DFD Rules • Data Flow • A data flow has only one direction of flow between symbols. • A fork in data flow means that exactly the same data goes from a common location to two or more processes/stores/sources/sinks. • A join in a data flow means that exactly the same data comes from any two or more processes/stores/sources/sinks. TCS2411 Software Engineering

15. DFD Rules • Data Flow (continued) • A data flow cannot go directly back to the same process it leaves. • A data flow to a data store means update. • A data flow from a data store means retrieve or use. • A data flow has a noun phrase label. More than one data flow noun phrase can appear on a single arrow. TCS2411 Software Engineering

16. DFD Characteristics • Can be used to model physical or logical, current or new systems • Does not represent procedural or time-related processes • Revisions to the same DFD are done to improve model based on understanding • Decision to stop iterative decomposition may be difficult TCS2411 Software Engineering

17. events behavior Outside world Application Behavioural Modeling TCS2411 Software Engineering

18. Behavioural Modeling • Representation of how the system changes and the events that cause the changes to happen • Also represent actions that may be taken as consequences of events • Graphically drawn as state transition diagram TCS2411 Software Engineering

19. State Transition Diagram (STD) Notation State Event causing transition Action that occurs New state TCS2411 Software Engineering

20. State Transition Diagram (STD) Idle announce complete hangup incoming call button pressed initiate answer Connected Ringing answered announce message TCS2411 Software Engineering

21. State Transition Diagram Elements • State - any observable mode of behaviour • represented as a node in STD • State transition - change of one state to another caused by an event • represented as labeled arrow in STD • label is the event causing the transition • Event - external or internal occurrence that has an effect on the system • Action - process taken as response to event TCS2411 Software Engineering

22. References • “Software Engineering: A Practitioner’s Approach” 5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001 • “Software Engineering” by Ian Sommerville, Addison-Wesley, 2001 • “Modern Systems Analysis and Design” by Jeffrey A. Hoffer, Joey F. George & Joseph S. Valacich, Benjamin/Cummings, 1996 TCS2411 Software Engineering