Inhertance with GeneralizationSets

[Paolo F Cantoni]

I've been playing around with generalization, particularly multiple generalization.  Although EA doesn't directly support GeneralizationSets, I emulate them by using the Constraints tab and placing a GeneralizationSet name as the constraint and the defining the type of Constraint as Gen.Set.

I'm working at very high levels of abstraction, what Jim Shaw and I have coined the DIM (no jokes please :-)) - the Domain Independent Model.  The model that is valid regardless of the specific domain of discourse.  In there, we find things like Collections, Graphs, Containers, Components etc.

Taking Collections for example, I currently have three GeneralizationSets: Mutability (is the collection fixed or not), Associativity (is the collection associative or not), Orderedness (is the collection ordered or not).  So far, I think, using combinations of these GeneralizationSets (plus further specializations, I can generate (in the conceptual sense) any collection I need.  Now, different Features apply to different combinations of GeneralizationSets.

An example is: if I have an AssociativeCollection Class I hold there, the Features common to all Collections that have that property, regardless of which other GeneralizationSets apply.  Similarly, I have Class called MutableCollection and Class OrderedCollection so on.

Thus any domain level Collection, just has to pick which specialization it inherits from from each GeneralizationSet.

However, at the DIM level I can also create joint specializations.  I have a Class called MutableAssociativeCollection.  Here I hold those Features that apply ONLY to AssociativeCollections that are also Mutable - or the MutableCollections that are also Associative.

Obviously, one can create a combinatorial explosion as more and more specializations are created.

So I need a mechanism to control this complexity.

Accordingly, if I inherit from AssociativeCollection and I'm Mutable, I also need to inherit from MutableAssociativeCollection or if I inherit from MutableCollection and I'm also Associative, I need to also inherit from MutableAssociativeCollection.

One proposal I have is to create a «generalization» Dependency which has a constraint on it that it only applies under certain circumstances.  For example, in the first case immediately above,  I have a «generalization» Dependency from AssociativeCollection to MutableAssociativeCollection with the constraint IsMutable == true.  Similarly in the second case immediately above, I have a «generalization» Dependency from MutableCollection to MutableAssociativeCollection with the constraint IsAssociative == true.

This means that when I inherit way down the tree, I can "shimmy up" the tree and look for any such dependencies and ensure that I also inherit from the supplier of the dependency (but only if the constraint is supported).

NOTE: the constraints in this case are effectively design time constraints.

Thoughts (or better still a better solution to the problem).

TIA,
Paolo

[sargasso]

[Aside]
Conceptually, can there be a difference between a MutableAssociativeCollection and an AssociativeMutableCollection?
[/Aside]

I think I have the same/a similar problem at a less DIM level.


bruce

[Paolo F Cantoni]

Sorry, bruce, your model is self inconsistent.  

You have created three subtypes of Animal based on where they can travel (and thus the types of operations applicable).  It may be the same GeneralizationSet (with members that overlap).

Aquatic - moves through the water.  Terrestrial - moves on the Earth.  Avian? - wrong name!  (and thus wrong concept!).  I suspect  Volant or Aeronautical - can move through the air.- would be more appropriate. You could also have added Subterranean (at the same level - not below) - travels under the earth.

Thus a Penguin is both aquatic and terrestrial, but not volant.  A Duck is volant, aquatic and terrestrial.

On further thought, perhaps it might have been better to have - InWaterAnimal, OnGroundAnimal, BelowGroundAnimal, InAirAnimal

I think your model is sufficiently simple for my idea not to be required.  But any more complex and I think there may be that combinatorial explosion I mentioned.

Paolo

WRT your aside, I don't think there ought to be any difference; since conceptually, I would have thought they were the same thing - and, according to my methodology outlined in the first post, they should yield the same set of Features.

[sargasso]

Sorry, bruce, your model is self inconsistent.  

Agreed - that is the problem!  I was using (trying to use) a concrete example to investigate the inconsistency.

You have created three subtypes of Animal based on where they can travel (and thus the types of operations applicable).  It may be the same GeneralizationSet (with members that overlap).

Yes, that's it - 3 subtypes with overlapping operations.  I suppose the construct I'm looking for is, for example, Aquatic.Swim "overides and renames" its' base.move operation.  Fine.  I'm only using the operation names to clarify what I'm looking at.

Aquatic - moves through the water.  Terrestrial - moves on the Earth.  Avian? - wrong name!  (and thus wrong concept!).  I suspect  Volant or Aeronautical - can move through the air.- would be more appropriate. You could also have added Subterranean (at the same level - not below) - travels under the earth.  
 

Fair enough on both counts and the introduction of the subterranean sub-type solves another problem I was ignoring at this point.

Thus a Penguin is both aquatic and terrestrial, but not volant.  A Duck is volant, aquatic and terrestrial.
 

and this is the rissole in the roll!  How can I describe a concrete and creatable type (penguin or duck) that is direct decendant of the (not shown) bird type that implements a different (sub)set of interfaces!

On further thought, perhaps it might have been better to have - InWaterAnimal, OnGroundAnimal, BelowGroundAnimal, InAirAnimal

Had these, only using the current names as shorthand

I think your model is sufficiently simple for my idea not to be required.  But any more complex and I think there may be that combinatorial explosion I mentioned.
 
Paolo
 

I probable should have taken the time to explain it a tad better

WRT your aside, I don't think there ought to be any difference; since conceptually, I would have thought they were the same thing - and, according to my methodology outlined in the first post, they should yield the same set of Features.

Not happy Jan!  Although I agree that in theory they are the same thing, I have a sneaky feeling that maybe they're occassionally not.

bruce

p.s. What I'm really truly asking is, am I looking at the same / a similar problem from a different branch lower down the monkey tree?

[Paolo F Cantoni]

bruce,

I won't quote your previous email because we'll quickly get into n-level quotes.  I'll answer bits and pieces.

Firstly with respect to the aside.  You're quite right to be unhappy!  I was too quick off the mark!  In this case they (MutableAssociativeCollections & AssociativeMutableCollections) are (probably) the same - but if this is the case then I should formally say so - in the model!

The contrary case is that a HouseBoat is definitely NOT the same as a BoatHouse.

I have mechanisms for handling these aliases.

Thanks for pulling me up...
Paolo

[Paolo F Cantoni]

bruce,

I take it you're happy with:

InWaterAnimal - Aquatic, OnGroundAnimal - Terrestrial, BelowGroundAnimal - Subterranean, InAirAnimal - Aeronautic

Now you haven't shown Bird (as you mentioned)..  The beauty (to my mind) about GeneralizationSets is that you DON'T have to be stuck with ALL birds fly.

In reality, not all birds fly - therefore, only those features that are true of ALL birds need go into Bird.  If the Bird is capable of flight then you also inherit from Aeronautic.

Some birds are aquatic - they  inherit from Aquatic.  Some birds (like our Emu)  are both flightless and non-aquatic - they inherit from Torrential only.

When designing a particular bird type, you have to inherit (or realize) from the appropriate suppliers to create the appropriate feature profile.

If you really need to design a Penguin versus a Duck then you have to have the right suppliers.

The question in my unoriginal post was: Do I have a method for controlling the combinatorial explosion this leads to?

The mechanism I've created (I think) allows me to work out which suppliers I need to consider (and under what circumstances).

Thoughts?
Paolo

[Paolo F Cantoni]

bruce,

I noticed that in your example you've used a mixture of Generalizations and Realizations.

A few questions:

The model seems a bit self inconsistent with regard to their usage.  Was that just a slip of the fingers or is there a rationale behind your usage?

You may recall some early pontificating of mine on Generalization versus Realization and the somewhat limited support for both in EA (and, to be fair, almost all other modelling tools).  I was thinking discussions around this might help firm up some ideas in this area.  Especially at the level we seem to be discussing - that is CIM and above...

Paolo

[sargasso]

Generalization v realization - the diagram is just a hack, at some point I thought interfaces (contracts) may help disolve the problem and changed classes to interfaces.  I have just never finished the exercise.

You are correct - the entire problem is penguins v ducks and how to design using the appropriate suppliers.  (Although torrents of emus is a frightening concept.)

The crux of my issue is, I believe, the same as yours.  I have a primitive type - animal that exhibits a primitive behaviour "move" (the implementation of which modifies the location attribute property of an instance of the concrete class).  Depending on some aspect of the concrete class classifier, an indeterminent set of the specialised behaviours need to be considered.  

As you say, at the conceptual level or DIM, this could lead to a plethora of possible 2nd and further level combinations.  I am trying to work backwards from a concrete example (as usual) to the conceptual answer.  I will now take your idea and try to work from both ends towards the middle and see where that gets me.  

I think where our thinking differs is that you (IMunderstanding) appear to be looking at a summation of available features, I am thinking that there are possibly more complex examples where the final concrete design may include "this and that but not those" issues.

bruce (wishing he'd never posted a working diagram   )

p.s. I've stolen your words!  Out of context they are eminently enigmatic.

[Paolo F Cantoni]

I think where our thinking differs is that you (IMunderstanding) appear to be looking at a summation of available features, I am thinking that there are possibly more complex examples where the final concrete design may include "this and that but not those" issues.

Well, in the topic What and How should things get Specialized?, I specifically address the need to support the notion of Undefining in the Specialization process.  So we have the same idea there.

But, in principle, it's better to sum than to remove.

However, the essential point is what we've come to agree on:  What is the Einsteinian¹ solution to specifying which set of specialized behaviours should be applied to this concrete classifier based on what set of aspects of the concrete classifier?

So, back to square one.  Does my current solution fit the bill or is there a simpler one.

Paolo

¹Einsteinian solution: one that is a simple as possible, but NO simpler.  That is, a solution that is NOT simplistic.