D1 - 27/06/2015 The present document contains information that remains the property of France Telecom. The recipient’s acceptance of this document implies his or her acknowledgement of the confidential nature of its contents and his or her obligation not to reproduce, transmit to a third party, disclose or use for commercial purposes any of its contents whatsoever without France Telecom’s prior written agreement. Multiple to single inheritance transformation June 15th, 2004 M. Dao, M. Huchard, T. Libourel, A. Pons, J. Villerd

France Telecom R&D Distribution of this document is subject to France Telecom’s authorization D2 - 27/06/2015 Multiple inheritance: a new birth?  OO programming languages and MI:  "good" implementation in not so popular languages: Eiffel, CLOS, …  "bad" implementation in once popular languages: C++, …?  "no" implementation in today popular languages: Java (MI interfaces though), C#, …?  Not much excitement about MI lately, but…  …the modelling era has begun!  When you model, for instance in UML, you can use MI (almost) without moderation

France Telecom R&D Distribution of this document is subject to France Telecom’s authorization D3 - 27/06/2015 MI to SI transformation  High-level MI models may eventually need to be transformed into SI models ("popular" OO languages, for instance)  Two possible approaches (among others?)  "combinatorial": cut inheritance links to obtain SI –need to duplicate class properties –how to choose those inheritance links –based on inheritance metrics (Roume 02)  "semantic": classify MI situations and transform MI into SI –use UML annotations to precise different MI situations –apply the "most appropriate" inheritance transformation

France Telecom R&D Distribution of this document is subject to France Telecom’s authorization D4 - 27/06/2015 UML inheritance annotations  Discriminators allow to group inheritance links that share a same semantic  Constraints on subsets of instances of a class: complete, disjoint, incomplete, overlapping  We propose new constraints:  concurrent (special case of overlapping)  successive, exclusive (special case of disjoint)  combined  alternative

France Telecom R&D Distribution of this document is subject to France Telecom’s authorization D5 - 27/06/2015 UML inheritance annotations Employee SalariedEmployee ExemptEmployee HourlyEmployee VestedEmployee UnvestedEmployee :pension :status VestedExemptEmployee {disjoint,incomplete} {disjoint,complete} Discriminators Constraints

France Telecom R&D Distribution of this document is subject to France Telecom’s authorization D6 - 27/06/2015 MI transformations  Duplication  cut one inheritance link and duplicate formerly inherited properties in the subclass  Nested generalizations  create a class for each possible MI situation  Direct link  make the leaf class directly inherit from root class  Role aggregation  replace one MI link by an aggregation  Class merge  replace all classes with one

France Telecom R&D Distribution of this document is subject to France Telecom’s authorization D7 - 27/06/2015 Example of transformation Employee SalariedEmployee ExemptEmployee HourlyEmployee VestedEmployee UnvestedEmployee :pension :status VestedExemptEmployee {disjoint,incomplete} {disjoint,complete}

France Telecom R&D Distribution of this document is subject to France Telecom’s authorization D8 - 27/06/2015 The right transformation for the right inheritance situation  Our proposition:  elaborate a list of possible MI "situations" based on UML extended annotations and other criteria (size, symmetry, etc.)  for each situation, propose a suitable MI transformation  Examples  role aggregation transformation might be used with complete constraint: the structure will not evolve  direct link transformation might be used when symmetry is important for example in the case of the alternative constraint

France Telecom R&D Distribution of this document is subject to France Telecom’s authorization D9 - 27/06/2015 Perspectives  elaborate a list of MI situations as complete as possible  a situation might be a subsituation of another: classification  try and find a most appropriate MI transformation for each situation  difficulties: –be able to automatically detect MI situations –different MI situations may overlap –order of transformations?  use of a model transformation language?  study an "hybrid" approach (combinatorial and semantic)?