Modeling Techniques

1
Modeling Techniques

• Dipl.-Wirt.Inform Holger Hansmann
• Department of Information Systems
• Steinfurter Str. 109, 48149 Muenster
• E-Mail ishoha_at_wi.uni-muenster.de

2
Agenda

• organizational modeling
• organization diagram
• functional modeling
• function decomposition diagram (FDD)
• data modeling
• entity relationship modeling (ERM)
• process modeling
• event-driven process chains (EPC)
• Petri-nets

3
Organizational Modeling
4
Information Objects in Organization Modeling
A) Organizational Unit
Accounting
External
Accounting
B) Position
Person
Staffing
G/L
Mr. Smith
Account
Manager
Personnel
Account
Mrs. King
Manager
5
Example Organizational Diagram
of a subsidiary / plant
Managing Directors
divisions
departments
giving orders
6
Functional Modeling
7
Function Decomposition Criteria
Enter Order
Enter Order
Perform Inventory
Perform Picking
Control Assortment
Process Order
Enter Third-Party order
using mobile scanner
Plan Picking
Sort Order
Enter Order
Plan Assortment
Enter Warehouse Order
Check Order
using cards
Control Assortment
Evaluate Order
Execute Picking
Calculate Order
Change Assortment
Save Order
Delete Order
Object
Tool
Level
Purpose
Activity
Phase
8
Example function decomposition diagram
vendor
vendor
Vendor type
purchasing
management
maintenance
vendor
views
vendor
roles
vendor
rating
item
management
condition
invoice
management
conditions
subsequent
settlement
quantity
contract
contract
management
value
contract
Scheduling
agreement
9
Process Modeling
10
Definitions

• Process
• A process is the self-contained, temporal and
  logical order (parallel and/or serial) of those
  activities, that are executed for the treatment
  of an economically relevant object with the goal
  of accomplishing a given task.
• This object determines the process, other objects
  can be relevant.
• Business Process
• Business processes are a subset of all processes.
• They represent a types of business transactions
  of a company, are derived from the companies
  strategic goals and require interactions with
  external business partners.

11
Process Model Definition

• A Process Model is defined as the abstract
  representation of a process to support the needs
  of a subject (esp. a designer of information
  systems and of organizations).
• Methods
• Petri-Nets
• Process-Event-Scheme
• Event-driven Process Chains
• ...

12
Example Simple Event-driven Process Chain (EPC)
Events (representing situations passive
elements)
Connectors
Functions (transforming a situation active
elements)
13
Extended EPC
Input Data
Organizat. Unit (responsible for performing a
task)
Enter products
Enter
provided by
new products
new suppliers
XOR
Product
Distribution
Assign
product to
sales office
Merchandise
Order Record
handling
software
Product
Output Data
Applications System
assigned
14
Basic Modeling Elements (1)
? example
15
ARIS - Architecture- Elements of the process view
Organizational Unit
An Organizational Unit describes one or more
human resources.
Organizational Unit
Organizational Unit
16
ARIS - Architecture- Elements of the process
view
Function
The Process Navigator serves as an interface
symbol for previous or later process models. It
may only stand at the beginning or the end of a
process model and has to be connected to events.
Process
Navigator
17
ARIS - Architecture- Elements of the process
view
Special Term
A Special Term defines company-relevant objects,
which arerelevant for the definition of the
enterprise structure (no functions!)
Special Term
FB
18
Additional Modeling Elements (2)
19
Connectors in EPCs
20
ARIS - ArchitectureView integration through the
EPC
Function
Event-Driven Process Chain (EPC)
Data
Organization
21
Control flow and data flow
Triggering
Function view
Input data
Output data
Execution
Transformation
Triggering
Data view
Generation
Processing
Execution
Data
Data flow
Data
Transformation
Data
Transformation
Application data flow Execution of functions
based on use data, their generation and
changes Control data flow Control of processes
between executable functions

22
Event/State-Orientation
Function
Triggering event
Provision event
IO
IO
Meeting the condition for the execution of the
function
Creation of control data for the
following activities
State transition

• Event
• Entry of a state in the information system, that
  determines the further sequence of activities
• Related to a specific moment
• Passive component

23
ARIS - ArchitectureRefinement of an EPC
24
Notation Rules for Event-driven Process Chains
(EPC)

• As basic elements functions, events and
  connectors can be found.
• Every process model starts and ends with one or
  more events.
• Functions never follow functions (??), events
  never follow events.
• In basic EPCs the three connectors AND,
  exclusive-OR (XOR) and inclusive-OR (IOR) have to
  be distinguished.
• An event is never followed by an OR-connector.
• Various symbols can be added to EPCs (e.g.
  input-/output-data, organizational units,
  application systems).

25
ARIS - ArchitectureConnector rules for the EPC
(1/2)
Event- connections
XOR
XOR
26
ARIS - ArchitectureConnector rules for the EPC
(2/2)
Function- connections
27
Conditions for the Efficient Use of Process Models

• Awareness of process orientation
• Use of a suitable method
• High competence in methods
• Requirements meeting standards
• Efficient modeling tools

28
Range of Use for Process Models

• Business Process Reengineering
• Description of organization (ISO 9000)
• Software functionality description (R/3 Analyzer)
• Software Customizing
• Software Design (process-based-CASE)
• Workflow Management
• Project Management
• Process Cost Accounting
• Description of Sector characteristics

29
View Integration withEvent-Driven Process Chains
Process View
Data View
Business Process Layer 0
Special term model
Organizational View
Organization Chart
Subprocess Layer 2-n
IT-View
Event
IT-HW/SW
IT-Org
OrgUnit
Function
IT-App.sys
Event
30
Data Modeling
31
Data Modeling

• Data modelSummary / structured description and
  analysis of all information objects, that are
  needed and used in a business company or rather
  for an information system.

32
Data Modeling Methods

• ERM Entity-Relationship-Model (Chen 1976)
• eERM Extended ER-Model
• SERM Structured Entity-Relationship-Model
• SAP-SERM Structured Entity-Relationship-Model
  used by SAP R/3

33
Data Modeling Methods

• There is no standard for the ER method.
• The most widely known model is Chen's
  entity-relationship (ER) approach.
• Nearly all data modeling approaches are very
  similar because they share common concepts.
• it is more important to understand the concept
  than the actual method

34
Information Objects in Entity Relationship Models
35
Generalization

• The entitytype that forms the superclass
  summarizes the common attributes of the members
  of the subclass(es)
• specialization defining subclasses (on the basis
  of certain characteristics, e.g. job
  type)subclass inherits all attributes from the
  superclass, but can have additional attributes of
  its own
• also known as the Is-a-relationship
• necessity for the generalization
• certain attributes may only apply to some
  entities of the superclass entity type
• some relationship types may be participated in
  only subclasses

36
Principles of AbstractionGeneralization and
Specialization
Superclass
Subclasses
37
Principles of Abstraction Aggregation
is the representation of one entity type that is
the combination of more than one existing entity
types beyond the relationship a new highly
valuable information object comes into being
38
Hierarchy as a Special Way of Recursion
39
Structure as a Special Way of Recursion
40
Re-Interpreting of Relationship Types
41
QuestionWhat is SAP SERM?
42
SAP-SERM

• Comparison SAP-SERM / ERM

43
SAP-SERM

• Kinds of relationships
• specialization
• hierarchical
• aggregative
• referential
• conditional-aggregative
• conditional-referential
• temporary-referential

44
SAP-SERM

• Generalization/Specialization relationship

45
SAP-SERM

• Hierarchical relationship
• the existence of one entity type depends on the
  existence of another entity type
• the key of the left entity is also a key of the
  right one

(SID, SAID)
(SID,)
46
SAP-SERM

• Aggregative relationship
• at the same time one entity type is created with
  at least two ingoing entity types.
• the existence of the entity type depends on the
  existence of the ingoing entity types
• the keys of the left entities are also keys of
  the right one

47
SAP-SERM

• Referential relationship
• one entity type refers to another entity type
• the dependent entity type depends on this
  referenced entity type existently, but not
  identically(marketing way is not identifyingthe
  trade action like TTA and Time)
• here marketing way is a not-key-attribute of
  trade action

48
SAP-SERM

• Conditional-aggregative relationship (1/2)
• like aggregative relationship, but theincoming
  entity type is only optionally involved.

49
SAP-SERM

• Conditional-aggregative relationship (2/2)
• branch and department (aggregative) (build time)
• only branch (hierarchical) (build time)
• both ways, decision at run time

50
SAP-SERM

• Conditional-referential relationship
• like the referential relationship but with the
  restriction, thatthe referential relationship is
  optional (null value possible).

51
SAP-SERM

• Temporary-referential relationship
• is the weakest kind of the referential relation.
  It can change as well as do not necessary exist
  at times.