Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Boron on July 31, 2017, 11:42:24 pm
-
Hello,
since several weeks I am asking myself the hell is a "property" when dropping a class element in a diagram.
When dropping a class element in a diagram a dialog appears asking of what kind the dropped element shall be created: Link, Instance, Child, Property.
Links, Instance and Child are perfectly clear.
I just don't know what a property might be.
Can anyone bring light into my darkness?
All explanations in the internet did not really help (maybe bad explained or I am too stupid for that).
-
In addition to attributes, there are some UML Class based languages having properties as well.
One example is SysML Block diagrams were a Block (more or less a Class) can have many specific kinds of properties.
Properties are similar to attributes but not the same.
-
The term "property" has many meanings, depending on both the domain and/or the context of usage. It's unfortunate, but there it is.
In addition, its meaning can vary depending on whether one is speaking in narrative or technical terms.
Paolo
-
When dropping a class element in a diagram a dialog appears asking of what kind the dropped element shall be created: Link, Instance, Child, Property.
Paolo is correct that Property has many meanings depending on context. In this context, it is used as a synonym for Part.
-
When dropping a class element in a diagram a dialog appears asking of what kind the dropped element shall be created: Link, Instance, Child, Property.
Paolo is correct that Property has many meanings depending on context. In this context, it is used as a synonym for Part.
Only Part? If so, why not just use Part? Why use a synonym (whose meaning is often not identical with the original term) when there is a perfectly acceptable (and, in this case, absolutely accurate) term already available?
Now that I've got involved with OntoTerminological Modelling, it has helped me work out some of the background rules or guidelines to enable as clear communication as possible. As a consequence, I've had to modify some of my language usage - hopefully for the better. :)
Paolo
-
Well, at least in SysML a property might be a part but it might be a shared thing as well or a Feature or a Flow Property, or ...
-
Well, at least in SysML a property might be a part but it might be a shared thing as well or a Feature or a Flow Property, or ...
Granted, Peter,
But in the context of dragging (and dropping) a class element onto a diagram (as Boron originally mentioned)...
Paolo
-
In UML 2.5 a property is just a catch-all name for a feature of a classifier. The excellent (and concise) "The Unified Modeling Language Reference Manual, second edition" by Rumbaugh, Jacobson and Book takes 7 PAGES to explain properties. So, I suggest you just roll with it.....
-
Hello Paolo,
yes, you are right.
The term property has just too many meanings depending on the context it is used.
Maybe “Role/Reference” instead of “Property” would fit better to that dialog.
-
The dialog is just using the UML term for what is created. In that sense, it's the easiest term to use.
Reference/Part and part both have specific meanings in SysML, while Property is the catch all term that encapsulates all usages.
-
According UML spec. 9-5.1
Properties are StructuralFeatures that represent the attributes of Classifiers, the memberEnds of Associations, and the parts of StructuredClassifiers.
So the dialog uses a superset term of what is happening.
The terms role and reference are used in both UML and SysML spec.
Now after looking in the UML spec. I think the best term to use would be “Aggregation”
But anyhow, I worked with the term “Property” for years and I can life with that in the future as well.
-
A classifier is a classifier.
An attribute/property/pin/part/pineapple/frangipani is an informational feature of the classifier.
It is "convenient", within a context to give such feature a "prominent" name.
There are 10 types of things about a classifier: attributes (informational features) and behaviors (things you can tell an instance to perform).
There are no other things.
No matter how you dress up reality with this, that or the other "approach" to modelling the universe.
A model is a picture of the universe that helps explain an aspect of something in the universe.
A house plan helps explain the dream between the architect and the builder.
A color patch helps (occasionally to) explain what the wall will look like when it is painted.
A UML diagram should be constructed to explain, within some conversational context, some aspect of a system.
If the so called "rules" of UML don't let me do that, then I break them.
Let me say this only once (for the second time)! The model is not reality. The house plan is not the house, the color patch is not the paint. To paraphrase(?) Sylvia Plath "A rose is a rose", a picture of a rose is not a rose but it may give some audience an idea of the plant that I am talking about.
Go think about a painting that you like, of a rose if you like, or a fish or a tree or a car or a scream. Why is it good? Because it engenders something in your psyche - it just "gels".
And explains.
Now consider the person who painted it. Were they worried about whether this shade of blue was called "Prussian" or "Cobalt"?
Or were they just using that shade to convey, as clearly as possible, to the "audience" some aspect about that flower that they wanted to explain?
Model to explain, perhaps even unto yourself, aspects of the universe. Dressing up models with OMG names and trying to comply with the so called "rules" is a waste of both your and your intended audience's waste of time.
Is a property the same as a "Prussian Blue"? I think not.
Not clear enough? Well let's go sit in a coffee shop tomorrow and you can explain to me "how to get from here to Tiffany's in time for breakfast", on the back of a napkin. Would I expect a Google map of the world? (Complying to dog knows whatever "standard" they use.) Now, given the current context, that we are sitting in a cafe in rural South Australia - would you try and draw a google map?
Classifier: Location
Attribute: geopos? (whatever)
Behaviour: Describe_route(destination::Location) as Scribble_on_napkin
bah! Sometimes I think UML modelling has got to the point of acute cranial-recto-insertion.
b
p.s. This rave was in part incited by a recent post on the dreaded "more than one instance of the same entity on one diagram" dinosaur. In particular let me refer to figure 15.1 in the most recent adopted specification. Oh dear! There is more than one instance of an Adapter Behavior in that diagram. Oh dear, worlds will collide! Oh no, don't tell me OMG just broke one of their own rules. Oh hang on - there is no such rule anyway. But why didn't they draw it with so many damn criss-cross lines as to make it totally unintelligible?
(Damn. It was another diagram, but the point is still there.)
-
Figure 15.1 on p. 372 of formal/2015-03-01 seems absolutely legit.
q.
-
? Same page (372), "Behavior" at top center and bottom left.
? And now I look at the there are two "Redefinable Elements" as well.
-
My brain...
However, I'd accept that as "kind of legit". EA has this nice italic display of generalized elements which has not found it's way into the UML specs.
q.
-
Now consider the person who painted it. Were they worried about whether this shade of blue was called "Prussian" or "Cobalt"?
Or were they just using that shade to convey, as clearly as possible, to the "audience" some aspect about that flower that they wanted to explain?
You sir, have obviously never hung out with historical war gamers or train spotters :-)
Which I suppose comes down to in some instances that colour is an attribute used to judge authenticity.
-
The "modeller's painting" is, of course, Rene Magritte's "La trahison des images" (The treachery of images), commonly called "Ceci n'est pas un pipe" ("This is not a pipe").
(https://uploads8.wikiart.org/images/rene-magritte/the-treachery-of-images-this-is-not-a-pipe-1948(2).jpg!Large.jpg)
Some information in: The Treachery of Images (https://en.wikipedia.org/wiki/The_Treachery_of_Images)
Also, listen to the "W**k" in: Two art historians discuss (https://www.khanacademy.org/humanities/art-1010/art-between-wars/surrealism1/v/magritte-the-treachery-of-images-ceci-n-est-pas-une-pipe-1929), wherein it is asserted that "the representation of the thing is the thing".
Welcome back, sargasso! I, for one, have missed you!
Paolo
[EDIT: on the subject of "The Treachery of Images", check out Bus seat burqas spark online outcry (http://thenewdaily.com.au/news/world/2017/08/02/burqa-bus-seats-spark-outcry/?utm_source=Responsys&utm_medium=email&utm_campaign=20170802_PM_Update) :-X]
-
Sorry for bringing this up again, but I have to vent my anger and here at least there are sane people.
This happened elsewhere and today by the way!
THEY: Oh, you can't have the same name for a component and a class.
ME: (deep breathing for at least 24 minutes) Que?
THEY: Oh, you can't do that because they would mean the same thing!
ME: (madly fumbling for 000 on my phone) So, a picture of a brick called "Fred" is the same thing as a picture of a dog called "Fred"?
THEY: Uh, what do you mean?
ME: ("Yes, hello operator. I desperately need three kg of Valium") Listen carefully, I will say this only once! (thinks: or twice,or thrice or perhaps 6.023*10^26 times...) (Very deep breath) OK. Is a picture of a dog called Fred the same thing as a picture of fish called Wanda?
THEY: I thought we were talking about the system?
ME: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGHHHHHHHHHH!
Oh and by the way Paolo, that is actually a picture of a Picture that is (vicariously) called "This is not a Pipe" :P
-
Oh and by the way Paolo, that is actually a picture of a Picture that is (vicariously) called "This is not a Pipe" :P
Actually an instance of a picture of a picture .....
<ducks>
-
Oh and by the way Paolo, that is actually a picture of a Picture that is (vicariously) called "This is not a Pipe" :P
Actually an instance of a picture of a picture .....
<ducks>
And so the question is begged... Over the last couple of weeks, since I came back from holidays, I have been grappling (again), occasionally, with the question of what is an "instance"? ;)
I'm serious! I contemplated posting on the matter to get feedback, but till now proved too lazy. Now I guess I'll have to. Watch out for it in the UML Process folder.
Paolo
-
Sorry for bringing this up again, but I have to vent my anger and here at least there are sane people.
This happened elsewhere and today by the way!
THEY: Oh, you can't have the same name for a component and a class.
ME: (deep breathing for at least 24 minutes) Que?
THEY: Oh, you can't do that because they would mean the same thing!
ME: (madly fumbling for 000 on my phone) So, a picture of a brick called "Fred" is the same thing as a picture of a dog called "Fred"?
THEY: Uh, what do you mean?
ME: ("Yes, hello operator. I desperately need three kg of Valium") Listen carefully, I will say this only once! (thinks: or twice,or thrice or perhaps 6.023*10^26 times...) (Very deep breath) OK. Is a picture of a dog called Fred the same thing as a picture of fish called Wanda?
THEY: I thought we were talking about the system?
ME: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGHHHHHHHHHH!
Oh and by the way Paolo, that is actually a picture of a Picture that is (vicariously) called "This is not a Pipe" :P
I would suggest that the answer could have been that in UML 2.x components and classes are semantically DIFFERENT things, therefore they CAN have the same name... it would be like using he same name for an actor and a class... not necessarily a good idea, but not incompatible with the standard. I think that classes realize components, so they are not the same thing semantically.
-
And so the question is begged... Over the last couple of weeks, since I came back from holidays, I have been grappling (again), occasionally, with the question of what is an "instance"? ;)
No, the question most definitely is:,
"Is the instance of the picture of the picture of a pipe
that you see
on your PC
the same instance of the picture of the picture of a pipe
that I see
in front of me
on my PC?"
It must surely be
that that could not be.
Unless we gaze upon the same PC.
Then I'd be thee, and thee'd be me ...
a thought that doth not comfort me.
See,this UML stuff is easy! Even a child could understand it.
As usual, I will sign off with a
b
-
"What's in a name? that which we call a rose" :)
-
"What's in a name? that which we call a rose" :)
"Aye, there's the rub"
That which we call a pig,
By any other word would not smell as sweet.
Paolo
-
"What's in a name? that which we call a rose" :)
(Now I was given the understanding that we were eschewing the Bard? Mneh?)
Don't forget that just at the beginning of that she (being the Juliet in question) says:
"'Tis but thy name that is my enemy."
Which of course brings back in a full circle to "What is a Romeo?" (originally "Wherefore art thou Romeo?")
Is it a part, a role, an actor, a class, a classifier, an instance of any of the beforesaid?
I think the only thing that we can definitely agree upon is that "Il est pas une pipe!"
b