Modeling System Functions

Name: Modeling System Functions
Uploaded: 2017-08-19T04:22:54+00:00
Duration: PTM27S29
Channel: Rose Bishop
Description: Modeling System Functions

Modeling System Functions
ENMA 6010: Data Flow Diagrams Modeling System Functions Primary Reference: Wikipedia – Data Flow Diagrams ©2010 – Mark Polczynski All rights reserved ENMA 6010: Data Flow Diagrams

ENMA 6010: Data Flow Diagrams
We will be studying four modeling approaches: Data flow diagram – system function State transition diagrams – time dependent behavior Entity relationship diagram – stored data/material Process flow diagrams – actions and decisions Detail To understand the rationale behind this modeling tool, We need to review the reasons for modeling, And the characteristics of good model. ENMA 6010: Data Flow Diagrams

Goals of System Modeling: To focus on important system features while downplaying less important features, To discuss changes and corrections to the user’s requirements at low cost and with minimal risk, To verify that we understand the user’s environment, To verify that we have documented our understanding in a way that would allow others to construct/maintain the system. Data flow diagrams are a good tool for modeling system functions. Additional tools are typically required to meet this complete set of goals. ENMA 6010: Data Flow Diagrams

Characteristics of Good Models Graphical, with support for detailed text descriptions: Picture is worth a thousand words  picture links to a thousand words. Top-down partitionable: Globe  Continents  Countries  Minimally redundant: Make changes in just one place in the model. Transparent: Requires no expertise in model building to understand the model. ENMA 6010: Data Flow Diagrams

Data flow diagrams focus on: Processes within a system that Transform data/material inputs to outputs Store data/materials Flows Within the system between the processes and stores, To/from entities outside of the system. Low-hanging apple Pick apple Picked apple Picked apples ENMA 6010: Data Flow Diagrams

Origins and Uses Data flow diagrams began to be widely used in the 1970’s. They are a key tool in software engineering. They are associated with the general field of structured analysis. So, they are good for modeling business systems. They focus on data (information), but in a general sense, they can represent any type of flow, e.g., money flow, material flow. Thus, they are a good tool for modeling inventory flow and storage in a manufacturing system. But in their basic form they are primarily qualitative vs. quantitative. That being said, they can be an excellent high-level representation for streamlining systems and reducing inventory. ENMA 6010: Data Flow Diagrams

Data, Materials, and Objects Because DFDs came out of software engineering, the focus was on data. But as we see, the modeling approach accommodates any kind of flow, including data, materials, money (which is now data, not materials like silver and gold), etc. So here, we will just use the generic term “object” for whatever is flowing. As it turns out, this term will show up in other modeling tools. ENMA 6010: Data Flow Diagrams

Data Flow Diagram Symbols Process Process (or function) which transforms data or material (objects) inputs to outputs. Black box - does not indicate how or when the transform is done. Shorthand = “bubble”. Place where objects come to rest. You only store object that the system needs to “memorize”. Store Flow Directed pathways between processes, stores, and terminators. Use a different flow for each type of object. External Terminator Entities outside the system. Where flows start and end. Outside the scope of the model. ENMA 6010: Data Flow Diagrams

Example Data Flow Diagram: Book Shipping and Receiving System Alternate shape From Yourdon – Some inconsistencies! ENMA 6010: Data Flow Diagrams

Naming Data Flow Diagram Elements Constructing and understanding data flow diagrams can be enhanced by sticking to some simple naming conventions: Process Verb-object phrase: “Calculate sales tax”. Don’t use the name of the person/computer/etc. Rather, describe the function (keep it general). Flow Noun: Name of the object flowing, e.g. “Apple”. If it is “Apple, Pear, Banana”, and you process them all the same way call it “Fruit”. Store Typically, plural of the object being stored: “Apples” External Terminator This is typically some physically distinct entity – person, computer, company, agency, another system. ENMA 6010: Data Flow Diagrams

Some Implementation Notes: If you are struggling with defining meaningful names for diagram elements (e.g. “valid tax return” vs. “input”), then you probably don’t understand the system. To increase clarity, you can show terminators and stores more than one time in a diagram (see BODS example), but each process bubble can appear only once. Terminators are outside the system being modeled. If you start drawing flows between terminators, then you are, in essence, expanding the boundaries of the system you are modeling. You can’t have processes or stores with inputs but no outputs (sinks), or outputs but no inputs (sources). Only terminators can be sources or sinks of objects. ENMA 6010: Data Flow Diagrams

Implementation Note on Terminators: Usually, your customer defines the scope of the system that you will be modeling. This defines the terminators for the DFD. Terminators are outside of the system, and, by definition, the modeler cannot change the contents, organization, or internal procedures of terminators. Therefore, the DFD is an essential document for customer interaction and model scope definition. It is essential to controlling customer expectations. ENMA 6010: Data Flow Diagrams

Further Information on Implementation The Yourdon text has detailed guidelines on do’s and dont’s of drawing DFDs. We will not cover this detail here, but it is highly recommended that someone on your team reads through this and does a thorough check of your project DFD. That being said, there are some key issues we still need to touch on: Logical model vs. physical model, Top-down modeling, Bottom-up modeling, Data dictionary Extensions for real-time control. ENMA 6010: Data Flow Diagrams

DFD Logical Model vs. Physical Model The logical model contains only the diagram elements absolutely needed to make a system meet the customer requirements. This is sometimes termed the essential model. The physical model contains process, store, and flow elements that are added by the designer to make implementation easier. This may be called the environmental model. The logical model is implementation independent… …The physical model is implementation dependent. ENMA 6010: Data Flow Diagrams

Great! What Does That Mean?! This is a very critical distinction… and an essential part of building good models. Let’s start with a simple example: Making a PBJ sandwich… ENMA 6010: Data Flow Diagrams

Processes and Flow Here is the logical model for preparing your sandwich. The model contains all the essential processes and flows. But what if you were preparing the sandwich in the morning, and it is supposed to be your lunch? ENMA 6010: Data Flow Diagrams

Process, Flow, and Storage Here, the sandwich is constructed and stored for later consumption. Thus, the storage element is required to implement this system, But it is not required to make a PBJ sandwich. ENMA 6010: Data Flow Diagrams

Logical Model: Ideally, orders are processed immediately. Physical Model: In this implementation of the ideal system, orders are processed in batches, so they need to be stored before processing. Un-Lean This is an example of a physical model containing an implementation-dependent data store. ENMA 6010: Data Flow Diagrams

Here is an example of a necessary data store in an order entry system… Here, it is absolutely necessary to keep a long-term record of Orders for government accounting regulations, warrantee coverage, etc… So this should be included in the logical model. ENMA 6010: Data Flow Diagrams

Using Logical and Physical Models Typically, you develop the logical model first to understand the system, Then build the physical model to use as a design spec showing actual implementation. The physical model represents compromises that add cost to the system. In the physical model, the diagram elements turn into the names of: People, Physical pieces of hardware, Software packages, File or databases, Inventory locations, Etc… ENMA 6010: Data Flow Diagrams

Goal is to make physical model look like logical model.
Buffers and Work-In-Process In practice, a primary difference between logical and physical models lies in the stores. In logical models, only the objects that needs to be stored for future use (“memorized” for data) appear in the model. The added data stores in physical models represent buffers needed for real- world systems to level out flow between processes. Since data flow and data store can also represent material flow and material store, data stores represent inventory or work-in-process. Comparison of logical and physical models is an excellent way of identifying and reducing work-in-process. Goal is to make physical model look like logical model. ENMA 6010: Data Flow Diagrams

Logical vs. Physical Model In a sense, the logical model represents an ideal future state of a system. Thus, the logical represents a “to-be” model that our kaizen efforts should be directed toward. It is important to build the logical model first, since we really need a description of the to-be state. Now, whether you are designing a new system or analyzing an old system, you must always ask: Why do I need this storage element in the physical model? How could I eliminate the need for this physical element? ENMA 6010: Data Flow Diagrams

Let’s see how this works…
Top-Down Modeling Obviously, a system with many processes, flows, and stores can result in a data flow diagram that is impossible to understand, maintain, and improve. The field of structured analysis allows top-down design, modeling, and documentation, where processes are decomposed into multiple sub- levels. Data flow diagrams support this approach. Let’s see how this works… ENMA 6010: Data Flow Diagrams

Returning to the Book Order and Delivery System, we see a bunch of process blocks, storage blocks, terminator blocks, and flows. So we can easily find the system boundaries right away… Process Store Flow External Terminator ENMA 6010: Data Flow Diagrams

Context Diagram By observing system boundaries, we can draw a Context Diagram which shows the system we are analyzing (target system), and the systems that our system interacts with. Target system for analysis Note: Drawing the Context Diagram resolved some inconsistencies in Yourdon’s original example! ENMA 6010: Data Flow Diagrams

Context Diagram The Context Diagram is the top level in our top-down model. Target system for modeling Once we settle on what is inside and outside the system we will model, And how our system interacts with the outside world, We can focus our attention on modeling the target system. ENMA 6010: Data Flow Diagrams

Level 0 Returning to Yourdon’s example, Level 0 shows the major functions and stores inside the Context Diagram target system. Note the numbering on the functions ENMA 6010: Data Flow Diagrams

Top-Down Modeling – Process Decomposition
Next, you draw data flow diagrams for what is happening inside each Level 0 function, etc…. Note the numbering convention on the processes. Context Diagram System Level 0 1 2 3 Level 1 3.3 3.1 3.2 Level 2 ENMA 6010: Data Flow Diagrams

Top-Down Decomposition Implementation Notes: Try to limit each DFD level to about 6 processes and stores (1 .ppt slide). If you have more than 6 processes, try to group them, and then create sub-level showing detail. You will rarely go beyond Level 2. Remember! DFD just shows: WHAT processes (transforms, functions) are performed on data/materials. Not HOW the processes are performed. We’ll use other tools to show the HOWs. ENMA 6010: Data Flow Diagrams

Top-Down Modeling for System Design The top-down approach works well when designing a new system. Since you don’t know details, you can start by identifying the main object transformations. Then figure out later (or delegate) how each major transformation will be done. This generates the lower levels of the diagram. Note: As you do this, you may choose to change the boundaries of upper layers, e.g., move Process 3.3 inside of Process 2. Level 0 1 3 2 Level 1 3.1 3.2 3.3 ENMA 6010: Data Flow Diagrams

DFD Modeling Process: Bottom-Up Modeling We saw how to build a top-down for a new process, but it is also possible to draw DFDs using a bottom-up approach. Bottom-up works OK for existing systems, but kind of difficult for systems that don’t exist yet. Here’s how you do it: Start by just writing down “events” (things that happen in your system) on post-it notes. These events represent the process elements (bubbles). For each process, identify what data or material is needed for the process function. Find the process that provides the needed object and draw a flow line. Create new processes where there is no source of the required object. Add stores where they are absolutely required. Processes which are read-only or write-only are terminators, or you haven’t analyzed the system correctly. ENMA 6010: Data Flow Diagrams

Process Flow Diagram for Bottom-Up Data Flow Diagramming
Enter Exit Group and Organize Process Walkthrough Review and Revise Test Model List all events that occur in the system Attach flows in and out to events (processes) Walk through system operation using the model For each event, identify the data/material in Attach data/material stores to flow in and out Process Flow Diagram for Bottom-Up Data Flow Diagramming For each event, identify data/material out Create diagram from flow/process/store sets sets For each data/material, identify stores as needed Eliminate duplicate flow/process/store elements No Model accurate? Put events, data/materials, stores on self-stick notes Identify missing processes, flows, and stores Yes Use the model ENMA 6010: Data Flow Diagrams

Data Dictionary You can collect the names of all of the stored objects into a text document. Then, you can describe the characteristics of that object. This is the data dictionary… It consists of what it is that we need to “remember” about each object. Of course, you can treat materials just like data, which results in an inventory list vs. a data dictionary ENMA 6010: Data Flow Diagrams

Extensions for Real-Time Control
Consider our PBJ System. Assumedly, we just don’t keep making and storing sandwiches, Or just keep eating sandwiches all day long… So, what turns the bubbles on and off? ENMA 6010: Data Flow Diagrams

Control flow Control function ENMA 6010: Data Flow Diagrams

Control Function The control function coordinates the activities of the other DFD functions. Control function inputs and outputs are 1-bit on/off yes/no signals. No data/materials flowing on control lines! These signals “wake up” other functions when the function needs to transform inputs to outputs. These could be expected or unexpected conditions. Typically there is no more than one control function for a particular data flow diagram. ENMA 6010: Data Flow Diagrams

What A Mess!! Yes, these models can get pretty complicated and messy, But whose fault is that?! One way to help keep things under control is to put your DFDs in matrix format: ENMA 6010: Data Flow Diagrams

OK, let’s convert Yourdon’s example to matrix form… Start with functions: Receive order Ship books Collect payments Then terminators: Customers Warehouse Now build the matrix… ENMA 6010: Data Flow Diagrams

DFD Matrix – Step 1 Now let’s fill in the cells… ENMA 6010: Data Flow Diagrams

DFD Matrix – Step 2 F = Flow S = Store ENMA 6010: Data Flow Diagrams

Why would you do this? Does Ship books send anything to warehouse?
Well, for example, now it’s pretty easy to go to each empty cell and ask if there actually should be a data flow that we missed in our analysis. ENMA 6010: Data Flow Diagrams

Data flow diagrams have these characteristics.
Characteristics of Good Models Graphical, with support for detailed text descriptions: Picture is worth a thousand words  picture links to a thousand words. Top-down partitionable: Globe  Continents  Countries  Minimally redundant: Make changes in just one place in the model. Transparent: Requires no expertise in model building to understand the model. Data flow diagrams have these characteristics. ENMA 6010: Data Flow Diagrams

Goals of System Modeling: To focus on important system features while downplaying less important features, To discuss changes and corrections to the user’s requirements at low cost and with minimal risk, To verify that we understand the user’s environment, To verify that we have documented our understanding in a way that would allow others to construct/maintain the system. Data flow diagrams are a good tool for modeling system functions. Additional tools are required to meet this complete set of goals. ENMA 6010: Data Flow Diagrams

Can you be more specific?
We will be studying several modeling approaches, including: Data flow diagram – system function State transition diagrams – time dependent behavior Entity relationship diagram – stored data/material Process flow diagrams – actions and decisions Detail Can you be more specific? ENMA 6010: Data Flow Diagrams

Preview of coming lectures… State transition diagram
Process flow diagram Entity relationship diagram ENMA 6010: Data Flow Diagrams

Notes on using Visio to draw data flow diagrams… ENMA 6010: Data Flow Diagrams

Forget it! See next slide My favorite shapes… ENMA 6010: Data Flow Diagrams

Start with “Dynamic connector”… Then select line and right click… Then choose “Curved Connector” ENMA 6010: Data Flow Diagrams

Modeling System Functions

Similar presentations

Presentation on theme: "Modeling System Functions"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Modeling System Functions

Similar presentations

Presentation on theme: "Modeling System Functions"— Presentation transcript:

Similar presentations

About project

Feedback