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 - Paul Lotz

Pages: 1 [2] 3 4 ... 17
I did a search on "operation parameter array" and found many threads  going back to 2009 discussing the same issue (including one I commented on in 2014), but I didn't see any threads with direct requests for a change, so I am creating one.

Among many others, these threads capture the issue and some workarounds:,7730.msg136609.html#msg136609,17799.msg172583.html#msg172583.

Naturally, I would prefer that the tool work implement a display feature rather than using a workaround. I did find some examples on line that did show the feature (e.g.,, although I didn't find anything specific about this in the UML 2.5 specification.

The feature request is to be able to indicate on a diagram that an operation parameter is a collection (an array, for example) based on the multiplicity settings (much as EA already does for class attributes). (Presently EA permits one to configure multiplicity, but there is no representation of this on a diagram.)


In one diagram I have defined a Collaboration.
On another diagram I have a Collaboration Use for the previously defined classifier. I also added instances of classes that will perform the roles defined by the collaboration. I connect a role binding connector from the Collaboration Use to one of the classes. I can define the role by typing text in a field on the General tab. I don't see where I could select one of the roles defined in the Collaboration. Am I missing something? If not, it would be nice to be able to do that, to establish a proper link.

(The most relevant EA help page is:

General Board / Re: Signal attribute details in generated document?
« on: August 05, 2016, 02:50:40 am »
I found the difference. In the Document Options for my template I had checked the Option "Hide note-less elements", and it just so happened that I had not added notes to any of the Signals in question.

General Board / Re: Signal attribute details in generated document?
« on: August 04, 2016, 09:13:43 am »
If I run the Model Report template on one of my packages, the generated report does indeed include the attributes in tables for the signals. I have thus verified it is possible. Now I have to find the critical difference.


General Board / Signal attribute details in generated document?
« on: August 03, 2016, 09:47:09 am »
With the documentation generation tool, I have been able to include a table with attributes or operations of Classes, using a table I make myself or using the Features fragment within a custom template.

I have Signals that have attributes as well, but the attributes for these do not appear in the generated documentation. (The "Exclude details for" filter is set to None.)



Well, I was more concerned with someone relying too much on text documents.  Traceability throughout a project is actually quite challenging, I've found.

One approach is to write requirements directly in EA.  In particular, SysML is designed to support this and I think the concept is outstanding.  (One ends up with only one model with precisely defined relationships between the elements rather than a set of documents containing elements with difficult to navigate, if defined, relationships.)  In the long run this is where I would like to go.  On the other hand, the traceability capabilities in the current version of EA are not, I think, sufficient, and not on par (yet) with those of a good requirements database management tool.  Specifically, we need a way to show effiiciently that we satisfy requirements with this design, that code, and these tests.  (The Enterprise Tester add-in is a big help towards this last effort.)  In EA (currently) we lack the capability to show requirements coverage effectively.  In particular, EA does not even distinguish between header requirements and detailed requirements when dealing with requirements satisfaction.  Since SysML is very much in the EA purview, I think it is not at all illogical for to pursue traceability capabilities further in EA.

A further thought on this...

We should be able to trace changes to individual requirements, which means we need to be able to track individual requirements in the source--even if the requirement moves in the source.  What this means is that each requirement needs a unique identifier in the source.  Hence I think simply typing requirements in a word processor,  without identifiers (and a tool that can read these), is not sufficient for requirements management--if theword processor document is to serve as the requirements source.  (Mind you, that is usually what happens in our office, much to my dismay.)

I welcome this new feature as a step forward, but a "complete solution" will require a real interface to an external source document so that changes in the source document will result in changes in EA.  (This is the idea behind the DOORS add-in.)

Suggestions and Requests / Re: Feature request: Confirm close
« on: August 19, 2010, 02:09:17 am »
I respectfully disagree on this one.  I like the application close behavior just the way it is.

Suggestions and Requests / Re: drag-and-drop sorting of features
« on: September 03, 2010, 02:52:14 am »
Ha, ha!  Sorry, I thought maybe I had mixed y'all up when I thought about it later.  Well, now I know!

Suggestions and Requests / Re: drag-and-drop sorting of features
« on: September 02, 2010, 03:28:11 am »
I, too, would like EA to feature drag and drop reordering of attributes.  (This is true, even though we are able to avoid creating classes with huge numbers of attributes in our systems.)


By the way, Bruce, if you want to express your idea correctly and clearly in Latin you might try, "Ceterum censeo errores esse emendandos."  (Technical explanations: errores is accusative plural versus erroris, genitive singular; emendandos because the gerundive--a verbal adjective--must agree with the noun in gender, number, and case.  And OK, I think emendare expresses the idea of correcting more clearly.)  Then readers of Latin will know what you mean!

Suggestions and Requests / Re: EALite integrated into Full version
« on: August 28, 2010, 03:46:15 am »
Geert isn't advocating not using version control.  He's just recommending you version control the packages, not the eap file.  Geert's approach seems to be the recommended one, and it is what we do as well.

We do share our eap files, but that's a different thing.  Also, we release versions in a separate configuration management database.

If I remember correctly you can create a new project and then add the packages that were roots in the first project as nonroot packages in the new project, but still in parallel to one another.  Then build the HTML for the new (single) top-level root.  I haven't tried this, but I think it would work.

Suggestions and Requests / Re: Display of Class Instances
« on: May 14, 2010, 03:23:19 am »
You can create a template that has the options you want and then use that template in each project.  I tried this a while back and some but not all of the options in the template actually applied.  I haven't tried this for v8.0.

Suggestions and Requests / Re: Support retrive history from VC
« on: August 12, 2009, 02:58:57 am »

I do agree that EA needs to support retrieving a user-selected previous version from version control, since that is a legitimate (although hopefully infrequent) use case.

Even more, I also would like to see improved baseline handling.


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