Lesson #2

Systems Analysis
Focus is the logical view of the system, not the physical What the system is to accomplish, not how

Data flow diagrams

Tools: data flow diagrams data dictionary process specification entity-relationship diagrams

Data dictionary

Process specification

Entity-relationship diagrams

Data Flow Diagram

"a network representation of a system. The system may be automated, manual, or mixed. The DFD portrays the system in terms of its component pieces, with all interfaces among the components indicated." - Tom DeMarco

hence DFDs: focus on the movement of data between external entities and processes, and between processes and data stores

Example Data Flow Diagram

data store

data flow

process

external entity

Data Flow Diagrams are:

Used to perform structured

analysis to determine logical requirements

A graphical tool, useful for

communicating with users, managers, and other IS personnel

Useful for analyzing existing

as well as proposed systems

A relatively simple technique

to learn and use

Why Conduct Process Modeling?

Understand components of

current logical or physical system for purpose of rebuilding in a different physical form/technology, possibly with some changed functionality
Find inefficiencies in current

system

Re-engineer current system

Sources/Sinks (external entities)

Any class of people, an organization, or another system which exists outside the system you are studying. Form the boundaries of the system. The system and external entities exchange data in the form of data flows. Must be named, titles preferred to names of individuals - use a noun

source/ sink

Data Flows
data in motion marks movement of data through the system - a pipeline to carry data connects the processes, external entities and data stores Unidirectional originate OR end at a process (or both) name as specifically as possible - reflect the composition of the data - a noun do not show control flow! Control flow is easy to identify- a signal with only one byte (on/off). HINT: if you can't name it: either it's control flow, doesn't exist or you need to get more information!

Processes
transform incoming data flows into outgoing data flows represent with a bubble or rounded square name with a strong VERB/OBJECT combination; examples: create_exception_rep ort validate_input_charac ters calculate_discount

process

Data Stores
data at rest represents holding areas for collection of data, processes add or retrieve data from these stores name using a noun (do not use file) only processes are connected to data stores show net flow of data between data store and process. For instance, when access a DBMS, show only the result flow, not the request
data store

Data Flow Diagram Donts

BLACK HOLES MIRACLES Let it get too COMPLEX: 7 2 processes Leave things UNLABELED (corollary: labels should have meaning) 5. Data stores that are SOURCES or SINKS 6. Data flows that are UNASSOCIATED with a PROCESS 7. Expect your diagram to be perfect the first time! 1. 2. 3. 4.

Data Flow Diagram Donts

process stuff

1. Black Hole

process stuff

2. Its a Miracle

Data Flow Diagram Donts

ds-1

A.1 A.2 data

3. Leave Things Unlabeled Corollary: Labels Should Have Meaning

Data Flow Diagram Donts

data store

4. Miracle data source

data store

5. Black hole data source

Data Flow Diagram Donts

6. Data Flows Unassociated With a Process
entity to entity

data store to entity or reverse

data store to data store

Diagramming A System
 multiple DFDs are required to represent a system  DFDs are created at increasing levels of detail

Different Types of DFDs

 Context diagram  Level-0 diagram (system diagram)  Level-n diagram  Primitive diagram

Context Diagram
 defines the scope of the system by identifying the system boundary  contains:

one process (which represents the entire system) all sources/sinks (external entities) data flows linking the process to the sources and sinks (external entities)

Example Context Diagram

student

course selections

schedule

Registration System

Registration details

business office

Constructing a Context Diagram

 identify and list sources/sinks (external entities)  identify and list inputs to and outputs from sources/sinks (external entities)  create context diagram

LevelLevel-0 Diagram
 describes the overall processing of the system  show one process for each major processing step or functional requirement  data flows from the context appear on system diagram also (level balancing)  can show a single data store to represent all data in aggregate at this level  can draw duplicate sources, sinks and data stores to increase legibility

Drawing a Level-0 Diagram Level list the major data stores  list major business steps  draw a segment for each business step  assemble into single DFD  re-organize until satisfied  number processes

Functional Decomposition
 similar to a series of more detailed maps  iterative process of breaking the description of a system into finer and finer detail to create a set of charts in which one process on a given chart is explained in greater detail on another chart  referred to as exploding, partitioning, or leveling  must use your judgment to decide what goes on each level  show error and exception handling on lower levels (if at all)

Lower Level Diagrams

 explode the processes shown on the level-0 diagram  each process is represented by its own DFD  balance data
data flows on upper level appear on lower level, or data flows on upper level are broken into component pieces with components shown on lower level

 each lower level shows greater and greater detail  follow numbering convention

Balancing DFDs
 conserve data from level to level inputs and outputs on the higher level must appears somewhere on the lower level

Advanced Rules
 Composite data flow on one level can be split into its component data flows on the next level - but new data cannot be added and all data in the composite must be included in the sub-flows  The inputs to a process must be sufficient to produce the outputs.  Lowest level DFDs may add new data flows to represent exception handling, i.e., error messages  May repeat data stores or sources/sink to avoid crossing lines

Additional Guidelines
 the inputs to a process are different from the outputs of that process  objects in a set of DFDs have unique names  do not change data flow names on lower levels unless you are decomposing a data flow into component pieces.  never explode a single process into another single process. If you cannot partition the process, then the lower level DFD is not needed.  expect to iterate, put down the DFD and go back to it a few times to create something satisfactory.

Other Questions about Lower level diagrams

1. How deep? (how many levels?)
if the process has only one input or one output, probably cannot partition further; can you describe the process in English in about 1/2 page?

2. How broad? (how many processes on a level?)

7 two is a reasonable heuristic may temporarily place much of the system on a single diagram then re-draw into separate levels

Quality Guidelines
 Completeness
all components included & in project dictionary

 Consistency
between levels: balancing, leveling

 Timing considerations
assume system never starts and never stops

 Iterative nature
revisions are common

 Drawing primitives (lowest level)

when to stop?

LABORATORY ACTIVITY(to be recorded)

Read and study first the DFD Leaders should find time to talk

presentation.
Find all the meaning of the words

with their members regarding chapter three and the deadline

Assignment should be pass today

by example and place it in a one whole sheet of paper.

To be pass before 4pm today Programmers should now create a

but make sure it is complete cause that is a one time assignment for this midterm
I would like to see the rough draft of

your system today(attention leaders and programmers per each group)

I ll answer all your questions when

task(division of labor) for their members and pass it to me through my email-msrenen09@yahoo.com

I m back, bear with me ill just take my lunch straight schedule no break