1. Process Modeling and Data Flow Diagrams
4/19/2017

2. System Models
Logical models show what a system ‘is’ or ‘does’. They are implementation-independent; that is, they depict the system independent of any technical implementation. As such, logical models illustrate the essence of the system. Popular synonyms include essential model, conceptual model, and business model.
Physical models show not only what a system ‘is’ or ‘does’, but also how the system is physically and technically implemented. They are implementation-dependent because they reflect technology choices, and the limitations of those technology choices. Synonyms include implementation model and technical model
Systems analysts have long recognized the value of separating business and technical concerns.
They use logical system models to depict business requirements.
They use physical system models to depict technical designs.
Logical models remove biases that are the result of the way the current system is implemented or the way that any one person thinks the system might be implemented. Thus, we overcome the “we’ve always done it that way’’ syndrome. Consequently, logical models encourage creativity.
Logical models reduce the risk of missing business requirements because we are too preoccupied with technical details. Such errors can be costly to correct after the system is implemented. By separating what the system must do from how the system will do it, we can better analyze the requirements for completeness, accuracy, and consistency.
Logical models allow us to communicate with end-users in non-technical or less technical languages. Thus, we don’t lose requirements in the technical jargon of the computing discipline.
4/19/2017

3. Process Concepts A System is a Process
The simplest process model of a system is based on inputs, outputs, and the system itself – viewed a process.
The process symbol defines the boundary of the system.
The system is inside the boundary; the environment is outside that boundary.
The system exchanges inputs and outputs with its environment
Because the environment is always changing, well designed systems have a feedback and control loop to allow the system to adapt itself to changing conditions.
Consider a business as a system. It operates within an environment that includes customers, suppliers, competitors, other industries, and the government. Its inputs include materials, services, new employees, new equipment, facilities, money, and orders (to name but a few). Its outputs include products and/or services, waste materials, retired equipment, former employees, and money (payments). It monitors its environment to make necessary changes to its product line, services, operating procedures, and the like.
4/19/2017

4. 4/19/2017 Figure 5.1 The Classical Process Model of a System
A common theme in systems analysis is the use of models to view or present a system. As shown in the figure above, the simplest process model of a system is based on inputs, outputs, and the system itself – viewed a process.
Systems analysis activities tend to focus on the logical system models for the following reasons:
Logical models remove biases that are the result of the way the current system is implemented or the way that any one person thinks the system might be implemented. Thus, we overcome the “we’ve always done it that way’’ syndrome. Consequently, logical models encourage creativity.
Logical models reduce the risk of missing business requirements because we are too preoccupied with technical details. Such errors can be costly to correct after the system is implemented. By separating what the system must do from how the system will do it, we can better analyze the requirements for completeness, accuracy, and consistency.
Logical models allow us to communicate with end-users in non-technical or less technical languages. Thus, we don’t lose requirements in the technical jargon of the computing discipline.
4/19/2017

5. What is Process Modeling?
Process modeling is a technique for organizing and documenting the structure and flow of data through a system’s PROCESSES and/or the logic, policies, and procedures to be implemented by a system’s PROCESSES.
Process modeling originated in classical software engineering methods.
A systems analysis process model consists of data flow diagrams (DFDs).
A data flow diagram (DFD) is a tool that depicts the flow of data through a system and the work or processing performed by that system. Synonyms include bubble chart, transformation graph, and process model.
Don’t confuse data flow diagrams with flowcharts! Program design frequently involves the use of flowcharts. But data flow diagrams are very different!
Processes on a data flow diagram can operate in parallel. Thus, several processes might be executing or working simultaneously. This is consistent with the way businesses work.
Data flow diagrams can show processes that have dramatically different timing. For example, a single DFD might include processes that ‘happen’ hourly, daily, weekly, yearly, and on-demand.
Data flow diagrams have been popular for nearly twenty years, but the interest in DFDs has been expanded recently because of their role in business process redesign (BPR). As businesses have come to realize that most data processing systems have merely automated outdated, inefficient, and bureaucratic business processes, there is renewed interest in streamlining those business processes. This is accomplished by first modeling those business processes for the purpose of analyzing, redesigning, and/or improving them. Subsequently, information technology can be applied to the improved business processes in creative ways that maximize the value returned to the business.
4/19/2017

6. Data Flow Diagram There are only three symbols and one connection:
The rounded rectangles represent processes or work to be done.
The squares represent external agents – the boundary of the system.
The open-ended boxes represent data stores, sometimes called files or databases, and correspond to all instances of a single entity in a data model.
The arrows represent data flows, or inputs and outputs, to and from the processes.
There are several competing symbol sets for DFDs. Most are named after their inventors (e.g., Yourdon/DeMacro, Gane/Sarson) or after a published standard (e.g., IDEF0, SSADM). Some analysts will argue semantics, but these data flow diagramming ‘languages’ generally support the same fundamental concepts and constructs. The textbooks have adopted the Gane and Sarson (Structured Analysis) notation because of its popularity and CASE tool support. (Visible Analyst can use Yourdon/DeMacro notation too.)
4/19/2017

7. Logical Processes You should be left only with logical processes that:
Perform computations (e.g., calculate grade point average)
Make decisions (determine availability of ordered products)
Sort, filter or otherwise summarize data (identify overdue invoices)
Organize data into useful information (e.g., generate a report or answer a question)
Trigger other processes (e.g., turn on the furnace or instruct a robot)
Use stored data (create, read, update or delete a record)
Process Name
Gane & Sarson
Process Shape
Logical process models omit any processes that do nothing more than move or route data, thus leaving the data unchanged.
Physical business systems frequently implement such processes, but they are not essential – in fact, they are increasingly considered unnecessary bureaucracy. Thus, you should omit any process that corresponds to a secretary or clerk receiving and simply forwarding a variety of documents to their next processing location, at least for now.
We will adopt the convention of naming event processes as follows:
PROCESS ____________ ,
RESPOND TO _____________ , or
GENERATE ______________.
where the blank would be the name of the event (or its corresponding input).
4/19/2017

8. Data Flows Data in Motion A data flow is data in motion. Gane & Sarson
A data flow represents an input of data to a process, or the output of data (or information) from a process. A data flow is also used to represent the creation, deletion, or update of data in a file or database (called a data store on the DFD).
A data flow is depicted as a solid-line with arrow.
Processes respond to inputs and generate outputs. Thus, at a minimum, all processes have at least one input and one output data flow. Data flows are the communications between processes and the system’s environment.
Think of a data flow as a highway down which packets of known composition travel. The name implies what type of data may travel down that highway. This highway is depicted as a solid-line with arrow. .
Name of data-flow
Gane & Sarson
Data Flow Shape
4/19/2017

9. System Concepts for Process Modeling
External Agents
An external agent defines a person, organization unit, other system, or other organization that lies outside of the scope of the project, but which interacts with the system being studied. External agents provide the net inputs into a system, and receive net outputs from a system. Common synonyms include external entity.
External agents are almost always one of the following:
An office, department, division, or individual within your company that provides net inputs to that system, receives net outputs from that system, or both.
An organization, agency, or individual that is outside your company, but which provides net inputs to, or receive net outputs from, your system. Examples include CUSTOMERs, SUPPLIERs, CONTRACTORs, BANKs, and GOVERNMENT AGENCY(ies).
Another business or information system—possibly, though not necessarily, computer-based—that is separate from your system but with which your system must interface. Very few information systems do not interface with other information systems. Indeed, it is becoming commonplace to interface the information systems with those of other businesses.
One of your system’s end-users or managers. In this case, the user or manager is either a net source of data to be input to your system and/or a net destination of outputs to be produced by your system.. .
External Agent
Gane & Sarson
External Agent Shape
4/19/2017

10. System Concepts for Process Modeling
Data Stores
A data store is an ``inventory’’ of data. Synonyms include file and database (although those terms are too implementation-oriented for essential process modeling).
Ideally, essential data stores should describe ``things’’ about which the business wants to store data. These things include:
Persons: AGENCY, CONTRACTOR, CUSTOMER, DEPARTMENT, DIVISION, EMPLOYEE, INSTRUCTOR OFFICE, STUDENT, SUPPLIER. Notice that a person entity can represent either individuals, groups, or organizations.
Places: SALES REGION, BUILDING, ROOM, BRANCH OFFICE, CAMPUS.
Objects: BOOK ,MACHINE, PART, PRODUCT, RAW MATERIAL, SOFTWARE LICENSE, SOFTWARE PACKAGE, TOOL, VEHICLE MODEL, VEHICLE. An object entity can represent actual objects (such as SOFTWARE LICENSE), or specifications for a type of object (such as SOFTWARE PACKAGE).
Events: APPLICATION, AWARD, CANCELLATION, CLASS, FLIGHT, INVOICE, ORDER, REGISTRATION, RENEWAL, REQUISITION, RESERVATION, SALE, TRIP.
Concepts: ACCOUNT, BLOCK OF TIME, BOND, COURSE, FUND, QUALIFICATION, STOCK.
Data-store name D1
Gane & Sarson
Data Store Shape
4/19/2017

11. 4/19/2017 Figure 2.4 Event-Driven Process Modeling Strategy - slide 1
Step 1: A system context diagram is constructed to establish initial project scope.
Step 2: A functional decomposition diagram is drawn to partition the system into logical subsystems and/or functions (or describe each function narratively ).
Step 3: An event-response list is compiled to identify and confirm the business events to which the system must provide a response.
Step 4: One process (for each event identified in step 3), called an event handler is added to the decomposition diagram.
Step 5: An event diagram (a child diagram) is constructed and validated for each event.
4/19/2017

12. 4/19/2017 Figure 2.5 Event-Driven Process Modeling Strategy - slide 2
Step 6: A system diagram(s) is constructed by merging the event diagrams.
Step 7: A primitive diagram is constructed for each event process.
(For milestones 2 & 3, you do not need to include these two diagrams.)
4/19/2017

13. Common Mechanical Errors
Be careful to avoid three common mechanical errors with processes (as illustrated in the following slide):
A black hole is when a process has inputs but no outputs. Data enters the process and then disappears.
A miracle is when a process has outputs but no input.
A gray hole is when the inputs of a process are insufficient to produce the output. (most common)
Process 1 has inputs but no outputs. We call this a black hole because data enters the process and then disappears. In most cases, the modeler simply forgot the output.
Process 2 has outputs but no input. Unless you are David Copperfield, this is a miracle! In this case, the input flows were likely forgotten.
Process 3 the inputs are insufficient to produce the output. We call this a gray hole. There are several possible causes including: (1) a misnamed process, (2) misnamed inputs and/or outputs, or (3) incomplete facts. Gray holes are the most common errors – and the most embarrassing. Once handed to a programmer, the input data flows to a process (to be implemented as a program) must be sufficient to produce the output data flows.
4/19/2017

14. Illegal Data Flows 4/19/2017 Figure 2 Illegal Data Flows
All of the data flows on the left side of the Figure above are illegal. The corrected diagrams are shown on the right side.
Data Flow Names:
Should discourage premature commitment to any possible implementation.
Should be descriptive nouns and noun phrases that are singular, as opposed to plural.
Should be unique.
Use adjectives and adverbs to help to describe how processing has changed a data flow.
No data flow should ever go completely unnamed.
Data flow names should describe the data flow without describing how the flow is or could be implemented.
All data flows must begin or end at a process, because data flows are the inputs and outputs of a process.
4/19/2017

15. Logical Processes
Logical processes are work or actions that must be performed no matter how you implement the system.
Even for the future system, at the definition phase, the process model should be logical.
In the study phase, the current system was analyzed in three levels of models:
Context Diagram
System Diagram (Level 0)
Event Diagrams (Level 1, level 2, …)
A function is a set of related and on-going activities of the business.
Each of these functions may consist of dozens, or hundreds of more discrete processes to do support specific activities and tasks.
Functions serve to group the logically related activities and tasks.
An event is a logical unit of work that must be completed as a whole. An event is triggered by a discrete input, and is completed when the process has responded with appropriate outputs. Events are sometimes called transactions.
Functions consist of processes that respond to events.
Each of these events has a trigger and response that can be defined by its inputs and outputs.
System functions are ultimately decomposed into business events.
Each business event is represented by a single process that will respond to that event.
4/19/2017

16. Context Diagram 4/19/2017 PIA interacts with two (2) external agents:
A CUSTOMER provides initial input to the system by placing an order. PIA responds to the order by sending the product (CD) ordered and invoice for payment. Sometimes the ordered product is out of stock, then Ed sends a letter of notice.
PIA sends vender_orders for supplies of CDs to VENDORs and receives products and vendor_invoice. Upon receiving the invoice, Ed pays the bill.
4/19/2017

17. System Diagram
1. Process Order: One function of the PIA is to process customer orders and related tasks including receiving orders, confirming the availability of the products ordered, and generating invoices/letters.
2. Process Inventory: Another function is to deal with inventory and suppliers
3. Process Accounting:
4/19/2017

18. Event (Child) Diagram(s)
1. Process Order (Diagram 1)
1.1 CUSTOMER places an order.
1.2 Upon receiving such an order, Ed first checks the availability of the products from his product inventory note.
1.3 If the product is in the inventory, he sends the product and types an invoice to send to the CUSTOMER.
1.4 If there is no such a product in inventory, he sends a letter to the CUSTOMER saying that he does not have the product.
4/19/2017

19. How to Model a New System
Step 1: Identify the changes in functional requirements for the new system
Step 2: Establish the context for the new system
Step 3: Create a new system diagram
Step 4: Create necessary child diagrams
Now after rigorously pursuing the model of current system (processes), we can offer an improvement. To do so, we use a logical models of future systems. Remember, we are only interested in logical model of the new system: that is, WHAT the new function/process should be.
4/19/2017

20. Identify the changes in functional requirements for the new system
Source: Problem Statement (Cause/Effect)
Prioritize the “System Objectives” based on the urgency/importance of the effects
Regroup the objectives into changes in functional requirements
e.g.,
Operational requirements,
Reporting/Inquiry requirements
Remember the cause/effect analysis we did in the milestone 2. The third column contains the functional objectives (what should be done). The second column should contain causes and effects of the said problem. Thinking about the seriousness of the problem judging from its effects, prioritize the objectives.
4/19/2017

21. Figure 1: Changes in the functional requirements
4/19/2017

22. Establish the context for the new system
Analyze the new functional requirements in terms of necessary input/output of data
i.e.,
Is there any new input?
Is it necessary to produce new output?
Is it going to allow new functions to external entities?
Most of the time, the new system maintains the same context diagram because changing it usually requires the cooperation from external entities.
However, the recent trend of getting online orders for electronic commerce make this different. It used to be a batch process to capture and enter the order data into the database. Now it is now the on-line process. It is more likely to have more interactions between the customers and the system.
4/19/2017

23. New Context Diagram
Now I added several data flows originating the external entities and output flows to the external entities.
4/19/2017

24. Create a new system diagram
Principles for creating new DFD
Keep the model simple
Try to use data stores to connect all the processes
Identify the functions that must be affected by the new functional requirements
Determine the boundary of the new system
Again, most likely that functions stays the same as the current system. Except for the Web-based electronic commerce system, in which customers plays a great deal of roles in input/inquiry functions to the system database.
Try make it simple and save the space by eliminating the obvious processes such as retrieving the data form data store (just an input arrow implies that there is a process of retrieving data from database).
Now for your milestones, I want you to specify the major functions that you can work on within the reasonable time-limit (that is one semester for IFS410 class). That would be your domain of change, and the edge of those combined processes would be your boundary of the new system.
4/19/2017

25. New System Diagram
Notice that because of the added input and output, one additional function appears on the DFD, but the not for the monthly report. Additional input/output may increase the number of functions or the number of events within a function.
In this case, we can work on the all the processes, therefore, the domain of change include all the functions.
4/19/2017

26. Create necessary child diagrams
Explode each function to depict the flow of data within the function
A list of events within the function will be helpful
Add necessary data stores
Again, list of events within the function may be of help. For instance, now you need to have events of electronic recording the order information, supply information, etc. in addition to receiving the order. Remember, it is a logical design. Do not concern how it is done (on-line, Web forms, etc.). Just depict what should be done, what info/data should be recorded.
4/19/2017

27. A New Event (Child) Diagram
At this point, without finishing the data modeling, it might be hard to consider which data stores are necessary. A data store is a representation of files, tables in a databases, etc. Initially, it is OK to have fewer or more data stores than actually necessary. We will talk about the data entities in data modeling.
4/19/2017

28. Group Project Objectives Milestone 2 Milestone 3 Overviews
Problem Statement
Narrative descriptions of processes (data flows, data stores, external entities)
Milestone 3
4/19/2017