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 - Arnoud_B

Pages: [1] 2 3 ... 6
1
Thanks Geert,
Well actually the SetCompositeDiagram() works in my case so I do not have to use your more dangerous query solution.

I am a bit ashamed to say that I just did not scroll down enough in the help text to find this myself.

In my defense I have now completed a kickstart script that will generate a basic set of diagrams with navigation between them based on an well structure model.
It is really amazing at times what you can do with the scripts although it is hard to get them dummy proof, as a mistake in your script (or in my case an unanticipated use of a script in a different context) can do a lot of harm to your repository. So my kickstart script is heavy user only ;-)

2
In the GUI you can easily add a ChildDiagram to an Element by using "New Child Diagram" either by creating a new Diagram with "Composite Structure Diagram" or linking an existing with "Select Composite Diagram".

I am generating a skeleton set of Diagrams based on my model and I would like to link the created diagrams to 'their' Element. However in the API the attribute CompositeDiagram is Readonly

Notes: Read only
If the element is Composite, returns its associated diagram; otherwise returns null.
Diagram Class

Also from the other side; Diagram object I do not find a way to set this, anybody did this before?

3
Well I try to keep the three axis aligned with scripting;
- Based on a structural ArchiMate relationship scripts in our repository will or move the element to the correct parent (in the repo browser setting the parent relationship or SparxEA) or alert with validation scripts where the parent is not the same as the expected element based on the found relationships. This way I try to keep the hierarchy in the repository the same as the ArchiMate relationships visible in the diagram.
Diagram scripts will auto nest or un-nest elements that are partially overlapping and are the child or parent of each other. Again to make what people think the see is modeled and and what is actually in the model the same.
Without validations on the repository and the diagrams you can easily create diagrams that suggest something completely different compared what is actually in the repository.
For that reason I am sub-typing ArchiMate stereotypes as we use the same ArchiMate stereotypes in different context and they are only allowed to use a different subset of the ArchiMate specification in that context. So we are 100% compliant to the ArchiMate spec but sometimes a bit more strict.

4
Hi Eve,

Quote
Why? Assuming you could eventually implement something equivalent to the implementation that already exists in EA.
It is ABSOLUTELY NOT my goal to re-invent the wheel and if I could support my modelling requirements without extending ArchiMate3 MDG or by extending it (and not re-implementing it) that would certainly be my preference. However SparxEA does not seem to enable you to really overwrite stereotypes you can only extend them. So if I think there is too much possible in a stereotype (my main example is that the quick picker shows relationships that are not in the spec and are actually derived relationships at best) I cannot remove these things I can only add more on top.
So I would definitely want to inherit the hiding behaviour during nesting of the ArchiMate3 MDG however if I generalize an ArchiMate3 stereotype I get all stuff I do not want. If you know a way around that I would be VERY HAPPY to understand how.
Quote
The only thing you'll achieve is that you would not be able to share models without sharing your technology. Even then, linking between the standard implementation and yours is going to be problematic.
Yes that is a major discussion now with my colleagues; do we stay standard and except limited useability on how much we can help our users to model correctly and how much we can auto validate with scripting. Or do we go custom and create a maintenance problem in the future as somebody has to maintain the MDG assure it followes future ArchiMate releases etc.
The whole reason we model in SparxEA and NOT in visio is because it is supported by a model which you can validate to detect modelling errors and from which you can auto generate views showing ALL related entities keeping views up to date with out a major resource impact. For now I am not able to create human readable things and clear errors without adding context to the ArchiMate model by specializing.
Again for me at the moment it is choosing between a rock and a hard place. But I am used to that as Architect  ;D

5
Quote
You actually are not nesting, but visually embedding.  We created some automation to manage this, but (as usual) there are some SParxian "gotchas" involved.
Thanks for putting me on the right track, embedding is the term used in the ArchiMate spec but that indeed does not mean SparxEA uses a similar terminology. I'll have a search an a try. Your last part of the sentence does not make me happy though  :-\

6
Quote
Having said that, it conceptually kind of works for aggregation/composition connectors but it can be ambiguous about what connector is present in this circumstance makes it generally a bad idea.
Well we can debate if ArchiMate syntax is logical or not on other fora I think. I just implement the specification is it is written down by the OpenGroup.

7
Querty, you are not correct SparxEA does that for you on numerous occasions only my MDG does not reproduce that behaviour so I have to set an attribute somewhere I think. Only then the $10.000 question which attribute. I did not find any thing in the documentation that pointed in the correct direction.
I made some screen shots of what happens:
https://imgur.com/a/OcwuYiQ

8
I now have a working (very partial) ArchiMate implementation with nice looking elements and the correct relationships in my quick linker by using the "stereotyped relationship" in my profile definition.
However when I nest elements the relationships do not get hidden or at least not always.
If I have a composition between two (the same) elements and I nest them in the correct direction the relationship gets neatly hidden in the diagram. However I have created for instance a realization between my version of a service and an interaction and that does not get hidden when I nest the service in the interaction.
I searched the docs but I cannot find an attribute that influences this behaviour.

9
Hi Sunshine,
I downloaded your zip and will take a look at it soon. Many, many thanks I am sure it will be an very valuable source of inspiration. This forum has been a life saver in many instances as I struggle through the documentation (which is actually not that bad it is just not enough) and often I do not understand or I think I understand and it does not work etc. Having an example will be very helpful to 'steal' and adapt. Hope I get better in this and maybe return the favour one day and fix a problem for you.

10
Hi Geert,
Thanks again, it works! learned another thing today. I'll get there step by step; i'll 'release' my first MDG next week to my colleagues as it now supports our modelling of technology standards. I'll extend it into other areas over the coming weeks-months-years who knows.

11
Well extending ArchiMate3 gives me headaches so I am going another direction; create an MDG from scratch but one of the things to do is to create icon's.
The documentation only tells:
Quote
Contains the bitmap file location of the 16x16-pixel icon displayed beside all elements defined by the Stereotype, in the Browser window. This does not apply to Package elements. The icon is also automatically used as the Diagram Toolbox image wherever the stereotyped element is listed.
That is not very specific, anybody created icons?
What do you have to create a bmp a jpg encode it base64 ... any tips and freeware tools (or even payed tools) people use to do this are more then welcome.

12
Thanks querty for blaming SparxEA and not me ;-)

I spend a morning experimenting and I succeeded in adding a connector type to my quicklinker.
As (nearly) always there were some 'you have to know it' where the documentation was not really 100% correct. Or at least not for my situation.
I needed to use the full name of the connector type so ArchiMate3::ArchiMate_Access otherwise no luck
And a nice one you have to set the "stereotype" tag on the stereotyped relationship tags which is only visible on the properties pop-up and NOT on the dependency tags which is the only thing visible in the properties window ...

So now I can add things to my quicklinker but I wanted to remove things from the quicklinker, the quicklinker has all kind of entries because my new Stereotype Generalizes an ArchiMate3 Stereotype. If I remove the generalization my quicklink menu only shows the one I configured but if I reintroduce the generalization they comeback. I succeeded to remove the UML connector types with the _HideUmlLinks=true attribute but that does not seem to work (which is logical seeing its name) for the inherited connectors from the ArchiMate3 stereotype.

Any idea's how to keep inheriting an ArchiMate stereotype but not inherit it's quicklinker menu entries?

13
Thanks Paolo,
That fixed it (well nearly) I still have a vague outline of the rectangle drawn although I "remove" two decorators the device one and the composite one and the top one still have a bit of a shadow left but the other one hasn't ?? if I zoom with SparxEA the shadow goes away or becomes bit worse, it seems a rendering glitch it is not really a problem.
I tried the noshadow command but I think it only effects the complete shape

   noShadow=true;

   // 'remove' the original image by drawing over it in the background color
   setorigin("ne",-26,10);
   setpencolor(getUserFillColor());
   rectangle(0,0,100,100);

A more generic question on this; is shapescript case sensitive? the documentation says noShadow and in the shapescript I copied (ArchiMate3) it uses noshadow. As tiny typo's lead to non-working stuff without any errors I get a bit paranoia, however I tried both and I have a tiny shadow anyway ...

14
Thanks guys!
I'll read the page carefully and experiment. I am mostly impressed with the tricks SparxEA can do but it is not at all self explanatory at times. Or my programming skills got rusty as I am doing Architecture in PowerPoint for too long ;-) Probably both!

15
Paolo,
Hopefully the last question; where do you turn the gradient fill off. I cannot find it in the default appearance (F4) you can only set the color there I think.

So here my code hack for anybody who wants to do the same:
@Paolo, did you do it in a similar fashion or did you find a better way to do this?

decoration device // same icon but on a different place
{
   orientation="ne";
   
   // 'remove' the original image by drawing over it in green
   setpencolor(getUserFillColor());
   
   setorigin("ne",-26,10);
   moveto(15,75);
   lineto(0,100);
   lineto(100,100);
   lineto(85,75);
   startpath();
   roundrect(0,0,100,75,30,30);
   endpath();
   strokepath();

   // now draw the new one in the same color as the border
   setpencolor(GetUserBorderColor());
   
   setorigin("ne",-15,0);
   moveto(15,75);
   lineto(0,100);
   lineto(100,100);
   lineto(85,75);
   startpath();
   roundrect(0,0,100,75,30,30);
   endpath();
   strokepath();
}

Pages: [1] 2 3 ... 6