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 - Geert Bellekens

Pages: 1 2 [3] 4 5 ... 566
31
If all else fails there's still the undocumented/unsupported backdoor Repository.Execute(SQL)

Geert

32
André,

I'm not saying you are wrong, but quickly renaming a set of requirements is much easier when you do "View as List"

Geert

33
General Board / Re: Auto creation of a composition with ArchiMate
« on: October 12, 2018, 07:49:24 pm »
In fact I'm not inclined to use the project browser nesting all to much, mostly for pragmatical reasons.

One of main reasons is version control and model security.

Version control only works on package level.
If I were to put all the business processes of my entire enterprise under one root process, all of them would be controlled in a single version control file.
That means that there would only be one person at a time who could work on the business processes.

Same story more or less with security.

Another reason to use explicit composition relations is that you also see them when you add two related elements on a diagram.
The project browser ownership/nesting relation is implicit and not visible on diagrams.
And it is all to easy to move an element up or down the tree by mistake. If you are using only te ownership/nesting relation you might not even know you changed something crucial to your model.

Geert

34
Hi Uwe,

I don't know if there is a standard, out of the box, solution, but there is no reason why it shouldn't work with scripting.
It's just a matter of figuring out exactly how EA stores all these elements and relations.

Geert

PS. Hooking up a profiler that records all SQL traffic to the model often helps in figuring out things like that.

35
So it seems like in a very distant past (v10?) the trace was a stereotypes dependency.
Then they seem to have introduced the Abstraction connector type and trace because a stereotyped Abstraction, just like the UML specs say.

It now going back to dependency when you don't have "Filter to Toolbox" checked then seems like a regression, where the v10 behavior somehow pops up again from beyond the grave.

Geert

36
Did some more testing.
[SNIP]

So I guess the bug is in the Filter to toolbox functionality

Geert
Actually, Geert, I think the problem is elsewhere.  You may find you have a «trace» relationship in the "Common" stereotype list.  Filter to Toolbox should exclude it (only the MDG version is selected), whereas unmarked Filter to Toolbox, doesn't - because the common one "kicks in" first.

That's why we purge ANY common stereotype that matches our MDG defined stereotypes in our overnight processing.

Paolo

Hmm, but in v12, where the Filter to toolbox doesn't exist I never have this problem.
Did they then change the default stereotype loading order?

Deleting the default trace stereotype from the common stereotypes list doesn't influence the behavior.

Geert

37
Did some more testing.
Disabled all add-ins and MDG's and actually removed the MDG's loaded in the model (apparently disabling them doesn't "really" disable them as I can still select the toolboxes from those MDG's. But that's a different issue)

Then tried it again using the quicklink and still a Dependency.
Then tried it with the trace connector from the common relationships toolbox and that creates an Abstraction ???

I'm using it on a class diagram from a class to another class and from a package to another package. Both Class as Package have the same results.

Then to be sure I created a new empty .eap file.
Disabled all but Basic UML2 technology MDG
Created a class diagram
Created a trace relationship using the quicklinker with "Filter to toolbox" checked => Abstraction
Created a trace relationship using the quicklinker with "Filter to toolbox" unchecked => Dependency

The same test (except that "Fitler to toolbox" doesn't exist) in v12.1.1230 results in Abstraction.

So I guess the bug is in the Filter to toolbox functionality

Geert

38
General Board / Re: Auto creation of a composition with ArchiMate
« on: October 11, 2018, 11:33:43 pm »
That is to the feature to link a "composite diagram" to an element -> drill-down.
Not related to composition relations.

Geert

39
General Board / Re: Auto creation of a composition with ArchiMate
« on: October 11, 2018, 11:20:03 pm »
No, it doesn't.
You'll have to write a little script or add-in if you want to do that.

Geert

40
When I create a «trace» relation in v12.1.1230 I get a connector of type Abstraction with stereotype «trace»
When I create the exact same «trace» relation in v14.1.1427 I get a connector of type Dependency with stereotype «trace»

WTF! >:(

Who?/Why?/What?

So now we are getting a nice mix of abstractions and dependencies in our models.
Not to mention the countless queries that are now broken, and a number of add-ins that depend on this relation being an Abstraction.

Was this an intentional change (I didn't see anything about it in the release notes) or a mistake?
In case of the latter I hope it gets rectified real soon.

Geert

PS. I'm not arguing Abstraction is better somehow than Dependency.

41
Automation Interface, Add-Ins and Tools / Re: Create MDG via script?
« on: October 10, 2018, 01:47:55 am »
What's even better with assembling the MDG from XMLs yourself is that you can look into the latter and detect whether they contain what they should (so is it a profile, for toolboxes, patterns, etc.). EA does not do that but blindly copies the files you pointed it to. I can't count how often I saved a profile at the wrong place (since EA does not remember the preferred place to save) which led to a just not working MDG ("go, figure" EA lets me stand in the rain) - well, until I did the assembly myself.

q.
Version 14.1 now remembers where you last save the package/diagram as a profile thus avoiding these common mistakes.
You see sometimes they listen to us  :)

Geert

42
General Board / Re: Status property of diagrams
« on: October 09, 2018, 08:38:08 pm »
Hi Jörg,

No, the Use Case is the entity that is relevant, and that use case can be shown on different diagrams.
The use case should have a status, not the diagram.

Even more so with activity diagrams. An Activity diagram should only exist nested under an Activity. It is the Activity (and it's status) that is relevant in your model, not the diagram.

Geert

43
General Board / Re: Status property of diagrams
« on: October 09, 2018, 07:42:57 pm »
Jörg,

You are maybe trying too much to depend on diagrams.
Diagrams are basically a view on your model, but they should not really be part of it.

So for things like statuses etc.. you should look for (or create) an element that represent the contents of your diagram and assign a status (and other properties) to that element.

Status colors are shown as a shadow on elements (more clearly on requirements) that are shown on diagram.
They don't color the diagram itself.

Geert

44
Automation Interface, Add-Ins and Tools / Re: Create MDG via script?
« on: October 09, 2018, 07:38:40 pm »
I don't think there is any support for it in the API, but it it is not rocket science either.
If you wanted to do it yourself you would basically need to put the different sources into a big XML file.

Geert

45
General Board / Re: Status property of diagrams
« on: October 09, 2018, 05:20:15 pm »
Because no fields have been added to the db schema since at least 2004. (Version 4.0 of EA was the last one that required a database upgrade. Even then I don't think that upgrade was significant.)
To be fair, that hasn't stopped you from adding all kinds of fields and information to the model before. Think key-value pair columns like StyleEx, xml strings in columns, t_xref...
So I'm sure if you really wanted to you could add a status field to diagrams without changing the database structure.

Geert

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