Systems Engineering is an interdisciplinary approach to enabling the realization of successful systems. ¹ It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem, including operations, cost and scheduling, performance, training and support, testing, disposal, and manufacturing.

Systems Engineering integrates all the disciplines and specialty groups into a team effort, forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. The Fellows of the International Council on Systems Engineering (INCOSE) have reached consensus on the definitions of "System" and "Systems Engineering." ²

Model-Driven Systems Development (MDSD) supports the INCOSE Consensus statement. It helps manage the complexity of designing a system. Managing the appropriate level of detail for any particular level of the model is an important component of MDSD. Several techniques, which can be described as best practices, are used to do this:

• Decompose systems, not requirements
• Enable both separation and integration of concerns
• Systems and components collaborate; so should development teams
• Specifications flow up and down the architecture
• Base the life cycle on removing risk and adding value
• Development organization should reflect product architecture

Systems are implemented by:

• Modeling the system with the Unified Modeling Language (UML) and Use Cases
• Creation of a common vision with Context Workshops
• Use of IBM® Rational® Software Architect tooling and an IBM Rational Unified Process® (RUP®) based methodology
• Working Iteratively focusing upon early risk removal
• Adoption of a program organization that mirrors the intended system architecture
• Ensuring that the architecture and design can be implemented with a technology readiness assessment

Now that an MDSD plug-in is available for RUP, a review of MDSD is in order. This article will explore the basic principles of MDSD, including modeling levels, levels of decomposition, and how MDSD supports the Software Engineering Institute's Capability Maturity Model Integration (CMMI®) concept.

Models and abstraction

Intuitively, we think in terms of abstraction. Whether we're aware of it or not, the process includes the use of models -- simplified depictions, sometimes only in our heads, of things under study; as well as decomposition -- the breakdown of things under study into their constituent parts. MDSD formalizes this idea of abstraction through the use of different levels of modeling and decomposition within a system.

In everyday life, we use abstraction to help us manage complexity. When we drive a car, for example, we typically abstract away all of the internal workings of the car and consider the car as largely a "black box" with a few main interfaces, including the steering wheel, accelerator, and brake. At the level of understanding we use in driving a car, we hide the internal implementation of these capabilities and consider only their usage from the outside (hence the "black box" metaphor -- we don't see, or don't care to see, the details inside). This places the car in a context of its usage by the driver and passengers.

Our local mechanic, on the other hand, considers quite a different abstraction perspective when we bring in the car for "making a funny noise." While we consider the entire car to be a black box, to the mechanic, the car appears as a "white box" -- a set of components to be viewed, understood, repaired, or replaced; each component is itself a black box. The mechanic is most aware of the interactions between components including the engine, transmission, braking system, etc. Models, abstraction, and levels of decomposition allow us to consider large systems and subsystems and their relationships without being overwhelmed by their internal complexity.

Levels of decomposition

"Level of decomposition" refers to the level of detail at which system elements are considered. In the above example, the mechanic considers the car at a lower level of decomposition than the owner; if the mechanic takes a component of the car to a specialist for repair, the specialist considers that single component at a lower level of decomposition than the mechanic.

At any given level of decomposition, there is a set of logical system elements considered from a black box perspective. These elements are treated as black boxes at that level of decomposition. White box elements within them are only considered at the next level of decomposition.

Thus, choosing what levels of decomposition to include in the model allows the modeler to choose what system elements to expose. Part of this decision, in turn, depends on who is to be the audience for the model at that level of decomposition. We've probably all seen the disadvantage of exposing too much detail in front of a higher level audience. System elements exposed at a given level of decomposition should be recognizable to the audience and in fact, should be named in terms familiar to them.

If we are speaking, for example, to department heads and business function owners in a mortgage company, it would not be wise to include elements such as message handlers and database managers in the model at this level, whereas elements like loan origination, credit, and title would be acceptable.

There are three important factors in considering a level of decomposition:

• The purpose and type of the model level (context, analysis, design, or implementation)
• What elements are considered black boxes
• The interactions exposed and emphasized

These factors will be discussed in detail below.

Model levels and their purposes

In developing a comprehensive system-of-systems model, whether it be for an aircraft, an enterprise IT development project, or a new business unit, a major challenge is figuring out the right set of levels with which to express the model. In MDSD we identify four model levels, each with a different purpose:

• Context
• Analysis
• Design
• Implementation

The Context Model Level, which includes the top level or enterprise level of decomposition, allows the system to be seen in the context of its usage by actors and other outside systems. Often this level expresses the area over which the team has control, or one level above that. For example, if we are modeling a new kind of traffic light, we may want to start at the level of the citywide traffic system, so that we can place the traffic light in its context. Thus the citywide traffic system would be our enterprise, our level 0 and the beginning of our model. This would be part of the context model level. A complex system could have more than one level of decomposition in the context model level, but in practice there is generally only one.

The Analysis Model Level elaborates the functionality, logical structure, and distribution of the system. In this level, we create logical elements, distribution elements, and collections of system functionality, and we model their interactions. A uniqueness of this approach is that these interactions do not exist in isolation, but are derived precisely from the high-level usages of the system. The analysis model level provides an abstraction above that of actual design. No one designs or builds from an analysis level. Taking the citywide traffic system example above, an analysis level might include system elements such as the traffic signaling, traffic detection, central control, and override control, among others.

In the analysis model level, the elements we consider to be black boxes are logical and distribution elements, made up of some combination of hardware, software, people, and information. They may be as small as a single automated capability, or as large as an army. We chose them to be elements in our architecture so that we can reason about their interactions and responsibilities. The number of levels created depends on the complexity of the system.

The Design Model Level captures the interaction between "designable" elements. At this model level, elements are generally homogenous; that is, they may consist of hardware, software, or people, but not a combination of these. Through the MDSD approach, we will assign responsibility for specific operations to these elements, and the designers will use this specification to create the element.

How design proceeds depends on the type of element. Software elements can use UML and use case realization, an approach very similar to MDSD, but applied at the software design level, to create the technical design of the software. The design of an electronic component would more likely be expressed as a schematic diagram, while a "people" element might use organizational charts and skill lists.

The Implementation Model Level addresses how elements expressed in the design model level will be created in the real world. For software, this would include the structure of code modules, executables, DLLs, etc., while for hardware it might include circuit pathways, board layouts, and the like.

In MDSD we are concerned primarily with the context and analysis model levels because our main purpose is to understand the system in its context, analyze the behavior of the entire system, and arrange the work to be performed by the design-and-build teams. These design-and-build teams may use RUP for software creation, and other discipline-specific approaches for the hardware design and people design.

Black box and white box perspectives

Let's consider a little more closely the distinction between black and white box perspectives. The terms "black box" and "white box" refer to a perspective taken when approaching a system or a part of a system. To take a black box perspective means that we ignore the inner workings of the system, and focus only on the interactions with that system. Most people take such a perspective with respect to a television. They don't know or care about how the TV works or what components exist inside, only that they can interact with it via its inputs (remote control, power plug, etc.) and outputs (screen and speakers). To take a black box perspective is to pay attention only to inputs and outputs and hide or ignore all of the internals.

The act of changing the channel on the TV would simply be described by showing that the viewer presses '+' and the TV changes the channel it is currently displaying. Notice that there can be no mention of the screen or the tuner, because these are internal system elements.

A white box perspective, on the other hand, includes information about two additional aspects of the system. In addition to the inputs and outputs, a white box perspective describes:

• Internal processes and functionality
• Internal system elements

Described as a white box sequence, changing the channel on the TV would specify how the viewer presses the '+' button on the remote control, how the remote control sends an infrared signal to the TV, how the TV control interface tells the tuner to re-tune to another channel, and how the display controller presents the image of the new channel when it is tuned. Notice that doing a white box description doesn't mean the system is fully decomposed to its lowest-level elements. White box descriptions still contain abstractions which are treated as black boxes. The "TV control interface" occurs in a white box expansion at this level of decomposition, and thus is treated as a black box. At a lower level of decomposition it, too, could be described in terms of its constituent components.

It's useful to note that black and white box attributes are not inherent characteristics of an element. That is, there are no "black box elements" or "white box elements." There are only black and white box perspectives and we use both throughout the MDSD modeling process.

Interaction among elements

The most essential facet of a level of decomposition is the interactions it exposes or hides. Since each element in a level of decomposition is considered from the black box perspective only, the only interactions shown are those between them and the systems actors. Interactions with sub-elements inside these elements are hidden.

An entertaining example comes from a recent class exercise where a group modeled a commercial aircraft. At a particular level of decomposition, the aircraft appeared as an element, and was described as including the airframe, all the systems on board, and the crew. Since all of this was included in the black box designated aircraft, the model could not speak of anything inside it at this level. In describing how passengers began their travel, the model spoke of the passenger being greeted by the aircraft, and being guided to their seats by the aircraft. While it sounded odd, this is the only way to describe this behavior. Since the crew was considered part of the aircraft, the crew greeting the passenger must be described as the aircraft greeting the passenger. And, in fact, this is a valuable approach, because the design decision of whether to have flight attendants greet the passengers or to have an automated system scanning ticket stubs and greeting them has not been taken at this level of decomposition.

At the same time, what is highlighted in a level of decomposition is the interaction between the elements identified there. In the example above, it is the interaction between the passenger and the aircraft that is described. Which interactions are important to describe will be a major factor in deciding what levels of decomposition to use. Take the case of the pilot in our commercial aircraft. Is the pilot part of the system of the aircraft or outside the system? Each is a completely valid way of modeling the system, but which we choose depends on which interactions are important. If what's important is how the pilot interacts with the aircraft -- i.e., treating the aircraft as a black box, and using some kind of interface to the entire aircraft -- then this would support making the pilot a separate entity at the level of the aircraft. This would allow us to describe the interaction between the pilot and the aircraft as a black box interaction. On the other hand, it may make more sense to think of the pilot and the aircraft together as a single system element -- thus emphasizing, say, the control tower's interaction with the aircraft-including-pilot element. For several reasons, this is probably the better approach. If we are designing aircraft, then we are probably more interested in how the aircraft as a whole (including its crew) interacts with elements outside it such as the control tower, passengers, and gate crew.

It probably makes more sense to think of the pilot as interacting with the elements or subsystems within the aircraft, not with the aircraft as a whole. Thus we would put the pilot as a separate element at a lower level of decomposition where the aircraft itself appears as a number of separate elements along with the pilot.

In practice, this judgment about what to set as elements in your architecture comes mainly from experience in the domain. Choosing these elements is a key part of designing the system architecture.

Integration with RUP

MDSD has not been added as a separate discipline within RUP, which underscores the unified nature of the teams, and the unified nature of the process.

RUP, without the MDSD plug-in, is a process for software engineering. RUP with the MDSD plug-in is a systems engineering process for which software engineering (via RUP) then becomes a subset.

The default RUP disciplines (business modeling, requirements, analysis and design, implementation, test, deployment) and the supporting disciplines (configuration and change management, project management, and environment) are as much part of the fabric of systems engineering as software engineering. MDSD adds new tasks, artifacts, and activities and modifies some existing ones to provide support for the wider scope of lifecycle development and the additional concerns of systems engineering.

Systems Engineering is not obviously delineated as a separate discipline on the RUP Website. MDSD inclusive of the existing RUP disciplines is, however, a Systems Engineering lifecycle process.

It is also important to understand the way the MDSD plug-in is articulated with respect to the rest of RUP. MDSD expects that systems are composed of subsystems, which in turn might be composed of subsystems, and so on. Systems, within the context of MDSD, are defined as and dealt with as systems of systems.

RUP with the MDSD extension is applicable at any level in the systems of systems hierarchy, including the lowest level, at which, at least for software, the behavior of a subsystem is realized by collaborations of software objects (and links). Note that a subsystem development effort, viewed from the level of its developers, is like the total system development in its process needs: that is, it needs to have an Inception phase, Elaboration phase, and so on. So, if you look at the overall system development plan, you find the RUP sequence of phases, then looking "inside" you find a number of RUP evolutions or lifecycles, one for each subsystem.

Top-level activities are simply rolled-up from the lower levels. There are requirements, design, and other activities at each level, along with separate logical plans. This permits one to describe the process simply, but still be able to construct plans of arbitrary complexity by recursive application of the RUP lifecycle. At any level, you then choose the activities, tasks, and steps within the tasks, appropriate to your purpose.

Capability Maturity Model Integration (CMMI) for Development

MDSD supports the CMMI-DEV v1.2 process model which characterizes systems engineering and systems engineers as follows:

"The interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a product solution and to support that solution throughout the product's life. (See also "hardware engineering" and "software engineering.")

This includes the definition of technical performance measures, the integration of engineering specialties toward the establishment of a product architecture, and the definition of supporting lifecycle processes that balance cost, performance, and schedule objectives." ³

A system -- which might contain hardware (computational and non-computational), software, and human workers -- delivers needed operational capability to its users and might itself require supporting systems for successful operation. Systems engineering has to consider not only the specification and creation of a product, but also the in-service support of that product (for example, its maintenance) to ensure its continued utility.

This view of a system extends the view at the core of RUP, where "system" is used to mean software and the computational hardware on which it runs. Additionally, it is likely the case that most applications of MDSD will be to large development efforts, where the subsystems into which the system is decomposed are themselves complex enough to be regarded as systems, with the implication that RUP (or MDSD) could be reapplied, in total, to their development.

A Systems Engineering process has, then, to be able to deal with systems that are arbitrarily complex and large, and which require a multidisciplinary approach in their construction, deployment, and support. The whitepaper The Rational Unified Process for Systems Engineering ⁴ describes the motivation for the development of RUP for Systems Engineering (RUP SE). As an evolution of RUP SE, MDSD extends the process model to address the problems of size and complexity (in the user needs and requirements as well as design), quality of service, and other engineering specialties that are faced by the systems engineer.

The MDSD plug-in is also of interest to the managers of a systems development project, as well as those concerned with system analysis and specification, system architecture, implementation, and test.

Notes

¹ INCOSE Systems Engineering Handbook, INCOSE-TP-2003-002-03.1, August 2007.

² For the complete text of this consensus statement, see http://www.incose.org/practice/fellowsconsensus.aspx

³ For the complete context of this quoted material, see the CMMI page at http://www.sei.cmu.edu/cmmi/faq/cov-faq.html

⁴ Rational Unified Process for Systems Engineering, Murray Cantor, Copyright IBM Rational Software, 2003.

Resources

Learn

• To learn more about RUP, visit the Rational Method Composer and RUP resource area on developerWorks Rational. You'll find technical documentation, how-to articles, education, downloads, product information, and more.
  
  
• Read the IBM Whitepaper: Best practices for software and systems development and delivery.
  
  

Get products and technologies

• Download the RUP for Model-Driven Systems Development Plug-in V4.0 from developerWorks Rational.
  
  
• For a complete list of available plug-ins for Rational Method Composer V7.2, visit the RMC 7.2 plug-ins page on developerWorks Rational.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Participate in the Rational Method Composer and RUP discussion forum.
  
  
• A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
  
  
• Global Rational User Group Community
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Models and abstraction
• Levels of decomposition
• Integration with RUP
• Capability Maturity Model Integration (CMMI) for Development
• Notes
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers