Basic Principles of Inheritance in Information Systems
Understanding inheritance in information systems is crucial for designing efficient architectures. This chapter delves into the principles of inheritance, such as attribute and method inheritance, generalization, and subtype hierarchies. It also discusses the modeling of inheritance through UML notations and abstract classes. By exploring examples and methodological principles, you can grasp the importance of strong typing and complete specializations in inheritance hierarchies.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Chapter 8 : Inheritance Basic Principles Architecture and Modelling of Information Systems (D0I71A) Prof. dr. Monique Snoeck (c) Monique Snoeck
2 What is Inheritance ? Inheritance of attributes, methods, (Finite State Machine ) generalisation, supertype override extend disable specialisation, subtype 20:43
3 Two UML notations (MERODE = UML) Supertype Supertype Subtype1 Subtype2 Subtype3 Subtype1 Subtype2 Subtype3 20:43
4 Example Title ITEM Author Playing Time Nr of Pages MULTI MEDIA ITEM BOOK JOURNAL VIDEO TAPE CDROM 20:43
5 Inheritance is close to subsetting Pet-animal Cat Dog Horse MERODE Methodological principle: STRONG TYPING 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 So, the extent (set of instances) of the class Pet-Animal is this (yellow) set: The deep extent of Pet-Animal is: Pet-animal Cat Dog Horse 20:43
6 Abstract Class / Total specialisation In UML notation, the triangle is White, even for total specialisation. In MERODE-notation, we make the trangle Black, to increase perceptual discriminability 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 Specialisation is COMPLETE (or TOTAL) Pet Animal is an ABSTRACT CLASS The set of instances (extent) of Pet-Animal is EMPTY 20:43
7 Notation for Abstract Class/Total Specialisation UML MERODE Account {abstract} Account {disjoint, complete} Checking account Savings account Checking account Savings account 20:43
WARNING !! 8 EER notation and UML notation are very different EER notation and UML notation use the same name for different things Aggregation see slides at the end of Chapter 8. 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:43
9 Inheritance and Substitutivity 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 Formal Parameter Class ORDER cr_orderline (p: PRODUCT, q: Integer) ... end PRODUCT Actual Parameter pc: NOTEBOOK moniquesorder: ORDER moniquesorder.cr_orderline (pc, 2) NOTEBOOK objects can be in the 'DEEP extent' of specified class 20:43
10 Inheritance works as an OR 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 OR 20:43
11 Frequent mistake ! Order has a Customer and this customer is a Private Person OR a Business Customer Order has a Private Person AND a Business Customer Wrong !! Correct OR AND 20:43
12 Inheritance of attributes and associations ! 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 using Inheritance in a conceptual schema creates a number of implicit associations 20:43
Extension: a subtype can participate in own associations 13 Extension specific to Business Customers 20:43
14 Inheritance in JMermaid Drag from supertype to subtype Double click the object to indicate total specialisation 20:43
Chapter 8 : Inheritance Inheritance & OET Architecture and Modelling of Information Systems (D0I71A) Prof. dr. Monique Snoeck (c) Monique Snoeck
16 Inheritance in MERODE Representation in the OET What about Business Events ? inheritance of methods not of events ! extension overriding & refinement Propagation rule revisited Consistency rules revisited 20:43
Inheriting, extension & Overriding (1) 17 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) "OR" OR 20:43
Inheriting, extension & Overriding (2) 18 EXTENSION: 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:43
Inheriting, extension & Overriding (3) 19 EVENT SPECIALISATION: (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:43
Inheriting, extension & Overriding (4) 20 EXTENSION or SPECIALISATION of ending methods ? 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:43
21 Inheriting, extension & Overriding (5) 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:43
22 Inheritance in JMermaid 20:43
23 Inheritance in JMermaid 20:43
24 Inheritance in JMermaid 20:43
25 Propagation rule & Inheritance 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:43
26 Inheriting Acquired methods The events of Order are propagated to Customer These Acquired Methods are inherited by BusinessCustomer and PrivateCustomer 20:43
27 Partial model of a bank 20:43
28 OET before propagation CUSTOMER LOAN BONUS Special Discount LOAN S/C S/E I/M I/M Credit BONUS Other type of Bonus S/C S/E cr_customer e_customer cr_bonus cr_credit_bonus cr_OT_bonus e_bonus e_credit_bonus e_OT_bonus cr_loan cr_SD_loan end_loan e_SD_loan change_rate change_duration O/C O/E O/C O/E S/C S/E O/C O/E O/M O/M 20:43
29 Inheritance and propagation BONUS CUST ... LOAN CREDIT BONUS SD SD LOAN LOAN 20:43
30 Partial model of a bank Inherited ED associations 20:43
31 OET after propagation CUSTOMER LOAN BONUS Special Discount LOAN Credit BONUS Other type of Bonus cr_customer e_customer cr_bonus cr_credit_bonus cr_OT_bonus e_bonus e_credit_bonus e_OT_bonus cr_loan cr_SD_loan end_loan e_SD_loan change_rate change_duration change_conditions O/C O/E A/M A/M A/M A/M A/M A/M A/M A/M, A/M A/M A/M, A/M A/M, A/M A/M, A/M A/M, A/M O/C I/C S/C I/C S/C I/E O/E I/E S/E S/E O/C I/C S/C I/E S/E I/M I/M O/M A/M O/E A/M A/M A/M A/M O/M O/M 20:43
32 Partial model of a bank CUSTOMER BONUS CREDIT BONUS Other type of BONUS LOAN Inherited ED associations Special discount LOAN Double Propagation 20:43
33 WRONG EDG for the library Inherited ED associations TITLE ITEM MEMBER BORROWABLE ITEM CDROM ISSUE LOAN VOLUME COPY RENEWABLE LOAN 20:43
34 20:43
35 CORRECT EDG for the library TITLE ITEM BORROWABLE ITEM CDROM ISSUE MEMBER VOLUME COPY LOAN NOT RENEW- ABLE LOAN RENEWABLE LOAN 20:43
36 EDG for a pharmacy PRODUCT FREE PRODUCT RESTRICTED PRODUCT SALE PRESCRIPTION FREE SALE RESTRICTED SALE 20:43
37 EDG for a pharmacy PRODUCT What was actually meant to be modelled FREE PRODUCT RESTRICTED PRODUCT SALE PRESCRIPTION FREE SALE RESTRICTED SALE 20:43
38 Partial Meta-Model 1 2 3 4 5 20:43
39 Consistency Rules revisited (EDG-OET) 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:43
40 Consistency Rules revisited (OET-FSM) 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:43
41 OET representation of Inheritance Cr_supertype cr_subtype1 cr_subtype2 endmod1_supertype endmod2_supertype endmod2_subtype1 endmod2_subtype2 Supertype */C */MorE */MorE Subtype1 S/C I/MorE S/MorE Subtype 2 S/C I/MorE S/MorE Mandatory ! Optional 20:43
Chapter 8 : Inheritance Inheritance & Code Generation Architecture and Modelling of Information Systems (D0I71A) Transformation Definition Transformation Tool Prof. dr. Monique Snoeck (c) Monique Snoeck
43 Inheritance and Code generation 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:43
44 Inheritance and Code generation 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:43
45 Inheritance and code-generation: example 20:43
46 Solution 1 Distinction between Business Customer and Private customer is now captured through - attribute Type - additional constraints on cr_employeeContract : requires self.customer.type = BusinessCustomer 20:43
47 Solution 2 20:43
48 Solution 3 Requires the creation of subtypes for all the dependents to avoid AND for masters (Order shouldn t have a PrivateCustomer AND a BusinessCustomer) See slide 25 20:43
Inheritance in Domain Models Inheritance of Life Cycles (c) Monique Snoeck
Precise definition of Inheritance ? 67 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:43
