Information systems of the future will have to perform well within ever-changing organizational environments. Unfortunately, existing software development methodologies (object-oriented, structured or otherwise) have traditionally been inspired by programming concepts, not organizational ones, leading to a semantic gap between the software system and its operational environment. To reduce this gap, we propose a software development methodology named Tropos which is founded on concepts used to model early requirements. Our proposal adopts the i* organizational modeling framework, which o#ers the notions of actor, goal and (actor) dependency, and uses these as a foundation to model early and late requirements, architectural and detailed design. The paper outlines Tropos phases through an e-business example, and sketches a formal language which underlies the methodology and is intended to support formal analysis. The methodology seems to complement well proposals for agent-oriented programming platforms.

Aspect-Oriented Programming (AOP) is intended to ease situations that involve many kinds of code tangling. This paper reports on a study to investigate AOP's ability to ease tangling related to exception detection and handling. We took an existing framework written in Java, the JWAM framework, and partially reengineered its exception detection and handling aspects using AspectJ, an aspect-oriented programming extension to Java. We found that

A Multi-Agent System (MAS) is an organization of coordinated autonomous agents that interact in order to achieve common goals. Considering real world organizations as an analogy, this paper proposes architectural styles for MAS which adopt concepts from organization theory and strategic alliances literature. The styles are intended to represent a macro-level architecture of a MAS, and they are modeled using the i* framework which offers the notions of actor, goal and actor dependency for modeling multi-agent settings. The styles are also specified as metaconcepts in the Telos modeling language. Moreover, each style is evaluated with respect to a set of software quality attributes, such as predictability and adaptability. The paper also explores the adoption of micro-level patterns proposed elsewhere in order to give a finer-grain description of a MAS architecture. These patterns define how goals assigned to actors participating in an organizational architecture will be fulfilled by agents.

In this paper, we discuss the notion of variability. We have experienced that this concept has so far been underdefined. Although, we have observed that variability techniques become increasingly important. A clear indication of this trend is the recent emergence of software product lines. Software product lines are large, industrial software systems intended to specialize into specific software products. Our contribution in this paper is that we provide the reader with a framework of terminology and concepts regarding variability. In addition, we present three recurring patterns of variability. Finally, we suggest a method for managing variability in software product lines.

Factory, and Singleton). Tactical patterns have a relatively localized impact on a software architecture. For instance, the Iterator pattern [7] allows elements in a collection to be accessed sequentially without violating data encapsulation. Although this pattern is widely applicable, the problem it addresses does not have sweeping architectural implications. In contrast, strategic design patterns have an extensive impact on the software architecture for solutions in a particular domain. For example, the HalfSync /Half-Async pattern [15] decouples synchronous I/O from asynchronous I/O in a system to simplify concurrent programming effort without degrading execution efficiency. This pattern greatly simplifies synchronization strategies in complex concurrent systems (such as BSD Unix). We focused most of our energy on documenting patterns related to our domain (communication software), and we reused existing tactical patterns rather than reinventing them. Focusing on strategic domain p...

Informally described design patterns are useful for communicating proven solutions for recurring design problems to developers, but they are inadequate for more rigorous use of design patterns. For example, they cannot be used as compliance points against which solutions that claim to conform to the patterns are checked. Pattern specification languages that utilize mathematical notation provide the needed formality but often at the expense of usability. In this paper we present a rigorous and practical technique for specifying pattern solutions expressed in the Unified Modeling Language (UML). The specification technique paves the way for the development of tools that support rigorous application of design patterns to UML design models. The technique has been used to create specifications of solutions for several popular design patterns. We illustrate the use of the technique by specifying Observer and Visitor pattern solutions.

This paper describes the Service Configurator pattern, which decouples the implementation of services from the time when they are configured. This pattern increases the flexibility and extensibilityof applicationsby enabling their constituent services to be configured at any point in time. The Service Configurator pattern is widely used in application environments (e.g., to configure Java applets into WWW browsers), operating systems (e.g., to configure device drivers), and distributed systems (e.g., to configure standard Internet communication services).

Frameworks are an object-oriented reuse technique that are widely used in industry but not discussed much by the software engineering research community. They are a way of reusing design that is part of the reason that some object-oriented developers are so productive. This paper compares and contrasts frameworks with other reuse techniques, and describes how to use them, how to evaluate them, and how to develop them. It describe the tradeoffs involved in using frameworks, including the costs and pitfalls, and when frameworks are appropriate.

It is a well-known fact that evolving a software application accounts for the largest part of the software development process, and is currently the most problematic phase. Aspect-oriented software development is often touted as a means to ameliorate this situation: by providing new modularization mechanisms, it enables cleaner separation of concerns and reduced code tangling, and consequently makes evolving the application easier. Unfortunately, current research results only indicate that AOSD leads to applications that are better modularized, but fail to show that this improves their evolvability. Paradoxically, we have found indications of the contrary: current AOSD technologies deliver applications that are as hard, or perhaps even harder, to evolve than was the case before. We will show in this paper that the particular cause of this problem is that aspect programmers are forced to write aspects that only work for one specific version of an application.

Although numerous mechanisms for promoting software reuse have been proposed and implemented over the years, most have focused on the reuse of implementation code. There is much conjecture and some empirical evidence, however, that the most effective forms of reuse are generally found at more abstract levels of software design. In this paper we discuss software reuse at the architectural level of design. Specifically, we argue that the concept of “architectural style ” is useful for supporting the classification, storage, and retrieval of reusable architectural design elements. We briefly describe the Aesop system’s Software Shelf, a tool that assists designers in selecting appropriate design elements and patterns based on stylistic