Upload
godwin-richard
View
218
Download
0
Tags:
Embed Size (px)
Citation preview
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
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:
(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.
(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
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.
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…
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.
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
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
Example 2: Book Supplier
Imagine books supplied to customers whereby no stock is maintained and the books are sourced directly from the publishers
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 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?
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
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