Upload
walter
View
32
Download
0
Embed Size (px)
DESCRIPTION
Systems Analysis and Design of a Business Event Driven System. Chapter 4. Objective. The objective of this chapter is to help you understand the key steps in analyzing and designing information technology (IT) applications. Analysis and Design of a Business Event-driven IT Application. - PowerPoint PPT Presentation
Citation preview
By Hollander, Denna, Cherrington
Accounting, Information Technology, and Business Solutions, 2nd Edition
Irwin/McGraw-Hill The McGraw-Hill Companies, Inc., 2000
Systems Analysis and Design of a Business Event Driven System
Chapter 4
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Objective
The objective of this chapter is to help you understand the key steps in analyzing and designing information technology (IT) applications.
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Analysis and Design of a Business Event-driven IT Application
Designing quality IT applications requires a thorough understanding of the organization including its current and desired objectives, strategies, value chains, risks, and business processes
There are a variety of methods for analyzing and designing information systems.
How do professionals move from a business need for information to creating the physical IT infrastructure that can provide that information?
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Systems Analysis and Design Methods
Exhibit 1 presents a systems analysis and design life cycle (SDLC) by J.A. Hoffer, J.F. George, and J.S. Valacich
Exhibit 2 displays the systems development process presented by J.L. Whitten, L.D. Bentley, and V.M. Barlow
Other analysis and design approaches, including object-oriented analysis and design, prototyping, systems engineering, joint application design, participatory design, essential system design, automating the SDLC using CASE tools
Implementation
Maintenance
Physical Design
Logical
Design
Analysis
Project Identification and Selection
Project Initiation
J.A. Hoffer, J.F. George, and J.S. Valacich, Modern Systems Analysis and Design, Reading, Massachusetts: Addison Wesley, 1999.
Steps of a Systems Analysis and Design Life Cycle (SDLC)
Steps of a Systems Analysis and Design Life Cycle (SDLC)
I. The Analysis Phase – determining systems
requirements and structuring the
requirements by creating process models, logical models, and conceptual
data models.
II. The Logical Design Phase – developing the
logical design of the database and designing forms, reports, interfaces, and
dialogues.
III. The Physical Design Phase – designing physical files, databases, and programming instructions.
IV. The Implementation and Maintenance Phase – performing system
coding, testing, installing,
documenting, user training, supporting
users, and maintaining the
system.
The Systems Development Process
J.L. Whitten, L.D. Bentley, and V.M. Barlow, Systems Analysis and Design, instructors ed., 3rd ed. Burr Ridge, Ill.: Richard D. Irwin, 1994.
Systems Planning Planned application
development process
Systems Analysis
Businessrequirements
statement
Systems Design
Technicaldesign
statement
Existing system detailsand limitationsSystems
Support
Existing systemdetails and limitations
Systems Implementation
Productioninformation
system
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Phase 1: Systems Analysis
Step 1-A: Defining systems requirements Step 1-B: Structuring systems requirements
using process modeling Step 1-C: Structuring systems requirements
using logical models Step 1-D: Structuring systems requirements
using conceptual data modeling Step 1-E: Selecting a design strategy
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
STEP I-A: Systems Analysis - Defining Systems Requirements
After an organization has: identified the need for a system project and has successfully made a business case to justify investing the time and funds
necessary to undertake the project, a project team organizes and plans the work to be completed.
The team considers the costs, benefits, feasibility, responsibilities, and project timeline.
After completing these details they define the system requirements: What are the expectations of this system? What work and decisions will it support? What objectives will it help the organization to accomplish?
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Defining Systems Requirements Your business analysis highlights the activities that an
organization needs to perform effectively and efficiently to accomplish its objectives.
An information system should support these activities.
Add information processes, including data stores, and data flows, to the analysis
Consider the desired environment and envision innovative ways for the system to enable organization objectives and desired processes.
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Recording operating event data
Maintaining reference data
about resources, agents, and
locations
Exhibit 4-3 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
Christopher Inc. provides baseball caps to major league baseball teams to sell in their ballparks. While analyzing their business
process, Christopher’s analysis team identified three key operating activities:
receive orders from baseball teams (who are Christopher’s customers), package and ship caps to the teams (the sale of merchandise),
and receive payment from the teams
Reporting useful information to information customers
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
The Structure of Information Processes
RecordingProcess
Stimulus
Response
Notification
Data
Executing each operating event triggers the need to record descriptive data about the event. When data is captured while the operating event occurs, the recording process can execute business rules specified by management for each operating event. These rules are the guidelines, standards, policies, and/or procedures intended to increase operational and information quality by reducing such problems as errors, irregularities, or fraud. Ideally, the execution of the operating event and the related information process occur simultaneously.
MaintainingProcess
Stimulus
Response
Notification
Data
To support a business process, a system must collect data about the resources, agents, and locations that define the operating events. The system must allow the data to be kept current. Maintaining reference data involves adding, deleting, or modifying data about resources, agents, and locations (e.g., changing products offered by a vendor; changing an employee's marital status; and adding a new vendor to the vendor list). The objective is to maintain accurate, complete, and timely data about the resources, agents, and locations involved in operating events for the process you are modeling.
ReportingProcess
StimulusData Response
Notification
The reporting processes extract and convert stored data about events, resources, agents, and locations into information, and formatting the information for presentation to information customers.These views often consist of financial and performance measures and may take the form of hardcopy source documents, hardcopy reports, electronic data flows, or ad hoc queries. These data flows authorize actions, provide documentation to other business functions or to outside parties, and support both operational and strategic decision making.
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.
The McGraw-Hill Companies, Inc., 2000
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.
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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)
The McGraw-Hill Companies, Inc., 2000
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.
The McGraw-Hill Companies, Inc., 2000
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.
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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.
The McGraw-Hill Companies, Inc., 2000
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.
The McGraw-Hill Companies, Inc., 2000
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).
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Example
CustomerPlaces/ or
Is Placed By
Orders
Contains orIs Contained By
Supplies
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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.
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Relationship DegreeRelationship Degree
SALESPERSONSALESPERSON
ORDERORDER
SP-ORDER
Degree 2
MOTHERMOTHER FATHERFATHER
CHILDCHILD
PARENT
Degree 3
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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)
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Access Database RelationshipsAccess Database Relationships
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Exhibit 4-8 Recursive Relationship Example
Employee manages
Employee
manages
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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)
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Exhibit 4-10 Different Notations to Represent Relationships Cardinalities
(1,1)
(1,*)
(0,1)
(0,*)
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Exhibit 4-11 Entity Attributes in an ER diagram
Inventory
InventoryItem #
InventoryItem #
InventoryItem #
InventoryItem #
InventoryItem #
InventoryItem #
InventoryItem #
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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]
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
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
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Exhibit 4-17Evolution Of AIS Modeling
Stage 1ManualSystems
Stage 2AutomatedSystems
Stage 3
Resources:ManualProcess: Acct CycleData Stores (Files): Journals & Ledgers
Resources:Information TechnologyProcess: Acct CycleData Stores (Files): Journals & Ledgers
Event Driven ITApplicationsResources:Information TechnologyProcess: Record, Maintain, ReportBusiness Activity DataData Stores: Business Activity DataIntegrated Stores
Bias:Generate financialstatements
Bias:Generate financialstatements
Bias:Support Planning, Control& Evaluation Activities ofVarious InformationCustomers
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Prototyping: Preliminary Steps
Step 1: Review the business process and identify the business events of interest.
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Prototyping: Preliminary Steps
Step 1: Review the business process and identify the business events of interest.
Step 2: Analyze each event to identify the event resources, agents, and locations.
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Prototyping: Preliminary Steps
Step 1: Review the business process and identify the business events of interest.
Step 2: Analyze each event to identify the event resources, agents, and locations.
Step 3: Identify the relevant behaviors, characteristics, and attributes of the event, resources, agents, and locations.
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Prototyping: Preliminary Steps
Step 1: Review the business process and identify the business events of interest.
Step 2: Analyze each event to identify the event resources, agents, and locations.
Step 3: Identify the relevant behaviors, characteristics, and attributes of the event, resources, agents, and locations.
Step 4: Identify the direct relationships between objects.
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Prototyping: Preliminary StepsStep 1: Review the business process and identify the business events of interest.
Step 2: Analyze each event to identify the event resources, agents, and locations.
Step 3: Identify the relevant behaviors, characteristics, and attributes of the event, resources, agents, and locations.Step 4: Identify the direct relationships between objects.
Step 5: Validate the model with the business person.
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Planning an Event-Driven Application
Identifying the business events of interest Identifying the resources, agents, and locations of each
event of interest Identifying the relevant behaviors, characteristics and
attributes of the events, resources, agents, and locations Identifying the direct relationship between objects Validating your business process model with business
persons
Chapter 2
Chapter 2
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Planning an Event-Driven Application
Defining the scope of the IT application Enhancing the relationships of the REAL model by
defining their cardinalities Designing the data repository Linking the recording, maintaining, and reporting process
to the data repository Constructing the prototype
Chapter 4
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
McKell’s Retail Sale StoreMcKell’s Retail Sale Store
Sale
CustomerMerchandise
SalespersonRegister
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Application Context Diagram
EVENT-DATADefinitions of various data flows for each business event within the application scope
MAINTENANCE-DATADefinitions of various data flows for maintaining application reference data
RESPONSES Definitions of various responses provided by the application
NOTIFICATIONS Definitions of various notifications provided by the application
REPORTS Definitions of various reports provided by the application
Event-Data
ReportsApplicationContextResponse
Notification
Maintenance-Data
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
McKell’s Retail Sale Context Diagram
EVENT-DATA Example= Sale-Data = Sale-Date + Register # + Customer # + Employee # + {Merchandise # + Qty-Sold}
MAINTENANCE-DATA Example=Definitions of various data flows for maintaining customer, salesperson, and register reference data
RESPONSE Example= Sales-Invoice = Invoice# +Sale-Date + Register # + Customer Name + Salesperson Name + {Merchandise Name + Qty-Sold + Price + Item-Total} + Sale-Total
NOTIFICATION Example = Warehouse-notification = Invoice#+{Merchandise# + Qty-Sold}
REPORT Example =Product-Sales = Report-Date + {Merchandise # + Merchandise Description + Qty-Sold +
%Margin + $ Contribution}Accounting-Revenue = Report-Date + Reporting-Period + Revenue for Reporting-PeriodSales-by-Salesperson = Report-Date + {Salesperson Name + {Merchandise-Description +
Qty-Sold + $ Contribution} Total Sales + Total ContributionCustomer-Profile = Report-Date + Name + State + Birthdate + Telephone +
{Merchandise Description + Qty-Sold}
Event-Data
ReportsApplicationContextResponse
Notification
Maintenance-Data
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Additional Prototyping Steps:
Step 6: Define the scope of the application.
Step 7: Enhance the relationships of the REAL model by defining their cardinalities.
• object 1(min, max) --- object 2(min, max)
•minimums denote business rules•maximums help establish data structures•both help structure your audit trail
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
McKell’s Retail Sale REAL Model With Cardinalities
Sale
CustomerMerchandise
SalespersonRegister(1,1)
(0,*) (0,*)
(1,1)
(0,*)
(1,1)(1,*)
(0,*)
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Additional Prototyping Steps:
Step 6: Define the scope of the application.
Step 7: Enhance the relationships of the REAL model by defining their cardinalities.
Step 8: Design the data repository structure.
•tables or objects•primary keys•posted keys•nonkey attributes
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
McKell’s Retail Sale Store - Tables
Register (Register#,
Merchandise (Merchandise#,
Sale (Sale#,
Customer (Customer#,
Salesperson (Employee#,
Sale-Merchandise ([Sale#], [Merchandise#],
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
McKell’s Retail Sale Store - Tables
Register (Register#,
Merchandise (Merchandise#,
Sale (Sale#, [Register#], [Customer#], [Employee#],
Customer (Customer#,
Salesperson (Employee#,
Sale-Merchandise ([Sale#], [Merchandise#],
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
McKell’s Retail Sale Store - Tables
Register (Register#, Store, Date-Purchased, Cost, ...
Merchandise (Merchandise#, Description, Current-Price, Current-Cost, ...
Sale (Sale#, [Register#], [Customer#], [Employee#], Time, ...
Customer (Customer#, Name, Address, State, Zip, Birthdate, Telephone#, Marital-Status, ...
Salesperson (Employee#, Name, Commission-Rate, ...
Sale-Merchandise ([Sale#], [Merchandise#], Qty-Sold, Historical-Cost, Historical-Price, ...
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Additional Prototyping Steps:
Step 6: Define the scope of the application.
Step 7: Enhance the relationships of the REAL model by defining their cardinalities.
Step 8: Design the data repository structure.
Step 9: Link the recording, maintenance, and reporting processes to the data repository.
• Record events• Maintain resources, agents, and locations• Report (source documents, queries, reports)
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Additional Prototyping Steps:
Step 6: Define the scope of the application.
Step 7: Enhance the relationships of the REAL model by defining their cardinalities.
Step 8: Design the data repository structure.
Step 9: Link the recording, maintenance, and reporting processes to the data repository.
Step 10: Build the application prototype.
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
McKell’s Retail Sale UpdatedREAL Model With Cardinalities
Sale
CustomerMerchandise
SalespersonRegister(1,1)
(0,*) (0,*)(1,1)
(0,*)(1,1)(1,*)
(0,*)
Receive Payment
Receipts ClerkCash
(0,*) (0,*)
(0,*)(1,1)(1,1)
(0,*)
(1,1)
Store
(1,1) (0,*)
(1,*)
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
McKell’s Retail Sale StoreTables:
Merchandise
Customer
Salesperson
Sale-Merchandise
Register
We are able to satisfy multiple views by the data we collect:
•What happened?•When?
•What resources were involved and how much?
•Where did it occur?
•Who was involved and what roles did they play?
Sale
Steps for Building an IT Application Prototype
1. Build a table for each table defined using the REAL model,2. Build a menu system that has the following choices:
Record Event Data, Maintain Data, Reports, and Exit.3. Develop the necessary forms and procedures to collect event data and store it in the appropriate tables. 4. Develop the necessary forms and procedures to maintain the resource, agent, and location tables.5. Develop queries required to generate desired information.6. Develop report formats for each report.7. Write the procedures required to execute the queries and format the reports.8. Link each recording, maintaining, and reporting form to the application menu defined in step 2. Each form becomes a choice under either the Record Event Data, Maintenance, or Reports menu options.
The McGraw-Hill Companies, Inc., 2000
Irwin/McGraw-Hill
Customer Places Order
Package and Deliver Product
Receive Payment
Salesperson
Product Components
Packager
Carrier
Customer
Customer Payment Clerk
Cash
Package
Customer Service Center
Distribution Center
Customer Returns Merchandise
Returns Clerk
REAL Business Process Modeling of Mail Order Sales/Collection Process