(c) Bruce Powel Douglass, Ph.D. 2019

Mar 19, 2018

OpCons and Events, are they redundant?

4 comments

I revisited Hoffmanns' paper to look at the main battle tank example and had a question regarding the Separation of Events from operational contracts. Why would one want create an Event called reqCalcCmdrLosCmd() and then an operational contract called CalcCmdrLosCmd()? Why not just Keep one of them? Afterall, the fact that you are invoking via reqCalcCmdrLosCmd() automatically adds that Event to the object MBT in Rhapsody. So why go through the effort of creating a private operation?

 

Mar 22, 2018

First, the SE model is largely logical in nature, rather than physical. So the logical interface is usually defined with logical flows - these may be events, operation calls (note: both events and operations can carry parameters as desired), or actually flows - data, energy, fluid, or materiel. Since the interfaces are logical, we want to describe only their logical properties and ignore the pesky implementation details. The easiest way for define the logical service invocations are with events - even if they end up later being realized in the physical interfaces as bus messages or operation calls. In that way, a host of issues around synchronization can be completely ignored because asynchronous events are automatically serialized into a FIFO order.

 

Note that it is STILL important to define the system function(s) (modeled as operations) invoked by the reception of the event because those system functions must implement requirements. Hence, the common practice is to have the interaction between the system and actors done via event passing and the actual behavior of the system (system function or operation call) is invoked upon receipt of the event.

 

I hope that helps.

- b

Mar 23, 2018

Thanks for the clarification, it definitely helps. I have one follow-up question which applies more to UML as Rhapsody implements it than the SE model. Rhapsody uses Events as constructs for Event passing. Is this the same as the term Signal in plain UML? In the UML spec you have the following types:

 

Signal

Time

Call

Change

 

The Harmony handbook uses Rhapsody terms but not everyone uses Rhapsody when applying the method to SE modeling.

 

 

Regards

 

 

 

 

 

Mar 23, 2018Edited: Mar 23, 2018

I found the answer in the Rhapsody modeler documentation. Although Rhapsody uses the same term for Reception as in the UML spec, a UML Signal is an Event in Rhapsody (here it is straight out of the Rhapsody help):

 

"A reception specifies the ability of a class to react to a certain event (called a signal in the UML). The name of the reception is the same as the name of the event; therefore, you cannot change the name of a reception directly. Receptions are displayed under the Operations category for the class."

 

The event (signal) is being managed automatically by Rhapsody because it's created as soon as you create a Reception. In other tools such as EA Architect you have to create this separately and keep them consistent as well.

Mar 23, 2018

Yes that's right:

UML = Rhapsody

Signal Event = Event

Call Event = Triggered operation

Time Event = timeout (although indicated with tm() rather than after())

Change event = change event (implemented via flow ports or proxy ports, generating a chXXX event when relevant data changes value)

 

New Posts
  • I noticed a slight change in naming convention for interfaces. Which one is the current standard or recommended guidance? In the Harmony Deskbook 4.1: Interfaces names should be referenced to the sender port. Naming convention: i<Sender>_<Receiver>. In Harmony MBSE Modeling Standards for use with UML, SysML, and Rhapsody: Interfaces shall be named in terms of their semantic concept (e.g. iNavData or FLIRCommands) and their names shall be prefixed with a lower case 'i'.
  • I've noticed in many books, papers, and model examples that many name their roles in a lowercase fashion and as an abbreviation of the original classifiers. Where did this convention come from and are there other naming conventions? Example from the SysML 1.5 standard: https://www.omg.org/spec/SysML/1.5/PDF See page 234, Figure D.19 - Internal Structure of the Power Subsystem (Internal Block Diagram There is "fp" for FuelPump or "trsm" for Transmission. Finally, when documenting our models, in any tool you can provide a description for parts as well as classifiers. I was wondering what the difference is when documenting part and classifiers. I end up usually copying and pasting the description of the classifier into the part as well, but perhaps that is not accurate. For example, in the description for FuelPump you write "The Fuel Pump block is etc. etc." In the IBD diagram, for the part "fp", the descrption would also be "The Fuel Pump block is etc. etc." Something doesn't seem right there, but I have no criteria for differentiating.
  • In the Harmony Deskbook there are ActorPins that send events which trigger certain actions in an activity diagram. If I am using UML 2.0, is there a way to model this?