SSA403 : System Analysis and Design Method

Chapter 2: System Development Techniques and Methodologies

Ms.Nor Alina

Learning Outcome
After studying this chapter, you should be able to :
How to define process modeling Understand about function decomposition. Understand about ERD Understand about DFD Understand about procedure modeling.

Process Modeling
Process modelling involves graphically representing the functions, or processes. All functions / processes which capture, manipulate, store and distributed data between a system and its environment and between components within system. Several different tools have been developed for process modelling.

Modeling system s Process

There are 3 sub-phases of the analysis phase of SDLC:
Requirements determination Requirements structuring Generating alternative system

The analysis team enter requirements structuring with an abundance of information gathered during requirements determination.

Modeling system s Process

Requirements structuring organize the information into to meaningful representation of the information system that exists and of the requirements desired in a replacement system. The modeling process elements of an information system and how data are transformed in the system. Modeling process also must processing logic and the timing of events in the system and the structure of data within the system.

Modeling system s Process

A process model is only one of three major complementary views of an information system. Process, logic and timing and data models provide a thorough specification of an information system and with the proper supporting tools, also provide the basis for the automatic generation of many working information system components.

Deliverables and Outcomes

In structured analysis, the deliverables from process modeling are a set of coherent, interrelated data flow diagrams. Deliverables for process modeling:

Context data flow diagram (DFD) DFDs of current physical system (adequate detail only) DFDs of current logical system DFDs of new logical system Thorough descriptions of each DFD component.

Deliverables and Outcomes

A context diagram shows the scope of the system, indicating which elements are inside and which are outside the system. DFD of the current physical system specify which people and technologies are used in which processes to move and transform data, accepting inputs and producing outputs. These diagrams developed into sufficient detail to understand the current system and to eventually determine how to convert the current system into its replacement.

Deliverables and Outcomes

Technology independent or logical DFD of the current system show what data processing functions are performed by the current information system. Data movement or flow, structure, and functional requirements of the new system are represented in logical DFD.

Deliverables and Outcomes

Entries for all of the objects included in all diagram are included in the project dictionary or CASE repository. This logical progression of deliverables allows to understand the existing system. Then, abstract this system into its essential elements to show the way in which the new system should meet its information processing requirements identified during requirements determination.

Deliverables and Outcomes

The deliverables process of modeling are simply stating from process during requirements determination. DFD involve from the more general to the more detailed as current and replacement systems are better understood. DFD remain popular tools for process modeling and can significantly increase software development productivity as reported above for Raytheon, data flow are not used in all system development methodologies.

S.S.A.D.M.
S.S.A.D.M. - Structured Systems Analysis and Design Method Uses different techniques to model a system Data Flow Diagrams Entity Relational Model (Logical Data Stores) Normalisation

Data Flow Diagrams

What is a Data Flow Diagram?

Known as DFDs A way to model a real world situation They are the interface between the real world activities and an understanding of how this can be converted into a computer system.

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

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 do we use DFDs?

It is a way of taking the physical view and converting it into a logical view. The physical view - all documents involved The logical view - the data they contain Their main purpose is to communicate with the user, the analysts understanding of the scope of the required system

Example Data Flow Diagram

data store

data flow

process

external entity

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_report validate_input_characters 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

Levelling
DFDs are expanded or decomposed into levels. Separating each process into sub processes Uncovers more and more detail

Conventions
- Balancing - Process at lower level should have identical data flows if they flow out of a process - Modelling Data Stores - Only use DATA STORES used within this process on the diagram - Numbering 1 - 1.1 - 1.1.1 1.2 - 1.2.1 - Labels

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

Decomposition and Abstraction

Decomposition - Divide and subdivide into manageable size problems Abstraction - Concentrate on the important issues and ignore the irrelevant

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

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)

The Elements
The four main elements of DFDs notation y Data Flows, with a label to indicate what data is flowing y Processes, that handle the data y Data stores, within the system (diary, filing cabinet or computer file) y Outside entities, outside sources of data

Process and Data Stores

A process is made up of Data Stores
Process Number Destination (Place or Name)

Process description Should be descriptive, starting with a verb.

Can be M for manual or D for computer base data stores.

MD

Name of Store

Outside Entity
Is anything outside the system that is of interest to the system. Can be a person, a company or another system.
Customer a

Outside entity shows the Name and a lowercase alpha character is used to uniquely identify it.

Customer a

If an outside entity is repeated for the purpose of neat layout a line is added across the top.

Data Flow
Is shown by a line with an arrowhead, indicating the direction of the flow of data. Each data flow should be named to indicate what data is being passed. Nouns or adjectives only no verbs are permitted.

Different Types of DFDs

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

Rules
Sequence not important - getting the Process correct is

Context or Level 0 - Identifies the system/ boundary/External Links Level 1 - Overview of function Level 2 - Breakdown to Understand Hard to know where to stop Rule of Thumb If there are more than 8 data flows break it Process of Identifying major Processes

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

T h e P r o c e d u r e fo r C o n s tr u c tin g D F D s
y y D r f t D r r rt y y y D r Id e n tif r f t t t t t D i r e s y s te m C u rre n t e s s e s in t rr t i t t t fl it ti i r t r

C o m p le te t e le v e l ys i l D F D

T h e D o c u m e n t F lo w
T s b s h e itu e s u c

D ia g r a m

t s k o f m o d e llin g u s in e s s a n e d a u n tin g a t fir s t. It is a tio n t to s ta rt it h s o m e t h in g s im p le h a s a d o c u m e n t flo w d ia g r a m .

Production Planning
Production Plan Delivery Note

Supplier

Purchase Order Supplier Details Update Form Delivery Note Material Requirements List

Stock Control

Purchasing

Stock Withdrawal Note

Bill of Materials

Factory

Design

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

Another example Context Diagram

a Production Planning
Production Plan

b Supplier
Delivery Note

e Design
Bill of Materials

Stock Control Maintain Stock System

Stock Withdrawal Note

Supplier Details Update Form Delivery Note Material Requirements List

c Purchasing

d Factory

A s p A s p

l y r l y r

l s o l s o

d a ta te m c e s s d a ta te m c e s s

fl m . fl m .

o w s g o in g in to th e u s t b e r e c e iv e d b y

o w s g o in g o u t o f th e u s t b e g e n e r a te d b y

T h e fir s t ta s k is th e r e fo r e to id e n tify th e s e p r o c e s s e s :

Stock clerk Maintain planned call-off

Stock clerk Maintain stock cards

Stock clerk Prepare material reqmnts list

D ra

e e x te r a l e titie s a a ta sto r e s.

a Production Planning

Stock clerk

M1
Maintain planned call-off

Bill of materials

b Supplier

M2

Stock cards

c Factory

Stock clerk Maintain stock cards

3
d Purchasing

Stock clerk Prepare material reqmnts list

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

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?

Level-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

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

L evel 1

y s ic a l D F D -

o m p le te

F in a lly d r a w in th e d a ta flo w s to g iv e a c o m p le te d d ia g r a m . o te th a t a d a ta flo w m u s t h a v e a p ro c e s s a t th e e n d .

t ck cl rk Pr Pl cti i Pr Pl cti l i t i c ll- ff Pl t ils li r li c ct r t ck it r t t ils li t Purc si t ri l r uir list r t ck cl rk r Pr t ri l r list r t t ck cl rk i t i st ck c r s t ck t ils t ck t ils c ll- ff t ils

ill f

t ri ls

t ck c r s

suppl

ts

ts

H a ir d r e s s in g a lo n e v e l h y s ic a l D F D
1
Receptionist Register Appointment Appointment details New client details

Existing client details Confirmation Request Confirmation Details

M1 Client card index

Appointment details

M2 Appointment diary
Confirmation of arrival

a Client Appointment details

(

Receptionist Confirm arrival Appointment details Change of hairstyle etc.

Change of hairstyle etc.

e jk

&

D e e k s )

Hairdresser/Rcptnst

Conduct appointment

Process 3 Level 2
3 Client a Clie a Hair Details 3.2 Hairdresser Hair/Reception

3.1

Hairdresser

Conduct Appointment

Appointment Details M2 Diary

Inform Reception Change of Hair Details 3.3 Receptionist M3 Client Card

Complete Appointment

Naming of DFD processes

Level 0 Level 1
2 1 P ro c e ss M an 2 .1 Sub P ro c e ss O v er a ll P ro c e ss 2 P ro c e ss P ro c e ss 2 .1 .1 Sub - Sub P ro c e ss

Level 2
2 .2

Level 3

Level 4
2 .1 .1 E le m e n ta r y pro c e ss d e s cr ip tio n s. D e ci si o n tr e e s D e ci si o n ta b l e S tr u c tu r e d E n g li s h

2 .2 Sub P ro c e ss 2 .1 .2 Sub - Sub P ro c e ss

3 P ro c e ss M an

2 .3 Sub P ro c e ss

T h e r e m u s t b e c o n s is te n c b e tw e e n le v e ls , w ith a ll th e a ta a p p e a r in g o n th e h ig h e r le v e l D F D . If a a ta s to r e is u s e o n l fo r o n e p r o c e s s it is p la c e w ith th a t p r o c e s s . u ts i e e n titie s a r e a lw a y s s h o w n o u ts i e th e b o u n a r y o f a lo w e r le v e l D F D p r o c e s s , e v e n if th e y o n ly c o m m u n ic a te w ith th a t o n e p r o c e s s .

Data Flow Diagram Donts

1. 2. 3. 4. 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!

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

4. Leave Things Unlabeled Corollary: Labels Should Have Meaning

Data Flow Diagram Donts

data store
5. Miracle data source

data store

5. Black hole data source

Data Flow Diagram Donts

6. Data Flows Unassociated With a Process
data store to entity or reverse entity to entity

data store to data store

Entity Relationship Diagrams

Basic Elements and Rules

Introduction to Entity-Relationship (E-R) Modeling

Notation uses three main constructs
Data entities Relationships Attributes

Entity-Relationship (E-R) Diagram

A detailed, logical representation of the entities, associations and data elements for an organization or business

Entity-Relationship (E-R) Modeling

Key Terms

Entity
A person, place, object, event or concept in the user environment about which the organization wishes to maintain data Represented by a rectangle in E-R diagrams An entity is a business object that represents a group, or category of data. 1 Do we know a similar concept?

Entity-Relationship (E-R) Modeling

Key Terms

Entity Type
A collection of entities that share common properties or characteristics

Attribute
A named property or characteristic of an entity that is of interest to an organization An attribute is a sub-group of information within an entity. 1 Do we know a similar concept?

Entity-Relationship (E-R) Modeling

Key Terms

Candidate keys and identifiers

Each entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same type Candidate key
Attribute (or combination of attributes) that uniquely identifies each instance of an entity type

Examples
Identify a few entity types, instances, attributes and candidate keys for:
DePaul Campus Connect Registration System Illinois Bureau of Motor Vehicles System Amazon.com Product Information System

Depicting Entities and Attributes

Draw a portion of the ERD for each of these systems:

 DePaul Campus Connect Registration System  Illinois Bureau of Motor Vehicles System  Amazon.com Product Information System

Conceptual Data Modeling and the E-R Diagram Goal

Capture as much of the meaning of the data as possible If you know the rules of normalization, referential integrity, foreign keys, etc., this is good but not as important now. It is much more important to get the organizational data model correct, i.e. to understand the actual data requirements for the organization.

Result
A better design that is scalable and easier to maintain

Entity-Relationship (E-R) Modeling

Key Terms

Identifier
A candidate key that has been selected as the unique identifying characteristic for an entity type Selection rules for an identifier 1. Choose a candidate key that will not change its value 2. Choose a candidate key that will never be null 3. Avoid using intelligent keys 4. Consider substituting single value surrogate keys for large composite keys

Entity-Relationship (E-R) Modeling

Key Terms

Relationship
An association between the instances of one or more entity types that is of interest to the organization Association indicates that an event has occurred or that there is a natural link between entity types Relationships are always labeled with verb phrases

Cardinality
The number of instances of entity B that can be associated with each instance of entity A Minimum Cardinality
The minimum number of instances of entity B that may be associated with each instance of entity A This is also called modality .

Maximum Cardinality
The maximum number of instances of entity B that may be associated with each instance of entity A

Naming and Defining Relationships

Relationship name is a verb phrase Avoid vague names Guidelines for defining relationships
Definition explains what action is being taken and why it is important Give examples to clarify the action Optional participation should be explained Explain reasons for any explicit maximum cardinality

Naming and Defining Relationships

Guidelines for defining relationships
Explain any restrictions on participation in the relationship Explain extent of the history that is kept in the relationship Explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance

Entity Relationship Models

Mandatory Relationships Optional Relationships Many-to-Many Relationships One-to-Many Relationships One-to-One Relationships Recursive Relationships

Mandatory, Many-to-Many

INSTRUCTOR

STUDENT

INSTRUCTOR

STUDENT

Optional, Many-to-Many

DEPARTMENT

STUDENT

DEPARTMENT

STUDENT

Optional/Mandatory, Many-to-Many

INSTRUCTOR

SKILL

INSTRUCTOR

SKILL

Optional/Mandatory, One-to-Many

PRODUCT

VENDOR

PRODUCT

VENDOR

Mandatory, One-to-One

AUTOMOBILE

ENGINE

AUTOMOBILE

ENGINE

Recursive
EMPLOYEE supervises

is supervised by

Resolving Many-to-Many Relationships

Many-to-many relationships should be avoided. We can resolve a many-to-many relationship by dividing it into two one-tomany relationships.

Resolving Many-to-Many Relationships

SALES ORDERS

INV. ITEMS

SALES ORDERS

ORDER ITEMS

INV. ITEMS

Example (ER Diagram)

CUSTOMERS CLERKS

SALES ORDERS

ORDER ITEMS

INV. ITEMS

Another example :Entity Relationship Diagram (ERD)

Q&A