Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on July 30, 2021, 06:19:43 pm
-
Many of you will be aware that we are using a highly structured metamodel to do (seemingly) magical things with our MDG. A significant technology used in this process is inheritance (via Generalization/Specialization). We are really starting to "kick-ass" with the inheritance of stereotyped relationships.
In the normal conceptualisation of inheritance, there are a number of use cases:
- Direct "inherited" copy of the feature from the generalization into the specialization
- Modified (typically renamed) "inherited" copy of the feature from the generalization into the specialization
- Addition of feature in the specialization
What is not so well known is:
- Removal of a generalization Feature from the specialization
Inclusion of the removal use case allows for the creation of "Einsteinian Structures"[1]
In the case of Stereotype inheritance (specialization), we have the first three in our metamodel. It seems to work well (in general).
When considering whether one stereotype is a specialization of another stereotype one needs to consider (inter aia) the degree of overlap of the features. I believe it is generally accepted that if the degree of common overlap is high enough, then a specialization exists. But that begs the question how do we indicate that the specialized stereotype may not have one or more features of the generalized stereotype?
When modelling real-world items, we generally handle this kind of thing via the Specialization relationship itself and encode how the mapping between the two ends is to be handled.
To get EA to do this "out of the box" would be tough (if not impossible)!
One idea we've had to indicate that a feature should not be inherited is to create a feature with the appropriate name in the specialized stereotype and set its multiplicity to [ 0 ]!
Thoughts?
Paolo
[1] That follow the Einsteinian dictum: "Keep things as simple as possible, but no simpler!"[2]
[2] People tend to ignore the second part of the dictum!
-
Honestly, I never heard of that concept. Is that stated in the UML specs?
q.
-
Honestly, I never heard of that concept. Is that stated in the UML specs?
q.
No, it's a function of OO type inheritance. You'll find it covered in chapters in Bertrand Meyer's Object-Oriented Software Construction.[1]
(Fun fact: Bertrand's lecturer was Jean-Raymond Abrial whose paper "Data Semantics" got me started on this "modelling lark", nearly 40 years ago!)
Paolo
[1] if you think you know what OO is about; read and absorb Bertrand's book. Then you'll KNOW what OO is about. :D
-
Looks like a recommendation :-)
Another fun fact: I looked it up on Amazon (Germany) and found it here (https://www.amazon.de/Object-Oriented-Software-Construction-Prentice-engl/dp/0136291554). In case Amazon will redirect you, here's the description:Textverarbeitung leicht gemacht mit dem neuen Word 2003 und dem bewährten Easy-Konzept für Einsteiger! ...
So it's described as a handbook for Word - lol.
q.
-
Looks like a recommendation :-)
Another fun fact: I looked it up on Amazon (Germany) and found it here (https://www.amazon.de/Object-Oriented-Software-Construction-Prentice-engl/dp/0136291554). In case Amazon will redirect you, here's the description:Textverarbeitung leicht gemacht mit dem neuen Word 2003 und dem bewährten Easy-Konzept für Einsteiger! ...
So it's described as a handbook for Word - lol.
q.
Took me some 30 days, reading 1.5-2 hours per night to get through it. It's a long haul, but worth it.
Paolo
-
Just ordered. 30€ from my USD Paypal account to a UK company taking GBP. And, damn, right after ordering I found that that they had the same book without the CD (wonder whether my old computer can read that, my new one doesn't have a drive any more) for less than half the price. Well, ...
q.n
-
Just ordered. 30€ from my USD Paypal account to a UK company taking GBP. And, damn, right after ordering I found that that they had the same book without the CD (wonder whether my old computer can read that, my new one doesn't have a drive anymore) for less than half the price. Well, ...
q.n
IIRC the CD was to install Eiffel. Sorry, you got caught out.
Meyer uses an interesting approach in the book. He discusses various issues in OO, looks at problems, possible solutions, never mentioning Eiffel once. Then, in the last chapter he says (words to the effect of) "You've seen how we can solve many of the problems with conventional OO languages, by the way, there's a language called Eiffel on the CD that incorporates all those solutions."[1]
Paolo
[1] Got me quite excited! I rushed to install the CD and found myself quite underwhelmed by the UI! Very clunky and pedestrian! It brought home the lesson that no matter how good the underlying functionality is if the UI sucks, it doesn't get you over the line. (Sparxians are you listening?)
My feeling was... "How can the people who figured out how to solve ALL those problems come up with this?" Anyhow, the book is worth it without using Eiffel.
-
I thought of a similar scenario. Alas, the book was made 1999. In IT measures that was about stone age (I would guess the same time a certain Mr. G. S. developed some UML tool). I haven't used Eiffel, but now there's version 20.11 out: https://www.eiffel.org/doc/eiffelstudio/Compiler (https://www.eiffel.org/doc/eiffelstudio/Compiler). I might compare the versions once the book arrives :-)
q.
-
I thought of a similar scenario. Alas, the book was made in 1999. In IT measures that was about stone age (I would guess the same time a certain Mr G. S. developed some UML tool). I haven't used Eiffel, but now there's version 20.11 out: https://www.eiffel.org/doc/eiffelstudio/Compiler (https://www.eiffel.org/doc/eiffelstudio/Compiler). I might compare the versions once the book arrives :-)
q.
The problem wasn't the language, it was the IDE. Even back then it was very functional. I, too, saw the latest version coming out last year.
Anyway, as I said, it contains useful concepts to help you think better about programming and modelling.
Paolo
-
To add my 2c to the debate...
I'm sure I was taught, when I was getting starting the OO world (probably about the same time as Paolo) that specializing like this - not inheriting everything from the parent - was a Bad Thing. A bit like multiple inheritance (see Tom Love's "Seven Deadly Sins of OO" ).
And even inheriting everything, but cheating by saying 'I just override some of the behaviour of my parent, by doing nothing' was fairly bad as well.
In this case, I'd abandon the 'generalize/specialize' approach, and use composition to assemble the right set of behaviours instead.
But without understanding the context fully, it's hard to be definite.
-
Hi Ian,
Thanks for the input.
To add my 2c to the debate...
I'm sure I was taught, when I was getting starting the OO world (probably about the same time as Paolo) that specializing like this - not inheriting everything from the parent - was a Bad Thing. A bit like multiple inheritance (see Tom Love's "Seven Deadly Sins of OO" ).
A couple of points here. I've mentioned many times, that modelling isn't coding. While we can't help but use the overlapping terminology (inheritance, composition, aggregation etc.) their realisation may be somewhat different. This is what I'm trying to look at. While our modelling may be oriented around instances (both specific and placeholder - a form of classification), the instances aren't "runtime objects" as in coding, but persistent.
And even inheriting everything, but cheating by saying 'I just override some of the behaviour of my parent, by doing nothing' was fairly bad as well.
Again, I think that was because of the state of the technology at the time (and, again in my view, to coding vs modelling). If we look at modelling the real world, we see that biological (and non-biological) inheritance is more complex than the simple inheritance allowed under most coding languages.
In this case, I'd abandon the 'generalize/specialize' approach, and use composition to assemble the right set of behaviours instead.
But without understanding the context fully, it's hard to be definite.
I agree that in this case, meronymy (probably aggregation more than composition, since the same shapescript fragment can be in multiple meronyms) is more appropriate in this case, but the technology only allows inheritance[1]. So we have to "go with the flow".
As you'll be aware, there's been a move away from inheritance toward composition thus, supposedly, providing more flexibility and reducing dependency. But the examples (nearly) always cite the stricter coding based inheritance and composition.
That notwithstanding, there is a place for both and it would be really cool if Sparx supported both at the metamodel level.
Paolo
[1] I assume the technology is purely Sparx specified, but there might be some standards applicable.