Integrating Architecture Methods: The Case of the Rational Unified Process

NEWS AT SEI

Authors

Rick Kazman

Robert Nord

This library item is related to the following area(s) of work:

Software Architecture

This article was originally published in News at SEI on: March 1, 2004

In a previous column (Rethinking the Software Life Cycle), we took a look at the traditional software-development life cycle in the context of the architecture-centric methods that we have developed at the Carnegie Mellon Software Engineering Institute (SEI) over the past 10 years. These methods include the Architecture Tradeoff Analysis Method(ATAM) [Clements 02], the SEI Quality Attribute Workshop (QAW) [Barbacci 03], the SEI Attribute-Driven Design (ADD) Method [Bass 03], the SEI Cost Benefit Analysis Method (CBAM) [Bass 03], and SEI Active Reviews for Intermediate Design (ARID) [Clements 02]. This column shows how these architecture-centric methods fit into the framework of the Rational Unified Process (RUP).

The SEI’s architecture-centric methods were developed at the same time that the RUP was being developed. The RUP is an object-oriented development framework. It provides guidelines, templates, and examples for all aspects and stages of a software-intensive system’s life cycle, although it treats software architecture obliquely.

The SEI’s architecture-centric methods have long demonstrated that they can illuminate important characteristics of architectures and the quality-attribute requirements that shape them. Until now, such considerations have been relegated to a separate “supplementary requirements” document in the RUP. Also, business drivers, long a key part of SEI methods, have just recently found a place in the RUP.

The SEI architecture-centric methods can provide explicit and detailed guidance on eliciting the architectural requirements, on designing the architecture, and on analyzing the resulting design.

  • The architecture-centric methods place an emphasis on quality attributes rather than functionality.
  • The architecture-centric methods help fill gaps in the RUP design process by providing specific advice on
    • the elicitation and documentation of quality-attribute requirements
    • which design operation will achieve a desired quality-attribute response
    • how to understand and predict the consequences of the design decisions in terms of risks, tradeoffs, and ultimately return on investment
  • The architecture-centric methods all use common concepts: quality attributes, architectural tactics, and a “views and beyond” approach to documentation that leads to increasingly efficient and synergistic use [Clements 03].

Table 1 shows where specific SEI architecture-centric methods can help to produce artifacts required in different RUP phases, or how the methods can enhance the activities of the RUP. More details are available in a forthcoming technical report [Kazman 04].

Table 1 :    The Architecture-Centric Methods as RUP Activities

Method

Role

Discipline

Workflow Detail

Artifacts Affected

QAW

System
analyst

Requirements

Understand Stakeholder Needs

Business case
Supplementary specifications

ADD

Software
architect

Analysis &
Design

Define a Candidate Architecture
Perform Architectural Synthesis

Software architecture document

ATAM/
CBAM

Technical
reviewer

Analysis &
Design

Refine the Architecture

Review record
Software architecture document

ARID

Technical reviewer

Analysis &
Design

Refine the Architecture
Analyze Behavior

Review record

Through the process of the QAW, vague requirements would be refined into several quality-attribute scenarios. The ADD Method defines a software architecture by basing the design process on the quality-attribute requirements of the system. The ADD approach follows a recursive decomposition process where, at each stage in the decomposition, design decisions are made to satisfy a chosen set of high-priority quality scenarios.

It is clear that design decisions interact. For this reason, we need an organized method for understanding the interaction of the many decisions that are made in creating a complex system architecture. The ATAM provides software architects with a framework for understanding the technical tradeoffs and risks that they face when making architectural design decisions. In addition, the CBAM helps software architects consider the return on investment of any architectural decision and provides guidance on the economic tradeoffs involved. Finally, the ARID evaluates whether the design can be used by the software engineers who must work with it.

The benefit of including the SEI methods is to address quality attributes in an explicit, methodical way. Quality-attribute requirements drive the software architecture, and architecture-centric activities (with an explicit focus on quality attributes) drive the software system life cycle. Properly managed, the architecture-centric methods can be a low-cost addition to the RUP that will increase the quality of the systems and products developed.

References

[Barbacci 03]
Barbacci, M. R.; Ellison, R.; Lattanze, A. J.; Stafford, J. A.; Weinstock, C. B.; & Wood, W. G. Quality Attribute Workshops (QAWs), Third Edition (CMU/SEI-2003-TR-016). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.

[Bass 03]
Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nd edition. Boston, MA: Addison-Wesley, 2003.

[Clements 02]
Clements, P.; Kazman, R.; & Klein, M. Evaluating Software Architectures: Methods and Case Studies. Boston, MA: Addison-Wesley, 2002.

 [Clements 03]
Clements, P.; Bachmann, F.; Bass, L.; Garlan, D.; Ivers, J.; Little, R.; Nord, R.; & Stafford, J. Documenting Software Architectures: Views and Beyond. Boston, MA: Addison-Wesley, 2003.

[Kazman 04]
Kazman, R.; Kruchten, P.; Nord, R.L.; Tomayko, J. E. Integrating Software Architecture-Centric Methods into the Rational Unified Process (CMU/SEI-2004-TR-011). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2004.

About the Authors

Rick Kazman is a senior member of the technical staff at the SEI, where he is a technical lead in the Architecture Tradeoff Analysis Initiative. He is also an adjunct professor at the Universities of Waterloo and Toronto. His primary research interests within software engineering are software architecture, design tools, and software visualization. He is the author of more than 50 papers and co-author of several books, including a book recently published by Addison-Wesley titled Software Architecture in Practice. Kazman received a BA and MMath from the University of Waterloo, an MA from York University, and a PhD from Carnegie Mellon University.

Robert L. Nord is a senior member of the technical staff in the Product Line Systems Program at the Software Engineering Institute (SEI) where he works to develop and communicate effective methods and practices for software architecture. Prior to joining the SEI, he was a member of the software architecture program at Siemens, where he balanced research in software architecture with work in designing and evaluating large-scale systems. He earned a Ph.D. in Computer Science from Carnegie Mellon University. Dr. Nord lectures on architecture-centric approaches. He is co-author of Applied Software Architecture and Documenting Software Architectures: Views and Beyond.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us

info@sei.cmu.edu

412-268-5800

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.