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 ... 409
1
+1

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.

Paolo

2
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?

Paolo

3
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.

Paolo

4
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.

Alain
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)

Paolo

5
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.

Paolo

6
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.

HTH,
Paolo

7
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.

Paolo

8
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.

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

Paolo

9
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?

Paolo

10
Alain,

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.

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

Paolo

11
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.

Geert
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).

Paolo

12
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.

Paolo

13
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?   :-\

Paolo

14
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)

Alain
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.

HTH,
Paolo


15
General Board / Re: Multiple elements (virtualised connector ends)
« on: June 01, 2018, 10:51:43 am »
[SNIP]
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 ... ?

Thanks
Matt
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

HTH,
Paolo

Pages: [1] 2 3 ... 409