Eran Toch

1
Object Process Methodology(OPM)
Day ?
October 2007

• Eran Toch
• http//www.technion.ac.il/erant

2
Agenda
3
Model Aspects
External / Internal
Events / Sequential
Physical / Informatical
e
4
Notating Aspects
Essence is an attribute of a thing that
determines whether the thing is physical or
informatical.
Informatical Object
Informatical Process
Phyisical Process
Phyisical Object
5
Model Aspects
External / Internal
Events / Sequential
Physical / Informatical
e
6
Environmental Notation
External Thing
Internal Things
7
Aspect Matrix
8
Model Aspects
External / Internal
Events / Sequential
Physical / Informatical
e
9
Events
External Systems
Event Generator, which is environmental,
triggers Triggered Process.
10
State Change
C triggers Triggered Process when its state
changes.
11
State entrance event
S triggers Triggered Process when it enters s3.
12
Process Timeout Events
Invoking Process triggers Min Constraint Handling
when it lasts less than Tmin and Max Constraint
Handling when it lasts more than Tmax.
13
State Timeout Events
S triggers Min Constraint Handling when s1 lasts
less than Tmin and Max Constraint Handling when
s1 lasts more than Tmax.
14
Agenda
15
There are no free meals
There is a tradeoff between clarity and
completeness
16
System Hierarchy
System Process
SD
SD-1
Zoomed-in Process
SD-2
SD-3
Leaf Process
17
SD (System Diagram - Top Level)
18
SD-1
19
SD-2
Every two things can have a single link between
them on the higher level
20
Top Level

• The top level diagram (SD), should contain
• A single process that represents the system
• External entities, and
• System Input / Output

This is only a guideline! Some examples might
not follow it
21
Unfolding

• Each thing in OPM can be unfolded in order to
  reveal more details

Unfolding
Folding
22
Structural Aggregations
Exposing structural relations and connected
elements
Unfolding
Folding
23
Unfolding
24
Unfolding contd
25
State Suppression and the Effect Link
State Suppression
State Expression
Lighting changes Lamp from off to on. Lighting
affects Lamp
OPL
26
Links precedence
27
Agenda
28
Methodology
How to model?
Bottom-up
Top-down
29
An Example of Top-Down Approach
Analyzing Scope
Modeling main processes
Modeling Main Data Objects
Modeling Conditions / States
Refining objects
Refining Processes
30
How to Model?
Combined
31
Combined
Analyzing Scope
Modeling main processes
Modeling Main Data Objects
Modeling Conditions / States
Refining objects
Refining Processes
32
Agenda
33
Working with Processes

• Push-down a process to a more detailed level
• Pulling up a process to a more abstract level

Ordering
Entering details
Entering details was pushed down
Entering details
Ordering
Ordering
Entering details
Entering details was Pulled up
Supplying
Supplying
34
Rules of Thumb for Combining Processes

• We will aspire for a diagram to have between 3 to
  7 processes
• We will aspire to get a balanced object
  distribution between process of a given diagram
  
• a similar scale of the number of related objects

35
Rules of Thumb for Dividing Processes

• If a process has connections with objects that do
  not take part in a given interaction, maybe the
  sub-processes should be divided
• If processes are executed in different time modes
  batch vs. online executions, then maybe they
  should be divided
• If processes do not share objects then maybe they
  should be divided

P2
P1
36
Process Dependency

• Three types of dependencies between processes
• Strong dependency When a process B is performed
  each time a process A occurs
• Weak dependency A generates some data which is
  later used by B
• Independence B does not use any data generated
  by A

P
A
B
Obj
A
B
37
Processes that should be Avoided

• Physical processes (depends on scope)
• If the system is concerned only with the data,
  then the physical processes should be avoided
• For instance, if the supply system sends a
  message to a worker to move a package, the system
  itself does not move the actual package this is
  not a process
• We are not coding! Avoid technical details, such
  as
• File and database handling
• Maintenance jobs
• Input verification
• Presentation

38
External Entities

• Sometimes the entity is the system itself.
• If you find a very large number of entities,
  maybe they should be grouped to a more general
  entity
• For instance, if some reports are sent to
  different clerks, the distinction between the
  clerks is not always important. All these clerks
  can be unified into a single entity
• Entities can have a unidirectional connection
  with the systems
• Only receiving data
• Only supplying data

39
Data Objects Design

• Aggregating data into a data store
• When the data has strong semantic proximity
• When the objects are always used together
• When the objects are accessed frequently by a
  single process
• Dividing data
• When semantic differences can be clearly defined
• When objects are too complex

40
Agenda
41
Example
Online Banking