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

Aug 7, 2018

Does UML 2.0 have the concept of ActionPins (ActorPin)

1 comment

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?

Aug 8, 2018

First, actor pins are a Rhapsody-specific enhancement that is meant to address a very specific problem - namely, the automatic construction of sequence diagrams from activity diagrams. The idea is to mark some actions as from from or going to actors, so that when the SE Toolkit Generate Sequence Diagram parser runs, it can produce messages between the actor and use case lifelines. You can also create them by building a correct and executing activity diagram and capturing the message sequences as the activity diagram executes.

 

As to your second question, the short answer is "Yes, of course". Use Send Action and Receive Action to send or receive events. Such an activity diagram can be made to actually execute, and then sequence diagrams can be automatically captured from the execution, as mentioned above.

- b

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.
  • When modeling a use case using a sequence diagram, do you use specific values for the values of parameters, or do you depict the parameters themselves? For example, suppose you have a message SetPosition. The message takes two parameters, PosX and PosY. When drawing a sequence diagram where 'A' calls 'B', which is preferred? SetPosition(144, 25) or SetPosition(PosX, PosY) Because it's a use case scenario, I thought using specific values like the first option would be preferred because you are illustraing a particular scenario. On the other hand, the second option is more generic and would apply to many scenarios. However, if you have a scenario, where the flow of control changes based on a particular parameters' value, the second option is not as obvious. On checking the IBM Rational Harmony for SE Deskkbook 4.1, on page 94 for example, they use the second option. In the ALT frame, there is a check on the value of CardStatus for example.