using existing techniques developed for the GRL. The support for socio-technical modelling in the GRL makes it a good host language for modelling design patterns. With a DSML approach how pattern concepts are transformed into GRL concepts can be formally specified. Moreover, modellers are presented with constructions and idioms that are bespoke to design patterns.
A secondary concern is practical in nature. The GRL is a visual language that does not support directly DSML creation. Chapter 10 presents a reformulation of the GRL, NovoGRL to allow for creation of DSMLs.
5.3
Language Specification
This section presents the formal language specification for Sif detailing the abstract syn- tax, type system, and interpretation into a GRL model instance. Chapter 10 introduces and explains the syntax for the formal GRL notation used in this chapter.
5.3.1
Abstract Syntax
Figure 5.1 presents the abstract syntax for Sif together with nominal typing information. The type-system is explained further in §5.3.2. Documentation within Sif is treated as a first class language construct. Many of the core language constructs require that a descriptive title is to be given explicitly, together with an optional textual descrip- tion. Such first-class treatment ensures that information can be collected and used in the generation of the pattern document stubs. Much like their design, problem specifications are presented as constructs that require a title and description, and a set of requirements. Requirements are given a title and optional description, and different constructors are used to denote to which requirement type the requirement belongs to in the Furps model. Solution specifications are presented as a list of titled properties that require a set of traits to be given. For each trait in the property, the satisfaction value must be given together with a list of ‘affects’ that detail the effect that the trait has on a requirement. Finally, domains of operation can be constructed that are used within the type-system to ensure that the language constructs used within a single pattern only operate within the same domain.
5. Sif Sif=Sif | ϕ| p | γ | r | s | a | t | l ϕ∈Φ(γ) =Patternt d p s p∈P(γ) =Problemt d{r1, . . . , rn} r∈R(γ) =Functionalt d | Usabilityt d | Reliabilityt d | Performancet d | Supportabilityt d s∈S(γ) =Solutiont d{a1, . . . , an} a∈A(γ) =Propertyt d{t1, . . . , tn} t∈E(γ) =Advt d q{l1, . . . , ln} | Dist d q{l1, . . . , ln} | Gent d q{l1, . . . , ln} l∈L(γ) =Affectc r d γ∈G=Domaint d
q∈Q=Denied | wDenied |wSatisfied | Satisfied
| Conflict | Unknown | None
c∈C=Make | Help | SomePos | Unknown
| SomeNeg | Break | Hurt
t, d∈String=String Values
Figure 5.1: Abstract Syntax for the Sif modelling language.
5.3.2
Type-System
T=G | Q | C | Φ:G→T | P:G→T | R:G→T
| S:G→T | A:G→T | E:G→T | L:G→T
Figure 5.2: Types in the Sif modelling language.
Dependent types allow for types to depend on values. The types used to describe pattern constructs are parameterised by the domain of operation that these constructs must exist in. Use of dependent types in this manner allows for modelling constructs to change domain yet remain structurally intact. Further, dependent types allows for type-level guarantees to be made that problems and solutions must be in the same context when being paired. Figure 5.2 presents the types for Sif, these types have the 64
5.3. Language Specification following semantic meaning.
G the type given to a domain of operation. Q the type given to satisfaction values. C the type given to contribution values.
Φ the dependent type given to all patterns for a given domain.
P the dependent type given to all problems for a given domain. R the dependent type given to all requirements for a given domain.
S the dependent type given to all solutions for a given domain. A the dependent type given to all properties for a given domain. E the dependent type given to all traits for a given domain. L the dependent type given to all affects for a given domain.
With the set of types given, the typing rules for the language can be presented. With these typing rulescorrectness by constructionguarantees can be made with Sif model
instances. If a model is well-typed then it will also be structurally correct. Problems and Requirements
First the typing rules for declaring problems and requirements are presented.
Γ`t:String Γ`d:String Γ`γ:G Γ`(Functionalt d) :R(γ) Γ`t:String Γ`d:String Γ`γ:G Γ`(Usabilityt d) :R(γ) Γ`t:String Γ`d:String Γ`γ:G Γ`(Reliabilityt d) :R(γ) Γ`t:String Γ`d:String Γ`γ:G Γ`(Performancet d) :R(γ) Γ`t:String Γ`d:String Γ`γ:G Γ`(Supportabilityt d) :R(γ)
Γ`t:String Γ`d:String Γ`rs:List(R(γ)) Γ`γ:G
5. Sif
Traits and Affects
Next the rules governing creation of traits and affects are presented.
Γ`c:C Γ`r:R(γ) Γ`d:String Γ`γ:G
Γ`(Affectc r d) :L(γ)
Γ`t:String Γ`d:String Γ`as:List(L(γ)) Γ`γ:G
Γ`(Advt d as) :E(γ)
Γ`t:String Γ`d:String Γ`as:List(L(γ)) Γ`γ:G
Γ`(Gent d as) :E(γ)
Γ`t:String Γ`d:String Γ`as:List(L(γ)) Γ`γ:G
Γ`(Dist d as) :E(γ)
Solutions and Properties
The typing rules for solutions and properties are presented as follows.
Γ`t:String Γ`d:String Γ`as:List(E(γ)) Γ`γ:G
Γ`(Propertyt d as) :A(γ)
Γ`t:String Γ`d:String Γ`as:List(A(γ)) Γ`γ:G
Γ`(Solutiont d as) :S(γ)
Pattern
Finally the typing rule that governs the creation of patterns is given.
Γ`t:String Γ`d:String Γ`p:P(γ) Γ`s:S(γ) Γ`γ:G
Γ`(Patternt d p s) :Φ(γ)
5.3.3
Interpretation Semantics
This section details the interpretation semantics for constructing NovoGRL model instances1from a Sif model instance. Figure 5.3 presents the interpretation semantics for Sif using set notation to succinctly describe operations on lists. The interpretation is a two stage process: first the problem is interpreted into a goal model; and secondly, the solution is interpreted into a list of declarations that describe the elements of the interpreted solution and their links to the goals and other elements in the model. The
1As a reminder, the definition of NovoGRL syntax is detailed in Chapter 10.
5.3. Language Specification Sif:Sif→GRL Patternt d w s=w ]? {x | x←s} Problemt d{r1, . . . , rn}=; ] r]? cs](r∧cs) where r=GoaltUnknown cs={r | r←{r1, . . . , rn}} Functionalt d=GoaltUnknown
Usabilityt d=GoaltUnknown Reliabilityt d=GoaltUnknown Performancet d=GoaltUnknown Supportabilityt d=GoaltUnknown Solutiont d{a1, . . . , an}=n∪xs∪ds∪(n∧xs) where n=GoaltUnknown (xs, ds) ={([x,[xs) | (x, xs)←a, a←{a1, . . . , an}} Propertyt d{a1, . . . , an}= (n, n∪xs∪( [ dds)∪(n∧ xs)) where n=GoaltUnknown (xs, dds) ={([x,[rs) | (x, rs)←a, a←{a1, . . . , an}} Advt d q{l1, . . . , ln}= (n,{n c −→ r | (c, r)←l, l←{l1, . . . , ln}}) where n=Taskt q Dist d q{l1, . . . , ln}= (n,{n −c −→ r | (c, r)←l, l←{l1, . . . , ln}}) where n=Taskt q Gent d q{l1, . . . , ln}= (n,{n −→c r | (c, r)←l, l←{l1, . . . , ln}}) where n=Taskt q Linkc r d= (c,r)
Figure 5.3: Interpretation semantics for converting Sif expressions into GRL con- structs.
5. Sif
problem itself becomes the top most goal of the NovoGRL model, with the require- ments in the problem specification being interpreted as sub-goals linked using ‘and’ decomposition. Solutions are interpreted into a list of declarations. These declarations specify a secondary goal model that is composed of tasks that represent the constituent components of a solution specification (i.e. the solution itself, properties, traits and affects) arranged hierarchically usingANDdecomposition links. The resulting No-
voGRL model will have a task representing the solution as its top most task with sub tasks representing properties, and so on. The ‘affects’ model elements, represented by theLinkconstructor are used to link traits directly to requirements in the problem
using contribution links with the satisfaction value being specified in the Sif model. The satisfaction values given to traits are also used to provide a default satisfaction value for their GRL interpretation. For traits that represent disadvantages their satisfaction values are inverted to enable negative satisfaction values to be propagated through out the model. For instance, disadvantages that areSatisfiedwill becomeDenied, and thus Deniedwill be propagated. Had the satisfaction value not been inverted then only a
positive value would be propagated.
5.3.4
Model Evaluation
The evaluation of a Sif model instance seeks to determine how well the given problem specification is satisfied by the presented solution. That is:How do the traits specified in a solution’s properties affect the requirements of the problem presented? With Sif being
built upon NovoGRL, the existing evaluation semantics can be leveraged. To evaluate a Sif model instance it is first converted into the NovoGRL model represention, and the resulting model evaluated.
There are several known algorithms for evaluating GRL models—see Chapter 3 §3.2.2. For the structure of the GRL models that represent Sif models a forward evaluation algorithm is required to determine if the goal nodes, representing the problem and requirements, can be satisfied by the task nodes representing the traits. The other known algorithms do not propagate the values in the correct direction. Further, no initial evaluation strategy is required as the model is constructed with all leaf nodes initialised to a default value.