Introduction

The concept of goal, as a state of affairs that an actor (human, organization or system) wants to achieve, together with social aspects and other intentional concepts define the Goal-Oriented (GO) paradigm that has been largely studied and applied in Requirements Engineering (RE) since more than ten years [1,2].

Evidences of the usefulness of the GO paradigm can be found in a variety of real world experiences that exploited available GO methodologies that support software system development activities ranging from requirements acquisition, analysis and understanding, to design and test cases derivation.

A key feature of the GO paradigm is that of allowing to model and reason about alternatives. These alternatives are usually represented in terms of OR-decompositions of goals or tasks, which lead to the definition of goal trees, whose alternative paths may be evaluated against possible situations of benefit, drawback or conflict.

This paper summarizes three ongoing research efforts at FBK-IRST in which the GO paradigm plays a central role at support of decision making for domain and system analysts, system designers and also for proactive artificial agents, in different contexts: (i) when analysts have to decide about the compliance of a set of the system's requirements with respect to law; (ii) when designers have to choose a suitable design pattern; (iii) when software agents of a self-adaptive system have to decide at run-time which one among their alternative sub-goals to achieve, while attempting to satisfy the main goals assigned to them by the designers.

2 An i * Framework for Law Compliance: Nòmos Laws and regulations address processes and associated information systems within organizations. Available methods and techniques for system design give little support to the requirements engineer when analysing the impact of those regulations during the definition of requirements for a new system, or when an existing organization has to restructure and re-engineer its operation in order to achieve compliance.

Goal-oriented requirements engineering rests on the idea of deriving the requirements for a software system from the analysis of the goals that the systemto-be will support once developed and deployed. However, when the stakeholders are addressed by laws, the system-to-be has to be aligned with the legal prescriptions, too, and goals per se do not provide information about such an alignment. This is the problem of law compliance of goals models. Finding a solution to this problem means finding the assignment of actors' responsibilities (goals) such that if every actor fulfils its goals, then law is respected. To address this problem we adopt a modelling approach which consists in starting from a model of legal prescriptions, and building the model of goals in an incremental way that maintains the alignment with the prescriptions.

The i * modelling language focuses on intentional elements as the key to describe and understand a given organizational setting. Laws play a different role as they have (i) physical existence as natural language sentences in legal texts; and (ii) prescription objectives with regard to the organization. The contribution of the Nòmos framework consists in a conceptual binding between the two conceptions of intentions and regulations. The binding relies on the analysis of legal sentences, which ultimately allows to identify the juridical concept of normative proposition (NP), as the most atomic proposition able to carry a normative semantics, containing information concerning: (i) the subject(s) addressed by the NP itself; (ii) the legal modality; and (iii) the description of the object of such modality. The legal modality is one of the eight elementary rights, classified by Hohfeld [3] as: Privilege, which is the entitlement for a person to discretionally perform an action, regardless of the will of others and Claim, which is the entitlement for a person to have something done from another person, with their correlative rights No-claim and Duty; Power, which is the (legal) capability to produce changes in the legal system towards another subject, and Immunity, which is the right of being kept untouched from other performing an action, and their correlatives rights, Liability and Disability.

In order to support modelling of laws and compliance solutions, the i * metamodel (in the variant proposed by the Tropos methodology [4]) has been extended with the Nòmos concepts, integrating the two set of concepts. Moreover, a systematic process has been defined to support the building of compliant requirements models, as described in detail in [5,6], considering the following issues: the binding of domain stakeholders with subjects addressed by law, the identification of legal alternatives, the identification of potential realisations of normative propositions, the identification of legal risks, the identification of proof artefacts, the constraining of delegation of goals to other actors.

As future work, we are investigating the use of argumentation framework in order to support the acceptability of compliance solutions.

Design Pattern Representation with Motivations

Software patterns are reusable solutions to recurring design problems andsince their definition -are considered a mainstream of software reuse practice. They are typically documented with a textual description of the context where they can apply, the purpose for their reuse and forces to balance. For encouraging the understanding of design patterns and to ease their application during the design phase, many approaches have been proposed to provide the solution by using formal, semi-formal graphical notations or logic languages [7].

We propose to use i * to represent not only the pattern solution, but also the whole reasoning process that led to its formation, including motivation, trade-offs and alternatives [8]. The main motivations of this approach are (i) to improve the communication encapsulated in a design pattern without changing the informative content and (ii) to provide some criteria for motivating pattern selection and reuse during the design process.

The proposed abstraction considers the design activity as the application area in which we apply the i * framework, and the Designer as the main Actor of the design activity, whose job is to balance design forces coming from the system to be modelled. The designer's activities arise from needs, such as: (i) the achievement of Design Goals to solve specific design problem emerging during the modelling of the system, and (ii) the compliance with Design Properties (or soft goals) that specify qualities of the system. In this context a pattern is a collection of collaborating roles, intended as autonomous holder of design intentions that are delegated of some responsibilities from the designer, namely: (i) design goals/soft-goals to be achieved, (ii) design tasks for introducing a well-known solution, and (iii) system elements to introduce or to organize in the solution.

In this approach, the designer is supported with techniques for balancing pattern contextual forces and for customizing the pattern implementation to the specific application context. We exploit the Strategic Dependency model for representing the high-level responsibility organization of a design pattern, and the Strategic Rationale model for entering in detail in the solution structure.

The Strategic Dependency main role is always the designer who delegates design intentionality to pattern roles. This view allows for highlighting main intents and motivations of a pattern, and it is an instrument for quick selection of the pattern to reuse from a catalogue. On the other side the Strategic Rationale model allows for reasoning on design issues, considering consequences and balancing design alternatives, thus customizing the solution to meet forces coming from the context. This approach opens new research directions we are working on: (i) to represent -and reason on -pattern composition and conflicts, and (ii) the use of an ontology for standardizing design intentional elements, that may help in automatic discovery of patterns to reuse.

4 Goal-Oriented Development of Self-Adaptive Systems Self-adaptive Software (SAS) aims at dealing autonomously with unpredictable changes which occur in the dynamic environment it executes (at run-time), on the basis of its knowledge and of the objectives it has been designed for. We aim at defining a process and a tool-supported design framework to develop SAS with the necessary knowledge that enables adaptation of their behaviour at run-time. Belief-Desire-Intention (BDI) agents [9] were chosen as reference architecture and implementation platform.

The proposed framework and development process, called Tropos4AS (Tropos for Adaptive Systems) [10], exploits the basic Tropos early and late requirements phases, with an extensive use of variability modelling [11], and extends the design phase with environment modelling, extended goal modelling and failure modelling.

The environment model captures the non-intentional entities involved in, used and perceived by the SAS, which are necessary for interfacing the system with the surrounding world. For instance, the environment for a cleaner robot includes the floor, the dustbins and a battery charging station. These entities are represented through artifacts [12], non-intentional entities that provide functionalities usable by agents to sense and act in the environment.

In extended goal modelling, the goal model is linked with the environment. The process of goal achievement is related to the environment by defining the context where the goal is applicable, the conditions which lead to its adoption, its achievement and failure states. Different goal types further characterise the process of goal achievement, distinguishing among goals that the SAS has to achieve in a given situation (e.g. clean a wet floor), goals that the SAS has to achieve and maintain all along its life cycle (e.g. maintain a battery loaded), and goals that can be rather described as executing a given procedure (e.g. searching for dirt). Goal types were already present in the Formal Tropos [13] language, which was however developed with the aim of consistency verification via modelchecking techniques. On the contrary, Tropos4AS focuses on the semantics of an agent's goal model that can be directly coded in a BDI agent programming language (e.g. Jadex, 2APL or Jack), following predefined mapping rules to link the goals in the design artefacts to the agent goals in the code, respecting the semantics of the goal model [14].

In failure modelling, Tropos4AS aids the designer in anticipating possible failures, giving a process to elicit errors possibly causing them and analysing the possibilities to fix them. Entities added to the Tropos4AS meta-model for supporting failure modelling are: failures, representing undesirable states known to the designer for the impossibility to achieve a goal, perceivable errors that may be the cause of these failures, and recovery activities, i.e. actions that the SAS may undertake to recover from errors, preventing failure.