Sunteți pe pagina 1din 56

Process Modeling Outline

Information Systems Purpose


The overriding purpose of any information system is to support the mission of the enterprise Every information system has a [specific] purpose or mission No matter how trivial the purpose may seem, do not skip documenting it

Information System Purpose Examples


A Convenience Store: The purpose of the information system is "To help each cashier work more effectively during checkout, to keep good records of each sale, and to support more efficient store operations." A Warehouse: The purpose of the information system is "To improve warehouse profitability by helping team members put away and pick items more efficientlyby keeping more accurate inventory counts, and by increasing fill rate."

Information Systems Purpose Guidelines


Purpose Statements should be:
Kept short 25 words or less if possible Proactive in form Supportive the mission of the enterprise Broad in scope, yet specific to the problem Void of technology jargon

Context Diagram Level 0 - Video Operation


Member Card Data

Customer

Customer Data

Confirm Data Overdue Charge

Credit Card Company

Video Request and Member Data

0 Video Rental/Return System

Charge Data

Receipt Data Video ID Data

Vendor Rental Data

Invoice Data

Report Data

Vendor Data

Accounting
Employee Data

Manager Vendor

Employees External Data store

Vendors External Data store

Modeling/Describing Your Lowest-Level Processes


Process 3.2.3 Give a Discount on the Purchase We drill down from Context Diagrams, to Level-1 DFDs, to Level-2 DFDs, each showing progressively greater levels of detail about our system processes. Once weve got to the lowest-level processes, we need to specify the lowest-level processes in detail using other techniques. zooming in on each of our lowest-level DFD processes and describing each low-level process using: Flow Charts, or Business Process Diagrams, or Plain English, or Structured English (Pseudocode), or Decision Tables / Trees
6

Process Modeling

Metadata (I) for the Video Current Operation DFDs Level 1 Diagram
Externals Accounting the person who keeps the financial and accounting data at Video. Credit Card Company the company that processes credit card transactions for Video. Customer people who wish to rent videos at a store. A customer must become a member to rent a video. Manager Video store manager(s) and Mr. Cosier Vendor companies that sell videos to .

Metadata (II) for the Video Current Operation DFDs


Data Flows (Partial list)
Charge Data credit card number, expire date and transaction amount Confirm Data either an approval or a reject message Customer data name, address, telephone and credit card info for a potential member supplied by a customer to become a member or to update his/her record Employee Data the employees number Member Card Data name and member number printed on a member card Member Data customer data plus a member number Overdue Charge credit card number, expire date and transaction amount

Metadata (III) for the Video Current Operation DFDs


Data Stores
Employees contains personal and payroll data for employees at Video. Each employee has an employee number. Customers contains customer data on paper forms arranged alphabetically. A copy of the form appears in Exhibit 1. Invoices contains rental, customer, employee and video data on paper forms, one for each rental arranged by rental date. A copy of the form appears in Exhibit 2. Video Rentals contains video and rental data on index cards, one for each rental video arranged by alphabetically by title and then by video number within a title. A copy of the card appears in Exhibit 3. Vendors contains in a notebook an alphabetical list of names with addresses for vendors.

First Explosion DFD for Video Current Operation (Figure 7.3)


1 Customer
Member Card Data Customer Data Video Request and Member Data Receipt Data

Enroll a new member or update record

Member Data

Customers

2
Credit Card Company
Charge Data Confirm Data

Member Data

Rent video(s) to member

Status Data

Video Rentals
Rental Data

Overdue Charge Video ID Data

3
Record return of video(s)

Return Date

Custome r

Return Data

Invoices

4 Accounting
Invoice Data

Invoice Data

Prepare a weekly report and send data to accounting

Employees External Datastore

Employee Data

Report Data

Manager 5 Vendor
Vendor Rental Data

Video Rentals
Video Data

Prepare a monthly vendor report

Vendors External Datastore


Vendor Data

Metadata for the Video Current Operation DFD


Processes (partial list) C3.0 Record return of video(s). When a video is returned, a back office clerk retrieves the card for the video rental and the invoice, records the return date on the invoice and the video rental card, calculates overdue charges if any and processes the credit card transaction. The credit card number is obtained by retrieving the customer form from the customer file. The overdue charges are noted on the invoice. The videos from a rental may be returned on different dates.

Guidelines for Creating the Current Operation First Level Explosion DFD
Match the narrative Provide clear detail on what happens Show data stores owned or maintained by other systems as externals Provide clear metadata on all DFD components Insure that DFD and narrative models are consistent

Flow Charts Notation


Systems Analysis, Design, and Implementation ANALYSIS PHASE Lecture 9: Process Modeling 1b

Process Modeling

Source: http://www.cems.uwe.ac.uk/~tdrewry/procdefs.htm

13

Flow Charts: Example


Flow Chart for Process 3.2.3: Give a Discount on the Purchase

Process Modeling

Source: http://www.cems.uwe.ac.uk/~tdrewry/procdefs.htm

14

Business Process Diagrams Notation

Process Modeling

15

Business Process Diagrams Example


Start Fill out form on web site Product Payment

Process Modeling

Business Process Diagram for Process 3.2.3: Give a Discount on the Purchase

Press 'Submit '

Read Pricing and Payment Time Data

Calculate Discount

End

16

Flow Charts vs DFDs ?


Flow Charts differ from DFDs in that DFDs capture the flow of data, whereas Flow Charts show the flow of control (i.e. flow charts show what conditions or decisions are evaluated and how the next process is chosen according to what actual condition or decision-result exists). For example the following condition/decision would be shown on a flow chart (or in a decision table or tree) but not on a DFD: Condition: Is price less than 100 ? Price < 100 No Result: Yes Action: Give 5% discount.
Yes

Process Modeling

The DFD would show only that the discounting process uses product price data, but would not show what conditions are tested (i.e. would not show what specific tests are made on the product-price-data values).
17

Plain English Base Descriptions


Plain English Base Description for Process 3.2.3: Give a Discount on the Purchase Process 3.2.3 Purchase Discounting Procedure
If the purchase is less than 100 then the discount given is 5%, unless the product is on special offer in which case the discount is 7.5% (with a minimum of 2 discount on special offer purchases). If the purchase is greater than 100 then the discount given is 8%. If the payment was made within 7 days then the discount is 7.5%. If the after-discountprice is greater than 45, then the discount is increased by 1% point (e.g. from 5% to 6%, or from 7.5% to 8.5%, or from 8% to 9%).

Process Modeling

Problems: what discount do we give if a purchase of 120 is paid within 7 days? Probably 9% we need to be explicit about which rule takes precedence across various different scenarios.
Source: Adapted from http://www.cems.uwe.ac.uk/~tdrewry/procdefs.htm

18

(Pseudocode) Pseudocode for Process 3.2.3: Give a Discount on the Purchase

Structured English Base Descriptions

Process Modeling

Note: Rather than hard-code these rules in program code (e.g. C++, Java, etc.) it would be best to provide a pricing configuration engine that allowed the marketer to adjust the pricing rules dynamically at run-time. (i.e. store the rules as data, rather than create them in program code).
Source: http://www.cems.uwe.ac.uk/~tdrewry/procdefs.htm

19

Process Modeling

Decision Tables/Matrices
Simple Decision Table for Process 3.2.3: Give a Discount on the Purchase

Source: http://www.cems.uwe.ac.uk/~tdrewry/procdefs.htm

20

Process Modeling

Simplified Decision Tables/Matrices


Decision Table for Process 3.2.3: Give a Discount on the Purchase

Source: http://www.cems.uwe.ac.uk/~tdrewry/procdefs.htm

21

Process Modeling

Decision Trees
(Vertical Layout)

Decision Tree for Process 3.2.3: Give a Discount on the Purchas

Source: http://www.cems.uwe.ac.uk/~tdrewry/procdefs.htm

22

Process Modeling

Decision Trees
(Horizontal Layout)

Decision Tree for Process 3.2.3: Give a Discount on the Purchas

Source: http://www.cems.uwe.ac.uk/~tdrewry/procdefs.htm

23

UML
The UML (Unified Modeling Language) is the most commonly used analysis notation for object-oriented systems. Originally developed by Rational Corporation (Booch, Rumbaugh, and Jacobson The Thee Amigos), it is now maintained by the Object Management Group (OMG) an industry standards organization for the OO community.

Rational is now part of IBM. Rational Rose is the CASE tool produced by Rational for UML modeling. Find out more about UML at:

or

http://www.omg.org/uml/ http://www.uml.org/

24

UML Use Case Diagrams: Notation


Actor / External Agent
[role name]
<< i

Process Modeling

Participates-In / Takes-part-in
nc lu d

External System
[system name] <<system>>

Indicates that a process e> is included in (i.e. is a > component in) more than one other process.

<< ex t

[process Use Case / Process name]

Indicates that a process is a special en d> > case (e.g. an error or exception case) of another process.

25

Type

Brief Description
A role played by a person, other system or other objects A start-to-finish feature of the system The communication path between an actor and a use case that it participates in

Notation

Actor Use case Association Extend Use case realization Include Boundary

The insertion of additional behavior into a base<<extend>> use case that does not know about it A relationship between a general use case and a more specific use case that inherits and adds features to it The insertion of additional behavior into a base<<include>> use case that explicitly describes the insertion The boundary of the information system

Figure 4.4 UML Use Case Diagram Notation


(adapted from The Unified Modeling Language Reference Manual, p. 65)

Actors
Actor definitions:
An abstraction for entities outside a system, subsystem, or class that interact directly with the system. An actor participates in a use case or coherent set of use cases to accomplish an overall purpose. [UML] A coherent set of roles that users of use cases play when interacting with the use cases. [Booch, Rumbaugh and Jacobson] Roles people or other information systems play when interacting through a use case with this information system. [Norman]

Actors
Actors are not part of the systemthey represent anyone or anything [another system] that must interact with the system Actors input to and/or receive output from the information system Actors are often identified via conversations with subject domain [matter] experts

Actor Examples
Customer
Mary Tom Jack Dino

Student Employee Faculty Member Credit Card Validation System

UML Use Case Diagrams: Example 1


Use Case Diagram for Consumer Banking System

Process Modeling

Source: http://www.modelingstyle.info/useCaseDiagram.html

30

Features
A prominent or significant functional, behavioral or descriptive part of an information system
Broad in scope; apply to whole system Narrow in scope; apply to one part of the system

An end-to-end (start-to-finish) significant process of the information system Synonymous with the UMLs Use Case Granularity is arbitrary

Feature Examples
(note the start-to-finish characteristic)
Course Registration or
Add a course Drop a course Check seat availability

Membership Maintenance or
Add a members information Change a members information Delete a membership Print/Display membership information

page 1 of 3

Types of Information System Features


A feature is a tangible, measurable, desired outcome that an information system could produce.

Log Information
(needed information) Business Problem Reference Data (Master, Foundational data)

Conduct Business
Business Problem Transaction Data

Analyze results
Business Problem Results

Interact with other systems


Business Problem Integration

page 2 of 3

Features Examples
x

Log Information:
Maintain membership information Maintain product information Maintain vendor (supplier) information Maintain employee security information etc Rental transaction Sales transaction Order products transaction etc...

Conduct Business:

(Maintain = adding, changing, deleting, & viewing)

page 3 of 3

Features Examples
x

Analyze results:
Produce Periodic Sales Report s by: Product Employee Fastest-moving rentals Fastest-moving sales Produce On-Order Report sorted by Vendor Produce On-Order Report sorted by Product etc

Interact with other systems:


Validation of Credit Cards etc...

Actor #1

Documenting Actors and Features


Actor #3
Feature #1 Feature #2 Feature #3

Feature #1 Feature #2 Feature #3

Actor #2
Feature #1 Feature #2 Feature #3

Actor #4
Feature #1 Feature #2 Feature #3

UML Use Case Diagrams: Example 2


Use Case Diagram for Online Shopping System (Example 1)

Process Modeling

Source: http://www.modelingstyle.info/useCaseDiagram.html

37

Use cases and Use-Case Diagrams


A use case is a description of a specific usage of the system Use cases define the functionality requirements (features) of the system A use case usually represents a user-recognizable end-to-end process rather than an individual step or activity within a process (e.g., rent a video instead of pay for video rental) A use-case diagram shows any number of external actors and their connection to the use cases that the system provides A use-case diagram generally includes a number of use cases Use cases are often identified by: identifying actors who input to or receive something from the system external events that the system must respond to (e.g., purchase an airline ticket, check-out a video)

Components of the Use Case


Actor (stick figure) a role that a user (e.g., people, other systems, and objects) plays with respect to the system Use case (oval) significant end-to-end process Valuation Stereotypes (<< >>) [guillemets] - provides the capability to extend the basic modeling elements of the UML to create new elements <<Include>> - a similar chunk of behavior across more than one use case (artifact reuse) <<Extend>> - indicates that one use case is similar to another but it does more Scenario (documented via an interaction diagram) documented step-by-step instantiation of an actual use case

UML Use Case Diagrams: Example 3


Use Case Diagram for Student Registration System

Process Modeling

(Closed head arrow indicates that the Enroll Family Member process is a type of Enroll Student process, and International Student is a type of Student. <<include>> indicates that the Enroll in Seminar process is used by the Enroll Student process and other processes. <<extend>> indicates that Enroll International Student is a special case of Enroll Student: i.e. it contains some additional processing steps to cater for the special case when the student is a foreigner.)
Source: http://www.modelingstyle.info/useCaseDiagram.html

40

UML Use Case Diagrams: Example 4


Use Case Diagram for Online Shopping System (Example 2)

Process Modeling

Multiple actors may participate in a single usecase (i.e. process) and multiple usecases may be associated with a single actor.

Source: Adapted from http://etna.int-evry.fr/COURS/UML/notation/notation6.html

41

Use Case Diagram Example #1

Use Case Diagram Example #2

base use case


Place Order <<extend>> Request Catalog

extension use case

<<include>> <<include>> Supply Customer Data Order Product

<<include>> Arrange Payment

parent use case child use case

inclusion use cases


Pay Cash

Arrange Credit

Figure 4.5 UML Use Case Relationships


(adapted from The Unified Modeling Language Reference Manual, p. 66)

UML Use Case Diagrams: Tips


Begin use-case (process) names with a strong, imperative verb: e.g. Withdraw Funds, Register Student in Seminar, or Deliver Shipment. Stack use-cases (processes) to imply timing: Processes completed first should be higher up in the diagram Name actors with business-relevant nouns (role names): e.g. Grade Administrator, Customer, Payment Processor Associate each actor with one or more use-cases (processes) The following types of process usually participate in <<include>> relationships as they are typically used by other processes: Lookup/Search-for , Sort, Process Payment Use <<system>> to indicate actors that are computer systems Use an actor called Time to indicate scheduled events Indicate different system releases with a boundary boxes: e.g. Release 1, Release 2.
Source: Adapted from http://www.modelingstyle.info/useCaseDiagram.html

Process Modeling

45

Using Microsoft Visio to Create UML Use Case Diagrams


Step 1: Choose File | New | Software | UML Model Diagram

Process Modeling

46

Using Microsoft Visio to Create UML Use Case Diagrams


Step 2: Choose UML Use Case from the categorized list of shapes on the left. Try Help | Microsoft Office Visio Help and type use case diagrams in the Search For box of the Assistance bar for more information.

Process Modeling

47

Process Modeling

Using Rational Rose to Create UML Use Case Diagrams

Source: Sample Order System model (ordersys.mdl file), packaged with Rational Rose.

48

UML Use Case Descriptions: Template


[Project Name] Use Cases [Date] [Use Case Name] Use-Case/Process ID: Priority: Actors: Goal: Preconditions: 1. 2. Flow of Events: 1. 2. Post-conditions: 1. 2. Alternative Flow: 1. 2. Alternative Flow Post-conditions: 1. 2.
49

Process Modeling

One of these Use Case Description forms is filled out for each use case (i.e. process) in the system.

UML Use Case Descriptions: Example


Hotel Reservation Use Cases 4 Feb 2004 Again, one of these Use Case Description forms is filled out for each use case (i.e. process) in the system. Reserve Room Use-Case/Process ID: UC1 Priority: High Actors: Hotel Guest Goal: To place a room reservation. Preconditions: 1. The guest has logged in Flow of Events: 1. The guest specifies their desired dates and location. 2. The guest is presented with available rooms. 3. The guest selects a room to book. Post-conditions: 1. The room has been booked exclusively for the guest. Alternative Flow 1: 1. Another guest books the room in the time between Guest A viewing the room and Guest A booking. 2. Guest A is presented with alternative rooms, or told that no rooms are available anymore. Alternative Flow 1 Post-conditions: 1. Guest A has booked an alternate room or Guest A has exited without booking.

Process Modeling

50

UML Activity Diagrams: Notation


Action / Activity Start State

Process Modeling

Transition between Activities

End State

Swimlane: indicating Actor participates in all actions / activities in that lane.


Source: http://www.dotnetcoders.com/web/learning/uml/diagrams/activity.aspx

Synchronization Bar: indicates merging of parallel activities, or splitting into parallel activities.
51

Process Modeling

UML Activity Diagrams: Example

Source: http://www.dotnetcoders.com/ web/learning/uml/diagrams/activity.aspx Original Source: OMG UML 1.4 Specification

52

Using Microsoft Visio to Create UML Activity Diagrams


Step 1: Choose File | New | Software | UML Model Diagram Step 2: Choose UML Activity from the categorized list of shapes on the left. Try Help | Microsoft Office Visio Help and type activity diagrams in the Search For box of the Assistance bar for more information.

Process Modeling

53

Process Modeling

Using Rational Rose to Create UML Activity Diagrams

Notice how each Activity Diagram is associated with one use-case (i.e. one high-level process).

Source: http://www.iqsoft.hu/termekek/rational/images/Image38.gif

54

Enterprise Data Model for Video


(Figure 7.5)
CUSTOMER RENTAL VIDEO
Requests Contains

Makes

Supplies

EMPLOYEE

VENDOR

EDM Metadata
Customer. A customer is a person who rents videotapes from Video. Before a customer can rent a video, the customer must become a member. A customer may make multiple rentals. Rental. A rental is the set of transactions for a customer to rent and return multiple video. Video. A video is a tape or CD that may be rented to multiple customers. Employee. An employee is a clerk, manager or other person employed by Video who may handle multiple rentals. Vendor. A vendor is a firm that may sell multiple videotapes to Video

S-ar putea să vă placă și