a conceptual data model is a process model too · let's talk about the item in your basket?...

A Conceptual Data Model is a Process Model too

Monique Snoeck

1

Separate worlds?

Conceptual Data Modelling

• (E)ER• Niam

• Class diagrams• Ontologies• OntoUML

• ...

Business Process Modelling

• Petri Nets• BPMN

• Activity Diagrams• Declare• CMMN• IDEF• ...

2

Separate worlds?

Business Process Modelling

• Petri Nets• BPMN

• Activity Diagrams• Declare• CMMN• IDEF• ...

Sebastian Steinau et al.Software & SystemsModelinghttps://doi.org/10.1007/s10270-018-0695-0

3

Separate worlds?

Conceptual Data Modelling

• (E)ER• Niam

• Class diagrams• Ontologies• OntoUML

• ...

4

5

Separate worlds?• Asymmetry:

• Process Modelling seems NOT (totally) agnostic of data• Data Modelling seems agnostic of Process Modelling

• For good reason ...• In software architecture:

• the process layer will use the data layer• the data layer will NOT use the process layer

5

6

Separate worlds?

• The data layer does not invoke the process layer, but ... Nevertheless:The data model does imply a number of sequence constraints on tasks.

• A process model defines a set of scenarios• e.g.

defines the scenarios {X.Y, X.Z}

• A data model defines a set of allowed scenarios too

6

7

Separate worlds• A data model defines a set of scenarios.

• The Business Processes also define scenarios.• The Business Processes are constrained by the Data Model.

These Business ProcessScenarios will always berefused by theData Model

7

8

Process model defined by the CDM• CDM & BPs of A web shop ...

Basket

8

CDM and BPs of a Web Shop

Basket

Create Terminate/EndUpdate/Modify

9

CDM and BPs of a Web Shop

Customer

10

CDM and BPs of a Web Shop

Customer Basket1..1 0..*

(frozen)

11

CDM and BPs of a Web Shop

Customer Basket1..1 0..*

(frozen)

"0..*" = unbounded interleaving of Baskets as a subprocess of Customer

12

CDM and BPs of a Web shop

Customer Basket1..1 0..*

(frozen)

Note: the semantics of the MI parallel marker is not a correct match with the semantics of "Parallell interleaving (0..*)". BPMN has no correct symbol for this.This can be expressed with PNs

14

CDM and BPs of a Library

Person Loan1..1 0..*

(frozen)

Book1..1

(frozen)

0..1

"0..1" = Iteration (with gaps) of Loans as a subprocess of Book

15

CDM and BPs of a Library

Loan Book1..1

(frozen)

0..1

16

CDM and BPs of a Library

Loan Processes

17

CDM and BPs of a Web Shop

Basket Product

18

CDM and BPs of a Web Shop

Basket Product0..* 0..*

19

CDM and BPs of a Web Shop

Basket Product0..* 0..*

add to basket

add to basket

add to basket

remove from basket

20

21

Let's talk about theitem in your

basket?Was it delivered? cancelled? Paid?

Basket

Product

22

Basket Product0..* 0..*

add to basket

add to basket

add to basket

remove from basket

BasketItem

23

CDM and BPs of a Web Shop

Process Nesting(M. Jackson:

"Marsupial Entity")

24

25

CDM and BPs of a Web Shop• In MERODE, the reification is required,

until an "Existence Dependency Graph" (EDG) is obtained

• EDG is a "DAG"• "Top Down Level" of the class can be

visualised.• The TDL number coincides with the process

nesting level.

• "Top-down" arrangement of the classes makes it easy to "see" the implied"business process" playground.

25

Example: Order Administration

26

0

1

12

3

4

0

1

0

1

2

3

4

27

Seeing the BP in the Class Diagram• Event Management

CDM as submittedQuite impossible toquickly evaluate ...

Are Ticket Types & their associated

permissionsdefined before or

after inviations are sent to the guests?

27

28

Seeing the BP in the Class Diagram• Event Management•Re-arranged CD+ adding of TDL

28

29

• 0: People• 1: Per Client: Event• 2: Per event:

• Website, mgr, Area's, groups of ??, invitations

• 3-4: In parallel• Invitees, then Guests• Permission Classes, then Assigned Areas

• 5-7: ticketing, then identifiers, then permissions & area presence

29

Seeing the BP in the Class Diagram

1. Define Event

2. Define the Ticket Categories per Event

3. Issue invitations per category

4. Issue tickets per invitation

1. Define the event

2. In parallel, per event:• Define Ticket

Categories• Issue invitations

3. Issue Tickets per invitation in category of choice

Different class diagrams support different business processes. When defining the class diagram, one should be aware of the implications a modelling choice has on the BP layer

30

31

BP Modelling versus Class Diagram• A Class diagram is a "behavioural model"

• Class on mandatory side of an association exists first• Tasks that triggers creation event of mandatory objects come first• Tasks that triggers creation of dependent come next• “Top-down” organisation of class diagram gives sequences of tasks

• Mandatory Class is deleted last• "ending" happens in reverse order.

A domain model (UML Class diagram) is NOT "just structure": it also implies some behaviour.

31

32

BP Modelling versus Class Diagram• Some business objects are a direct representation of a business process

32

Introducing Object Orientation:object lifecycles

Basket

Update/Modify:ConfirmShipPay

Create Terminate/End

33

Introducing object lifecycles

Basket

Update/Modify:

These actions do not occur in a random order

ConfirmShipPay

Create Terminate/End

34

Introducing object lifecycles

Update/Modify:

Basket

ConfirmShipPay

Create Terminate/End

35

BP versus OLC: example

36

37

BP versus OLC: example"Customer pays invoice" BP Perspective

Customer performs payment TASK pay in BP of customer (subject of verb)

OLC perspectiveinvoice is paid event "Pay" triggers transition in OLC of invoice (object of verb) to state "Paid".

37

Domain Layer

LOAN

borrow

COPY

MEMBER

....borrow()...

TITLE

...borrow()

...

borrow return, lose

renew

acquire lose, dispose

borrow,return,renew

classify

38

39

BP versus Object Life Cycles• BP: group behaviour according to aspects of work organisation• FSM: group behaviour per business object type

Object Type A

Object Type B

Object Type C

Object Type D

XY

Z

X

Y

X

YZ

XYZ

Y Z

39

Positioning in the Zachman Framework

40

1

2

3

Contextual/Scope

Conceptual/Enterprise

Logical/IS Functionality

WhyWho WhenWhereWhat How

Business Process Model

Domain Model:- information content of the business components - rules managing the relations between business components

Domain Model:- rules managing the behavioural aspects of business components

EnterpriseModel

41

BP versus OLC: example• Basket Management

?

41

42

Compatibility checks required• Global behaviour of Domain Layer

• Behavioural aspects of existence dependency• Parallel composition of FSMS of single object types• Synchronisation by means of joint participation to events• Additional constraints such as EDG Cardinality, Referential Integrity, Preconditions

• Behaviour induced by Business Process Layer

42

Compatibility between Business Process Models and Object Life Cycles needs to be managed as well

Scenarios accepted by the domain model

Business process scenarios accepted by the domain model

Scenarios not used by business processes

Business process scenarios rejected by the domain model

Scenarios modelled by the business process models

CDM scenarios versus BPM scenarios

43

The CDM sets the boundaries of what is possible

44

Business Processes

Conceptual Data Model

How it is mostly considered

Conceptual Data Model

Business Processes

How it is in terms of Scenarios & Rules ....

45

Discussion• Good Conceptual Modelling requires

• managing cross-model quality• managing the different perspective simultaneously

• M. Jackson "The World & The Machine"• Modelling is also about engineering OF the world

• Process/behavioural view of the CM cannot be underestimated• See again Jackson: it should be about the shared events• ==> that kind of behaviour is NOT about work organisation/Business processes

45

Implications for training good modelers

46

47

Good Conceptual Modelling requires• managing cross-model quality

• Formal Foundations

• managing the different perspective simultaneously• Tool Support !• Educational Support !

48

Managing cross-view Consistency• "Existence Dependency" allows arranging Object Types in a DAG

• Existence Dependency builds on the notions of • "Weak Entity" from ER modelling• "Marsupial" from Jackson Systems Development• Set inclusion "⊆" of Formal Languages (a JSD diagram is a regular expression)• Notion of "more deterministic than" (≤) for processes

• This maps to a mathematical "Lattice" structure• Combine Relational Algebra• With Process Algebra

• MERODE relies on "CSP" from C.A.R. HOARE to define the behavioural aspects of object types

49

Tool support• Understanding & managing the different perspective simultaneously is really

HARD !• Using Existence Dependency simplifies the set of modelling concepts

• The modelling language is smaller• Code generation becomes easier

• Educational support:• Simulation• Built-in Feedback: explaining application behaviour based on the model• Experiments demonstrate that fast prototyping and adding feedback to the prototype

improves models understanding

• See http://merode.econ.kuleuven.be/ for resources

50

MERODE & MDE• Create Model

• Generate Prototype to validate model• E.g. Library Model

MERODE Prototyping

51

52

MERODE Prototyping

53

MERODE Prototyping

World & MachineFour facets of the relationship

ModelsInterfaceEngineeringProblem

54

Model of

Rob Stevens

Relationship between the World & the Machine: Models

15:40 55

Organisation“Real World”

Output

Information System“mirror”

Input

56

Four Facets of the relationship• Models to simulate and have information about the World & the Machine

• The machine embodies a model or a simulation of some part of the world. • There are data models, object models, process models. • Provides efficient and convenient access to information about the world.

What's in the World? What's in the Machine ?• Where's the copy of my old book ?

• KULeuven's library system: • At Home?

57

Rob Stevens

Relationship between the World & the Machine: Interface

• What is mirrored? • What is captured and what not?

• Student registers for a course• Student attends a class?• Student coughing in class

Organisation“Real World”

Output

Information System“mirror”

Input

58

Relationship between the World & the Machine: Engineering

• What to control?

• Student registers for a course?• Student borrows a book?• Student steals a book?

Organisation“Real World”

Information System“mirror”

Input

Output

59

60

Four Facets of the relationship• Models to simulate / have info about the World

• Interfaces define what phenomena are shared between the world and the machine

• The engineer must understand the properties of the world and manipulate and exploit those properties to achieve the purposes of the system

"He died last week". "He doesn't exist any more"

The Interface facet & the Engineering facet require us to deal withbehavioural aspects as well

Wrap up• A data model is a business process

model too• Because objects have behaviour

• Default• Defined via OLC

• Because objects are related• Relationships put constraints on

behaviour• Because objects represent (parts of)

business processes

• Awareness of the CDM behaviouralpart is important because

• It defines the "playground" for BPs• Could be too restrictive or not restrictive

enough• Consistency with Business Processes

needs to be managed

• Reflecting about the "shared phenomena" is needed to establish a proper relationship between the World and the Machine

61

• MERODE offers a concrete methodology & tool support for "behaviour-aware" conceptual data modelling

62

Useful references• The World & the Machine:

• M. Jackson, The world and the machine, in: 1995 17th International Conference on Software Engineering, IEEE, 1995, pp. 283–283

• MERODE - BPModelling• M. Snoeck, Enterprise Information Systems Engineering: The MERODE Approach, Springer• M. Snoeck, G. Dedene, Existence dependency: The key to semantic integrity between structural and behavioral

aspects of object types, IEEE TSE, 24, 233-251, DOI: 10.1109/32.677182• R. Haesen, M. Snoeck, W. Lemahieu and S. Poelmans, "Existence Dependency-Based Domain Modeling for Improving

Stateless Process Enactment," 2009 Congress on Services - I, Los Angeles, CA, 2009, pp. 515-521, doi: 10.1109/SERVICES-I.2009.19.

• Snoeck, M., Poelmans, S., Dedene, G. (2000). An architecture for bridging OO and business process modelling. In: R. Mitchell, J.M. Jezequel, J. Bosch, B. Meyer, A.C. Wills, M. Woodman (Eds.), TECHNOLOGY OF OBJECT-ORIENTED LANGUAGES - TOOLS 33, PROCEEDINGS, (132-143). ISBN: 0-7695-0732-8. doi: 10.1109/TOOLS.2000.848757

• Snoeck, M., Poelmans, S., Dedene, G. (2000). A layered software specification architecture. In: Conceptual modeling, ER 2000, proceedings: LNCS vol. 1920, (454-469).

62

63

Useful references• MERODE :

• Teaching• Bogdanova, D., Snoeck, M. (2019). CaMeLOT: An Educational Framework For Conceptual Data Modelling. Information and

Software Technology, 110, 92-107. doi: 10.1016/j.infsof.2019.02.006• Bogdanova, D., Snoeck, M. (2020). Oops, I did it again: exploring frequent errors of novice data modellers, Sosym (in review)• Bogdanova, D., Snoeck, M. (2020). Where online and face-to-face learning meet: a universal architecture for agile teaching,

Computers & Education (submitted).• Tooling - Impact of Simulation on Learning

• Sedrakyan, G., Snoeck, M., Poelmans, S. (2014). Assessing the effectiveness of feedback enabled simulation in teaching conceptual modeling. Computers and Education, 78, 367-382. doi: 10.1016/j.compedu.2014.06.014 Open Access

• Sedrakyan, G., De Weerdt, J., Snoeck, M. (2016). Process-mining enabled feedback: “tell me what I did wrong” vs. “tell me how to do it right”. Computers in Human Behavior, 57, 352-376. doi: 10.1016/j.chb.2015.12.040 Open Access

• Consistency checking• Haesen, R., Snoeck, M. (2005). Implementing Consistency Management Techniques for Conceptual Modeling. In: Consistency

Problems in UML-Based Software Development. International Conference on Unified Modeling Language (UML2004), Lisbon, Portugal, 10 Oct 2004-15 Oct 2004. Open Access

• Snoeck, M., Michiels, C., Dedene, G. (2003). Consistency by construction: The case of MERODE. In: Lecture Notes in Computer Science: vol. 2814, (105-117).

• see also full publication list on KULeuven's who-is-who

63

Questions?

64