Object Oriented Analyis

1
C H A P T E R
8
PROCESS MODELING
2
Chapter Eight Process Modeling

• Define systems modeling and differentiate between
  logical and physical system models.
• Define process modeling and explain its benefits.
• Recognize and understand the basic concepts and
  constructs of a process model.
• Read and interpret a data flow diagram.
• Explain when to construct process models and
  where to store them.
• Construct a context diagram to illustrate a
  systems interfaces with its work environment.
• Identify use cases, external and temporal
  business events for a system.
• Perform event partitioning and organize events in
  a functional decomposition diagram.
• Draw event diagrams and merge those events into a
  system diagram.
• Draw primitive data flow diagrams and describe
  the elementary data flows and processes in terms
  of data structures and procedural logic
  (Structured English and decision tables),
  respectively.
• Document the distribution of processes to
  locations.
• Synchronize data and process models using a CRUD
  matrix.

3
Chapter Map
4
Models Logical and Physical
A model is a representation of reality. Just as a
picture is worth a thousand words, most models
are pictorial representations of reality.

• Logical models show what a system is or does.
  They are implementation independent that is,
  they depict the system independent of any
  technical implementation.

• Physical models show not only what a system is or
  does, but also how the system is (to be)
  physically and technically implemented. They are
  implementation dependent because they reflect
  technology choices.

5
Why Logical System Models

• Logical models remove biases that are the result
  of the way the system is currently implemented,
  or the way that any one person thinks the system
  might be implemented.
• Logical models reduce the risk of missing
  business requirements because we are too
  preoccupied with technical results.
• Logical models allow us to communicate with
  end-users in nontechnical or less technical
  languages.

6
Process Modeling and DFDs

• Process modeling is a technique for organizing
  and documenting the structure and flow of data
  through a systems processes, and/or the logic,
  policies, and procedures to be implemented by a
  systems processes.
• A data flow diagram (DFD) is a tool (and type of
  process model) that depicts the flow of data
  through a system and the work or processing
  performed by that system.
• DFDs have become a popular tool for business
  process redesign.

7
Simple Data Flow Diagram
8
Differences Between DFDs and Flowcharts

• Processes on DFDs can operate in parallel
  (at-the-same-time)
• Processes on flowcharts execute one at a time
• DFDs show the flow of data through a system
• Flowcharts show the flow of control (sequence and
  transfer of control)
• Processes on one DFD can have dramatically
  different timing
• Processes on flowcharts are part of a single
  program with consistent timing

9
Systems Thinking

• Systems thinking is the application of formal
  systems theory and concepts to systems problem
  solving.
• DFDs are a tool that supports systems thinking.

10
Process Concepts

• A process is work performed on, or in response
  to, incoming data flows or conditions.

• A System is a Process

11
Decomposition
System Decomposition

• Decomposition is the act of breaking a system
  into its component subsystems, processes, and
  subprocesses. Each level of abstraction reveals
  more or less detail.

12
Decomposition Diagrams

• A decomposition diagram or hierarchy chart shows
  the top-down, functional decomposition of a
  system.

13
Types of Logical Processes

• A function is set of related and ongoing
  activities of a business.
• An event (or transaction) is a logical unit of
  work that must be completed as a whole (as part
  of a function).
• An elementary process (or primitive process) is a
  discrete, detailed activity or task required to
  respond to an event. Usually, several such tasks
  must be completed to respond to an event.

14
Common Process Errors on DFDs
15
Problems with Natural English

PROBLEMS WITH NATURAL ENGLISH 1

• Many of us do not write well, and we also tend
  not to question our writing abilities.
• Many of us are too educated! Its often difficult
  for a highly educated person to communicate with
  an audience that may not have had the same
  educational opportunities. For example, the
  average college graduate (including most
  analysts) has a working vocabulary of 10,000 to
  20,000 words on the other hand, the average
  non-college graduate has a working vocabulary of
  around 5,000 words.
• Some of us write everything like it was a
  program. If business procedures required such
  precision, wed write everything in a programming
  language.
• Too often, we allow the jargon and acronyms of
  computing to dominate our language.
• English statements frequently have an excessive
  or confusing scope. How would you carry out this
  procedure If customers walk in the door and
  they do not want to withdraw money from their
  account or deposit money to their account or make
  a loan payment, send them to the trust
  department. Does this mean that the only time
  you should not send the customer to the trust
  department is when he or she wishes to do all
  three of the transactions? Or does it mean that
  if a customer does not wish to perform at least
  one of the three transactions, that customer
  should not be sent to the trust department?
• We overuse compound sentences Consider the
  following procedure Remove the screws that hold
  the outlet cover to the wall. Remove the outlet
  cover. Disconnect each wire from the plug, but
  first make sure the power to the outlet has been
  turned off. An unwary person might try to
  disconnect the wires prior to turning off the
  power!
• Too many words have multiple definitions.
• Too many statements use imprecise adjectives. For
  example, an loan officer asks a teacher to
  certify that a student is in good academic
  standing. What is good?
• Conditional instructions can be imprecise. For
  example, if we state that all applicants under
  the age of 19 must secure parental permission,
  do we mean less than 19, or less than or equal to
  19?
• Compound conditions tend to show up in natural
  English. For example, if credit approval is a
  function of several conditions credit rating,
  credit ceiling, annual dollar sales for the
  customer in question, then different combinations
  of these factors can result in different
  decisions. As the number of conditions and
  possible combinations increases, the procedure
  becomes more and more tedious and difficult to
  write.

Source Adapted from Matthies, Leslie, The New
Playscript Procedure, (Stamford, CT Office
Publications, Inc. 1977)
16
Structured English

• Structured English is a language and syntax,
  based on the relative strengths of structured
  programming and natural English, for specifying
  the underlying logic of elementary processes on
  DFDs.

17
Structured English Constructs (Part 1)
18
Structured English Constructs (Part 2)
complex logic in which rows represent conditions
19
Structured English Constructs (Part 3)
20
Policies and Decision Tables

• A policy is a set of rules that governs some
  process of the business.
• A decision table is a tabular form of
  presentation that specifies a set of conditions
  and their corresponding actions (as required to
  implement a policy).

21
A Simple Decision Table
22
Data Flows Control Flows

• A data flow represents an input of data to a
  process, or the output of data from a process.
• A data flow may also be used to represent the
  creation, reading, deletion, or updating of data
  in a file or database (called a data store).
• A composite data flow is a data flow that
  consists of other data flows.
• A control flow represents a condition or nondata
  event that triggers a process.
• Used sparingly on DFDs.

23
Data Flow Packet Concept
24
Composite and Elementary Data Flows
25
Data Flows to and from Data Stores
26
Illegal Data Flows
27
Data Structures

• Data flows can be defined by data structures.
• A data structure is a specific arrangement of
  data attributes that defines the organization of
  data contained in a data flow.
• A data attribute is the smallest piece of data
  that has meaning to the end-users of a business.

28
A Data Structure for a Data Flow

• DATA STRUCTURE
• ORDER
• ORDER NUMBER
• ORDER DATE
• PERSONAL CUSTOMER NUMBER,
• CORPORATE ACCOUNT NUMBER
• SHIPPING ADDRESSADDRESS
• (BILLING ADDRESSADDRESS)
• 1 PRODUCT NUMBER
• PRODUCT DESCRIPTION
• QUANTITY ORDERED
• PRODUCT PRICE
• PRODUCT PRICE SOURCE
• EXTENDED PRICE N
• SUM OF EXTENDED PRICES
• PREPAID AMOUNT
• (CREDIT CARD NUMBEREXPIRATION DATE)
• (QUOTE NUMBER)

ENGLISH ENTERPRETATION An instance of ORDER
consists of ORDER NUMBER and ORDER DATE
and Either PERSONAL CUSTOMER NUMBER or
CORPORATE ACCOUNT NUMBER and SHIPPING ADDRESS
(which is equivalent to ADDRESS) and
optionally BILLING ADDRESS (which is equivalent
to ADDRESS) and one or more instances
of PRODUCT NUMBER and PRODUCT DESCRIPTION
and QUANTITY ORDERED and PRODUCT PRICE
and PRODUCT PRICE SOURCE and EXTENDED
PRICE and SUM OF EXTENDED PRICES and PREPAID
AMOUNT and optionally both CREDIT CARD NUMBER
and EXPIRATION DATE An instance of ADDRESS
consists of optionally POST OFFICE BOX NUMBER
and STREET ADDRESS and CITY and Either STATE
or MUNICIPALITY and optionally COUNTRY and
POSTAL CODE
29
Data Structure Constructs
30
Data Structure Constructs (concluded)
31
Data Types and Domains

• Data attributes should be defined by data types
  and domains.
• A data type defines what class of data can be
  stored in an attribute (e.g., character,
  integers, real numbers, dates, pictures, etc.).
• A domain defines what values or range of values
  an attribute can legitimately take on.

32
Diverging and Converging Data Flows

• A diverging data flow is one that splits into
  multiple data flows.
• Useful for illustrating data that starts out
  naturally as one flow, but needs to be routed to
  parallel processes.
• Also useful for illustrating multiple copies of
  the same output going to different destinations.
• A converging data flow is the merger of multiple
  data flows into a single packet.
• Useful for illustrating data from multiple
  sources that must come back together for some
  subsequent processing

33
Diverging and Converging Data Flows
34
External Agents

• An external agent defines a person, organization
  unit, or other organization that lies outside of
  the scope of the project but that interacts with
  the system being studied.
• External agents define the boundary or scope of
  a system being modeled.
• As scope changes, external agents can become
  processes, and vice versa.
• Almost always one of the following
• Office, department, division inside the business
  but outside the system scope.
• An external organization or agency.
• Another business or another information system.
• One of your systems end-users or managers

35
Data Stores

• A data store is an inventory of data.
• Frequently implemented as a file or database.
• A data store is data at rest compared to a data
  flow that is data in motion.
• Almost always one of the following
• Persons (or groups of persons)
• Places
• Objects
• Events (about which data is captured)
• Concepts (about which data is important)
• Data stores depicted on a DFD store all instances
  of data entities (depicted on an ERD)

36
When to Draw Process Models

• Strategic systems planning
• Enterprise process models illustrate important
  business functions.
• Business process redesign
• As is process models facilitate critical
  analysis.
• To be process models facilitate improvement.
• Systems analysis (primary focus of this course)
• Model the existing system including its
  limitations
• Model the target systems logical requirements
  (meaning processes and data flows needed
  regardless of how the system will be implemented)
• Model candidate technical solutions (physical
  DFDs only)
• Model the target technical solution (physical
  DFDs only)

37
Classical Structured Analysis

• Draw top-down physical DFDs that represent the
  current physical implementation of the system
  including its limitations.
• Convert the physical DFDs to their logical
  equivalents.
• Draw top-down logical DFDs that represent an
  improved system.
• Describe all data flows, data stores, policies,
  and procedures in a data dictionary or
  encyclopedia.
• Optionally, mark up copies of the logical DFDs to
  represent alternative physical solutions.
• Draw top-down physical DFDs that represent the
  target solution.
• THE ABOVE METHODOLOGY IS RARELY PRACTICED
  ANYMORE BECAUSE IT IS VERY CUMBERSOME AND
  TIME-CONSUMING.

38
Modern Structured Analysis

• Draw a context DFD to establish initial project
  scope.
• Draw a functional decomposition diagram to
  partition the system into subsystems.
• Create an event-response or use-case list for the
  system to define events for which the system must
  have a response.
• Draw an event DFD (or event handler) for each
  event.
• Merge event DFDs into a system diagram (or, for
  larger systems, subsystem diagrams).
• Draw detailed, primitive DFDs for the more
  complex event handlers.
• Document data flows and processes in the data
  dictionary.
• THE ABOVE METHODOLOGY, BASED ON EVENT
  PARTITIONING, IS MORE COMMONLY PRACTICED.

39
Structured Analysis Diagram Progression (1 of 3)
40
Structured Analysis Diagram Progression (2 of 3)
41
Structured Analysis Diagram Progression (3 of 3)
42
CASE for DFDs (Sample Screen) from System
Architect 2001
43
SoundStage Context DFD
44
SoundStage Functional Decomposition Diagram
XOR_Cntr_1
45
Events

• Events define processes needed to respond to
  those events.
• External events are those initiated by external
  agents. They result in an input transaction or
  data flow.
• Temporal events are those that are triggered by
  the passage of time. They simply happen and
  are indicated by a control flow.
• State events are those based on a systems change
  from one state to another.

46
Use Cases

• Use cases are based upon object-oriented concepts
  that are essentially the same as events.
• Use case analysis is the process of identifying
  and modeling business events and how the system
  responds to them.
• An actor is anything that needs to interact with
  the system (essentially, a synonym for external
  agent).

47
Use Case List
Actor
Event (or Use Case)
Trigger
Responses




NEW MEMBER SUBSCRIPT
ION
Marketing

Establishes a new
Generate
SUBSCRIPTION

PROGRAM
membership subscription plan
.

PLAN CONFIRMATION
to entice new members.

Create
in the
AGREEMENT
database.

Marketing

Establishes
a new
Generate
PAST MEMBER
SUBSCRIPTION
membership resubscription
.

RESUBSCRIPTION PROGR
AM
PLAN CONFIRMATION
plan to lure back former
Create
in the
AGREEMENT
members.

database.

Marketing

Changes a subscription plan
Generate
SUBSCRIPTION PLAN
AGREEMENT
for current members (e.g.,
.

.

CHANGE
CHANGE CONFIRMATION
extending the
fulfillment
Update
in the
AGREEMENT
period)

database.

(time)

A subscription plan expires.
(current date)

Generate
AGREEMENT
.

CHANGE CONFIRMATION
Logically Delete (void)
in the da
tabase.
AGREEMENT
48
Use Case List (continued)
Actor
Event (or Use Case)
Trigger
Responses
Generate
Marketing

Cancels a subscription plan
.

before its planned expiration

CHANGE CONFIRMATION
CANCELATION

Logically Delete (void)
in the database.

AGREEMENT
Generate
Member

Joins the club by subscribing.

MEMBER
NEW SUBSCRIPTION
(Take any 12
CDs for one
DIRECTORY UPDATE
.

penny and agree to buy 4
CONFIRMATION
more at regular prices within
Create
in the
MEMBER
two years.)

database.

Create first
MEMBER ORDER
MEMBER ORDERED
s in the database.

PRODUCT
Generate
Member

hanges address


MEMBER
CHANGE OF ADDRESS
DIRECTORY UPDATE
(including email and privacy
.

CONFIRMATION
code)

Update
in the
MEMBER
database.

49
Use Case List (continued)
Actor
Event (or Use Case)
Trigger
Responses
Generate
Changes members credit
Accounts

CREDIT
CHANGE OF CREDIT STA
TUS
status

Receivable

DIRECTORY UPDATE
.

C
ONFIRMATION
Update
in the
MEMBER
database.

Generate
90 days after a Marketing
(time)

(current date)

CATALOG CHANGE
.

decides to no longer sell a
CONFIRMATION
product.

Logically Delete
(deactivate)
in the
PRODUCT
database
.

Generate
Wants to pick products fo
r
Member


CATALOG
PRODUCT INQUIRY
.

possible purcase.

DESCRIPTION
(Logical requirement is driven
by vision of web
-
based access
50
Event Decomposition Diagram (partial)
51
External Event DFD
52
External Event DFD (more complex)
53
Temporal Event DFD
54
System DFD (see book for more readable copy)
55
Primitive DFD (see book for more readable copy)
56
Data Structure for a Primitive Data Flow
57
Logic for a Primitive Process
58
8.30 Data to Process CRUD Matrix
59
8.31 Process to Location Association Matrix