1. The Object-Event Table
Architecture and Modelling of Information Systems (D0I71A)
Prof. dr. Monique Snoeck

2. Course Overview Introduction
Basics of Enterprise Modelling (Domain Model)
Overview of the approach
Enterprise Object Types: EDG Basics
Atomic activities: OET Basics
Life cycles: FSM basics
Refining & extending the model
Refining: Adding attributes & constraints
Extending to the upper layers: Information Services, Business Processes
17:57

3. Session Overview What is a business event ?
The Object-Event Table (OET)
Consistency with the EDG
17:57

4. Behavioural Modelling in UML
Modelled as dynamic features of a Class
Modelled as sequences of messages exchanged between objects
 fine grained modelling
 not practical for Enterprise Modelling
Interaction scenario’s can’t be modelled completely when only enterprise layer is considered.
More a design activity than a requirements engineering activity
pertains to the solution (HOW) more than to the problem (WHAT)
17:57

5. Modelling Behavioural aspects in UML
OO  Message Passing: 1 event - 2 Objects
Collaboration Diagrams
Interaction Diagram
Interaction scenario is incomplete because other layers are missing when considering EM only.
borrow
COPY
MEMBER
borrow
COPY
MEMBER
(c) Monique Snoeck 17:57

6. Modelling Behavioural aspects in UML
Collaboration Diagram
Interaction Diagram
both message oriented
 OO platform specific !
(c) Monique Snoeck 17:57

7. Interaction scenario’s contain too many non-RE aspects
Check payment
cr_order
Can you ship this ?
Check Customer
blacklist
Check Stock
Yes I can !
Confirm Order
Do Shipping
Ship it !
Shipped !
Pay
make invoice
Invoice
Payment OK!
Thank you
and see you
again !
transfer Money
Customer
Supplier
Shipper
Bank
Some sequences reflect coordination: notification & validation
Some sequences reflect business process
Part of scenario is requirements oriented
Part of scenario is design-oriented
 too much intertwining of different aspects
 Separate concerns to master complexity
(c) Monique Snoeck 17:57

8. Behavioural aspects in Enterprise Modelling
Business Process Modelling
Processes are decomposed into tasks
Tasks affect/use business objects
 there’s a need for mapping processes/tasks to business objects
Tasks can be similar
Similar because affecting the same business objects in the same way
But different (for example) in terms of “user channel”
E.g. transfer of money using online banking, using an ATM machine, using bank clerk’s application, …
Need for identification of reusable “unit of behaviour”, independent of work organisation aspects
”Business Event”
17:57

9. Behavioural aspects in Enterprise Modelling
Direct mapping from BP Task to (EL) Class features
BP1
BP2
Task 1
Task2
Business Object Type
Feature1
Feature 2
...
Business Object Type
Feature1
Feature 2
...
Business Object Type
Feature1
Feature 2
...
Business Object Type
Feature1
Feature 2
...
Business Object Type
Feature1
Feature 2
...
17:57

10. Behavioural aspects in Enterprise Modelling
Mapping using business events as hinge bricks between the BP layer and the EL
BP1
BP2
Task1
Task2
Business Event 1
Business Event 2
Business Object Type
Feature1
Feature 2
...
Business Object Type
Feature1
Feature 2
...
Business Object Type
Feature1
Feature 2
...
Business Object Type
Feature1
Feature 2
...
Business Object Type
Feature1
Feature 2
...
17:57

11. What is a Business Event ?
something that happened (Kim Clijsters won from Venus Williams)
something that happens (I’m withdrawing money with an ATM)
a concept (a payment)
a request to register a real world event in the IS: register student subscription
note: a request can be refused
Discern between
notification
activity
concept
request
All these concepts are linked together
17:57

12. (In Merode) A Business Event is ...
A request to perform an activity to register something that happens or that you would like to happen in the real world.
“business” = in the real world  Not technology-event like mouse click, keyboard stroke, insert card in machine, ….
“event”  registration should be processed in its entirety to maintain consistent state
Business Events are abstracted into event TYPES. An event TYPE is a template for an individual event. A business event CLASS is a set of business events with the same characteristics, that conform to the same TYPE.
17:57

13. Good practices in RE Requirements should be action based
Use of business events is in line with this principle
Requirements should describe what happens in the interface between environment and the machine
Stated differently: requirements should explain how the mirroring (of the real world into the IS) should work
Distinguish between
Shared versus unshared events
Machine controlled versus environment controlled events
17:57

14. Example “Environment” = physical library “machine” = Library system
17:57

15. Example
Shared action, environment controlled
Borrowing a book
17:57

16. Example UNShared action, environment controlled start reading a book
17:57

17. Example Shared event, machine controlled
Automatic renewal 1 day before return deadline
Unshared event, machine controlled
(you don’t want to know about these)
17:57

18. In summary, a business event
is an action shared between the real-world and the information system;
can be both environment-controlled and machine-controlled;
combines the notion of a request and an atomic action: it is the request to perform an action in its entirety, namely, to register the occurrence of an event in the real world in the enterprise information system; the request can be refused.
E.g. “Borrowing a book”
request to borrow can be refused
if accepted, borrowing is registered. Registration is an activity: updates state of member, of copy, creates a loan-object
Loan-object represents event as a concept
17:57

19. Session Overview What is a business event ?
The Object-Event Table (OET)
Consistency with the EDG
17:57

20. The Object Event Table identifies Business Event Types
identifies Object Types
models participation of Object Types to Business Event Types with an Object-Event-table
(Decide on notification & coordination pattern later at implementation time)
17:57

21. The Object Event Table
In Merode, a business event is a request + an activity
request can be refused
 when filled, a cell specifies what preconditions are imposed on a business event by a business object type
activity is distributed across participants
(assuming that the request has been accepted)
 when filled, cell specifies what the effect is of that business event on the participating business object type (modified attributes, operation to call)
17:57

22. The Object Event Table: example
X1 = condition to accept request: Customer not blacklisted ? Activity: nil
X2 = Condition to accept request: nil Activity: Create Order
X3 = Condition to accept request: Enough Stock ? Activity: adapt stock level
register Order
Invoice
Pay
Ship
CUSTOMER
PRODUCT
PAYMENT
ORDER
X1 X2 X3
17:57

23. The Object Event Table: Event versus method
Order
OrderLine
Product
ModifyQuantity x …
EVENT
Order
OrderLine
Product
modify_quantity
modify_quantity
modify_quantity
METHOD
METHOD
METHOD
17:57

24. Session Overview What is a business event ?
The Object-Event Table (OET)
Consistency with the EDG
Propagation rule
Type of involvement rule
Contract rule
Multiple Propagation
17:57

25. Propagation rule: Why ?
example: copy and member involved in borrow, renew, return
 OET identifies all potential places for effects and verifications
 Propagation rule is an OET filling rule & contributes to the completeness of requirements analysis
Examples:
renewal is allowed if there is no reservation --> to be checked by copy
count the number of times a book has been borrowed--> to be counted by copy
member can borrow books provided (s)he has no more than 1 late returnal of a copy --> to be checked by member
17:57

26. Propagation Rule
All the object types that participate in 1 event type are always interconnected through ED relation
Owner of the event type is the lowest object type in de ED graph (that is to say: most existence dependent)
17:57

27. Filling the OET: starting point
Identify the business events
ensure that each object type has at least one creating event type and one ending event type
Determine the "owner" object type of a business event.
This is the lowest object type in the EDG that is involved in a business event
Ship an order line (=a part of an order) or ship an order (entirely) ?
17:57

28. Filling the OET: starting point
17:57

29. Identification of business events and Object-Event Table (OET): owner participations
17:57

30. Propagation Rule
"Propagate" participations according to ED relationships
A dependent cannot exist without a master.
So, each master is by definition involved (directly or indirectly) in all the business events its dependent object types are involved in.
Each master can define its own constraints & effects
“Owned” participation: O/C, O/M, O/E
“Acquired” participation: A/C, A/M, A/E
Propagation is transitive
from dependent to the master and the master of the master and the master of the master of the master and ...
17:57

31. OET after propagation
17:57

32. Propagation Rule 2 1 1
17:57

33. Example: Order Administration4 3 3
Propagation in EDG: from BOTTOM to TOP 2 2 1 1
17:57

34. 17:57

35. Type of Involvement RuleQ Q
A/C
A/M
A/M
A/M
A/M
A/E Q 1
O/C
O/E
0..*
O/C
O/E P P
P's
O/C
O/E
17:57

36. Type of Involvement Rule
Let P depend on Q
Propagation Rule: P participates in event e  Q participates in event e
Type of Involvement Rule:
e creates P-object  e creates or modifies corresponding Q-object
*/C becomes A/M (default) or A/C
e modifies P-object  e modifies corresponding Q-object
*/M becomes A/M
e terminates P-object  e terminates or modifies corresponding
Q-object
*/E becomes A/M (default) or A/E Q Q 1
0..* P P
17:57

37. ONE C-M-E = ONE instance
= ONE instance of this class participates
WRONG: NOT ATOMIC (can be split into many close_registration events)
O/M
O/E
WRONG: NOT ATOMIC (can be split into many end_registration events)
17:57

38. Propagation in JMERMAID
17:57

39. Propagation in JMermaid
17:57

40. to show propagation path Double Click (left) to Pop Up method dialog
OCL or Free Text
Right Click
to show propagation path
Double Click (left) to Pop Up method dialog
17:57

41. When the EDG tab is clicked while the Propagation Dialog is active, the propagation path will also be drawn on the EDG screen. The Objects, Dependencies and Inheritances in the path will be colored.
17:57

42. Contract Rule Informally: Contract Rule:
When do people have a relationship ?
... when they do (a lot of) things together
Model a long lasting relationship as a class (cfr. UML AssociationClass)
Contract Rule:
If 2 classes share 2 or more event types, there must be a common dependent class that is involved in these event types.
17:57

43. Contract Rule
17:57

44. Contract Rule: WRONG OET
member
copy
loan
enter
O/C
leave
O/E
acquire
classify
O/M
borrow
A/M
renew
return
sell
reserve
?/M
cancel
fetch
lose
A/E
17:57

45. correct OET for the Library
member
copy
loan
reser- vation
enter
O/C
leave
O/E
acquire
classify
O/M
borrow
A/M
renew
return
sell
reserve
cancel
fetch
A/M, A/M
lose
A/E
17:57

46. Multiple Propagation
Results in Multiple Instances participating in 1 Event Type
Happens when we have 2 paths from a dependent to one master
17:57

47. Multiple propagation
Two interpretations for person.marry (called “Aliases”)
Wife: precondition: Gender = female
Husband: precondition: Gender = male
17:57

48. Multiple Propagation
When paths yield same object, one interpretation will suffice
Cfr. section 7.7 Aliases
17:57