92
1 Week 10 -System Design IT2005 System Analysis & Design

1 Week 10 -System Design IT2005 System Analysis & Design

Embed Size (px)

Citation preview

Page 1: 1 Week 10 -System Design IT2005 System Analysis & Design

1

Week 10 -System Design

IT2005 System Analysis

& Design

Page 2: 1 Week 10 -System Design IT2005 System Analysis & Design

2

Model

• Model is a presentation of reality. Just a picture is worth a thousand of words,

most system models are pictorial representations of reality.

Page 3: 1 Week 10 -System Design IT2005 System Analysis & Design

3

Modelling MethodsA set of techniques used to implement a Methodology

• Data Flow Diagrams -– A process model– Depict the flow of data through a system and the workperformed by the system

• Entity Relationship Diagrams –– A data model– Depict data in terms of entities and relationships

described by the data– Consists of several notations

• Structure Charts etc.

Page 4: 1 Week 10 -System Design IT2005 System Analysis & Design

Logical and physical data flow design

4

• Logical DFDs-– that illustrate what occurs without showing how

it occurs are known as logical DFDs.

• Physical DFDs-– DFDs that show how things happen, or the

physical components are called physical DFDs

Page 5: 1 Week 10 -System Design IT2005 System Analysis & Design

5

Process Modeling

Is a technique for organizing and documenting the Process Requirements and Design for a system.

• Data Flow Diagram : Popular Process Modeling Technique.

Shows the flow of data through the system and the processing performed by the system.

Page 6: 1 Week 10 -System Design IT2005 System Analysis & Design

6

Data Flow Diagrams

• Systems Analyst (SA)- may first draw Data Flow Diagram- may first draw Document Flow Diagram- Depends on the Methodology

Page 7: 1 Week 10 -System Design IT2005 System Analysis & Design

7

Page 8: 1 Week 10 -System Design IT2005 System Analysis & Design

8

Page 9: 1 Week 10 -System Design IT2005 System Analysis & Design

9

Page 10: 1 Week 10 -System Design IT2005 System Analysis & Design

10

Page 11: 1 Week 10 -System Design IT2005 System Analysis & Design

11

Page 12: 1 Week 10 -System Design IT2005 System Analysis & Design

12

ATI System

Page 13: 1 Week 10 -System Design IT2005 System Analysis & Design

13

Page 14: 1 Week 10 -System Design IT2005 System Analysis & Design

14

4. Data Flows

• Data flow model the passage of data in the system and are represented by lines joining system components.

• Flows of data in the system can take place:– Between two processes– From a data store to a process– From a process to a data store– From entities to a process – From process to a entities

Page 15: 1 Week 10 -System Design IT2005 System Analysis & Design

15

Page 16: 1 Week 10 -System Design IT2005 System Analysis & Design

16

Page 17: 1 Week 10 -System Design IT2005 System Analysis & Design

17

Context diagram

• A common way to begin is to model, the whole system by one process.

• It shows all the external entities that interact with the system and the data flow between these external entities and the system.

Page 18: 1 Week 10 -System Design IT2005 System Analysis & Design

18

Context Diagram

• defines the scope of the system by identifying the system boundary

• contains: – one process (which represents the

entire system)– all sources/sinks (external entities)– data flows linking the process to

the sources and sinks (external entities)

Page 19: 1 Week 10 -System Design IT2005 System Analysis & Design

19

Constructing a Context Diagram

• identify and list sources/sinks (external entities)

• identify and list inputs to and outputs from sources/sinks (external entities)

• create context diagram

Page 20: 1 Week 10 -System Design IT2005 System Analysis & Design

20

Page 21: 1 Week 10 -System Design IT2005 System Analysis & Design

21

Page 22: 1 Week 10 -System Design IT2005 System Analysis & Design

22

Page 23: 1 Week 10 -System Design IT2005 System Analysis & Design

23

Page 24: 1 Week 10 -System Design IT2005 System Analysis & Design

24

Page 25: 1 Week 10 -System Design IT2005 System Analysis & Design

25

Page 26: 1 Week 10 -System Design IT2005 System Analysis & Design

26

Page 27: 1 Week 10 -System Design IT2005 System Analysis & Design

27

Page 28: 1 Week 10 -System Design IT2005 System Analysis & Design

28

Page 29: 1 Week 10 -System Design IT2005 System Analysis & Design

29

Page 30: 1 Week 10 -System Design IT2005 System Analysis & Design

30

Page 31: 1 Week 10 -System Design IT2005 System Analysis & Design

31

Page 32: 1 Week 10 -System Design IT2005 System Analysis & Design

32

Page 33: 1 Week 10 -System Design IT2005 System Analysis & Design

33

Library System

Page 34: 1 Week 10 -System Design IT2005 System Analysis & Design

34

Page 35: 1 Week 10 -System Design IT2005 System Analysis & Design

35

Page 36: 1 Week 10 -System Design IT2005 System Analysis & Design

36

Page 37: 1 Week 10 -System Design IT2005 System Analysis & Design

37

Level-0 Diagram

• describes the overall processing of the system

• show one process for each major processing step or functional requirement

• can draw duplicate sources, sinks and data stores to increase legibility

Page 38: 1 Week 10 -System Design IT2005 System Analysis & Design

38

Drawing a Level-0 Diagram

• list the major data stores• list major business steps• draw a segment for each business

step• assemble into single DFD• re-organize until satisfied• number processes

Page 39: 1 Week 10 -System Design IT2005 System Analysis & Design

39

DFD context level diagram

Page 40: 1 Week 10 -System Design IT2005 System Analysis & Design

40

DFD level 0 diagram

Page 41: 1 Week 10 -System Design IT2005 System Analysis & Design

41

DFD level 1 diagram

Page 42: 1 Week 10 -System Design IT2005 System Analysis & Design

42

Other Questions about Lower level diagrams

1. How deep? (how many levels?)– if the process has only one input or one

output, probably cannot partition further;– can you describe the process in English in

about 1/2 page?

2. How broad? (how many processes on a level?)– 7 ± two is a reasonable– may temporarily place much of the system

on a single diagram then re-draw into separate levels

Page 43: 1 Week 10 -System Design IT2005 System Analysis & Design

43

Quality Guidelines• Completeness– all components included & in project

dictionary• Consistency– between levels: balancing, leveling

• Timing considerations– assume system never starts and never

stops• Iterative nature– revisions are common

• Drawing primitives (lowest level)– when to stop?

Page 44: 1 Week 10 -System Design IT2005 System Analysis & Design

44

Budget monitoring system

Page 45: 1 Week 10 -System Design IT2005 System Analysis & Design

45

Top-level DFD diagram

Page 46: 1 Week 10 -System Design IT2005 System Analysis & Design

46

Expansion of classify expenditure process

Page 47: 1 Week 10 -System Design IT2005 System Analysis & Design

DFD Example: Bus Garage Repairs

• Buses come to a garage for repairs. • A mechanic and helper perform the repair, record

the reason for the repair and record the total cost of all parts used on a Shop Repair Order.

• Information on labor, parts and repair outcome is used for billing by the Accounting Department, parts monitoring by the inventory management computer system and a performance review by the supervisor.

Page 48: 1 Week 10 -System Design IT2005 System Analysis & Design

DFD Example: Bus Garage Repairs (cont’d)

• External Entities: Bus, Mechanic, Helper, Supervisor, Inventory Management System, Accounting Department, etc.

• Key process (“the system”): performing repairs and storing information related to repairs

• Processes: – Record Bus ID and reason for repair– Determine parts needed– Perform repair– Calculate parts extended and total cost– Record labor hours, cost

Page 49: 1 Week 10 -System Design IT2005 System Analysis & Design

DFD Example: Bus Garage Repairs (cont’d)

• Data stores: – Personnel file– Repairs file– Bus master list– Parts list

• Data flows:– Repair order– Bus record– Parts record– Employee timecard– Invoices

Page 50: 1 Week 10 -System Design IT2005 System Analysis & Design

Bus

Mechanic

Helper Bus Repair ProcessSystem

Supervisor

Accounting

Bus Garage Context Diagram

Mechanical problem to be repaired

Labor

Labor

Fixed mechanical problems

Inventory Management

System

Repair summary

List of parts used

Labor, parts cost details

Page 51: 1 Week 10 -System Design IT2005 System Analysis & Design

51

Logical and physical data flow design

• Logical DFDs-– that illustrate what occurs without showing how

it occurs are known as logical DFDs.

• Physical DFDs-– DFDs that show how things happen, or the

physical components are called physical DFDs

Page 52: 1 Week 10 -System Design IT2005 System Analysis & Design

52

What is a good data flow diagram?

• The absence of flowchart structures• protection of data• Good naming conventions

Page 53: 1 Week 10 -System Design IT2005 System Analysis & Design

53

Differences between flowcharts and data flow diagrams

• DFDs are not program flow chats and should not include control elements. A good DFD should;1. Have no data flows that split up into a number of

other data flows.2. Have no crossing lines

Page 54: 1 Week 10 -System Design IT2005 System Analysis & Design

54

3. Not include flowchart loops of control elements

(process “compare” has outgoing data flows that are labeled by the conditions under which a data flow occurs, rather than by the contents of the data flow.)

Control Signals From a process

Loops

Page 55: 1 Week 10 -System Design IT2005 System Analysis & Design

55

4) Not include data flows that act as signals to activate processes

Input signal ( end of month)

Page 56: 1 Week 10 -System Design IT2005 System Analysis & Design

56

Method of describing the process

• Structured English• Decision tree• Decision Table

Page 57: 1 Week 10 -System Design IT2005 System Analysis & Design

SUMMARY OF ER-DIAGRAM NOTATION FOR ER SCHEMAS

Chapter 3-57

Meaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

TOTAL PARTICIPATION OF E2 IN R

CARDINALITY RATIO 1:N FOR E1:E2 IN R

STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R

Symbol

E1 R E2

E1 R E2

R(min,max)E

N

Page 58: 1 Week 10 -System Design IT2005 System Analysis & Design
Page 59: 1 Week 10 -System Design IT2005 System Analysis & Design

Questions

1. What is the different between super key and candidate key

2. Explain the distinctions among the terms primary key, candidate key, and super key.

Page 60: 1 Week 10 -System Design IT2005 System Analysis & Design

answer

• A super key is a set of columns that uniquely identifies a row. A Candidate key would be a MINIMAL set of columns that uniquely identifies a row.

• So essentially a Super key is a Candidate key with extra unnecessary columns in it.

Page 61: 1 Week 10 -System Design IT2005 System Analysis & Design

Draw notation to the followings

• Entity• Attribute• Relationship• Key Attribute• Multivalued attributes• Derived Attribute• Weak Entity• Identifying Relationship

Page 62: 1 Week 10 -System Design IT2005 System Analysis & Design

62

Conceptual Design

Notations

Entity

Relationship

Attribute

Page 63: 1 Week 10 -System Design IT2005 System Analysis & Design

63

Conceptual DesignAttribute

Key Attribute

Multivalued attributes

Derived Attribute

Weak Entity

Identifying Relationship

Page 64: 1 Week 10 -System Design IT2005 System Analysis & Design

64

Explain the term ‘Degree’

Number of participating entity types.• Unary Relationship

– A relationship between the instances of a single entity type

e.g. Person is married to a Person Employee manages Employees

• Binary Relationship– A relationship between the instances of two entity typese.g. An employee works for a department

Employee

manages

Employee DepartmentWorks-for

Page 65: 1 Week 10 -System Design IT2005 System Analysis & Design

65

Degree of Relationship Type

• Ternary Relationship A simultaneous relationship among the instances

of three entity types– Supplier s supplies part p to project j

Part

Project

Supplier Supplies

Page 66: 1 Week 10 -System Design IT2005 System Analysis & Design

66

Explain term ‘Cardinality’

• Cardinality Ratios for Binary Relationships Specify the number of instances of one entity

that can (or must) be associated with each instance of another entity.

The possible cardinality ratios for binary relationship types are– 1:1– 1:N– M:N

Page 67: 1 Week 10 -System Design IT2005 System Analysis & Design

67

Phases of Database Design

Miniworld

Requirements collection and Analysis

Conceptual design

Logical design

Physical Design

Functional Analysis

Application Program design

Data Requirements

Conceptual Schema

Logical (Conceptual) Schema

Internal Schema

Functional Requirements

High-level transaction Specification

Transaction Implementation

Application Programs

DBMS-independent

DBMS-specific

Page 68: 1 Week 10 -System Design IT2005 System Analysis & Design

68

Entity Types

Weak Entity– An entity types whose existence depends on

some other entity

Dependent

Employee

Strong (Regular) Entity– An entity that exists independently of other

entity types

Page 69: 1 Week 10 -System Design IT2005 System Analysis & Design

69

Entity Types

Identifying Relationship– A relationship between a weak entity type and

its owner

Identifying Owner– The entity type on which the weak entity type

dependse.g. Employee is the Owner of Dependent

has

Page 70: 1 Week 10 -System Design IT2005 System Analysis & Design

70

Attributes

• Multi-valued Attribute– An attribute that may take on more than one

value for a given entity instancee.g. Employee Skills, Qualifications

• Composite Attribute– An attribute that can be broken down into

component parts e.g. Address (Street, City, State, Postal Code) Name (First Name, Middle Initials, Last Name)

Page 71: 1 Week 10 -System Design IT2005 System Analysis & Design

71

Key Attribute (Identifier)

• Identifier– An attribute (or combination of attributes) that uniquely

identifiers individual instances of an entity typee.g. Emp No

• Composite Identifier– An identifier that consists of a composite attributee.g. Flight Id (Flight No, Date)

Page 72: 1 Week 10 -System Design IT2005 System Analysis & Design

72

Explain ‘Associative entities’

• The presence of one or more attributes on a relationship suggests that the relationship may be represented as an entity type.

• An associative entity is an entity type that associates the instances of one or more entity types and contains attributes that are relevant to the relationship between those entity instances.

• The associative entity type CERTIFICATE is represented with the diamond relationship symbol enclosed within the entity rectangle.

Page 73: 1 Week 10 -System Design IT2005 System Analysis & Design

73

Attributes on relationships

Employee Course

Emp id Emp Name Date Completed Course id Course Title

Completes

Page 74: 1 Week 10 -System Design IT2005 System Analysis & Design

A university registrar's office maintains data about the following entities: (a) courses, including number, title, credits, syllabus, and prerequisites;(b) Course offerings, including course number, year, semester, section

number, instructor(s), timings, and classroom;(c) students, including student-id, name, and program;(d) instructors, including identification number, name, department, and

title.Further, the enrollment of students in courses and grades awarded to

students in each course they are enrolled for must be appropriately modeled.

Construct an E-R diagram for the registrar’s office. Document all assumptions that you make about the mapping constraints.

Page 75: 1 Week 10 -System Design IT2005 System Analysis & Design
Page 76: 1 Week 10 -System Design IT2005 System Analysis & Design

• Consider a university database for the scheduling of classrooms for final exams.

• This database could be modeled as the single entity set exam, with attributes course-name, section-number, room-number, and time.

• Alternatively, one or more additional entity sets could be modeled, along with relationship sets to replace some of the attributes of the exam entity set, as course with attributes name, department, and c-number

• section with attributes s-number and enrollment, and dependent as a weak entity set on course room with attributes r-number, capacity, and building

• a. Show an E-R diagram illustrating the use of all three additional entity sets listed.

Page 77: 1 Week 10 -System Design IT2005 System Analysis & Design
Page 78: 1 Week 10 -System Design IT2005 System Analysis & Design

University registrar’s tables:

• student (student-id, name, program)• course (courseno, title, syllabus, credits)• course-offering (courseno, secno, year, semester,

time, room)• instructor (instructor-id, name, dept, title)• enrolls (student-id, courseno, secno, semester, year,

grade)• teaches (courseno, secno, semester, year,

instructor-id)

Page 79: 1 Week 10 -System Design IT2005 System Analysis & Design

• Construct an E-R diagram for a car-insurance company whose customers own one or more cars each. Each car has associated with it zero to any number of recorded accidents.

Page 80: 1 Week 10 -System Design IT2005 System Analysis & Design

1 m

0..*

1

Page 81: 1 Week 10 -System Design IT2005 System Analysis & Design

• person (driver-id, name, address)• car (license, year, model)• accident (report-number, date, location)• participated(driver-id, license, report-number,

damage-amount)

Page 82: 1 Week 10 -System Design IT2005 System Analysis & Design

• Construct an E-R diagram for a hospital with a set of patients and a set of medical doctors. Associate with each patient a log of the various tests and examinations conducted.

Page 83: 1 Week 10 -System Design IT2005 System Analysis & Design
Page 84: 1 Week 10 -System Design IT2005 System Analysis & Design

• Hospital tables:• patients (patient-id, name, insurance, date-

admitted, date-checked-out)• doctors (doctor-id, name, specialization)• test (testid, testname, date, time, result)• doctor-patient (patient-id, doctor-id)• test-log (testid, patient-id) performed-by

(testid, doctor-id)

Page 85: 1 Week 10 -System Design IT2005 System Analysis & Design

• Explain the difference between a weak and a strong entity set.

• Answer: A strong entity set has a primary key. All tuples in the set are distinguishable by that key. A weak entity set has no primary key unless attributes of the strong entity set on which it depends are included.

Page 86: 1 Week 10 -System Design IT2005 System Analysis & Design

86

Page 87: 1 Week 10 -System Design IT2005 System Analysis & Design

ER DIAGRAM – Entity Types are:EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Page 88: 1 Week 10 -System Design IT2005 System Analysis & Design

Designing an ER Diagram

Consider the following set of requirements for a University database. Design an ER diagram for this application:

• The university keeps track of each student's name, student number, social security number, current address and phone number, permanent address and phone number, birthdate, sex, class (freshman, graduate), major department, minor department (if any), degree program (B.A., B.S., ... Ph.D.). Some user applications need to refer to the city, state, and zip code of the student's permanent address and to the student's last name. Both social security number and student number are unique for each student. All students will have at least a major department.

• Each department is described by a name, department code, office number, office phone, and college. Both the name and code have unique values for each department.

• Each course has a course name, description, course number, number of credits, level and offering department. The course number is unique for each course.

• Each section has an instructor, semester, year, course, and section number. The section number distinguishes sections of the same course that are taught during the same semester/year; its value is an integer (1, 2, 3, ... up to the number of sections taught during each semester).

• A grade report must be generated for each student that lists the section, letter grade, and numeric grade (0,1,2,3, or 4) for each student and calculates his or her average GPA.

Page 89: 1 Week 10 -System Design IT2005 System Analysis & Design

University ER Diagram

Student

Class

StudentID SSN

Sex

Zip

Degree

City

Birth date

State

Name

Address

Department

DName DCode OfficeNumber

OfficePhone

College

Course

CName

CourseDesc

CNumber

Credits

Section

Instructor Year

SemesterSectionNumber

GPA

Numeric Grade

Letter Grade

Grade_Report

Belong_To

Offer

Minor In

Major In

Page 90: 1 Week 10 -System Design IT2005 System Analysis & Design

90

Structured English

IF credit limit exceededTHEN

IF customer has bad payment historyTHEN refuse creditELSEIF purchase above Rs. 1000/=THEN refuse creditELSE refer to manager

ELSE allow credit

Page 91: 1 Week 10 -System Design IT2005 System Analysis & Design

91

• Structured English used to – Explain the conditions which occurs in a process.– Identify the decisions which makes these conditions occur.– Find alternative actions to be taken

• The process is defined by using three types of statements– Sequence structure– Decision structure– Iteration structure

Page 92: 1 Week 10 -System Design IT2005 System Analysis & Design

92

System design Approaches

• Modern structured design• Information engineering• Prototyping• JAD• RAD• Object-oriented