Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Svend Erik Nygaard

Pages: 1 ... 5 6 [7] 8
91
UPDATE: Sparx has acknowledged this as a bug:
 
"Our developers have confirmed that this is a bug and it is logged to be fixed. We cannot yet say when (in which build) the fix will be implemented."
 
"If necessary, as a current workaround you can right click the Port, select 'Port Size Customizable', then manually resize the Port."

92
UPDATE: Sparx has acknowledged this as a bug.

In my MDG I hav created some stereotypes extending the Port metaclass.
When we use these stereotypes, the elements are not manually resizable - just like original Port elements.
However, unlike the original port elements, these elements do not resize automatically when we add exposed interfaces to them.
Is there a solution to this (e.g. can I make them manually resizable or auto-resizable somehow)?

93
Quote
It would perhaps be helpful to know why ...

Quote
...

Hi Simon M and RoyC, am I too optimistic to hope that your silence indicates that you are considering what to do about this?

94
@Simon: ”Intentional … UML … owned by the stereotype”:
But I guess that does not prevent a UML solution (e.g. EA) to add a feature of saving ’orphan’ tagged values (and possibly even trying to convert them into the new tagged values belonging to the new stereotype. It could be an option in the settings.

@Simon: ”… two stereotypes have a common parent …”
Well actually this depends:
If you choose the new stereotype from the drop-down-box in the properties window – then the tagged values with common namespace actually do survive.
If you dragt it from the tool box and “Apply …” it, then it adds the new stereotype (the element now having two steretypes). Sometimes the new stereotype becomes the last stereotype in the stereotype list for this element – sometimes not, I haven’t figured out how this works. This is actually one reason why users often delete the old stereotype from an element - before they apply a new stereotype for the element.

@RoyC: ”why … take the defining stereotype away again”.
Well two quick and not-totally-fair [ch61514] answers (1 and 2), but still worthy of consideration – and then some more reasons 3-5:
1: not-totally-fair answer (but still worth considering): well – why is it possible to change the stereotype of an element? – I guess in some ways, that’s the same question (even for MDG-stereotyped elements)
2: Likewise: why is it made possible to change even the type of an element (Advanced -> change type)
3: it also happens by accident – and even though it may not be very often its impact increases by the fact that the user often does not notice, that all the tagged values have disappeared. There may be 20 tagged values which each represents considerable analysis time and interview time with business people.
4: Sometimes, users want/need to change stereoypes simply because they get more clarified of what they/others really are talking  about (during an analysis phase quite a lot of concepts can be very abstract/fussy initially). Usually this does not lead to a change in stereotype, but it does happen. I guess this scenario is part of point 1 and 2.

@RoyC: ” If someone deletes a stereotype by accident … you can restore … Tagged Values by dragging the stereotyped element from the Toolbox over the 'broken' element in a diagram."
No. The earlier specified values are not restored (the tags are restored, of course, and with default values, but the actual values are not restored)


95
@Simon: This is quite an issue for the use of EA in my Company (CPH Airport) - and we don't see any work-around for it. I really don't know what to do on this - we are in trouble!

@qerty: Thanks for the input. OnContext event - I don't know it, it seems to be something that Add-Ins can use - but I don't write Add-Ins.
Can I use it in EA scripting (JScript)? - I do write EA scripts.

96
I have created Stereotypes in MDG.
When I remove/change the stereotype on an element in my model, it looses the tagged values associated with the stereotype.
In the MDG I have derived stereotypes, e.g.:
ResourceObj specializes BusinessObj which specializes Obj which extends Class.
Obj carries the tags which are common for all aobjetcs etc.
My problem is, if a user changes/removes the stereotype on an element, all the tagged values are delted - and often the user wants to keep/transfer the tagged values.
Or maybe the user just removed the stereotype from the element by an accident.
Is there a way around this issue?
(In the old days, when I just used UML profiles (in EA v. 7), EA kept any old tagged values. That might leave some mess, but better for me to clean up via scripts, than loosing the tagged values)

97
Thanks @qwerty.
So EA Object Model does not support testing if an element has a given stereotype with a given namespace like "CPH_MetaModel::Application"?

98
Thanx, qwerty, that works just fine.
But new challenge: How do I see the full name of the existing stereotype?
(I mean in script - but actually I don't see how to se it in the GUI either)

99
In EA script, How do I specify which stereotype when there are more stereotypes with the same name?
They have different namespaces. But how do I specify the one I need in an assignment like: Obj.StereoType = "StTypName"


100
Thanks Qwerty.

I was fooled by my own 'debug'function that wrote the element collections out before and after - I just forgot to refresh those collections :-/

Thanks for good response :-)

101
In an EA script, I want to move an element from one parent element to new parent element.
How do I do that?

102
Quote
Quote
BUT: the tags are not grouped according to the tag groups
I'm fairly sure that was fixed for EA 11
OK, sounds good, then I'll wait for EA 11. Can you indicate when this might be?
BTW: So the way, I used the specialization is OK?

103
The model in the top post works except the grouping of tags is it  it ignored at the specialized stereotypes. The tags are there, just not grouped.
(In EA 1007)

104
Thanks MrWappy,

I thought about that - but then I thought, There must be a smarter way  :-/

I will fall back on that, if I don't find other solutions.

(BTW, I updated my post with a picture of the profile's diagram  (apparently one cannot upload images directly to posts here?) )

I hope to get back to solve this issue tomorrow (There's also the Tagged Value connector in the profile toolbox?)

105
In a UML profile, I have:
• A <<metaclass>> ”Class”
• A <<stereotype>> ”Obj” extending ”Class”
• Three <<stereotype>>s (”ProcessObj”,”ResourceObj”,”ReferenceObj”) specializing ”Obj”

Like this:


When I use the three <<stereotype>>s ”ProcessObj”,”ResourceObj”,”ReferenceObj”, they all have inherited the tags from  ”Obj” – so far so good.
BUT: the tags are not grouped according to the tag groups – in fact they don’t seem to have the tag groups (although the tags themselves are all there).

If I double check by including the ”Obj” in a toolbox in the MDG file, the ”Obj” does have the tags grouped properly.
I have many stereotypes sharing a common set of base tags. Is this not the proper way to do it?
I’m not familiar with how to use the Metatype, but have tried different variations without that solving this issue.
Does any body know how to do this (sharing a common set of tags)?
Also: Am I using the ”Generalization” connector in a wrong way in my UML profile?



Pages: 1 ... 5 6 [7] 8