1. At the end of this lesson you should be able to;
SYSTEM DESIGN
At the end of this lesson you should be able to;
Draw flowcharts
Draw Function Decomposition (FD) Diagrams
Draw Context Diagrams
Represent physical systems through Data Flow Diagrams (DFD)
Prepare Decision Tables
Display Decision Trees
Prepare Data Dictionaries
Draw Entity Relation Diagrams (ERDs)

2. 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

3. 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

4. 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

5. Context Diagram…
Input 1
Output 1

6. 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.

7. 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:
Algorithm is the process or set of rules to be followed in calculation/processing of a computer

8. Flowcharts… Flowcharts are of three types: System flowcharts
Run flowcharts
Program flowcharts

9. (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.

10. (a) System Flowcharts…
The features of system flowcharts are:
the sources from which data is generated and device used for this purpose
various processing steps involved
the intermediate and final output prepared
the devices used for their storage

11. System Flow Chart
The Figure is a sample of system flowchart for the following algorithm:
Prompt the student for the Tuition Fees Paid (TFP).
Store the Amount paid
Set Tuition Balance to Tuition Fees (TF) minus TFP
Print the Tuition Fees Balance
Stop

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

13. Run flowcharts…

14. (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.

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

16. 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

17. 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)

18. Function Decomposition…
Continue decomposition until elementary processes are identified
Process decomposition diagram is;
A tree structure
Elementary processes are leaf nodes
Data is not shown

19. 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

20. Decomposition rules… System Function 1 Activity 1.1 Task 1.1.1

21. FD Diagrams: Examples Student Registration
Register for backlog courses
Register for prescribed courses
Approve registration

22. Determine quantities reorder
FD Diagrams: Examples
Inventory Control
Predict demand
Focus stock levels
Check inventory
Determine quantities reorder

23. Function Decomposition …
Use proper naming of processes
Business 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

24. 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
Controls describe computations, decisions, interactions & loops

25. Data Flow Diagram (DFD)…
DFDs facilitate top-down development
They permit outlining of preferences and scope
Unlike 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

26. Components of DFD
DFDs are constructed using four major components;
external entries
data stores
processes and
data flows

27. 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.

28. 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.

29. Steps in Building DFDs
Build the context diagram
Create DFD fragments for each scenario
Organize DFD fragments into level 0
Decompose level 0 DFDs as needed
Validate DFDs with user

30. DFD Fragment Tips All process names must be verb phrases
Maintain organization’s viewpoint in naming processes
Layouts often place
inputs from the left
processes in the center
outputs to the right
stores beneath the processes

31. A DFD Fragment Example
Process
Storage
Input
Output

32. A Second DFD Fragment Example

33. 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.

34. Logical DFD

35. 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 details
Names and locations of places/people
Ways of storing data (like card indexes)
Tasks as performed.

36. Physical DFD

37. 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.

38. Qualities of a good DFD A good DFD should;
have no data flows that split up into a number of other data flows
have no crossing lines
not include flowchart loops of control elements
not include data flows that act as signals to activate processes.

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

40. Example: Air line reservation

41. Reading a DFD

42. 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.

43. 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.

44. Refinement …
Continue decomposition and stop when control flow (conditional branches, loops) surfaces. Refine until processes are well understood.
DFDs do not show control flow
DFDs do not show initializations (such as initial file creation), but show processes running in a steady state

45. 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

46. 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

47. Refinement …

48. Level 0 Diagram
Shows all the processes that comprise the overall system
Shows how information moves to and from each process
Adds data stores
Generally move from top to bottom, left to right
Minimize crossed lines
Iterate as needed
The DFD is often drawn many times before it is finished, even with very experienced systems analysts

49. 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 complexity
Two processes generally don’t need lower level
More than seven processes become overly complex and difficult to read

50. 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

51. 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

52. 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

53. 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

54. Showing Boundaries

55. More DFD Examples: Payroll

56. Example 2: Book Supplier
Imagine books supplied to customers whereby no stock is maintained and the books are sourced directly from the publishers

57. Level 0 DFD/Context diagram

58. Book Supplier: Refinement 1

59. Book supplier: Exploding Process 2

60. Book Supplier : homework
Refinement 1 needs to be extended for handling payments
Extend for : Payments from customers
Create ‘a/c receivable’ for books sent
Update receivable when payments received
Credit rating will need to be adjusted periodically
Extend for : Payments to publishers
Create ‘a/c payable’ when invoices received
Check invoices with books actually received
Make payments periodically as per payment terms (within fixed days; incentives for early payment, etc.)

61. Validating the DFD Syntax errors; Assure correct DFD structure
Semantics errors; Assure accuracy of DFD relative to actual/desired business processes
User walkthroughs
Role-play processes
Examine lowest level DFDs
Examine names carefully
Syntax error is a bug within the structure of statements of a computer program
Semantic errors are errors with the meaning of words or sentences

62. 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.

63. 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.

64. 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

65. Five sections of a decision table:
TITLE:  Author : Comments :
DATE: System :
Condition Stub
Condition Entry
Action Stub
Action Entry

66. 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.

67. 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.

68. 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.

69. Let us consider the following example of book order
If order is from book store
And 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 copies
Then discount is 10%
Else if order is for 6 to 19 copies
Then discount is 5%
Else (order is for less then 6 copies)
No discount is allowed

70. Decision Table for above process
The condition entry is read vertically, e.g. If order is from book store (Y against Customer is bookstore condition stub), And if order is for 6 copies (Y against Order size is 6 or more condition stub), Then discount is 25% (X against Allow 25% discount Action stub), the rest in that column are Ns (no) and dots (no action) etc

71. 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.

72. Illustration of the concept of decision tree The figure illustrates the decision tree for the book order decision table seen earlier.

73. 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.
Read more on data dictionaries

74. Simple Data Dictionary Entity: Student
Field Name
Data Type
Key
Description
StudName
Text
Student’s Name
Reg No
Primary Key
Student’s Reg number
Prog ID
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
OLE – Object Linking and Embedding

75. 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.

76. 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

77. 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.
by Professor Harman.

78. 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). 
by Professor Harman.

79. 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).

80. 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?

81. 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 entity
Usually automatically happens.
Sometimes involves introduction of a link entity (which will be a foreign key) Examples: Patient-Drug

82. How do we start an ERD?
5. This flexibility allows us to consider a variety of questions such as:
Which beds are free?
Which assistants work for Dr. X?
What is the least expensive prescription?
How many doctors are there in the hospital?
Which patients are family related?

83. Symbols used in ERDs

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

85. Issues brought out by ERD
Many-to-Manys
Ambiguities
Entities and their relationships
What data needs to be stored
The Degree of a relationship

86. 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

87. 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

88. 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

89. Sample ERDs

90. Sample ERDs…

91. Sample ERDs…

92. Summary
Context Diagram – Shows business process as just a single process
Flow Chart Diagram - represents various steps involved in designing a system
System Flowchart - shows dataflow description
Run Flowchart – shows routines
Program Flowchart – shows logical/arithmetic/ algorithm steps

93. 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

94. 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