Pertemuan 12 Systems Analysis and Design of a Business Event Driven System Matakuliah: M0034...

Pertemuan 12 Systems Analysis and Design of a Business Event Driven System

Matakuliah : M0034 /Informasi dan Proses Bisnis Tahun : 2005

Versi : 01/05

Learning Outcomes

Pada akhir pertemuan ini, diharapkan mahasiswa

akan mampu :

• Menjelaskan tahapan dalam menganalisa dan merancang aplikasi TI

Outline Materi

• Model-model tahapan Analisis & Perancangan Sistem Informasi– Data Flow Diagrams– Kamus Data– Logical Models– Data Modeling

Lanjutan Dari Lanjutan Dari

Pertemuan 11Pertemuan 11

The McGraw-Hill Companies, Inc., 2000

Irwin/McGraw-Hill

STEP I-B: Systems Analysis - Structuring Systems Requirements Using Process Modeling

Some analysis methods create several versions of data flow diagrams, including context data flow diagrams, data flow diagrams of the current physical system, data flow

diagrams of the current logical system, and data flow diagrams of the proposed logical system.

Often, each data flow diagram includes a thorough description of each data flow.


Irwin/McGraw-Hill

Exhibit 4-4Christopher Inc., Context Diagram

OSales /

collectionsystem

Christopher Inc. needs a system that enables communication with customers several times during

the process (e.g., customers send in order data as well as payment data, and Christopher Inc. sends back shipping, sales, billing, and

payment data).

Customers

Order

Shipping/Bill

Payment

Decision Makers

DesiredInformation

Christopher Inc. needs a system that allows them to send shipping data to their

carriers and receive shipment confirmations

from their carriers.

Carriers

Shipping Data

Confirmation

Finally, Christopher Inc.’s systems should allow

access by internal agents (such as management and other decision-makers) to

critical data and information.

the circle represents computer processing

A context diagram shows the sources and destinations of the data that are outside the boundaries or scope of the system being analyzed. You do not show the data stores and data flows within the boundaries of the system.


Irwin/McGraw-Hill

Exhibit 4-5 Christopher, Inc. Level 0 Data Flow Diagram

1.0 Processcustomer

orders

2.0 Processshipments

tocustomers

3.0 Process payments from

customers

CustomersDecisionmakers

Orders

Bill

Payment

DesiredinformationShipping request data

Payments duedata

Desired

informati

on

Desiredinformation


Irwin/McGraw-Hill

Exhibit 4-6 Christopher Inc., Level 1 Data Flow Diagram

1.1 Approve

and record customer order data

Customer order data

1.2 Generate

information about orders

Order Approved Order

Order data

ShippingRequestData

Desired information


Irwin/McGraw-Hill

Context Dictionary Some analysts like to add more detail to context and

other data flow diagrams, by providing the data elements that comprise the data flows on the diagram. We will refer to these data flow details as the context dictionary. Each entry in the context dictionary is separated from its definition by an equal sign (=) and is defined using the following set of symbols:

– + To connect elements of the definition

– {} To identify repeating elements of the definition


Irwin/McGraw-Hill

Sample Context Dictionary Entries Sales-Invoice = Invoice # + Sale-Date + Register # + Customer

Name + Salesperson Name + {Merchandise Name + Qty-Sold + Price + Item-Total} + Sale-Total

Customer-Profile = Report-Date + Name + State + Birth date + Telephone + {Merchandise Description + Qty-Sold}

Product-Sales = Report-Date + {Merchandise # + Merchandise Description + Qty-Sold + %Margin + $ Contribution}

Accounting-Revenue = Report-Date + Reporting-Period + Revenue for Reporting-Period

Sales-by-Salesperson = Report-Date + {Salesperson Name + {Merchandise-Description + Qty-Sold + $ Contribution} + Total Sales + Total Contribution


Irwin/McGraw-Hill

When you are creating data flow diagrams or work-flows for a business process, how do you know how many recording, maintaining, and reporting processes you need for an IT application?

You can use your REAL model and the context diagram as a guide.

•context diagram•inflows and outflows to

Record event dataMaintain resource, agent, location dataReport source documents, queries, reports

You need one recording process in your IT application for each business event object in the application’s REAL model

You need one recording process in your IT application for each business event object in the application’s REAL modelYou need one maintenance process in your IT application for

each resource, agent, and location object in the application’s REAL model

You need one maintenance process in your IT application for each resource, agent, and location object in the application’s REAL model

The number of reporting processes required for an application is a function of the number of views required by information customers. You will need one reporting process for each required output view. To help you plan, determine how many of the following three types of reporting output views your information customers need:- Source documents:

printed or electronic transmission of event data documentation- Preformated reports:

reports that are regularly used by information customers-Ad hoc reports:

reports that information customers design and request to provide a new view or a view that is rarely used

The number of reporting processes required for an application is a function of the number of views required by information customers. You will need one reporting process for each required output view. To help you plan, determine how many of the following three types of reporting output views your information customers need:- Source documents:

printed or electronic transmission of event data documentation- Preformated reports:

reports that are regularly used by information customers-Ad hoc reports:

reports that information customers design and request to provide a new view or a view that is rarely used

Additional Prototyping Steps


Irwin/McGraw-Hill

McKell's Retail Sale Store Case Checkpoint

Using our retail sale example, the IT application would have:•One recording process (i.e., Record Sale Data) to record the one event of interest

Four maintenance processes •Maintain Customer Data, •Maintain Merchandise Data, •Maintain Salesperson Data, and •Maintain Register Datato keep our resource, agent, and location data up to date and valid

Reporting processes to handle key management functions: • Sales Invoice - the customer's bill; • Customer Profile - a report that provides information about customers and their purchasing habits; • Product Sales - a report that provides the margin and contribution for each merchandise items type sold; • Accounting Revenue - a report that provides a calculation of sales revenue for a specific period; • Sales by Salesperson - a report that details the merchandise and contribution to sales revenue for each salesperson)


Irwin/McGraw-Hill

Step 1-C Structuring Systems Requirements Using Logical Models

After completing data flow diagrams that graphically show the flow of data to fulfill the system requirements, many analysts use logic models to represent the logic of the information processes denoted in the data flow diagram(s).

Their objective is to produce structured descriptions and diagrams that enumerate the logic contained in each process denoted in the data flow diagram(s).

Techniques used during this step include structured English, decision tables, decision trees, and state-transition diagrams or tables.

We will overview just one of these techniques: Structured English.


Irwin/McGraw-Hill

Structured English Structured English is used to plan and document the steps of a

computer instruction set (a program) without using a programming language. Structured English is used to define the detailed logic of each information process (Exhibit 4-7).

Structured English focuses on conciseness and clarity to document the essence of an information process and eliminates: Adjectives. Adverbs. Compound sentences. Non-imperative expressions. All but a limited set of conditional and logic structures. Most punctuation. Footnote type details.


Irwin/McGraw-Hill

Exhibit 4-7 Structured English Example

ProcessInput

Output

DataFor each Customer-Order do the following:1. Search for Customer-Name

if foundConfirm customer info with customerif not foundEnter customer data

2. Check for availability of inventory requestedif availableConfirm ship-to-informationif not availableInform customer with Order-Confirmation

3. Provide customer with Order-Confirmation4. Send notification to packing agents


Irwin/McGraw-Hill

Business Event Risks In addition to including the logic for completing a desired task,

this step provides an opportunity for thinking about ways information technology can be used to help reduce business and information risks An operating event occurring at the wrong time or sequence. An operating event occurring without proper authorization. An operating event involving the wrong internal agent. An operating event involving the wrong external agent. An operating event involving the wrong resource. An operating event involving the resource amount. An operating event occurring at the wrong location.


Irwin/McGraw-Hill

Information Event Risks Information event risks include the risks associated with

incomplete, inaccurate, or unauthorized recording, maintaining, and reporting information activities: Recording risks - Recording risks include recording incomplete,

inaccurate, or invalid data about an operating event. Incomplete data results in not recording all of the relevant characteristics about an operating event in the data stores. Inaccuracies arise from recording data that does not accurately represent the event. Invalid refers to data that are recorded about a fabricated event.

Maintaining risks - Maintaining risks are essentially the same as recording risks. The only difference is that the data maintained relates to resources, agents, and locations rather than operating events.

Reporting risks - Reporting risks include data that are improperly classified, improperly summarized, provided to unauthorized parties, or not provided in a timely manner.


Irwin/McGraw-Hill

STEP I-D: Systems Analysis: Structuring Systems Requirements Using Conceptual Data Modeling

To focus on the specific data you want to capture to describe reality and generate needed outputs we use a conceptual data model.

Conceptual data models represent the entities or objects you want to collect data about, and rules about the meaning and interrelationships among these data objects.

To complete this step, most analysts use one of two modeling techniques: Entity-Relationship (E-R) or Object Oriented (OO).


Irwin/McGraw-Hill

EntityName

RelationshipName

ERD Data Entity

anything, real or abstract, about which we want to store data.

synonyms include entity type, entity class or object

Data relationship a natural association that exists between

one or more entities business activities or events that link one or

more entities


Irwin/McGraw-Hill

Example

CustomerPlaces/ or

Is Placed By

Orders

Contains orIs Contained By

Supplies


Irwin/McGraw-Hill

Entities

AGENTS Entities that describe roles played in a system. They

usually represent people or organizations. ACCOUNT, AGENCY, ANIMAL, APPLICANT,

BORROWER, CHILD, CLASS, CLIENT, CONTRACTOR, CREDITOR, DEPARTMENT, EMPLOYEE, EMPLOYER, INSTRUCTOR, MANAGER, OFFICE, SALESPERSON, SUPPLIER, TEAM, VENDOR


Irwin/McGraw-Hill

Entities

RESOURCES Entities that describe tangible things. Most tangible

things are easy to identify because you can see them. BOOK, CHEMICAL, COURSE, DISK, EQUIPMENT,

MACHINE, MATERIAL, METAL ,PART, PRODUCT, PROGRAM, SERVICE, SUBSTANCE, VEHICLE


Irwin/McGraw-Hill

Entities

EVENTS Most events are easy to identify because the business

records data on forms or files. Events are characterized by the fact that they happen or

have duration AGREEMENT, APPLICATION, APPOINTMENT, ASSIGNMENT,

BACKORDER, BUDGET, CLAIM, CONTRACT, DEPOSIT, DISBURSEMENT, FORECAST, INVOICE, JOB, LICENSE, PAYMENT, PURCHASE ORDER, REGISTRATION, RESERVATION, RESUME, SEMESTER, SHIPMENT, STEP, TASK, TEST, WORK ORDER


Irwin/McGraw-Hill

Entities

LOCATIONS Entities that describe locations

BRANCH, BUILDING, CAMPUS, CITY, COUNTRY, COUNTY, ROOM, ROUTE, SALES REGION, SCHOOL ZONE, PROVINCE, STORAGE BIN, VOTER DISTRICT, WAREHOUSE ZONE


Irwin/McGraw-Hill

Entities and Entity Classes or Groups

Entities of a given type are grouped into an entity class Thus, the EMPLOYEE entity class is the collection of all

EMPLOYEE entities Entity classes are described by their structure An instance of an entity is the representation of a particular

entity such as Customer 1234 and is described by its values of the attributes

Name entities with nouns that describe above (singular) INVOICE

Instances of the entity are referred to in the plural - Invoices


Irwin/McGraw-Hill

Attributes

Data attributes are characteristics that are common to all or most all instances of a particular entity.

Synonyms include: properties, data elements, descriptors, and fields

Attributes take on values for each occurrence of an entity. An attribute must have more than one legitimate value otherwise it is a constant.


Irwin/McGraw-Hill

Identifier

Identifier is an attribute or combination of attributes that uniquely identifies one, and only one occurrence of an entity.

Synonyms include key or primary key For example, Employee instances could be identified by a

SocialInsuranceNumber, EmployeeNumber or EmployeeName

Identifiers of an entity instance consists of one or more of the entity’s attributes

An identifier may be either unique or non-unique Identifiers that consist of two or more attributes are called

composite identifiers


Irwin/McGraw-Hill

RelationshipsRelationships

Entities can be associated with one another in relationships. A relationship can include many entities; and the number of

entities in a relationship is a degree of the relationship. Degree 2 relationships are common and are called binary

relationships 1:1 one to one AUTO-ASSIGNMENT 1:N one to many DORM-OCCUPANT N:M many to many STUDENT-CLUB


Irwin/McGraw-Hill

Relationship DegreeRelationship Degree

SALESPERSONSALESPERSON

ORDERORDER

SP-ORDER

Degree 2

MOTHERMOTHER FATHERFATHER

CHILDCHILD

PARENT

Degree 3


Irwin/McGraw-Hill

Three Types of Binary RelationshipsThree Types of Binary Relationships

EMPLOYEEEMPLOYEE AUTOAUTO

AUTO-ASSIGNMENT

1:1

DORMITORYDORMITORY STUDENTSTUDENT

DORM-OCCUPANT

1:N

STUDENTSTUDENT CLUBCLUB

STUDENT-CLUB

N:M

These areoften called

HAS Arelationships

These areoften called

HAS Arelationships

ShowsMAXIMUMcardinality

ShowsMAXIMUMcardinality

may or may notmay or may not

must exist


Irwin/McGraw-Hill

Other relationshipsOther relationships

DORMITORYDORMITORY STUDENTSTUDENT

DORM-OCCUPANT

1:N

Minimum cardinality

Recursive relationship

STUDENTSTUDENT 1:N

ROOMS-WITH

EMPLOYEEEMPLOYEE DEPENDENTDEPENDENT1:N

Weak Relationships

BUILDINGBUILDING APARTMENTAPARTMENT1:NID Dependent

entity

ERD:

CUSTOMERCUSTOMER SALESPERSONSALESPERSON

SALES-ORDERSALES-ORDER

LINEITEMLINEITEM

ITEMITEM

I:N N:1

I:N

I:N

Semantic Object Model (SALSA)


Irwin/McGraw-Hill

Access Database RelationshipsAccess Database Relationships


Irwin/McGraw-Hill

REAL DiagramREAL Diagram

Customer(Agent)

Customer(Agent)

Take Order(Event)

Take Order(Event)

SalesPerson(Agent)

SalesPerson(Agent)

Product-Item(Resource)

Product-Item(Resource)

List Items Ordered (Event)

List Items Ordered (Event)

(1,1)

(1,1)

(1,*)

(1,1) (0,*) (0,*)

(0,*)

(0,*)

CUSTOMER (Customer#, CustomerName, Street, City, State, Zip)

SALESPERSON (SalesPerson#, SalesPersonName)

SALES-ORDER (Order#, Date, [Customer#], [SalesPerson#],Subtotal, Tax, Total)

ITEM (Item#, Name, Description)

(LineItem#, [Order#],Quantity, [Item#], ExtendedPrice)ITEMS-ORDERED


Irwin/McGraw-Hill

Exhibit 4-8 Recursive Relationship Example

Employee manages

Employee

manages


Irwin/McGraw-Hill

Relationships

Described by verbs or verb phrases Multiple relationships are possible between two entities

COURSE STUDENT

Was Taken by

Is Being Taken by


Irwin/McGraw-Hill

Ordinality

Defines whether the relationship between entities is mandatory or optional.

Ordinality determines the minimum number of occurrences of one entity relative to another.

Ordinality must be defined in both directions


Irwin/McGraw-Hill

Cardinality

Defines the maximum number of occurrences of one entity for a single occurrence of the related entity

This is the number to the right of the colon below. Ordinality is the number to the left of the colon.

Customer

Places

Order

Contains

Products

1:10:M

0:M

1:M


Irwin/McGraw-Hill

Relationships That Can Be Described by Data

Normally relationships are not described by data attributes

However if Cardinality is many in both directions, the relationship itself is frequently described by data attributes.

“Many to Many” relationship An associative entity is a data entity whose attributes

describe a relationship between two or more fundamental entities


Irwin/McGraw-Hill

Ordered Product

Many to Many

Service

Product

Order

IsPlaced

For

Is Placed

For

Shipment

Invoice

Requested

Service

1:M

1:M

OR

0:M

0:M

AND

1:1

1:1

0:M

0:M


Irwin/McGraw-Hill

Create a separate table that includes the key attributes

from both object tables.

Create a separate table that includes the key attributes

from both object tables.

Linking Objects with Many to Many (*:*)

Relationships


Irwin/McGraw-Hill

Linking Objects with One to One (1:1) Relationships

Put the key attribute

of either object in the table of the other

Put the key attribute

of either object in the table of the other

Create a separate table that includes

the key attributes from both objects

Create a separate table that includes

the key attributes from both objects

When you are linking two events with a 1:1 relationship,either put the key of the prior event table

into the subsequent event table or create a third table.

OR


Irwin/McGraw-Hill

Post the key attribute of the object with the 1 side of the cardinality

into the table of the many (*) side of the cardinality.

Post the key attribute of the object with the 1 side of the cardinality

into the table of the many (*) side of the cardinality.

If you follow the specified rule and find that you would post the key of the event that occurs

second into the table of the event that occurs first, create a separate table that includes the key attributes

from both event tables.

Linking Objects with One to Many (1:*) or

Many to One (*:1) Relationships


Irwin/McGraw-Hill

Exhibit 4-9 Christopher Inc. REAL ModelResources Events Agents

Order personnel

CustomerInventory

Receivecustomer

orderincludes

takes

places

Cashier

Collectpayment

CashBank

is keptat increases

takes in

sends

Shippingpersonnel

Shippingfirm

ShipOrder

is made

up of

goes to

executes

carried by(1,*)

(1,*)

(1,*)

(0,*)(0,*)

(0,*)

(0,*)

(0,*)

(0,*)(0,*)

(0,*)

(0,*)

(0,*)

(0,*)

(0,*)

(0,*)

(1,1)

(1,1)(1,1)

(1,1)

(1,1)

(1,1)

(1,1)

(1,1) (1,1)

(1,1)


Irwin/McGraw-Hill

Exhibit 4-10 Different Notations to Represent Relationships Cardinalities

(1,1)

(1,*)

(0,1)

(0,*)


Irwin/McGraw-Hill

Exhibit 4-11 Entity Attributes in an ER diagram

Inventory

InventoryItem #

InventoryItem #

InventoryItem #

InventoryItem #

InventoryItem #

InventoryItem #

InventoryItem #


Irwin/McGraw-Hill

Exhibit 4-12Example Relational Database Table

Customer # LastName

FirstName

Address Telephone

1001 Mays Willie 112 Say Hey Ave. 242-42421002 McCovey Willie 147 Fencebuster Way 999-99991003 Bonds Bobby 301 Out-of-here Blvd. 123-4567

Customer Table

SALES table (without a separate table for the sale-inventory *:* relationship):

SalesEvent # Date

Termsof Sale

SalespersonID

CustomerID

InventoryItem #

InventoryQuantity

Priceeach

1 2/5 2 10,net 30

4 3654 987 5 2.50

1 2/5 2 10,net 30

4 3654 785 4 1.75

1 2/5 2 10,net 30

4 3654 562 15 1.99

2 2/5 2 10,net 30

6 746 998 27 2.95

2 2/5 2 10,net 30

6 746 624 94 1.05

3 2/5 COD 8 2956 847 18 9.99

3 2/5 COD 8 2956 112 29 5.75

3 2/5 COD 8 2956 413 8 3.00

3 2/5 COD 8 2956 335 57 7.50

Sales Event TableSalesEvent # Date Terms

SalespersonID

CustomerID

1 2/5 2 10, net 30 4 3654

2 2/5 2 10, net 30 6 746

3 2/5 COD 8 2956

(*:*) Sale-Inventory Table

SalesEvent #

InventoryItem #

InventoryQuantity

Priceeach

1 987 5 2.50

1 785 4 1.75

1 562 15 1.99

2 998 27 2.95

2 624 94 1.05

3 847 18 49.99

3 112 29 15.75

3 413 8 16.00

3 335 57 17.50


Irwin/McGraw-Hill

Exhibit 4-13 Christopher Inc. Event Logical Structures - Order Taking

CUSTOMER Customer #, Name,Street Address,City, State, Zip, Telephone#Credit Rating,Credit Limit

RECEIVE CUSTOMER ORDER Sales Order #, [Customer #],[Customer Order Representative Employee #], Date, Time, Instructions, Cancel by Date, Location or order

EMPLOYEE,Employee #,Name, AddressTelephone #,BirthDateStart date, Salary,

ORDER/INVENTORY [Sales Order #], [Inventory item #], Quantity Ordered

INVENTORY Inventory Item #,Description,Product Specification,Reorder Point,Current Price,Beginning Quantity,Beginning Quantity Date

LegendRELATION

Primary Key

[Foreign Key]


Irwin/McGraw-Hill

Exhibit 4-13 Christopher Inc. Event Logical Structures - Shipping

SHIP ORDER Invoice #, [Sales Order #], [Customer #], [Shipping Personnel Employee #], [Shipping Firm ID #], Date, Time, Shipment tracking #, Sales TaxSHIPPING FIRM,

Shipping Firm ID#,Shipping Firm Name, AddressTelephone #,Contact PersonRate Information

SHIP/INVENTORY [Invoice #],[Inventory Item #], Quantity Shipped, Price Each

Inventory

Customer

Employee

Sales Order


Irwin/McGraw-Hill

BANKBank #,Bank Name, Address

COLLECT PAYMENT Cash Receipt #, [Cash Account #], [Customer #], [Cashier Employee #],Date, Time, Amount Received, Electronic Funds Transfer #

Exhibit 4-13 Christopher Inc. Event Logical Structures - Cash Collection

SHIP/COLLECT PAYMENT[Invoice #],[Cash Receipt #], Amount applied to this Invoice

CASHCash Account #,[Bank #],Type of AccountBeginning BalanceDate

Customer

Employee

Shipping Order


Irwin/McGraw-Hill

Exhibit 4-14 Linking the Order Recording Process with the Data Repository

RecordSale

Order-Data

INVENTORY

ORDER

CUSTOMER

ORDER PERSONNEL

ORDER-INVENTORY


Irwin/McGraw-Hill

Exhibit 4-15 Sample Maintenance Processes and Data Access

Update BankData

Register-Data

Update Customer

Data

Customer-Data

Update Shipping

firmData

Salesperson-Data

Update Inventory

Data

Merchandise-DataINVENTORY

BANK

CUSTOMER

SHIPPING FIRM


Irwin/McGraw-Hill

Exhibit 4-16Example fo Generating a Sales-by-Salesperson

Report

ReportSale

Request Sales-by-Salesperson report

MERCHANDISE

Sales-by-Salesperson = Report-Date + {Salesperson Name + {Merchandise-Description + Qty-Sold + $ Contribution} Total Sales + Total Contribution

Sales-by-Salesperson

SALE

SALESPERSON

SALE-MERCHANDISE

Tugas

Agar perkuliahan pada Agar perkuliahan pada pertemuan 14 bisa berjalan pertemuan 14 bisa berjalan

dengan lancar, Setiap dengan lancar, Setiap mahasiswa diwajibkan untuk mahasiswa diwajibkan untuk mendownload dan mencetak mendownload dan mencetak

kasus pada pertemuan 14kasus pada pertemuan 14

Berlanjut ke Berlanjut ke

Pertemuan 13Pertemuan 13

Pertemuan 12 Systems Analysis and Design of a Business Event Driven System Matakuliah: M0034...

Documents

Transcript of Pertemuan 12 Systems Analysis and Design of a Business Event Driven System Matakuliah: M0034...