System self-contextualizability is the system ability to autonomously adapt its behavior to the uncontrollable relevant context to keep its objectives satisfied. Self-contextualizable system must have alternative behaviors each fitting to a set of contexts. We propose to start considering context at the level of requirements engineering, adopting Tropos goal model to express requirements and complementing it with our proposed context analysis. We define variation points on goal model where a context-based decision might need to be taken, and propose constructs to analyze context. While goal analysis provides constructs to hierarchically analyze goals and discover alternative sets of tasks to be executed to satisfy a goal, our proposed context analysis provides constructs to hierarchically analyze context and discover alternative sets of facts to be monitored to verify a context.
Self-contextualizable software is able to monitor context and to autonomously adapt to it in order to keep its design objectives satisfied. This mainly means that the developed software has a space of alternative behaviors each fitting to a specific context. Consequently, and to allow for a systematic behavior adaptation to context, we need to specify the relation between each behavior and the context where such behavior is adoptable.
Context modeling, (e.g. [
Goal analysis (i* [
Customizing goal models to fit to user skills and preferences was studied in [
In this paper, we extend our previous goal modeling framework [
Self-contextualization, from a goal oriented perspective, is the autonomous selection between goal satisfaction alternatives to fit to the variable context. The basic idea is to keep the goals satisfied in different contexts through an adaptable course of execution. Here we give four principles for self-contextualizability from a goal perspective: Context effects: context influences the set of satisfiable goals, the need to satisfy each goal, the possible goal satisfaction alternatives, and the quality of each alternative. Context is not adaptable: context does not adapt to users and software; rather, users and software have to adapt to context to satisfy, and/or to better satisfy, their goals. Users contextualizability comes first: defining software self-contextualizability has to be based on how its users behave in different contexts. We need to analyze users goals to discover a space of satisfaction alternatives, and to analyze how context influences users in deciding and choosing among different alternatives for satisfying their goals. Self-contextulaizable software has to reflect users adaptation to the context first, and then adapt itself to context.
Contextualization times: software contextualization can be done while deploying the software, that supports different alternatives, in a certain environment to adapt it to some contextual characteristics that never change, i.e. some alternatives are not usable and redundant in that environment. Other variable characteristics necessitate keeping different alternatives and adopting one of them at runtime based on which context is valid. In both cases, the systematic contextualization needs specifying the relation between goal alternatives and context.
Fig. 1 represents a partial goal model for a promotion information system that will interact with customers and sales staff, through their PDAs, for promoting products with a number of alternatives. To make it self-contextualizable, we need to explicitly represent the relation between these alternatives and context. Contexts can be related to the following variation points of Tropos goal model: Custom er IS by cross-selling product to customer promote product to customer in mall
or 1. Or-decomposition: Or-decomposition is the basic variability construct, we still need to specify in which context each alterative in an Or-decomposition can be adopted. 2. Actors dependency: in some contexts, an actor might attain a goal / get a task executed by delegating it to another actor. 3. Goal activation: an actor, and depending on the context, might find necessary or possible triggering (or stopping) the desire of satisfying a goal. 4. And-decomposition: a sub-goal / sub-task might (or might not) be needed in a certain context, that is, some sub-goals / sub-tasks are not always mandatory to fulfil the top-level goal / task in an And-decomposition. 5. Means-end: goals can be ultimately satisfied by means of specific executable processes (tasks). The adoptability of each task might depend on the context. 6. Contribution to soft-goals: the contributions to the softgoals can vary from one context to another. We need to specify the relation between the context and the value of the contribution.
We need to analyze context to discover, represent, and to agree on how it can be
verified. Differently from the research in context modeling (see the survey [
To better explain the approach, let us consider the Or-alternative “ Promote by crossselling the product to customer” which concerns the elements: product, and customer. The parameterized goal is “Promote by cross-selling the product [p] to customer [c]”. A simplified analysis of the context where this alternative is adoptable is shown in Fig. 2.a. Moreover, by analyzing the elicited facts, the analyst can extract the conceptual data model the monitoring system has to instantiate to make facts validation possible. The analysis of the last context facts leads to the conceptual data model of Fig. 2.b. product to promote [p] in mal [m] can give more value to a related product [rp] that customer [c] already has
and [p] has a common use
with [rp] [c] does not already
have [p] [c] did not get [p] from [m] recently
and [c] did not buy [p] from [m] recently [p]compleme
nts [rp] functionality
We provide a set of modeling constructs to analyze high-level context statements
and to elicit the monitorable facts that are used to assign truth values to statements.
Context, the reification of the environment that surrounds the system and influences it,
can be monitored but not controlled by the system itself [
The objective method to compute a fact truth value requires monitoring some characteristics and history of a set of relevant environment elements.
Definition 2 (Statement) a boolean predicate specifying a current or a previous context, whose truth value can not be computed objectively.
Statement verification could not be objectively done because the system is not able to monitor and get all the data needed to compute the truth value of a statement, or because there could be no consensus about the way of knowing the truth value of a statement. Anyhow, to handle such problem we adopt a relaxed confirmation relation between facts, which are objectively computable by definition, and statements, in order to assign truth values to statements. We call this relation “help” and define it as following: Definition 3 (Help) Let f be a fact, s be a statement. help(f, s) ⇐⇒ f → s The relation help is strongly subjective, since different stakeholders could define different help relations for the same statement.
Definition 4 (And-decomposition) Let {s, s1, . . . , sn}, n ≥ 2 be statements (facts). and decomposed(s, {s1, . . . , sn}) ⇐⇒ s1 ∧ . . . ∧ sn → s Definition 5 (Or-decomposition) Let {s, s1, . . . , sn}, n ≥ 2 be statements (facts). or decomposed(s, {s1, . . . , sn}) ⇐⇒ ∀i ∈ {1, . . . , n}, si → s Here we give some examples to illustrate the previous concepts: – “two products, [p1] and [p2], are usually sold together” is a fact the system can verify through checking the sales record of all customers and check if the two products are often sold together. – “customer [c] is interested in the product [p]” is a statement since the system can not objectively compute its truth value. This statement can be Or-decomposed into “customer [c] is behaviorally interested in product [p]” and “customer [c] is historically interested in product [p]” substatements. The system can get some evidence of the first substatement through the help of the fact “[c] holds [p] for long time”, or the fact “[c] comes to [p] area so often”. The second substatement can be verified through the fact “[c] buys periodically [p]” or the fact “[c] buys usually of [p] category”. – “customer [c] does not have the product [p]” is a statement that can be verified through the fact “[c] did not get [p] recently from the mall [m]”, that is Anddecomposed into “[c] did not buy [p] recently from [m]” and ”[c] does not have [p] in his/her shopping cart”. However both facts do not ensure that the customer does not have the product (e.g., the system cannot verify if the customer was given the product as a gift, or bough it from another mall).
Our proposed hierarchical context analysis has the potential to make a context (i) more understandable for the stakeholders, (ii) easily modifiable as it is not given as one monolithic block, and (iii) more reusable as parts of the statement analysis hierarchy can be also used for other variation points or other stakeholders context specifications. Moreover, the analysis justifies why the monitoring system has to capture environmental data, as such data are needed to verify facts that in turn confirm or disapprove statements that are needed to make a decision at the variation points of the goal model. Specifying for each fact the related fragments of the data conceptual model is useful for purpose of tracking. For example, if for some reason, a group of stakeholders decided to drop, to alter, or to reuse one alternative, statement, or fact, we still can track which fragments in the conceptual data model could be influenced. 3
In this paper, we have introduced a goal-oriented framework for self-contextualizable
systems. We have discussed the self-contextualizability from goal-based perspective.
We have proposed the association between goal satisfaction alternatives and context.
In turn, context is defined through statement analysis that elicits the alternative sets of
facts the system has to validate on monitorable data so to confirm the high level
statements. As future work, we will define models covering all development phases of
selfcontextualizable software and a process to facilitate the development of high quality
self-contextualizable software. We also want to extend the formalization and reasoning
mechanisms we proposed in [
This work has been partially funded by EU Commission, through the SERENITY, and COMPAS projects, and by the PRIN program of MIUR under the MEnSA project. We would also like to thank Prof. Jaelson Brelaz de Castro for the valuable discussion we had about this work.