Top 10 modeling hints for system engineers: 8: Napkin models are a good way to start a conversation, but a terrible way to end one

Don’t risk a failed system from imprecise thinking sketched on a napkin. #8 in Bruce Douglass’s top 10 modeling hints series helps you move from lightweight to high-fidelity models.


Bruce Douglass (, 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.

29 October 2013

Also available in Chinese Russian Japanese

This hint is a thinly veiled complaint about the most common (mis)use of modeling that I see in the industry: The construction of lightweight, imprecise, incorrect, and unmaintainable models that add little in the way of analytic support and answer zero questions of interest. You might notice that I am not in favor of modeling this way. I prefer "high-fidelity" models. These are (within their scope and intent) complete, accurate, correct, and precise; and verifiably so (something we'll talk about later in hint #1).

Let me be clear: The value of modeling lies in our ability to be verifiably complete, precise and accurate with respect to the intent and scope of a model. Napkin models, named because they are often hand-drawn on any handy disposable surface, are a common way of using UML or SysML. But using models in this way is a little like programming a missile with approximate ballistic parameters. It'll land somewhere, so what's the difference? If you're at the terminal end of the trajectory, a lot.

Figure 1. Napkin models are imprecise
model sketched on a napkin

Note: Because this is a napkin model, there is no repository underneath to ensure the consistency of the semantic statements with any other napkin you might have in your pocket.

Some questions you might have about this model include:

  • What is this model trying to depict?
  • Are those all the attributes of Student or Seminar?
  • What are the data types and appropriate subranges for the attributes?
  • What are the parameters and return values of the operations?
  • How do you determine eligibility for a seminar? What information is needed to determine that?
  • How are these elements created? How are they linked together? How are they destroyed?
  • How can you tell if a seminar is empty or full? What information is needed for that? Is the MaxNumber:unsigned int attribute missing?
  • Are there any default values for the attributes?

It sounds like I have reserved a rung of hell for those creating napkins models. That's not precisely true. I think that this is a fine place to start a conversation. As you answer questions and reason about system structure and behavior, you morph this model from "napkin" to "high-fidelity". This is easier when the model is managed in a modeling tool with a real model repository. It's even easier when the tool supports model verification, like some high-end tools, such as Rational Rhapsody.

The bottom line is that imprecise thinking results in failed systems. In my world, that is unacceptable.



Get products and technologies



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

ArticleTitle=Top 10 modeling hints for system engineers: 8: Napkin models are a good way to start a conversation, but a terrible way to end one