Systems design

1. What is systems design?
2. What are the objectives and guidelines in designing output?
3. What are the objectives and guidelines in designing input and data-entry procedures?
4. What are the objectives and guidelines in designing user interfaces?
5. What are the objectives in designing data storage?
6. How to use ER diagram for data modeling?

Systems design -- define the “look and feel” of all system outputs, inputs, interfaces, dialogues, and data requirements

· Output design

To deliver the right information to the right people in the right format at the right time

· Input & data entry design

To develop user-friendly interface and process for getting quality data into the information system in a timely and accurate fashion

· Interface/dialogue design

To define the manner (method and sequence) in which humans and computers exchange information

· Data modeling

To represent data in an organization used by a database management system

Output design

Objectives	Guidelines
· Purposeful · Meaningful · Adequate · Appropriate distribution · Timely · Appropriate medium (Figure 15.3)	· Consider usage factors before choosing an output technology/medium (pg.478) · Avoid output bias (Figure 15.9) · Consider functional and stylistic attributes in designing printed reports · Keep screen output simple, consistent, easy to navigate, and attractive

Types of output technology/medium

1. Print
2. Screen
3. Audio
4. Microform
5. CD-ROM or DVD
6. Electronic
7. Web-based documents

Usage factors in making output technology decisions

1. Users
2. Number of users
3. Physical destination
4. Purpose
5. Speed
6. Frequency
7. Longevity
8. Legal requirements
9. Costs
10. Environmental requirements

Sources of output bias

1. Sorting
2. Setting limits
3. Misleading graphics

Input design

Objectives	Guidelines
· Effective · Accurate · Ease to use · Consistent · Attractive · Simple	· Input forms should be easy to fill out, purposeful, facilitate accurate completion, and attractive · Screens should be simple, consistent, facilitate navigation, and attractive · Web-forms should use a variety of input methods, provide clear instructions, demonstrate a logical entry sequence, provide a feedback screen, separate a lengthy form into simpler forms on separate pages

Web-form input methods

1. Text-box
2. Check-box
3. Option button
4. Drop-down list
5. Sliders
6. Image maps
7. Message box
8. Command button
9. Tab control dialog box

Data entry design

Objectives

Guidelines

· Effective coding · Efficient data capture · Effective data capture · Effective input validation

Reduce data input volume · Keep codes concise, stable, unique, sortable, simple, uniform, modifiable, and meaningful (Figure 19.11) · Input necessary data only · Do not input data that can be computed/retrieved from the system · Provide default values when appropriate · Allow look up of value Reduce data input error Validate input transactions to avoid submitting wrong or unauthorized data and to prevent unauthorized action Validate input data to prevent missing data, incorrect field length, type, range, value, cross-reference, un-match data.

Types of codes

Purpose	Codes	Example
Tracking information	· Sequence codes (Figure 19.2)	· Order number at Atlanta Bread
	· Alphabetic derivation codes (Figure 19.3)	· U-connect account name
Classifying information	· Classification codes (Figure 19.4)	· Letter grade
	· Block sequence codes (Figure 19.6)	· IP address
Concealing information	· Cipher codes (Figure 19.7)	· Morse code
Revealing information	· Significant-digit subset codes (Figure 19.8)	· Course number system at UK
	· Mnemonic codes (Figure 19.9)	· Acronyms
Requesting action	· Function codes (Figure 19.10)	· Menu choices

Date-entry methods

1. Keyboards
2. Optical character recognition
3. Magnetic ink character recognition
4. Mark-sense forms
5. Bar codes
6. Intelligent terminals

Validation tests

1. Data type/class test – data are of proper type

2. Combination test – data from two or more fields are consistent or reasonable when considered together

3. Expectancy test – data are anticipated, e.g., in some predetermined sequence

4. Existence test – data must be input, e.g., a required field

5. Range test – data are within proper range of values

6. Domain test – data are of proper situation or come from set of standard values

7. Size test – data are of proper length

8. Validity test – data must have certain values, e.g., referential integrity

9. Batch control test – use record count/hash totals to verify batch input

10. Check digit test – add an extra digit to a numeric field to verify its accuracy (Figure 19.19)

User interface design

Objectives	Guidelines
· Task matching · Efficient · Feedback provision · Productivity improvement	Minimize user frustration Communicate Minimal user action Standard operation and consistency Context-sensitive help Provide feedback on Acknowledgement Error/warning Status Reassurance Availability of further assistance

Types of user interface

1. Natural language, e.g., www.askjeeves.com (search engine)
2. Question-and-answer, e.g., dialog box
3. Menu, e.g., Menu bar in Access
4. Form-fill, e.g., registration form as www.yahoo.com members
5. Command-language, e.g., DOS operating systems
6. Graphical, e.g., Icon bar in Access
7. Touch-screen, e.g., ATM machine

Database design

Objectives	Guidelines
· Purposeful information retrieval · Efficient data storage · Data availability · Efficient data update and retrieval · Data integrity	· Use ER diagram for data modeling · All tables are normalized

Data integrity

• Entity integrity: the primary key of a table cannot have a null value
• Referential integrity: all foreign keys in a child table must have a matching record in the parent table
• Domain integrity: table entries must be of the same type, limit, range and other validation checks.

Basic constructs of the E-R model

Concept	Definition	Examples
Entity	A person, place, object, event or concept	Employee, department, building, sale, account
Relationship	An entity that serves to interconnect two or more entity types	Assignment (Employee-Department)
Attribute	A property or characteristic of an entity/relationship type	Employee_name, department_location, sale_date

Types of relationships (Figure 17.5)

1. one-to-one, e.g, STUDENT-Assign-PARKING
2. one-to-many, e.g., DEPARTMENT-Offer-COURSE
3. many-to-many, e.g., STUDENT-register-COURSE

E-R models à relational models

Elements	Relational model
Entity	A table
Attribute	A column of the table
One to one relationship	· One table is created for each entity · The key of either one of the tables is placed as the foreign key in the other table
One to many relationship	· One table is created for each entity · The key of the table on the "one" side of the relationship (parent) is placed as the foreign key in the table representing the "many" side of the relationship (child)
Many to many relationship	· One table is created for each entity · One table is created for the relationship itself

Two conditions for tables to be normalized to the third degree:

1. All nonkey attributes are dependent on the whole key

2. All nonkey attributes are dependent on nothing but the key

Process modeling vs data modeling

Process modeling

• Views a system from an input-process-output perspective
• DFD is the technique used to represent the hierarchical decomposition of the real-world system under investigation.
• DFD achieves top-down partitioning by decomposing the system first into subsystems, then into processes performed within a subsystem.

Data modeling

• Views a system from a reality-metadata-date modeling perspective (Figure 17.4)
• ERD is used to capture the meaning of data from the users’ point of view (reality level)
• Relational data model is used to represent data in the form of table (metadata level)

Finding:

Process modeling is easier to learn and apply than data modeling