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 ... 17
Somewhat surprisingly, that path doesn't work. I even tried a number of orders of doing things that I thought might yield positive results for one reason or other, but none of these worked.

The way that works is a good way, at least.

I guess in the latter case I did not provide a name for the action, so it just has a type.

Well, now, here is something.

If instead of:
creating an action, then changing the property of the action to be CallBehavior linked to an activity

I do the following:
drag the activity I want to invoke onto the calling diagram, select Invocation, and opt to include all inherited items, the effect is the same except that the action pins do not have the invoked activity name displayed. (The parameter names and types seem to update more automatically if I change them on the called activity as well.) This might work for me.

I probably will just want to show the names on the diagrams. I will link to types, but those do not need to appear on the diagram, and certainly the name of the called activity does not.

Thanks for the reply. I already tried changing that setting, but the value in this checkbox makes no difference for this case.

I configure an action as type CallBehavior, configure Call to point to an existing activity, and synchronize the parameters, so that action pins appear on the action in the calling diagram. Great!

The action pin names on the calling diagram include not only the parameter name and type, but are preceded by the name of the called behavior (activity). An example: "Apply pointing origin offset.PointingOriginOffsetAlg.Algorithm".

The information is correct, but I want to suppress the name of the called behavior on the calling diagram, since this is noise for the intended audience. I haven't figured out how to do this (without manually changing each parameter name, which is time-consuming and breaks the synchronization). Is there a way?

General Board / Re: attribute range and unit; best practice?
« on: November 17, 2017, 05:50:31 am »
For the record, I submitted a new bug report regarding the inability to display attribute constraints on a class diagram.

I just wanted to reiterate this would be highly desirable.

General Board / attribute range and unit; best practice?
« on: November 17, 2017, 05:18:00 am »
I have asked related questions about profiles and showing attribute constraints before, but I will take a step back and ask a more basic question.

What is the best practice for showing attribute range (min, max) and unit in UML? (SysML has a somewhat different answer.)

For context, we are modeling signals in a publish-subscribe system. These signals have attributes, and some of these attributes have properties (e.g., a numeric value representing a reference input or a measured value has a range and a unit). I consider these to be invariant constraints defined on the attribute, but I suppose it practically is also possible to model these as tagged values. Does anyone have a suggested best practice?
For the record, my baseline is simply to add a set of invariant constraints to each attribute. (These are simple: {unit = m}, {min = 5}, {max = 15}. We parse this ourselves so we don't need to comply with OCL syntax.) The constraints show up fine in the exported UML. A drawback (discussed for years) is that these constraints do not appear on a class diagram in Enterprise Architect.


I encountered the same issue in EA 13. Updating to the latest build (1351) did not help. I submitted a bug report.

Build 1307 (hopefully updating this week):
The "Requirement Report - Summary" document template, for instance, does not produce desirable results with SysML 1.4 requirements, since the requirement ID and text are now in SysML tagged values (which is a good thing). It would be a good idea to create a new (or modified) system template that works well with SysML 1.4, if this has not already been done.

Thanks. I know about those. Even if I deselect all the compartments that show here, the compartment with the requirements remains. I think this is due to the shape script.


Oh, and if I copy existing requirements from a previous model (probably not SysML 1.4, but I copy the requirement text from a note field to the SysML 1.4 <requirement> 'text' field, the behavior is different. The first compartment does not appear. I have to configure the diagram to show element tagged values.

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.


Pages: [1] 2 3 ... 17