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 4 ... 13
Suggestions and Requests / Re: Database icon
« on: November 08, 2007, 08:43:21 am »

you are absolutely right.

But don't you think this is such a basic thing, that sparx could provide a database element/package/entity/component?

I am sick of doing it again and again. :'(


Suggestions and Requests / Re: Database icon
« on: November 08, 2007, 07:38:36 am »

it should be a database symbol when dropped onto a diagram.

Yes I could use it from deployment or component toolbox too,
but I would expect it in database toolbox too.

Any solution would be better than the currents solution,
I guess.

Suggestions and Requests / Re: Database icon
« on: November 08, 2007, 07:29:52 am »

maybe as an extended stereotype of an entity in the datamodel toolbox.

Yes, I could do it by myself.
But this is such basic, and I always do it for every customer where I am.


Suggestions and Requests / Database icon
« on: November 08, 2007, 07:13:17 am »

can you please provide a database symbol/icon?

I am missing it very often and it's such a basic thing.


Suggestions and Requests / Parts and Ports
« on: November 06, 2007, 07:34:33 am »

when drag'n'drop classes to components you can define that the class is part, port or neither of them.

When you select Port or Part you have to give them a name
and the default proposal that EA gives is Port  or Part.

It would be very helpful if the name would be the same as the class I drop.

In most cases this is good enough.

In the way EA implements it, you always have to change that default, because Port and Part explains nothing in the diagram.

If I don't want to have it as a port or part,
I would expect that the dropped class is shown in the project explorer as a sub element of the component, but not as a copy, rather than as a reference to the original class.

Thus I would circumvent the port/part level, which we don't find necessary. It would be very nice, if the class references are directly shown below the component node in the project browser.


Suggestions and Requests / Re: depenencies on packages
« on: November 05, 2007, 11:56:01 am »
Hello David,

yes you are right, the elements in the package have the dependcies and therefore it shouldn't be possible to remove a dependencie from one package to another if there are still elements in these packages which are dependend from each other. Only if no dependencies on the element level exist, than the dependency on the package level should be allowed to be deleted.

Showing dependencies for different aspects between packages is just the same as showing them between classes.

When dropping two classes with an association between then on a diagram, leads to a drawn association between the classes. And it's my decision if I want do have it in the diagram or not. If I don't want to show it, i remove it, without deleting it.

And that's what we need for dependencies too.

I guess, if you will get a diagram where nearly every package is dependend from nearly every otherone, than this is a good indicator that here is something going wrong.

There shouldn't be an option for package dependency detection.
This is a must in my point of view. Not an option.

The question is: Do I want to show the dependency them?

And that's the same question, everybody has to answer on every class diagram. The relationship between them is there.
They are just not visible on all diagrams, depending on the context I want to show.

And you are right, there are still ohter areas in the product, where other things have to be done.

And as a sample, we need the same solution for components too.


Suggestions and Requests / Re: depenencies on packages
« on: November 05, 2007, 09:07:05 am »
Hello David,

thank you for your answer, but I don't agree with you.

Beginning with your first sentence, I have to ask why is it possible to draw dependencies on package level if the concept does not relate to dependencies.

It is not impossible nor difficult to infer them.
This is a problem of directed graphs and can be calculated very easy with matrices. These problems are very well understood in mathmatics and I can't see a problem in that.
By the way: rational rose did it this way.

Of course your sample can make sense. I don't disagree.
If it makes sense, thatn do it.

But it also makes sense that I want do find e.g. these cyclic dependencies, because in a refactoring I want to get rid of them.

Or you want to find dependencies of packages which against
architecural rules e.g. frontend directly accesses DB layer
instead of going through the middleware layer.

it would be an ease to find these things it the dependcies are drawn automatically.

I am talking about the scenario, when creating new diagrams.
At least at this diagrams I want to have the dependcies.

Existing diagram, of course shouldn't be affected, because
the tool can not decide if the user wants to see it, or not.

On new diagrams I can decide it I want do see it.


Suggestions and Requests / dependencies on packages
« on: November 05, 2007, 08:46:56 am »

I wonder if there is a possibility to show the dependencies between packages.

Asume you have


so ClassA is in namespace/package A
and ClassB is in namespace/package B.
Now draw an aggregation in a way that
ClassA aggregates ClassB.

If you have modelled it this way you have an
implicit dependency from package A to package B.

If you now create a package diagram and drag and drop
package A and B on it, NO dependency is shown.

This is wrong.

And reverse engineering doesn't elaborate the depencies on this level.

This is bad.

Because that's what I want to see for refactoring and it would be an ease for such a tool to draw this dependencies.

So please create this dependencies at reverse engineering and modeling automatically.

This information is very worthy.


Suggestions and Requests / Re: deleting namespaces
« on: November 05, 2007, 12:39:20 am »

SPARX will fix it, that the dialog becomes the context menu again. :)


Suggestions and Requests / Re: deleting namespaces
« on: October 31, 2007, 03:55:07 am »
Hello David,

this is the current status.

I will inform you if it changes.

I don' have to check it.
The functionality inside the dialog is definitely gone but still available in the documentation.


Suggestions and Requests / Re: deleting namespaces
« on: October 30, 2007, 11:47:41 pm »

instead of bringing back the funtionality,
they are adapting the documentation.

That means the feature is gone now!


Suggestions and Requests / Re: deleting namespaces
« on: October 18, 2007, 09:01:14 pm »

I try to explain it better.

There is a dialog in 6.5 AND 7.0 ( Settings -> Namespaces).

In this dialog, in 6.5 it was possible to delete namespaces,
by right clicking on the namespace name.

In the 7.0s dialog it is NOT possible to delete the namespace, because the context menu which opens by right clicking is gone.

In the documentation of 7.0 the dialog is shown with the old screenshot made from 6.5, because the 7.0 dialog documenation still shows the context menu of deleting namespaces, but this context menu does NOT open in 7.0.

So eihter the documentation doesn't fit the implementation
or vice versa.

Neithertheless, I wrote a bug report.

I hope this was more clear now and I expressed better.


Suggestions and Requests / Re: deleting namespaces
« on: October 18, 2007, 04:08:23 am »

in the help under index Namespace root
you will find the dialog with a context menu opening
showing the menu "Clear Namespace Attribute".

This screenshot belongs to EA 6.5. In 7.0 it is missing.

So is the implementation correct and documentation wrong or vice versa?

Neithertheless, I write the bug report.  :'(


Suggestions and Requests / Re: deleting namespaces
« on: October 18, 2007, 03:45:12 am »
Hello thomaskilian,

yes, I know, that's the place where it was in 6.5 and in 7.0.

But additionaly in 6.5 it was in the mentioned dialog under
Settings -> Namespaces, but it seems to be gone there in 7.0.

So is it a bug that it is gone or is sparx just thinking now
that nobody needs it anymore in this dialog?

Suggestions and Requests / deleting namespaces
« on: October 17, 2007, 11:33:35 pm »

the behaviour of deleting namespaces changed from EA 6.5 to EA 7.0.

Settings -> Namespaces

formerly you had the possibility to delete namespaces.
Now this possibility seems to be gone.

Is it unfeatured or bugged or am I too simple minded to find the old feature?


Pages: 1 [2] 3 4 ... 13