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 ... 3 4 [5] 6 7 ... 431

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

General Board / Re: SQL command - Tag Value
« on: September 03, 2018, 09:19:54 am »
You need to use is null in conjunction with the left join.

Automation Interface, Add-Ins and Tools / Re: Uml to typescript
« on: August 30, 2018, 10:10:39 am »
I don't know much about typescript, but usually the time is more in learning how to use the grammar and code templates.

Generally I'd estimate 1-2 days for 90%+ coverage in code templates. For a grammar I'd say 1-2 weeks for 90%+ coverage, although that varies a lot more depending on what kind of language documentation exists and how much of the syntax can legally appear at the file/class level vs inside operations only.

Suggestions and Requests / Re: Current user's name (about the display)
« on: August 30, 2018, 09:58:22 am »
It's displayed in the top right of the EA window in EA 14.1

General Board / Re: Protobuf .proto generation from a class diagram
« on: August 28, 2018, 09:23:34 am »
Looks equivalent to xsd, json schemas etc. You could generate it using code generation templates. I'd also consider the API for the schema composer.

Like Geert, I'm not aware that anything already exists.

BPMN2.0::Activity (UML::Activity) --> so UML::Activity is the base-type - this sounds logical
Actually, action would be the closest mapping to UML. A Process should be mapped to Activity.

BPMN2.0::Pool (UML::ActivityPartition) --> UML::ActivityPartition - but WHY??
Probably because it had the closest appearance.

Those mappings come from when EA was less flexible with profile customization than it is now. But they aren't as important when implementing a profile to represent a completely different metamodel.

How can I generally extract the base-UML-types for any Element? Is there a SQL solution?

The only trick is that the EA search window will helpfully show you the metatype that comes from the stereotype. If you want the base type you need to go around it.
Code: [Select]
select Object_Type as Real_Type from t_object where <condition>

Unfortunately, this is a Windows issue.

If you want to know the details... EA declares itself as single DPI aware. What that means is that EA is only expected to handle a single DPI scaling for a session. It is Windows responsibility to scale any API functions that involve window/screen dimensions when they apply to a monitor with different scaling from the default.

Unfortunately, there appears to be some situations where Microsoft didn't get that right. One is the rendering of the non-client area (outside edge) of windows on secondary monitors. This impacts the visual styles that draw a colored glow around a dialog or floating window. Other times the windows themselves don't get scaled correctly. Unfortunately, EA itself can't detect that you are using multiple resolutions. Windows tries to protect it from the information that it declared it can't handle, so the results of the APIs to detect that kind of thing are fabrications.

The only other option is for EA to declare itself as fully DPI aware. But the impact of that is that we need to rescale everything dynamically as you move windows around etc. For now that's not feasible, so we're left with the behavior you have seen.

Bugs and Issues / Re: Notes for class attributes
« on: August 20, 2018, 10:34:59 am »
Jules, my comment wasn't intended to be offensive in any way.

I acknowledge that the attribute list, attribute properties and attribute notes were previously all in the one dialog. EA 14 is a little different, you can edit the properties and notes for attributes in the same windows that you can edit the properties and notes for anything.  So, you can select an attribute in the project browser, diagram or the attribute list and edit it in the same place you would edit a class. You'll also get a number of extended dialogs depending on the type. That unification of where to look was the intended improvement.

Having said all of that, as discussed already in this thread, version 14.1 offers an option to access the old dialog. So there's your alternative.

Bugs and Issues / Re: Notes for class attributes
« on: August 15, 2018, 12:08:24 pm »
What's missing is an option.

Start | View | Visual style | Prefer Property Dialogs

General Board / Re: Aggregates connector is shown the wrong way around
« on: August 15, 2018, 09:21:41 am »
Fortunately there used to be a flag in the preferences (Pref's -> Links -> Association default - source --> target) that allowed to swap (i.e. correct) that behavior.
That flag is still there but in the v13.0 and also 13.5 this flag has apparently no effect, i.e. that connector is shown the wrong way round, regardless of whether that flag is checked or not.
The option changed the drawing direction, but EA still placed the aggregation at the same end. It has less effect these days because the quicklinker provides options to be explicit about the drawing direction. If you drag an aggregation from the toolbox it still uses that option.

Bugs and Issues / Re: v14 long lasting bugs
« on: August 14, 2018, 10:05:59 am »
Yes, it is, but for v14. It doesn't work for v14.1 beta
In EA 14, open the about dialog. It tells you when your activation code is valid until. I'm guessing it has expired.

Pages: 1 ... 3 4 [5] 6 7 ... 431