Archives

Get monthly notifications of updates to news@sei features and columns

Contact the Editor

SEI Technical Reports

SEI Events

SEI Home

columns the architect

The Architect
ArchE—the Architecture Expert [2007 | 5]
Len Bass

The Architecture Expert (ArchE) tool is an experimental assistant to the architect that the SEI has been developing for several years. With the current release of Version 2.1, it is available for non-commercial use.

One of the SEI’s axioms is that quality-attribute requirements such as those for security, performance, modifiability, usability, and so forth have a dominant influence on a software architecture. A reasonable question in light of this axiom is “How can quality-attribute knowledge be codified to help the architect during the design process?” ArchE is a system that embodies our efforts to codify quality-attribute knowledge.

ArchE is based on four different concepts:

  1. Quality-attribute scenarios. ArchE requires that quality-attribute scenarios be specified in a six-part formal structure involving a stimulus, a stimulus source, an environment, an artifact being stimulated, a response, and a response measure.
  2. Responsibilities. Activities within the system being designed are represented by responsibilities. As the design process progresses, responsibilities are added, split, or modified to support the achievement of particular quality-attribute requirements.
  3. Reasoning frameworks. Quality-attribute knowledge is encapsulated into reasoning frameworks. A reasoning framework includes abstracting relevant quality-attribute knowledge from an architecture, evaluating whether the architecture meets the requirements for that quality attribute, and proposing tactics as improvement mechanisms.
  4. Architectural tactics. An architectural tactic is a means of satisfying a quality-attribute response by manipulating some aspect of the architecture.

One analogy for ArchE is tax preparation software. That is, tax preparation software encapsulates a great deal of knowledge about the structure of the tax code and has the ability to check for consistency, but the information on which the tax return is based and the correctness of the resulting return depend on the information provided by the user. ArchE has knowledge of quality attributes and how to relate quality requirements to architecture design, but has no knowledge of the semantics of the system being designed. The architect must provide ArchE with information about system semantics.

To use ArchE during the design process, the architect provides design knowledge and judgment, and ArchE provides quality-attribute knowledge. The dialogue between the architect and ArchE proceeds as follows:

Version 2.1 of ArchE is now available online. It includes quality-attribute knowledge about modifiability and real-time performance. It has been used successfully in a graduate-level software architecture class at Clemson University. ArchE depends on the following software, which is all freely available for non-commercial use:

The target audience for this release includes educators who want to incorporate software architecture design concepts into their classes and others who are interested in exploring the use of tactics within an architecture-design process.

If you are interested in using ArchE on a commercial project, contact Greg Such at gsuch@sei.cmu.edu.

If you are interested in downloading a copy of ArchE, visit http://www.sei.cmu.edu/architecture/arche.html to get started.

About the Author

Len Bass is a senior member of the technical staff at the Software Engineering Institute who participates in the High Dependability Computing Program. He has written two award-winning books on software architecture as well as several other books and numerous papers in a wide variety of areas of computer science and software engineering. He is currently working on techniques for the methodical design of software architectures and to understand how to support usability through software architecture. He has been involved in the development of numerous production or research software systems ranging from operating systems to database management systems to automotive systems.

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.

Return to COLUMNS list

 



Terms of Use
Copyright © 2008 Carnegie Mellon University