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 5 ... 434
General Board / Re: Aggregates connector is shown the wrong way around
« on: November 12, 2018, 03:22:33 pm »
The option you are talking about is:
Start | View | Preferences | Links | Draw Aggregations Reversed.

This option is still used when dragging an aggregation or composition from the toolbox.

That option doesn't have any effect when using the quicklinker because that generally shows 'to whole' or 'to part' in the menu.

Regardless of which option you pick or how you create it, the source end of the aggregation has/will always be the the part unless you explicitly swap it via the UI.

From a UML perspective, associations don't have a source and target. They have two1 equal ends.

The real question, is why is this causing you a problem? Perhaps we can solve that problem.

1 When aggregation is set it's limited to two, with only one specifying aggregation. Otherwise it's two or more.

Matthew, it's a little more complicated than that.

In addition to the metamodel, there is a textual description of how derived relationships work. This is where the "ambiguous" comes in to my comments. However, even taking that into account there are some connectors allowed by the table that I can't see how they fit into the metamodel. EA currently doesn't have those derived relationships added. Most issues reported come down to that.

There's also a comment somewhere about something not happening between layers. Going from memory here, so I don't have the specifics. But the effect of that comment is excluding relationships in the table that the metamodel would otherwise allow.

EA 14.1 uses a metamodel approach to build quicklinkers for UML, UAF, ArchiMate and user technologies if they choose. It works well when the metamodel is well defined. Unfortunately, it doesn't necessarily meet user expectations when the specification writers have ignored the metamodel and defined a table showing what the available relationships are.

General Board / Re: Shape script control by external switch
« on: November 12, 2018, 11:31:59 am »
If you're wanting to change that notation for all elements on the diagram, I would be creating customized diagram types, then checking diagram.mdgtype within your shape scripts. This means the modeler has the choice of whether the extra notation is shown or not.

From what I can see, the dictionaries are located in the registered users section. When you purchase EA you will receive a username and password that will allow access to that section for a year.

General Board / Re: Unapply profile in XMI export
« on: November 12, 2018, 09:34:13 am »
I'd look at running an XSLT transform on the exported XMI. There's built-in support to do that, to the extent that you can use it as a new export format.

Archimate 3 MDG seems to be broken in build 1427.

In my opinion, it's the ArchiMate 3 specification that's broken. It's self-contradictory and ambiguous.

EA has implemented the relationships as defined the the metamodel described by the specification. We are aware that it's different than the appendix, which attempts to provide an interpreted view of that metamodel.

PCS General Board / Re: André
« on: November 12, 2018, 09:24:00 am »
I'm not aware of any existing translations of WebEA (or Prolaborate) into Portugese.

However, my understanding is that the English strings used for display in the UI are all declared in a single PHP file to allow for translation. (Sorry, I don't know exactly where that is)

Profile Metatype (bad) Component, (good) ArchiMate3::ArchiMate_ApplicationComponent.

This sounds like when you exported, the definition was type, now it's profile metatype. Changing it back to Type may get you going.

Bugs and Issues / Re: Can't order Responsibilities
« on: November 05, 2018, 11:20:16 am »
Element Responsibilities (aka - Internal Requirements) can't be ordered.  The ONLY order available is alphabetic.

Please rectify.

Every collection in EA should be able to be ordered.
While I appreciate what you are saying that "every" collection could have an order applied, there are other factors at play here.

UML itself has several "unordered" collections. My interpretation of this is that there is no meaning in the order, and it can be validly be presented in any order.

For an EA specific issue, there's nowhere for EA to store a user specified order on these. That alone means you're probably better off adapting.

Yes that is correct for the current version.

General Board / Re: Change of stereotype to "Functional"
« on: October 29, 2018, 04:15:17 pm »
This isn't a new issue. I've seen it reported/discussed/etc many times over the years. But in my opinion it's not wrong.

I would say that EA's implementation of a Requirement is that it has a 1..* relationship to Requirement Type.

As a result, any requirement without a requirement type is incomplete. There are many ways to manage this, and none of them are going to satisfy everyone.

The dialog automatically fills the type during load to ensure it is complete. The user then presses 'save' which writes the value being displayed.

I would personally recommend that Ian accepts that the requirement will have a stereotype. (from the 1..*) relationship above and use it how it's intended to be used.

Regarding your personal issues. If I've searched our system correctly I can see a mix of issues that have been confirmed but not yet fixed, fixed or considered not a bug. (Including at least one "bug report" for behavior that if changed would break existing diagrams for every ArchiMate user)

General Board / Re: Change of stereotype to "Functional"
« on: October 29, 2018, 10:26:43 am »
"Oh that feature doesn't really work and doesn't appear to be getting fixed anytime soon, here are some ideas on how you can build your own solution instead"

It works, but there are always differing views on how people would like it to work. There are also people here that seem to enjoy complaining.

The 'Type' field for any requirement like type is implemented using stereotypes. They are most useful when used with a profile that provides additional fields for each type. But there is also a model wide list of requirement types that act like a simple profile for those that don't want to build a profile (or use a built-in one like SysML)

The idea is that without a type, a requirement is like an abstract metaclass.

General Board / Re: Meta-Constraints
« on: October 29, 2018, 10:10:00 am »
Not to EA.

It may make a difference to you if you want to be strict when describing your profile. From a technical view, not all metaclasses have the same umlRoles.

client/supplier would be for dependency types
source/target would be for directed relationship types
end[0].role/end[1].role would be for associations
informationSource/informationTarget would be for information flow.

General Board / Re: Hide stereotype on Information Items Conveyed
« on: October 26, 2018, 11:43:25 am »
SysML is a language of it's own and EA just mimics it with a profile.
Actually, the current version of SysML is defined as a UML profile. SysML 2, which is still in very early stages is expected to be defined as both a metamodel and profile.

Code: [Select]
[ 16.5,11.5 ] x 96 = [ 1584,1123 ]Although those page sizes are only accurate to one decimal place.

ISO 216 which defines those sizes was updated in 2007, so you could be right. But I expect the page size didn't change.

Pages: 1 2 [3] 4 5 ... 434