Messages

1

Suggestions and Requests / Display full namespaces in diagrams

« on: January 30, 2010, 09:54:52 am »

Display full namespaces in diagrams, not just the parent package name, next to any given element. Would be helpful in dialog boxes as well, where lists of objects are presented.

2

Suggestions and Requests / Re: Linux support

« on: March 12, 2009, 12:37:25 pm »

As a former Linux enthusiast (note, I still think it is a far superior OS) I must say that was one of the reasons that also contributed to my "defection" to the Windows ranks. I got tired of working with incomplete clone applications that had portability problems...

Though Qt is good and there are plenty of others, the fact remains that the GUI frameworks used in Linux often follow the whims of people. As a result developers have to spend a lot of time maintaining code that becomes broken after a new GUI framework release.

I was formerly developing s/w for Linux using GTK (among many other frameworks I try and don't care to remember) and I remember every time I had to spend time on re-porting, time I could have better used to concentrate on the application itself.

Anyway, I probably get flamed to a roast by all Linux enthusiasts in this forum. Been there, done that, emigrated to Windows and I can live with it.

Sure, as a very sporadic Linux user I would also like an EA port. But frankly speaking if I was EA I would rather concentrate the resources on ironing out bugs and requests to improve the product (which is already FANTASTIC and my favorite) rather than spending a great deal of time in maintaining two code lines. EA was developed as a Windows application so I really don't think its original design accounts for separation of presentation layer.

What you say about GTK+ and other toolkits may be somewhat true, but QT is a stable commercially developed and supported toolkit. The era of application suites being married to one specific platform is drawing to a close.

3

General Board / Search & Replace?

« on: October 23, 2009, 08:31:44 am »

This tool provides a robust set of features to assist with finding and reporting against data in the repository, but nothing apparently designed to help manage data in the repository. I've run into a handful of scenarios over the past 10 minutes that call exactly for this sort of thing:

1. Change the author of a set of elements to someone else.
2. Change the status of a set of elements from proposed to approved.
3. Change the version of a set of elements from 1.0 to 2.0.

etc.

Am I missing something? Is there an efficient way to do this that doesn't involve importing/exporting the data or writing SQL directly against the model repository?

Any help would be greatly appreciated.

-Matt

4

General Board / Re: Destructive XMI Import

« on: April 18, 2009, 02:37:08 am »

Just found a similar topic that was being discussed a few days ago. Branching/merging appears to do what we want. Is it possible to selectively merge changes to selected packages, or is that something that is done at the model level?

5

General Board / Destructive XMI Import

« on: April 18, 2009, 12:45:16 am »

Does the following still apply to version EA Corporate v7.5? We are trying to understand the best way to merge changes from multiple branches of the architecture over time. XMI import under version 7.0 does not appear suitable for this purpose.

http://www.sparxsystems.com/uml_tool_guide/uml_model_management/importxmi.html

Important:
When you import an XML file over an existing package, ALL information in the current package is deleted first. Before you import the XML file, please make sure you do not have important changes that you do not want to lose.

6

General Board / Re: Concurrent Development

« on: April 18, 2009, 02:33:57 am »

Dermot, is step 3 something any user can perform quickly and easily as needed with a DBMS based model, at the package level? Or is this something that has to be done at the model level?

7

General Board / Re: Duplicate Type Definitions

« on: April 04, 2009, 08:23:30 am »

I don't believe there are any nuances to this, at least there shouldn't be. Inside any given source file, there may live a class.  We want EA to recognize this class, ignoring the name of the file in which it was found, and synchronize it if it already exists under the current root package.

I can see how this might complicate round-tripping changes back into the file, but if forced to choose between reconciling source code files and hunting for and merging duplicate types in the model, well, there are hundreds of tools to facilitate transforming source code files, and NONE to facilitate cleaning up an EA model.

8

General Board / Re: Duplicate Type Definitions

« on: April 04, 2009, 08:01:43 am »

I'd like to completely decouple the file path from any target model artifacts that may have the same fully-qualified name, so that importing a type does not result in the creation of a duplicate artifact. It sounds like I need to develop a custom add in to address this. Is that correct?

9

General Board / Re: Duplicate Type Definitions

« on: April 04, 2009, 12:16:08 am »

We have multiple developers involved in our round-trip engineering process, and we would prefer the location of these classes not to factor into the import/synchronization process, as anyone might at anytime want to sync from their local workspace. Is that possible?

10

General Board / Re: Duplicate Type Definitions

« on: April 03, 2009, 09:38:05 am »

Will that be improved in a future release? We'd prefer to enforce unique names across the board.

11

General Board / Duplicate Type Definitions

« on: April 03, 2009, 08:57:49 am »

Is it possible to globally require that all types in a given package be uniquely named, or if not, a tool that will locate and list all duplicate class definitions and facilitate some kind of merge?

In a similar vein, when reverse engineering classes by namespace for example, if a source file changes its location on disk, sometimes a new class is created where it should instead synchronize the existing class.

12

General Board / Verification

« on: March 15, 2009, 02:51:10 am »

So how does one verify C# reverse engineering completed successfully? The reverse engineering progress dialog is consistently disappearing near the end of the process, and having no log, no output in the output tab and no "Import Complete" message, there doesn't appear to be any way of knowing whether a 20-30 minute source code import/sync actually succeeded.

Any suggestions are much appreciated.

13

General Board / Re: create all dependencies reverse engineering

« on: March 13, 2009, 12:44:28 am »

Absolutely. And if not at reverse-engineering time, a separate analysis tool built into the application could serve the same purpose, creating the appropriate links (associations) everywhere classes of a given type are cross referenced.

14

General Board / Collections as Properties

« on: March 12, 2009, 11:56:35 am »

As a part of our SOA strategy we have developed several thousand C# classes and interfaces that define our service contracts and message schemas. These are all very consistent in their use of generic lists, List<#TYPE#>, for all collections, and expose all of these collections as properties. I have been able to successfully reverse engineer these properties into the model, but the collection classes are not correctly translated into aggregation/composition relationships – they just appear as operations with no direct link to the underlying type. We need these links to visualize the relationships between entity classes and to enable full traceability between these entities.

Likewise, I seem to be having difficulty generating collection class properties from aggregation/composition relationships. What I get are fields instead of properties, which isn’t surprising considering there do not appear to be any options to control property handling from the aggregation/composition link. This seems quite fundamental, am I missing something? We are still using EA 7.0.

15

Bugs and Issues / Re: Export/Import Sequence Diagram lost message

« on: October 22, 2009, 01:58:59 am »

We are discovering this as well, and consider it a major problem.