Program families are defined (analogously to hardware families) as sets of programs whose common properties are so extensive that it is advantageous to study thecommon properties of the programs before analyzing individual members. The assumption that, ifone is to develop a set of similar programs over a period of time, one should consider the set asawhole while developing the first three approaches to the development, is discussed. A conventional approach called "sequential development" is compared to "stepwise refinement" and "specification of information hiding modules." A more detailed comparison of the two methods is then made. By means of several examples it is demonstrated that the two methods are based on the same concepts but bring complementary advantages.

: Separation of concerns is at the core of software engineering, and has been for decades. This has led to the invention of many interesting, and effective, modularization approaches. Yet many of the problems it is supposed to alleviate are still with us, including dangerous and expensive invasive change, and obstacles to reuse and component integration. A key reason is that one needs different decompositions according to different concerns at different times, but most languages and modularization approaches support only one "dominant" kind of modularization (e.g., by class in object-oriented languages). Once a system has been decomposed, extensive refactoring and reengineering are needed to remodularize it. Multi-dimensional separation of concerns allows simultaneous separation according to multiple, arbitrary kinds (dimensions) of concerns, with on-demand remodularization. Concerns can overlap and interact. This paper discusses multi-dimensional separation of concerns in general, our particular approach to providing it, called hyperspaces , and our support for hyperspaces in Java^TM , called Hyper/J^TM. 2 Chapter # 1.

Studying the design and implementation of a number of computer has led to some general hints for system design. They are described here and illustrated by many examples, ranging from hardware such as the Alto and the Dorado to application programs such as Bravo and Star. 1.

Two of the most important issues in distributed systems are the synchronization of concurrent threads and the application-level data transfers between execution spaces. At the design level, addressing these issues typically requires analyzing the components under a different perspective than is required to analyze the functionality. Very often, it also involves analyzing several components at the same time, because of the way those two issues cross-cut the units of functionality. At the implementation level, existing programming languages fail to provide adequate support for programming in terms of these different and cross-cutting perspectives. The result is that the programming of synchronization and remote data transfers ends up being tangled throughout the components code in more or less arbitrary ways. This thesis presents a language framework called D that untangles the implementation of synchronization

Many maintenance tasks address concerns, or features, that are not well modularized in the source code comprising a system. Existing approaches available to help software developers locate and manage scattered concerns use a representation based on lines of source code, complicating the analysis of the concerns. In this paper, we introduce the Concern Graph representation that abstracts the implementation details of a concern and makes explicit the relationships between different parts of the concern. The abstraction used in a Concern Graph has been designed to allow an obvious and inexpensive mapping back to the corresponding source code. To investigate the practical tradeoffs related to this approach, we have built the Feature Exploration and Analysis tool (FEAT) that allows a developer to manipulate a concern representation extracted from a Java system, and to analyze the relationships of that concern to the code base. We have used this tool to find and describe concerns related to software change tasks. We have performed case studies to evaluate the feasibility, usability, and scalability of the approach. Our results indicate that Concern Graphs can be used to document a concern for change, that developers unfamiliar with Concern Graphs can use them effectively, and that the underlying technology scales to industrial-sized programs.

We investigate proof rules for information hiding, using the recent formalism of separation logic. In essence, we use the separating conjunction to partition the internal resources of a module from those accessed by the module's clients. The use of a logical connective gives rise to a form of dynamic partitioning, where we track the transfer of ownership of portions of heap storage between program components. It also enables us to enforce separation in the presence of mutable data structures with embedded addresses that may be aliased.

Module mechanisms have received considerable theoretical attention, but the associated concepts of separate compilation and linking have not been emphasized. Anomalous module systems have emerged in functional and object-oriented programming where software components are not separately typecheckable and compilable. In this paper we provide a context where linking can be studied, and separate compilability can be formally stated and checked. We propose a framework where each module is separately compiled to a self-contained entity called a linkset ; we show that separately compiled, compatible modules can be safely linked together.

Fortran M is a small set of extensions to Fortran 77 that supports a modular approach to the design of message-passing programs. It has the following features. (1) Modularity. Programs are constructed by using explicitly-declared communication channels to plug together program modules called processes. A process can encapsulate common data, subprocesses, and internal communication. (2) Safety. Operations on channels are restricted so as to guarantee deterministic execution, even in dynamic computations that create and delete processes and channels. Channels are typed, so a compiler can check for correct usage. (3) Architecture Independence. The mapping of processes to processors can be specified with respect to a virtual computer with size and shape different from that of the target computer. Mapping is specified by annotations that influence performance but not correctness. (4) Efficiency. Fortran M can be compiled efficiently for uniprocessors, sharedmemory computers, distributed-m...

Data abstraction is a valuable method for organizing programs to make them easier to modify and maintain. Inheritance allows one implementation of a data abstraction to be related to another hierarchically. This paper investigates the usefulness of hierarchy in program development, and concludes that although data abstraction is the more important idea, hierarchy does extend its usefulness in some situations.

While software architecture has become an increasingly important research topic in recent years, insufficient atten-tion has been paid to methods for evaluation of these archi-tectures. Evaluating architectures is dijjicultfor two main reasons. First, there is no common language used 10 de-scribe different architectures. Second, there is no clear way of understanding an architecture with respect to an organi-zation’s ll~e cycle concerns—software quality concerns such as maintainability, portability, modularity, reusability, and so forth. This paper addresses these shortcomings by describing three perspectives by which we can understand the description of a soflware architecture and then propos-ing ajve-step method for analyzing software architectures called SAAM (Software Architecture Analysis Method). We illustrate the method by analyzing three separate user in-terface architectures with respect to the qualiiy of modifi-ability. 1