An effective requirements engineering (RE) approach must harmonise the need to achieve separation of concerns with the need to satisfy broadly scoped requirements and constraints. Techniques such as use cases and viewpoints help achieve separation of stakeholders ' concerns but ensuring their consistency with global requirements and constraints is largely unsupported. In this paper we propose an approach to modularise and compose such crosscutting, aspectual requirements. The approach is based on separating the specification of aspectual requirements, non-aspectual requirements and composition rules in modules representing coherent abstractions and following well-defined templates. The composition rules employ informal, and often concern-specific, actions and operators to specify how an aspectual requirement influences or constrains the behaviour of a set of non-aspectual requirements. We argue that such modularisation makes it possible to establish early trade-offs between aspectual requirements hence providing support for negotiation and subsequent decision-making among stakeholders. At the same time early separation of crosscutting requirements facilitates determination of their mapping and influence on artefacts at later development stages. A realisation of the proposed approach, based on viewpoints and the eXtensible Markup Language (XML), supported by a tool called ARCaDe and a case study of a toll collection system is presented.

There is a well documented problem in the software engineering field relating to a structural mismatch between the specification of requirements for software systems and the specification of object-oriented software systems. The structural mismatch happens because the units of interest during the requirements phase (for example, feature, service, capability, function etc.) are different to the units of interest during object-oriented design and implementation (for example, object, class, method, etc.). The structural mismatch results in support for a single requirement being scattered across the design units and a single design unit supporting multiple requirements -- this in turn results in reduced comprehensibility, traceability and reuse of design models.

Persistence - the storage and retrieval of application data from secondary storage media - is often used as a classical example of a crosscutting concern. It is widely assumed that an application can be developed without taking persistence requirements into consideration and a persistence aspect plugged in at a later stage. However, there are no real world examples showing whether persistence can in fact be aspectised and, if so, can this be done in a manner that promotes reuse and is oblivious to the application. In this paper, we provide an insight into these issues drawing upon our experience with a classical database application: a bibliography system. We argue that it is possible to aspectise persistence in a highly reusable fashion, which can be developed into a general aspect-based persistence framework. Nevertheless, application developers can only be partially oblivious to the persistent nature of the data. This is because persistence has to be accounted for as an architectural decision during the design of data-consumer components. Furthermore, designers of such components also need to consider the declarative nature of retrieval mechanisms supported by most database systems. Similarly, deletion requires explicit attention during application design as mostly applications trigger such an operation.

Constructing comprehensive operational models of intended system behaviour is a complex and costly task. Consequently, practitioners have adopted techniques that support incremental elaboration of partial behaviour descriptions. A noteworthy example is the wide adoption of scenario-based notations such as message sequence charts. Scenario-based specifications are partial descriptions that can be incrementally elaborated to cover the system behaviour that is of interest. However, how should partial behavioural models described by different stakeholders with different viewpoints covering different aspects of behaviour be composed? How should partial models of component instances of the same type be put together? In this paper, we propose model merging as a general solution to these questions. We formally define model merging based on observational refinement and show that merging consistent models is a process that should result in a minimal common refinement. Because minimal common refinements are not guaranteed to be unique, we argue that the modeller should participate in the process of elaborating such a model. We also discuss the role of the least common refinement and the greatest lower bound of all minimal common refinements in this elaboration process. In addition, we provide algorithms for i) checking consistency between two models; ii) constructing their least common refinement if one exists; iii) supporting the construction of a minimal common refinement if there is no least common refinement.

The UML is a collection of notations, some visual some textual.

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.

Software architecture analysis methods aim to predict the quality of a system before it has been developed. In general, the quality of the architecture is validated by analyzing the impact of predefined scenarios on architectural components. Hereby, it is implicitly assumed that an appropriate refactoring of the architecture design can help in coping with critical scenarios and mending the architecture. This paper shows that there are also concerns at the architecture design level which inherently crosscut multiple architectural components, which cannot be localized in one architectural component and which, as such, can not be easily managed by using conventional abstraction mechanisms. We propose the aspectual Software Architecture Analysis Method (ASAAM) with the aim to explicitly identify and specify these architectural aspects and make these transparent early in the software development life cycle. ASAAM introduces a set of heuristic rules that help to derive architectural aspects and the corresponding tangled architectural components from scenarios. The approach is illustrated for architectural aspect identification in the architecture design of a window management system.

This paper's position is that the time is ripe for initiating a proposal for an AOSD UML Profile. Some of the proposed Profile requirements are: (1) The Profile shall enable specifying, visualizing, and documenting the artifacts of software systems based on Aspect-Orientation. (2) The Profile shall be supported by UML (avoid "Heavy-weight" extension mechanisms), this allows a smooth integrating of existing CASE tools that support UML. (3) The Profile shall support the modular representation of crosscutting concern. And (4) the Profile shall not impose any behavioral implementation for AOSD, however it shall provide a complete set of model elements (or Stereotypes) that enable representing the semantics of the system based on Aspect-Orientation. AOSD Profile will set the stage for AOSD modeling, will enable capturing desired terminology of AOSD and will provide "native" support for AOSD in UML. Initial research publications and workshops on UML for AOSD have set the stage for our proposal.