Peri L. Tarr

N degrees of separation: multi-dimensional separation of concerns

Done well, separation of concerns can provide many software engineering benefits, including reduced complexity, improved reusability, and simpler evolution. The choice of boundaries for separate concerns depends on both requirements on the system and on the kind(s) of decomposition and composition a given formalism supports. The predominant methodologies and formalisms available, however, support only orthogonal separations of concerns, along single dimensions of composition and decomposition. These characteristics lead to a number of well-known and difficult problems. The paper describes a new paradigm for modeling and implementing software artifacts, one that permits separation of overlapping concerns along multiple dimensions of composition and decomposition. This approach addresses numerous problems throughout the software lifecycle in achieving well-engineered, evolvable, flexible software artifacts and traceability across artifacts.

Multi-Dimensional Separation of Concerns and the Hyperspace Approach

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.

Model-driven development: the good, the bad, and the ugly

In large software development organizations, increased complexity of products, shortened development cycles, and heightened expectations of quality have created major challenges at all the stages of the software life cycle. As this issue of the IBM Systems Journal illustrates, there are exciting improvements in the technologies of model-driven development (MDD) to meet many of these challenges. Even though the prevalent software-development practices in the industry are still immature, tools that embody MDD technologies are finally being incorporated in large-scale commercial software development. Assuming MDD pervades the industry over the next several years, there is reason to hope for significant improvements in software quality and time to value, but it is far from a foregone conclusion that MDD will succeed where previous software-engineering approaches have failed.

Using multidimensional separation of concerns to (re)shape evolving software

S Separation of concerns [11] is a key guiding principle of software engineering. It refers to the ability to identify, encapsulate, and manipulate only those parts of software that are relevant to a particular concept, goal, or purpose. Concerns are the primary criteria for decomposing software into smaller, more manageable and comprehensible parts that have meaning to a software engineer. As software becomes more pervasive and its life expectancy increases, it becomes subject to greater pressures to integrate and interact with other pieces of software—often off-the-shelf software that has been written by entirely separate organizations—and to evolve and adapt to uses in new and unanticipated contexts, both technological (new hardware, operating systems, software configurations, standards) and sociological (new domains, business practices, processes and regulations, users). Simplifying development, evolution, and integration of Java software using Hyper/J.

Hyper/J: multi-dimensional separation of concerns for Java

Hyper/J/sup TM/ supports flexible, multi-dimensional separation of concerns for Java/sup TM/ software. This demonstration shows how to use Hyper/J in some important development and evolution scenarios, emphasizing the software engineering benefits it provides.

Subject-oriented design: towards improved alignment of requirements, design, and code

In practice, object-oriented design models have been less useful throughout the lifetime of software systems than they should be. Design models are often large and monolithic, and the structure of the designs is generally quite different from that of requirements. As a result, developers tend to discard the design, especially as the system evolves, since it is too difficult to keep its relationship to requirements and code accurate, especially when both are changing. This paper presents a different approach to designing systems, based on flexible decomposition and composition, that closely aligns designs with both requirements specifications and with code. We illustrate how this approach permits the benefits of designs to be maintained throughout a system’s lifetime.

Software engineering tools and environments: a roadmap

Tools and environments to aid developers in producing software have existed, in one form or another, since the early days of computer programming. They are becoming increasingly crucial as the demand for software increases, time-to-market decreases, and diversity and complexity grow beyond anything imagined a few decades ago. In this paper, we briefly review some of the history of tools and environments in software engineering, and then discuss some key challenges that we believe the field faces over the next decade.

Web Services: Promises and Compromises

Much of web services’ initial promise will be realized via integration within the enterprise, either with legacy applications or new business processes that span organizational silos. Enterprises need organizational structures that support this new paradigm.

Concern modeling in the concern manipulation environment

The Concern Manipulation Environment (CME) is an AOSD environment in which software is organized and manipulated in terms of concerns. This paper is about ConMan, the CME concern manager, which supports the identification, definition, encapsulation, extraction and composition of concerns. ConMan models software in terms of concerns, relationships, constraints, units, artifacts, and associated information. The concern model is multidimensional and concerns can be defined extensionally and/or intensionally. ConMan is neutral with respect to artifact types and formalisms, and it can be used with both aspect-oriented and non-aspect oriented software and methods. ConMan is intended to serve both as a tool for directly modeling concerns and as a platform for developing alternative concern-modeling approaches.

Using subject-oriented programming to overcome common problems in object-oriented software development/evolution

This note presents an overview of this ICSE ‘99 tutorial.