It is generally accepted that early determination of the stakeholder requirements assists in the development of systems that better meet the needs of those stakeholders. General security requirements frustrate this goal because it is difficult to determine how they affect the functional requirements of the system. This paper illustrates how representing threats as crosscutting concerns aids in determining the effect of security requirements on the functional requirements. Assets (objects that have value in a system) are first enumerated, and then threats on these assets are listed. The points where assets and functional requirements join are examined to expose vulnerabilities to the threats. Security requirements, represented as constraints, are added to the functional requirements to reduce the scope of the vulnerabilities. These requirements are used during the analysis and specification process, thereby incorporating security concerns into the functional requirements of the system.

Abstract: Developers of modern software systems are often required to build software that addresses security, fault-tolerance and other dependability concerns. A decision to address a dependability concern in a particular manner can make it difficult or impossible to address other concerns in software. Proper attention to balancing key dependability and other concerns in the

There has been significant recent interest, within the Aspect-Oriented Software Development (AOSD) community, in representing crosscutting concerns at various stages of the software lifecycle. However, most of these efforts have concentrated on the design and implementation phases. We focus in this paper on representing aspects during use case modeling. In particular, we focus on scenario-based requirements and show how to compose aspectual and nonaspectual scenarios so that they can be simulated as a whole. Non-aspectual scenarios are modeled as UML sequence diagrams. Aspectual scenarios are modeled as Interaction Pattern Specifications (IPSs). In order to simulate them, the scenarios are transformed into a set of executable state machines using an existing state machine synthesis algorithm. Previous work composed aspectual and non-aspectual scenarios at the sequence diagram level. In this paper, the composition is done at the state machine level. 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.

Aspects are behaviours that are tangled and scattered across a system. In requirements documentation, aspects manifest themselves as descriptions of behaviours that are intertwined and interdependent. Some aspects may be obvious, as specifications of typical crosscutting behaviour. Others may be more subtle, making them hard to identify. In either case, it is difficult to analyse requirements to locate all points in the system where the aspects should be applied. To identify aspects early in the software lifecycle developers need support for aspect identification and analysis in requirements documentation. To address this, we have devised the Theme/Doc approach for viewing the relationships between behaviours in a requirements document to identify and isolate aspects in the requirements. This paper describes the approach, and illustrates it with a case study and analysis.

Handling aspects within models looks promising for managing crosscutting concerns early in the software life-cycle, up from programming to design, analysis and even requirements. At the modeling level, even complex behavioral aspects can easily be described for instance as pairs of sequence diagrams: one for the pointcut specifying the behavior to detect, and the second one for an advice representing the wanted behavior at the join point. While this is fine for informal documentation purposes, or even intuitive enough when a single aspect has to be woven, a more precise semantics of both join point detection and advice weaving is needed for using these modeling artifacts for Model Driven Engineering activities such as code generation or test synthesis. This paper proposes various interpretations for pointcuts that allow multiple behavioral aspects to be statically woven. The idea is to allow join points to match a pointcut even when some extra-messages occur in between. However, with this new way of specifying join points, the composition of the advice with the detected part cannot any longer be just a replacement of the detected part by the advice. We have to consider the events (or the messages) of the join point, but also the events which occur between them, and merge them with the behavior specified within the advice. We thus also propose a formal definition of a new merge operator, and describe its implementation on the Kermeta platform.

In aspect-oriented modeling (AOM), a design is described using a set of design views. It is sometimes necessary to compose the views to obtain an integrated view that can be analyzed by tools. Analysis can uncover conflicts and interactions that give rise to undesirable emergent behavior. Design models tend to have complex structures and thus manual model composition can be arduous and errorprone. Tools that automate significant parts of model composition are needed if AOM is to gain industrial acceptance. One way of providing automated support for composing models written in a particular language is to define model composition behavior in the metamodel defining the language. In this paper we show how this can be done by extending the UML metamodel with behavior describing symmetric, signature-based composition of UML model elements. We also describe an implementation of the metamodel that supports systematic composition of UML class models. 1.

Existing requirements engineering approaches manage broadly scoped requirements and constraints in a fashion that is largely two-dimensional, where functional requirements serve as the base decomposition with nonfunctional requirements cutting across them. Therefore, crosscutting functional requirements are not effectively handled. This in turn leads to architecture trade-offs being mainly guided by the non-functional requirements, so that the system quality attributes can be satisfied. In this paper, we propose a uniform treatment of concerns at the requirements engineering level, regardless of their functional, non-functional or crosscutting nature. Our approach is based on the observation that concerns in a system are, in fact, a subset, and concrete realisations, of abstract concerns in a meta concern space. One can delineate requirements according to these abstract concerns to derive more system-specific, concrete concerns. We introduce the notion of a compositional intersection, which allows us to choose appropriate sets of concerns in our multidimensional separation as a basis to observe trade-offs among other concerns. This provides a rigorous analysis of requirements-level trade-offs as well as important insights into various architectural choices available to satisfy a particular functional or non-functional concern. 1.

The success of large-scale software systems depends on how accurate the huge amount of requirements is elicited and analysed by software engineers. Requirements engineering provides suitable approaches to define requirements of such systems in a systematic way. For example, viewpoint and object-oriented approaches have adequate mechanisms to reach these purposes. Nevertheless, the crosscutting nature of requirements is not addressed by these approaches, but this can be managed using aspect-oriented concepts. This work describes how aspects could be integrated to Vision, a viewpoint-oriented requirements method that integrates UML models. 1

Identifying and documenting early crosscutting concerns, i.e. requirements-level crosscutting concerns, is critical. It improves traceability among requirements as well as between requirements and downstream artifacts, facilitates easier assessment of change impact, supports requirements evolution, enables the application of aspectorientation from the very start of the software lifecycle and prevents easy oversight of crosscutting influences. However, the identification of requirements-level crosscutting concerns has been neglected in countless software projects but may---with the growing dissemination of aspect-oriented approaches---retroactively become relevant for some or even many of them. This paper, therefore, describes an approach to the identification problem from an aspect-mining point of view, i.e. to identify crosscutting elements in preexisting requirements specifications, and gives reasons why such an approach is highly desirable. Two techniques for aspect mining from these documents are suggested. Further, some preliminary results of a case study conducted to confirm the feasibility of the approach, are presented.