Paul C. Clements

Scenario-based analysis of software architecture

Despite advances in clarifying high level design needs, analyzing a systems ability to meet desired quality criteria is still difficult. The authors propose using scenarios to make analysis more straightforward. In their case study report, they analyze lessons learned with this approach. They developed the Software Architecture Analysis Method, an approach that uses scenarios to gain information about a systems ability to meet desired quality attributes. Scenarios are brief narratives of expected or anticipated system uses from both user and developer views and they provide a look at how the system satisfies quality attributes in various use contexts.

The Modular Structure of Complex Systems

This paper discusses the organization of software that is inherently complex because of very many arbitrary details that must be precisely right for the software to be correct. We show how the software design technique known as information hiding, or abstraction, can be supplemented by a hierarchically structured document, which we call a module guide. The guide is intended to allow both designers and maintainers to identify easily the parts of the software that they must understand, without reading irrelevant details about other parts of the software. The paper includes an extract from a software module guide to illustrate our proposals.

A survey of architecture description languages

Architecture description languages (ADLs) are emerging as viable tools for formally representing the architectures of systems. While growing in number, they vary widely in terms of the abstractions they support and analysis capabilities they provide. Further, many languages not originally designed as ADLs serve reasonably well at representing and analyzing software architectures. This paper summarizes a taxonomic survey of ADLs that is in progress. The survey characterizes ADLs in terms of: the classes of systems they support; the inherent properties of the languages themselves; and the process and technology support they provide to represent, refine, analyze, and build systems from an architecture. Preliminary results allow us to draw conclusions about what constitutes an ADL, and how contemporary ADLs differ from each other.

A rational design process: How and why to fake it

Many have sought a software design process that allows a program to be derived systematically from a precise statement of requirements. It is proposed that, although designing a real product in that way will not be successful, it is possible to produce documentation that makes it appear that the software was designed by such a process. The ideal process and the documentation that it requires are described. The authors explain why one should attempt to design according to the ideal process and why one should produce the documentation that would have been produced by that process. The contents of each of the required documents are outlined.

The golden age of software architecture

Since the late 1980s, software architecture has emerged as the principled understanding of the large-scale structures of software systems. From its roots in qualitative descriptions of empirically observed useful system organizations, software architecture has matured to encompass a broad set of notations, tools, and analysis techniques. Whereas initially the research area interpreted software practice, it now offers concrete guidance for complex software design and development. It has made the transition from basic research to an essential element of software system design and construction. This retrospective examines software architectures growth in the context of a technology maturation model, matching its significant accomplishments to the models stages to gain perspective on where the field stands today. This trajectory has taken architecture to its golden age.

Getting there from here: a roadmap for software product line adoption

Mapping the technical and business activities and steps required for successful organizational adoption.

Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design

This paper reports on the third Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, which has been held in Lancaster, UK, on March 21, 2004. The workshop included a presentation session and working sessions in which the particular topics on early aspects were discussed. The primary goal of the workshop was to focus on challenges to defining methodical software development processes for aspects from early on in the software life cycle and explore the potential of proposed methods and techniques to scale up to industrial applications.

MT: A toolset for specifying and analyzing real-time systems

This paper introduces MT, a collection of integrated tools for specifying and analyzing real-time systems using the Modechart language. The toolset includes facilities for creating and editing Modechart specifications. Users may symbolically execute the specifications with an automatic simulation tool to make sure that the specified behavior is what was intended. They may also invoke a verifier that uses model-checking to determine whether the specifications imply (satisfy) any of a broad class of safety assertions. To illustrate the toolsets capabilities as well as several issues that arise when formal methods are applied to real-world systems, the paper includes specifications and analysis procedures for a software component taken from an actual Naval real-time system.<<ETX>>

The Duties, Skills, and Knowledge of Software Architects

This paper focuses on the human aspects of architecting software-in particular, the duties, skills, and knowledge of software architects. We present the results of a survey of approximately 200 public sources of information aimed at professional software architects that we conducted in the summer of 2006. We summarize what those sources have to say about the duties, skills, and knowledge that competent architects must perform and have.

Being proactive pays off

The key to this enterprise-level strategic positioning is understanding the scope of the product line. A product lines scope states what systems an organization would be willing to build as part of its product line and what systems it would not. In other words, it defines whats in and whats out. Explicitly scoping the product line lets us examine regions in the neighborhood that are underrepresented by actual products in the marketplace, make small extensions to the product line, and move quickly to fill the gap. In short, a consciously preplanned, proactive product line scope helps organizations take charge of their own fate. The scope feeds other product line artifacts; the requirements, architecture, and components all take their cues for the variabilities they need to provide from the scope statement.