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 - Simon M

Pages: 1 [2] 3 4 ... 429
General Board / Re: Named default value constraints
« on: September 17, 2018, 09:18:17 am »
Looks similar to the primary keys and uniqueness constraints etc that are modeled using a separate stereotyped operation.

General Board / Re: Create read-only tag in an UML profile
« on: September 17, 2018, 09:16:18 am »
Predefined Structured Types
Code: [Select]
Used to: Create a read-only constant value.

To include this in a profile, see With Predefined Tag Types.

According to, BABOK is included in Corporate.

(qwerty, it won't be in yours because it was added in v14 and you refuse to update)

No, you can't change the metatypes in a profile.

My only recommendation is to use a template package.

I was talking about the impact such a change would have on the existing tagged values for elements with those stereotypes already applied. You can probably correct that by running a synchronize stereotype though.

General Board / Re: Custom element label in EA with ArchiMate
« on: September 12, 2018, 08:58:01 am »
On a basic shape it looks something like this. (Note, the bold text for a subshape is EA 14.1 only)

Code: [Select]
shape main


shape name
shape body

General Board / Re: Automatically maintain users from AD group
« on: September 11, 2018, 05:38:10 pm »

The bottom two options are what you want. At login it manages group membership etc. I believe there is still local user and group entries required, but it will no longer be used for login.

I'm not sure how it handles deleted users. They should no longer have access to the model, but there may still be a user entry.

Your data modeler deserves a kick in the butt if that is really the reason he refuses to use EA.
That was more or less what I wanted to say. I could understand someone saying they think a tool is too hard to use or doesn't do everything they think it should. But if you're told to use a particular tool anyway, you find a way to make it work. (And that applies even if you're being directed away from Enterprise Architect)

There is a (fairly) new set of events related to editing tagged values:

Unfortunately, they are only relevant for AddinBroadcast tagged values.

But you could use them to force tagged value edits to go through your addin.

Bugs and Issues / Re: Use of @Element in QuickLinker
« on: September 11, 2018, 01:19:42 pm »
As I said, @Element in the source won't work for implementation reasons, not necessarily conceptual ones. EA needs the source type to be a concrete term.

The metamodel method for specifying relationships does allow it, but it works by expanding the three metatypes involved before feeding information to the quicklinker.


My users are doing modelling Archimate Business Processes and linking them to Archimate Business Objects. The use
- Business Process
- Business Object
- Flow
- Some of my own Stereotypes extending standard Archimate elements.

They don't need any of the other Archimate element/connector types, and I don't even want them to.

Sounds like exactly what the view definitions are for. See Custom Metamodel Diagram View

  • Create a "view specification" in a new profile.
Create an "Extension" connector to one or more ArchiMate diagram types. As described in that link, open the desired diagram and enter the following into a Javascript scripting console to get the fully qualified name: ?GetCurrentDiagram().MetaType
Add "Exposes" connectors to the types you want to display. Use the metaclass item in the toolbox to select the profile items you want included. (Quick way to create abstract stereotypes with the fully qualified names needed)
Include this profile in your technology in the UML profiles section[/li]

Users can then select this view under the the diagram types extended in the second step. The result is that the toolbox and quicklinker are filtered to the types you specified. You can also optionally filter the diagram to those types even if something else was added for any reason.

No no, it is not to move the tag from one element to another but from one stereotype to another stereotype. And both stereotypes are present on all the tables in the model. So the tag will stay on all the tables too.
Each tagged value that comes from a profile is uniquely identified, including the stereotype that it comes from. If you move the tagged value definition to the supertype of its current stereotype that will still change. The result is that any existing tags will no longer match the definition, they will then appear to be not from any profile because they don't match any available tag definition.

Bugs and Issues / Re: Use of @Element in QuickLinker
« on: September 11, 2018, 09:14:53 am »
I'd say the reasons why it doesn't work are implementation rather than a conceptual it shouldn't. Both the connector type and source element type need to be concrete metaclasses.

You can define a relationship like this using the metamodel functionality in EA 14.  (Define Metamodel Constraints)

Suggestions and Requests / Re: Need: Category (Tagged Value Type)
« on: September 05, 2018, 01:18:26 pm »
My point was that multi-select tagged value types aren't a good idea. Shape scripts were just an example of how they are unsuitable.

I would recommend anyone implementing a profile away from RefGUIDList for the same reason. You can't reliably/easily determine the reverse relationship when it's a list. You can see an example of that in the traceability window. It offers the ability to show tagged value references, but it can't do that for a RefGUIDList. The performance would be an absolute killer on any non-trivial database.

Your category tagged value would suffer the same problems if you wanted to use it to drive reporting or similar.

Out of curiosity, is there a reason you are encoding a static list of categories into your categorisation instead of modeling them? These days I almost always prefer to define something in the model where possible so that it's self-documenting and easily extensible.

Suggestions and Requests / Re: Need: Category (Tagged Value Type)
« on: September 05, 2018, 09:09:23 am »
I would strongly recommend using multiple enum tagged values instead.

ie. Each one is a single value in a 0..* list.

In general it's more flexible and powerful. Even if we do need to add improved capabilities to query for multiple values in places.

As an example, I know you use shape scripts. At a guess, you're probably wanting this so a shape script can print out multiple values. But it actually means that you can't decide to convert that into decorations or similar in the future.

Using multiple tags, it would by possible to update HasTag to query on multiple values. (If it doesn't already) There's also no reason why we can't extend the syntax to get the list of values in a print (optionally specifying a separator)

Something like this:
Code: [Select]
shape main

decoration Val1
decoration Val2
decoration Val3

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