Top 10 modeling hints for system engineers: #10 Forget 7 ± 2

System engineers have responded to the need for more rigor by adopting the UML and SysML standards. The standards are complex, and don’t provide guidance on how best to apply modeling techniques with these languages to effectively specify requirements and architectures, nor how to use modeling to perform trade studies and the various kinds of analyses required by systems engineering. Dr. Douglass has spent more than 30 years consulting on hundreds of project. He shares his observations and deep experience in this list of his top ten hints for model-based systems engineering.

Share:

Bruce Douglass (Bruce.Douglass@us.ibm.com), Rational Chief Evangelist, Systems Engineering, IBM

author photoEmbedded Software Methodologist. Triathlete. Systems engineer. Contributor to UML and SysML specifications. Writer. Black Belt. Neuroscientist. Classical guitarist. High school dropout. Bruce Powel Douglass, who has a doctorate in neurocybernetics from the USD Medical School, has over 35 years of experience developing safety-critical real-time applications in a variety of hard real-time environments. He is the author of more than 5,700 book pages from a number of technical books including Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, and Design Patterns for Embedded Systems in C. He is the Chief Evangelist at IBM Rational, where he is a thought leader in the systems space. Bruce consults with and mentors IBM customers all over the world. Follow Bruce on Twitter @BruceDouglass.



15 October 2013

Also available in Chinese Russian Japanese

Editor's note:

developerWorks Rational will feature a modeling tip for systems engineers from Bruce Douglass each week for the next 10 weeks. Undeniably, Bruce is the perfect person to provide this information, and he does so with humor… which makes it all the more fun. We hope you find these tips helpful as you do your job.

Introduction

Systems engineering has undergone significant change over the last 20 years. Notably, systems engineering has moved from textual-based documents describing analysis results to model-based methods that abstract the system into its essential properties to better focus and apply rigorous analysis. This was, to a large degree, enabled by the popularity of the Unified Modeling Language (UML), which led to the development of a companion, derived standard modeling language, the Systems Modeling Language (SysML). I had the privilege and opportunity to work on both these standards. As a long time systems and embedded software engineer, I provided input as the analytic and representational needs of system engineers. My input also helped to ensure the language's suitability for its purpose which is "to support and improve the state of the practice of systems engineering."

In the decades I've spent working, I've worked on a very diverse set of systems ranging from small implantable medical devices to telecommunications systems to helicopter avionics and spacecraft. I've seen models constructed of varying precision, completeness, accuracy and value. This experience and diversity have helped me form strong opinions about what works well for modeling in systems engineering and what is, let us say, "less effective." I'm sharing with you what I believe are my top ten insights for effective modeling for systems engineers. This certainly doesn't capture everything I have to say on the topic, but it is a start.


10: Forget 7 ± 2

Stop me if you're heard this one: "All diagrams should contain seven elements, plus or minus two."

Have you ever wondered where that statement came from?

In 1956, George Miller published an article in the journal Psychology Review titled "The magical number seven, plus or minus two: some limits on our capacity for processing information." This article dealt with two aspects of stimulus recall. The first aspect is called one-dimensional absolute judgment, a measurement of our ability to distinguish between a number of stimuli that vary one dimension (e.g. size or color) and return a previously learned response (e.g. button press) as a result. The other aspect studied is memory span – our ability to recall a list of items presented and then removed from view. It turns out that by coincidence, both of these things are limited (to 50% accuracy) to seven elements plus or minus two.

The interesting question here is "So what has this got to do with now many things should be put on a model diagram?"

The answer is, of course, "absolutely nothing."

The thing to remember is that unlike the experiments that Dr. Miller performed – in which he presented a list of elements, removed the list, and then asked people to recite the list from memory after a time delay – the elements on a diagram remain in front of you when you look at them.

On the other hand, a model of any reasonable size has hundreds to thousands of elements. Clearly, you can't put everything on one diagram either. So what should you do?

As the author of the Harmony process, I have a recommendation: every diagram should have a singular concept or question it is trying to represent and it shows all of the elements related to that concept. This is known as the "mission" of the diagram.

Some diagrams have fairly clear missions. A UML or SysML state machine, for example, represents the state behavior of a single class or block in the system. Other diagrams are more flexible in their use.

Sequence diagrams, for example, can be used toPurpose
Show how the system interacts with actors in its environment during the execution of a use case Capture requirements around a scenario of a use case
Show how internal design elements interact in a particular case Show a collaboration of interest unfold over time
Define an expect input-output transform sequence Show a test case
Represent what the system actually does in some particular test case Show a test outcome

Class or block diagrams are even more flexible. Common mission statements for class or block diagrams include:

  • Show the design elements of a collaboration realizing a larger scale behavior, such as a use case
  • Show the allocation of requirements to structural elements or to a use case
  • Show a generalization taxonomy
  • Show organization of a model (a so-called "package diagram")
    Note:
    The UML and SysML standards do a poor job of distinguishing between the types of diagrams and the uses of diagrams. A task diagram is a class diagram whose purpose is to show the concurrency architecture, just as a structure diagram is a class diagram whose purpose is to show the internal structure of a class. Both are still class diagrams.
  • Show an architectural aspect such as:
    • The subsystem and component architecture
    • The deployment architecture (allocation of responsibilities to different engineering disciplines)
    • The concurrency and resource management architecture
    • The distribution architecture
    • The dependability architecture (including safety, reliability, and security)
  • Show a design pattern abstraction
    • Show an instance snapshot (aka "object diagram")
    • Show interfaces between software elements
    • Show interfaces between engineering disciplines
    • Show the structure of a structured class (so-called "structure diagram")

The mission concept means that each diagram should only try to answer one question or support one specific line of reasoning. In my experience, most bad diagrams fail because they either have no clear mission or they are trying to answer too many missions.

I like to be clear and clearly state the diagram mission in a comment placed on the diagram. Figures 1-3 show typical examples.

Figure 1. Mission: Show requirements allocated to a use case
personnel transport mission use case diagram
Figure 2. Mission: Show the design elements that collaborate to realize a use case
depict spatial relations
Figure 3. Mission: Show a scenario for a use case (including pre- and post-conditions)
scenario for the personnel transport use case

This of course means that the same element has the potential to show up on many diagrams, but that's not a problem. Any good modeling tool maintains a repository of semantic information that serves as a single source of truth about the model, and diagrams always depict some subset of that encompassing truth.

So there's the tenth hint on my list. Next week you'll learn about #9, All models are abstractions, but some are useful. Stay tuned.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=948288
ArticleTitle=Top 10 modeling hints for system engineers: #10 Forget 7 ± 2
publish-date=10152013