Messages

1

Suggestions and Requests / Richer note fields (on elements)

« on: March 09, 2009, 09:50:43 pm »

The notes field of the element dialog is a semi-rich text box allowing bold/italics/super/subscript and font color. It however misses being able to change the font size and font type. That comes in very useful when exporting documents or doing copy/paste between the model and a document.

2

Suggestions and Requests / Set font in a diagram/element note

« on: August 31, 2009, 06:38:34 pm »

Currently the Note thingies that are associated to either an element or drawn as part of the diagram have minor formatting capabilities such as Bold, Italics, Underline and Text color.

Many times I find myself trying for format notes as tables. There is no tables capabilities in a Note element. However, this would have been easily circumvented if one could set the font of an element to a FIXED SIZE font such as Courier.

With a fixed size font one can at least nicely format tables in a note element. Because they are not then the "tables" look all jagged.

3

Suggestions and Requests / Move/Copy attributes/methods to another element

« on: August 31, 2009, 06:53:50 pm »

During the making of a model I find myself many times needing to move and/or copy a class attribute or method to another class. Normally you just copy a class as new to start a new one if it is similar in some way but other times you already have an existent one. Currently one has to retype the whole thing

It would be nice to have an element (class/struct/interface) context menu item to copy (and/or move) an attribute or method to another element in the model.

4

Suggestions and Requests / Deferring addition of implemented interface method

« on: August 11, 2009, 04:21:36 pm »

EA 7.5

The subject line is not long enough for a proper description....

When one creates a class in the diagram and draws a Generalization or Realization association to a parent class/interface EA shows a dialog with "Methods to override/implement".

Now the question here is, should one only add them IF one is going to modify the behaviour (override)? or do they get automatically generated during code generation in which case there is less cluttering in a diagram because one can already see WHAT it is implementing.

My other question here is... when the parent interface or class is added an method that can be overriden (or implemented) what would happen? Apparently EA has no way to allow the user that deferred this action to add these at a later time. You either have to retype the whole thing again or drop the relationship and draw it again.

IMHO there should be an option in the context menu to pop up the list of methods to implement/override which already takes into consideration which of those have already been implemented.

5

Suggestions and Requests / Tests view

« on: August 05, 2009, 08:11:45 pm »

Under the View menu there is a Tests entry which when selected a Test case view is docked on EA for Unit, Integration, System, Acceptance and Scenarios.

The problem with this is that it is not very useful. When you prepare test cases you usually have to perform variations of the same as different test cases.

Currently you have to type the whole thing all over again because there is no "Copy" option to create a new test case based on an existent one that one can then modify.

Implementing this option would save quite a lot of time and would make the Test view useful. I was going to use it in my technical designs but it is simply too much work to type that much.

6

Suggestions and Requests / Transform Interface

« on: August 05, 2009, 07:07:18 pm »

Earlier this year I posted about some of the unfortunate differences (with regards to the Project Browser) between droping an object on the canvas as an Interface or dropping a Class object and then stereotyping it as an Interface.

There the primary difference was that even though the later is an interface (by stereotype) the icon on the project browser shows it as a class.

Another drawback is that a standard Interface does not have the Details tab where you can add Tempated Parameters. This you can do with a Class object.

So if you need a parameterirzed (generic) interface you can only use a Class stereotyped as Interface. But if for some reason you use the standard Interface object and later you want to "upgrade" it to a Parameterized Interface, then there is no way to transform the element. The only possibility seems to type all over again

7

Suggestions and Requests / Re: Please Rewrite the RTF (template) Editor

« on: August 05, 2009, 07:03:21 pm »

I agree, I have had a lot of problems with this and creating company templates are just time consuming if you want to enforce them in EA RTF.

8

Suggestions and Requests / Re: Ribbon request

« on: April 03, 2009, 07:16:51 pm »

No matter what I still abhor (sp?) the Office 2007 ribbon, I think it is one of the worst ideas Microsoft came over with. I don't know what designers where thinking! well, maybe about eye candy as usual and totally forgetting about usability.

The whole idea of a ribbon plus auto-hiding of less used options in a menu (was that Office 2001?) is very annoying when it comes to using a product with that feature.

Although I think the EA menu structure can still use some improvement I don't think a ribbon will actually be a major improvement. I would rather see other sort of features and improvements made to the product.

9

Suggestions and Requests / Re: Another Relationship Matrix Drawback

« on: April 06, 2009, 06:58:10 pm »

The company I work at is using v7.1 which was a refreshment of a previous license. We acquired v7.1 last year so I don't think they will buy 7.5 they way things are

As for the other reply, yes I had the Include Source Children and Include Target children options enabled in the R.M. options but that does not make any difference (or does not work as expected).

10

Suggestions and Requests / Another Relationship Matrix Drawback

« on: April 03, 2009, 07:24:23 pm »

EA Version:7.1

In a previous installment  about the Relationship Matrix it was discussed about its deficient export capabilities. I have just run across another limitation when doing my data model and mapping the various tables to the requirements and features in the Requirements Model.

The business analyst has created a requirements diagram in which two types have been defined (a) Requirements and (b) Features, these are two types that can be specified in EA.

Additionally and for a good reason, these requirements and features have been created as hierarchies, i.e. REQ-1, REQ-1.1, REQ-1.2, REQ1.-3, REQ-2 etc. and the child requirements (1.1, 1.2, etc.) have been dragged in the Project Browser as a subrequirement of the parent.

Now when that is done I found the following problems with the relationship matrix:

1. In the Source/Target Type combo box you can only select either Requirement or Feature but not both. This makes it difficult to consolidate the relations in one matrix.

2. In our case the Requirements is the target but I see that it only lists the parent requirements (REQ-1, REQ-2, REQ-3) and not the subrequirements (REQ-1.1, REQ-1.2, etc.). This makes it difficult to map items to subrequirements.

11

Suggestions and Requests / Re: Model DrillDown

« on: March 13, 2009, 01:59:04 am »

In the top level diagram of every view I place two notes as headings followed by hyperlinks to diagrams. For example

NOTE: Navigate Upward to Component Model
DIAGRAM HYPERLINK(s): Component Model diagram(s)

NOTE: Navigate Deeper to Class Model
DIAGRAM HYPERLINK(s): xxxxxx

That way I lead the model reader into conceptually higher abstractions or down into more details.

Then I also make use of the Relationship Matrix (with profiles) to make mappings (realizes, etc.) between packages in one view to packages or components in another view. Or to map packages in the component model to Collaborations in the Use Case Model View.

Little by little I am getting into setting up a whole model that is auditable qua implementing requirements. So far this is working well.

12

Suggestions and Requests / Navigator Note: a built-in diagram menu

« on: March 13, 2009, 08:59:11 pm »

For every project we have an EA model and the EA model in turn has several views that comprise the entire design:

- Domain model view
- Business Process model view
- Requirements model view
- System Use Cases view
- Data Model view
- Technical Components view
- Technical Class model view
- Deployment model view
- Test Model view

Various people from different disciplines work at the same time on the model (Business Analyst, Technical Architects, Test Team, Developers). An many a times it becomes a bit difficult to navigate to the right places (specially when the Project Browsers leaves you to drawn in an UML jungle!).

So far we have worked around this weakness by having the top level diagram of every view with a several Note elements as headings and underneath the notes element various diagram links to help the viewer navigate the model in an easier way than with the project browser (which is then used for low level navigation).

What would be nice here is what I call the "Navigator Note" that would implement such functionality. In other words if this feature existed the designer would do as follows:

- Select the "Navigator Note" from the top menu bar (instead of the regular "Note" element)
- A Navigator Note dialog would appear that is not like the Notes text editor).
- In the Navigator Note the user would enter the text associated with the note in the DESCRIPTION text field.
- In the Navigation Items group box (just like the Operations or Attributes) the user will see Add|Modify|Delete buttons for the
 navigation entries.
- When a new entry is to be added to the navigation items the
  user would enter the following (form controls become activated):

    (a) The type of hyperlink: Web (http://), EA diagram,
         or EA Help link
    (b) The hyperlink address (navigate to)
    (c) The display text associated with the link

All of this will then be contained in a nicely formatted Super Note (the Navigator Note) which you can for example place as a whole on the left side of the diagram as a navigation menu.

At this moment we simply have to compose this out pieces and move them around independently

13

Suggestions and Requests / Re: Linux support

« on: March 05, 2009, 12:29:45 am »

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.

14

Suggestions and Requests / Color coding Object scope

« on: March 10, 2009, 09:46:44 pm »

Currently (v7.1) the user can alter or define the color coding of objects according to their status (Proposed, Approved, Implemented, etc.) and indicate to which type of object it applies (Requirement, Class, etc.).

In EA that color coding of the status appears as a halo around the box that represents the object in the diagram (kind of a shadow).

It would also be FANTASTIC if one could do that color coding according to the SCOPE/VISIBILITY of an object. For example, as a model reader I would like to see if an object is PUBLIC or INTERNAL, the first being accessible outside the component, the 2nd being internal to that component. This is currently not possible.

If such feature were to be implemented it cannot be drawn as the shadow/hallo because it would conflict with the status color coding. It can however be displayed in the object's header (the top part of the drawn object) by means of a color or perhaps even an icon on the left side of the header where it does not compete for space with the multiplicity or stereotype icon.

15

Suggestions and Requests / Re: Sync project browser with opened diagram

« on: March 10, 2009, 09:01:27 pm »

Yes I find it utterly confusing, users almost invariably have several diagrams opened at the same time and sometimes these diagrams MAY have the same name but be on different views (Component, Class Model, etc.).

Then when you switch from one diagram to another you expect to have some orientation from the Project Browser as to WHERE you are in the model. Well, no hope there my feeling is that of total disorientation and that happens very often if you are not working with mickey-mouse designs (the simple ones).

I think this should not be a feature but a requirement in any design tool that is supposed to HELP the designer rather than confusing him. Dealing with the complexity of the design is enough.

Anyway, I hope they fix this soon.

BTW We have v7.1 but I wouldn't feel compelled to upgrade unless I see some substantial advantages and improvements.