The new, improved RUP SE architecture framework

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

Dave Brown, Global Community of Practice Lead, IBM Rational
Jim Densmore, Consulting Technical Services Specialist, IBM Rational

15 Jun 2005

from The Rational Edge: This article summarizes recent improvements to the RUP SE architecture framework, an essential element of the systems engineering plug-in for the IBM Rational Unified Process, or RUP. It explains concepts underlying the framework's main components: example viewpoints and model levels.

For more than five years, IBM Rational clients have been applying the Systems Engineering Plug-In to the IBM Rational Unified Process -- also known as RUP SE -- to their programs. During this time we have learned many lessons and revised some of the plug-in's key elements, including the architecture framework. This article provides an up-to-date view of the framework¹, reflecting ongoing improvements that we discovered through client engagements.

Overview of the RUP SE architecture framework

The RUP SE architecture framework provides the following support for constructing a sound architecture:

• Separation of concerns. Designers can address each set of stakeholder concerns independently.
  
  
• Integration of concerns. The framework enforces integration by requiring the use of a common set of design elements across multiple sets of concerns.
  
  
• System decomposition (different from functional decomposition). The framework provides levels of structure that allow parallel development to proceed.

Table 1 illustrates the RUP SE architecture framework, representing viewpoints as columns and model levels as rows (see sidebar "Definitions for the RUP SE Plug-In").

Table 1: The RUP SE architecture framework

It is important to remember that the framework is simply a way to describe the underlying architectural model, which remains a cohesive, consistent repository. Multiple, overlapping views within the framework express subsets of this model.

Definitions for the RUP SE Plug-In As some of these terms have other, possibly conflicting, definitions, it is important to understand how we use them in the context of the RUP SE Plug-In. Artifact. Any item that describes the architecture, including a diagram, matrix, text document, or the like. System. An encapsulated, physical entity that provides a set of services. This could be an enterprise architecture, a business organization, or a product (e.g., ship, ground station, software program). The system is the subject of the development activity. Architecture model. A collection of all the artifacts that describe the system. Model level. A subset of the architecture model that represents a certain level of specificity (abstract to concrete); lower levels capture more specific technology choices. Note that model levels are not levels of abstraction; in fact, a model level may contain multiple levels of abstraction. Viewpoint. A subset of the architecture model that addresses a certain set of engineering concerns. The same artifact may appear in more than one viewpoint. There is no standard set of viewpoints; engineering concerns relevant to the development effort dictate what viewpoints are needed. View. The set of artifacts at a certain level of specificity (model level) that addresses a certain set of concerns (viewpoint). In a matrix in which viewpoints are represented by columns and model levels by rows, views are the cells at the intersections. Transform. To create one level of specificity (model level) from another.

Back to top

Model levels in the RUP SE architecture framework

Model levels are a way of grouping artifacts with a similar level of detail. The Context level treats the entire system as a single entity: a black box. It does not address the system's internal elements.

At the Analysis level, we begin seeing the system's internal elements, describing domain elements at a relatively high level. These elements vary, depending on which viewpoint we are in. For example, in the Logical viewpoint, we create subsystems to represent abstract, high-level elements of functionality. Less abstract elements are represented as sub-subsystems or classes. In the Physical viewpoint, we create localities to represent the places in which functionality is distributed.

The Design level is where we capture design decisions that will drive the implementation. In going from Analysis to Design, we transform subsystems / classes and localities into hardware, software, and worker designs. This is not a direct mapping; we are making design decisions about how the functionality represented in the subsystems and classes will be allocated. Factored into these design decisions are considerations for supplementary requirements and distribution represented by the localities. The resulting design must realize all of the specifications from the Analysis level. In other words, when we were designing the system at the Analysis level, we were creating requirements that the Design level must satisfy.

The Implementation level is where we capture decisions about technology choices for implementation. We can specify commercial products (e.g., a messaging middleware software product or a model / part # for a piece of hardware) or items for internal implementation. Again, going from the Design level to the Implementation level is a transformation, but this time the mapping is more direct. For the Design-level worker, the mapping is to a position specification with a defined set of skills. Then, we can fulfill the specification by either hiring someone with the correct skill set (similar to choosing a commercial product with certain capabilities) or training an individual to acquire the required skills (similar to doing an internal implementation).

Table 2 describes model levels expressed in the framework.

Table 2: Model levels in the RUP SE architecture framework

Back to top

Viewpoints in the RUP SE architecture framework

Viewpoints allow framework users not only to separately address different stakeholders' concerns but also to maintain an integrated, consistent representation of the underlying design. Our original, minimal set of viewpoints has grown over time. In addition, we have confirmed that most development efforts do not require every viewpoint. In fact, there is no finite set of viewpoints. Viewpoints are mechanisms to address program stakeholders' needs. Each program has a unique set of stakeholders, and therefore a unique set of appropriate viewpoints. We use general terms (such as those identified in the framework) to identify a type of viewpoint, but each viewpoint's specific content is driven by the stakeholders' unique concerns on a particular development effort. Nevertheless, the viewpoint descriptions in the framework are useful, because they enable us to talk about the approach in general terms.

We have also learned that a particular viewpoint may not be useful at all model levels. For example, hardware developers are a category of (internal) program stakeholders concerned with the allocation of functionality and distribution of hardware within the system. However, at the Analysis model level, decisions about where functionality will be implemented -- in hardware, software, or workers -- have not yet been made. So there is typically no need for a hardware viewpoint at the Analysis level. However, if the system involves actual hardware development, then we certainly do need a hardware viewpoint at the more specific (lower) model levels.

Table 3 describes example viewpoints expressed in the framework.

Table 3: Example viewpoints in the RUP SE architecture framework

Although different architectures require different sets of viewpoints, almost all require the logical and physical viewpoints.

Back to top

Conclusion

The RUP SE approach will continue to evolve and improve, based on the experience and feedback we harvest from clients who have applied it. Significant changes to the RUP SE architecture framework have already made it an even more useful mechanism for describing development artifacts captured in the architecture model. Although the framework cannot possibly identify the unique viewpoints required for every program, it does provide general viewpoint descriptions that can be tailored to individual program needs.

Our RUP SE content will grow more detailed as we continue to receive contributions from practitioners. If you would like to send suggestions or feedback, please use the comments box in the "Rate this article" section below.

Back to top

Notes

¹ This article does not address all details of RUP SE or its application. For a more in-depth look at capabilities, please refer to The Rational Edge series by Murray Cantor:

• "Rational Unified Process for Systems Engineering -- Part I: Introducing RUP SE Version 2.0," August 2003.
  
  
• "Rational Unified Process for Systems Engineering -- Part II: System Architecture," September 2003.
  
  
• "Rational Unified Process for Systems Engineering -- Part III: Requirements Analysis and Design," October 2003
  
  

About the authors

		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.

		Jim Densmore is a consulting technical services specialist with IBM Rational. His responsibilities include enabling clients in the areas of organizational transformation and the engineering of complex systems. Before joining Rational as a sales team tech rep in 2000, he spent more than twenty years involved in the architecture, design, and development of high-fidelity, real-time combat simulations and real-time telecommunications software. He holds a BA from the University of California, Los Angeles, and an MS in computer science from the University of Maryland.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

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

Back to top