Course Overview Part II Domain Modelling Techniques Chapter 4: - - PowerPoint PPT Presentation

▶
course overview
SMART_READER_LITE
LIVE PREVIEW

Course Overview Part II Domain Modelling Techniques Chapter 4: - - PowerPoint PPT Presentation

Jul 16, 2023 355 likes •1k views

1 Course Overview Part II Domain Modelling Techniques Chapter 4: The Existence-Dependency Graph (Class Diagram) Chapter 5: Object Interaction Chapter 6: Object and System Behaviour (FSMs) Chapter 7: Attributes &

slide-1
SLIDE 1

 Monique Snoeck

Course Overview

Part II Domain Modelling Techniques

  • Chapter 4: The Existence-Dependency Graph (Class Diagram)
  • Chapter 5: Object Interaction
  • Chapter 6: Object and System Behaviour (FSMs)
  • Chapter 7: Attributes & constraints
  • Chapter 8: Inheritance
  • ex-Cursus: Domain Modelling Patterns

1

slide-2
SLIDE 2

 Monique Snoeck

Patterns & antipatterns

  • Patterns are methods and techniques developed over a period of many years that have been

accumulated into expert knowledge and reusable templates (‘old hat’ to seasoned professionals and domain experts)

  • Design Patterns address the problem of designing a software solution
  • Analysis Patterns address conceptual modelling
  • Proven optimal solutions to any recurring design problem in a form of reusable design

template.

  • Likewise the term anti-pattern refers to common mistakes in addressing the known problems

in architecting process. 2

slide-3
SLIDE 3

 Monique Snoeck

Origin: Christopher Alexander

  • Roots in Alexander’s work on urban design and building architecture
  • The Timeless Way of Building
  • A Pattern Language
  • “Each pattern describes a problem that occurs over and over again in our

environment and then describes the core of the solution to that problem in such a way that you can use this solution a million times over without ever doing it the same way twice.”

3

slide-4
SLIDE 4

 Monique Snoeck

Patterns are…

  • Recurring solutions to common problems of design
  • Practical/concrete solutions to real world problems
  • BUT every problem is context specific
  • a good pattern pays attention to a description of the contextual factors
  • a good patterns explains how& why a solution is a ‘best-fit’ for the given set of concerns/trade-offs

(cfr. "forces" & "rationale")

  • a good pattern usually identifies a number of "variation points"
  • Description of context, forces, solution and rationale offers
  • a shared vocabulary for problem-solving discussions
  • an effective means of (re)using, sharing and building upon existing wisdom/experience/expertise

4

slide-5
SLIDE 5

 Monique Snoeck

Coplien format

  • 1. Problem
  • 2. Context
  • 3. Forces
  • 4. Solution
  • 5. Resulting Context
  • 6. Rationale

5

slide-6
SLIDE 6

 Monique Snoeck

Domain Modelling Patterns

  • 1. Association Patterns
  • 2. Role Patterns
  • 3. Generalisation / specialisation

anti-pattern

  • 4. Object Type pattern

6

slide-7
SLIDE 7

 Monique Snoeck

Domain Modelling Patterns (ex-Cursus)

  • 1. Association Patterns
  • Single association
  • Nested associations
  • "Connect to the lowest"
  • Three party pattern

1

slide-8
SLIDE 8

 Monique Snoeck

Association Patterns

  • Single Association
  • Unary
  • Binary
  • N-ary

2

See Chapter 4

slide-9
SLIDE 9

 Monique Snoeck

Unary, Binary, Multiple

3

BusinessConcept

association 0..* 0..1

A B Organisational Unit PartOf Relation

1 1

As_Main Dept. as_Subdepartment

0..* 0..1

Unary: always reify Org.Unit

part_of 0..* 0..1

Main SubDept

Example

Main SubDept

Bus.Concept Ass.Concept

1 1

A B

0..* 0..1

as_A as_B

slide-10
SLIDE 10

 Monique Snoeck

Unary, Binary, Multiple

4

Multiple: Always reify Bus.Concept2 Bus.Concept1 Bus.Concept 3 Bus.Concept4

N-ary association 1 1 1 1

N-ary_Assoc Bus.Concept2 Bus.Concept1 Bus.Concept 3 Bus.Concept4

slide-11
SLIDE 11

 Monique Snoeck

Unary, Binary, Multiple

5

Multiple: example Room Course Person

N-ary association 1 1 1

Lecture Room Course Person

slide-12
SLIDE 12

 Monique Snoeck

Unary, Binary, Multiple

  • For binary associations, a more in-depth analysis is required
  • Benefit !
  • more in-depth analysis/elicitation of the business rules

6

Binary: it depends

BusConcept1 Bus.Concept2

1 0..*

The two business concepts are not existent dependent The association expresses existence dependency

Student Registration

1 0..*

PEC Course

1..1 0..*

Course Responsibility

1 1

slide-13
SLIDE 13

 Monique Snoeck

Unary, Binary, Multiple

7

  • many to many ==> reification
  • ED ==> no reification
  • item can exist without the parcel?

==> no ED ==> reification

COURSE COURSE MODULE

[1..*] [0..*]

part of composed of

ORDER ORDER LINE

[1..*] [1..1]

part of composed of

PARCEL ITEM

[0..*] [0..1]

part_of composed of

Binary: it depends

slide-14
SLIDE 14

 Monique Snoeck

Domain Modelling Patterns (ex-Cursus)

  • 1. Association Patterns
  • 2. Role Patterns
  • 3. Generalisation / specialisation

anti-pattern

  • 4. Object Type pattern

1

slide-15
SLIDE 15

 Monique Snoeck

Domain Modelling Patterns (ex-Cursus)

  • 1. Association Patterns
  • Single association
  • Nested associations
  • "Connect to the lowest"
  • Three party pattern

2

slide-16
SLIDE 16

 Monique Snoeck

Nesting Associations

  • The existence of an association depends on the existence of another

association.

  • Example:
  • Association 1: A Supplier supplies Products
  • Association 2: A Person orders a Product from a Supplier
  • For Association 2 to exist, Association 1 needs to exist first:
  • one can only order a product from a supplier that is supplied by that supplier.

3

slide-17
SLIDE 17

 Monique Snoeck

Nesting Associations

4 Concept1 Association1 Concept2

1

Concept 2 Association2 Concept3

2

0..* 1 0..* 1 0..* 1 0..* 1

3 Concept1 Association1 Concept2 Association2 Concept3 Binary association nested in another association 0..* 1 0..* 1 0..* 1 0..* 1

slide-18
SLIDE 18

 Monique Snoeck

Nesting Associations

5 Supplier SuppliedProduct Product

1

0..* 1 0..* 1

OrderedProduct

0..* 1 0..* 1

3 Supplier Supplied Product Product Binary association nested in another association

0..* 1 0..* 1

OrderedProduct

0..* 1 0..* 1

Product Basket

2

Customer

0..* 1

Concept 3

Basket Customer

0..* 1

slide-19
SLIDE 19

 Monique Snoeck

Nesting Associations Example 2

6 Account AccHoldership Person

1

Account Delegation Person

2

0..* 1 0..* 1 0..* 1 0..* 1

Binary association nested in another association

3

Account AccHoldership Person Delegation

0..* 1 0..* 1 0..* 1 0..* 1

received from

slide-20
SLIDE 20

 Monique Snoeck

Domain Modelling Patterns (ex-Cursus)

  • 1. Association Patterns
  • Single association
  • Nested associations
  • "Connect to the lowest"
  • Three party pattern

7

slide-21
SLIDE 21

 Monique Snoeck

"Connect to the lowest" pattern

  • Situation:
  • You have a model
  • You have a new concept to add to this model
  • There are several concepts in the model, the to-be-added concept can be

associated with

  • Problem
  • Which association to choose?

8 Course Program CourseUse Individual Study Program Course Booking

1 1 1 0..* 0..* 0..*

slide-22
SLIDE 22

 Monique Snoeck

"Connect to the lowest" principle

  • Solution
  • Connect to the "most existence dependent" business concept
  • Rationale
  • By connecting to the "lowest object" (CourseUsage), one can navigate to the

masters (Couse, Program)  One connection gives all required information

9 Course Program CourseUse Individual Study Program Course Booking

1 1 1 0..* 0..* 0..* 0..* 1

slide-23
SLIDE 23

 Monique Snoeck

Connect to the lowest

10 Account AccHoldership Person

1

??? Delegation Person

2

0..* 1 0..* 1 0..* 1 0..* 1

3

Account AccHoldership Person Delegation Connect “Delegation” to “lowest”  to Account Holder Result = association nested in another association

0..* 1 0..* 1 0..* 1 0..* 1

slide-24
SLIDE 24

 Monique Snoeck

Connect to the lowest

  • Yet another example

11 Team- membership Leadership Project Employee Team- membership Leadership Project Employee

slide-25
SLIDE 25

 Monique Snoeck

Connect to the lowest

  • Caveat ! this only works when
  • the "lowest" business objects exist at the moment you will create the association
  • the association cannot continue to exist after ending the life of the "lowest" object
  • Example
  • Authorship cannot be nested into contract, because a person continues to be author, even

after ending the contract

  • Contract cannot be nested into Authorship, because Authorship is not a prerequisite for

contract 12 Person University Contract Paper Authorship

1 1 1 0..* 0..1 0..* 0..* 1

slide-26
SLIDE 26

 Monique Snoeck

Connect to the lowest

13

Connect to "Lowest" + MPC ensures that you select products that are supplied by the right supplier Connect to "Lowest" allows detailed registration of order fulfiment MPC ensures that you match Received Shipments to BackOrders from the sampe supplier

slide-27
SLIDE 27

 Monique Snoeck

Domain Modelling Patterns (ex-Cursus)

  • 1. Association Patterns
  • Single association
  • Nested associations
  • "Connect to the lowest"
  • Three party pattern

14

slide-28
SLIDE 28

 Monique Snoeck

Reading assignment

  • Three Party Pattern
  • Repeated application of "connect to the lowest

15

Person Dept. Task

Dept.Membership

TaskResponsibility TaskAssignment

1 0..* 1 0..* 1 0..* 1 0..* 1 0..* 1 0..*

slide-29
SLIDE 29

 Monique Snoeck

Domain Modelling Patterns (ex-Cursus)

  • 1. Association Patterns
  • 2. Role Patterns
  • Single role type pattern
  • Separate fixed role type pattern
  • Separate changeable role type pattern

1

slide-30
SLIDE 30

 Monique Snoeck

Single role type pattern

2

Single_Concept Concept1 Concept2 Concept3 … ConceptN

slide-31
SLIDE 31

 Monique Snoeck

Domain Modelling Patterns (ex-Cursus)

  • 1. Association Patterns
  • 2. Role Patterns
  • Single role type pattern
  • Separate fixed role type pattern
  • Separate changeable role type pattern

3

slide-32
SLIDE 32

 Monique Snoeck

Single role versus Separate fixed role pattern

4

Modelling the marketplace using a single role pattern Complete separation of the three business entities

as_agent as_buyer as_seller

Person Meeting Meeting Seller Buyer Agent

slide-33
SLIDE 33

 Monique Snoeck

Single role versus Separate fixed role pattern

5

Modelling the marketplace using a single role pattern Complete separation of the three business entities

slide-34
SLIDE 34

 Monique Snoeck

Domain Modelling Patterns (ex-Cursus)

  • 1. Association Patterns
  • 2. Role Patterns
  • Single role type pattern
  • Separate fixed role type pattern
  • Separate changeable role type pattern

6

slide-35
SLIDE 35

 Monique Snoeck

Separate changeable role type pattern

  • Object has role
  • Mandatory or not
  • One or many
  • Example
  • Person has role as Dean, Teacher, Project Manager, ….

7 Object Role OfObject Person Teacher Dean

slide-36
SLIDE 36

 Monique Snoeck

Separate changeable role type pattern

  • Object has role
  • Mandatory or not
  • One or many
  • Example
  • Person has role as Dean, Teacher, Project Manager, ….

8

slide-37
SLIDE 37

 Monique Snoeck

Separate changeable role type pattern

  • Object has role
  • Mandatory or not
  • One or many
  • Example
  • Changeable roles often result from assigning people to another object

9 Person Teacher Dean Course Faculty

slide-38
SLIDE 38

 Monique Snoeck

Separate changeable role type pattern

  • Object has role
  • Mandatory or not
  • One or many
  • Example
  • Changeable roles often result from assigning people to another object

10

slide-39
SLIDE 39

 Monique Snoeck

Separate Changeable Role example

11

slide-40
SLIDE 40

 Monique Snoeck

Separate Changeable Role example

12

slide-41
SLIDE 41

 Monique Snoeck

Separate Changeable Role example

13

slide-42
SLIDE 42

 Monique Snoeck

Separate Changeable Role example

EasyChair allows to view the entire history of roles taken

14

slide-43
SLIDE 43

 Monique Snoeck

Domain Modelling Patterns (ex-Cursus)

  • 1. Association Patterns
  • 2. Role Patterns
  • 3. Generalisation / specialisation

anti-pattern

  • 4. Object Type pattern
  • Type Pattern
  • Property Pattern
  • Strategy Pattern

1

slide-44
SLIDE 44

 Monique Snoeck

Type Object Pattern

2 Product Sub Product1 Sub Product2 Sub Product3 Product Type Product

slide-45
SLIDE 45

 Monique Snoeck

UML: Power Type

  • The notion of power type was inspired by the notion of power set.

A power set is defined as a set whose instances are subsets.

  • In essence, a power type is a class whose instances are subclasses.

3

slide-46
SLIDE 46

 Monique Snoeck

Account {abstract} Checking account Savings account Account Type

Power Type

  • Checking Account and Savings Account are both instances of Account Type, as

well as subclasses of Bank Account.

4

Checking Account Savings Account

Power Type

slide-47
SLIDE 47

 Monique Snoeck

UML Power Type

  • Power Type can be used to denote a generalisation set
  • UML's suggested use leads to a mix of the Type Pattern and Inheritance

5

slide-48
SLIDE 48

 Monique Snoeck

Account {abstract} Checking account Savings account

Inheritance versus Type Pattern

6

Stock account Account Type Account Checking Account Savings Account StockAccount

slide-49
SLIDE 49

 Monique Snoeck

With Inheritance

7

Product BOOK JOURNAL CD

ID Author Title Price B1 J.K.Rowling Harry Potter and the philosopher's stone 18€ B2

  • M. Fowler

Analysis Patterns 59€ B3

  • F. Brooks

The Mythical Man Month 39€

BOOK

ID TITLE Editor Price J1 National Geographics NG 100€ B2 Communciations ACM 59$ B3 Transactions on Softw. Engineering IEEE 39€

JOURNAL

ID Title Price C1 The Mirror 18€ C2 Hitclub 0106 18€ C3 Fictions 14.95€

CD

slide-50
SLIDE 50

 Monique Snoeck

With Type Pattern

8

nr name PT1 book PT2 CD PT3 journal PRODUCT TYPE PRODUCT

Product Type Product

ID PType Title Price B1 PT1 Harry Potter and the philosopher's stone 18€ B2 PT1 Analysis Patterns 59€ B3 PT1 The Mythical Man Month 39€ J1 PT3 National Geographics 100€ J2 PT3 Communications 59$ C1 PT2 Hitclub 01 06 18€ ... .... ....

slide-51
SLIDE 51

 Monique Snoeck

Property Pattern

9 PROPERTY ID Prod. ID name value 1 1 number 123 2 1 colour black 3 2 number 111

name: string number:integer colour: string

Product

mandatory

Product Property

name: ... value: ... name: string

  • ptional

PRODUCT name number colour blackpen 123 black book 111 -- PRODUCT ID name 1 blackpen 2 book

slide-52
SLIDE 52

 Monique Snoeck

Type Pattern + Property Pattern

10 Attribute Type Product Product Type Property Value Property

slide-53
SLIDE 53

 Monique Snoeck

An example

11

PRODUCT TYPE PROPERTY ATTRRIBUTE TYPE PRODUCT PROPERTY VALUE Nr name Prop Product V1 Harry Potter and the Philosophers Stone Pr1 P1 V2 Harry Potter and the Gobelet

  • f Fire

Pr1 P3 V3 Musti in de regen Pr1 P2 V4 The Visit Pr4 P4 Nr PT Price P1 PT1 10€ P2 PT1 6€ P3 PT1 11 € P4 PT2 20€ nr name PT1 book PT2 CD PT3 journal Prop name PT AT Pr1 Title PT1 AT1 Pr2 Acquisition Date PT1 AT2 Pr3 Description PT2 AT3 Pr4 Title PT2 AT1 nr name AT1 string AT2 Date AT3 Text

slide-54
SLIDE 54

 Monique Snoeck

Strategy Pattern

12

name: string number: integer colour: string

Product Attribute Type

name type validate()

slide-55
SLIDE 55

 Monique Snoeck

Strategy Pattern

  • Allows validating the type of a value

13

Property PropertyValue Attribute Type name type Validate () Product Type Product base_attr1 base_attr2

slide-56
SLIDE 56

 Monique Snoeck

Product Type Attribute Type Property Product Value cr product type C end product type E cr attribute type C end attribute type E cr property M M C end property M M E cr product M C end product M E cr value MM M M M C end value MM M M M E

OET for Dynamic Object Model

14 Class PROPERTY VALUE product.product_type = property.product_type

Property PropertyValue Attribute Type Product Type Product base_attr1 base_attr2

slide-57
SLIDE 57

 Monique Snoeck

Constraints

15

base_attr1 base_attr2 Product Type Product Property PropertyValue Attribute Type

Only values for registered attributes: MPC: Class PropertyValue self.property.product_type = self.product.product_type p v (Exactly) One value for every registered attribute: Class Product: Forall p in self.product_type.property exists (exactly one) v in self.PropertyValue with v.property = p

slide-58
SLIDE 58

 Monique Snoeck

Type Level – Instance Level

16

Type Level Instance Level

Product Type Product Property Property Value Attribute Type base_attr1 base_attr2

slide-59
SLIDE 59

 Monique Snoeck

Type Level/Meta Level – Instance Level

17

ITEM-TYPE ITEM

Type Level Instance Level

slide-60
SLIDE 60

 Monique Snoeck

Type Pattern example

18

Type Level Instance Level

slide-61
SLIDE 61

 Monique Snoeck

Type Level as “Factory”

19

Type Level Instance Level

slide-62
SLIDE 62

 Monique Snoeck

Comparing Inheritance & Type Pattern

20

Product Sub Product1 Sub Product2 Sub Product3 attribute1 attribute2 base_attr1 base_attr2 attribute3 attribute4 attribute5 attribute6

Add a new type of product =

  • Add class
  • Recompile & Link
  • Put new version into

production

slide-63
SLIDE 63

 Monique Snoeck

Comparing Inheritance & Type Pattern

21

Add a new type of product =

  • Add a new instance of Product Type
  • Add new instances of Attribute Type
  • Add instances of Property

==> NO NEW VERSION OF THE SOFTWARE REQUIRED !

Attribute Type Product Product Type Property Value Property

1 0..* 1 0..* 1 0..* 1 0..* 1 0..*

slide-64
SLIDE 64

 Monique Snoeck

Comparing Inheritance & Type Pattern

Forces Inheritance Dynamic Object Model Product Management Flexibility requires extension of hierarchy for new products Allows continuous change Ease of Implementation easier More difficult to implement Ease of Use easier for programmers and for users

  • More difficult to use for pgmrs
  • Requires more training of end-users
  • Requires tools for end-users to test,

control, … new product definitions Performance More efficient at run-time More costly at run-time

22