Executable MBSE: Method Part 1: Requirements Analysis

The following video shows the latest SysMLHelper profile in action:

The purpose of this method is to produce functional requirements driven from use case analysis of the system.

The Requirements Analysis method is a 10 minute method. Using the open-source 'SysML Helper' profile takes only 10 minutes to use Rhapsody end-to-end to create a SysML project from scratch and get the requirements created in it into Rational DOORS (it takes about 1 hour to show someone how to do it).


The essential steps are:

1. Create the Rhapsody project, populate a package structure with a use case diagram and setup the Rhapsody Gateway project to sync requirements into a formal module in DOORS.
2. Create use cases and their related high-level requirements (goals).
3. For each use case create a simplified (text-based) activity diagram of the steps including both the sunny and rainy day scenarios.
4. For each step create a new, or trace an existing, functional requirement, such that all steps are covered by at least 1 functional requirement (in some cases a step may be covered by more than one requirement, or a requirement may be related to more than one step).
5. (Optional) Sync all requirements into Requirements Management tool such that they can be management and tracked with allocated unique ID's.
6. (Optional) Sync all diagrams into the RM tool such that they can provide additional information to support the requirements.

Obtaining, installing and/or recompiling the SysMLHelperProfile

The following slide deck gives instructions for obtaining and installing the SysMLHelperProfile from https://github.com/fchadburn/mbsetraining/releases. This includes instructions for recompiling for different Rhapsody versions (at the moment it is built for 8.1.3). If you are upgrading my recommendation would be to move to the new 8.2 rather than 8.1.5., if you can. The profile is starting to look really cool in what you can do (more info to come).

Sys ml helperprofile-rhapsody813-obtainandinstall-v1 from Fraser Chadburn

Version 2.0 of SysML helper is nearing release

Due to overwhelming workload I have been a remiss in posting Rhapsody tips recently. However, that's not to say that I've not been busy. For those that might be interested in Executable MBSE my version 2 of the Rhapsody SysMLHelper that I first showed here is nearing completion.

Version 2 is much more extensive. Latest changes are support for menu localization and a three way option for populating the hierarchy.

 The helper is about 12,000 SLOC of Java plugin code. The latest is v2.0.28 (I did say I was busy). The goal is to make Executable MBSE with Rhapsody simple enough to do without training. Building on my 7+ years experience in IBM with Harmony/SE and subsequent experience. It is designed to be more flexible and easy to adopt, works at a range of modelling scales, and is completely free if you're happy to accept the GPL 3.0 license. More info to follow.

For those interested in knowing more about executable MBSE and other SysML topics my latest Rhapsody MBSE/SysML training course is moving to Dec 6-8th 2016 at HORIBA MIRA. Depending on participants interest I will show the helper in full glory as part of the discussion on methods.

10 Tips for Requirement Writing

Here are 10 tips for requirement writing:

1. Write atomic requirements that stand alone. Use “Shall“ where requirements are being stated, “Will” when representing statements of facts; and “Should” to present a goal that needs to be achieved.
2. Make them easy to read and jargon free. Form a complete sentence devoid of loose terms, buzzwords, or acronyms.
3. Avoid using let-out clauses or ambiguity such as but, except, if necessary, etc., etc.
4. Use a subject (user/system) and a predicate (intended result, action or condition).
5. Write what is wanted not how it is done.
6. Avoid indefinable terms like user-friendly, versatile, robust, approximately, minimal impact, etc. Select aspects that are measurable.
7. Don’t make references to unreachable documents or requirements yet to be defined.
8. Avoid conflicting statements.
9. Make them achievable.
10. Use positive statements “The system shall…”, not “The system shall not…”.

New option to install the Rhapsody Design Manager client as part of the Rhapsody installation.

One thing I do like a lot about the Jazz products is the open development philosophy, e.g. ability to download and trial the product, raise Jazz work items and view the status of these in real time via Jazz.net, forums etc. I think this community is a massive step forward.

For those interesting in all things Jazz or Design Manager it's interesting to know that the Rhapsody 8.1.5 installation now includes the installer for the Design manager client extension. This Jazz.net article by Johan gives a little bit more info but essentially it simplifies deployment a whole lot:

Essentially, there's now an option to install the Rhapsody Design Manager client as part of the Rhapsody installation, rather than having to find and download the right one. This relates to Design Manager v6.0.2.

Rhapsody Tip #18 - Exporting high-quality vector-based images out of Rhapsody (Simple)

Here's a question that somebody actually asked me today, hence it's become my tip of the week. We often want to quickly get diagrams out of Rhapsody to send to people or include in manually-created documents. There are a number of options to do this, the obvious being to Export Diagram Image... However, this is not necessarily the best option (as only exports raster-based format).

The easiest and most effective way to get a vector-based image is to Ctrl-A, Ctrl-C and Paste (Ctrl-V) from the diagram canvas. If you want to send pictures for people to review another really handy idea is to Print to PDF (in conjunction with either Windows 10's built in feature, or a third-party PDF printer tool (preferably one that's safe and doesn't install bloat ;-). This short video illustrates:

Obtaining and installing my SysMLHelperProfile

In some of my videos I've hinted at a method for speeding up the use of Rational Rhapsody for systems engineering tasks such as creating requirements from use case steps and creating executable MBSE models from textual use case models expressed using activity diagrams.

This method acceleration is achieved using a plugin I've written called the SysMLHelperProfile that adds new menu commands to the Rhapsody menu. It provides a similar function to that of the SE-Toolkit provided by Rhapsody to support the Harmony/SE, except that I've made this helper available as an open source project on GitHub under GNU General Public License (GPL) v3.0 terms. The latest improvements were to improve the double-click functionality to easy navigation graphical.

This video gives instructions on how to install the SysMLHelperProfile. The helper itself is a work in progress:

Installing Rhapsody with Cygwin/gcc for Executable MBSE

If you don't install Rational Rhapsody in the right way then you might be missing out on a lot of its capabilities. If you want to try using Rhapsody's powerful simulation capabilities for Executable MBSE then it's more important than ever to get it installed right.

These are the instructions that I provide for setting up Rhapsody with the Cygwin gcc compiler for my Mastering MBSE with OMG SysML and IBM Rational Rhapsody and Executable MBSE training and consulting. The main thing to consider is that you can save an awfully large amount of disk space and time by just installing the small part of the compiler tool chain you need.

The training uses the Rhapsody Designer for Systems Engineers Edition. However, as the slides suggest we can pretty much install all the Editions and then control the Editions we use using shortcuts.

Installing Installing IBM Rational Rhapsody Designer and Architect for MBSE from Fraser Chadburn

Rhapsody Tip #17 - Making space on sequence diagrams using the Shift key (Simple)

And so the foraging for useful tips and tricks continues. This simple tip can be used to speed up drawing sequence diagrams in IBM Rational Rhapsody. If you don't hold the SHIFT key before you click on an element then just the individual element will be moved. However, if you hold down the SHIFT key before selecting an element on the diagram then Rhapsody will move all the elements below to create or remove white space. The technique can also be used to create or remove white space between lifelines on the diagram as this very short video highlights ...

Rhapsody Tip #16 - Some magic drawing key tips to know (Simple)

IBM Rational Rhapsody has a number of handy key presses you can use when you're drawing diagrams, e.g., holding down the alt key to prevent re-sizing contained elements is the one most people learn first but there are others, e.g., press Shift while re-sizing will keep the shape's symmetry, and pressing Shift while moving an element with arrows allows you to nudge without moving the contained elements. There's also ways to add user points and draw lines parallel to the axis. This short video shows a bunch of them.

The Squiggle of Design

I really love this.

I was recently in discussion with a colleague about the importance of the cone of uncertainly in systems engineering. This aligns a bit with Robert Spinrad's, VP-Xerox, quote “In architecting a new software program, all the serious mistakes are made on the first day.” 1988.

Something my colleague mentioned was that he really likes The Design Squiggle. It's pretty cool, isn't?

The Process of Design Squiggle by Damien Newman, Central Office of Design is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.

A more elaborated example is here.

The real thing here, I think, is this: Iterate and get feedback. Try something, improve quality of experience, try something else, make sure it works, look for simple things, look for elegant things. You'll make more mistakes at the beginning but keep going and keep soliciting feedback and changing things and an elegant design will emergent that revolutionizes the user experience.

Rhapsody Tip #15 - Changing the default project directory (Intermediate)

This is a lesser known tip. When you create a project in Rhapsody, the New Project dialog will, by default, choose an installed folder as the default root for new projects. This is not usually a desired location, and may not be read/write, requiring you to browse to a new root. Doing this every time you create a project can be annoying especially in training or when demoing. Fortunately, you can tailor the default folder by adding a line ProjectsDirectory= to the rhapsody.ini file. This short video illustrates:

Note: Rhapsody also writes to this file, hence when editing the rhapsody.ini try to have Rhapsody closed.

MBSE Rhapsody SysML Method #1 - Requirements Analysis with Use Cases and Activity Diagrams

One thing I hear a lot from people new to MBSE is where to start? It’s a valid question because SysML and tools like Rhapsody can be used in many different ways. They provide the mechanisms to express systems models, not a method. In this video I show some extended tool support I’ve developed to accelerate a method that I know works. It's for a very simple SysML method that goes back to UML basics.

I've also decided to open source this code in order to support my training and consulting work. The repository is: https://github.com/fchadburn/mbsetraining/releases/tag/v1.2. You are free to download, use it, or try it out providing you accept the GPL v3.0 license.

This is an initiating method used to perform requirements definition work from analysis of use case steps using an activity model. It can be used regardless of whether you want to go on to model execution; as it aims to squeeze the best out of two worlds; DOORS for Requirements Management and Rhapsody using the SysML graphical notation. The premise is that SysML offers a brilliant landscape for the requirements definition work, and DOORS provides a scaffolding for connecting and managing the resulting requirements with the wider world.

Rhapsody Tip #14 - Using make default and drawing interruptible edges (Simple)

This video shows a couple of simple tips when working with Rhapsody's drawing surface. The first is the ability to choose a new default size for things by right-clicking and choosing Make Default... The second tip is a workaround for drawing a jagged edge coming out of an interruptible region by adding user points. Both are things I actually use quite often, hence I thought I'd bottle them into a video.

p.s. The Helper profile I use in the video is something I've made available as an open source helper (more info to come on this).

Rhapsody Tip #13 - Managing Unresolved elements/units (Intermediate)

This video gives some housekeeping tips for IBM Rational Rhapsody. A model, by definition, differs from drawing pictures because you have the ability to view the same artifacts in many different ways. A common data dictionary means we can keep things consistent as information and ideas are evolved by the team developing it.

But what if someone sends you a model that references a profile or units in a different model that you don't have, or your CM strategy fails to ensure related files are propagated together? This video hopefully helps to explain. It also shows how you can use the File > Add to model dialog in Rhapsody to reference other profiles and Edit > Advanced Search and Replace dialog to check a model for unresolved elements.

p.s. I've expanded my domain names. Can you guess which ones I've gone for? ;=)

Integrating Rhapsody with Configuration Management (CM) tools

Following on from my short video on Units (Tip #12)...

If anybody is configuring Rhapsody with their Software Configuration Management (SCM) tool then this IBM dW article by Patrick Schnieder, Patrick Weber and Martin Stockl is quite interesting:
http://www.ibm.com/developerworks/rational/tutorials/integration-guide-for-rhapsody-and-clearcase-on-windows/

The command line part is very CC tool specific but some of the principles such as units and the need to configure properties run across all SCM tools. The MS-SCCI mode setup for Rhapsody is also more generically useful for a range of other CM tools but the actual CM tool and related API does make a difference. Eclipse has its own way of integrating with SCM and is a option some people use for Rhapsody with RTC or SVN. For some tools such as RTC, however, more than one option exists (Eclipse or MSSCI) hence it's important to understand the general tool landscape/product versions and what you want to achieve. 

If you google well enough then you can find the Team Collaboration Guide from the 'list of books' days before IBM. The first bit, at least, is worth a read just to get a basic grounding. It's been superseded by IBM's online help but I like the intro. 

Considering MBSE methods as model-to-model (MDA) transformations

During a recent discussion at the INCOSE Working Group there was a comparison between Model Driven Architecture (MDA) and Model-based Systems Engineering (MBSE). It promoted an old friend to raise a point that he felt that his organization does apply MDA techniques in MBSE because they transform models from one form to another. They may not call it MDA - and it may be semi-automated or manual - but fundamentally there is an underlying concept of a model-driven transformation that exists. I really liked this idea.

One method is to transform use cases into functional requirements via actions in an activity diagram. With the right tool customization, I can explain and show an engineer who knows nothing about SysML how to do this in 10 minutes. It's a very simple method and very simple to explain. It's amazing what they can come up with. Simple methods can be used to embody and analyze very complex behaviors and “model driven transformation” is a neat way of thinking about it.

Ultimately teams use Model-based Systems Engineering methods to transform ideas into other ideas. The transform may be model-to-model (M2M), model-to-text (M2T), or text-to-model (T2M). The adage that you don’t need something complex to explain something complex applies. Using a set of simple transformations we can assemble an end-to-end process that flows information across teams and achieves astounding results. We can move from static pools of silo'd knowledge:

To business level transformation of ideas (notice the use of the «block» notation at the bottom ;-):

 (if we can get all the teams to all agree that is, ha ha).

Rhapsody Tip #12 - The General::Model::RenameUnusedFiles property (Intermediate)

I created this video to help explain some basic principles about how Rhapsody stores UML/SysML projects on the file-system; the folder structure and the concepts of units are the key ones. For more advanced users I've also highlighted what happens when you rename units plus one of many properties Rhapsody has that can be configured to control how it works. Whether you need to use the property may depend on the setup. At the very least, my hope is that the video gives a few basic concepts worth knowing. Hope it helps ;-)

Next public training is at MIRA Academy

The next opportunity for public Rhapsody MBSE training is 10th-12th May at HORIBA-MIRA Academy near Nuneaton. This includes an option for a 1 day "hands on" Introduction to MBSE with Rhapsody and SysML. The 1 day focuses on a Wireless Alarm System sample project and provides an introduction to SysML. It's self contained and hence provides a great "hands on" introduction to Rhapsody 8.1.3 for those taking their first steps or wanting to refresh.

Depending on how bold you want to be (and whether you have budget) you can expand into the longer course. See MIRA landing page for course inquiries and booking. I'm happy to give you a call if you need more info.

Rhapsody Tip #11 - Understanding Rhapsody's property hierarchy (Intermediate)

Rhapsody has thousands of properties to customize the way it works. Diagram display defaults, toolbar menus, the browser, code or simulation generation behavior can all be tailored for your project or company needs. Accessing this power requires understanding of the property hierarchy.

1. When you open Rhapsody, it reads the properties in the read-only factory prp files in the $OMROOT/properties folder.

2. It then opens the site prp files in the same folder. The latter are user editable. Setting a property here will override the value set in the factory prp files. Care, however, is needed when sharing models as different users may have different site.prp files (unless you're pointing to a common OMROOT). As such, site prp customization may not be the best way.

3. Rhapsody then opens the project. A property set at the project level will override properties in the Site prp files, and so on; this is what we mean by the property hierarchy.

4. Next comes the profiles or settings. If a profile is ‘globally applied’ it will override the Project settings. If we don’t tick ‘Globally Applied’ then we can make the profile apply to only part of the project by establishing an «AppliedProfile» dependency.

5. At this stage we could still override the properties at a level lower than the project, e.g., at a package level or a diagram level. If you want to customize the code generation then this can also be done at Component/Configuration level. This help topic is pretty good.

This video illustrates the hierarchy in action:

The benefit of using profiles are that we can standardize the use of the same default properties across multiple projects. You can create your own profiles or settings (a setting is like a profile) be careful though, there’s no guarantee of order precedent here if you have multiple profiles. One guarantee you do have though, is that you need to customize Rhapsody properties if you want to harness the true power of MBSE for your project. In our training we provide a ready to use example of this.

Rhapsody Tip #10 - What are new term stereotypes? (Intermediate)

IBM Rational Rhapsody allows us to extend the UML/SysML with our own terms. It's a bit like playing fancy dress with UML/SysML. Standard stereotype mechanisms provide us with a fairly transparent extension mechanism (a James Bond theme party?). If we want to pull out the stops then we can mark a stereotype as a New Term and give it new browser icons. This is more akin to dressing up as the Pink Panther or a Giraffe (well something like that ;-). This 2 min video shows an example starting from a blank project:

RedBend white paper on automotive recalls

I can't validate its impartiality but I found this RedBend white paper on Cost Effective Updating of Software in Cars quite interesting. The automotive recall problem is summed up simply by the words: software, software, software...

The trend suggests that the automotive industry needs a paradigm shift and fast. One wonders if micro-controllers running C code if the answer? ;-).

Rhapsody's RY_LICENSE_FILE environment variable

As ex-Telelogic stable mates' both Rational Rhapsody and Rational DOORS use FLEXlm licensing. They share the use of the TELELOGIC_LICENSE_FILE semi-colon separated environment variable. How to set up license is quite well documented but did you know there is also an RY_LICENSE_FILE environment variable? The logic? Well perhaps you want Rhapsody token licenses to be pulled from a different license server than DOORS? Actually, I also found at one point Rhapsody was pulling license servers from a registry entry at one point also! At least nowadays you can see the license path being pulled from in the About Rhapsody dialog.

Rhapsody Tip #9 - Using a query to find (and delete) requirements removed from view (Intermediate)

On occasion in Rhapsody, we may create elements on diagrams and then change our minds. In the context menu we can either Delete from model or remove from view (but keep in model). Just pressing 'Delete' will remove from view (i.e. the safe option). This is sometimes not our intent. To find elements that have no traceability we could create a user-defined Query in the model. Queries exist in the browser and are like persisted search terms, e.g. we can create a Query to search for requirements with exactly zero incoming dependencies. This video illustrates and also explains the difference between remove from view and delete from model:

The Wedding Album analogy

Diagrams in a model should all serve a purpose. They are user defined views of the model. Lenny Delligatti makes an analogy that views are like photographs. In his book SysML distilled: a brief guide to the systems modeling language, Pearson Education Inc., ISBN 0-321-92786-9, Lenny cites photographs of a mountain. The mountain exists in 3D regardless of whether you take pictures of it. Different pictures can view the mountain from different angles.

I like using the analogy of the modeler being like a photographer at a wedding because the wedding photographer doesn’t just take pictures but they make choices about what to put in them. They are responsible for capturing key moments and forming who is in what photograph. Each picture in a model tells a different story (separate families, the grandparents, friends not enemies, love, even the pets). Increasingly with social media and high quality phone camera’s, people can form their own album from multiple people’s views. 

To me this is what modeling is like. It helps manage complexity by presenting different views; structural, behavioral, traceability but with a single source of truth (the model).

Rhapsody Tip #8 - Using and extending the Enhanced Tooltip (Intermediate)

One of Rhapsody's usability enhancements has been an Enhanced Tooltip. It gives a preview with hyperlinks that can be clicked. Things you may not know are that it can be enabled on diagram by pressing Shift+Alt+F2 (or setting a property). Also useful is that Ctrl+F2 will break the tooltip out into a separate Window. Advanced users can also extend Rhapsody's capabilities with method-specific usability enhancements, for example, to view the specification text of related requirements. This short video illustrates:

NOTE: My code for extending the HTML Enhanced Tooltip is now included in the SysMLHelperProfile on GitHub.

Modeling tools vs drawing tools

The goal of MBSE Training and Consulting is to make model-based systems engineering tool adoption easy. That does make it easy though. Occasionally, I get into discussions with people who have learnt about systems modeling but they’ve never experienced it. A person used to Visio for example may see SysML modeling tool as something very similar. As they step into SysML for the first time they make take the perspective that MBSE with SysML is about “I draw a use case diagram, and then I draw an activity or sequence diagram, and I can express this on this internal block diagram” and "look at the model that I created".

For sure, it's important to know what diagrams are and what they mean but is that a true reflection of model-based systems engineering? As product manager for Artisan in 2004-2007 I was closely involved in the creation of its SysML 1.0 profile (I'd used the tool at Xerox, Acterna/WWG and a subsidiary of Rolls Royce prior to that). For me, the thing I loved about the tool was the ability to have 30-150 engineers working on the same model at the same time. It was the shared repository of knowledge; the common data dictionary; the graphical equivalent of a project Wikipedia (long before Wikipedia was developed). After all, Systems Engineering is not a solo task by its nature and neither is modelling. While I can argue this, experience is very difficult to convey and best experienced ;-) Only once you have this, however, will you experience true model-based systems engineering. A model can be worked on at the same time by many engineers. Many teams may work on a model. A model may be part of a bigger model. A model is always consistent across its many views. A drawing tool does not allow this. It’s a key distinction as systems engineering is not an individual task; it's about people and teams. 

Systems thinking - The Skydiving analogy

I heard an interesting comment recently about how to ensure that engineers have “enough room to breathe”. The danger, of course, is that if you specify things at the wrong level, over specify things, or simply specify things that you don’t have a right to specify, then you can easily end up with contention. Conversely, a perfect world lives in harmony.

Engaging an SysML modeling at multiple levels in an organization is a bit like skydiving. When you first jump out of the aircraft everything is very abstract. You can see areas of blue (sea) and green/brown (land). Unless you have a life-raft you probably will make a decision to go for the green/brown. Of course, there’s also the white areas of uncertainty (the clouds). As you get closer to the ground, the level of abstraction changes. The ground and sea distinction still holds but you can now see field boundaries, rivers, and tree-lines. You're through the clouds so things are looking a little clearer as well but you're not home and dry yet. As you get closer to the ground, the level of abstraction changes again. You’re now closing in on the field you picked for landing; its soft and hard bits, the support vehicle that's taking you home, and herd of Bullocks that you weren’t anticipating. All these levels are valid, of course, as they exist at the same time. They’re in harmony because they’re at different levels of abstraction just like a good MBSE/SysML multi-level system hierarchy. Abstraction enables you to understand the big picture, and different teams have precision over the aspects that they own. The perfect world lives in harmony.

Use cases workshops

I was first introduced to use cases in 2000 while working as Ada engineer in Vancouver for Raytheon Systems Canada. The course was run by Steve Adolph, the author of Patterns for Effective Use Cases. Of course, Use Cases are almost ubiquitous now and I often find engineers capturing them without even knowing their origin or intent from UML. The reason is perhaps because the usage of a system actually remains rather important. That doesn’t make capturing use cases easy though. A use case diagram may have the simplest syntax but are the hardest things in UML/SysML to get right. In the 16 years since my training I come across some recurring themes. People often conflict:

a) Use case steps vs Use Cases (aka functional decomposition)
b) Scenarios vs Use Cases (e.g. forgetting that a use case includes alternative paths)

So, does it matter? Well, one implication of this is that you can’t give different use cases to an engineer or an engineering team and say “build me this”. Another issue is volatility and proliferation. We need to avoid ending up with 100’s of use cases whose names are continuously changing rather than the peaceful high level view of what the main goals of a system are.

So, what’s the solution? First, we accept that use cases will change as our understanding evolves. They are a requirement solicitation technique. Second, we accept that the purpose is not to get them 100% right but rather to get 100% of the people to agree on them.

The best mechanism I’ve found is to actually hold off creating use case diagrams unless you’re in a workshop context. Use case diagram workshops can be a sharing and consensus gathering forum and provide an opportunity for constructive questioning and subtle coaching: Is this a scenario of another use case we’re discussing? Is this an end to end usage or a function in a use case? Does this use case have alternate flows? By starting with a blank page, we have an opportunity for sharing opinions and knowledge of the system we think is needed.

The danger with letting people do use case diagrams on their own is that they will turn meat into mincemeat by over working them. The gold dust is often to have fewer not more use cases. It sometimes requires art not science to everyone on the same page.

Rhapsody Tip #7 - Customizing drawing toolbars to ease usage (Intermediate)

Ever wanted to modify Rhapsody’s toolbar to simplify or add the drawing tools that you want? Actually, it’s pretty simple to do. We have the option also whether to do it on individual diagrams or across the project. This video shows how you can override the Toolbar property on a SysML/UML Activity Diagram, e.g., so that a modeler can add a Dependency with stereotype in a single step. A more advanced customization of Rhapsody is also shown; illustrating how we can make it easy for new users to pick up the tool.

Rhapsody Tip #6 - Using a guard-based STM pattern (Advanced)

Occasionally, I want to share some advanced tips and ideas. Sometimes in real-time systems development it can help to capture more continuous behavior in an STM, particularly in automotive. This 2 minute advanced video contrasts two executable MBSE state machines drawn in Rhapsody.

The first State Machine uses a conventional Harel Statechart where the transitions are triggered by asynchronous events. The second shows a different pattern that only uses [guard] conditions to trigger transitions. It shows how a parallel region in Rhapsody can be used to trigger the null-triggered transitions in other parallel regions.

Thinking outside the box

Let's consider this thinking inside and outside the box thing again... 'I'll tell you what I want it to do and you work out how it's going to meet my needs'. The reason we write requirements, after all, isn't because we like writing. It's because we want someone else to do something. Specs are a way we can try and conduct the work of multiple teams working in parallel. The intent being that when they all do their job well, we'll end up with a sum of parts that actually mean something. The same patterns apply to good MBSE with SysML.

The trouble, of course, is that systems engineers are engineers. They love the Chocolate of actually designing the system. Sometimes they can end up thinking inside the box, whereas perhaps they shouldn't. In some cases it's their role, but in other's it's not. Solid division of responsibility on the other hand allows us to get multiple teams working together in parallel. The simplest way by far to separate concerns between teams, whether internal or external, is for one team to work on what happens outside, while another team works out what happens internally, i.e the inside/outside the box division. This is very easy with diagrams in SysML such as Sequence Diagrams and Internal Block Diagrams, and arguably one of the key differences between how SysML techniques are applied in systems engineering vs how UML has been historically applied in software design.

Rhapsody Tip #5 - The General::Model::BackUps property (Simple)

Just one of a thousand useful properties, did you know that this property can be set on a model to get it to save a copy of the previous version, every time you save? This can be handy to give you Backups when using Rhapsody "solo", i.e. without an SCM tool configured.

Rational Rhapsody JAVA API – Code Snippets & Helper Apps

Now, always remember if you're actually looking for Rhapsody tips and tricks on the web, then the tip is to prefix Rhapsody as 'Rational Rhapsody', and you may get lucky.

Forum's and google doesn't tell you everything, for sure. But here's a useful link for those writing Java helpers for IBM Rational Rhapsody that's on the IBM website.

Forget the Rational and, yep, it's 1975 again, probably ;-).

Systems Thinking

What is systems modelling? At what level of thinking is MBSE done? Let’s take the analogy of the Game of Chess.

As a Pawn, I may think that I understand the game. I can see all the other players on the board (well most of them but sometimes I have to stretch). I know the moves each can make. But, as the Pawn, do I understand everything that is in the Chess players head? Well, I’m not sure. There’s the whole bigger picture about the current game-plan, the strategies like Fool’s Mate and the Fortress Endgame, the tactics for countering the opposition, and fooling the opposition.

As the Chess Master in a game I see the bigger picture, the tactics and the plan, I’m at a different level of abstraction. Both levels of viewpoints are abstraction, of course, and both valid. However, I can do things and see things at the system level that are not possible at subsystem level. Then there’s the question about why the Chess board is like it is? Does every Chess Master understand why Chess is like it is? Well, probably, but imagine they don’t. Imagine Chess was not invented and were trying to come up with a game. What characteristics do we want the game to have? Perhaps we want a game between two players, a game that mimics the tactics of battlefield, a game of cunning, a game that has evolved from other games...

All these levels of abstraction are valid. They are all about the same system. However, they are at different levels of abstraction. This is one view of what successful modelling can provide, if you embrace systems thinking. Of course, there are other views of MBSE but for me the trick is to have multiple views that are all valid and all useful with no duplication. That's an art not a given.

Rhapsody Tip #4 - Applying format using a stereotype (Simple)

This basic-level technique I use all the time. I've seen many engineers make great use of it. The most recent example was a requirements engineers who wanted to differentiate 'User Interface' requirements from other requirements on the same diagram so that the guy from the HMI team could pick them out with ease. Another example is for «abstract»  use cases. By making the text Italic and shading them I can place more focus on the concrete use cases.

Interesting Automotive MBSE paper related to Ford

I really like hearing about real-world usage and lessons learnt. Christopher Davey's paper from an INCOSE 2013 (USA) MBSE Workshop on Jan 26-28th is interesting. It talks about Automotive MBSE at Ford (EE Systems). The PDF is on the OMG Wiki.

"These forcing functions lead to the need to support a HYBRID MBSE environment that consists of a set of modelling tools with associated style guides, maturity levels, completeness levels" (p33) is what I took away; particularly when it comes to reconciling the different worlds of PLM BOM-centric vs SysML/UML/Software is-the-future ;-)

Rhapsody Tip #3 - Deleting Events and usages in one step (Advanced)

This super short video shows how it's possible to use a custom Helper written in Java to automate the deletion of Events and related EventReceptions and diagram references. Helpers like this can simplify usage in increase a team's productivity by removing repetitive tasks.

This helper is part of the toolkit delivered with the training we offer.

How soon do I need tool-specific vs non-tool training/consulting?

The adage that “tool-training is not necessary” is sometimes aligned to the propensity to believe that "the production of diagrams is more important than the engineering content behind them". The reality is that the sooner you get you engineers focused on the latter, the better. It's my experience that this naturally happens if you remove questions about how to use the language and the tools by delivering tool-specific SysML training.

It’s not uncommon to go into companies who have been trying to use Rhapsody and SysML for 1-2 years without training. They think they don’t need it. They believe they are doing OK but you see immediately that they are exploiting only a fraction of the tool and languages’ capability.

Contrast this with those who do the training at the start of their journey. If you do training at the start, you start with relative expertise and understanding of what can be achieved. Empowered with knowledge you make better choices sooner. By unlocking the potential from the start this helps to show to everybody what can be achieved with a few clever choices. People will bow to your superior knowledge. Everybody will want to be part of it. Because you’ve done the training, you now understand that training is valuable. You ensure that training is included in tool deployment. People naturally end up focusing on the engineering issues and problems, not on how to use the tool or exploit the language, and the circle is complete. Well, at least, that's the hope ;-)

Rhapsody Tip #2 - Allowing spaces in names (Intermediate)

This quick tip video shows how you can use the NamesRegExp property in IBM® Rational® Rhapsody® to relax or change the naming rules. For example, to allow spaces or special characters in element names of things that it would not normally allow.

This can also be useful for action names; particularly when we sync them into Rational DOORS® using the Rhapsody Gateway add-on.

Rhapsody Tip #1 - Using the Alt key when resizing (Simple)

Here's a simple Rhapsody usage tip for you: If you want to re-size a container without re-sizing the elements inside it, then just hold down the Alt key first.