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.
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:
- "Leading modern systems development"
- "Thoughts on Functional Decomposition"
- "Organizing RUP SE projects"
- "Rational Unified Process for Systems Engineering" (series)
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
Dave Brown is Principal Solution Architect in IBM Rational's® services organization. He holds a position on the worldwide Solution Delivery Assurance team, providing guidance to Rational's technical staff on the most strategic client engagements. Previously, he was the global lead of the Solution Architecture Community of Practice within IBM's Rational Software brand. Dave has been a consultant at Rational since 1997 focusing on software and systems architecture and process. Prior to that Dave participated in all aspects of the software development lifecycle during his seventeen-year career at TRW.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
