Friday 27 January 2017

Run as administrator when doing Rhapsody 8.2 installation

Rhapsody 8.2 was released on 8th Dec 2016.

For 8.2 to correctly install you should right-click the setup.exe and choose Run as administrator (it is not sufficient that the user has admin rights to ensure correct installation)

Note also that there is an iFix1 for Rhapsody 8.2 client available on IBM's Fix Central website. If you're forming a deployment package then it may make sense to include this (which is critical if looking to use Jazz/dm with related iFix1, but also to ensure you're up to date with fixes).

Sunday 15 January 2017

Rhapsody Tip #20 - Adding a HyperLinkShortCut list to graphical elements for navigation (Simple)

In IBM Rational Rhapsody version 8.2 (released Dec 2016) to enhance navigation from individual graphic elements in diagrams, you can add a list of shortcuts that are accessible from the title bar of the element. In Rhapsody 8.2, the feature is only available for classes, objects, composite classes, and any "new term" elements based on these elements. It's still useful, however. This super short video shows how to use the Compartment display options to do it.

Sunday 8 January 2017

Rhapsody Tip #19 - Smart Routing and some other 8.2 diagramming enhancements (Simple)

This short video covers 3 new features in IBM Rational Rhapsody 8.2 that relate to diagramming: Smart Routing, Alignment Guides, and the Rounded Rectilinear line shape option. Actually, they're pretty cool. You do need to set a property to get Smart Routing to work by default though.

Monday 2 January 2017

v2.0 of SysMLHelper release now on GitHub

It was a long time coming but I have now completed testing with both Rhapsody 8.1.3 and Rhapsody 8.2 and have confidence to label a v2.0 of the SysMLHelper as stable. It has a lot of features.


Note: I will be splitting the SysMLHelper information into a separate blog so that I can keep the pure Rhapsody and method-specific threads separate. More info will follow on this.

Sunday 1 January 2017

Executable MBSE: Method Part 2: Functional Analysis

The second stage of the method that follows on from Requirements Analysis is called Functional Analysis.

This is another 10 minute method, in that it should only take 10 minutes to build a model from scratch using the free 'SysML Helper' plugin on Github. The method is highly systematic. The profile provides a "Swiss Army" knife of automation tools for creating the model, transforming the steps and verifying the emergent behavior.

The following video gives an end-to-end example:

In this transformation we need to ensure that all the functions are traced to the same set of functional requirements. As such, one can consider this method to be an evolution of the behavioral model from an activity-model (traced to initial functional requirements) into an interaction model (traced to final functional requirements). This method can be done by the same person or a different person from the Requirements Analysis phase and supports parallel working in separate models, if needed. The focus switches from the left hand side of the V to the right-hand side of the V.

The essential steps are:
  1. Create a functional analysis model structure for performing the model execution based on a given requirements-analysis model.
  2. Take the activity diagram for each use case. Progressively work through it transforming the textual steps into operations, events or attributes. Integrate these system functions, inputs and outputs into an executable state machine. Ensure that the related-requirements trace to transitions in the state machine for coverage.
  3. Execute the state machine to generate a scenario that was described in the original textual-based activity diagram. Validate the emergent behavior of the integrated scenarios. 
  4. Once all the scenarios are integrated, we will start to find missing requirements, hence can fill in the gaps, add new requirements and clarify ambiguous ones in the context of the richer model.
  5. Capture each key usage scenario as a test case that is traced to the requirements. 
  6. Fix issues including removing duplicate requirements, correcting ambiguous requirements, and adding missing requirements prior to hand-off. Sign off all the test cases with stakeholders.
The purpose of the state machine is to ensure that all the paths are consistent. It also allows the verification of the desirable emergent behavior through simulation. Inevitably this finds unexpected and desirable emergent behavior and gaps in the requirements that need to be corrected before cascading into the architectural model (in Design Synthesis). It is very similar to unit testing the requirements model as a suite of tests can be built up and results executed to ensure that modifications do not break existing test cases.

This method aligns in principal and goal to the original Harmony-SE method proven by Dr Hans-Peter Hoffman. As well as working from text-based activity model the SysMLHelper also applies a design pattern to support guard-based, rather than event-based, transitions to be expressed in the state-machine. This is a tailoring of the Harmony-SE method for automotive based applications, and enables a more continuous-based simulation semantic to be expressed. This smooths the hand-off to software engineering teams downstream and eases adoption by engineers familiar with Stateflow.

Importantly, the model is not a software implementation model. It is a requirements definition model and is fully traced to all the functional requirements. It is the test cases traced to functional requirements defined as sequence diagrams that is the primary hand-off to the next level not the state machine. Included in this definition is a set of system functions, system attributes, and events sent to/from the actors that all trace to the functional requirements. In the subsequent stage of the method, Design Synthesis, it is these that will be allocated to components inside the system. This allocation will result in the creation of logical interfaces between the components.