Saturday 23 September 2017

Rhapsody Tip #25 - Exporting just diagrams into existing DOORS modules (Intermediate)

Conventional Rhapsody Gateway usage would be to export a Rhapsody model as a surrogate module in DOORS with links to a formal module that contains the requirements. However, did you know that the Export Document to DOORS functionality can be used to add Rhapsody diagrams to an existing DOORS module? This can be useful for supplementing textual requirements with diagrammatic information that makes them easier to understand and conveys additional meaning. It's straight forward. However, the settings need to be done carefully to make it work as expected. This short video illustrates.


Key things to remember:
  • Set the Capture diagrams variable for the model (in the Project Configuration), re-analyze and make sure the diagrams are shown.
  • In the Export Document to DOORS dialog:
    - Filter out all the element types that are not diagrams (and parts of the model you don't want).
    - Check the box for Diagram images.
    - Check the box for Keep children of filtered elements.
    - Check the box for Do not maintain elements location.
    - Specify the DOORS login details (e.g. using a profile for the server)

Saturday 2 September 2017

Rhapsody Tip #24 - Using change events with flowports (Intermediate)

I've not posted in a while (I have a good excuse, I committed to do some volunteering work!).

I keep getting asked about Flow-ports and how to get them to work in Rhapsody, hence I thought I'd kick things off again by providing a video on this. My gut-feeling, SysML proxy-ports still lack the simplicity you can achieve with flow-ports (which, given they are the base of the Simulink integrations, are unlikely to go away in Rhapsody anytime soon).

Despite the introduction of proxy ports in SysML 1.3, flow-ports remain very useful when simulating systems. In this video I demonstrate how to use flow-ports in IBM Rational Rhapsody to transfer data values from Parts defined by different Blocks, and get the receiving Block to react to changes to the value in the transmitting Block. One of the good things about flow-ports is that they are multi-cast, e.g. it's possible to draw connectors to multiple parts. This, in combination with the fine granularity makes them very useful for simulating automotive systems.

While I admire the intent behind proxy-ports, I think there are practical reasons therefore why flow-ports persist as useful. They are also the basis of Simulink integration in Rhapsody, another reason why they are not going away quickly. The trick to using flow-ports for simulation in Rhapsody is to understand that it uses naming conventions. This video illustrations the use of a change event (e.g. chSpeed) and a setter (e.g. setVehSpeed), together with name equivalence between the flow-port and the value property/attribute to get it working for simulation.