S O F T WA R E T E C H N O L O G I E S
Bridging the Software Architecture Gap Mikael Lindvall, Fraunhofer Center for Experimental Software Engineering Dirk Muthig, Fraunhofer Institute for Experimental Software Engineering
The SAVE tool helps developers align a system with the planned architecture.
T
here’s a growing gap between the state of the art and the state of the practice in software architecture. The state of the art revolves around advanced architecture description and modeling languages, while in practice, the software architect—if there is one— has neither the power nor the tools to create a sound software architecture that is truly useful throughout the entire software life cycle. Actually, in most cases there’s no documented software architecture at all. The reason is that most software projects are small enough, at least initially, that they can survive without much upfront design. Sometimes the software project team recognizes the importance of software architecture and produces architecture diagrams, but these PowerPoint boxes and arrows seldom have much to do with the actual implementation of the software. Thus, the effort invested in dividing the software into components, layers, and other architectural constructs has little practical value.
ture with decoupled layers, components, and rules governing how software entities are structured and how they communicate with one another. This lack of an explicit connection between the software architecture and the source code is difficult to overcome and makes it hard for anyone to understand exactly how the software system works and where changes belong. This is especially true for code written by somebody else, and in long-lived systems, software developers work on somebody else’s code all the time. This problem is exacerbated in distributed development where it’s even more difficult to get access to detailed information about the software and its underlying rationale.
Vision In a few instances, where the implementation indeed matches the original architecture, there’s typically no cost-effective way to continuously keep the implementation in sync with the architecture. As the software undergoes changes due to new requirements, it increasingly deviates from the intended architecture. In all cases, the software easily becomes a maintenance nightmare. Understanding how new requirements might impact the software becomes very difficult, and other predictions based on the architecture become invalid as well. Another problem is that reusing software components becomes almost impossible. There are many examples of software product lines and attempts to reuse software that failed because of degenerated software. Most software developers are very smart people who understand every aspect of every line of code they write. The problem is that even if the source code is of high quality, it doesn’t necessarily translate into a high-quality software architec-
For any software system large enough to require more than one developer, an architecture is critical. As a result, we’re researching viable ways to understand, design, maintain, change, and check the software system’s architecture. We envision a practical environment that clearly connects the architecture, architectural rules and constraints, and implementation of the system throughout the entire software life cycle. Software developers will model important aspects of the software architecture such as built-in flexibility and variability and how architectural styles, patterns, and rules contribute to these goals. The architecture will drive development and evolution of the software system. For example, software developers will be able to divide up work based on the architecture and verify that the implementation meets the goals defined by the architect. The architect will in turn be able to check that the different components integrate well with the system. This environment will also let developers simulate and test nonfunctional requirements, and June 2008
93
S O F T WA R E T E C H N O L O G I E S
automatically generate most source code once the models pass all tests. We’ve participated in many software system assessments in which quality problems led to unpleasant disagreements between the main developer and the subcontractors. These disagreements could, in most cases, be traced to massive inconsistencies between the architecture provided by the subcontractors and the implementation that was actually delivered to the main developer. To detect and remove such inconsistencies as early as possible and to begin realize our vision, we’ve developed a Software Architecture Visualization and Evaluation tool and process.
SAVE tool
SAVE automatically extracts and visualizes the architecture manifested in the source code using module-type views and compares it with user-specified models and rules representing the structure of the intended architecture. It can, for example, detect extensive coupling and strong dependencies on commercial off-the-shelf (COTS) components or libraries. The tool can also help developers understand, rearchitect, reuse, and create more maintainable software. In addition, SAVE can help determine the software’s product-line potential in terms of architectural commonalities and deviations between different software products. The tool makes reviews more efficient by providing a high-level picture of the software and identifying those areas needing more attention. For example, SAVE reveals that applying a compliancechecking approach decreases the number of architectural violations significantly, and that remaining, difficult-to-remove violations are explicitly documented exceptions (and thus part of the architectural description). The tool primarily analyzes C/C++ and Java code, but it also works with Ada, Delphi, Fortran, and Simulink. 94
Computer
SAVE process
For any tool to be useful, it must have a well-defined process. The SAVE process consists of six steps.
Step 1
The first step is to capture and model the planned architecture. Because many software architectures are relatively poorly documented, this step often draws on knowledge from architects and lead developers. SAVE uses information about architecture goals, styles, and components as well as some high-level design patterns to model the structure of the planned architecture using a simple built-in editor based on Unified Modeling Language notation.
SAVE can help developers understand, rearchitect, reuse, and create more maintainable software. Step 2
The next step is to extract the actual architecture, which is an abstraction of the code structure and its dependencies, from the source code. SAVE automatically creates diagrams based on the user-specified “zoom” level, enabling analysts to drill down all the way to the source code to inspect components and couplings.
Step 3
The third step is to map the components in the actual architecture to those in the planned architecture. SAVE accomplishes this using a simple mapping editor. The mapping is manual and also draws on knowledge from architects and lead developers, but typically doesn’t take much time to complete. For example, all sourcecode class files named “client” can be mapped to the client subsystem using a regular expression.
Step 4
The fourth step is to automatically compare the actual architec-
ture with the planned one based on the mapping. SAVE flags each item in the actual architecture that doesn’t match an item in the planned architecture. For example, a typical violation of the layered architecture style is the existence of couplings from lower to higher layers. Another is the dependence of libraries and other common assets on application-oriented components. A third violation is the insufficient insulation of COTS components, which makes it difficult to replace such components with others.
Step 5
The fifth step is to analyze each deviation to determine whether it’s critical. This step is manual but relatively efficient given the tool’s ability to drill down to the source code. The deviations described above are generally regarded as critical, whereas import/include statements that are never used are considered harmless.
Step 6
The last step is to define a plan for removing the violations deemed critical. In most of the systems we’ve analyzed, the number of violations was small enough that they could be removed relatively easily. However, that isn’t always the case. For example, we identified more than 5,000 violations in one large system, and in another we found a large set of duplicated source-code files infected with bugs. Removing 5,000 violations or removing duplicated buggy code translates into a large reengineering effort. In such a case, it’s necessary to first develop a new target architecture and then refactor the existing code into it.
Example
We applied SAVE to a system called the Visual Query Interface that degenerated because new programmers made changes without following the architecture guidelines. Figure 1a illustrates the VQI software’s planned architecture,
Package viewer
Cache
Logger
Web
HIS
Hyperwave server
Server stub
Stand-alone server WebVQI server
Main mediator
VQI
Mainframe
Editor
Connector
Package viewer
Cache
Logger
Web
(a)
HIS
Hyperwave server
Server stub
Stand-alone server
Connector
WebVQI server
Main mediator
VQI
Mainframe
Editor
(b)
Figure 1. SAVE tool. (a) Example planned architecture. (b) Example actual architecture as visualized by SAVE.
which is based on the client-server architectural style and the mediator design pattern. In this case, the task was to Web-enable the system by adding the “Web” component shown in the dotted box. The planned architecture specifies that only the main mediator should know the Web component. Figure 1b is a snapshot obtained from the SAVE tool indicating how the solution violated the planned architecture with additional connections between components. These additional connections, highlighted in orange, threaten the maintainability of the software by making it harder than necessary to both understand the architecture and add new components. Thus, performing what should be a relatively straightforward task—adding some new functionality—caused the architecture to degenerate substantially. By using
SAVE, we’re able to identify and remove such undesirable connections while keeping the intended functionality intact.
R&D activities
The current SAVE tool is a mature research prototype that we’ve applied to many types of industrial systems including digital cameras, automotive embedded software, ground control systems, space networks, and flight software. The results from these studies are promising and have helped us to reason about and improve the analyzed software systems from a structural point of view. We continue to conduct R&D with strategic government and industry partners to get SAVE closer to our vision. We’re already in the process of practically testing new dynamic and forward-engineering capabilities as well as integrating
the tool with behavior-modeling technologies. In a project supported by NASA’s Software Assurance Research Program, we’re exploring ways to combine analysis of static and dynamic information in SAVE. While static analysis is easier to perform, it doesn’t detect dynamic structures that are more related to the conceptual architecture. By adding information collected from the system during execution, we can add new view types that give the architect practical ways to analyze and understand the software. Another R&D activity adds forward-engineering capabilities to SAVE. This will let software architects first specify the planned architecture and then allocate components to individual developers. During development, project members will be able to monitor and detect architecture violations June 2008
95
S O F T WA R E T E C H N O L O G I E S
so that they can avoid such violations before they get committed. This feedback prevents the massive amount of rework that sometimes is required when evaluation occurs only after development is complete. We’re also working on integrating SAVE with advanced behavior-modeling technologies based on Simulink and Reactis, which are successfully used in the embedded-software industry. For example, we’re investigating how these technologies can increase productivity as well as software quality via automated test-case generation. The most recent R&D activity is to add requirements traceability capabilities to SAVE. We’re researching information-retrieval technologies as a way to suggest traceability links from requirements to the architecture extracted by SAVE, and further to the source code. This will help analysts determine where a certain requirement is implemented as well as the amount of software change needed for a modified requirement.
96
Computer
M
ost software systems are too complex to understand by reading the source code. Such systems must instead be analyzed and controlled at the architectural level. This is especially true for software developed in distributed organizations because of the added complexity distributed development brings. Therefore, we believe that the future of software development is architecture-centric and based on models. We’re actively conducting R&D to reach that goal using a bottomup approach. The first component of that vision is the SAVE tool that helps software architects and developers understand the structure and other aspects of their system and keep it aligned with the planned architecture. The tool connects the abstract architecture to the implementation and thus directly connects developers with the architecture and its implications in their daily work. The next step is to continue bridging the architecture gap by adding
support for developers when they’re initially architecting the software. Such support will prevent both structural and behavioral architecture violations from entering the system at all. ■ Mikael Lindvall is director of the Software Architecture and Embedded Systems division at the Fraunhofer Center for Experimental Software Engineering, College Park, Maryland. Contact him at
[email protected]. Dirk Muthig manages the Software Development division at the Fraunhofer Institute for Experimental Software Engineering, Kaiserslautern, Germany. Contact him at dirk.
[email protected].
Editor: Mike Hinchey, Lero—The Irish Software Engineering Research Centre;
[email protected]
