CHAPTER 19: Building a Preliminary Behavioral Model

Size: px
Start display at page:

Download "CHAPTER 19: Building a Preliminary Behavioral Model"

Transcription

1 1 z 7 CHAPTER 19: Building a Preliminary Behavioral Model Things are always at their best in their beginning. Blaise Pascal Lettres Provinciales, , no. 4 IN THIS CHAPTER, YOU WILL LEARN: Why a pure top-down approach to the behavior model is difficult; How to develop a preliminary behavior model using event partitioning; and How to develop the initial ERD model. In the previous chapter, we saw how to develop the environmental model for a system. If you were working on a real project at this point, you would have finished the context diagram, the event list, and a statement of purpose. In addition, you should have begun constructing the data dictionary, with at least a definition of the data elements that represent interfaces between the external terminators and the system. Our task now is to begin building the behavioral model, that is, the model of what the internal behavior of the system must be in order to deal successfully with the environment. This will involve the development of a preliminary dataflow diagram and entity-relationship diagram, as well as an elaboration of the initial data dictionary entries. Basically, this approach involves drawing a first-cut dataflow diagram, with one process (bubble) for the system response to each event that we have identified in our event list. We then draw stores on our first-cut DFD to model the data that must be remembered between asynchronous events. Finally, we connect appropriate input flows and output flows to the bubbles and check our set of DFDs against the context diagram for consistency. Once having done this, we will go through a clean-up process, described in Chapter 20, to produce a well-organized process model and data model for presentation to the end user. This approach was given the name event partitioning in [McMenamin and Palmer, 1984]. We begin by comparing this approach to the classical top-down approach THE CLASSICAL APPROACH The approach suggested in this chapter is substantially different from the top-down approach described in such classical textbooks as DeMarco [DeMarco, 1979], Gane [Gane and Sarson, 1979], and others. The classical approach assumes that you have already drawn your context diagram; but it assumes that you will proceed directly from the single bubble in the context diagram to a high-level DFD (known as Figure 0), in which each of the bubbles represents a major subsystem. Each bubble in Figure 0 is then partitioned into lower-level figures, and each bubble in the lower-level figures is partitioned further, and so on, until you have reached the level of an atomic bubble that requires no further decomposition. This is illustrated by Figure 19.

2 2 z 7 Figure 19.1: The top-down development of the behavioral model Though this top-down approach is different than the one presented in this book, I am not opposed to its approach... if it works. However, you should be aware that many systems analysts encounter the following problems when attempting to follow a top-down approach: Analysis paralysis. In many large, complex systems, there simply isn t a clue to guide the systems analyst in drawing an appropriate Figure 0 from the context diagram. So the analyst sits at her desk, staring at the context diagram, waiting for divine inspiration, or for someone to tell her that the project has run out of time for systems analysis and that it s time to begin coding. The six-analyst phenomenon. On a large, complex system, there is often more than one systems analyst staring at the context diagram. In order to divide up the work equally and not get in each other s way, they arbitrarily create a Figure 0 with one bubble for each systems analyst. Thus, if there are six systems analysts, Figure 0 will consist of six bubbles. Needless to say, this may not be the optimal partitioning of the system. What happens, for example, if the same system is specified by three systems analysts? Nine analysts? One analyst? An arbitrary physical partitioning. In many cases, a new system is based on an existing system, or it represents the computerization of an existing organization. The top-level partitioning of the current system (e.g., the current organizational units or the existing computer systems) is often used as the rationale for developing the partitioning of the new system. Thus, if the existing system is represented by a Purchasing Department and a Quality Assurance Department, the new system will often have a Purchasing Subsystem and a Quality Assurance Subsystem even though those might not be (and often are not) the best partitioning (from a functional point of view) of the system. The approach described in this chapter is not a pure top-down approach; neither is it a pure bottom-up approach. It is, in a sense, a middle-out approach; after the initial DFD is developed, some upward leveling is required, and some further downward partitioning may be necessary IDENTIFYING EVENT RESPONSES The event partitioning approach involves the following four steps: 4. A bubble, or process, is drawn for each event in the event list. The bubble is named by describing the response that the system should make to the associated event. Appropriate inputs and outputs are drawn so that the bubble will be able to make its required response, and stores are drawn, as appropriate, for communication between bubbles. The resulting first-cut DFD is checked against the context diagram and event list for completeness and consistency. The first step is straightforward, indeed almost mechanical in nature. If there are 25 events in the event list, you should draw 25 bubbles. For convenient reference, you should number the bubble to match the associated event. Thus, event 13 corresponds to bubble 1 (Later, as we will see in Chapter 20, we will renumber the bubbles appropriately.) The second step is also straightforward and mechanical: each bubble is given an appropriate name based on its required response. This means that you should examine the event and ask yourself, What response is the system supposed to make to this event? Remember, though, that you should choose names that are as specific as possible. Thus, if an event is CUSTOMER MAKES PAYMENT, an appropriate bubble name might be UPDATE ACCOUNTS RECEIVABLE (if that is the only required response from the system), rather than PROCESS CUSTOMER PAYMENT (which tells us nothing about the nature of the response). The third step is definitely not mechanical, but it is usually fairly straightforward. For each bubble that you have drawn, you must identify the inputs that the bubble requires to do its work; you must identify the outputs (if any) that the bubble produces; and you must identify the stores that the bubble must access. This is normally done by interviewing the appropriate user(s) and concentrating on each event and its associated bubble. What does this bubble need to do its job? you will ask the user, and What outputs does it generate? In many cases, the event is flow-driven; this means that the system becomes aware of the occurrence of the event because of the arrival of some data from an external terminator. Obviously, this means that the appropriate dataflow must be attached to the process required to respond to that event. But, as shown in Figures 19.2(a) and (b), additional inputs (from other terminators and possibly from data stores) may be required in order for the process to be able to produce its required output. Similarly, you must draw in the appropriate outputs produced by the process as part of the response. In many cases, this will involve outputs being sent back to the terminators outside the system; however, it may involve outputs that are sent to data stores, to be used as

3 3 z 7 inputs by other processes. This is illustrated by Figures 19.3(a) and (b). Finally, the fourth step is a consistency-checking activity similar to the balancing steps described in Chapter 14. You must verify that every input shown on the context diagram is associated with an input on one of the processes in the preliminary DFD; and you must verify that every output produced by a process in the preliminary DFD is either sent to a store or is an external output shown on the context diagram. There are two special cases: (1) single events that cause multiple responses and (2) multiple events that cause the same response. In the first case, a single event may cause multiple responses, each of which is modeled with its own bubble in the preliminary DFD. This is illustrated in Figure This is appropriate only if all the responses use the same incoming dataflow, and only if all the responses are independent of one another. No output from one part of the overall response should be needed as input by another part of the overall response. Figure 19.2(a): A dataflow signaling the occurrence of an event Figure 19.2(b): Additional inputs required to produce the response Figure 19.3(a): An output sent from a process to a terminator

4 4 z 7 Figure 19.3(b): An output being sent from a process to a store Conversely, there will be occasional situations where one process is associated with more than one event; this is illustrated by Figure This is valid and appropriate only if the response made by the bubble is identical for the various events, and only if the input data and output data are identical for the various event responses. Figure 19.4 : Multiple responses from the same event Figure 19.5: Multiple events with the same response 19.3 CONNECTING EVENT RESPONSES Note that in the previous examples, none of the processes in the preliminary dataflow diagram are connected to each other: bubbles do not talk directly to other bubbles. Instead bubbles communicate with each other through data stores. Why is this? Simply because the bubbles in the preliminary DFD represent responses to an event, and events that occur in the external environment are, in the general case, asynchronous. That is, we have no way of guaranteeing that two events will occur at the same instant, or within two seconds of one another, or within any other specified period of time. Events happen in the external environment whenever the environment feels like making them happen. And since: the response to one event may require data produced by some other event, and we have no way of knowing when the events will occur in time, and

5 5 z 7 we have to assume, in an essential model, that each process will perform its work infinitely quickly, and each dataflow acts as a pipeline that can transmit data elements at infinite speed. it follows that the only way we can synchronize multiple interdependent events is through a store. Note that this is an essential store: a store required, not because of time delays associated with imperfect technology, but because of timing considerations in the environment. Thus, you should not see a preliminary dataflow diagram like the one shown in Figure 19.6(a); since the associated events are asynchronous, Figure 19.6(a) could only work if a time-delayed storage of data was hidden within one of the processes or the dataflow itself. Thus, Figure 19.6(b) is the proper way of showing the communication between processes DEVELOPING THE INITIAL DATA MODEL As we have seen, the procedure of sketching the initial DFD involves drawing data stores between asynchronous processes. In most cases, the nature of these stores will be obvious, and the names can be chosen from your understanding of the subject matter of the project. Meanwhile, however, you or one of your colleagues should have begun working on the initial version of the entity-relationship diagram as an independent activity, in parallel with the development of the initial DFD. This should be done using the techniques described in Chapter 1 As the ERD and DFD are being developed in parallel, they can be used to cross-check each other. Thus, stores that have been tentatively defined in the preliminary DFD can be used to suggest objects in the preliminary ERD; and objects that have been tentatively identified in the preliminary ERD can be used to help choose appropriate stores in the preliminary DFD. Neither model should be considered the dominant model that controls the other; each is on an equal footing and can provide invaluable assistance to the other. Figure 19.6(a): Improper model of time-delayed communication between processes Figure 19.6(b): Proper model of time-delayed communication between processes You may also find that the event list is as useful for creating the initial ERD as it is for creating the initial DFD. Nouns in the event list will often turn out to be objects in the ERD; for example, if an event is Customer places order, we would immediately identify customer and order as tentative objects. Similarly, we can use the event list as a means of cross-checking the initial ERD: all the object types in the ERD should correspond to nouns in the event list SUMMARY The most important thing to realize from this chapter is that you will not produce a behavioral model that is ready to be shown to the user. It is not finished; it is not pretty; it is not simple enough or well-organized enough to be understood in its entirety. You can see an example of this by looking at the case study in Appendix F. So what is it? What is the point of carrying out the steps described in Section 19.3? Very simply, it is a beginning, a framework upon which you can base the development of the finished, final version of the essential model. You should not be concerned at this point about the organization of the behavioral model, or its complexity, or its understandability. You

6 6 z 7 should resolutely resist the temptation to reorganize, package, decompose, or recompose any of the bubbles in the preliminary DFD. All you should care about at this point is the underlying correctness of the model: Does it have a process for each event? Does it show the necessary inputs and outputs for each event? And does it show the necessary connections between events? Once you have established this, then you can begin working on a reorganization of the model. This is discussed in more detail in Chapter 20. REFERENCES Tom DeMarco, Structured Analysis and Systems Specification. Englewood Cliffs, N.J.: Prentice-Hall, Chris Gane and Trish Sarson, Structured Systems Analysis: Tools and Techniques. Englewood Cliffs, N.J.: Prentice-Hall, Steve McMenamin and John Palmer, Essential Systems Analysis. New York: YOURDON Press, QUESTIONS AND EXERCISES What is a behavioral model of a system? What is its purpose? What are the three major components of the preliminary behavioral model? What is the classical approach to building a behavioral model? Why is it characterized as a top-down approach? What are the three major problems typically faced by systems analysts when trying to follow the classical top-down approach to building a behavioral model of an information system? Why do you think that some systems analysts suffer paralysis, or writer s block, when trying to develop a Figure 0 DFD from the context diagram? Why does the behavioral model in some projects exhibit an arbitrary physical partitioning? What does the term event partitioning mean? What are the four steps in event partitioning? If the systems analyst has discovered 13 events in the environmental model, how many processes (bubbles) should be in the first-cut behavioral model? What kind of numbering scheme is used to number the bubbles in the first-cut DFD of the behavioral model? What rationale is used to give a name to each bubble in the first-cut DFD of the behavioral model? How should the systems analyst determine the inputs, outputs, and stores required by each bubble in the first-cut DFD? If an event is flow-driven, how many input dataflows must the bubble processing that event receive? What are the consistency-checking guidelines that the systems analyst must go through when drawing the first-cut DFD of the behavioral model? How should the first-cut DFD be drawn for the case of an event that produces multiple responses? Under what conditions could a single bubble in the first-cut DFD be associated with more than one event? In the first-cut DFD, how do bubbles communicate with one another? That is, how does an output produced by one bubble become input to another bubble? How does the first-cut DFD show the synchronization of multiple, asynchronous, interdependent events? Which should be developed first: the first-cut DFD or a first-cut data model (ERD)? Why? What should the systems analyst do with the first-cut DFD and first-cut ERD after he or she has finished them? When the first-cut DFD has been finished, should it be reviewed with the user? Why or why not? What is wrong with the following first-cut DFD? 2 What s wrong with the following first-cut DFD?

7 7 z Ed Yourdon

Fundamentals of Health Workflow Process Analysis and Redesign

Fundamentals of Health Workflow Process Analysis and Redesign Fundamentals of Health Workflow Process Analysis and Redesign Unit 10.3d Process Mapping Gane-Sarson Notation Slide 1 Welcome to the Gane-Sarson Notation for Data Flow Diagrams Subunit. This is the third

More information

System Analysis & design

System Analysis & design Assiut University Faculty of Computers and Information System Analysis & design Year 2 Academic Year 2014/ 2015 Term (2) 5 A PICTURE IS WORTH A 1,000 WORDS A process model is a graphical way of representing

More information

Slide 1 Welcome to Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: Gane-Sarson Notation. This is Lecture d.

Slide 1 Welcome to Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: Gane-Sarson Notation. This is Lecture d. WORKFLOW ANALYSIS Audio Transcript Component 10 Unit 3 Lecture D Fundamentals of Health Workflow Process Analysis & Redesign Interpreting and Creating Process Diagrams Process Mapping Gane-Sarson Notation

More information

Data Process Modeling: Context Diagrams & Data Flow Diagrams (DFDs)

Data Process Modeling: Context Diagrams & Data Flow Diagrams (DFDs) Introduction Data Process Modeling: Context Diagrams & Data Flow Diagrams (DFDs) MIS 374 When designing/building an information system for an organization, you should consider the following questions regarding

More information

Structured Analysis and Design

Structured Analysis and Design 1 st Cut - Creating... 14:10 A Actors... 2:11 Additional Notations... 11:17 Alternative Names for the System... 13:15 Analysis - Overview... 1:9 Analysis and Design - Goals... 1:6 Analysis and Design -

More information

Data and Process Modeling

Data and Process Modeling Chapter 5 Data and Process Modeling 5 CHAPTER Data and Process Modeling Chapter 5 is the second of four chapters in the systems analysis phase of the SDLC. This chapter discusses data and process modeling

More information

Fundamentals of Health Workflow Process Analysis and Redesign

Fundamentals of Health Workflow Process Analysis and Redesign Fundamentals of Health Workflow Process Analysis and Redesign Process Mapping: Yourdon Notation for Data Flow Diagrams This material Comp10_Unit3c was developed by Duke University, funded by the Department

More information

Module 5. Function-Oriented Software Design. Version 2 CSE IIT, Kharagpur

Module 5. Function-Oriented Software Design. Version 2 CSE IIT, Kharagpur Module 5 Function-Oriented Software Design Lesson 12 Structured Design Specific Instructional Objectives At the end of this lesson the student will be able to: Identify the aim of structured design. Explain

More information

Software Engineering Prof.N.L.Sarda IIT Bombay. Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II)

Software Engineering Prof.N.L.Sarda IIT Bombay. Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II) Software Engineering Prof.N.L.Sarda IIT Bombay Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II) We will continue our discussion on process modeling. In the previous lecture

More information

Supporting Systems Engineering with Methods and Tools: A Case Study

Supporting Systems Engineering with Methods and Tools: A Case Study Supporting Systems Engineering with Methods and Tools: A Case Study Jock Rader and Leslie Haggerty Hughes Aircraft Company and H&A System Engineering Abstract Many projects have applied the Hatley-Pirbhai

More information

Structured Modeling Methods. Lecture 15: Advantages and Disadvantages. University of Toronto Department of Computer Science.

Structured Modeling Methods. Lecture 15: Advantages and Disadvantages. University of Toronto Department of Computer Science. Lecture 15: Structured Modeling Methods Basics of Structured Analysis Notations used Modeling Process Variants SADT SASS SSADM SRD Advantages and Disadvantages 2001, Steve Easterbrook CSC444 Lec15 1 Definition

More information

Lecture c, Process Mapping: Yourdon Notation for Data Flow Diagrams, covers Yourdon notation for data flow diagrams.

Lecture c, Process Mapping: Yourdon Notation for Data Flow Diagrams, covers Yourdon notation for data flow diagrams. WORKFLOW ANALYSIS Audio Transcript Component 10 Unit 3 Lecture C Fundamentals of Health Workflow Process Analysis & Redesign Interpreting and Creating Process Diagrams Process Mapping Yourdon Notation

More information

Kuratowski Notes , Fall 2005, Prof. Peter Shor Revised Fall 2007

Kuratowski Notes , Fall 2005, Prof. Peter Shor Revised Fall 2007 Kuratowski Notes 8.30, Fall 005, Prof. Peter Shor Revised Fall 007 Unfortunately, the OCW notes on Kuratowski s theorem seem to have several things substantially wrong with the proof, and the notes from

More information

Fundamentals of Health Workflow Process Analysis and Redesign

Fundamentals of Health Workflow Process Analysis and Redesign Fundamentals of Health Workflow Process Analysis and Redesign This material Comp0_Unit3d was developed by Duke University, funded by the Department of Health and Human Services, Office of the National

More information

STRUCTURED ANALYSIS AND SYSTEM SPECIFICATION

STRUCTURED ANALYSIS AND SYSTEM SPECIFICATION r STRUCTURED ANALYSIS AND SYSTEM SPECIFICATION by Tom DeMarco Foreword by P.J. Plauger =3p YOURDDN PRESS =fm P T R PRENTICE HALL Englewood Cliffs, NJ 07632 PAGE PARTI: BASIC CONCEPTS 1. The Meaning of

More information

Functional Modeling with Data Flow Diagrams

Functional Modeling with Data Flow Diagrams Functional Modeling with Data Flow Diagrams Amasi Elbakush 5771668 Teaching Assistant : Daniel Alami Utrecht University 1 Introduction Data Flow Diagrams (DFDs) are a visual representation of the flow

More information

Process Modeling. Wei-Tsong Wang 1 IIM, NCKU

Process Modeling. Wei-Tsong Wang 1 IIM, NCKU Process Modeling Based on Chapter 9 of Whitten, Bentley, and Dittman: Systems Analysis and Design for the Global Enterprise (7th Ed). McGraw Hill. 2007 Wei-Tsong Wang 1 IIM, NCKU 2 Models: Logical and

More information

Programming and Data Structure

Programming and Data Structure Programming and Data Structure Dr. P.P.Chakraborty Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture # 09 Problem Decomposition by Recursion - II We will

More information

Chapter 6 Structuring System Requirements: Process Modeling 6.1

Chapter 6 Structuring System Requirements: Process Modeling 6.1 Chapter 6 Structuring System Requirements: Process Modeling 6.1 Learning Objectives Explain process modeling Discuss data-flow diagramming mechanics, definitions, and rules Discuss balancing data-flow

More information

SE Assignment III. 1. List and explain primitive symbols used for constructing DFDs. Illustrate the use of these symbols with the help of an example.

SE Assignment III. 1. List and explain primitive symbols used for constructing DFDs. Illustrate the use of these symbols with the help of an example. SE Assignment III 1. List and explain primitive symbols used for constructing DFDs. Illustrate the use of these symbols with the help of an example. There are essentially 5 different types of symbols used

More information

System Analysis & design

System Analysis & design Assiut University Faculty of Computers and Information System Analysis & design Year 2 Academic Year 2014/ 2015 Term (2) Copyright 2014 Dr. Hossam Ragab 6 data model describes the data that flow through

More information

Software Design Report

Software Design Report Software design is a process by which the software requirements are translated into a representation of software components, interfaces, and data necessary for the implementation phase. The SDD shows how

More information

CHAPTER 4 Data and Process Modeling (Phase 2: Systems Analysis)

CHAPTER 4 Data and Process Modeling (Phase 2: Systems Analysis) CHAPTER 4 Data and Process Modeling (Phase 2: Systems Analysis) Jakrapop Maisen DATA FLOW DIAGRAMS A data flow diagram (DFD) shows how data moves through an information system but does not show program

More information

Chapter : Analysis Modeling

Chapter : Analysis Modeling Chapter : Analysis Modeling Requirements Analysis Requirements analysis Specifies software s operational characteristics Indicates software's interface with other system elements Establishes constraints

More information

(Refer Slide Time 04:53)

(Refer Slide Time 04:53) Programming and Data Structure Dr.P.P.Chakraborty Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture 26 Algorithm Design -1 Having made a preliminary study

More information

SYSTEMS DESIGN THROUGH THE USER INTERFACE. Jim Underwood School of Computing Sciences University of Technology, Sydney

SYSTEMS DESIGN THROUGH THE USER INTERFACE. Jim Underwood School of Computing Sciences University of Technology, Sydney Jim Underwood School of Computing Sciences University of Technology, Sydney First Annual Conference on Information Systems Monash University, Melbourne, Australia, 6th February 1990 ABSTRACT This paper

More information

Modelling as a Communication Tool: Introduction to Process Modelling. Modelling. Simplification in modelling. Representation in modelling

Modelling as a Communication Tool: Introduction to Process Modelling. Modelling. Simplification in modelling. Representation in modelling CSE104 - Information Systems 1 Modelling as a Communication Tool: Introduction to Process Modelling The requirements specification document Must be communicated to key stakeholders Should contain: Functions

More information

SEEKING THE ACTUAL REASONS FOR THE "NEW PARADIGM" IN THE AREA OF IS ANALYSIS 2. GENERAL CHARACTERISTICS OF THE "STRUCTURED APPROACH" IN IS DEVELOPMENT

SEEKING THE ACTUAL REASONS FOR THE NEW PARADIGM IN THE AREA OF IS ANALYSIS 2. GENERAL CHARACTERISTICS OF THE STRUCTURED APPROACH IN IS DEVELOPMENT SEEKING THE ACTUAL REASONS FOR THE "NEW PARADIGM" IN THE AREA OF IS ANALYSIS Václav Řepa Prague University of Economics, W.Churchill sq. 4, 130 00 Praha 3, Czech Republic E-mail: REPA@VSE.CZ 1. INTRODUCTION

More information

Data Flow Diagrams System Analysis ( (

Data Flow Diagrams System Analysis ( ( 7 Data Flow Diagrams System Analysis (1932475( Kendall & Kendall 7-1 Data Flow Diagrams A top down approach to diagramming data movement, it moves from general to specific. Graphically characterize data

More information

SOFTWARE ENGINEERING Prof.N.L.Sarda Computer Science & Engineering IIT Bombay. Lecture #10 Process Modelling DFD, Function Decomp (Part 2)

SOFTWARE ENGINEERING Prof.N.L.Sarda Computer Science & Engineering IIT Bombay. Lecture #10 Process Modelling DFD, Function Decomp (Part 2) SOFTWARE ENGINEERING Prof.N.L.Sarda Computer Science & Engineering IIT Bombay Lecture #10 Process Modelling DFD, Function Decomp (Part 2) Let us continue with the data modeling topic. So far we have seen

More information

Structured Analysis and Structured Design

Structured Analysis and Structured Design Structured Analysis and Structured Design - Introduction to SASD - Structured Analysis - Structured Design Ver. 1.5 Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr http://dslab.konkuk.ac.kr References Modern

More information

Slide 1 Welcome to Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: Entity-Relationship Diagrams. This is Lecture e.

Slide 1 Welcome to Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: Entity-Relationship Diagrams. This is Lecture e. WORKFLOW ANALYSIS Audio Transcript Component 10 Unit 3 Lecture E Fundamentals of Health Workflow Process Analysis & Redesign Interpreting and Creating Process Diagrams Process Mapping UML notation for

More information

BTEC Nationals IT - Unit2 FAQs

BTEC Nationals IT - Unit2 FAQs BTEC Nationals IT - Unit2 FAQs Q1 Q2 I need more clarity on what is required in the design task Is it expected that the race officials are entering times as raw times and then the table is set up so it

More information

Database management system Prof. D. Janakiram Department of Computer Science and Engineering Indian Institute of Technology, Madras

Database management system Prof. D. Janakiram Department of Computer Science and Engineering Indian Institute of Technology, Madras Database management system Prof. D. Janakiram Department of Computer Science and Engineering Indian Institute of Technology, Madras Lecture 25 Basic 2-phase & 3-phase Commit protocol In the last lecture,

More information

(Refer Slide Time: 1:43)

(Refer Slide Time: 1:43) (Refer Slide Time: 1:43) Digital Circuits and Systems Prof. S. Srinivasan Department of Electrical Engineering Indian Institute of Technology, Madras Lecture - 27 Pattern Detector So, we talked about Moore

More information

Session 2b: structured specifications Purpose and criteria Structured specification components Introduction to dataflow diagrams

Session 2b: structured specifications Purpose and criteria Structured specification components Introduction to dataflow diagrams Session 2b: structured specifications Purpose and criteria Structured specification components Introduction to dataflow diagrams COMP 320 / 420, Spring, 2018 Conrad Weisert Criteria for the ESD (from session

More information

An Introduction to Business Process Modeling using Data Flow Diagrams

An Introduction to Business Process Modeling using Data Flow Diagrams An Introduction to Business Process Modeling using Data Flow Diagrams BSAD 141 Dave Novak BDIS: 2.2 (61-77) Lecture Overview Systems and Business processes Business process models Data Flow Diagrams (DFDs)

More information

The compiler is spewing error messages.

The compiler is spewing error messages. Appendix B Debugging There are a few different kinds of errors that can occur in a program, and it is useful to distinguish between them in order to track them down more quickly. Compile-time errors are

More information

6.001 Notes: Section 4.1

6.001 Notes: Section 4.1 6.001 Notes: Section 4.1 Slide 4.1.1 In this lecture, we are going to take a careful look at the kinds of procedures we can build. We will first go back to look very carefully at the substitution model,

More information

Software Modeling & Analysis. - Introduction to SASD - Structured Analysis. Lecturer: JUNBEOM YOO

Software Modeling & Analysis. - Introduction to SASD - Structured Analysis. Lecturer: JUNBEOM YOO Software Modeling & Analysis - Introduction to SASD - Structured Analysis Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr References Modern Structured Analysis, Edward Yourdon, 1989. Introduction to System Analysis

More information

Session 2. Getting started with a well-structured system specification

Session 2. Getting started with a well-structured system specification Session 2 Getting started with a well-structured system specification COMP 320/420 Spring, 2018 Conrad Weisert The situation A representative approaches us. (or vice versa) He or she may be a. an executive

More information

EC121 Mathematical Techniques A Revision Notes

EC121 Mathematical Techniques A Revision Notes EC Mathematical Techniques A Revision Notes EC Mathematical Techniques A Revision Notes Mathematical Techniques A begins with two weeks of intensive revision of basic arithmetic and algebra, to the level

More information

Lab 16: Visio Introduction

Lab 16: Visio Introduction Lab 16: Visio Introduction () CONTENTS 1 Visio- Introduction to DFD Data Flow Diagraming... 2 1.1 In-Lab... 3 1.1.1 In-Lab Materials... 3 1.1.2 In-Lab Instructions... 3 2 Getting started: Let s decompose

More information

PROTOTYPING 29/11/2017. Presented by: Shuchita Singh

PROTOTYPING 29/11/2017. Presented by: Shuchita Singh PROTOTYPING 29/11/2017 Presented by: Shuchita Singh Outline Requirement Analysis Overview Prototyping Life cycle of Prototyping Types of prototyping techniques Advantages and Disadvantages Case Studies

More information

We move from a general information system to a Computer Based Information System

We move from a general information system to a Computer Based Information System Introduction to Information Systems: In this section of the course we start to think of the computer as just being a component in a system which may contain one or many computers linked together. An Information

More information

Project and Production Management Prof. Arun Kanda Department of Mechanical Engineering Indian Institute of Technology, Delhi

Project and Production Management Prof. Arun Kanda Department of Mechanical Engineering Indian Institute of Technology, Delhi Project and Production Management Prof. Arun Kanda Department of Mechanical Engineering Indian Institute of Technology, Delhi Lecture - 8 Consistency and Redundancy in Project networks In today s lecture

More information

CHAPTER 18: CLIENT COMMUNICATION

CHAPTER 18: CLIENT COMMUNICATION CHAPTER 18: CLIENT COMMUNICATION Chapter outline When to communicate with clients What modes of communication to use How much to communicate How to benefit from client communication Understanding your

More information

Introduction to Programming

Introduction to Programming CHAPTER 1 Introduction to Programming Begin at the beginning, and go on till you come to the end: then stop. This method of telling a story is as good today as it was when the King of Hearts prescribed

More information

REVIEW OF THE BASIC CHARACTERISTICS OF OBJECT ORIENTATION

REVIEW OF THE BASIC CHARACTERISTICS OF OBJECT ORIENTATION c08classandmethoddesign.indd Page 282 13/12/14 2:57 PM user 282 Chapter 8 Class and Method Design acceptance of UML as a standard object notation, standardized approaches based on work of many object methodologists

More information

Usability Test Report: Requesting Library Material 1

Usability Test Report: Requesting Library Material 1 Usability Test Report: Requesting Library Material 1 Summary Emily Daly and Kate Collins conducted usability testing on the processes of requesting library material. The test was conducted at the temporary

More information

(Refer Slide Time 6:48)

(Refer Slide Time 6:48) Digital Circuits and Systems Prof. S. Srinivasan Department of Electrical Engineering Indian Institute of Technology Madras Lecture - 8 Karnaugh Map Minimization using Maxterms We have been taking about

More information

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS 6403 - SOFTWARE ENGINEERING QUESTION BANK TWO MARKS UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT 1. What is software engineering? Software engineering

More information

FROM A RELATIONAL TO A MULTI-DIMENSIONAL DATA BASE

FROM A RELATIONAL TO A MULTI-DIMENSIONAL DATA BASE FROM A RELATIONAL TO A MULTI-DIMENSIONAL DATA BASE David C. Hay Essential Strategies, Inc In the buzzword sweepstakes of 1997, the clear winner has to be Data Warehouse. A host of technologies and techniques

More information

Application of Clustering Techniques to Energy Data to Enhance Analysts Productivity

Application of Clustering Techniques to Energy Data to Enhance Analysts Productivity Application of Clustering Techniques to Energy Data to Enhance Analysts Productivity Wendy Foslien, Honeywell Labs Valerie Guralnik, Honeywell Labs Steve Harp, Honeywell Labs William Koran, Honeywell Atrium

More information

System Analysis and Design. Data Flow Diagram. System Analysis and Design

System Analysis and Design. Data Flow Diagram. System Analysis and Design Data Flow Diagram 1 Data Flow diagram The dataflow diagram is a modeling tool that allows us to picture a system as a network of functional processes, connected to one another by pipelines and holding

More information

Chapter 8. Achmad Benny Mutiara

Chapter 8. Achmad Benny Mutiara Chapter 8 SOFTWARE-TESTING STRATEGIES Achmad Benny Mutiara amutiara@staff.gunadarma.ac.id 8.1 STATIC-TESTING STRATEGIES Static testing is the systematic examination of a program structure for the purpose

More information

Chapter 9. Process Modeling. McGraw-Hill/Irwin. Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved.

Chapter 9. Process Modeling. McGraw-Hill/Irwin. Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 9 Process Modeling McGraw-Hill/Irwin Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Objectives Define systems modeling and differentiate logical and physical models. Define

More information

Programming in the Simple Raster Graphics Package (SRGP)

Programming in the Simple Raster Graphics Package (SRGP) Programming in the Simple Raster Graphics Package (SRGP) Chapter 2 This chapter focuses on a graphics package called SRGP. SRGP was written by the authors to demonstrate some of the basics of Raster Graphics

More information

Process Modelling. Data flow Diagrams. Process Modelling Data Flow Diagrams. CSE Information Systems 1

Process Modelling. Data flow Diagrams. Process Modelling Data Flow Diagrams. CSE Information Systems 1 CSE104 - Information s 1 Process Modelling Data Flow Diagrams Process Modelling Process modelling aims to graphically represent the processes which capture, manipulate, store and distribute data. data

More information

1: Introduction to Object (1)

1: Introduction to Object (1) 1: Introduction to Object (1) 김동원 2003.01.20 Overview (1) The progress of abstraction Smalltalk Class & Object Interface The hidden implementation Reusing the implementation Inheritance: Reusing the interface

More information

H&A Engineering. Systems

H&A Engineering. Systems Introduction to Structured Methods The idea that system descriptions are more clear and easier with pictures rather than words provided the basis for the development of structured methods. Structured analysis

More information

Discrete-event simulation

Discrete-event simulation 1 SYSTEM MODELING AND SIMULATION UNIT-2 VIK UNIT 2 GENERAL PRINCIPLES, SIMULATION SOFTWARE: Concepts in Discrete-Event Simulation: The Event-Scheduling / Time-Advance Algorithm, World Views, Manual simulation

More information

Darshan Institute of Engineering & Technology for Diploma Studies

Darshan Institute of Engineering & Technology for Diploma Studies REQUIREMENTS GATHERING AND ANALYSIS The analyst starts requirement gathering activity by collecting all information that could be useful to develop system. In practice it is very difficult to gather all

More information

4Sight for Mac User Guide. Version 2.4

4Sight for Mac User Guide. Version 2.4 4Sight for Mac User Guide Version 2.4 Contents Welcome to 4Sight for Mac Desktop Client... 3 How to Install 4Sight... 3 Where is it?... 4 The Dock menu... 4 The menu bar... 4 Phone window... 5 Preview

More information

13/11/2017. Meltem Özturan misprivate.boun.edu.tr/ozturan/mis515

13/11/2017. Meltem Özturan misprivate.boun.edu.tr/ozturan/mis515 Meltem Özturan misprivate.boun.edu.tr/ozturan/mis515 2 1 Traditional Approach to Requirements Data Flow Diagram (DFD) A graphical system model that shows all of the main requirements for an information

More information

DFD Symbols. Process. Data Store Data Store Data Store

DFD Symbols. Process. Data Store Data Store Data Store ? Context Diagram Level 1 Diagram Level 2 Diagram DFD Symbols External Entity Source/Sink User Data Flow Process Process Data Store Data Store Data Store Rule for naming a process: The Joe Test A process

More information

High Performance Computing Prof. Matthew Jacob Department of Computer Science and Automation Indian Institute of Science, Bangalore

High Performance Computing Prof. Matthew Jacob Department of Computer Science and Automation Indian Institute of Science, Bangalore High Performance Computing Prof. Matthew Jacob Department of Computer Science and Automation Indian Institute of Science, Bangalore Module No # 09 Lecture No # 40 This is lecture forty of the course on

More information

Learning outcomes. On successful completion of this unit you will: 1. Understand data models and database technologies.

Learning outcomes. On successful completion of this unit you will: 1. Understand data models and database technologies. 2015-2016 Phil Smith Learning outcomes On successful completion of this unit you will: 1. Understand data models and database technologies. (Assignment 1) Recap and setting the scene Before we get to Normalisation

More information

SALVO-a fourth-generation language for personal computers

SALVO-a fourth-generation language for personal computers SALVO-a fourth-generation language for personal computers by MARVIN ELDER Software Automation, Inc. Dallas, Texas ABSTRACT Personal computer users are generally nontechnical people. Fourth-generation products

More information

Requirements Analysis

Requirements Analysis Requirements Analysis Based on K. E Wiegers Software Requirements, Chap 5, 14 D. Leffingwell & D. Widrig, Managing Software Requirements A use case approach, Chap 5 Requirements Analysis The process of

More information

Post Experiment Interview Questions

Post Experiment Interview Questions Post Experiment Interview Questions Questions about the Maximum Problem 1. What is this problem statement asking? 2. What is meant by positive integers? 3. What does it mean by the user entering valid

More information

Fundamentals of Operations Research. Prof. G. Srinivasan. Department of Management Studies. Indian Institute of Technology Madras.

Fundamentals of Operations Research. Prof. G. Srinivasan. Department of Management Studies. Indian Institute of Technology Madras. Fundamentals of Operations Research Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology Madras Lecture No # 06 Simplex Algorithm Initialization and Iteration (Refer Slide

More information

Requirements Engineering process

Requirements Engineering process Requirements Engineering process Used to discover, analyze, validate and manage requirements Varies depending on the application domain, the people involved and the organization developing the requirements

More information

How to Compute Halting

How to Compute Halting 2015-1-2 0 How to Compute Halting Eric C.R. Hehner Department of Computer Science, University of Toronto hehner@cs.utoronto.ca Abstract: A consistently specified halting function may be computed. Halting

More information

Database Management System Prof. D. Janakiram Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No.

Database Management System Prof. D. Janakiram Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. Database Management System Prof. D. Janakiram Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. # 20 Concurrency Control Part -1 Foundations for concurrency

More information

the Computability Hierarchy

the Computability Hierarchy 2013 0 the Computability Hierarchy Eric Hehner Department of Computer Science, University of Toronto hehner@cs.utoronto.ca Abstract A computability hierarchy cannot be constructed by halting oracles. Introduction

More information

An Evaluation of ERwin

An Evaluation of ERwin An Evaluation of ERwin by David C. Hay ERwin is arguably the most popular CASE tool on the market today. In the view of your author, this is unfortunate, because it has shortcomings that prevent users

More information

AN ONTOLOGICAL EVALUATION OF JACKSON'S SYSTEM DEVELOPMENT MODEL. Fiona Rohde. Department of Commerce The University of Queensland, 4072.

AN ONTOLOGICAL EVALUATION OF JACKSON'S SYSTEM DEVELOPMENT MODEL. Fiona Rohde. Department of Commerce The University of Queensland, 4072. AN ONTOLOGICAL EVALUATION OF JACKSON'S SYSTEM DEVELOPMENT MODEL Fiona Rohde Department of Commerce The University of Queensland, 4072. Australia ABSTRACT Within the discipline of information systems, numerous

More information

An Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs)

An Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs) An Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs) Rosziati Ibrahim, Siow Yen Yen Abstract System development life cycle (SDLC) is a process uses during the development of any

More information

shortcut Tap into learning NOW! Visit for a complete list of Short Cuts. Your Short Cut to Knowledge

shortcut Tap into learning NOW! Visit  for a complete list of Short Cuts. Your Short Cut to Knowledge shortcut Your Short Cut to Knowledge The following is an excerpt from a Short Cut published by one of the Pearson Education imprints. Short Cuts are short, concise, PDF documents designed specifically

More information

Chapter 4: Data Management

Chapter 4: Data Management Accounting Information Systems: Essential Concepts and Applications Fourth Edition by Wilkinson, Cerullo, Raval, and Wong-On-Wing Chapter 4: Data Management Slides Authored by Somnath Bhattacharya, Ph.D.

More information

Lecture 3: Linear Classification

Lecture 3: Linear Classification Lecture 3: Linear Classification Roger Grosse 1 Introduction Last week, we saw an example of a learning task called regression. There, the goal was to predict a scalar-valued target from a set of features.

More information

Lecture 25 Spanning Trees

Lecture 25 Spanning Trees Lecture 25 Spanning Trees 15-122: Principles of Imperative Computation (Fall 2018) Frank Pfenning, Iliano Cervesato The following is a simple example of a connected, undirected graph with 5 vertices (A,

More information

20/06/ Projectile Motion. 3-7 Projectile Motion. 3-7 Projectile Motion. 3-7 Projectile Motion

20/06/ Projectile Motion. 3-7 Projectile Motion. 3-7 Projectile Motion. 3-7 Projectile Motion 3-7 A projectile is an object moving in two dimensions under the influence of Earth's gravity; its path is a parabola. 3-7 It can be understood by analyzing the horizontal and vertical motions separately.

More information

UNINFORMED SEARCH. Announcements Reading Section 3.4, especially 3.4.1, 3.4.2, 3.4.3, 3.4.5

UNINFORMED SEARCH. Announcements Reading Section 3.4, especially 3.4.1, 3.4.2, 3.4.3, 3.4.5 UNINFORMED SEARCH Announcements Reading Section 3.4, especially 3.4.1, 3.4.2, 3.4.3, 3.4.5 Robbie has no idea where room X is, and may have little choice but to try going down this corridor and that. On

More information

CS350 Lecture 2 Requirements Engineering. Doo-Hwan Bae

CS350 Lecture 2 Requirements Engineering. Doo-Hwan Bae CS350 Lecture 2 Requirements Engineering Doo-Hwan Bae bae@se.kaist.ac.kr Contents Overview of Requirements Engineering OO Analysis: Domain modeling, Use-case, sequence, class Structured Analysis: Dataflow

More information

Software Design. Software design is a blueprint or a plan for a computerbased solution for system

Software Design. Software design is a blueprint or a plan for a computerbased solution for system Software Design Software Design Software design is a blueprint or a plan for a computerbased solution for system Software design deals with transforming the customer requirements, as described by the SRS

More information

Compiler Design Prof. Y. N. Srikant Department of Computer Science and Automation Indian Institute of Science, Bangalore

Compiler Design Prof. Y. N. Srikant Department of Computer Science and Automation Indian Institute of Science, Bangalore Compiler Design Prof. Y. N. Srikant Department of Computer Science and Automation Indian Institute of Science, Bangalore Module No. # 10 Lecture No. # 16 Machine-Independent Optimizations Welcome to the

More information

Interaction Design. Task Analysis & Modelling

Interaction Design. Task Analysis & Modelling Interaction Design Task Analysis & Modelling This Lecture Conducting task analysis Constructing task models Understanding the shortcomings of task analysis Task Analysis for Interaction Design Find out

More information

(Refer Slide Time: 00:01:30)

(Refer Slide Time: 00:01:30) Digital Circuits and Systems Prof. S. Srinivasan Department of Electrical Engineering Indian Institute of Technology, Madras Lecture - 32 Design using Programmable Logic Devices (Refer Slide Time: 00:01:30)

More information

SYSTEM ARCHITECTURES FOR LIFE SUPPORT SYSTEMS

SYSTEM ARCHITECTURES FOR LIFE SUPPORT SYSTEMS SYSTEM ARCHITECTURES FOR LIFE SUPPORT SYSTEMS Alexander H. Levis and Lee W. Wagenhals George Mason University, Fairfax, VA, USA Keywords: operational architectures, technical architectures, functional

More information

06. Analysis Modeling

06. Analysis Modeling 06. Analysis Modeling Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 Overview of Analysis Modeling 1 Requirement Analysis 2 Analysis Modeling Approaches

More information

Requests Charges. Librarian. University affiliated patrons students, faculty, staff. Media Center Staff

Requests Charges. Librarian. University affiliated patrons students, faculty, staff. Media Center Staff Catherine Rutan INFO 530-901 Dr. Valerie Yonker Circulation of Media Materials from University Media Center: Requests Charges Librarian Circulation Desk Attendant Inquires University ID # (Primary Key)

More information

Power Standard 5 Practice Test

Power Standard 5 Practice Test Name Date 1) Variable a. A symbol that is used to represent a number. b. A symbol that is used to represent another symbol. c. A number that is used to represent a symbol. 2) Expression Power Standard

More information

CS 167 Final Exam Solutions

CS 167 Final Exam Solutions CS 167 Final Exam Solutions Spring 2018 Do all questions. 1. [20%] This question concerns a system employing a single (single-core) processor running a Unix-like operating system, in which interrupts are

More information

Become a Champion Data Modeler with SQL Developer Data Modeler 3.0

Become a Champion Data Modeler with SQL Developer Data Modeler 3.0 Become a Champion Data Modeler with SQL Developer Data Modeler 3.0 Marc de Oliveira, Simplify Systems Introduction This presentation will show you how I think good data models are made, and how SQL Developer

More information

VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS6403 SOFTWARE ENGINEERING II year/ IV sem CSE (Regulation 2013) UNIT 1- SOFTWARE PROCESS AND PROJECT

More information

An Eternal Domination Problem in Grids

An Eternal Domination Problem in Grids Theory and Applications of Graphs Volume Issue 1 Article 2 2017 An Eternal Domination Problem in Grids William Klostermeyer University of North Florida, klostermeyer@hotmail.com Margaret-Ellen Messinger

More information

Slide Set 5. for ENEL 353 Fall Steve Norman, PhD, PEng. Electrical & Computer Engineering Schulich School of Engineering University of Calgary

Slide Set 5. for ENEL 353 Fall Steve Norman, PhD, PEng. Electrical & Computer Engineering Schulich School of Engineering University of Calgary Slide Set 5 for ENEL 353 Fall 207 Steve Norman, PhD, PEng Electrical & Computer Engineering Schulich School of Engineering University of Calgary Fall Term, 207 SN s ENEL 353 Fall 207 Slide Set 5 slide

More information

Fundamentals of Operations Research. Prof. G. Srinivasan. Department of Management Studies. Indian Institute of Technology, Madras. Lecture No.

Fundamentals of Operations Research. Prof. G. Srinivasan. Department of Management Studies. Indian Institute of Technology, Madras. Lecture No. Fundamentals of Operations Research Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology, Madras Lecture No. # 13 Transportation Problem, Methods for Initial Basic Feasible

More information