Saturday 28 April 2018

Rhapsody Tip #32 - Graphical merge using Rhapsody's 3-way DiffMerge tool (Intermediate)

Although Rational Rhapsody has a multi-user repository in Design Manager available, it has historically a file-based tool which integrates directly with configuration management tools. Core to SCM is making sure the tool of choice (e.g. RTC, ClearCase, Synergy) is configured to use the Rational Rhapsody DiffMerge tool. DiffMerge is therefore a separate tool launched independent to Rhapsody that understands Rhapsody projects and how to merge them. Included in this is a very advanced feature known as 3-way merge.

This video shows the basic operation of the DiffMerge when dealing with parallel changes to the same project and diagrams. Key aspects of this are that the Rhapsody DiffMerge will automatically resolve all trivial parallel changes, leaving the user to deal with changes that are non-trivial, i.e. conflicting or where a user choice is needed. This video illustrates an example where two users change the same diagram.


Friday 27 April 2018

Different port types in an OMG SysML model (the old pre SysML 1.3 vs new 1.3+)

This post covers a brief introduction to the different port types in a Rhapsody SysML project (8.2.1 and 8.3).

Standard UML ports

The port named ‘pOC’ here is a standard port contracted with standard UML Interfaces. Ports are named interaction points used for isolating Blocks/Classes.


Recognisable with the lollipop and cup symbology, the lollipop tells us the port is contracted to provide the iSubsystem interface.



The cup tells us that it requires the iConsoleAck interface.



The «interface» is a type of class in UML that lists the signatures of operations provided independent of implementation.



This notation is core to component-based design of software with UML2, hence works well with software-centric system modelling. Although deprecated from SysML it remains important in UML, and is still widely used in SysML and systems models, due to its flexibility and power. For example, a single port can provide or require multiple interfaces







If you make use of these, then you may also find you are making use of object-orientated features of UML (such as polymorphism). For example, a behaviour port is one where the Block itself will realize the provided interfaces on the port.











When using standard ports where the port is connected to other parts that provide or require interfaces, separate interfaces need to be used to show the operations in each direction, i.e. a single interface cannot show bi-directional services/operations. Also UML ports are service-orientated; hence they cannot show the flow of data or objects.

SysML proxy ports

The second port type shown here is a SysML proxy port, recognizable by the «proxy» stereotype. There is no lollipop and cup symbology. Proxy ports interfaces are described using a new type of Block introduced in SysML 1.3 onwards called an «InterfaceBlock». Rather than using the Contract tab in Rhapsody, the port is typed by the «InterfaceBlock» that describes the contract.








Use of the «directedFeature» stereotype allows specification of direction as provided or required. Unlike with standard ports, single interface block can therefore show bi-directional interfaces between two Blocks.









The provd and reqd annotations in the «InterfaceBlock» compartment show us the directedFeature settings.













As with UML and pre SysML 1.3 ports, the ~ tells us that this port is ‘conjugated’, i.e. it mirrors or provides the reverse of the interface.







Unlike the UML port we can also show data or object flows, not just operations and invoked behaviors. For example, if we add flow properties then we can see that a direction indicator is also shown.











With a proxy port we can therefore manage the bi-directional signals sent between two components on a single «InterfaceBlock».












In some ways, therefore, this is a simplification.

SysML Flow Ports (pre 1.3)

The third type of Port shown here is a pre-SysML 1.3 Flow Port.










Flow Ports were typed by a SysML concept called «FlowSpecification», an interface concept focusing on data or material that flows designed to allow systems engineers to model aspects like the flow of physical properties.







These concepts have been replaced by the ProxyPort and InterfaceBlock, respectively, hence a direct translation of this to the SysML 1.3+ proxy port notation is possible.

One area where FlowPorts can still be useful is where you want to show discrete signals typed by primitive data types.












When modelling such concepts, a separate InterfaceBlock for each port would lead to a plethora of model elements in the browser which is both difficult to maintain and would bloat a model. This notation is commonly used for integration with Simulink Blocks, and can be desirable for automotive models.

Until the SysML standard and Rhapsody tool fully support primitive types using Proxy ports therefore, the presence of Flow Ports is likely to remain.

Also, you may find that there is code or event generation possible with flow ports, not supported in model executable with proxy ports.

SysML Full Ports (1.3)

The final type of port shown here is a Full Port, which can be thought of as “a part on the boundary”. A full port is most commonly typed by a Block itself. 






The different with a proxy port is that the Block will realize the behaviours of itself. Using Full Ports typed by Blocks, the concept of conjugation does not really exist. They are more commonly used to represent physical connections. Another way of doing the way thing would be to create a part and use proxy ports with an InterfaceBlock.










In summary:

Full Ports were also introduced in SysML 1.3. They represent a part on the boundary. More commonly used when modelling a physical assembly, as they provide a clear graphical representation that can be shown as connected to the outside world. They tend to be used less, and some authors suggest that modelling with non-behaviour proxy ports may offer more consistency as the part is then shown inside the owner.

Standard Ports are UML ports and make use of UML Interfaces. If you use them then you are essentially modelling with UML in a SysML model (which to be honest may be perfectly fine). They make use of the cup and ball (aka lollipop and cup) symbols to show the provided and required interfaces contracted on a port.

The more correct SysML port nowadays tends to be a Proxy Port. Proxy ports are typed by a SysML InterfaceBlock. InterfaceBlocks and ProxyPorts can show both flows and operations/messages and show them flowing in either direction.

The result of the introduction of Proxy Ports and Interface Blocks means that the need for Flow Specifications with Flow Ports becomes redundant. That said, there are still some instances where Flow Ports can be simpler, for example, want to use primitive types, and when you want to do simulation.

Wednesday 25 April 2018

Feedback from my Mastering MBSE with Rhapsody training in Sweden last week

I've done a couple of training deliveries since my last post about them. This was the averaged feedback from a 3 day Mastering MBSE with OMG SysML and IBM Rational Rhapsody 8.3 training last week.










This one was in Sweden. Testimonials included: "Good course - Recommended", "Good rundown of SysML and Rhapsody!" and "Good mix of general MBSE and Rhapsody". My reflection is that we could've easily done another day. I certainly have enough 8.3 material for when it runs as a 4 day (esp. when you get into understanding the different types of ports).

Friday 13 April 2018

Rhapsody Tip #31 - Referencing units in other projects (Intermediate)

This Rational Rhapsody helper videos follows on from my video #30 on units and managing the project on the file system. In this video we look at referencing units from other Rational Rhapsody projects. Building families of projects that reference each other can often be better than having a single monolithic project. Separation of concern across projects means that projects can be managed separately, in different locations, and with separate versioning yet they can share common elements or interfaces. In this video I show how two projects can reference the same common unit in another project, including touching on the importance of considering absolute or relative references.

Interestingly, the video also shows something that I didn't know until very recently. If you manage to import two projects that reference and nest the same third party unit, then Rhapsody will deal with the duplicate import situation by creating a linked unit. Generally, this problem will only occur if you move referenced units until other units (but it's interesting to know that there are still things to know!)



Sunday 8 April 2018

I released V2.2 of my open source SysMLHelper profile for executable MBSE with Rhapsody

This includes a fix to the Functional Analysis Profile package helper that prevents issues that were found with running the helper with Rhapsody 8.3.

See my executablembse.com blog for more information, links to the profile and full change history (I try not to keep the technical detail for the profile separate from this website).

Profile should work with both 8.2 and 8.3. I'm now planning my version 3 enhancements which focus on more 8.3-based development (with DOORS Next and Test Conductor).

Monday 2 April 2018

Rhapsody Tip #30 - Understanding units and the Edit Unit dialog (Intermediate)

Related to a key topic for for a US-based company I've been working for this is a new short helper video on using Rhapsody. It's the first of two related to sharing units across projects and provides base knowledge on what Rhapsody 'Unit's are and some of the options in the Edit Unit dialog (available on the right-click menu).

A 'Unit' in Rhapsody is a file on the File System in which model information is stored. Understanding the concept of units is important prior to configuring Rhapsody projects under source-code management tool control, or to share information across projects on the file system. By default units are created for each package. It's also possible to create units at a finer level of granularity, e.g., for elements based on components, classes, objects and diagrams. This can be done individually or by setting project properties. This video explores some of these concepts and provides an in depth overview of the Edit Unit dialog.

A follow-up video will cover sharing units between projects.