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

Pages: 1 ... 70 71 [72] 73 74 ... 85
Uml Process / Re: Profiles Multiple Values for taggedValue
« on: October 17, 2007, 08:10:10 pm »
Hi there,

There's nothing stopping you from creating multiple taggedValue connectors with different names from one stereotype to another.

Another way is to create the tags as Attributes in the Stereotype and not use the taggedValue connector. If you need a large number of same-type tags, this might be preferable from the visual perspective.

The ordering of tags, though, cannot be enforced AFAIK.

However, since you say the tags must be ordered I'm assuming you'll be wanting to generate code out of this (since ordering of attributes within a class carries no meaning in UML).
And in your code generation template, you are free to do things in any order you like.

Hope this helps,


Hi John,

Could be a JavaScript issue possibly?
The generated HTML contains a truckload of JavaScript.


Automation Interface, Add-Ins and Tools / Re: User or model default diagram
« on: November 28, 2015, 02:07:47 am »

Well, It Depends[size=8]TM[/size].

Repository.ConnectionString can contain a file path, and that file may be a shortcut file, which is a text file with an .EAP extension (check the size, if it's less than 100 KB it's a shortcut).
That file may contain an OpenActions:$diagram://{GUID} clause, which would be one way of specifying a default diagram.



Automation Interface, Add-Ins and Tools / Re: Element marker in tree view
« on: November 25, 2015, 08:24:08 pm »
P.S. I even have added the _icon attribute
There's your problem.

This particular special attribute must not have the underscore prefix. It must be named "icon", not "_icon".

Its value is the file path to the icon file, Windows-style, plain text, no double backslashes or anything like that.
And it goes on the «stereotype» class, not the «metaclass» class.


Automation Interface, Add-Ins and Tools / Re: Element marker in tree view
« on: November 25, 2015, 03:52:24 am »
The closest thing you could do is create your own stereotypes in a UML profile, and link an icon to the stereotype.
This icon will then be used both in the project browser as in the toolbox.

The icon can be shown in toolboxes, but it does not appear in the project browser. How can that be managed?

Oh dear - didn't you just release a book on how to write MDG Technologies?  ;D

Anyway, I can't recall having done this with packages, but it certainly works with elements. Check the help page Extending UML Models -- MDG Technology SDK -- MDG Technologies - Creating -- Create Toolbox Profiles -- Assign Icons To Toolbox Items.

If you extend the «metaclass» ToolboxItemImage, only the toolbox icon is affected. But if you use an "icon" attribute, both the toolbox and the project browser icons are affected.

BUT all that gives you is a different, but fixed, icon. There is no way to create an overlay of the type EA can place on packages.

Back to the OP, you can add an image to a shape script, and you can set a toolbox / project browser icon.

You could set different images in a shape script depending on some condition the script can evaluate (eg the element's status), which would give you a kind of overlay-type function, but that will only work in diagrams because the icon is fixed and not part of the shape script.



You could use an add-in to get the information. Of course this is by far more effort.
Also quite drastically inefficient. There's (apparently) no caching so think twice before you use an AddIn-backed shape script if you will be placing large numbers of elements in a single diagram and accessing the repository over a LAN.

But if the shape you're drawing is essentially the same as the non-stereotyped one but with some minor alterations, like border colour based on status or a decoration based on phase or something like that, you might be able to use drawnativeshape() or drawparentshape().


The advantage of using MDG is that it relates diagram and toolbox (which really makes a lot of sense). Throwing that away seems to be a bit silly.

I'm actually thinking along an enhancement of smitasam's idea...

One technology that defines the stereotypes and other generic objects.
Then in folders below the base, each role has an MDG that uses the base MDG to define the toolboxes.  

Since the diagram specification  in the base MDG defines the name of the toolbox to be activated, then each role based MDG defines that toolbox!  Since you shouldn't be loading more than the base and 1 role at a time, we can get away with it...  (I think).  Haven't tried it out yet, but I think it should work.  Anyone see why it won't?
No, I'm pretty sure it will. For additional safety, you could set them up in different directories and get the different roles to configure their EA client accordingly. But that's a bit of the old ding dong, tweet-tweet.


I seem to be able to cross-reference MDGs (for example, MDG2 uses a stereotype definition from MDG1 and can place it on its Toolbox, also it can use it in its (MDG2) QuickLinker.  Is that by design or EAUI in our favour?  It seems to be very useful and I'd like to know if I can rely on it.
I'm pretty sure you're safe there.

It is perfectly possible to refer to profiles in other MDG Technologies from a toolbox, notably UML and SysML as exemplified in the help. The toolbox simply doesn't know or care which MDG Technology the profile resides in.

The references to element/connector types in toolboxes are on the form MyProfile::MyStereotype (the MDG Technology is not part of this identifier), and that's exactly how they're written to the MDG Technology XML file. (If you reference a pattern, that's referenced as MyMdgTech::MyPattern.)

In other words, they don't get resolved into whatever internal format EA uses during creation of the file. The resolution happens later, either when the MDG Technology is loaded, or even on demand each time the user opens the toolbox.

Which it is doesn't matter. The point is that this is clearly by design and not an accident: this is how MDG Technologies work.

I'm not entirely sure when it comes to quick linker definitions, since those are stored within a profile and the stereotypes are referenced without the MyProfile:: prefix. I can't recall setting up a quick linker that uses elements from different profiles, and the help doesn't list any such example. But again, if it works it's most likely intended to.



Or you could make available two different versions of the same technology (same technology name, same UML profile, same diagram profile, different toolbox profiles). Sounds like a maintenance nightmare (and it probably is), but really all you would need is two separate .MTS files which differ in contents by the name of the toolbox profile file to be included, and the folder to which the technology file gets written. Enterprise Architects will add one folder to their technology path; Solution Architects will add the other folder. As long as nobody adds both folders...
Actually, the files could be in the same folder - so long as they have different file names - couldn't they?.  The internals could be identical or different - where required as you indicate.

May not be such a problem since the changes can be limited to a small area.

The published technologies have to be in different folders because at startup EA will go to each folder in the technology path and load every technology in the folder. You need to avoid loading two different versions of the same technology.
Yes, but - although each MDG Technology EA discovers is enabled by default, you can disable them and EA will remember for future sessions -- right?

Either way, this approach makes it a deployment problem and there are ways around. If you repackage EA you can set (some of) your own registry values, and you can decide which MDG Technologies get installed to the EA program directory.

You should also note that EA warns the user (in the System Output window) if it detects the same profile in two different MDG Technologies, which in this case would be an excellent indicator that the setup is wrong.


[size=8]Grumble mumble my solution's still better mumble grunt.[/size]

Hi Paolo,

I don't think what you're after is possible without constructing an Add-In.

First off, let's straighten out a couple of things.

The link is from the diagram type to the toolbox -- not the other way around. Several diagram types can utilize the same toolbox, but a diagram type can only specify one toolbox. So your surmise in the OP is correct.

When EA opens a diagram, it checks the type and uses that to look up which toolbox to open. The type consists of two parts, the base type (UML diagrams, plus a few additional EA-specific ones) and the customized type [my term].

The customized type is on the form MyMdgTech::MyDiagramType -- in other words, two different MDG Technologies can contain diagram definitions with the same name without any conflict, since EA always uses the fully-qualified name internally.

The only thing you can use to control which toolbox gets opened is the diagram type. You can't get EA to sometimes open one toolbox and sometimes another for the same diagram type.

Pinning toolboxes means they remain for all diagram types. You'd have to get users of each role to pin their respective toolboxes -- and if the toolbox is intended for some analysis role, why should it stay open when they open a sequence diagram?

The Common toolbox is a very special beast which is outside the regular rules. If you overrode that (don't know that you can, but if) in different ways in two MDG Technologies, that might work -- but you'd have the same relevance problem, plus two different MDG Technologies to mainpain.

I simply don't think you can implement role-based anything in MDG Technologies; it's a dimension they just don't have.

Add-Ins to the rescue.

You can create a very simple Add-In which responds to the EA_OnPostOpenDiagram event by checking the diagram's type and the user's role (which you can ascertain from the API by combining Repository.GetCurrentLoginUser(), Repository.GetAuthor() and Repository.ProjectRoles), and then calling Repository.ActivateToolbox().

Unless you get really fancy, this solution means the (three-way) association between a role, a diagram type and a toolbox gets hard-coded. Or you could write it into the description field of the roles if you like, depending on how tightly you intend to lock down your environment (if anyone can change it, they will -- especially if they're architects).

Either way, this approach should work. Mind you, I haven't tested it and it does become a race between EA and you in terms of opening the toolbox. It's a matter of who gets in last.



Hi again,

The content that I had quoted is from the following document file distributed as part of EA12.0.1210 client program:

...\ProgramFilesX86\Sparx Systems\EA\Books\Automation\Scripting\Introduction to Scripts.rtf
Oh dear. Well I'd definitely call that plain wrong an over-simplification.

I explained the different storage locations in my answer to this SO question the other year. In brief, scripts can be used from the EA installation directory ("Local scripts"), from within the project itself, and from an MDG Technology.

In order to distribute scripts, you can use the Model Import/Export functions under the Project menu; importing a script this way will store it in the project, and if you want to make any changes you have to run the export/import cycle again.

An MDG Technology is an XML file, just like the result of a reference data export. The difference is that an MDG Technology can contain more than one type of thing, eg scripts, UML profiles, and document templates.

Using an MDG Technology, you can make your scripts available to the users regardless of which project they happen to be in, if they configure their EA clients to look for MDG Technologies in a shared directory. They only need to do this once. Subsequent updates requires them to restart EA (or deselect / reselect the MDG Technology, which is too complicated for some users).

It gets a little more complicated by the fact that an MDG Technology itself can also be imported to a project, or to a user's installation directory. Don't do that, use a shared directory instead.



Doesn't seem wrong to me.
If I write a script it is stored in the model and organised in groups no?
When you write it, yes. But not necessarily when you use it (could be in an MDG Technology). Plus, if you save a script from the editor it gets written to disk. So the statement is incomplete or, using a couple fewer letters, wrong. :)
And since this is a deployment issue, both the writing side and the using side are important.

You have a point with regards to the distribution, but a big downside is that from an MDG file you get all scripts in one single standard group.
So you can't use the scripts context menu's to execute scripts (unless there's a hidden passage way I haven't discovered yet)
No, I haven't found one either. But it wasn't clear from the OP that this was a requirement. Which is part of the reason I asked about the source of the incorrect information he or she has been working from: if there are more errors in that document, then clearing those up might help.



The document (Introduction to Scripts) states 'Scripts are stored with the model and are organized using Groups.'
Pardon me, but what document is this? Is it in the help file, a Sparx white paper, or something from a third party? I really do want to know, because that quote seems wrong to me.

The best way of distributing scripts is to package them into an MDG Technology. This is how Sparx does it with their EAScriptLib.

With an MDG Technology, the scripts are not bound to any particular project. They are stored in a file and can be used freely in any project.



Hallå igen,

I'm afraid you can't use VBScript for this, you have to write an Add-In.

An Add-In is compiled code, usually written in C#, which is deployed as a DLL and can receive event callbacks from the EA client. Regular scripts in EA can't. They can read and write models and other project data as available through the Object Model API, but only Add-Ins can receive calls from EA, and that's what you need for the EXEC_ADD_IN macro.

There's more details in the help file, check out the top pages under Automation and Scripting in particular. For an example of how to create a simple Add-In, you can look at Geert Bellekens' blog. It doesn't address issues around packaging and distribution so it's not much good for anything like team or enterprise situations, but it's an OK place to start.


Hej Rolf,

To my knowledge, not in out-of-the-box EA.

While you can create templates which refer to each other, the underlying infrastructure is out of reach and you can't make the generator do things in a different order, or in fact tell it to do much of anything: your code is called to transform bits of the model into text, but not to create files.

What you can do is create an Add-In and call that from one of your templates with the EXEC_ADD_IN macro. The method signature only includes the class and operation being processed, but from that you can look at the relationships the class has and create whatever files you wish from that.

Note that your Add-In will get called once for each class/operation combination, so you'll need to keep track of what you've done in previous calls or accept that your connector-based files will get repeatedly overwritten during code generation.

Hoppas detta hjälper,


Pages: 1 ... 70 71 [72] 73 74 ... 85