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.

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

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Overview of the RUP SE architecture framework
• Model levels in the RUP SE architecture framework
• Viewpoints in the RUP SE architecture framework
• Conclusion
• Notes
• About the authors
• 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

Try Rational System Architect

See how this fully integrated collection of models and documents can help you better align your IT systems and infrastructure to simplify business processes

Special offers