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.