Skip to main content

skip to main content

developerWorks  >  Rational  >

How does RUP SE apply to a system of systems?

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Introductory

Dave Brown, Staff, IBM

08 Mar 2004

from The Rational Edge: Brown explains how IBM RUP for Systems Engineering,® or RUP-SE,® can support project involving the integration of multiple systems.

Illustration In today's systems development environment, more often than not the programs that IBM Rational clients work on involve the integration of multiple systems. This article explains how IBM Rational Unified Process for Systems Engineering® (RUP SE®) can help in these situations.

By definition, a system is a self-contained entity that includes all the resources needed to satisfy its business purpose or mission. These resources include hardware, software, data, and/or people. A "system of systems" is a large-scale entity that integrates the capabilities provided by smaller (contained) systems. IBM Rational Unified Process,® or RUP,® is oriented toward building single systems.

So what do we do when our context is a system of systems? Use RUP SE. RUP SE extends RUP to more fully address the physical aspect of systems, in addition to the logical aspects represented by subsystems.

Figure 1: Many development programs involve a system of interconnected systems.

Figure 1: Many development programs involve
a system of systems.

In a system of systems, typically there is a many-to-many mapping between logical elements (subsystems) and physical elements (represented in RUP SE as localities or design nodes). However, this is not always the case, and it is sometimes difficult to distinguish between subsystems and localities. The best way to understand the distinction is that subsystems are logical, whereas localities are physical . In working with clients, we provide examples that relate directly to their domain to illustrate this difference. Even so, they often have a hard time separating the two concepts, especially if they have a background in producing physical systems such as a car -- or more specifically, in integrating physical systems such as the car's engine, brakes, and seats.

So we did a little research and analysis to find out why clients kept having trouble distinguishing between subsystems and localities. The reason, we discovered, is that clients are used to buying existing physical elements that do not require development. These elements have both logical and physical aspects, yet they are treated as a single entity.

For example, take a car seat. If your context is the vehicle, then the seat is a physical element of the vehicle. Yet today's seats have functionality to "remember" and adjust position for different drivers, and to turn heating devices in the seat on and off. These are logical characteristics. But if you were purchasing such a seat to assemble a car, the physical seat and logical functionality would come together in one package as a single part number, so why would you ever think of separating them? The seat is in fact a system in its own right; the vehicle integrator can treat it as a black box. What makes it a system? It follows the definition we started with: It is a self-contained entity that includes all the resources needed to satisfy its purpose.

Does this mean that our approach to systems engineering -- which calls for the separation of logical and physical perspectives -- is flawed? Not at all. On the contrary, our approach prescribes logical and physical separation if design is required but allows you to treat an entity as a black box if no design is needed. RUP SE is scalable and robust enough to address everything from full system development -- that is, when you must design all elements from scratch -- to system development for integrating a system of systems, and everything in between.



Back to top


RUP SE activities provide guidance

What does all this mean with respect to the activities described in the RUP SE plug-in? Actually, these activity descriptions provide nearly all the guidance you need for any program. With respect to activities, there is one main difference between a perspective that separates logical and physical elements and one that treats elements as a system: For the first perspective we would define logical functionality (services) in logical subsystems; for the second perspective we would define the services directly in the contained system (a lower-level element that represents both logical and physical perspectives). Whenever the guidelines in the IBM RUP SE plug-in call for the use of a subsystem, you can simply substitute the contained system. And there is no need to decompose the contained system into either logical or physical elements; you can treat it as a single black box for your purposes.

To do this in your design models, represent the contained system as a single class with the <<System Proxy>> stereotype. Just as you would for subsystems, you should represent the services as operations on this class. And, just as you would for localities, you can capture the physical characteristics in the tagged values of the class (see Figure 2).

Figure 2: Use system proxy and tagged values for contained systems.

Figure 2: Use system proxy and tagged values for contained systems.



Back to top


Resources

I hope this short treatment provides a useful way for you to think about your development challenges, especially if you are working on a system of systems program. My colleagues and I constantly exchange and analyze input from clients about RUP SE and other IBM Rational tools through our internal Systems Engineering Community of Practice (SE CoP). If you have systems engineering questions or concerns you'd like to share with us, please send them via The Rational Edge. For more information about IBM RUP SE and the IBM RUP SE Plug-In, see Murray Cantor's recent Rational Edge articles:

IBM Rational clients can also access the section on the RUP SE Plug-In at http://www-128.ibm.com/developerworks/rational/library/4313.html. And for information about IBM Rational consulting services, see
http://www-306.ibm.com/software/rational/services/professional/index.html



About the author

Dave Brown

Dave Brown is the worldwide lead for the Systems Engineering Community of Practice within the Rational brand of IBM Software Group. He has contributed significantly to the development of RUP for Systems Engineering,® or RUP SE,® and has applied it in multiple customer engagements. He joined Rational in 1997 after a seventeen year career at TRW, where he was involved in every aspect of the software development lifecycle, from defining the vision to releasing maintenance updates.




Rate this page


Please take a moment to complete this form to help us better serve you.



 


 


Not
useful
Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top