Messages

1

General Board / Other UI languages than English

« on: December 10, 2021, 01:08:24 am »

Sorry for stupid question.

I try to find here in the forum a hint, but wasn't able get usefull info.

Is EA UI available in other languages?
If yes, how can I switch?

Regards
Mr. Sanders

2

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?

3

General Board / Re: floating license expiration

« on: February 02, 2016, 10:14:49 pm »

@BORON
Are you using file based or service based Keystore?

Regards

4

General Board / Re: floating license expiration

« on: February 02, 2016, 01:43:50 am »

Hello

thank you.
But the scenario is as I describe

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

5

General Board / floating license expiration

« on: February 01, 2016, 11:52:38 pm »

Hi,

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?

Regards

6

Suggestions and Requests / segregate/decompose large sequence diagrams

« on: September 17, 2009, 09:01:09 pm »

Hello,

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.

Regards
Michael

7

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.

8

Suggestions and Requests / Re: Voting

« on: March 19, 2008, 10:14:46 pm »

Hello,

how can I ask him?

Now he is an ex-member.

Michael

9

Suggestions and Requests / partial C# classes

« on: March 19, 2008, 10:11:43 pm »

Hello,

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?

Michael

10

Suggestions and Requests / reverse engineering

« on: January 19, 2008, 08:08:21 am »

Hello,

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.

Michael

11

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

12

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:

NSR.A.B.C

Now you get code with class

A.B.C.D.NewClass

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.

Michael

13

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.

Michael

14

Suggestions and Requests / Re: reverse engineering and renamed classes in cod

« on: November 08, 2007, 08:00:12 am »

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.

15

Suggestions and Requests / Re: reverse engineering and renamed classes in cod

« on: November 08, 2007, 07:26:53 am »

Hello Midnight,

what's the ouch for?

Me or the subject?

Did you burn your fingers before?

Nevertheless, I wrote a feature request for that too.

Michael