2.5 Summary
3.1.2 Constraints and Requests
An evolution problem consists of two sets of constraints; constraints created by the user request to change the system, and constraints required for the system to be valid. To clarify the purpose of these constraints, they are separated into two sets.
Definition 5 The set of user requests ∆ is the set of all constraints, where each constraint in ∆ is either:
1. an installation request of constraint type 3.
2. a remove request of constraint type 1.
3. a *grade3 request of constraint type 5.
Consider the examples of:
• an installation request a∨b is a request by the user to install component aor b into the system.
• a remove request ¬a is a request by the user to remove component a from the system.
3
• a *grade request a+b= 1 is a request by the user to include either a orb, but not both.
The *grade request uses the “exactly one” constraint (type 5) to represent both downgrade and upgrade requests from the user. The intuition is that after upgrading or downgrading a component, exactly one component should be included in the system (Treinen and Zacchiroli, 2009a).
Definition 6 The set of system constraintsΩis a set of all constraints, where each constraint in Ω is either:
1. a keep constraint of type 3.
2. a dependency constraint of type 4.
3. a conflict constraint of type 2.
Consider the examples of:
• a keep constraint a∨b is a system constraint to keep component a or b in the system.
• a dependency constraint a → b∨c is a system constraint where if a is in the system, thenborc must be in the system.
• a conflict constraint a → ¬b is a system constraint where if a is in the system thenb must not be in the system.
The evolution of a component system happens over time. This concept of “time” must be introduced to the model.
Definition 7 The setT is the set of all times. T is a strict total ordered under<time,
where times ti and ti+1 in T implies ti <timeti+1
At any time, there exists only a finite set of components.
Definition 8 Ct is the finite set of components that exists at time t, Ct⊂f inite C At any point in time, the sets of system constraints and user request constraints are with respect to the set of components that exist at that time. That is, a constraint can only describe systems that are composed of components that exist at a given time.
Definition 9 Given time t, and the set of components Ct, the set of system
constraints w.r.t. time is Ωt, where Ωt = {con∩2Ct | con ∈ Ω}, and the set of
user requests w.r.t. time is∆t, where ∆t={con∩2Ct |con∈∆}
Definition 10 Given a time t, a user request, δt, is a finite set of user requests at
timet, i.e. δt⊆f inite ∆t; and a set of system constraints,ωt, is a finite set of system
constraints at time t, i.e. ωt⊆f inite Ωt.
An evolution problem,EP, can be defined by combining a user request δt and a set of
system constraints ωt, such thatEP =δt∪ωt.
An example is presented to illustrate the relationship an evolution problem has to time. Consider the system constraint con1 that is defined asa → b∨d, and the user request constraintcon2defined asa(a singleton installation constraint). The constraint con1 can (but is not limited to) be satisfied by the component systems{},{b},{a, b},
{a, b, d}, and {a, d}, and the constraintcon2 can (but is not limited to) be satisfied by component systems{a},{a, b} and {a, b, d}.
Assume that at time t, only the components a and b exist, i.e Ct = {a, b}. The set
of all component systems at time tis 2Ct ={{},{a},{b},{a, b}}. Therefore, at time t
component ddoes not exist, it is not inCt, nor in any component system in 2Ct.
The system constraint con01 ∈ Ωt, is such that con01 = con1∩2Ct = {{},{b},{a, b}}. The user request constraintcon02∈∆t, is such that con02 =con2∩2Ct ={{a},{a, b}}. Assume a set of system constraints ωt = {con01}, and a user request constraints δt={con02}. An evolution problemδt∪ωt, will have exactly one solution, the component
system{a, b}.
3.1.3 Component System Evolution
A component system is changed from one system to another to satisfy an evolution problem containing a user request and system constraints. Many evolution problems have multiple valid solutions, as evolution problems are generally under-constrained (Le Berre and Parrain, 2008). Different solutions may have different properties, and as a result, a user may prefer one system over another. Introducing an ordering over the solutions addresses such user preferences.
Definition 11 Given a component system α, an evolution preference orderw.r.t. α is a strict partial order ≺α⊆2C×2C.
A strict partial order has the properties of irreflexivity (not β ≺α β), asymmetry (if
β ≺α β0 then not β0 ≺α β), and transitivity (if β ≺α β0 and β0 ≺α β00 then β ≺α β00). The non-strict evolution preference order α can be defined such that β ≺α β0 if and
only if (β αβ0 and β6=β0).
Definition 12 Given a component system α, an evolution preference order w.r.t. α
≺α, and an evolution problemEP; a component systemβ isoptimalif β is a solution
to EP, and there exists no other solution to EP β0, such thatβ ≺αβ0.
Definition 13 Given times ti−1 and ti, a component system αti−1, an evolution preference order ≺αti
−1, a user request δti, and a set of system constraints ωti; the
evolution step function (αti−1, δti∪ωti) returns the component systemαti such that:
• iff the evolution problemδti∪ωtiis satisfiable,αti is an optimal solution toδti∪ωti.
• iff the evolution problemδti∪ωti is unsatisfiable, αti equals αti−1.
The evolution step function takes a previous system and changes it to satisfy a user’s request and system constraints with a preferable system. If the evolution problem is unsatisfiable, the evolution step function does not change the system and returns the previous system αti−1. Such a situation occurs when the user requests a change that either conflicts with itself, or conflicts with the system constraints. For example, consider the situation where a user requested to install componentsaandb, butaandb conflict with each other. If this situation happened in reality, a report will be generated and returned to the user explaining why the evolution problem is unsatisfiable. This report may also include hints to the user as to how to make the request satisfiable. If an evolution problem is unsatisfiable, it could be possible to return a component system that maximises the number of satisfied constraints in the user request. This approach, however, is impossible to define as the intentions of a user request are unknown. For example, consider the situation where a user requested to install components a and b, but a and b conflict with each other. Which component should be selected to be installed in the system? Given the user request, this question cannot be answered. The user may only require a if b is installed, or vice versa. Making no assumptions about the intent of the user request is the prudent approach taken in this model.
Definition 14 Given a series of times t0, . . . , tn, an initial component system αt0, sets of components Ct1, . . . , Ctn, a series of user requests δt1, . . . , δtn, a series of system
constraints ωt1, . . . , ωtn, and a series of evolution preference orders ≺αt0, . . . ,≺αtn−1;
the evolution function ∗ is defined as
∗(αt0,hδt1∪ωt1, . . . , δtn∪ωtni) = ((. . . (αt0, δt1∪ωt1), . . .), δtn∪ωtn) =αtn.
This evolution function is the core definition in CoSyE as it describes the evolution process of repeatedly changing a component system. That is, the evolution function∗ is the “closure” of the evolution step function . An instance of CoSyE will contain:
• A series of times t0, . . . , tn.
• Sets of componentsCt0, . . . ,Ctn.
• Sets of user requestsδt1, . . . , δtn.
• Sets of system constraints ωt1, . . . , ωtn.
• Evolution preference orders ≺αt
0, . . . ,≺αtn−1.
• Initial system αt0.
This is enough information to calculate the system from αt1 to αtn, also known as
resolving a CoSyE instance.
The following observations can be made about the CoSyE model.
Observation 2 It is not required for an evolution step to satisfy prior user requests. For example, if a user wants to install a text editor into the system, the user would expect that in future the text editor will remain in the system. This property is not explicitly stated in the model, because (as described above) it is difficult to determine a user’s intention with a request.
A similar problem is faced by the revision function in the domain of belief revision (Alchourr´on et al., 1985). Revision functions try to preserve consistency across a set of beliefs as new, and possibly inconsistent, information is introduced. This is similar, as a set of previous user requests should try to remain satisfied with the component system, as the user requests to change the system. This problem with the evolution process is not further explored in this research, but belief revision may provide inspiration for future research.
Observation 3 Multiple evolution steps may produce a less optimal component system than an equivalent, single evolution step.
This can be demonstrated by describing an instance of CoSyE. Let the evolution preference order select solutions with the minimum number of components altered (the symmetric difference between the solutions), i.e. β ≺αβ0 iff |α∆β|>|α∆β0|. Further,
let:
• The times 0, 1 and 2.
• The set of components C0=C1 =C2 ={a, b, c, d}.
• The system at time 0 be α0 ={}.
• A series of user requests beδ1={a} and δ2 ={c}.
• The set of constraintsω1 =ω2 ={a→b∨c, c→d}. Consider the component evolution from α0 toα2:
• α0 ={}.
• α1 =(α0, δ1∪ω1), given the preference order ≺α0. |α0∆{a, b}|= 2 is minimal, therefore α1 ={a, b}.
• α2 = (α1, δ2 ∪ω2), given the preference order ≺α1. |α1∆{a, b, c, d}| = 4 is minimal, therefore α2 ={a, b, c, d}.
Further, consider the component evolution directly fromα0 toα2, whereδ20 =δ1∪δ2:
• α0 ={}.
• α20 =(α0, δ20 ∪ω2), given the preference order≺α0. |α0∆{a, c, d}|= 3 is minimal, therefore α02 ={a, c, d}.
In this example, the system α2 is less optimal than the system α02 w.r.t. the order
≺α0. This counter-intuitive result shows that the incomplete knowledge of future user requests may effect the optimality of the evolved component system.