Abstract. An aspect-oriented design model consists of a set of aspect models and a primary model. Each of these models consists of a number of different kinds of UML diagrams. The models must be composed to identify conflicts and analyze the system as a whole. We have developed a systematic approach for composing class diagrams in which a default composition procedure based on name matching can be customized by user-defined composition directives. This paper describes a set of composition directives that constrain how class diagrams are composed. 1

Separation of concerns is a basic engineering principle that is also at the core of object-oriented analysis and design methods in the context of the Unified Modeling Language (UML). The UML gives the designer a rich, but somehow disorganized, set of views on her model as well as many features, such as design pattern occurrences, stereotypes or tag values, allowing her to add nonfunctional information to a model. Aspect-oriented concepts are applied to manage the multitude of design constraints. However, it can then be an overwhelming task to reconcile the various aspects of a model into a working implementation. In this paper, we present our UMLAUT framework as a toolkit for easily building application specific "weavers" for generating detailed design models from high level, aspect oriented UML models. This is illustrated with a toy example of a distributed multimedia application with a weaving generating an implementation model. More ambitious applications are briefly outlined in the conclusion. 1.

Aspect-oriented modeling (AOM) techniques allow system developers to address pervasive objectives such as security and fault-tolerance separately from core functional requirements during system design. An aspect-oriented design model consists of a set of aspects and a primary model. An aspect describes how a single objective is addressed in a design, and a primary model describes how core functionality requirements are addressed. In order to analyze the interactions between aspects and primary models they must be composed. System developers may need to create and analyze alternative realizations in order to produce a design that balances competing objectives (concerns). Treating realizations of design objectives as aspects allows developers to more easily swap in and out alternative realizations in a design. The iterative nature of design dictates that composition and analysis be carried out in a flexible and intuitive manner. Composing aspects and primary models can produce designs with conflicting structures or behaviors. We have developed a twolevel structure of composition constraints to address this issue; a high level that identifies the aspects and determines the order in which they will be composed (composition strategy), and a lower level that constrains how a single aspect is composed with a primary model (composition directives). In this paper we describe a model composition approach that utilizes composition constraints. We illustrate the approach using small examples of security and faulttolerance aspects. 1.

Over the recent years aspect-oriented programming (AOP) has found increasing interest among researchers in software engineering. Aspects are abstractions which capture and localise cross-cutting concerns. Although persistence has been considered as an aspect of a system aspects in the persistence domain in general and in databases in particular have been largely ignored. This paper brings the notion of aspects to object-oriented databases.

Separation of concerns is a basic engineering principle that is often applied in object-oriented analysis and design by dissociating functional aspects (business objects) from non-functional ones, such as persistency, fault-tolerance and so on. The Unified Modeling Language (UML) then gives the designer a rich, but somehow disorganized, set of views on her model as well as many features, such as design pattern occurrences, stereotypes or tag values to add non-functional annotations to a model. In this paper, we explore a possibility to organize all of these features around the central notions of (1) quality of service contracts (for specifying non-functional properties a la QML) and (2) aspects for describing how they can be implemented. We propose to model contracts in UML with a small set of stereotypes, and to represent aspects a bit like design pattern occurrences, that is using parameterized collaborations equipped with transformation rules expressed with meta-level OCL2. The design level aspect weaver is then just a meta-level OCL2 interpreter, that takes a UML model as entry point, processes the various aspect applications as specified by the designers, and outputs another (detailed design level) UML model that can serve as a basis for code generation.

In model driven development (MDD), specifying transformations between models at various levels of abstraction can be a complex task. Specifying transformations for pervasive system features that are tangled with other system features is particularly difficult because the elements to be transformed are distributed across a model. This paper presents an aspect oriented model driven framework (AOMDF) that facilitates separation of pervasive features and supports their transformation across different levels of abstraction. The framework is illustrated using an example in which a platform independent model of a banking application is transformed to a platform specific model. Keywords: Aspect-oriented software development, distributed applications, QVT, middleware, model driven development, separation of concerns, transactions, UML. 1

The development of dependable software requires developers to address multiple, interrelated, design concerns, for example, security, fault tolerance, and safety concerns. As the complexity of software increases there is a need to develop mechanisms that allow developers to isolate realizations of design concerns during design and then compose them to obtain a comprehensive design. Such mechanisms can facilitate separation of concerns along multiple dimensions and can help manage the complexity inherent in creating and evolving highly-dependable software. In this paper we discuss some of the issues and challenges that should be addressed in developing mechanisms that support multi-dimensional separation of design concerns (MDSoC). We also outline a UML-based approach we are currently developing to support MDSoC.

The EU IST-project CORAS has developed an integrated risk management and system development process for security-critical systems based on AS/NZS 4360, RUP, and RM–ODP. The approach presented in this paper is based on the concepts of risk-driven development and extends the CORAS framework by using aspects to specify security risk treatment options. This enhances the evaluation of the treatment options since aspects models are decoupled from the primary model. The result is an aspect-oriented risk-driven development approach, in which security requirements or security risks may be identified in each phase of the development. The treatments that addresses these requirements or security risks are specified and implemented as aspects. Using aspects makes it easier to develop and evaluate security treatments options and to evolve the treatments.

Abstract. Addressing non-orthogonal software concerns that arise from requirements can significantly contribute to the complexity of developing large systems. Difficulties arise from the need to: locate related requirements, reason about the software concerns they represent, and analyze the impact of changing requirements. We address these issues through the use of requirements aspects. We present a method to identify requirements aspects from viewpoints, to associate requirements aspects with generic design solutions based on domain experience, and to specify the generic solutions using the UML. We demonstrate these techniques using a smart home controller application.

Abstract. In this paper, we describe the tool we plan to build in order to show the feasibility of aspect-oriented design, and demonstrate the advantages that it implies. This technique allows one to independently specify cross-cutting concerns and functionnal features of a system. The tool would then allow the weaving of the aspects on the model one after the other, creating a design model that would comply to all speci cations, with additionally a high-quality architecture.