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.
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 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.
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.
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 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
| 
