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.
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 to||Purpose|
|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")
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
Figure 2. Mission: Show the design elements that collaborate to realize a use case
Figure 3. Mission: Show a scenario for a use case (including pre- and post-conditions)
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.
- Learn more about Rational System Architect:
- To learn more about the tool for collaborative, model-driven development for embedded systems, start with the Rational Rhapsody product line overview and the Rational Rhapsody page on IBM developerWorks. Also see the Rational Rhapsody 7.6 information center and the Changing the location of help content to get a local copy of the documentation.
- Explore the various versions, too: IBM Rational Rhapsody Architect for Software, a visual development environment for embedded systems and software
- IBM Rational Rhapsody Architect for Systems Engineers
- IBM Rational Rhapsody Designer for Systems Engineers
- IBM Rational Rhapsody Developer for collaborative, model-driven development of embedded systems. This edition is required for Eclipse users, and editions are available to create specialized projects in C, C++, Java, and Ada languages.
- To learn more about Rational Rhapsody design management capabilities, check out the IBM Rational Rhapsody Design Manager to see how to collaborate, share, review, and manage designs and models with the entire engineering team. Also see the Design Management page on Jazz.net.
- Explore the Rational software area on developerWorks for technical resources, best practices, and information about Rational collaborative and integrated solutions for software and systems delivery.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, anytime, and many of the Getting Started ones are free.
Get products and technologies
- Download a free, fully enabled trial version of Rational System Architect.
- Take an online tour of Rational Rhapsody with an online trial or download Rational Rhapsody or special editions to Evaluate, free of charge, for 30 days.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, or use it in a cloud environment.
- Participate in the Enterprise Architecture and Business Architecture forum, where you can share information about methods, frameworks, and tool implementations. Discussions include tool-specific technical discussions about Rational System Architect.
- Join the discussion in the Rational Rhapsody forum.
- Get connected with your peers and keep up on the latest information in the Rational community.
- Rate or review Rational software. It's quick and easy.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.