Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: Paolo F Cantoni on December 09, 2011, 06:16:33 pm
-
Can anyone tell me what the meaning of the IsSpecification property of an EA element is?
The somewhat tautological definition in the help says:
IsSpec Boolean Read/Write
Boolean value indicating whether the element is a specification or not.
1 = True, 0 = False.
which doesn't indicate what the property actually means.
If an element is a Classifier isn't it (by definition) a specification? The UML 2.3 Superstructure (formal) (http://www.omg.org/cgi-bin/doc?formal/2010-05-05) Specification says (in 7.3.7 Class (from Kernel)):
Semantics
The purpose of a class is to specify a classification of objects and to specify the features that characterize the structure and behavior of those objects.
which seems pretty conclusive that it is a specification.
In the Superstructure I could find a reference to the keyword "{abstract}", but not to {specification} (nor, for that matter, {root} or {leaf} - IS Active doesn't generate a property rendering)
So if every classifier is a specification, is the point of the Is Specification property?
TIA
Paolo
-
No sorry, I haven't found an explanation in the UML 2.3 specification either.
Maybe if you look into very old UML specs (like 1.1 or something like that)?
Geert
PS. isLeaf is still in use, and isRoot was in use in a previous version, but has been replaced in UML 2.3
-
Ha, I was right!
From UML 1.5 superstructure:
isSpecification:
Specifies whether the ownedElement is part of the specification for
the containing namespace (in cases where specification is
distinguished from the realization). Otherwise the ownedElement is
part of the realization. In cases in which the distinction is not made,
the value is false by default.
Geert
-
Ha, I was right!
From UML 1.5 superstructure:
isSpecification:
Specifies whether the ownedElement is part of the specification for
the containing namespace (in cases where specification is
distinguished from the realization). Otherwise the ownedElement is
part of the realization. In cases in which the distinction is not made,
the value is false by default.
Geert
Thanks Geert,
I was discussing this with colleagues yesterday (which prompted the post) and we came to the conclusion that, from first principles, the only point might be to differentiate realization from specification. Indeed the discussion was generated by finding «instanceOf» and «specifiedBy» relationships in a large enterprise model.
It now seems to me that "{instance} is an «instanceOf» {classifier}" and "{instance} is «specifiedBy» {classifier}" are semantically identical.
What do others think?
On a related note, although a classifier can inherit (be a specialization of) from a number of other classifiers (the multiple-inheritance situation). It seems to me that you can only be an instance of ONE classifier and that if you want to be an instance of multiple, then you first create an aggregate classifier by multiple inheritance and then you instantiate that.
Thoughts?
Paolo
-
Hi,
I'm looking at this issue again with the view to refactoring a number of repositories and models we have.
Does anybody have any more thoughts to contribute?
TIA,
Paolo
-
Paolo,
I think an object always has one and only one type. This type is always a concrete classifier.
But of course the object is also an instance of all classifiers realized or generalized by this concrete classifier.
To be less abstract:
Consider :
Object: MyBrowDuckNamedPolly which has type Duck.
Duck -generalizes-> Bird -generalizes-> Animal
but also
Duck -realizes-> Swimmer
Bird -realizes-> Flyer
Bird - realizes-> WarmBlooded
so we can also say that MyBrowDuckNamedPolly is an instance of Bird, Animal, Swimmer, Flyer and WorkBlooded
Makes sense?
Geert
-
Makes sense to me !
-
Paolo,
I think an object always has one and only one type. This type is always a concrete classifier.
[size=18]...[/size]
Makes sense?
Geert
Thanks for the input Geert. However, I'd like to initiate a discussion since I'm not sure I agree fully with you - perhaps due to my misunderstandings.
Firstly, let me observe that for the purposes of this discussion, multiple inheritance is possible. This is because I'm dealing with the creation of (typically) conceptual models at the enterprise level.
Your example (as I understand it) stems from single inheritance languages (such as c#) which can only inherit from one classifier, but implement multiple interfaces - thereby providing ersatz multiple inheritance. I'm not (I think) talking about interfaces, but only classifiers and objects.
Let me then agree that an object can be an instance of only one classifier (type).
Also, I'm happy with:
Object: MyBrownDuckNamedPolly which has type Duck.
As a consequence we can (and MUST) say: MyBrownDuckNamedPolly is an instance of duck. and therefore that MyBrownDuckNamedPolly realizes duck.
And I agree that:
Duck -specialises-> Bird -specialises-> Animal (NOTE: I changed the name of the relationship, but not the intent)
but also one can say:
Duck -specialises-> swimming Bird -specialises-> Bird -specialises-> flying Animal -specialises-> Animal
And that Bird -specialises-> warm blooded Animal -specialises-> Animal
Providing the multiple inheritance.
Does that sound right?
The real question is: if the object is the instance of the classifier does it always realize the classifier?
-
Why is it that my gut gets bad feeling when someone talks about multiple inheritance? Warm blooded animal? What class is that? It just provides a constraint that the metabolism has constant blood temperature. Which does in no way rectify to be a class. In "natural" taxonomy you always have single inheritance. Multiple inheritance is something so artificial that I can't find it useful for anything. There are always better ways to describe what you want to express with it.
q.
-
Why is it that my gut gets bad feeling when someone talks about multiple inheritance? Warm blooded animal? What class is that? It just provides a constraint that the metabolism has constant blood temperature. Which does in no way rectify to be a class. In "natural" taxonomy you always have single inheritance. Multiple inheritance is something so artificial that I can't find it useful for anything. There are always better ways to describe what you want to express with it.
q.
I agree that one should avoid multiple inheritance whenever possible. But occasionally it is necessary.
Getting back to Geert's example. If I wasn't interested in flight I could postulate:
Duck -specialises-> swimming Bird -specialises-> Bird -specialises-> warm blooded Animal -specialises-> Animal
(nice single inheritance)
and if I wasn't interested in blood I could postulate:
Duck -specialises-> swimming Bird -specialises-> Bird -specialises-> flying Animal -specialises-> Animal
(another single inheritance)
In "natural" taxonomy - in the Linean sense - you are constrained by the classifications that enforce single inheritance - since it relied on external appearances. I believe that it was specifically designed to generate a tree (as opposed to a lattice). Modern genetic biology has found real problems with the original classification and some plants (Australian, of course ;)) are being moved around. Whereas you'll note that Geert's example uses other than visual characteristics to classify.
Can someone explain exactly why the two single inheritance branches above are wrong.
If they are both correct and it's the same duck why can't I combine the two branches into the multiple inheritance lattice I started with?
Just trying to get a better understanding.
The example I normally use for multiple inheritance is a houseboat - inherits from both house and boat (to be distinguished from a boathouse - inherits from house only and contains boats)
Paolo
FWIW, languages like Eiffel - which are specifically designed to handle conceptual to physical modelling/coding do allow mutliple inheritance and handle it with very precise semantics. (See OOSC2 by Bertrand Meyer)
-
If they are both correct and it's the same duck
You can not compare apples with peaches. Both might be right but then they can't be the same duck. They might be correct aspects of the same duck. But than in both cases the abstraction is not complete. Is it that you want to join both abstraction lines into one single object to make it complete?
q.
-
If they are both correct and it's the same duck
You can not compare apples with peaches. Both might be right but then they can't be the same duck. They might be correct aspects of the same duck. But than in both cases the abstraction is not complete. Is it that you want to join both abstraction lines into one single object to make it complete?
q.
Yes! To me this example is the essential problem of Enterprise Architecture: Each application/organisational unit/some other viewpoint has an incomplete picture of the same object. One of the jobs of the enterprise architect is to resolve the legitimately different views of the same object into a single coherent view and, conversely, to identify and eliminate the illegitimate views.
So, for example, supposing the first single inheritance chain was the DB structure for one application and the second was another application's view in their DB. If I was needing to build an operational datastore which needed to reconcile both views, I'd end up with the union of the two (for the same duck). I'd have to change the right information for the views of each application but retain the corporate view in addition.
By the way, the multiple inheritance issue is actually peripheral to the question I'm asking - which is (effectively) under UML v2 is the IsSpecification property in EA redundant?
I'm interested in resolving the multiple inheritance issue. But at present, it is secondary to understanding the relationship between object realizing its classifier and the object being specified by its classifier.
Are they two directions of the same relationship (such as generalizes/specializes above). it seems to me that they are - but I'd like independent confirmation.
Paolo
-
By the way, the multiple inheritance issue is actually peripheral to the question I'm asking - which is (effectively) under UML v2 is the IsSpecification property in EA redundant?
Paolo,
Did we not already establish that?
IsSpecification was present in the UML 1.5 spec, but not anymore in UML 2.0 spec.
So the only reason it still exists in EA is because of compatibility with UML 1.5.
Geert
-
One of the jobs of the enterprise architect is to resolve the legitimately different views of the same object into a single coherent view and, conversely, to identify and eliminate the illegitimate views.
The other job is the exact opposite: create different views of the same object. Which is what appears to be the more "natural" task of the architect. Finding redundant views and unifying them is one that never has been too much in my focus. I must confess: a quite interesting task. But unfortunately none I could contribute too much.
q.
-
By the way, the multiple inheritance issue is actually peripheral to the question I'm asking - which is (effectively) under UML v2 is the IsSpecification property in EA redundant?
Paolo,
Did we not already establish that?
IsSpecification was present in the UML 1.5 spec, but not anymore in UML 2.0 spec.
So the only reason it still exists in EA is because of compatibility with UML 1.5.
Geert
Yes we had esablished that. But I guess the real quesstion I was asking was: is "Specified by" the semantic inverse of "Realizes"? If so then I only need one arc otherwise I need (I guess, potentially) two different suppliers.
Paolo
-
One of the jobs of the enterprise architect is to resolve the legitimately different views of the same object into a single coherent view and, conversely, to identify and eliminate the illegitimate views.
The other job is the exact opposite: create different views of the same object. Which is what appears to be the more "natural" task of the architect. Finding redundant views and unifying them is one that never has been too much in my focus. I must confess: a quite interesting task. But unfortunately none I could contribute too much.
q.
Yes, you are correct and in my experience the latter is much easier. ;)
But the former is the real problem as enterprises find their existing "stovepipes" get in the way of effectiveness and efficiency. One of the first enterprise level assignments I took on (over 20 years ago) was when the CEO of a rail freight organisation asked the question: "How many trains do we have?" of his 4 senior managers and got 5 different answers! :-?
An interesting assignment...
Paolo