Gallery Tutorial TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7] Section Section: SysML-1.6: HSUV sample Tags and keywords UML keywords Pin CallBehaviorAction ActivityParameterNode ObjectNode ObjectFlow elided Pin notation InputPin OutputPin Parameter::isStreaming InterruptibleActivityRegion Activity SysML keywords SysML Activity Diagram Continuous «continuous» Allocate AllocateActivityPartition allocation «allocate» Slide kind SysML Activity Diagram Click on the image to view it full size There are some major tool issues: MagicDraw/Cameo: ERROR: Incorrectly uses 2 ObjectFlow edges and a CentralBufferNode for "elided Pin notation" instead of an abstract ObjectNode _symbol_ and 2 arrow _symbols_ (notations that are supposed to represent together 2 Pins and 1 ObjectFlow edge) Webel recommends when using MagicDraw/Cameo: AVOID the "elided Pin" abstract ObjectNode notation on Activity Diagrams, use explicit Pins! MagicDraw/Cameo: DO NOT use the ObjectNode menu item on Activity Diagrams ever! MagicDraw/Cameo: ERROR: Incorrectly uses 2 ObjectFlow edges and a CentralBufferNode for "elided Pin notation" instead of an abstract ObjectNode _symbol_ and 2 arrow _symbols_ (notations that are supposed to represent together 2 Pins and 1 ObjectFlow edge) In the Webel trail versions of the SysML-1.6 spec sample Figure D.38, the alignment of ObjectNode symbols over the ActivityParameterNode boundaries is completely contrived, please DO NOT mimic it; please use explicit Pins instead! And also some spec diagram issues, including: SysML-1.6: Each «continuous» Parameter (of each corresponding ActivityParameterNode) in Figure D.36 and Figure D.38 should be set to be streaming, because the Continuous Stereotype has a Generalization to Rate SysML-1.6: The allocation from ObjectNode 'driveCurrent' in Figure D.38 to itemFlow 'i1' on the Connector in Figure D.39 does not appear in the allocation table Figure D.40; Instead there is an allocation from an ObjectFlow 'o6' to the Connector 'epc-emg' It is therefore impossible to consistently represent this spec sample figure in the tool. See however next a more successful attempt using explicit Pins (as recommended by Webel Best Practice). Up next Figure D.38 - Detailed Behavior Model for “Provide Power” {EXPLICIT PINS} Notes [NAMING, VARIATION] The Webel trail versions of the Activity Diagrams D.36 and D.38 use the name 'transMode' for the output Parameter and corresponding ActivityParameterNode (consistent with the spec figure D.38) NOT 'transMode_imported' (as in spec figure D.36) [ISSUE, TOOL] MagicDraw/Cameo: ERROR: Incorrectly uses 2 ObjectFlow edges and a CentralBufferNode for "elided Pin notation" instead of an abstract ObjectNode _symbol_ and 2 arrow _symbols_ (notations that are supposed to represent together 2 Pins and 1 ObjectFlow edge) [DISPLAY, ISSUE, TOOL, WARNING] Webel recommends when using MagicDraw/Cameo: AVOID the "elided Pin" abstract ObjectNode notation on Activity Diagrams, use explicit Pins! [ISSUE, TOOL, WARNING] MagicDraw/Cameo: DO NOT use the ObjectNode menu item on Activity Diagrams ever! [ISSUE] SysML-1.6: Each «continuous» Parameter (of each corresponding ActivityParameterNode) in Figure D.36 and Figure D.38 should be set to be streaming, because the Continuous Stereotype has a Generalization to Rate [ISSUE] SysML-1.6: The allocation from ObjectNode 'driveCurrent' in Figure D.38 to itemFlow 'i1' on the Connector in Figure D.39 does not appear in the allocation table Figure D.40; Instead there is an allocation from an ObjectFlow 'o6' to the Connector 'epc-emg' [ISSUE] MagicDraw/Cameo 19SP3: Continuous and Discrete have metaclass [ActivityEdge, ObjectNode, Parameter] not just [ActivityEdge, Parameter] (via Rate), so may be applied directly to Pin and ActivityParameterNode [DISPLAY, FEATURE, TIP, TOOL] MagicDraw/Cameo 19SP3: if Continuous or Discrete are applied to the Parameter of an ActivityParameterNode the keywords «continuous» or «discrete» can be optionally displayed on the ActivityParameterNode symbol [ISSUE, STYLE] In the Webel trail versions of the SysML-1.6 spec sample Figure D.38, the alignment of ObjectNode symbols over the ActivityParameterNode boundaries is completely contrived, please DO NOT mimic it; please use explicit Pins instead! Snippets (quotes/extracts) [SysML-1.6] Figure D.38 shows the ProvidePower activity, which includes Actions invoking the decomposed Activities and ObjectNodes from Figure D.37. [SysML-1.6] Figure D.38 ... It also uses AllocateActivityPartitions and an allocation callout to explicitly allocate activities and an object flow to parts in the PowerSubsystem block. [SysML-1.6] Note that the incoming and outgoing object flows for the ProvidePower activity have been decomposed. This was done to distinguish the flow of electrically generated mechanical power and gas generated mechanical power, and to provide further insight ... [SysML-1.6] AllocateActivityPartition is used to depict an «allocate» relationship on an Activity diagram. The AllocateActivityPartition is a standard UML::ActivityPartition, with modified constraints... Related slides (includes other tutorials) Related slides (backlinks, includes other tutorials) Allocation of a CallBehaviorActionAction to a PartProperty via an AllocateActivityPartition "swimlane" Allocation via swimlanes in usage allocation mode - DOs and DON'Ts Allocation via swimlanes in definition allocation mode - DOs and DON'Ts Allocation matrix in the MagicDraw/Cameo tool Allocation table in the MagicDraw/Cameo tool Visit also Visit also (backlinks) Flags Book traversal links for Figure D.38 - Detailed Behavior Model for “Provide Power” {ELIDED PINS} Previous Up Next
