SYSTEM DESIGN At the end of this lesson you should be able to; Draw flowcharts Draw Function Decomposition (FD) Diagrams Draw Context Diagrams

SYSTEM DESIGNAt the end of this lesson you should be able to;

Draw flowchartsDraw Function Decomposition (FD) DiagramsDraw Context DiagramsRepresent physical systems through Data Flow

Diagrams (DFD)Prepare Decision TablesDisplay Decision TreesPrepare Data DictionariesDraw Entity Relation Diagrams (ERDs)

Process

A process is a business activity which when executed produces certain outputs from given inputs.

The function(s) performed by a process may be complex, with multiple inputs, outputs and users. The entire application itself is a process.

Successive decomposition is used into sub processes to reveal greater details of the processing

Key Definitions

A process model is a formal way of representing how a business operates

Logical process models describe processes without suggesting how they are conducted

Physical models include information about how the processes are implemented

Data flow diagramming shows business processes and the data that flows between them

CONTEXT DIAGRAM

Shows the context into which the business process fits

Shows the overall business process as just one/ single process

Shows all the outside entities that receive information from or contribute information to the system (external interfaces)

This is the starting point; also called Fundamental System Model or Level 0 DFD

Input 1Output 1

Context Diagram…

FLOWCHARTS

It is a diagrammatic/picture representation of the various steps involved in designing a system.

It consists of a set of ‘flowchart symbols’ connected by arrows. Each symbol contains information about what must be done at that point & the arrow shows the ‘flow of execution’ of the algorithm.

Flowcharts…

The purpose of using flowcharts is to graphically present the logical flow of data in the system and define major phases of processing along with the various media to be used.

Some of the boxes which are used in flowcharts are:

Flowcharts…

Flowcharts are of three types:System flowchartsRun flowchartsProgram flowcharts

(a) System Flowcharts

System flowchart describes the data flow for a data processing system.

It provides a logical diagram of how the system operates, represents the flow of documents, the operations performed in data processing system and also reflects the relationship between inputs, processing and outputs.

(a) System Flowcharts…

The features of system flowcharts are:the sources from which data is generated

and device used for this purposevarious processing steps involvedthe intermediate and final output

prepared the devices used for their storage

System Flow ChartThe Figure is a sample of system flowchart for the following algorithm:Prompt the student for the Tuition Fees Paid (TFP).Store the Amount paidSet Tuition Balance to Tuition Fees (TF) minus TFPPrint the Tuition Fees BalanceStop

(b) Run flowcharts

Run flowcharts are used to represent the logical relationship of computer routines along with inputs, master files, transaction files and outputs.

Run flowcharts…

(c) Program flowcharts

A program flowchart represents, in detail, the various steps (logical/ arithmetic operations, algorithms etc) to be performed within the system for transforming the input into output.

These flowcharts constitute an important component of documentation for an application.

Program flowcharts…The Figure represents a program flowchart for finding the sum of first five numbers ( i.e. 1,2,3,4,5).

FUNCTION DECOMPOSITION/ HIERARCHY CHART

Decomposition splits work of a task into subtasks; subtasks together make-up the parent task. It should have characteristics of;

Balanced decomposition: sub-tasks are roughly equal in complexity

Top-down decomposition: gives hierarchical structure

Function Decomposition…

Decomposition should be divided into 2 or more but not more than 5

A high cohesion (high independence) and minimum coupling (minimum interdependence) are fundamental criteria

Elementary process is the smallest unit of activity meaningful to end user (it sees and leaves data in consistent state)

Function Decomposition…

Continue decomposition until elementary processes are identified

Process decomposition diagram is;A tree structureElementary processes are leaf nodesData is not shown

Decomposition rules

Each process in a decomposition diagram is either a parent process or a child process of a parent or both

A parent must have two or more children. A single child does not make sense because that would not reveal any additional detail about the system

In most decomposition diagramming standards, a child may have only one parent

Finally a child of one parent may be a parent of its own children

Decomposition rules…

System

Function 1

Activity 1.1

Task 1.1.1

Task 1.1.2

Activity 1.2

Function 2

Activity 2.1

Activity 2.2

Task 2.2.1

Task 2.2.2

Function 3

FD Diagrams: Examples

Student Registration

Register for backlog courses

Register for prescribed

courses

Approve registration

FD Diagrams: Examples

Inventory Control

Predict demand

Focus stock levels

Check inventory

Determine quantities

reorder

Function Decomposition …

Use proper naming of processesBusiness functions are named as nouns (marketing,

Inventory control, etc)Process name consists of an active verb and an object

(accept order, calculate interest, …)Avoid long names (sentences containing and, if, then,

etc. indicate non-cohesive complex tasks)Real world is a good reference for selecting proper

names; organizational units are organized functionally and each unit has a well-defined task

DATA FLOW DIAGRAM (DFD)

DFDs are the most commonly used way of documenting the process of current & required systems. They are a pictorial way of showing the flow of data into, around & out of a system.

It is a graphical representation of a system’s data and how the processes transform the data.

They can describe processing at physical as well as logical levels

Its shows flow of data and not flow of control

Data Flow Diagram (DFD)…

DFDs facilitate top-down developmentThey permit outlining of preferences and scopeUnlike flowcharts, DFDs do not give detailed

descriptions of modules but graphically describe a system’s data and how the data interact with the system.

FDD may be done before DFD or one may prepare DFDs directly

It has more contents than FDDs

Components of DFD

DFDs are constructed using four major components;

external entriesdata storesprocesses anddata flows

Components of DFD…

External Entities: represent the source of data as input to the system and also the destination of system data. External entities can be called data stores out side the system. Represented by squares.

 Data Stores: represent stores of data within the system. Examples, computer files or databases. Represented by an open-ended box – data at rest or a temporary repository of data.

Components of DFD…

 Process: represents activities in which data is manipulated by being stored or retrieved or transferred in some way; transforms the input data into output data. Represented by Circles/ovals.

 Data Flows: represents the movement of data from one component to the other. An arrow identifies data flow/data in motion. Data flows are generally shown as one-way only. Data Flows between external entities are shown as dotted lines.

Steps in Building DFDs

Build the context diagramCreate DFD fragments for each scenarioOrganize DFD fragments into level 0Decompose level 0 DFDs as neededValidate DFDs with user

DFD Fragment Tips

All process names must be verb phrasesMaintain organization’s viewpoint in naming

processesLayouts often place

inputs from the leftprocesses in the centeroutputs to the rightstores beneath the processes

A DFD Fragment Example

InputOutput

Process

Storage

A Second DFD Fragment Example

Logical DFD

It focuses on what work or action is being performed.

It doesn’t show who or what is performing the work.

E.g. in the next figure orders are placed, received, the location of ordered parts is determined and delivery notes are dispatched along with the order.

Logical DFD

Physical DFD

Physical DFD shows the actual devices that perform the functions. It shows how things happen, or the physical components. E.g. there is an "order processing clerk", an "entry into computer file" process and a "run locate program" process to locate the parts ordered.

Shows implementation detailsNames and locations of places/peopleWays of storing data (like card indexes)Tasks as performed.

Physical DFD

Physical DFD…

Useful for describing existing system to validate it with users

Needs to be converted into logical DFD after validation from users

Typical processes that appear in physical DFDs are methods of data entry, specific data transfer or processing methods.

Qualities of a good DFD

A good DFD should;have no data flows that split up into a number

of other data flowshave no crossing linesnot include flowchart loops of control

elementsnot include data flows that act as signals to

activate processes.

Difference between flowcharts & DFD

The program flowchart describes boxes that describe computations, decisions, interactions & loops while data flow diagrams should not include control elements.

Example: Air line reservation

Reading a DFD

Process Refinement/Levelling Key Definitions

Decomposition is the process of modelling the system and its components in increasing levels of detail.

Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.

Process Refinement/Levelling

Decompose a process into sub processes– May reveal more data stores, external interfaces– Use decimal numbering system: process 1 is

decomposed into 1.1, 1.2, etc.

At each level, understand all data flows and processing; label processes, data stores and data flows (arrows) meaningfully.

Refinement …

Continue decomposition and stop when control flow (conditional branches, loops) surfaces. Refine until processes are well understood.

DFDs do not show control flowDFDs do not show initializations (such as

initial file creation), but show processes running in a steady state

Refinement …

DFDs only show exceptions/errors having specific business rules to deal with them; handling of routine errors is generally not shown.

Processes must be independent of each other (cohesion, coupling principles apply); work of a process depends only on its inputs and not on state of another process

Refinement …

Only needed data should be input, and outputs should be based on data entering the process

Ensure consistency among levels: inputs and outputs at previous level should be present at next level

Refinement …

Level 0 Diagram

Shows all the processes that comprise the overall systemShows how information moves to and from each processAdds data storesGenerally move from top to bottom, left to rightMinimize crossed linesIterate as needed

The DFD is often drawn many times before it is finished, even with very experienced systems analysts

Tips for Level 1 and Below

Sources for inputs and outputs listed at higher level

List source and destination of data flows to processes and stores within each DFD

Depth of DFD depends on overall system complexityTwo processes generally don’t need lower levelMore than seven processes become overly

complex and difficult to read

Level 1 Diagrams

Shows all the processes that comprise a single process on the level 0 diagram

Shows how information moves from and to each of these processes

Shows in more detail the content of higher level process

Level 1 diagrams may not be needed for all level 0 Processes

Level 2 Diagrams

Shows all processes that comprise a single process on the level 1 diagram

Shows how information moves from and to each of these processes

Level 2 diagrams may not be needed for all level 1 processes

Correctly numbering each process helps the user understand where the process fits into the overall system

Data Flow Splits and Joins

A data flow split shows where a flow is broken into its component parts for use in separate processes

Data flow splits need not be mutually exclusive nor use all the data from the parent flow

As we move to lower levels we become more precise about the data flows

A data flow join shows where components are merged to describe a more comprehensive flow

Alternative Data Flows

Where a process can produce different data given different conditions

We show both data flows and use the process description to explain why they are alternatives

Tip -- alternative data flows often accompany processes with IF statements

Showing Boundaries

More DFD Examples: Payroll

Example 2: Book Supplier

Imagine books supplied to customers whereby no stock is maintained and the books are sourced directly from the publishers

Level 0 DFD/Context diagram

Book Supplier: Refinement 1

Book supplier: Exploding Process 2

Book Supplier : homework

Refinement 1 needs to be extended for handling paymentsExtend for : Payments from customers

Create ‘a/c receivable’ for books sentUpdate receivable when payments receivedCredit rating will need to be adjusted periodically

Extend for : Payments to publishersCreate ‘a/c payable’ when invoices receivedCheck invoices with books actually receivedMake payments periodically as per payment terms (within

fixed days; incentives for early payment, etc.)

Validating the DFD

Syntax errors; Assure correct DFD structureSemantics errors; Assure accuracy of DFD

relative to actual/desired business processesUser walkthroughsRole-play processesExamine lowest level DFDsExamine names carefully

Summary

The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes and data flows.

Use cases record the input, transformation, and output of business processes.

Eliciting scenario descriptions and modelling business processes are critically important skills for the systems analyst to master.

DECISION TABLES AND DECISION TREES

Decision tables and trees were developed long before the widespread use of computers. They not only isolate many conditions and possible actions but they help ensure that nothing has been overlooked.

DECISION TABLES

The decision table is a chart with four sections listing all the logical conditions and actions. In addition the top section allows space for title, date, author, system and comment

Five sections of a decision table:

TITLE: Author :Comments :

DATE:System :

Condition Stub Condition Entry

Action Stub Action Entry

Five sections of a decision table…

The condition stub contains a list of all the necessary tests in a decision table.

The action stub is where one may note all the processes desired in a given module. It contains a list of all the processes involved in a decision table.

Five sections of a decision table…

The condition entry contains a list of all possible permutations of yes and no responses related to the condition stub arranged as a vertical column called rules (numbered 1,2,3 etc). We can determine the rules in a decision table by the formula:Number of rules = 2^N = 2N where N represents the

number of conditions and ^ means exponentiation. Thus a decision table with four conditions has 16 (24 = 2 x 2 x 2 x 2 = 16) rules. One with six conditions has 64 rules and eight conditions yield 256 rules etc.

Five sections of a decision table…

The action entry; X’s or dots indicate whether an action should occur as a consequence of the yes/no entries under condition entry. X’s indicate action; dots indicate no action.

Example of book order

Let us consider the following example of book order

If order is from book storeAnd if order is for 6 copies

Then discount is 25%

Else (if order is for less then 6 copies)No discount is allowed

Else (if order is from libraries)

If order is for 50 copies or more

Then discount is 15%

Else if order is for 20 to 49 copiesThen discount is 10%

Else if order is for 6 to 19 copiesThen discount is 5%

Else (order is for less then 6 copies)No discount is allowed

Decision Table for above process

DECISION TREE

The decision tree defines the conditions as a sequence of left to right tests. A decision tree helps to show the paths that are possible in a design following an action or decision by the user.

It turns a decision table into a diagram. This tool is read from left to right, decision results in a fork, and all branches end with an outcome.

Illustration of the concept of decision tree

The figure illustrates the decision tree for the book order decision table seen earlier.

DATA DICTIONARY/ METADATA REPOSITORY

It is a centralized repository of information about data such as meaning, relationships to other data, origin, usage, and format.

It is a separate set of tables that describes the application tables. The Data Dictionary contains such information as column names, types, and sizes, titles, captions, primary keys, foreign keys, and hints to the user interface about how to display the field.

Simple Data DictionaryEntity: Student

Field Name Data Type Key Description

StudName Text Student’s Name

Reg No Text Primary Key Student’s Reg number

Prog ID Text Foreign Key Program Id number

Year Look up wizard Year of study

Gender Lookup Wizard Student’s gender

DOB Date/Time Date of birth

Pic OLE Object Student’s passport size photograph

Tuition Number Tuition fees paid

ENTITY RELATIONSHIP DIAGRAMS (ERD) /MODEL (ERM)

Illustrate the logical structure of databases.It is a specialized graphic that illustrates

the relationships between entities in a database in a top-down fashion.

The models are used in analysis to describe the data requirements and assumptions in the system from a top-down perspective. They also set the stage for the design of databases later on in the SDLC.

Entity-Relationship Diagrams…

There are three basic elements in ER models: Entities - "things" about which information is sought.Attributes – data collected about the entities.Relationships - provide the structure needed to draw

information from multiple entities.

They often use symbols to represent three different types of information. Boxes - represent entities. Ovals - represent attributes.Diamonds - represent relationships

Developing an ERD

Developing an ERD requires an understanding of the system and its components. Use the example below;

Consider a hospital: Patients are treated in a single ward by the doctors assigned to them. Usually each patient will be assigned a single doctor, but in rare cases they will have two.

Healthcare assistants also attend to the patients, a number of these are associated with each ward. 

Initially the system will be concerned solely with drug treatment. Each patient is required to take a variety of drugs a certain number of times per day and for varying lengths of time.

Developing an ERD…

The system must record details concerning patient treatment and staff payment.

Some staff are paid part time and doctors and care assistants work varying amounts of overtime at varying rates (subject to grade).

The system will also need to track what treatments are required for which patients and when and it should be capable of calculating the cost of treatment per week for each patient (though it is currently unclear to what use this information will be put). 

How do we start an ERD?

1. Define Entities: these are usually nouns used in descriptions of the system, in the discussion of business rules, or in documentation; identified in the narrative (see highlighted items above).

2. Define Relationships: these are usually verbs used in descriptions of the system or in discussion of the business rules (entity _ entity); identified in the narrative (see highlighted items above).

How do we start an ERD?

3. Add attributes to the relations; these are determined by the queries and may also suggest new entities, e.g. grade; or they may suggest the need for keys or identifiers.

What questions can we ask?a. Which doctors work in which wards?

b. How much will be spent in a ward in a given week?

c. How much will a patient cost to treat?

d. How much does a doctor cost per week?

e. Which assistants can a patient expect to see?

f. Which drugs are being used?

How do we start an ERD?

4. Add cardinality to the relations. Many-to-Many must be resolved to two one-to-

manys with an additional entityUsually automatically happens. Sometimes involves introduction of a link entity

(which will be a foreign key) Examples: Patient-Drug

How do we start an ERD?

5. This flexibility allows us to consider a variety of questions such as:a. Which beds are free?

b. Which assistants work for Dr. X?

c. What is the least expensive prescription?

d. How many doctors are there in the hospital?

e. Which patients are family related?

Symbols used in ERDs

Reading an ERD

It takes some practice reading an ERD, but they can be used with clients to discuss business rules.

Issues brought out by ERD

Many-to-ManysAmbiguitiesEntities and their relationshipsWhat data needs to be storedThe Degree of a relationship

ERD Notations

Entity: an object or concept about which you want to store information.

Weak Entity: an entity that must be defined by a foreign key relationship with another entity as it cannot be uniquely identified by its own attributes alone.

Entity

Weak Entity

ERD Notations…

Key attribute: the unique, distinguishing characteristic of the entity. E.g., an employee's social security number.

Multivalued attribute: can have more than one value. For example, an employee entity can have multiple skill values.

Attribute

Attribute

ERD Notations…

Derived attribute: is based on another attribute. E.g., an employee's monthly salary is based on the employee's annual salary.

Relationships: illustrate how two entities share information in the database structure.

Derived attribute

Relationship

Sample ERDs

Sample ERDs…

Sample ERDs…

Summary

Context Diagram – Shows business process as just a single process

Flow Chart Diagram - represents various steps involved in designing a systemSystem Flowchart - shows dataflow descriptionRun Flowchart – shows routinesProgram Flowchart – shows logical/arithmetic/

algorithm steps

Summary

Function Decomposition Diagram – Splits work into subtasks

Dataflow Diagram – shows flow of data into, around and out of the system to show data transformation

Decision Table – lists possible conditions and actions taken in system development

Summary

Decision Tree – shows path that are possible in a design following an action or decision by the user

Data Dictionary/ Metadata repository – describes application tables

Entity Relationship Diagram – illustrates the logical structure of relationships between entities