The concept of goal has long been used as useful abstraction in many areas of computer science, for example artificial intelligence planningnewell63 , agent-based systems BDIAgents95 , and knowledge management Jarvis01 . More recently, software engineering has also been using goals to model requirements for software systems, business objectives for enterprises, and design qualities anton96 ; anton98 ; dardenne93 ; Lamsweerde01 ; Giorgini04formalreasoning .
Goal-oriented requirements engineering approaches have gained popularity for a number of significant benefits in conceptualizing and analyzing requirements Lamsweerde01 . Goal models provide a broader system engineering perspective compared to traditional requirements engineering methods, a precise criterion for completeness of the requirements analysis process, and rationale for requirements specification, as well as automated support for early requirements analysis. Moreover, goal models are useful in explaining requirements to stakeholders, and goal refinements offer an accessible level of abstraction for validating choices among alternative designs.
Current goal modelling and reasoning techniques, however, have limitations with respect to expressiveness and/or scalability. Among leading approaches for goal modelling, KAOS offers a very expressive modelling language but reasoning isn’t scalable (in fact, it is undecidable). i*, on the other hand, is missing constructs such as preferences, priorities and optimization goals. Although more recent proposals, such as Techne JuretaBEM10 ; Liaskos10 offer expressive extensions to goal models, they still lack some features of our proposal, notably optimization goals, and also lack scalable reasoning facilities.
As a result of these deficiencies, no goal modelling framework can express goals such as “Select which new requirements to implement for the next release, such as to optimize customer value while maintaining costs below some threshold” and be able to reason about it and generate a specification/solution for it. As another example, consider a situation where a goal model changes and a new specification/solution needs to be generated for the new goal model. In this case, the new specification may be required to fulfill the evolution goal “Minimize implementation effort” or “Maximize user familiarity by changing as little as possible the new functionality of the system relative to the old one”. (For the latter case, see also Nguyen16 .) In both cases we are dealing with requirements that are beyond the state-of-the-art for goal modelling and reasoning. As we will discuss in §3, our proposal can accommodate such requirements both with respect to modelling and scalable reasoning.
We are interested in advancing the state-of-the-art in goal models and reasoning by proposing a more expressive modelling languages that encompasses many of the modelling constructs proposed in the literature, and at the same time offers sound, complete and tractable reasoning facilities. We are aiming for a goal modelling language in the spirit of Sebastiani et al. sebastiani_caise04 , rather than a social dependencies modelling language, such as i*. To accomplish this, we exploit advances in automated reasoning technologies, notably Satisfiability Modulo Theories (SMT) barrettsst09 and Optimization Modulo Theories (OMT) sebastiani15_optimathsat , to propose and formalize an extended notion of goal model, namely Constrained Goal Model (CGM).
CGMs treat (AND/OR) refinements as first class citizens allowing associated constraints, such as Boolean formulas or SMT/OMT formulas. For instance, when modelling a meeting scheduling system, we may want to express the fact that, to fulfill the nice-to-have requirement of keeping the scheduling fast enough (e.g., strictly less than 5 hours) we cannot afford both the time-consuming tasks of performing the schedule manually (3 hours) and of calling the participant one-by-one by phone (2 hours). CGMs provide user-friendly constructs by which we can encode constraints like this, either by adding Boolean formulas on the propositions which label such requirement and tasks, or by associating to those propositions numerical variables and by adding SMT formulas encoding mixed Boolean-arithmetical constraints on those variables and propositions. (See §3.) To the best of our knowledge, this was not possible with previous goal modelling techniques, including that in sebastiani_caise04 .
At the same time, the CGM tool we developed can cope with goal models an order of magnitude beyond what has been reported in the literature in most cases. In some cases involving optimization goals, e.g., “minimize development costs for the next release of software product S”, the CGM tool performs more modestly, but can still handle models of size in the hundreds of elements.
The main contributions of this work include:
An integration within one modelling framework of constructs that have been proposed in the literature in a piecemeal fashion, specifically,
Allow for explicit labelling of goal refinements with Boolean propositions that can be interactively/automatically reasoned upon;
Provide an explicit representation of domain assumptions to represent preconditions to goals;
Allow for Boolean constraints over goals, domain assumptions and refinements;
Provide a representation of preferences over goals and their refinements, by distinguishing between mandatory and nice-to-have requirements and by assigning preference weights (i.e., penalties/rewards) to goals and domain assumptions. Alternatively, preferences can be expressed explicitly by setting binary preference relations between pairs of goals or pairs of refinements;
Assign numerical attributes (e.g., resources like cost, worktime, and room) to goals and/or refinements and define constraints and multiple objective functions over goals, refinements and their numerical attributes.
Define optimization goals over numerical attributes, such as cost or customer value;
Fully support automated reasoning over CGMs that is both sound and complete, i.e., returns only solutions that are consistent with CGM semantics, and all such solutions;
Establish that reasoning with CGM models is scalable with models including thousands of elements.
Taking advantage of CGMs’ formal semantics and the expressiveness and efficiency of current SMT and OMT solvers, we also provide a set of automated reasoning functionalities on CGMs. Specifically, on a given CGM, our approach allows for:
the automatic check of the CGM’s realizability (i.e., check if the goal model has any solution);
the interactive/automatic search for realizations;
the automatic search for the “best” realization in terms of penalties/rewards and/or of user-defined preferences;
the automatic search for the realization(s) which optimize given objective functions.
Our approach is implemented as a tool (CGM-Tool), a standalone java application based on the Eclipse RCP engine. The tool offers functionalities to create CGM models as graphical diagrams and to explore alternatives scenarios running automated reasoning techniques. CGM-Tool uses the SMT/OMT solver OptiMathSAT sebastiani15_optimathsat ; st_tacas15 ; st_cav15 , which is built on top of the SMT solver MathSAT5 mathsat5_tacas13 , as automated reasoning backend. 111The OMT solver OptiMathSAT can be used also as an SMT solver if no objective function is set: in such case it works as a wrapper of MathSAT5.
The structure of the paper is as follows: §2 provides a succinct account of necessary background on goal modelling and on SMT/OMT; §3 introduces the notion of CGM through an example; §4 introduces the syntax and semantics of CGMs; §5 presents the set of automated reasoning functionalities for CGMs; §6 gives a quick overview of our tool based on the presented approach; §7 provides an experimental evaluation of the performances of our tool on large CGMs, showing that the approach scales well with respect to CGM size; §8 gives overview of related work, while in §9 we draw conclusions and present future research challenges.
Our research baseline consists of our previous work on qualitative goal models and of Satisfiability and Optimization Modulo Theories (SMT and OMT respectively). Our aim in this section is to introduce the necessary background notions on the these topics, so that the reader can follow the narrative in subsequent sections. As prerequisite knowledge, we assume only that the reader is familiar with the syntax and semantics of standard Boolean logic and of linear arithmetic over the rationals.
2.1 Goal Models.
Qualitative goal models are introduced in Mylopoulos92 , where the concept of goal is used to represent respectively a functional and non-functional requirement in terms of a proposition. A goal can be refined by means of AND/OR refinement relationships and qualitative evidence (strong and weak) for/against the fulfillment of a goal is provided by contribution links labelled etc. In Giorgini04formalreasoning , goal models are formalized by replacing each proposition , standing for a goal, by four propositions (, , , ) representing full (and partial) evidence for the satisfaction/denial of . A traditional implication such as is then translated into a series of implications connecting these new symbols, including , , as well as , , etc. The conflict between goals and is captured by axioms of the form , and it is consistent to have both and evaluated to true at the same time. As a result, even though the semantics of a goal model is a classical propositional theory, inconsistency does not result in everything being true. In fact, a predicate can be assigned a subset of truth values .
sebastiani_caise04 extended the approach further by including axioms for avoiding conflicts of the form . The approach recognized the need to formalize goal models so as to automatically evaluate the satisfiability of goals. These goal models, however, do not incorporate the notion of conflict as inconsistency, they do not include concepts other than goals, cannot distinguish “nice-to-have” from mandatory requirements and have no notion of a robust solution, i.e. solution without ”conflict”, where a goal can not be (fully or partially) denied and (respectively, fully or partially) satisfied at the same time.
2.2 Satisfiability and Optimization Modulo Theories.
Satisfiability Modulo Theories (SMT) is the problem of deciding the satisfiability of a quantifier-free first-order formula with respect to some decidable theory (see sebastiani07 ; barrettsst09 ). In this paper, we focus on the theory of linear arithmetic over the rationals, : is the problem of checking the satisfiability of a formula consisting in atomic propositions and linear-arithmetic constraints over rational variables like “”, combined by means of Boolean operators . (Notice that a Boolean formula is also a formula, but not vice versa.) An -interpretation is a function which assigns truth values to Boolean atoms and rational values to numerical variables; satisfies in , written “” –aka, is a solution for in – iff makes the formula evaluate to true; is -satisfiable iff it has at least one -interpretation s.t. .
An Optimization Modulo Theories over () problem is the problem of finding solution(s) to an formula which optimize the rational-valued objective functions , either singularly or lexicographically nieuwenhuis_sat06 ; st-ijcar12 ; sebastiani15_optimathsat ; st_tacas15 ). A solution optimizes lexicographically if it optimizes and, if more than one such -optimum solutions exists, it also optimizes ,…, and so on.
Very efficient and
solvers are available, which combine the power of modern SAT solvers with dedicated linear-programming decision and minimization procedures (seesebastiani07 ; barrettsst09 ; mathsat5_tacas13 ; nieuwenhuis_sat06 ; st-ijcar12 ; sebastiani15_optimathsat ; st_tacas15 ; st_cav15 ). For instance, in the empirical evaluation reported in sebastiani15_optimathsat the solver OptiMathSAT sebastiani15_optimathsat ; st_cav15 was able to handle optimization problems with up to thousands Boolean/rational variables in less than 10 minutes each.
3 Constrained Goal Models
The narrative of the next 3 sections is in line with the following schema.
In this section (§3), we introduce the notions of constrained goal model (CGM), and of realization of a CGM; we also present the automated-reasoning functionalities of our CGM-Tool through a meeting scheduling example (Figure 1), without getting into the formal details yet.
In §5 we describe how to support automated reasoning functionalities on CGMs by encoding them into SMT and OMT. We first show how to encode a CGM into a formula , so that the search for an optimum realization of reduces to an problem over the formula , which is then fed to an OMT solver. Then we present the reasoning functionalities over CGMs we have implemented on top of our OMT solver.
3.1 The CGM Backbone: Goals, Refinements, and Domain Assumptions.
We model the requirements for a meeting scheduling system, including the functional requirement , as well as non-functional/quality requirements , , and . They are represented as root goals.
Notationally, round-corner rectangles (e.g., ) are root goals, representing stakeholder requirements; ovals (e.g. ) are intermediate goals; hexagons (e.g. ) are tasks, i.e. non-root leaf goals; rectangles (e.g., ) are domain assumptions. We call elements both goals and domain assumptions. Labeled bullets at the merging point of the edges connecting a group of source elements to a target element are refinements (e.g., ), while the s denote their labels.
Unlike previous goal modelling proposals, refinements are explicitly labeled, so that stakeholders can refer to them in relations, constraints and preferences. (This fact will be eventually discussed with more details.) The label of a refinement can be omitted when there is no need to refer to it explicitly.
Intuitively, requirements represent desired states of affairs we want the system-to-be to achieve (either mandatorily or preferrably); they are progressively refined into intermediate goals, until the process produces actionable goals (tasks) that need no further decomposition and can be executed; domain assumptions are propositions about the domain that need to hold for a goal refinement to work. Refinements are used to represent alternatives of how to achieve a non-leaf element, i.e., a refinement of an element represents one of the alternative of sub-elements that are necessary to achieve it.
The principal aim of the CGM in Figure 1 is to achieve the requirement , which is mandatory. (A requirement is set to be mandatory by means of user assertions, see below.) has only one candidate refinement , consisting in five sub-goals: , , , , and . Since is the only refinement of the requirement, all these sub-goals must be satisfied in order to satisfy it. There may be more than one way to refine an element; e.g., is further refined either by into the single goal or by into the single goal . Similarly, and have three and two possible refinements respectively. The subgoals are further refined until they reach the level of domain assumptions and tasks.
The requirements that are not set to be mandatory are “nice-to-have” ones, like , , , and (in blue in Figure 1). They are requirements that we would like to fulfill with our solution, provided they do not conflict with other requirements.
3.2 Boolean Constraints: Relation Edges, Boolean Formulas and User Assertions.
Importantly, in a CGM, elements and refinements are enriched by user-defined Boolean constraints, which can be expressed either graphically as relation edges, or textually as Boolean or formulas, or as user assertions.
Relation Edges. We have three kinds of relation edges. Contribution edges “” between elements (in green in Figure 1), like “”, mean that if the source element is satisfied, then also the target element must be satisfied (but not vice versa). Conflict edges “” between elements (in red), like “”, mean that and cannot be both satisfied. Refinement bindings “” between two refinements (in purple), like “”, are used to state that, if the target elements and of the two refinements and , respectively, are both satisfied, then is refined by if and only if is refined by . Intuitively, this means that the two refinements are bound, as if they were two different instances of the same global choice.
For instance, in Figure 1, the refinements and are bound because such binding reflects a global choice between a manual approach and an automated one.
Boolean Formulas. It is possible to enrich CGMs with Boolean formulas, representing arbitrary constraints on elements and refinements. Such constraints can be either global or local to elements or to refinements, that is, each goal can be tagged with a pair of prerequisite formulas –called positive and negative prerequisite formulas respectively– so that [resp. ] must be satisfied when is satisfied [resp. denied]. (The same holds for each requirement .)
For example, to require that, as a prerequisite for , and cannot be both satisfied, one can add a constraint to the positive prerequisite formula of :
or, equivalently, add globally to the CGM the following Boolean formula:
User Assertions. With CGM-Tool, one can interactively mark [or unmark] requirements as satisfied (true), thus making them mandatory (if unmarked, they are nice-to-have ones). In our example is asserted as true to make it mandatory, which is equivalent to add globally to the CGM the unary Boolean constraint:
Similarly, one can interactively mark/unmark (effortful) tasks as denied (false). More generally, one can mark as satisfied or denied every goal or domain assumption. We call these marks user assertions, because they correspond to asserting that an element must be true, i.e., it is part of the solutions we are interested in, or false, i.e., we are interested in solutions that do not include it.
Notice that the process of marking/unmarking elements is conceived to be more interactive than that of adding/dropping relation edges or constraints.
3.3 Arithmetical Constraints: Numerical Attributes and Formulas
Numerical Attributes. In addition to Boolean constraints, it is also possible to use numerical variables to express different numerical attributes of elements (such as cost, worktime, space, fuel, etc.) and to add arithmetical constraints in the form of formulas over such numerical variables.
For example, suppose we estimate that fulfillingcosts 80€, whereas fulfilling costs 200€. With CGM-Tool one can express these facts straightforwardly by adding a global numerical variable to the model;
then, for every element in the CGM, CGM-Tool automatically generates a numerical variable representing the attribute of the element , it adds the following defaultglobal constraint and prerequisite formulas:
|for every element ,||(6)|
that set the default value 0 for each . (Notice that (4) is a default global constraint: the user is free to define his/her own objective functions.) Eventually, for the elements of interest, one can set a new value for in case is satisfied: e.g., and . When so, CGM-Tool automatically updates the values in the positive prerequisite formulas (6), e.g.:
Formulas. Suppose that, in order to achieve the nice-to-have requirement , we need to have a total cost smaller than 100€. This can be expressed by adding to the prerequisite formula:
Similarly to , one can introduce, e.g., another global numerical attribute to reason on working time, and estimate, e.g., that the total working time for , , , , are 3, 1, 1, 2, and 1 hour(s), respectively, and state that the nice-to-have requirement must require a global time smaller than 5 hours. As a result of this process, the system will produce the following constraints.
plus the corresponding negative prerequisite formula, which force the corresponding numerical attributes to be zero.
As with the previous case, e.g., the arithmetic constraints make the combination of and incompatible with the nice-to-have requirement .
Notice that one can build combinations of numerical attributes. E.g., if labor cost is , then one can redefine as , or introduce a new global variable as .
Although the nice-to-have requirements and look isolated in Figure 1, they are implicitly linked to the rest of the CGM by means of arithmetic constraints on the numerical variables and respectively, which implicitly imply Boolean constraints like:
Nevertheless, there is no need for stakeholders to consider these implicit constraints, since they are automatically handled by the internal reasoning capabilities of CGM-Tool.
3.4 Realizations of a CGM.
We suppose now that is marked satisfied by means of an user assertion (i.e. it is mandatory) and that no other element is marked. Then the CGM in Figure 1 has more than 20 possible realizations. The sub-graph which is highlighted in yellow describes one of them.
Intuitively, a realization of a CGM under given user assertions represents one of the alternative ways of refining the mandatory requirements (plus possibly some of the nice-to-have ones) in compliance with the user assertions and user-defined constraints. It is a sub-graph of the CGM including a set of satisfied elements and refinements: it includes all mandatory requirements, and [resp. does not include] all elements satisfied [resp. denied] in the user assertions; for each non-leaf element included, at least one of its refinement is included; for each refinement included, all its target elements are included; finally, a realization complies with all relation edges and with all Boolean and constraints. (Notationally, in Figures 1, 2 and 3 a realization is highlighted in yellow, and the denied elements are visible but they are not highlighted.)
Apart from the mandatory requirement, the realization in Figure 1 allows to achieve also the nice-to-have requirements , , but not and ; in order to do this, it requires accomplishing the tasks , , , , , , , , and it requires the domain assumption .
3.5 Setting Preferences in a CGM.
In general, a CGM under given user assertions has many possible realizations. To distinguish among them, stakeholders may want to express preferences on the requirements to achieve, on the tasks to accomplish, and on elements and refinements to choose. The CGM-Tool provides various methods to express preferences:
attribute penalties and rewards for tasks and requirements;
introduce numerical objectives to optimize;
introduce binary preference relations between elements and between refinements.
These methods, which are described in what follows, can also be combined.
Preferences via Penalties/Rewards. First, stakeholders can define two numerical attributes called and , then stakeholders can assign penalty values to tasks and reward values to (non-mandatory) requirements (the numbers “” and “” in Figure 1). This implies that requirements [resp. tasks] with higher rewards [resp. smaller penalties] are preferable. Next, stakeholders can define another numerical attribute , that represents the total difference between the penalties and rewards. (This can be defined as a global constraint: .) When a model represents preferences, an OMT solver will look for a realization that minimizes its global weight. For instance, one minimum-weight realization of the example CGM, as shown in Figure 2, achieves all the nice-to-have requirements except , with a total weight of , which is the minimum which can be achieved with this CGM. Such realization requires accomplishing the tasks , , , , , , and , and requires no domain assumption. (This was found automatically by our CGM-Tool in seconds on an Apple MacBook Air laptop.)
Preferences via Multiple Objectives. Stakeholders may define rational-valued objectives to optimize (i.e., maximize or minimize) as functions of Boolean and numerical variables —e.g., , , can be suitable objectives— and ask the tool to automatically generate realization(s) which optimize one objective, or some combination of more objectives (like ), or which optimizes lexicographically an ordered list of objectives . (We recall that a solution optimizes lexicographically an ordered list of objectives if it makes optimum and, if more than one such solution exists, it makes also optimum, …, etc.) Notice that lexicographic optimization allows for defining objective functions in a very fine-grained way and for preventing ties: if the stakeholder wants to prevent tie solutions on objective , he/she can define one further preference criterion in case of tie on , and so on.
Importantly, our CGM-Tool provides some pre-defined objectives of frequent usage. (see last paragraph) is one of them. Other examples of pre-defined objectives stakeholders may want to minimize, either singularly or in combination with other objectives, are:
the number of nice-to-have requirements which are not included in the realization;
the number of tasks which are included in the realization;
the number of user-defined binary preference relations which are not fulfilled by the realization (see later).
For example, the previously-mentioned optimum-weight realization of Figure 2 is such that , and . Our CGM has many different minimum-weight realizations s.t. , with different values of and . Among them, it is possible to search, e.g., for the realizations with minimum , and among these for those with minimum , by setting lexicographic minimization with order . This results into one realization with , and achieving all the nice-to-have requirements, as shown in Figure 3, which requires accomplishing the tasks: , , , , , , , , , , and which requires the domain assumptions: , . (This was found automatically by our CGM-Tool in seconds on an Apple MacBook Air laptop.)
Preferences via Binary Preference Relations. In general, stakeholders might not always be at ease in assigning numerical values to state their preferences, or in dealing with terms, constraints and objectives. Thus, as a more coarse-grained and user-friendly solution, it is also possible for stakeholders to express their preferences in a more direct way by stating explicitly a list of binary preference relations, denoted as “”, between pairs of elements of the same kind (e.g. pair of requirements, of tasks, of domain assumptions) or pairs of refinements. “” means that one prefers to have satisfied than satisfied, that is, that he/she would rather avoid having denied and satisfied. In the latter case, we say that a preference is unsatisfied. Notice that allows for having both and satisfied or both denied.
These are binary preferences, so that they say nothing on the fact that each is singularly desirable or not, which in case must be stated separately (e.g., by penalties/rewards.) Thus, the fact that a binary preference allows for having both and denied should not be a surprise: if both and violated , then would play no role in the preference, so that it would reduce to the unary preference “I’d rather have than not have it.” A dual argument holds for the fact that allows for having both and satisfied.
Also, this choice is a very general one, since it implements the case in which are both desirable/rewarding (“I prefer winning the Turing Award than winning at the lottery.”) like the preference between two requirements, as well as the opposite case in which they are both undesirable/expensive (“I prefer being shot than being hanged.”) like the preference between two tasks, plus obviously the trivial case in which is desirable and is undesirable. If this choice is considered too general, then the stakeholder can add mutual-exclusion constraints, or combine it lexicographically with penalty/rewards, or directly use penalty/rewards instead.
With CGM-Tool, binary preference relations can be expressed either graphically, via a “prefer” arc “”, or via and ad-hoc menu window. Once a list of binary preference relations is set, the system can be asked to consider the number of unsatisfied preference relations as a pre-defined objective (namely ), and it searches for a realization which minimizes it. It is also possible to combine such objective lexicographically with the other objectives.
One typical usage we envision for binary preferences is between pairs of refinements of the same element –or equivalently, in case of single-source refinements, between their relative source elements. This allows for expressing stakeholders’ preferences between possible ways one intermediate element can be refined.
For example, suppose we want to minimize the total weight of our example goal model. As previously mentioned, there is more than one realization with minimum weight . Unlike the previous example, as a secondary choice we disregard and ; rather, we express also the following binary preferences:
(Notice that the goal preferences in (15) are pairwise equivalent to the following refinement preferences:
Then we set as secondary objective to minimize after , that is, we set the lexicographic order . Then our tool returned the same realization of Figure 3 —that is, the same as with minimizing and as secondary and tertiary choice— instead of that in Figure 2. (This solution was found in seconds on an Apple MacBook Air laptop.)
4 Abstract Syntax and Semantics
In this section we describe formally the abstract syntax and semantics of CGMs.
4.1 Abstract Syntax
We introduce first some general definitions. We call a goal graph a directed acyclic graph (DAG) alternating element nodes and refinement nodes (collapsed into bullets), s.t.: each element has from zero to many outgoing edges to distinct refinements and from zero to many incoming edges from distinct refinements; each refinement node has exactly one outgoing edge to an element (target) and one or more incoming edges from distinct elements (sources).
We call a root element node any element node that has no outgoing refinement edges, a leaf element node any (non-root) element node that has no incoming refinement edges, and an internal element node any other element node. (Hereafter we will usually drop the word “node”, simply saying “refinement” for “refinement node”, “element” for “element node”, etc.)
Notice that, by construction, only elements can be roots and leaves of a goal graph. The sets of root, leaf and internal elements of a goal graph are denoted as , , respectively. Given a refinement with outgoing edge to the element and incoming edges from the element s , we call the source elements of and the target element of , which are denoted by and respectively. We say that is a refinement of and that refines into , denoted “”. The set of refinements of an element are denoted with .
Elements are goals or domain assumptions, subject to the following rules:
a domain assumption cannot be a root element;
if the target of a refinement is a domain assumption, then it sources are only domain assumptions;
if the target of a refinement is a goal, then at least one of its sources is a goal.
We call root goals and leaf goals requirements and tasks respectively.
|Constructor||Textual Representation||Graphical Representation||Propositional Encoding|
Notationally, we use the symbols , for labeling refinements, , for generic elements (without specifying if goals or domain assumptions), , for goals, , for domain assumptions. Graphically (see Figure 1) we collapse refinements nodes into one bullet, so that we see a refinement as an aggregation of edges from a set of other goals. (See Table 1.) Hence, in a goal graph we consider element nodes as the only nodes, and refinements as (aggregations of) edges from a group of source elements to a target element.
Definition 1 (Constrained Goal Model)
A Constrained Goal Model (CGM) is a tuple , s.t.
is a set of atomic propositions, where , , are respectively sets of goal, refinement and domain-assumption labels. We denote with the set of element labels: ;
is a set of numerical variables in the rationals;
is a goal graph, s.t. all its goal nodes are univocally labeled by a goal label in , all its refinements are univocally labelled by a refinement label in , and all its domain assumption are univocally labeled by a assumption label in ;
is a formula on and .
A CGM is thus a “backbone” goal graph –i.e., an and-or directed acyclic graph (DAG) of elements, as nodes, and refinements, as (grouped) edges, which are labeled by atomic propositions in – which is augmented with an formula on the element and refinement labels in and on the numerical variables in . The formula is a conjunction of smaller formulas encoding relation edges, global and local Boolean/ constraints, user assertions, and the definition of numerical objectives, all of which will be described later in this section.
Intuitively, a CGM describes a (possibly complex) combination of alternative ways of realizing a set of requirements in terms of a set of tasks, under certain domain assumptions and constraints. A couple of remarks are in order.
The fact that the goal graph is an and-or graph can be deduced from the propositional encoding of Goal refinement and Closed World in Table 1: by combining the propositional encodings of goal refinement and Closed World in Table 1, we can infer the formulas: 222We recall that in Boolean logic the formula , which comes from the goal refinement encoding in Table 1, is equivalent to . The latter, combined with the encoding of Closed World , gives the left formula in (17). The right formula in (17) is the other part of the goal refinement encoding in Table 1.
Thus, each non-leaf element is or-decomposed into the set of its incoming refinements , and each refinement is and-decomposed into the set of its source elements .
CGMs are more succinct in terms of number of goals than standard and-or goal models. On the one hand, a standard -ary and-decomposition of a goal can be represented straightforwardly in a CGM by one refinement with sources (Figure 4, Top), and an or-decomposition by one-source refinements (Figure 4, Middle), so that no extra goals are added. On the other hand, in order to represent a piece of CGM with non-unary refinements by standard goal models, we need introducing new auxiliary intermediate goals to encode refinements, which CGMs encode natively (Figure 4, Bottom). We recall from §3 that refinements do not need to be explicitly labeled unless they need to be mentioned in other parts of the model.
Stakeholders might not be at ease in defining a possibly-complex global formula to encode constraints among elements and refinements, plus numerical variables. To this extent, as mentioned in §3, apart from the possibility of defining global formulas, CGMs provide constructs allowing the user to encode graphically and locally desired constraints of frequent usage: relation edges, prerequisite formulas and and user assertions. Each is automatically converted into a simple formula as follows, and then conjoined to .
, meaning that satisfying forces to be satisfied (but not vice versa). They are encoded into the formula . (The edge can be used to denote the merging of the two contribution edges and into one.)
, meaning that and cannot be both satisfied. They are encoded into the formula .
, meaning that, if both the target goals of and (namely and respectively) are satisfied, then refines if and only if refines . They are encoded into the formula .
and , are encoded into the formulas , respectively.