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 [2] 3 4 ... 73
Uml Process / Re: Action pins and instances of artifacts
« on: December 11, 2017, 08:53:49 pm »
I've heard back from the support team, and yes it is a bug and yes it will be addressed in a future release.

The current release at the time of writing is 13.5.1351.


Automation Interface, Add-Ins and Tools / Doc template: generalization set
« on: December 08, 2017, 10:36:57 pm »
Hey all,

I can't find anything that looks like a generalization set field in the connector section of an RTF template.
Is it available somewhere, or do I need to write a fragment?


Automation Interface, Add-Ins and Tools / Re: MDG - change diagram icon
« on: December 07, 2017, 11:23:36 pm »
Yes, exactly.

As to other characteristics, well there are three basic types of diagram in terms of behaviour: "normal", sequence and timing. This type is not represented in any way as far as I know, it's just there. I assume that's inherited.

Other than that, most diagram characteristics can be specified with the styleex, pdata and other attributes.


General Board / Re: Project MDG Technology options storage
« on: December 07, 2017, 11:14:26 pm »
Ah, genopt. Of course. Silly me.  ;D



Automation Interface, Add-Ins and Tools / Re: MDG - change diagram icon
« on: December 07, 2017, 03:09:53 am »

The icon is not configurable. Instead, extend the diagram type that has the icon you want.


General Board / Project MDG Technology options storage
« on: December 07, 2017, 02:57:08 am »
Hi all,

Anyone know where the project set of required / disabled MDG Technologies is stored?
Can't find an obvious candidate table.


General Board / Audit: document generation
« on: December 06, 2017, 02:43:58 am »
Hey all,

Auditing can audit XMI import/export. Can it also audit document generation? Who, what, when?
No, right?


qwerty's point is that the element structure is complex, and the API does not have a Clone() feature. The simple workaround is to create a temp package and clone that, as Q suggested.


I could use the diagram stereotype to show different tagged values. This shape script will go into a mdg profile later, so it may be better to use Type or MdgType.

If you use Type or MdgType, you can create custom diagram types which are preconfigured to show/hide relevant sets of tags. Downside with that is you have to change diagram type in order to change what's shown in it. If instead you use the diagram stereotype, you can change it on the fly, but you can't create a custom diagram type that only shows a specific subset of tags. So that's a question of how you prefer to work.

Either way though, changing diagram type or stereotype constitutes a modification of the diagram which may require you to unlock it etc.

Right now I am trying to find out the best way to do this. We can still change the way we work. Is custom compartments a better way?

With this approach, you move the different specialized sets of tags to different elements (either child elements or other elements connected to the core element), then select custom compartments in each diagram. You can also create linked notes which show custom compartments. Custom compartments are a bit wonky at least in version 11, and IIRC you have to select custom compartments individually for each element. So it's all down to how you want to work.


Is there another (better) way to do this?

In brief: don't.

Do not allow a metamodel where one element type represents different aspects of some concept. You will end up tearing your hair out.
I know you won't listen to that -- no one ever does -- but just for the record.

I'm with qwerty on this one, it's better to use some property of the diagram, rather than the element, to determine which tagged values you show. I'd suggest the .Type or .MdgType rather than the .Stereotype because the diagram stereotype can only be set manually and is not really a true property of the diagram, but it depends on how you set up your diagrams.

If you hadn't bunched all the unrelated tags into the same element, you could have used custom compartments with ChildElement or RelatedElement sub-scripts.


Uml Process / Re: Tagged values
« on: December 01, 2017, 10:28:07 pm »
I was pointed to this by a recent question in StackOverflow: tagged values do no longer exist in the UML 2.5 specs. The only real mention is on p. 205
When a Stereotype is applied to a model element, the values of the Properties have traditionally been referred to as tagged values.
That's it!

Now, what would that mean to EA? A concept that is used vastly in MDG does basically not exist in UML. How does that fit?

Well, they're actually mentioned in 19.2.3 as well. But that's neither here nor there.

The point is that the term "tagged value" may be considered obsolete, but the concept is most definitely not. It actually says as much at the beginning of same paragraph.

Quote from: UML 2.5,
Just like a Class, a Stereotype may have Properties, which have traditionally been referred to as Tag Definitions. When a Stereotype is applied to a model element, the values of the Properties have traditionally been referred to as tagged values.

Stereotypes may have properties. Says so right there. The rest is just a clarification that what this version of the specification refers to as properties and property values, is what has traditionally been referred to as tag definitions and tagged values, respectively.

So no. Tagged values have not been removed from the standard. They're referred to as property values, and function the same as before.


Suggestions and Requests / Re: Relationship between/to Attributes
« on: December 01, 2017, 07:58:48 pm »
Hi Tom, and welcome to the forum.

Am I expecting too much?

In brief: yes.

This isn't an EA issue, but the way UML works: Attributes Do Not Have Relationships.

EA has a function called "link to element feature," with which you can fake connections to attributes and operations (which is what qwerty's talking about and something you've already tried). However, this is mainly visual. Crucially, these fake (well, semi-fake) attribute connections are not available to other core functions like basic document generation or relationship matrices: these functions only see relationships between elements (classes, components, etc).

That said, the semi-fake links are stored in the database (every EA project is a database, even an .EAP file) and it is quite possible for a skilled document template wizard to create an advanced template which pulls that information out of there. But in order to get that done, the wizard would need a complete understanding of what else you want in your document -- a requirement spec, in other words.

I don't think you could get attribute links to work in a relationship matrix. With document templates, it's possible to use "template fragments" which can query the database directly, but that option is not available to relationship matrices.



Actually, I just notice that it does indeed work if I create a toolbox-item for MyAttribute and from there drop a MyAttribute on a MyElement which confirms my suspicion above. So I guess my question now is, how do i get MyElement to always define attributes as MyAttribute no matter which way of adding attributes to an element I'm using?

The only way to do that is with an Add-In, which sets the stereotype and adds the tags when the attribute is created.


Hej Mats,

Not with a regular XMI export. If you've got the Reusable Asset Service set up, its upload function checks for dependencies and prompts you to include them. Main selling point of that service right there.

I think an XMI import includes references (GUID) to out-of-scope elements, so that they can be resolved if the referenced elements are present in the target project, but I think the import ignores those that cannot be resolved. I may be wrong on this.




Using the enumeration type approach, you can of course reuse the same enumeration as a tagged value type for both class stereotypes and attribute stereotypes.

In general, it doesn't quite make sense to inherit tagged values from an element to its attributes. UML inheritance doesn't work that way. You should note, however, that if you create a stereotyped class with a set of tagged values and (in another class) add attributes whose types are that class, then the class' tagged values are inherited to the attributes and can be overridden if you wish. The attributes need not themselves be stereotyped for this mechanism to work.


Pages: 1 [2] 3 4 ... 73