Robert W. Schwanke

An intelligent tool for re-engineering software modularity

The author describes a software tool that provides heuristic modularization advice for improving existing code. A heuristic design similarity measure is defined, based on the Parna information hiding principle. The measure supports two services: clustering, which identifies groups of related procedures, and maverick analysis, which identifies individual procedures that appear to be in the wrong module. The tool has already provided useful advice in several real programming projects. The tool will soon incorporate an automatic tuning method, which allows the tool to learn from its mistakes, adapting its advice to the architects preferences. A preliminary experiment demonstrates that the automatically tuned similarity function can assign procedures to modules very accurately.<<ETX>>

Cross references are features

When a software system is developed by a large team of programmers, and has matured’ for several years, changes to the code may introduce unexpected interactions between diverse parts of the system. This occurs because the system has become too large for one person to fully understand, and the original design documentation has become obsolete as the system has evolved. Symptoms of structural problems include too many unnecessary recompilations, unintended cyclic dependency chains, and some types of difficulties with understanding, modifying, and testing the system. Most structural problems cannot be solved by making a few “small” changes, and most require the programmer to understand the overall pattern of interactions in order to solve the problem.

Smarter recompilation

Tichys Smart Recompilation method can be made smarter by permitting benign type inconsistencies between separately compiled modules. This enhanced method helps the programmer to make far-reaching changes in small, manageable steps.

Using Neural Networks to Modularize Software

This article describes our experience with designing and using a module architecture assistant, an intelligent tool to help human software architects improve the modularity of large programs. The tool models modularization as nearest-neighbor clustering and classification, and uses the model to make recommendations for improving modularity by rearranging module membership. The tool learns similarity judgments that match those of the human architect by performing back propagation on a specialized neural network. The tools classifier outperformed other classifiers, both in learning and generalization, on a modest but realistic data set. The architecture assistant significantly improved its performance during a field trial on a larger data set, through a combination of learning and knowledge acquisition.

Configuration management in BiiN SMS

BiiN SMS is a new industrial-strength software management system that solves four con figuration management problems in new ways: the dependency mapping problem, the stable context problem, the short circuit problem, and the composition problem.

Measuring architecture quality by structure plus history analysis

This case study combines known software structure and revision history analysis techniques, in known and new ways, to predict bug-related change frequency, and uncover architecture-related risks in an agile industrial software development project. We applied a suite of structure and history measures and statistically analyzed the correlations between them. We detected architecture issues by identifying outliers in the distributions of measured values and investigating the architectural significance of the associated classes. We used a clustering method to identify sets of files that often change together without being structurally close together, investigating whether architecture issues were among the root causes. The development team confirmed that the identified clusters reflected significant architectural violations, unstable key interfaces, and important undocumented assumptions shared between modules. The combined structure diagrams and history data justified a refactoring proposal that was accepted by the project manager and implemented.

Software architecture analysis: a case study

The Arch project is investigating methods and tools for understanding, specifying, controlling and improving the subsystem architecture of large so~are systems. This paper focuses on one of Arch’s capabilities, critiquing modularity. It discusses the relationship of modularity and architecture to configuration management, describes Arch’s information-sharing measure and its heuristic method, maverick analysis, for spotting poor information-hiding, and gives examples of using Arch tofind and analyze problem modules. Then it describes a case study in which Arch was used to analyze a “real”, production software system, including the real developer’s responses to Arch’s analysis.

Industrial software architecture with Gestalt

The architecture of a software system specifies, among other things, its decomposition into parts and the communication between those parts. The structure of this decomposition and interconnection is separable from the protocols (types and sequencing) of communication. A language for specifying this structure and a toolset for checking consistency between structure specifications and code would provide substantial benefits to practicing industrial software architects. Gestalt is an architecture language for specifying structure, with separate, partial support for protocol specifications. The Gestalt toolset checks structural consistency between the architecture and the code. It specifies and checks protocol type compatibility at the interfaces, using the implementation language and tools (e.g. compiler). It provides annotation support for sequencing and other architectural information.

Experience with the architectural design of a modest product family

Many product families are modest in the sense that they consist of a sequence of incremental products with, at any point in time, only a few distinct products available and minimal variations among the products. Such product families, nevertheless, are often large, complex systems, widely deployed, and possessing stringent safety and performance requirements. This paper describes a case study that tends to confirm the value of using a product‐line approach for the architectural design of a modest product family. The paper describes the process, design alternatives, and lessons learned, both positive and negative, from the architectural design of one such family of medical image analysis products. Realized benefits included identifying previously unrecognized common behavior and sets of features that were likely to change together, aligning the architecture with specific market needs and with the organization, and reducing unplanned dependencies. Most interesting were the unanticipated benefits, including decoupling the product‐family architecture from the order of implementation of features, and using the product‐family architecture as a ‘guiding star’ with subsequent releases moving toward, rather than away from, the planned architecture. Copyright

Toward a real-time event flow architecture style

Recent literature on the architectures of real-time systems reveals striking similarities among designs used in many different domains, including avionics, satellites, process control, signal processing, power generation and manufacturing. This paper presents an architecture style that can be used for a large class of real-time event-processing systems. It gives the common requirements of these systems, the major design patterns shaping the architecture, and the rationale leading from the requirements to the chosen patterns. Although most of the design patterns could be used individually to define stand-alone architecture styles, collectively the requirements and design patterns have many interrelationships that make this an architecture style worth documenting and studying. The paper ends with brief discussions of three previously published systems that have similar architectures.