Top 10 modeling hints for system engineers: # 9 All models are abstractions but some are useful

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.

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.



22 October 2013

Also available in Chinese Russian Japanese

Human cognition is a study of modeling. Not all such models are graphical, certainly, but make no mistake about it – humans cannot reason without modeling.

A model is an abstraction of a thing, or set of things, in which we omit details that are unimportant to the questions we wish to answer or the reasoning we wish to support. This allows us to focus on the details that are relevant to the analysis or questions at hand.

For example, consider the office chair shown in Figure 1. What would constitute a model of a chair?

Figure 1. Models of a chair
image of a chair

Well, it depends on what questions you are trying to answer. If you're trying to assemble the chair, then your model is one of parts and instructions. If you're trying to design an office space according to feng shui, then you care about color and style. If you're retailer, you might focus on cost and availability. Those are all reasonable models, depending on the reasoning you are trying to perform.

You must clearly identify the questions you want to answer, and the reasoning you want to support, before you can create a useful model.

The point of this hint is that you must clearly identify the questions you want to answer, and the reasoning you want to support, before you can create a useful model. You should clearly answer – before you construct the model – the following questions:

  • Why am I constructing the model?
  • What is the scope of this model?
  • Who are the consumers of this model?
  • What questions are the consumers likely to ask of this model?
  • With what reasoning are the consumers going to use this model?

Each of the questions is likely to result in one or more diagrams. For example, if I'm building a system architecture model, I might have the following answers to the above questions:

I am constructing the model to reason about the large-scale pieces of the system, the allocation of requirements to these elements, the definition of interfaces among them, and the allocation of responsibilities to mechanical, electronic, and software engineering disciplines.

Scope

The scope of this model is the system engineering architecture, including the large scale multidisciplinary pieces (subsystems) and their interfaces. It contains trace links back to the requirements model and forward to engineering specific models (mechanical, electronic, and software).

The consumers of the model include:

  • System engineer
  • System safety engineer
  • System reliability engineer
  • Security analyst
  • Requirements analyst
  • Mechanical engineer
  • Electronic engineer
  • Software engineer

Questions include:

  • What are the subsystems?
  • How are requirements allocated to subsystems?
  • What are the interfaces between the subsystems?
  • Is the system safe in the presence of likely failures?
  • What is the reliability of the important system functions?
  • What are the assets that must be protected by security countermeasures?
  • What are the security threats and the points of system vulnerability?
  • What requirements are allocated to mechanical (or electrical or software) design?
  • What are the interfaces between the software and the electronics?

Some reasoning that might be done:

  • Analysis of the fault tree analysis cut sets (sets of faults that contribute to the manifestation of a hazard)
  • Demonstration that all requirements are covered by the design
  • Demonstration that design elements are all present to meet a requirement
  • Test cases required to verify a system is fit for purpose

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=948885
ArticleTitle=Top 10 modeling hints for system engineers: # 9 All models are abstractions but some are useful
publish-date=10222013