NEWS AT SEI
This article was originally published in News at SEI on: December 1, 1998
In the previous release of news@sei, Mario Barbacci compared software architecture with more traditional architectural and engineering practices. In this column, I will both take the analogy a little bit farther and also begin to discriminate software architecture and architectural engineering from "traditional" forms of architecture and engineering in terms of the specific needs for representing software and system architectures.
It is first useful to consider the question: Why should one bother to design and use a software or system architecture?1
Fundamentally, there are three reasons why software architecture is important to large, complex, software-intensive systems :
Communication among stakeholders. Software architecture represents a common high-level abstraction of a system that most if not all of the system’s stakeholders can use as a basis for creating mutual understanding, forming consensus, and communicating with each other.
Early design decisions. The software architecture of a system is the earliest artifact that enables the priorities among competing concerns to be analyzed, and it is the artifact that manifests the concerns as system qualities. The tradeoffs between performance and security, between maintainability and reliability, and between the cost of the current development effort and the cost of future developments are all manifested in the architecture.
Transferable abstraction of a system. Software architecture constitutes a relatively small, intellectually graspable model for how a system is structured and how its components work together—this model is transferable across systems; in particular, it can be applied to other systems exhibiting similar requirements and can promote large-scale reuse.
If we believe in these reasons, then it is immediately obvious that the way that we represent the software architecture is of crucial importance, because the representation will affect how well the architecture serves as a communication vehicle, how well it conveys early design decisions, and how accurately it describes the system’s key abstractions. Thus, the clarity, completeness, and precision of the architectural representation are of key importance.
Clarity is important to support communication. Completeness and precision are needed to support analysis.
We have now introduced a new concept to the picture: analysis. Engineering representations, in any field, serve to support analysis. Structural engineers, for example, might analyze the strength and bending properties of the materials that they use to construct a building, to determine if a roof will withstand an anticipated snow load, or if the walls will crumble in an earthquake.
So too with software architecture. As architects, we need to be able to understand whether a system, as it is designed, will support the anticipated volume of user requests within some acceptable latency bounds. We need to be able to know that anticipated changes to the system can be made within reasonable time and budget constraints. And so forth. Consequently, we must understand what it is that we need to analyze before we can decide what to represent.
Software has many possible representations. In the software architecture community, these representations are known as views or structures. Some of the most common and useful are
conceptual/logical: The units of this view are abstractions of the system’s functional requirements. These abstractions are related by the "shares data with" relation. This view is useful for understanding the interactions among entities in the problem space, and their variation.
process: This structure deals with the dynamic aspects of a running system. The units of the view are processes or threads. Relations represented by the links include "synchronizes with," "can’t run without," "can’t run with," "preempts," or any of several other relations dealing with process synchronization and concurrency.
physical: This structure shows the mapping of software onto hardware. It is particularly of interest when dealing with distributed or parallel systems. The components are hardware entities (processors, sensors) and the links are communication pathways (typically networks). Relations between the processors are "communicates with." This view allows an engineer to reason about performance, availability, and security.
module: The units are work assignments and have products (such as interface specifications, code, test plans, etc.) associated with them. They are linked together by the "is a submodule of" relation. Module structure is used to allocate a project’s labor and other resources during maintenance as well as development.
uses: The units of this view are procedures or modules; they are linked by the "assumes the correct presence of" relation. Uses structure is used to engineer systems for which it is easy to create extensions or subsets. One might want to do this to create different-"strength" versions of a product for different markets or to make use of an incremental-build approach to integration.
calls: The units of this structure are procedures or methods; they are related by the "calls" or "invokes" relation. The relations are characterized by their interfaces. The calls structure is used to trace the flow of execution in a program.
data flow: The units of this view are programs or modules; the relation is "may send data to." The links are labelled with the name of the data transmitted. The data-flow view is most useful for requirements traceability.
control flow: The units of this view are programs, or modules; the relation is "activates" or "becomes active after." This view is useful for verifying the functional behavior of the system as well as for understanding timing and ordering properties. If the only mechanism for transferring control is procedure call, then this view is identical to the calls structure.
class: Units of this structure are classes. The most common relation between the classes is "inherits from." This view supports reasoning about collections of similar behavior (i.e., the classes that other classes inherit from), and parameterized differences from the core, which are captured by sub-classing.
Note that we have used both terms "structure" and "view" in the above list. This is intentional. But we do not use them interchangeably. A structure defines a unique set of components and connectors. A view is simply that: a particular view of some structure or structures. An analogy can be found with relational databases. There is some information that can be found in the tables of the databases. These are the database’s structures. One can then select and compose any number of views on top of this structure, to extract from the database particular information that is of importance.
Now, what is the connection between these views and structures and the analysis of software and system architectures? Quite simply, the views must carry sufficient information to support analysis. Another way of saying this is that they must be appropriately annotated to support analysis. For example, to support a performance analysis, the process view of a system must include information about process priorities, scheduling policies, queuing policies, and processing times. In addition, information about CPU speeds, network bandwidths, sensor rates, memory sizes, and the allocation of processes to hardware will be needed from the physical view to complete this analysis. At the SEI, we are currently working on a set of architectural-representation requirements—with an eye to supporting analysis—and we expect to publish this as a technical report in early 1999.
One final point: given that it is important to represent software architectures and that there is so much information to be represented, a natural question is "What tools exist to aid in this representation?" While many tools—both academic and commercial—exist, none of them is currently satisfactory in that they cannot represent even the incomplete list of views and structures that we presented here. Some partial solutions do exist however. UML (Unified Modeling Language) is currently becoming an industry standard for software representation, and there is great interest in extending UML to support architectural concepts. And commercial tools are beginning to extend themselves to incorporate architectural notions; so there is hope.
 L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998.
1 While we say software architecture we are almost always talking about system architecture for software-intensive systems.
About the Author
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 over 50 papers and co-author of several books, including a book recently published by Addison-Wesley entitled 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.
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.