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 - Paolo F Cantoni

Pages: 1 2 [3] 4 5 ... 411
We have a number of relationships defined in our QuickLinker between relationship metatypes and various element metatypes.  Under v13.5 the Quicklinker displays them as appropriate.  Under v14 with the SAME MDG file, they are missing.



There are XPDL to BPMN translation tools, you can then import the BPMN. See (tip, select 'translate')

Or you can pay someone for a full translation service, see:


So I got a .bpmn file (via the BPI) but it looks as if I'm NO closer to importing a .xpdl export from ProMapp.  Has anyone done it?


[Edit: IGNORE this post (except as how to NOT fall into the "trap for young players")!  I'd accidentally disabled the BPMN 2.0 MDGs and so, naturally, didn't have the BPMN 2.0 import menu item in the Publish | Technologies | Import menu".  THe .bpmn file imported without issue.  I'll put it down to a "slip of the mind!]

Suggestions and Requests / Re: Package Indicator for Here Be Locks
« on: June 18, 2018, 10:18:49 am »

Even with resetting the locking of items within the entire repository every night to ensure correct locking by package, EA occasionally ends up in an anomalous lock.  SO being able to see any lower level anomalies reflected up the tree would be useful.


Bugs and Issues / Re: EA14: Archimate shapescript / rendering issues
« on: June 14, 2018, 03:29:18 pm »
In build 1422

"ArchiMate 3

    - Quicklink behavior updated to set aggregation kind for Aggregation and Composition connectors
    - Connector validation rules updated:
        Specialization, Aggregation and Composition connectors now validate correctly
        Flow and Triggering connectors no longer report as not UML compliant"
I've been about to report a bug related to Aggregation Kind and the QuickLinker, but when I saw this I thought the bug might have been fixed.
We have our own MDG that has Aggregation and Composition relationships.  If the user drags the relationship between the two shapes and selects the appropriate relationship type, the aggregation kind is set correctly (because our MDG specifies it correctly).   However, if the user then uses the [F3] functionality, the Aggregation Kind is NOT correctly set and consequently, it can't match to the MDG and creates a spurious <MDG>::<Stereotype> entry in the local Stereotypes list.  Causing all manner of havoc.

Can anyone confirm before I submit a bug report?


I believe it's basically a standardization of our profile.
Hi Simon,

Can you clarify that?  In b1421 of the ArchiMate3.xml MDG file, ArchiMate_BusinessPRocess is  <Apply type="Activity"> which implies it extends "Activity", not "Class" as shown in Table 7-4. Business Layer Behavior Concepts of the ARCH document.


When a tag is added to a stereotype in an MDG using "Edit with profile helper", the features/attributes window does no synchronize properly
=> the new tag does not show in the list of attributes.

Hi Alain,

I think this is an example of a more general problem. I've also seen attributes not update correctly until you move focus.  This has changed since v13.  I think it was Uffe who asked that the WHOLE dialog be fixed.  The selection of portions of the edit boxes is abysmal and infuriating.  (Try double-clicking to select a word in the Attribute name field)


Hi Uffe,

We solved this problem by having multiple paths/environments (similar to the concept of Dev, Test, Prod)  MDG developers have paths that point to their local machine. Power users have one common path, general users have a different general path.

The MDG is "promoted" from one location to the other as testing/validation proceeds.

It's, perhaps, less than optimal. But we haven't found too many problems with this approach.  We've found enough problems with trying to switch MDG versions via the dialog that this is the easiest process.  The MDG is just slip-streamed into the appropriate folder and activated the next initialisation.


General Board / Re: Import Database Schema and Foreign Keys
« on: June 11, 2018, 12:37:36 pm »
I completely agree with what you have said. Unfortunately the system is quite old (10+ years) and those who created the physical tables, for some reason, decided not to define foreign keys.

We do not have the luxury of forward engineering the changes at this point. I was wondering if Sparx had something which prevents overwriting the relationships already defined in the model or add only those tables from the database that are new/modified.
Hi Raju,

We have a similar problem (and in this case, the third party software is pretty current).  From what we can see, there are over 2000 tables without a single Foreign Key Constraint!

Now to your question.  As Geert says, you are (by reverse engineering) creating a physical model.  Consequently, every time you reverse engineer, what you should end up with is a "copy" of the physical DB.  If you want to create things that DON'T exist in the physical model, then you either have to be able to forward engineer the changes to the physical DB (and thus make the reality the same as the updated model) or you have to change something other than the physical model - because otherwise you can't update the physical model.

About a decade ago, we came to the conclusion that there are TWO models at the physical level.  The Design Model (what we want to see in the DB) and the Implementation Model (what is actually in the DB).  The Design Model is only ever forward engineered and the Implementation Model is only ever reverse engineered.  The two models can (because they are at the same level of abstraction) can be compared and contrasted.

The process we generally use to create the Design Model (where there is only an implementation model), is to export the Implementation Model and re-import changing the GUIDs and tracing back to the implementation model. We can, therefore, make changes (such as you intend) to the design model and that's what we use in normal circumstances.

In any event, since (as I understand it) you can't change the physical DB, you aren't creating Foreign Key Constraints in the implementation model, but merely documenting dependencies between the columns in various tables.  You may "get away with" creating your relationships as Dependencies which might NOT be affected by reverse engineering.


Bugs and Issues / Re: Tag values mixing groups (ver 13.0)
« on: June 07, 2018, 09:44:59 am »
It worked! the solution is:
1) Apply the undesired stereotype by drag&dropping from the Toolbox pressing Ctrl over the conflicting element.
2) Uncheck the desired stereotype from the checkboxes in the Stereotype attribute of the element. At this point, the tag values are all grouped in the wrong stereotype group, but are all in the same group.
3) Apply the desired stereotype by drag&dropping from the Toolbox pressing Ctrl.
4) Uncheck the undesired stereotype from the checkboxes in the Stereotype of the element.
Hi Arquesoft,

I thought yu had already done that procedure...  What you have defined is the standard process for manually redefining a metatype.  If you don't do the steps of making sure you have cleared the StereotypeEx properties (where you unmark the checkbox of the non-current stereotype) then EA doesn't recognise the metatype correctly (Ask me how I know?  ;))

Anyway good to see you've solved it.

My issue, I now recognise is not the same as yours, is that the order of the Groups seems to vary between metatypes even though the same groups might be involved.  But I'll do more checking.


General Board / Re: Reusing a Use Case, generic or template?
« on: June 06, 2018, 11:33:50 am »
I only can recommend Bittner/Spence. Use case synthesis is a rather simple thing. But sometimes simple things are harder to understand than complex ones. IT people tend to analyze things and dissect them once they start with it. But UCs are just the other way around. I always see the same sort of questions (yes, I had them too in the beginning when working with UCs). The only remedy is to understand what UCs are good for. It's like teaching people Zen. So simple. So difficult.

Is that: Managing iterative software development projects / Kurt Bittner, Ian Spence?


Bugs and Issues / Re: Tag values mixing groups (ver 13.0)
« on: June 06, 2018, 11:31:30 am »
I've noticed something similar.  It may be just a lack of consistency enforcement (happened a few years ago, IIRC).

It is irritating.

However, it may just be Sparxian Consistency versus User Consistency. "It's consistency, Jim.  But not as we know it..."  ;)

BTW: Is it reproducible?  If you put the original stereotype back, does it revert and then revert again as you put the new stereotype back?



You can install both version 13 as version 14 on the same machine as long as you rename the EA directory in the program files.

Don't forget to setup the <User>\AppData\Roaming\Sparx Systems\EA folder with whatever you want to have 13 (such as Workspaces etc.)


General Board / Re: Reusing a Use Case, generic or template?
« on: June 05, 2018, 04:13:15 pm »
See in-line...
I can embed/inherit/include a use case in a use case? Or have I misunderstood you?

Embedding, inheriting and including use cases are three different things.  <<<=== YES!

- Embedding means you nest a use case under another use case (ownership). I don't really see the point in doing that.  <<<=== NO! Embedding is NOT Nesting! (but in both cases, there's not much point)
- Inheriting means you have a generalization relationship between use cases. (UseCaseA is a UseCaseB) Haven't seen much useful constructs like that as there is really a standard defines set of rules that determine how this generalization will manifest itself. (unlike in Class generalization where we know exactly what happens if you inherit from another class)

In general, I only use include, and only if I have a reasonable chunk of behavior that is shared between use cases.

In graphical terms Embedding means placing one object inside the shape of another.  Nesting is not a graphical term, but a structural one.  Embedding may imply nesting, but it need not (and in Archimate - notionally doesn't).


I usually take the approach teach them the modelling notation as I teach how to do various diagrams with various notations. Examples seem to be the best way to get them up the learning curve quickly. For enterprise architecture using archimate I start off with motivations then move through the various domains such as business, application, infrastructure etc. Each time introducing something new that Sparx EA can do.

I get people to start modelling and tell them not to worry about being correct.  Then I read their model back to them and get them to confirm whether what I read is what they intended to convey.  ArchiMate especially should break down into a series of statements, and be able to be read like a story.  Story telling is a fundamentally human activity and we train children to do it in schools so I find that people pick up how to improve their modelling this way.
A couple of times, in the past, I have automated the process of replaying (some parts of) the model back to the user.  But not since I started using Sparx EA.  It would be interesting to see what could be done.  As you say GB, it sure sorts out if your modelling is correct.


Bugs and Issues / Re: EA14: Archimate shapescript / rendering issues
« on: June 05, 2018, 10:43:47 am »
There are several rendering issues with he Archimate3 shapes in EA14 (many / most of which trace back through earlier EA versions and Archimate MDGs).  From what I can tell many people are accepting these or working around the (eg by creating their own shapes) - I can't find any mention of bugs or issues being explicitly raised in this forum.  However, given that Archimate is one of the major reasons why we are using EA I thought I would formalise the issues we are encountering.  I will raise a formal bug report for these also.

3rd worst shapescript in the product :-)
You DO mean that the Sparx ArchiMate 3 scripts are the 3rd Worst, yes?  What are the other two?   :-\


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