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 ... 5 6 [7] 8 9 ... 415
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?   :-\


I know this is a weird situation but...

If an MDG XYZ is stored in a repository
and an AddIn is installed that loads the same MDG (or another version of it)

then  the MDG that is activated is the one from AddIn (as expected)
and the quicklinks defined in the MDG loaded from the AddIn are ignored (BUG)

Hi Alain,

Because we dynamically slipstream (local) development MDGs during our (currently) manual development process, we are familiar with the issue.

I believe it is because QuickLinker files are only loaded on program initialisation.  This isn't a big problem for us as it takes 10-15 mins to regenerate our QuickLinker file from our source specification matrix, so exiting and reentering EA isn't so much an issue.

Perhaps a Sparxian can confirm if the QuickLinker is only read once.


General Board / Re: Multiple elements (virtualised connector ends)
« on: June 01, 2018, 10:51:43 am »
Write a little script to pop them on...

I was kind of hoping to just use a commercial product to do Archimate modelling without having to get under the covers and code, and I suspect that path leads to an ever growing eco-system of self coded 'enhancements' and work-arounds (you seem to have invested quite some time in doing that ...)
Having said that, is there somewhere you can point me for an example of the sort of script you're talking about to give e a head start ... ?

As it happens, in this case, I can't (I only know it can be done because our diagrammer had a bug where it created them accidentally).  But the Standard scripts or Geert's excellent script repository will help.

The key concepts you need are:
  • Select the object on the diagram
  • Run the script:
  • Find the diagram object in the diagram objects collection of the current diagram
  • Create a new diagram object, copying the data from the existing object, but change the location by adjusting the x&Y coordinates
  • Udate the diagramobject
  • Refresh the diagram objects collection
  • I think that should do it or at least get you started


Sounds like you're being offered the Eric Morcombe Gambit - "Get out of that without moving" or even the infamous Catch-22.

You need to share files, but you can't (not allowed to?) share files?

Since you're not allowed to create a shared folder, I assume you can't link them either.  SneakerNet sounds like the only option.  But then you ARE sharing files, so why inhibit you in the first place?

But, as Sunshine says, your collaboration needs to be well orchestrated (ArchiMate based pun intended).


General Board / Re: Multiple elements (virtualised connector ends)
« on: May 31, 2018, 04:42:40 pm »
Hi Matthew,

AFAIK, most of my issues have not been fixed.

If you want a model, then Visio won't give it to you.  It will just give you diagrams. (but, I'm sure you know that).

You can only have one Virtualised Connector End per connector on a diagram (hence your comment about only one "duplicate").

If you are intending to use Visual Embedding for your diagram and you DON'T intend to show ANY relationships then there's a possible solution - thanks to EAUI!  While through the manual UI, you can't add more than one diagram object for each element on the diagram, you CAN (or, at least you could) with automation.  Consequently, you are seeing multiple views of the same thing!

Write a little script to pop them on...


Hi All,

Thanks for the responses! I can confirm that using Visio diagram elements from actual templates and stencils makes the import much more useful. Visio "User" elements come in as <<user>> stereotypes, Server nodes as <<node>> types, etc. so there is some promise. It's not perfect, but certainly better than having everything import as <<rectangle>>, <<circle>>, etc.

So now that the technical problem is somewhat taken care of, we'll need to start working on the social problem i.e. either use Visio to create meaningful diagrams, or use EA, and if you 'just want something quick' then use the Whiteboard/Hand-Drawn mode for those drawings.

Thanks again!
One approach to the social problem is to determine if the users are trying to create models or just pictures or drawings.  Often, we find they are just trying to draw pictures - i.e modelling is NOT their "day job" and the overhead gets in the way of getting the work package completed.  Consequently, Sparx appears to have TOO much friction.  If they are trying to draw pictures instead of creating models, you need to work on that.  Forget EA for a minute, just work on the implication of a model versus a picture (pixels) or even a drawing (as in Visio).
If they are really trying to create models, then you need to explain why a Visio diagram is NOT a model.  THEN, you need to work on reducing the friction to them creating models in Sparx.
That's why we emphasise creating a good user experience with EA.

As an example, our integration group used to create integration diagrams in Visio and for years we couldn't wean them off.  Then a new Integration Architect Lead came on board who understood the value to him and his team of true models.  We worked with him and the group to create a sub-MDG to handle the Integration Aspect - the kinds of objects one finds in the various Enterprise Service Bus technologies.  New elements and connectors.  Now they are enthusiastic users of EA (and our poster children on why you should switch to a modelling approach).

However, this is an example of one of my aphorisms: "If they're not buying, you can't sell".  (until the new Lead came on board, we couldn't mount a good enough argument)  You need to seize your moment carefully.


Pages: 1 ... 5 6 [7] 8 9 ... 415