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

Pages: [1] 2 3 ... 13
General Board / Re: floating license expiration
« on: February 03, 2016, 02:19:14 am »
ok, ours is file based.
anybody here who has file based?

General Board / Re: floating license expiration
« on: February 02, 2016, 10:14:49 pm »
Are you using file based or service based Keystore?


General Board / Re: floating license expiration
« on: February 02, 2016, 01:43:50 am »

thank you.
But the scenario is as I describe

1. increase lease time to 5 days
2. checkout
=> expiration time is 1 day

General Board / floating license expiration
« on: February 01, 2016, 11:52:38 pm »

we set the Floating license expiration to 5 days.
When we look at the checked out licenses they are mentioned to expire in 1 day. ???

Is the second issue intended?
How can we know, when the license checkout expires than?


Suggestions and Requests / segregate/decompose large sequence diagrams
« on: September 17, 2009, 09:01:09 pm »

we would be very pleased about that feature:

When sequence diagrams grow through their live cycle it is often later recognised, which part of it can be a sequence diagram of its own to be referenced in other diagrams (like loops, optional parts, etc.)

Currently one has to draw this  parts  as a separate diagram and then can add it as a reference to the original diagram and has to remove the messages out of the original diagram.

This is very cumbersome.

It would be much more easy to add a fragment element to the original large sequence diagram and than being able to create a new diagram from all objects and messages in this fragment by converting it to a referenced diagram.

This is the straigth forward way to cut large diagrams into smaller pieces.


Suggestions and Requests / Re: Voting
« on: March 19, 2008, 10:47:43 pm »
Hello midnight,

you are talking like an oracle  :-/

And I am not talking about the DB. :)

Suggestions and Requests / Re: Voting
« on: March 19, 2008, 10:14:46 pm »

how can I ask him?

Now he is an ex-member.


Suggestions and Requests / partial C# classes
« on: March 19, 2008, 10:11:43 pm »

there is an ugly behavior when one has to handle partial classes.
Especially some UI wizards generate partial classes to separate the
user modifyable code and the always regenerated code from the wizard.

The problem occurs when these partial classes are e.g. reverse engineered.

Doing it this way, one will get n class elements in its package for the n parts existing in the n implementation files.

The ugly behavior is, when one has to do some sequence or class diagrams.

You never know in which class element the method, association, property etc. is, you currently need.

That means that you select in 50% (when having 2 parts) the wrong element. A worse case is, that you have n elements with the same name on your diagrams to be able showing the information you want to elaborate.

It would be better if EA wrappes these parts into a single element, which offers all properties, methods, attributes of all partial implementations.

That would be a great help.

What do you recon?


Suggestions and Requests / reverse engineering
« on: January 19, 2008, 08:08:21 am »

last week I had some discussions with sparx.
I was able to convince them, that the reverse engineering has some problematic features.

The said, they will change it in the following way:

In future it wönt be necessary to checkout every pacakge from namespace root down to the package that shall be reverse engineered.

In a first step only the namespace root and the direct package must be checked out.

In a second step, it is even not necessary to checkout the namespace root.

In a third step, EA will take care about the existing namespace package and when you reverse engineer A.B.C.MyClass  from package C it will be engineered into NSR.A.B.C and not in NSR.A.B.C.A.B.C as in the current implementation.

I hope the will fix this soon.


Suggestions and Requests / Re: Packages, Namespaces & groupings
« on: December 18, 2007, 07:42:54 am »
Hello Paul,

yes, in my point of view, we have two problems here,
and Paolos solution, doesn't help the reverse-engineering problems.

But I think Paolo will provide a solution for the other problem soon too! Isn't it Paolo :)

Suggestions and Requests / Re: Packages, Namespaces & groupings
« on: November 13, 2007, 06:05:33 am »
Hello Peter,

the problem is not the checkout.
The problem is the reverse engineering.

Let's name namespace root 'NSR'.
Assume you have the follwing packages:


Now you get code with class


The problem is, that you have to trigger the reverse engineering from namespace root (this is the fault of sparx IMHO). So as the consequence you have to checkout
package A AND package B AND package C, even if packages A AND B are not involved. This is the EA logic and this is cumbersome and contraproductive in a team collaborative environment.

If reverse engineering of the new namespace A.B.C.D lasts 4 days (this is our scenario, 17.000 classes, 4.000 interfaces) the team is blocked for 4 days working on packages A and B.
Although NOTHING happens in A and B!

It's just checked out because of the sparx logic and this strange namespace root concept and that it doesn't allows reverse engineering from the namespace root, if not ALL  subpackages are checked out. Even if nothing happens in the middle subpackages, but only in the leaf nodes.


Suggestions and Requests / Re: Packages, Namespaces & groupings
« on: November 06, 2007, 07:54:19 am »
Hello Bruce and Paolo,

please go to the development halls of sparxs and implement it.

We need that too.

But I can't see the mess you were talking about, Bruce.

Packages are namespaces and components are the deployable units.

The problem is how EA handles it.

It makes no sense, e.g. to start the build, debug, test, deployment and run command on a package.

These commands must be bound to a component of course and not to a package.

The deployment encompasses the classes of the target binary
and therefore it only makes sens on a component to run a build, debug, test script.

I have worked years with rose (no I don't want to use it again, don't be afraid) and they solved this problems.

You can drag and drop classes on components and thess components are the container/grouping where the work has to be done.

IMO the reverse engineering is bad in EA and the namespace root didn't make it better.

It's even worse, because EA automatically sets a namespace root when you import a source dir. This leads to a wrong code generation when starting from this point, because suddenly we have a namespace where no should be.

It's even worse, because you have to checkout every package level up to your namespace root, even if the pakages above your node where you want to reverse engineer are not affected.

This blocks team collaboration.

I don't think that OMG is the problem. For me its the package, namespace, namespace root logic of EA.


I propose, that such tool providers, like Sparx, Rational (now IBM) should develop their tool by using its tool.

I know that rational was not using rose at development.

That's what rational consultants were whispering to me.

Is Sparx using the EA to develop EA?

They would have the same problems, isn't it?
And a lot of problems would be fixed through the pain
the developers would have.

Hello Midnight,

what's the ouch for?

Me or the subject? 8)

Did you burn your fingers before?

Nevertheless, I wrote a feature request for that too.


Suggestions and Requests / reverse engineering and renamed classes in code
« on: November 08, 2007, 04:02:37 am »

We have the following scenario:

We use kind of 3rd party classes, which we reverse engineered to be able using these classes in our model.

Now our model is infused with hundreds of sequence diagrams using these classes.

Now we got a new release of the 3rd party classes, where some very core classes were renamed.

What happens at reverse engineering?
EA find the new renamed classes and provides you a dialog where you can delete the old class from the model, because EA thinks the old classes are gone from code. (because of the missing ids in the source code, rose!)

Deleting the old class corupts all diagrams in our model and this is a very rude mechanism.

Not deleting it results in two classes.
The new renamed one (not in the diagrams) and the still in the model existing old class (still in the diagrams).

What we need are additional buttons/dialogs/mechanisms where we are able to say
e.g. replace old class with new class (so internal uids stay the same), so the diagrams are not corupted.

Of course there are still other problems to solve, e.g.
methods/attibutes/properties are renamed, ...
In an additional release we would expect to have the same kind of matching of old to new methods/attributes/.. too.

But for a first shot, it would be very helpful that hundreds of diagrams are not corupted.

It's much easier to redraw the new messages than to redraw the whole diagram or diagram part concerning the deleted class.

Please give us a solution for that.


Pages: [1] 2 3 ... 13