Phew. Just finished updating my 3-4 days of my IBM Rational Rhapsody MBSE/SysML hands-on training material (that's 560+ slides of tool training) to Release 8.3 to make a Version 6.
Rational Rhapsody 8.3 was released 04 December 2017. Update was relatively straight forward. Main impacts were:
- 8.3 offers a new xml-based file format, hence unit file extensions are appended with an x (e.g. .sbsx, .rpyx). You get a choice to upgrade when you open a project which results in files with the new unit extensions being saved (the old ones remain hence I had to manually clear these out which is easy but worth knowing)
- I did need to explicitly make rhapsody.exe the default application for new .rpyx file extensions.
- I'm following up on a few things with queries that are no longer working.
- The Format and Display Options dialog have been fused for Classifiers. I felt this leads to improved usability, e.g., much easier to enable the Quick Navigation icons (although multi-select doesn't fully work for things like compartments).
In summary, I think 8.3 is an improvement over 8.2.1. Actually some fixes to 8.2.1 proved useful (mainly word-wrap issues that were fixed). The fix list for 8.3 is here. I expect that an iFix will cover a few of the above (like the file extensions one). I'll post when I know one is out.
Understand the art of the possible. My mission is to make executable Model-based Systems Engineering (MBSE) easy with the Object Management Group's Systems Modeling Language™ (SysML®) and UML® to make simple modeling easy to deploy to the masses. This site provides practical experience of tuning IBM® Rational® Rhapsody® - a precision engineering UML/SysML tool. Rhapsody tips and ideas will be posted with links to videos. You can follow by email (if google app is allowed).
Sunday 31 December 2017
Friday 22 December 2017
Rhapsody Tip #28 - Using explicit vs derived configs to define what to build (Intermediate)
Here's a another video for you.
I sometimes get asked to explain how to define what to build for a Rhapsody model simulation. You can do this either using global parts (which exist in the browser) or using a composite structure, i.e. a Block that has parts which are then connected together. The latter is actually the more powerful as you can tell Rhapsody to derive the bits of the model to build using the "assembly block". Using the property called HighlightElementsInActiveScope you can see in the browser which elements are in active scope, i.e. will be built. This video hopefully explains.
I tried to make the model festive! Happy Xmas!
I sometimes get asked to explain how to define what to build for a Rhapsody model simulation. You can do this either using global parts (which exist in the browser) or using a composite structure, i.e. a Block that has parts which are then connected together. The latter is actually the more powerful as you can tell Rhapsody to derive the bits of the model to build using the "assembly block". Using the property called HighlightElementsInActiveScope you can see in the browser which elements are in active scope, i.e. will be built. This video hopefully explains.
I tried to make the model festive! Happy Xmas!
Thursday 21 December 2017
2 day tool-neutral SysML training
Based on a couple of private deliveries I have decided to begin advertising a 2 day Understanding SysML notation for productive MBSE course. This is really focused on people new to MBSE who want to get an understanding before they look at a tool. They can actually be quite fun. There is a lot of team-working using white boards and I teach all theory from the tool training (e.g. understanding the difference between include vs extend on use cases, aggregation vs composition vs association, associations vs connectors, ports/parts etc).
See: http://www.mbsetraining.com/p/training-courses.html
See: http://www.mbsetraining.com/p/training-courses.html
Wednesday 20 December 2017
8.3 What's New: Display options dialog improvements
On the subject of Rational Rhapsody 8.3 changes I thought I'd post stuff as I find it (for your awareness more than anything).
Other than the obvious (it now saves model files in an xml format) it's worth noting that the Display Options dialog is now vastly different.
Other than the obvious (it now saves model files in an xml format) it's worth noting that the Display Options dialog is now vastly different.
Rhapsody 8.3 is released (6.0.5)
For those that don't know Rhapsody 8.3 was released on 4th December 2017:
http://www-01.ibm.com/support/docview.wss?uid=swg24044061
I have big hopes for this release. Most significantly it aligns with the Jazz 6.0.5 release that heralds the introduction of a new Jazz application called Jazz/am that is licensed for users that have Design Manager licenses. Although the abbreviation is /am to align with the OSLC "Architecture Management". Essentially this is modified version of RTC for model management called Rhapsody Model Manager (or RMM for short). There is some summary information on jazz.net here. For those that don't know what OSLC is there is a summary video here. It's about publishing lifecycle data as URLs and linked them without moving data and making this standards, non-proprietary based.
Bare in mind that the IBM Announcement Letter for 8.1 stated that "Design Manager is now part of Rhapsody Developer and Rhapsody Designer products" so if you have Developer or Designer products under maintenance then you have the ability to generate DM licenses and thus use RMM without additional cost of RTC licenses.
In essence this means that it's possible to use the powerful SCM capabilities of RTC for modelling, such as component-based SCM, repository-based private sandboxes for review, stream-based SCM, without needing to pay for RTC Professional licenses. It also means that some of the deployment aspects such as getting Rhapsody models to publish OSLC resources will be simplified, as it will be built-in with the RMM application model saving.
The IBM Help pages for 8.3 are here. Remember that if you want to google for Help or Topics on Rhapsody that if you pre-fix with "Rational Rhapsody" then chances are that you'll get a good return on your search. You don't pre-fix your google search then think Freddie Mercury. On that subject check out these 20 versions of Bohemian Rhapsody. I like the Muppet version the best.
http://www-01.ibm.com/support/docview.wss?uid=swg24044061
I have big hopes for this release. Most significantly it aligns with the Jazz 6.0.5 release that heralds the introduction of a new Jazz application called Jazz/am that is licensed for users that have Design Manager licenses. Although the abbreviation is /am to align with the OSLC "Architecture Management". Essentially this is modified version of RTC for model management called Rhapsody Model Manager (or RMM for short). There is some summary information on jazz.net here. For those that don't know what OSLC is there is a summary video here. It's about publishing lifecycle data as URLs and linked them without moving data and making this standards, non-proprietary based.
Bare in mind that the IBM Announcement Letter for 8.1 stated that "Design Manager is now part of Rhapsody Developer and Rhapsody Designer products" so if you have Developer or Designer products under maintenance then you have the ability to generate DM licenses and thus use RMM without additional cost of RTC licenses.
In essence this means that it's possible to use the powerful SCM capabilities of RTC for modelling, such as component-based SCM, repository-based private sandboxes for review, stream-based SCM, without needing to pay for RTC Professional licenses. It also means that some of the deployment aspects such as getting Rhapsody models to publish OSLC resources will be simplified, as it will be built-in with the RMM application model saving.
The IBM Help pages for 8.3 are here. Remember that if you want to google for Help or Topics on Rhapsody that if you pre-fix with "Rational Rhapsody" then chances are that you'll get a good return on your search. You don't pre-fix your google search then think Freddie Mercury. On that subject check out these 20 versions of Bohemian Rhapsody. I like the Muppet version the best.
Friday 8 December 2017
The Why, What, How, and Who of requirements writing...
... it's interesting when I talk to many engineers how they struggle with the concept of raising their thinking to a systems, rather than implementation level. Of course, this is a well known struggle within the world of good requirements writing. The ability to define hierarchies and separate customer/stakeholder need, for the how the implementation will full-it, gives the solution architect the freedom to choose and explore alternatives. Of course, the same thing happens with model-based systems engineering...
Here's one way to think about it.
In Scott and Long's MBSE Primer I quite like the way that they talk about 3 systems:
1. The system as it's perceived by the user (the Context System)
2. The design of components that realise the emergent behaviour (the system under design)
3. The designing system (i.e. the system being used to do the MBSE).
We often talk about 1 as being the Black-box system, 2 = the white box, and 3 = the process/method/people.
Of course, the way we model the context system is at a level of abstraction above that of white box modelling. This abstraction enables us to manage complexity. If we don't know how the user will use the system, then the chances of us being able to define the internal communication in the system is slim (at least if the system is new this is the case).
Another way of thinking of this abstraction is the why, what, how and who.
Take unlocking a vehicle use case, for example.
The first level to consider is the Why?
We can state the why, i.e. the goal, regardless of the what, how and who: The Driver needs to be able to secure their vehicle from theft. There may be many ways of doing this, of course. Conventionally, one uses a lock, but that doesn't mean that a water cannon that automatically fires when anybody else gets need, would not meet the same objective.
At the user interaction level we might define what a system does. For example, when I unlock the car, I expect the lights to flash. This behaviour is emergent behaviour realised by multiple components, hence we can consider this to be a functional requirements of a system. The system includes a vehicle and a key. This is essentially a statement of what the system does. System level behaviours are black box requirements. They are realised by multiple components that are not realised by any individual component.
Below this level, is the white box. Perhaps we can think of this as the how (and maybe the who). Which components do what, and how do they communicate to achieve the black-box system level requirements. At the how level we can start to model the internal interactions of the system and allocate behaviour and logical interfaces to individual components.
Another way we could use the Who, of course, is to think of the 3rd system that Scott and Long consider which is the system used to create the system. Perhaps the Who is really the identification of the requirements and behaviours in the components of the system as these components are ultimately defined around people, i.e. as system engineers we write requirements at component level so that we can allocate work to people with some confidence that the work they complete will be valuable in realising the system requirements.
Each of these layers, is a lesson in abstraction. Without abstraction we cannot manage complexity. Abstraction is our friend.
Here's one way to think about it.
In Scott and Long's MBSE Primer I quite like the way that they talk about 3 systems:
1. The system as it's perceived by the user (the Context System)
2. The design of components that realise the emergent behaviour (the system under design)
3. The designing system (i.e. the system being used to do the MBSE).
We often talk about 1 as being the Black-box system, 2 = the white box, and 3 = the process/method/people.
Of course, the way we model the context system is at a level of abstraction above that of white box modelling. This abstraction enables us to manage complexity. If we don't know how the user will use the system, then the chances of us being able to define the internal communication in the system is slim (at least if the system is new this is the case).
Another way of thinking of this abstraction is the why, what, how and who.
Take unlocking a vehicle use case, for example.
The first level to consider is the Why?
We can state the why, i.e. the goal, regardless of the what, how and who: The Driver needs to be able to secure their vehicle from theft. There may be many ways of doing this, of course. Conventionally, one uses a lock, but that doesn't mean that a water cannon that automatically fires when anybody else gets need, would not meet the same objective.
At the user interaction level we might define what a system does. For example, when I unlock the car, I expect the lights to flash. This behaviour is emergent behaviour realised by multiple components, hence we can consider this to be a functional requirements of a system. The system includes a vehicle and a key. This is essentially a statement of what the system does. System level behaviours are black box requirements. They are realised by multiple components that are not realised by any individual component.
Below this level, is the white box. Perhaps we can think of this as the how (and maybe the who). Which components do what, and how do they communicate to achieve the black-box system level requirements. At the how level we can start to model the internal interactions of the system and allocate behaviour and logical interfaces to individual components.
Another way we could use the Who, of course, is to think of the 3rd system that Scott and Long consider which is the system used to create the system. Perhaps the Who is really the identification of the requirements and behaviours in the components of the system as these components are ultimately defined around people, i.e. as system engineers we write requirements at component level so that we can allocate work to people with some confidence that the work they complete will be valuable in realising the system requirements.
Each of these layers, is a lesson in abstraction. Without abstraction we cannot manage complexity. Abstraction is our friend.
Presentation on adapting Harmony/SE process for automotive
This was the presentation I did at INCOSE ASEC 2017 for any who might be interested.
Monday 13 November 2017
I'm presenting a paper and tutorial at the INCOSE ASEC 2017
If anybody wants to meet me, then I am presenting a paper and a tutorial at the INCOSE UK Annual Systems Engineering Conference 2017 on 21-22 Nov 2017 at Warwick University.
The paper is on Tuesday 21st (11:00-11:45) in the Conference Theatre and focuses on Concept-of-Operations simulation and requirements modelling approaches to tailoring the "Classic" Harmony/SE method for automotive. The tutorial is on Wednesday 22nd (11:00-12:30 and 13:30-15:00). We will build a system model from scratch.
See: https://incoseonline.org.uk/ASEC2017/Brochure.aspx
Both topics relate to experiences in using executable MBSE approaches in automotive and the parallels/differences with aerospace and other conventional systems engineering markets (with SysML and Rhapsody).
The tutorial will explore use of customizations in a GPL open-sourcer SysMLHelper profile. If anybody wants to try exploring this using their own machines, then they should install either 8.2 or 8.2.1 with Cygwin/gcc compiler and SysMLHelper v2.1 using the SlideShare instructions here:
https://www.slideshare.net/FraserChadburn/installing-rational-rhapsody-designer-82-or-821-for-executable-mbse
The paper is on Tuesday 21st (11:00-11:45) in the Conference Theatre and focuses on Concept-of-Operations simulation and requirements modelling approaches to tailoring the "Classic" Harmony/SE method for automotive. The tutorial is on Wednesday 22nd (11:00-12:30 and 13:30-15:00). We will build a system model from scratch.
See: https://incoseonline.org.uk/ASEC2017/Brochure.aspx
Both topics relate to experiences in using executable MBSE approaches in automotive and the parallels/differences with aerospace and other conventional systems engineering markets (with SysML and Rhapsody).
The tutorial will explore use of customizations in a GPL open-sourcer SysMLHelper profile. If anybody wants to try exploring this using their own machines, then they should install either 8.2 or 8.2.1 with Cygwin/gcc compiler and SysMLHelper v2.1 using the SlideShare instructions here:
https://www.slideshare.net/FraserChadburn/installing-rational-rhapsody-designer-82-or-821-for-executable-mbse
v2.1 (Release) of SysMLHelperProfile on GitHub (and www.executablembse.com)
I have released v2.1 of my open-source SysMLHelper profile on www.executablembse.com (this is functionally equivalent to 2.1.r). The v.2.1 profile will work with Rhapsody 8.2, 8.2.1, or the next release. It can work with 8.1.3 but would require modifying the profile a bit (as there were changes in 8.2)
I also updated my "Mastering MBSE with OMG SysML and IBM Rational Rhapsody" 3-day instructor-led training material to Rhapsody 8.2.1. The focus of the 3-day training is understanding standard SysML notation and deep-knowledge of using the Rhapsody tool for it. Note: My training uses the SysMLHelper v2.1 release to speed up things up and to provide an example of setting up properties for Rhapsody systems models. IMHO without setting up a model systems engineers will have a sub-optimal experience with Rhapsody. The good thing is that the configuration of Rhapsody is one of the most powerful features, hence if you learn how to do this then you will have the power at your finger tips!
My updated training was successfully delivered last week (in Germany).
I also updated my "Mastering MBSE with OMG SysML and IBM Rational Rhapsody" 3-day instructor-led training material to Rhapsody 8.2.1. The focus of the 3-day training is understanding standard SysML notation and deep-knowledge of using the Rhapsody tool for it. Note: My training uses the SysMLHelper v2.1 release to speed up things up and to provide an example of setting up properties for Rhapsody systems models. IMHO without setting up a model systems engineers will have a sub-optimal experience with Rhapsody. The good thing is that the configuration of Rhapsody is one of the most powerful features, hence if you learn how to do this then you will have the power at your finger tips!
My updated training was successfully delivered last week (in Germany).
Saturday 28 October 2017
Mastering MBSE with OMG SysML and IBM Rational Rhapsody public training course
I'm pleased to announce booking is open for Rhapsody/SysML instructor-led training in conjunction with functional safety team at HORIBA MIRA on 5th - 7th December 2017. This is ideal where there is not enough people needing to be training to warrant on-site training.
Location is the MIRA Academy, near Nuneaton. See HORIBA MIRA's website for more information.
Location is the MIRA Academy, near Nuneaton. See HORIBA MIRA's website for more information.
Feedback from Rhapsody in C++ training delivery
This was my feedback from last instructor-led training on updated IBM Rhapsody in C++ Essentials for Software Engineers (4 day) training (where 5 = Strongly agree, and 1 = Strongly disagree).
... to quote "Enjoyed the course. Found it very interesting and useful" (a Senior Software Engineer).
... to quote "Enjoyed the course. Found it very interesting and useful" (a Senior Software Engineer).
Sunday 22 October 2017
Rhapsody Tip #27 - Controlling which Sequence Diagrams get animated (Simple)
When running simulations in IBM Rational Rhapsody, it's common for new users to end up with a proliferation of animated sequence diagrams open. This problem can compound itself each time you run. This video covers simple techniques for avoiding this situation and overviews the use of the SequenceDiagram::General::AutoLaunchAnimation property that controls this Rhapsody behavior. Also covered in the video is the DisplayMessagesToSelf property which can be used to simplify animated sequence diagrams, so they only focus on the messages between lifelines.
Friday 13 October 2017
Latest SysMLHelperProfile released on www.executablembse.com
The latest SysMLHelperProfile is v2.1.r. I have moved information about SysMLHelper releases to www.executablembse.com. This website will cover aspects of method automation, including use of this Open Source helper to accelerate building automotive-focused system simulations using IBM Rational Rhapsody Designer or Developer Editions.
Note: The SysMLHelper follows in principle Dr Hans-Peter Hoffman's Harmony/Systems Engineering (SE) method. However, it is has tailored to make it slightly easier to adopt, particularly in an automotive context. The difference is that this helper is open-source, i.e. it can be improved and tailored by the community rather than being proprietary to IBM.
I will be presenting a paper and tutorial on this at this years INCOSE ASEC.
Note: The SysMLHelper follows in principle Dr Hans-Peter Hoffman's Harmony/Systems Engineering (SE) method. However, it is has tailored to make it slightly easier to adopt, particularly in an automotive context. The difference is that this helper is open-source, i.e. it can be improved and tailored by the community rather than being proprietary to IBM.
I will be presenting a paper and tutorial on this at this years INCOSE ASEC.
Tuesday 10 October 2017
Updated C++ Essentials for IBM Rational Rhapsody for Software Engineers (QQ139)
I recently updated IBM's Essentials of IBM Rational Rhapsody C++ for Software Engineers (QQ139) for a later version of Rhapsody. This means that I can now deliver it with a more up to date Rhapsody version. The initial update was to 8.1.1 but later versions are possible, depending on delivery context, and I could deliver this through an IBM Global Training Partner (GTP) if needed.
This 4 day intensive "hands on" course teaches you UML and Rational Rhapsody's core Developer Edition capabilities, enabling you to rapidly develop applications using UML, placing a strong focus on Rhapsody's Object eXecution Framework for embedded real-time software. The course is focused on the C++ language using Rational Rhapsody for C++ although it does include an exercise of reverse engineering library functions in C. Using hands-on exercises that replicate ''real world'' applications, you forge a strong UML 2 and Rational Rhapsody foundation and learn how to optimally leverage automation of software development activities and artefact generation using model-driven development (MDD).
This 4 day intensive "hands on" course teaches you UML and Rational Rhapsody's core Developer Edition capabilities, enabling you to rapidly develop applications using UML, placing a strong focus on Rhapsody's Object eXecution Framework for embedded real-time software. The course is focused on the C++ language using Rational Rhapsody for C++ although it does include an exercise of reverse engineering library functions in C. Using hands-on exercises that replicate ''real world'' applications, you forge a strong UML 2 and Rational Rhapsody foundation and learn how to optimally leverage automation of software development activities and artefact generation using model-driven development (MDD).
Saturday 7 October 2017
Update to my Rhapsody installation guide pptx
A lot of people fail to install Rhapsody in a way which gives them access to its ultimate power if they need it. Historically we always used to send people pptx's to set up training machines because screenshots help avoid mistakes and also because it's possible to include test steps to make sure everything worked ok. I've continued this process outside of IBM.
I've done a fresh of my installation guide on slideshare following some recent experience. The guide now covers both 8.2 and 8.2.1 and includes some additional notes on silent installation and dealing with situations where you are compelled to install for all users (i.e. ProgramData is used). The guide also covers installation of the smallest amount of Cygwin gcc compiler chain, plus comprehensive instructions on how to verify that everything is working as it should.
I've done a fresh of my installation guide on slideshare following some recent experience. The guide now covers both 8.2 and 8.2.1 and includes some additional notes on silent installation and dealing with situations where you are compelled to install for all users (i.e. ProgramData is used). The guide also covers installation of the smallest amount of Cygwin gcc compiler chain, plus comprehensive instructions on how to verify that everything is working as it should.
Installing Rational Rhapsody Designer 8.2 or 8.2.1 for Executable MBSE from Fraser Chadburn
This helps people who are installing for my training but also may help others. For example, who want to evaluate the product.
This helps people who are installing for my training but also may help others. For example, who want to evaluate the product.
Sunday 1 October 2017
Rhapsody Tip #26 - Avoiding kinky lines, e.g., when drawing activity diagrams (Simple)
When I'm drawing a diagram in Rational Rhapsody - such as an activity diagram in SysML/UML - I often end up going back to the diagram to remove kinks in things like control or object flows. A simple technique to stop this happening is to press the Ctrl key when drawing the line. This very short 1’15’’ video illustrates. This is a simple proactive technique that means you spend less time going back to adjust lines you’ve just drawn.
This video, as it uses Rhapsody 8.2.1, also gives a quick view of the new on-diagram toolbar which also speeds things up as it reduces the need to go back to the drawing toolbar, and reminds you that there’s also a Stamp Mode that can speed up wiring up actions on an activity diagram (although I find you have to remember to turn it off).
The Rhapsody help has a full list of shortcuts:
https://www.ibm.com/support/knowledgecenter/SSB2MU_8.2.1/com.ibm.rhp.reference.doc/topics/rhp_r_ref_rr_shortcuts.html
This video, as it uses Rhapsody 8.2.1, also gives a quick view of the new on-diagram toolbar which also speeds things up as it reduces the need to go back to the drawing toolbar, and reminds you that there’s also a Stamp Mode that can speed up wiring up actions on an activity diagram (although I find you have to remember to turn it off).
The Rhapsody help has a full list of shortcuts:
https://www.ibm.com/support/knowledgecenter/SSB2MU_8.2.1/com.ibm.rhp.reference.doc/topics/rhp_r_ref_rr_shortcuts.html
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.
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.
Thursday 13 July 2017
Executable MBSE webinar planned for IBM on Wed, Jul 19, 2017 4:00 PM BST
https://register.gotowebinar.com/register/4742377653032506369
Wed, Jul 19, 2017 4:00 PM - 5:00 PM BST
Show in My Time Zone
Presenter: Fraser Chadburn, Trainer/consultant in Rational Rhapsody (currently working in automotive)
Fraser will demonstrate creating an executable “concept of operations” OMG SysML model from scratch with requirements traced in DOORS. He will use an open-source alternative to the Harmony-SE toolkit and explain how it has evolved slightly differently in order to fit with the experiences he's seen in the automotive market. Advanced and exploratory techniques will be touched on such as using Object-Orientated inheritance of black-box behaviours, coping with iterative and evolving use case models, as well as use of tool automation to reduce training needs during deployment. Aligning SysML/UML usage to the graphical notations familiar to automotive control engineers expectations, using state-based behaviours with continuous conditions, flowing data between controllers, and automatically building test plans/cases from executing the system specification will be touched on based on aspirations to use standards-based SysML modelling in automotive feature development.
Wed, Jul 19, 2017 4:00 PM - 5:00 PM BST
Show in My Time Zone
Presenter: Fraser Chadburn, Trainer/consultant in Rational Rhapsody (currently working in automotive)
Fraser will demonstrate creating an executable “concept of operations” OMG SysML model from scratch with requirements traced in DOORS. He will use an open-source alternative to the Harmony-SE toolkit and explain how it has evolved slightly differently in order to fit with the experiences he's seen in the automotive market. Advanced and exploratory techniques will be touched on such as using Object-Orientated inheritance of black-box behaviours, coping with iterative and evolving use case models, as well as use of tool automation to reduce training needs during deployment. Aligning SysML/UML usage to the graphical notations familiar to automotive control engineers expectations, using state-based behaviours with continuous conditions, flowing data between controllers, and automatically building test plans/cases from executing the system specification will be touched on based on aspirations to use standards-based SysML modelling in automotive feature development.
Friday 30 June 2017
Rhapsody Tip #23 - Enhanced usability with Quick Navigation icons in 8.2.1 (Intermediate)
Being able to navigate between diagrams, including drilling back and forth through hierarchies of diagrams is increasingly important for systems engineers and SysML in general (and is also important in UML 2.x which introduced structured classes). In this video I show a new feature added to Rhapsody 8.2.1 (June 2017) called "Quick Navigation" shortcuts.
As illustrated in this short video, this new feature is enabled by setting the General::Graphics::EnableQuickNavigation property. The categories of displayed types can then be tailored for individual diagram or element types using QuickNavigationCategories properties for different meta-classes/diagrams. Further refinement is also possible using the Compartment tab of individual graphical elements, resulting in quite a cool new usability feature that is easily enabled (with a certain amount of power behind it for advanced users to play with). A very welcome addition to Rhapsody for both UML and SysML users ...
As illustrated in this short video, this new feature is enabled by setting the General::Graphics::EnableQuickNavigation property. The categories of displayed types can then be tailored for individual diagram or element types using QuickNavigationCategories properties for different meta-classes/diagrams. Further refinement is also possible using the Compartment tab of individual graphical elements, resulting in quite a cool new usability feature that is easily enabled (with a certain amount of power behind it for advanced users to play with). A very welcome addition to Rhapsody for both UML and SysML users ...
Sunday 25 June 2017
Rhapsody Tip #22 - Why you can't draw connectors between Blocks in SysML (Intermediate)
Another Rhapsody SysML/MBSE tips and tricks video!
Understanding the difference between Blocks and Parts (and thus the difference between BDDs and IBDs) is a massively important topic for a SysML practitioner and something that very few Rhapsody users with no training will guess their way into (I'm forever finding users who try to draw connectors between Blocks, give up, and choose to use Flows instead!).
The whole Block, Part, Port/Connector capability of SysML (and to some extent UML) is really powerful though. This video tries to shed some light on the typical question: Why can't I draw a connector between ports on two Blocks? The video is using IBM Rational Rhapsody 8.2.1 (released June 2017)
p.s. The topic of which ports to use is a whole different ballgame ;-)
Understanding the difference between Blocks and Parts (and thus the difference between BDDs and IBDs) is a massively important topic for a SysML practitioner and something that very few Rhapsody users with no training will guess their way into (I'm forever finding users who try to draw connectors between Blocks, give up, and choose to use Flows instead!).
The whole Block, Part, Port/Connector capability of SysML (and to some extent UML) is really powerful though. This video tries to shed some light on the typical question: Why can't I draw a connector between ports on two Blocks? The video is using IBM Rational Rhapsody 8.2.1 (released June 2017)
p.s. The topic of which ports to use is a whole different ballgame ;-)
Tuesday 20 June 2017
Rhapsody 8.2.1 was released on 12th June 2017
Just so you know, v8.2.1 of IBM Rational Rhapsody was released on June 12th. The IBM page for release notes etc is here and includes a Whats New overview. There's quite few usability things that look good, e.g., Diagram: back and forward navigation button improvements, Diagrams: hover Drawing toolbar and Diagrams: new layouts for Populate Diagram and Rearrange. Some videos will follow. Rhapsody has significant releases roughly twice a year, hence there are 6 months of development time in 8.2.1 compared with 8.2. (my understanding is that development team has also invested more effort - with a particular focus on usability).
I've updated my download and setup Rhapsody Designer for MBSE setup instructions to align, see below. Note fully tested all the training against it but initial tests didn't indicate any show stoppers so I will start update soon (so that all my Rhapsody training is on the latest!).
I've updated my download and setup Rhapsody Designer for MBSE setup instructions to align, see below. Note fully tested all the training against it but initial tests didn't indicate any show stoppers so I will start update soon (so that all my Rhapsody training is on the latest!).
Sunday 4 June 2017
Executable MBSE and SysMLHelper updates
As an update the SysMLHelper has recently had a couple of updates (latest is v2.1.g). Aim is to finish testing in next 2 weeks, hence it's possible I'll do a couple more updates. These mainly relate to speeding up workflow on the "straight to white-box" modelling workflow. I'm posting details to http://www.executablembse.com/ and preparing a tutorial for this.
Monday 1 May 2017
How important is the tool choice?
I heard an interesting analogy recently from someone who was describing how your needs from a tool change over time. For example, when you first go to University you need a fork, knife and tin opener (and a glass). The things you cook may be limited but you learn about cooking over time. When you get your first house you may invest in a set of cooking utensils. If you really like cooking and you have the money you might splash out on some great knives.
It's a nice analogy but there are a few things to consider. Usually when one makes a modelling tool choice it's something you learn to live with because changing tools is difficult and people begin to invest their time, i.e. it's not simply the case of buying a new set of tools as there are people to consider (for example, the manager who stuck their head out to get the money approved).
While you might consider the modelling tool to be a set of knives there is also the bigger picture about the kitchen. For example, IBM doesn't sell knives, it sells kitchens hence a lot of people using a tool like Rhapsody are in big companies where the kitchen is in play, including wider issues such as interfacing with change management and requirements management tools.
Something to remember though is that modeling tools are very different in their architectures. Some are repository-based, some file-based, some use Relational databases, some - like Jazz/Design Manager - use an ontological database. Some even have a file-based and repository-based option (Rhapsody, for example).
Chances are though that you won't find out the real differences until later. That's not to say that one tool is better than another. For example, when I was product manager for Artisan Studio one of the great things was how easy it was to collaborate on the same model as it had a Object-based database with very fine granular locking. This of course has benefits and disadvantages (e.g. what happens over a wide-area network?). Rhapsody has some really sharp aspects. Simulation is one. Configure-ability is another, or working with SCM.
The thing is whichever tool you choose, you're provably stuck with it for a while. I'd recommend therefore that you learn it very well (or get someone that does). Play to your tools strengths but don't be surprised if at some point you see others shooting down the river on different boats, at different times, or occasionally you find you need to portage a waterfall in a few years.
It's a nice analogy but there are a few things to consider. Usually when one makes a modelling tool choice it's something you learn to live with because changing tools is difficult and people begin to invest their time, i.e. it's not simply the case of buying a new set of tools as there are people to consider (for example, the manager who stuck their head out to get the money approved).
While you might consider the modelling tool to be a set of knives there is also the bigger picture about the kitchen. For example, IBM doesn't sell knives, it sells kitchens hence a lot of people using a tool like Rhapsody are in big companies where the kitchen is in play, including wider issues such as interfacing with change management and requirements management tools.
I prefer to think of the analogy of a boat that you intend to tend you down river. You could choose a canoe or an inflatable raft. The chances however is that when you hit the rapids you won't have the luxury to change tools. You'll just have to hang on. That's not to say that your tool won't carry you there. You'll just need to take the rough with the smooth.
Chances are though that you won't find out the real differences until later. That's not to say that one tool is better than another. For example, when I was product manager for Artisan Studio one of the great things was how easy it was to collaborate on the same model as it had a Object-based database with very fine granular locking. This of course has benefits and disadvantages (e.g. what happens over a wide-area network?). Rhapsody has some really sharp aspects. Simulation is one. Configure-ability is another, or working with SCM.
The thing is whichever tool you choose, you're provably stuck with it for a while. I'd recommend therefore that you learn it very well (or get someone that does). Play to your tools strengths but don't be surprised if at some point you see others shooting down the river on different boats, at different times, or occasionally you find you need to portage a waterfall in a few years.
Tuesday 18 April 2017
4 Different Representations for Use Cases in OMG SysML/UML
This 6 minute video uses one of the example models from my 3 day Mastering MBSE with OMG SysML and IBM Rational Rhapsody training. I actually speak!
It shows 4 different forms for how use cases might be represented in SysML or UML: namely structured text, an activity diagram, an interaction model with sequence diagrams, and as an executable state machine model. The cool thing is that we’re free to use whatever you like. Neither SysML nor the UML specify how a use case shall look. The main thing to consider is that use cases take on a journey from analysis to design! Through-out this journey we will meet different people with different needs and levels of knowledge. We need to consider their needs, recognizing that different stakeholders will have different needs, and that needs will change over time. After all there is little value in building an executable state machine of a system, if a simple review of the use case description can determine that it is not what the customer wants after all.
It shows 4 different forms for how use cases might be represented in SysML or UML: namely structured text, an activity diagram, an interaction model with sequence diagrams, and as an executable state machine model. The cool thing is that we’re free to use whatever you like. Neither SysML nor the UML specify how a use case shall look. The main thing to consider is that use cases take on a journey from analysis to design! Through-out this journey we will meet different people with different needs and levels of knowledge. We need to consider their needs, recognizing that different stakeholders will have different needs, and that needs will change over time. After all there is little value in building an executable state machine of a system, if a simple review of the use case description can determine that it is not what the customer wants after all.
Monday 17 April 2017
Rhapsody training updated to 8.2
Yep, it's official. In line with my goal to deliver the most up to date training, all my training has been updated to Rhapsody 8.2 (and what a nice release it is).
Sunday 2 April 2017
Official launch of ExecutableMBSE.com
To better align with the refined mission statement of the business which is "to make executable MBSE simple through the provision of consulting and training services", I've created a new website http://www.executablembse.com/
The focus of this site (http://www.mbsetraining.com/) will remain on generic Rhapsody training & advice while aspects including the executable MBSE method, and updates to the supporting open-source SysML Helper profile, will be moved to the new website.
The focus of this site (http://www.mbsetraining.com/) will remain on generic Rhapsody training & advice while aspects including the executable MBSE method, and updates to the supporting open-source SysML Helper profile, will be moved to the new website.
Friday 31 March 2017
Feedback from Rhapsody MBSE training on 15-17th March
Past performance is best indication of future performance. This was the aggregated top 5 feedback from my last training course (where 5 = Strongly agree and 1 = Strongly disagree):
Monday 27 March 2017
Rhapsody Tip #21 - Display options for ports incl. PortsSingleLabelLayout (Intermediate)
Rhapsody has many properties and display options for how ports are show. This video shows some of these, including a rather cool (and slightly hidden) PortsSingleLabelLayout property. Some advanced ideas are also shown, such as using a stereotype to convey new default properties to a diagram as well as basic usability such as showing or hiding ports from display. Enjoy!
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).
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.
See:
https://github.com/fchadburn/mbsetraining/releases/tag/v2.0
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.
See:
https://github.com/fchadburn/mbsetraining/releases/tag/v2.0
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:
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.
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:
- Create a functional analysis model structure for performing the model execution based on a given requirements-analysis model.
- 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.
- 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.
- 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.
- Capture each key usage scenario as a test case that is traced to the requirements.
- 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.
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.
Subscribe to:
Posts (Atom)