Basic Principles of Inheritance in Information Systems

Architecture and Modelling

of Information Systems (D0I71A)

Prof. dr. Monique Snoeck

20:35

2

generalisation,

supertype

specialisation,

subtype

Inheritance of  attributes,

methods, (Finite State

Machine )

override

extend

disable

20:35

3

20:35

4

Title

Author

Playing 

Time

ITEM

BOOK

JOURNAL

CD

ROM

VIDEO

TAPE

MULTI

MEDIA

ITEM

Nr of Pages

20:35

5

Pet-animal

Cat

Dog

Horse

M

E

R

O

D

E

M

e

t

h

o

d

o

l

o

g

i

c

a

l

p

r

i

n

c

i

p

l

e

:

S

T

R

O

N

G

T

Y

P

I

N

G



No object has two types

 

Overlapping subtypes are not allowed: one can't be a cat

and a dog at the same time



Principle: a subtype hierarchy should always be disjoint:

An object is either a Pet-Animal or a Dog/Cat/Horse



S

o

,

t

h

e

e

x

t

e

n

t

(

s

e

t

o

f

i

n

s

t

a

n

c

e

s

)

o

f

t

h

e

c

l

a

s

s

P

e

t

-

A

n

i

m

a

l

i

s

t

h

i

s

(

y

e

l

l

o

w

)

s

e

t

:



T

h

e

d

e

e

p

e

x

t

e

n

t

o

f

P

e

t

-

A

n

i

m

a

l

i

s

:

P

e

t

-

a

n

i

m

a

l







































20:35

6

Pet-animal

Cat

Dog

Horse

Partial or complete ?

Does there exist an object that is a "Pet Animal"

without being a cat/dog/horse ?

NO

  

   

    

 

The set of instances (extent) of Pet-Animal is EMPTY

Account

{abstract}

Account

20:35

7

UML

MERODE

{disjoint, complete}



EER notation and UML notation are very different



EER notation and UML notation use the same name for different things



Aggregation



       





Comparing EER to UML notation



Additional methodological considerations given in AMIS



MANDATORY READING !!



if questions persist, send me an email and I'll give feedback in class

20:35

8



Principle of Substitutivity (Barbara Liskov):



Anywhere an object of  Type T is expected, it can be replaced by an object of

type S, S being a subtype of T



Class ORDER



cr_orderline (p: PRODUCT, q: Integer)



...



end



pc: NOTEBOOK



moniquesorder: ORDER



moniquesorder.cr_orderline (pc, 2)



objects can be in the 'DEEP extent' of specified class

20:35

9

PRODUCT

NOTEBOOK



Order  is ED from Customer



The actual Customer of an order can be from the DEEP extent of class Order.



So, this customer  can be a Private Person OR a Business Customer

20:35

10

OR



Order has a Private Person AND

a Business Customer

20:35

11



Order has a Customer and this

customer is a Private Person OR

a Business Customer

AND

OR

Correct

Wrong !!



The actual Customer of an order can be  a Private Person OR a Business Customer



a Private Person has zero to many orders



a Business Customer has zero to many orders

20:35

12

using Inheritance in a

conceptual schema

creates a number of

implicit associations

20:35

13

Extension specific to Business

Customers

20:35

14

Drag from supertype

to subtype

Double click the

object to indicate

total specialisation

Architecture and Modelling

of Information Systems (D0I71A)

Prof. dr. Monique Snoeck



Representation in the OET



What about Business Events ?



inheritance of methods



not of events !



extension



overriding & refinement



Propagation rule revisited



Consistency rules revisited

20:35

16



PrivateCustomer and BusinessCustomer inherit

the method end_customer from Customer,

together with the rules that go with this method.



A customer can not be ended as long as there are

living orders



 

Neither can a PrivateCustomer or a Business

Customer



When the method "end_customer" is invoked,

the type of object it is invoked upon can be

"casted" and the right variant of the method is

choosen accordingly (polymorphism & dynamic

binding)



 

20:35

17

O

R

E

X

T

E

N

S

I

O

N

:



PrivateCustomer and BusinessCustomer can add

their OWN methods next to the inherited ones



the business events end_PrivateCustomer and

end_BusinessCustomer exist next to the business

event end_customer



e.g. the class PrivateCustomer has two ending

methods:



end_Customer inherited from Customer



its OWN end_PrivateCustomer method



The class BusinessCustomer extends the class

Customer by adding a method for the event 

grant

payment facilities

20:35

18

E

V

E

N

T

S

P

E

C

I

A

L

I

S

A

T

I

O

N

:



(does not exist in UML)



When you create an object, you don't have an instance yet

to cast the type of.



So you need to specify which class you want to create an

instance of



This is achieved by SPECIALISING creating event types



cr_Customer is specialised into cr_PrivateCustomer and

cr_BusinessCustomer 



Inherited cr_customer is available in the subclass to implement

the specialised methods



When invoking the event cr_customer, only a CUSTOMER

instance can be created (no OR !!)

20:35

19

E

X

T

E

N

S

I

O

N

o

r

S

P

E

C

I

A

L

I

S

A

T

I

O

N

o

f

e

n

d

i

n

g

m

e

t

h

o

d

s

?



a subtype inherits all existence dependency

relationships from its supertype, it needs to obey the

rules of life-cycle ending imposed on the supertype,



Each ending of a subtype therefore needs to obey all

the rules that apply to the ending of the supertype.



This can be made explicit by requiring that the ending of

a subtype is either the unmodified inherited version of

the ending method of the supertype, or a specialisation

of the ending of a supertype.

20:35

20

?

?



creating event types must always be specialised: a 'C'-involvement therefore always

gives rise to an 'S/C'-involvement for the specialisation type;



modifying and ending event types can be inherited or specialized;



there cannot be an owned creating event type for a subtype;



owned modifying event types are allowed for subtypes.



it‘s advised not to have an owned ending event type for a subtype, but rather to

specialise the inherited ending event to stress the fact that all inherited rules should be

obeyed.

20:35

21

20:35

22

20:35

23

20:35

24



Propagation along explicitly modelled associations, but also along implicitly modelled associations



Creating an Order affects a customer, who may be a PrivateCustomer or a Business Customer.

20:35

25

20:35

26

20:35

27

20:35

28

20:35

29

CUST

LOAN

BONUS

SD

LOAN

SD

LOAN

CREDIT

BONUS

...

20:35

30

20:35

31

20:35

32

CUSTOMER

LOAN

Special

discount

LOAN

CREDIT

BONUS

BONUS

Other type of

BONUS

Inherited ED

associations

20:35

33

COPY

VOLUME

ITEM

TITLE

ISSUE

CDROM

BORROWABLE

ITEM

MEMBER

LOAN

RENEWABLE

LOAN

Inherited ED

associations

20:35

34

20:35

35

20:35

36

PRODUCT

FREE

PRODUCT

RESTRICTED

PRODUCT

SALE

FREE

SALE

RESTRICTED

SALE

PRESCRIPTION

20:35

37

PRODUCT

FREE

PRODUCT

RESTRICTED

PRODUCT

SALE

FREE

SALE

RESTRICTED

SALE

PRESCRIPTION

20:35

38

1

2

3

4

5



Inheritance rule



An object type inherits all the event types from its

parent object type, either unchanged or by specialising them.



Propagation rule



All event types in the alphabet of a dependent object type are propagated to their master

object type.  The event types in the alphabet of the descendants of a dependent object type

are also propagated to the master object type.



==> Type of Provenance indication

 (Owned, Acquired, Specialised, Inherited)



Type of involvement rule



For event types propagated because of existence dependency, the type of involvement rule

remains unchanged.



Inherited event types keep their type of involvement unchanged.

20:35

39



Alphabet rule (unchanged)



The FSM of an object type P must contain all and only the event types in the alphabet of P.



Default life cycle rule (unchanged)



The events in c(P), m(P) and e(P) must appear as creating, modifying or ending event types,

respectively, in the sequence restrictions of the object type P.

20:35

40

20:35

41

Architecture and Modelling

of Information Systems (D0I71A)

Prof. dr. Monique Snoeck



The built-code generator can not yet handle models with inheritance



"Beta" version available as independent tool that can handle many models, but not all



http://merode.econ.kuleuven.ac.be/CodeGeneration.html

20:35

43



If generation doesn’t work,



Send us your model as a testcase for us !



use the rules for translating models with inheritance to relational database schema



 3 alternatives:



All-in-one class



Separate class for supertype & subtypes, connected with optional-one relation



Class for subtypes merged with supertype



Add attributes, FSMs and constraints to obtain desired behaviour

20:35

44

20:35

45

20:35

46

Distinction between Business Customer and Private

Distinction between Business Customer and Private

customer is now captured through

customer is now captured through

- attribute “Type”

- attribute “Type”

- additional constraints on cr_employeeContract :

- additional constraints on cr_employeeContract :

requires self.customer.type = “BusinessCustomer

requires self.customer.type = “BusinessCustomer

20:35

47

20:35

48

Requires the creation of subtypes for all the dependents to avoid “AND” for masters

Requires the creation of subtypes for all the dependents to avoid “AND” for masters

(Order shouldn’t have a PrivateCustomer AND a BusinessCustomer)

(Order shouldn’t have a PrivateCustomer AND a BusinessCustomer)

See slide  25

See slide  25

On the use of G/S hierarchies and Roles

cfr. 

Pattern Language on (Role) Types 

and G/S Anti-Patterns



Strong Typing Approach suggests:



Every object belongs to exactly one class



Migration between classes is impossible



Substitutivity must be ensured



Examples of G/S abuses 

    

      



attribute subclasses



existence defined subclass



state defined subclass



Abuse is result of ‘old’ semantic modelling approaches trying to capture all specs in one (EER) diagram.

 

Object orientation allows multiple views on 1 model

      

  

’

     

   

20:35

50

Avoid the use of

Avoid the use of

inheritance in these cases

inheritance in these cases



Read section 8.3 at home

20:35

51

20:35

52

book

book.colour

subclasses of a BOOK based on the 

colour

-attribute

red 

book

blue 

book

BOOK

Blue Book

Red Book

Reading 

Assignment

20:35

53

S

o

l

u

t

i

o

n

w

i

t

h

a

s

i

n

g

l

e

c

l

a

s

s

:

c

a

r

.

i

n

v

o

i

c

e

i

f

p

r

i

c

e

<

3

0

0

0

0

t

h

e

n

a

m

o

u

n

t

=

p

r

i

c

e

*

1

,

1

9

e

l

s

e

a

m

o

u

n

t

=

p

r

i

c

e

*

1

.

3

3

subclasses of a CAR based on the 

price

-attribute

Subclasses have different method-bodies for

"Invoice" method  (polymorphism)

d

e

_

l

u

x

e

_

c

a

r

.

i

n

v

o

i

c

e

a

m

o

u

n

t

=

p

r

i

c

e

*

1

,

3

3

S

t

a

n

d

a

r

d

_

c

a

r

.

i

n

v

o

i

c

e

a

m

o

u

n

t

=

p

r

i

c

e

*

1

,

1

9

Object migrates between

 subclasses

Solution with a single class is to be

preferred

!

Reading 

Assignment

20:35

54

head of

employee

department

1:1

0:1

head of

manager

department

1:1

1

:1

non-

manager

employee

Existence of a relationship is basis for subclassing

Object migrates between

 subclasses

Solution with a single class is to be

preferred

!

Reading 

Assignment

20:35

55

PERSON

PAPER

SESSION

SUBSCRIPTION

1

0..*

author

0..*

0..*

Co-author

referee

0..*

0..*

0..*

1

0..1

1

attendee

Session

leader

Solution without Inheritance

Reading 

Assignment

20:35

56

Object migrates between

 subclasses

Overlapping subclasses

Solution with a single class is to be

preferred

PAPER

SESSION

SUBSCRIPTION

1

1..*

author

1..*

0..*

Co-author

referee

0..*

1..*

1..*

1

1

1

attendee

Session

leader

PERSON

CO

AUTHOR

AUTHOR

REFEREE

ATTENDEE

SESSION

LEADER

!

Reading 

Assignment

20:35

57

Object migrates between

 subclasses.

Set of methods varies with state.

Solution with a single class is to be preferred

Subclassing based on the state of an objects

is equivalent to attribute-defined subclass 

when state is an attribute

!

Reading 

Assignment

20:35

58

Object migrates between

 subclasses !

Solution with a single class is to be

preferred

!

Reading 

Assignment

20:35

59

submit

classify

send to

referee

send to

referee

comment

comment

submit

Letter of

intent

1

2

3

4

5

accept

publish

reject

7

8

9

10

11

Intended Paper

submitted paper

rejected paper

accepted paper

non-stratified FMS …

Reading 

Assignment



Decision Rules



Strong typing: an object belongs to ONE class once

and for all



=> use  ROLES



to model temporal aspects



to model overlapping subclasses



Use SUBCLASSES  when different methods are

required or when different constraints apply

20:35

60

Reading 

Assignment



Criteria:



When compared to B



A has additional attributes



A has different/stronger attr. constraints



A is involved in more events



A responds differently to events (= has other method-body)



A has different/stronger sequence constraints on events



Do Objects belong permanently or temporarily to A ?



Possible outcomes:

A is subclass of B, A is role of B, A= B, cannot decide

20:35

61

Reading 

Assignment

20:35

62

Reading 

Assignment

20:35

63

Object types: room, classroom, research-room, office

Assume classroom, research-room, office have additional

attributes & events, different methods ==>  Specialisations

Rooms can receive other destination

== >Temporal aspect

==>  Roles

Each building consists of a number of rooms.  Each room serves a

specific purpose: a didactic, research or logistic purpose.  When a

building is rearranged, rooms can receive another destination.

Reading 

Assignment

20:35

64

ROOM

OFFICE

RESEARCH

ROOM

CLASS ROOM

DESTINATION

Reading 

Assignment

20:35

65



 Consider the following inheritance graph.  Do you think it is

appropriate to use inheritance in this case.  Why or why not ?

HIGH

RISK 

PATIENT

SMOKER

PATIENT with  

HEART DESEASE

Reading 

Assignment

Inheritance of Life Cycles



Everybody agrees on inheritance of attributes and methods



How about State Machine ?  Can subclass



Add states ?



Split states ?



Redefine inherited methods ?



Add events ?



Moreover



How about specialisation of events?



Inheritance of Roles ?



Overlapping Subtypes ?



Migration between Subtypes ?



Migration between Subclass and Superclass ?

20:35

67

Inheritance should be treated the same way in



PIM



PSM



Code

20:35

68

Device_dialog

d : DEVICE

set_Device (d: DEVICE)

Printer_dialog

inherit Device_Dialog

redefine d, set_device

d: PRINTER

set_Device (p: PRINTER)

20:35

69



C

O

V

A

R

I

A

N

C

E

:

A

r

e

d

e

c

l

a

r

a

t

i

o

n

o

f

a

f

e

a

t

u

r

e

m

a

y

r

e

p

l

a

c

e

t

h

e

t

y

p

e

o

f

t

h

e

f

e

a

t

u

r

e

o

r

t

h

e

t

y

p

e

o

f

a

f

o

r

m

a

l

a

r

g

u

m

e

n

t

b

y

a

n

y

t

y

p

e

t

h

a

t

c

o

n

f

o

r

m

s

t

o

(

=

i

s

a

s

u

b

t

y

p

e

o

f

)

t

h

e

o

r

i

g

i

n

a

l



N

O

V

A

R

I

A

N

C

E

:

A

r

e

d

e

c

l

a

r

a

t

i

o

n

o

f

a

f

e

a

t

u

r

e

m

a

y

N

O

T

r

e

p

l

a

c

e

t

h

e

t

y

p

e

o

f

t

h

e

f

e

a

t

u

r

e

o

r

t

h

e

t

y

p

e

o

f

a

f

o

r

m

a

l

a

r

g

u

m

e

n

t

b

y

a

n

o

t

h

e

r

t

y

p

e



C

O

N

T

R

A

V

A

R

I

A

N

C

E

:

A

r

e

d

e

c

l

a

r

a

t

i

o

n

o

f

a

f

e

a

t

u

r

e

m

a

y

r

e

p

l

a

c

e

t

h

e

t

y

p

e

o

f

t

h

e

f

e

a

t

u

r

e

o

r

t

h

e

t

y

p

e

o

f

a

f

o

r

m

a

l

a

r

g

u

m

e

n

t

b

y

a

n

y

t

y

p

e

t

h

a

t

i

s

a

s

u

p

e

r

t

y

p

e

o

f

t

h

e

o

r

i

g

i

n

a

l

20:35

70

COW

TIGER

ANIMAL

FOOD

GRASS

MEAT

likes

likes

likes

CO

VARIANCE !



Consider two inheritance hierarchies H1 and H2:



Co-variance = when associating supertypes in H1 to supertypes in H2, and subtypes in H1

redeclare this link to subtypes in H2



See the Animal & Food example, and the Order & Product example further down



Contra-variance = when associating supertypes in H1 to subtypes in H2, and subtypes in

H1 redeclare this link to supertypes in H2



see next slide



No-variance = when not re-declaring links: subtypes in H1 just inherit the links of their

supertype, and do not redeclare it.

20:35

71

20:35

72

POLYGLOT 

STUDENT

STUDENT

ENGLISH

LANGUAGE

SPANISH

Speaks

Speaks

CONTRA - 

VARIANCE !

The general rule is that a

student speaks English

The subtype - a Polyglot

Student- inherits that

property, but "widens" it: The

Polyglot Student can do

more: s/he can speak ANY

language

H1

H2

20:35

73



UML 2.0



Association is a descendant of Classifier



Can be specialised



Arity must be kept



Participants must be type-conformant to original participants



Association/property subsetting: "may strengthen the type and upper bound may be 

less"



Semantic Variation point:  "

The interaction of association specialisation with association end

redefinition and subsetting is not defined

".



MDA: Translations to code ?

20:35

74



Liskov Principle of Substitutivity:



Anywhere an object of  Type T is expected, it can be replaced by an

object of type S, S being a subtype of T

Class ORDER

cr_orderline (p: PRODUCT, q: Integer)

...

end

n: Notebook

o: ORDER

o.cr_orderline (n, 2)



objects can be in the 'DEEP extent' of specified class

20:35

75

PRODUCT

NOTEBOOK



objects can be in the 'DEEP extent' of specified class



==> object can be replaced by specialised object



==> specialised object should not refuse action allowed on objects of superclass



==> extension is OK, but restriction is not



    



     



20:35

76



Reminder: Precondition, Postcondition



B. Meyer: Programming by contract:



Pre-condition: conditions under which I accept to do my job properly (--> Obligations for my

Client)



Post-condition: To what I engage myself, my obligations (--> Benefice for my Client)

20:35

77

Pre:  N > 0

Calculate N!

Post: result = N!

Benefice for me: have not to

worry about negative

numbers

Benefice for my Client: I

guarantee a correct result



How to be honest ?



The invariants of all the parents of a class apply to the class itself



Assertion redeclaration rule



A

r

o

u

t

i

n

e

r

e

d

e

c

l

a

r

a

t

i

o

n

m

a

y

o

n

l

y

r

e

p

l

a

c

e

t

h

e

p

r

e

c

o

n

d

i

t

i

o

n

b

y

o

n

e

e

q

u

a

l

o

r

w

e

a

k

e

r



R

E

Q

U

I

R

E

E

L

S

E

(

=

O

R

)



a

n

d

t

h

e

p

o

s

t

c

o

n

d

i

t

i

o

n

b

y

o

n

e

e

q

u

a

l

o

r

s

t

r

o

n

g

e

r



E

N

S

U

R

E

T

H

E

N

(

=

A

N

D

)

20:35

78

Imagine a library where different kinds of items can be consulted: single issues of

journals, volumes of journals, books, DVDs, ... and so on.  All available items can be

searched for by means of an on-line catalogue.  Issues of journals can not be

borrowed; books and volumes of journals can.  Only loans of books can be renewed.

To prevent loss, DVDs are kept in a separate place and must be lend out at the loan

desk.  They must not leave the library.  Equipment is provided to view DVDs and to

print information.  Printing is charged when the DVD is returned.

20:35

79

20:35

80

ITEM =

<{create_item, classify, borrow, return, lose, end_item},

create_item.classify.(borrow +  return)*.(lose + end_item)>

BOOK =

<{cr_book, renew},

create_book.classify.(borrow.(renew)*.return)*.(borrow.(renew)*.lose + end_item)>

BOOK/



= <{}, create_book.classify.(borrow.(

renew

)*.return)*.(borrow.(

renew

)*.lose + end_item)>

= <{}, create_book.classify.(borrow.(

1

)*.return)*.(borrow.(

1

*).lose + end_item)>

= <{}, create_book.classify.(borrow.return)*.(borrow.lose + end_item)>

20:35

81

20:35

82

CLASS ITEM

Return is

require

state = available

...

lose is

require

state = available

CLASS BOOK

Inherit ITEM

return is

r

e

q

u

i

r

e

e

l

s

e

state = out

....

Lose is

r

e

q

u

i

r

e

e

l

s

e

state = out

...



CO-variance: most natural when modelling



BUT can entail programming problems ...



    



In a model, Covariance & Narrowing occurs when superclass definition is wrong or

imprecise



The superclass makes a promise that cannot be supported by the subclasses



In the superclass, the type of the attribute or related object is vague, but becomes clearer and clearer as

subclasses are derived.

20:35

83

20:35

84

Novariant or

Invariant approach

for sequence

constraints is in

line with principle

of substitution

20:35

85

item

DVD

Volume

Book

loan-

item

issue

ITEM =

<{create_item, classify, declassify, remove_item},

create_item.classify.declassify,remove_item>

ISSUE = <{}, create_item.classify.declassify.remove_item>

DVD = <{borrow, return, print}, create_item.classify.(borrow.(print)*.return)*.declassify.remove_item>

LOAN_ITEM = <{borrow, return, lose},

create_item.classify.(borrow.return)*.(borrow.lose + 1).declassify. remove_item>

20:35

86

LOAN_ITEM = <{borrow, return, lose},

create_item.classify.(borrow.return)*.

(borrow.lose + 1).declassify. remove_item>

BOOK =<{renew},

create_item.classify.(borrow.(renew)*.return)*

.(borrow.(renew)*.lose +1).declassify.remove_item>

VOLUME = <{},

create_item.classify.(borrow.return)*.

(borrow.lose + 1).declassify.remove_item

20:35

87



Restriction rule (unchanged)



Existence dependent object types must have a more deterministic life cycle definition than

their master object type.



Contract rule



Let P and Q have common event types (two or more)



There is no need to define a contract object type if an object type in the cluster of P is

existence dependent of Q or vice versa.



Substitutability rule



A specialisation type must not restrict the behaviour it inherited from the generalisation type.

20:35

88