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)

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

Context Diagram… Input 1 Output 1

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

Flowcharts… Flowcharts are of three types: System flowcharts Run flowcharts Program 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 purpose various processing steps involved the intermediate and final output prepared the devices used for their storage

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

(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 structure Elementary processes are leaf nodes Data 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

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

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

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

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

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

Components of DFD DFDs are constructed using four major components; external entries data stores processes and data 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 diagram Create DFD fragments for each scenario Organize DFD fragments into level 0 Decompose level 0 DFDs as needed Validate DFDs with user

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

A DFD Fragment Example Process Storage Input Output

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 details Names and locations of places/people Ways 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 flows have no crossing lines not include flowchart loops of control elements not 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 flow DFDs 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 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

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

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

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

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.

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

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

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

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

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

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.

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 entity Usually 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: 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?

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-Manys Ambiguities Entities and their relationships What data needs to be stored The 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 system System Flowchart - shows dataflow description Run Flowchart – shows routines Program 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