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
General Board / sysml requirements tag on diagram -- cannot turn off?
« on: August 08, 2017, 07:34:21 am »
I am working in build 1307. (Hopefully we will upgrade soon.)

On a SysML 1.4 requirement diagram I place a new Requirement element (from the Toolbox).
I enter the text of the requirement. (This is now in a SysML 1.4 'text' tagged value, rather than in the element Note. This itself is a major improvement.
The SysML 1.4 tags (id, text) automatically show in a compartment in the element on the diagram, which, in itself, is not a bad thing.
If I configure the diagram to show element tags, the tags appear again in a separate compartment.
If I configure the diagram not to show element tags, the second compartment disappears, but the first compartment with the requirement tagged values remains.

What makes the first set appear in the first place?  Is it possible not to display this information (if a user does not want this to display)?. Maybe this is defined in a shape script in the SysML profile?

I may just use this as is, but I would like to be sure I understand what is happening in the diagram.


On the Connectors tab of the Diagram Properties dialog, there is an option to Suppress All Connector Labels.
In the case at hand, however, I need at least some of the connector labels to be visible. I want to hide the labels on the required and provided interfaces between which I am drawing the connectors. Is there a way to hide interface labels in a diagram? If so, how? (I haven't found such an option in the pop-up dialog for the diagram, nor have I found such an option in the pop-up menu options for the interfaces themselves.)

I found the problem in my case. The template I was using has its own Document Options, which apparently were overriding my selection in the Generate Documentation dialog.

Is there any more information on this?

I also am seeing elements without notes in documents generated from my UML and SysML models (EA Build 1107). Previously generated versions of the same document did not have this issue. I am using model documents, so this should be highly repeatable.

Suggestions and Requests / Re: QA Reports Filters do not function correctly
« on: February 24, 2017, 11:38:51 am »
OK, EA support already replied to me. The "Keyword like" search uses the "Keywords" property of the Use Case. (That does make sense, after all.) I mistakenly thought it searched in the use case names. So this is user error on my part rather than a bug. Now I know how to use the feature.


Fair enough.

(The referenced section below -- 9.4.4 -- actually does indicate that the notation should include [[<multiplicity-range>]], but the document could be clearer about what this means.)


Clarify diagram notation for collection parameters in operation

Unified Modeling Language Version 2.5 specification

9.4.4 Notation, p. 108

Please clarify the notation diagram for indicating that an operation parameter is a collection (e.g., array). Some tools do not indicate this on the diagram, but simply indicate the base type. It is unclear to me, at least, if the specification really requires anything else. It would seem to be appropriate for a future version of the specification to require this and to specify the manner in which this appears.

Suggestions and Requests / QA Reports Filters do not function correctly
« on: February 24, 2017, 04:35:57 am »
I have tried to use this feature for some time, and it hasn't worked. I thought maybe I just wasn't understanding how to use it, but it seems pretty clear to me I am using it as one would expect it to work. I filed the following report.

"I want to filter the use cases that appear in the Use Cases in the QA Reports. I should be able to do this using the "Keyword like" button. (From the help: "Include Use Cases with a keyword that matches the wildcard value in the field.")
The actual behavior is not thus, however. For instance, entering a valid keyword in the "Keyword like" field (and clicking Reload) returns 0 results. This is true even if the value is '*'.'
This functionality would be very useful if it worked correctly. Please fix it."

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.)

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