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

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

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

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

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

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

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

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

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

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

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

(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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Filling the OET: starting point 17:57

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

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

OET after propagation 17:57

Propagation Rule 2 1 1 17:57

Example: Order Administration 4 3 3 Propagation in EDG: from BOTTOM to TOP 2 2 1 1 17:57

17:57

Type of Involvement Rule Q 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

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

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

Propagation in JMERMAID 17:57

Propagation in JMermaid 17:57

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

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

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

Contract Rule 17:57

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

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

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

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

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