Systems Analysis and Design of a Business Event Driven System - PowerPoint PPT Presentation

1 / 85
About This Presentation
Title:

Systems Analysis and Design of a Business Event Driven System

Description:

What objectives will it help the organization to accomplish? The McGraw-Hill Companies, Inc. ... Sample Context Dictionary Entries ... – PowerPoint PPT presentation

Number of Views:136
Avg rating:3.0/5.0

less

Transcript and Presenter's Notes

Title: Systems Analysis and Design of a Business Event Driven System


1
Systems Analysis and Design of a Business Event
Driven System
  • Chapter 4

2
Objective
  • The objective of this chapter is to help you
    understand the key steps in analyzing and
    designing information technology (IT)
    applications.

3
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?

4
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

5
Steps of a Systems Analysis and Design Life Cycle
(SDLC)
J.A. Hoffer, J.F. George, and J.S. Valacich,
Modern Systems Analysis and Design, Reading,
Massachusetts Addison Wesley, 1999.
6
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.
7
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

Process Modeling
Logical Models
Conceptual data modeling
8
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?

9
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.

10
Exhibit 4-3 Christopher Inc. REAL Model
Resources
Agents
Events
Christopher Inc. provides baseball caps to major
league baseball teams to sell in their ballparks.
While analyzing their business process,
Christophers analysis team identified three key
operating activities receive orders from
baseball teams (who are Christophers customers),
package and ship caps to the teams (the sale of
merchandise), and receive payment from the teams
11
The Structure of Information Processes
12
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.

13
Exhibit 4-4Christopher Inc., Context Diagram
O Sales / collection system
  • 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 circle represents computer processing
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).
Christopher Inc. needs a system that allows them
to send shipping data to their carriers and
receive shipment confirmations from their
carriers.
Finally, Christopher Inc.s systems should allow
access by internal agents (such as management and
other decision-makers) to critical data and
information.
14
Exhibit 4-5 Christopher, Inc. Level 0 Data Flow
Diagram
1.0 Process customer orders
Desired information
Orders
Shipping request data
2.0 Process shipments to customers
Desired information
Decision makers
Bill
Customers
Payments due data
Payment
Desired information
3.0 Process payments from customers
15
Exhibit 4-6 Christopher Inc., Level 1 Data Flow
Diagram
Customer order data
Approved Order
Order
1.1 Approve and record customer order data
Order data
1.2 Generate information about orders
Desired information
Shipping Request Data
16
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

17
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

18
Additional Prototyping Steps
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.
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
  • context diagram
  • inflows and outflows to
  • Record event data
  • Maintain resource, agent, location data
  • Report source documents, queries, reports

You need one recording process in your IT
application for each business event object in the
applications REAL model
You need one maintenance process in your IT
application for each resource, agent, and
location object in the applications REAL model
19
McKell's Retail Sale Store Case Checkpoint
  • 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)
  • Four maintenance processes
  • Maintain Customer Data,
  • Maintain Merchandise Data,
  • Maintain Salesperson Data, and
  • Maintain Register Data
  • to keep our resource, agent, and location data up
    to date and valid
  • 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

20
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.

21
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.

22
Exhibit 4-7 Structured English Example
Process
Data
Input
For each Customer-Order do the following 1.
Search for Customer-Name if found Confirm
customer info with customer if not found Enter
customer data 2. Check for availability of
inventory requested if available Confirm
ship-to-information if not available Inform
customer with Order-Confirmation 3. Provide
customer with Order-Confirmation 4. Send
notification to packing agents
Output
23
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.

24
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.

25
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).

26
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

EntityName
RelationshipName
27
Example
Customer
Orders
Supplies
28
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

29
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

30
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

31
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

32
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

33
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.

34
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 entitys attributes
  • An identifier may be either unique or non-unique
  • Identifiers that consist of two or more
    attributes are called composite identifiers

35
Relationships
  • 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
  • 11 one to one AUTO-ASSIGNMENT
  • 1N one to many DORM-OCCUPANT
  • NM many to many STUDENT-CLUB

36
Relationship Degree
37
Three Types of Binary Relationships
These are often called HAS A relationships
38
Other relationships
Weak Relationships
EMPLOYEE
DEPENDENT
1N
ID Dependententity
BUILDING
APARTMENT
1N
39
ERD
Semantic Object Model (SALSA)
40
Access Database Relationships
41
REAL Diagram
(1,1)
Product-Item (Resource)
Customer(Agent)
(0,)
(0,)
(1,1)
Take Order (Event)
(0,)
SalesPerson (Agent)
(1,)
List Items Ordered (Event)
(1,1)
(0,)
42
Exhibit 4-8 Recursive Relationship Example
manages
Employee
Employee
manages
43
Relationships
  • Described by verbs or verb phrases
  • Multiple relationships are possible between two
    entities

Is Being Taken by
COURSE
STUDENT
Was Taken by
44
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

45
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.

0M
Order
Products
Customer
11
0M
Places
1M
46
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

47
Many to Many
Service
Shipment
IsPlacedFor
0M
Requested Service
1M
0M
11
Order
OR
AND
11
Is Placed For
1M
Ordered Product
0M
0M
Product
Invoice
48
Linking Objects with Many to Many ()
Relationships
Create a separate table that includes the key
attributes from both object tables.
49
Linking Objects with One to One (11)
Relationships
Create a separate table that includes the key
attributes from both objects
Put the key attribute of either object in the
table of the other
OR
When you are linking two events with a 11
relationship, either put the key of the prior
event table into the subsequent event table or
create a third table.
50
Linking Objects with One to Many (1) or Many
to One (1) Relationships
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.
51
Exhibit 4-9 Christopher Inc. REAL Model
Resources
Events
Agents
Order personnel
(1,1)
Receive customer order
takes
(0,)
(0,)
(1,)
(1,1)
(1,1)
Customer
(0,)
Inventory
includes
places
(1,1)
(1,)
(1,1)
goes to
is made up of
(0,)
(0,)
Shippingpersonnel
Ship Order
(1,1)
(0,)
executes
(0,)
(0,)
(1,)
(1,1)
carried by
Shipping firm
(0,)
is kept at
increases
Collect payment
sends
(0,)
Cash
Bank
(0,)
(0,)
(1,1)
(1,1)
(0,)
takes in
Cashier
(1,1)
52
Exhibit 4-10 Different Notations to Represent
Relationships Cardinalities
(1,1)
(1,)
(0,1)
(0,)
53
Exhibit 4-11 Entity Attributes in an ER diagram
Inventory Item
Inventory Item
Inventory Item
Inventory Item
Inventory Item
Inventory
Inventory Item
Inventory Item
54
Exhibit 4-12Example Relational Database Table
Customer Table
55
SALES table (without a separate table for the
sale-inventory relationship)
56
Sales Event Table
() Sale-Inventory Table
57
Exhibit 4-13 Christopher Inc. Event Logical
Structures - Order Taking
RECEIVE CUSTOMER ORDER Sales Order , Customer
,Customer Order Representative Employee ,
Date, Time, Instructions, Cancel by Date,
Location or order
CUSTOMER Customer , Name,Street
Address, City, State, Zip, Telephone Credit
Rating, Credit Limit
ORDER/INVENTORY Sales Order , Inventory item
, Quantity Ordered
Legend
EMPLOYEE, Employee , Name, Address Telephone
, BirthDate Start date, Salary,
INVENTORY Inventory Item , Description, Product
Specification, Reorder Point, Current
Price, Beginning Quantity, Beginning Quantity Date
RELATION
Primary Key
Foreign Key
58
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 Tax
SHIP/INVENTORY Invoice , Inventory Item ,
Quantity Shipped, Price Each
Sales Order
Customer
Employee
SHIPPING FIRM, Shipping Firm ID, Shipping Firm
Name, Address Telephone , Contact Person Rate
Information
Inventory
59
Exhibit 4-13 Christopher Inc. Event Logical
Structures - Cash Collection
BANKBank , Bank Name, Address
CASHCash Account , Bank , Type of
Account Beginning Balance Date
Shipping Order
SHIP/COLLECT PAYMENTInvoice , Cash Receipt
, Amount applied to this Invoice
COLLECT PAYMENT Cash Receipt , Cash Account
, Customer , Cashier Employee ,Date,
Time, Amount Received, Electronic Funds Transfer
Customer
Employee
60
Exhibit 4-14 Linking the Order Recording Process
with the Data Repository
INVENTORY
Record Sale
ORDER
Order-Data
CUSTOMER
ORDER PERSONNEL
ORDER-INVENTORY
61
Exhibit 4-15 Sample Maintenance Processes and
Data Access
Update Bank Data
Register-Data
BANK
Update Customer Data
Customer-Data
CUSTOMER
Update Shipping firm Data
Salesperson-Data
SHIPPING FIRM
Update Inventory Data
Merchandise-Data
INVENTORY
62
Exhibit 4-16Example fo Generating a
Sales-by-Salesperson Report
MERCHANDISE
Request Sales-by- Salesperson report
Report Sale
SALE
Sales-by- Salesperson
SALESPERSON
SALE-MERCHANDISE
Sales-by-Salesperson Report-Date Salesperson
Name Merchandise-Description Qty-Sold
Contribution Total Sales Total Contribution
63
Exhibit 4-17 Evolution Of AIS Modeling
Stage 1
Stage 2
Stage 3
Manual Systems
Automated Systems
Event Driven IT Applications
Resources Manual Process Acct Cycle Data
Stores (Files) Journals Ledgers
Resources Information Technology Process Acct
Cycle Data Stores (Files) Journals Ledgers
Resources Information Technology Process
Record, Maintain, Report Business Activity
Data Data Stores Business Activity
Data Integrated Stores
Bias Support Planning, Control Evaluation
Activities of Various Information Customers
Bias Generate financial statements
Bias Generate financial statements
64
Prototyping Preliminary Steps
Step 1 Review the business process and identify
the business events of interest.
65
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.
66
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.
67
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.
68
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.
Step 5 Validate the model with the business
person.
69
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
70
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
71
McKells Retail Sale Store
72
Application Context Diagram
EVENT-DATA Definitions of various data flows for
each business event within the application
scope MAINTENANCE-DATA Definitions of various
data flows for maintaining application reference
data RESPONSES Definitions of various
responses provided by the application NOTIFICATIO
NS Definitions of various notifications
provided by the application REPORTS
Definitions of various reports provided by the
application
73
McKells 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 InvoiceMerchandise
Qty-Sold REPORT Example Product-Sales
Report-Date Merchandise Merchandise
Description Qty-Sold Margin
Contribution Accounting-Revenue Report-Date
Reporting-Period Revenue for Reporting-Period S
ales-by-Salesperson Report-Date Salesperson
Name Merchandise-Description Qty-Sold
Contribution Total Sales Total
Contribution Customer-Profile Report-Date
Name State Birthdate Telephone
Merchandise Description Qty-Sold
74
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

75
McKells Retail Sale REAL Model With Cardinalities
Salesperson
Register
(1,1)
(1,1)
(0,)
(0,)
Sale
(0,)
(0,)
Customer
(1,1)
(1,)
Merchandise
76
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

77
McKells Retail Sale Store - Tables
Register (Register,
Merchandise (Merchandise,
Sale (Sale,
Customer (Customer,
Salesperson (Employee,
Sale-Merchandise (Sale, Merchandise,
78
McKells Retail Sale Store - Tables
Register (Register,
Merchandise (Merchandise,
Sale (Sale, Register, Customer,
Employee,
Customer (Customer,
Salesperson (Employee,
Sale-Merchandise (Sale, Merchandise,
79
McKells 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,
...
80
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)

81
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.
82
McKells Retail Sale UpdatedREAL Model With
Cardinalities
83
McKells Retail Sale Store Tables
  • 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
Merchandise
Sale-Merchandise
Register
Customer
Salesperson
84
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.
85
REAL Business Process Modeling of Mail Order
Sales/Collection Process
Write a Comment
User Comments (0)
About PowerShow.com