87、基于Alloy语言定义建模语言的形式语义

基于Alloy语言定义建模语言的形式语义

1. 集合运算与状态更新

在定义建模语言的形式语义时，集合运算起着重要作用。为了保持状态的确定性，在事件调用期间，对于实例属性的修改通常采用普通的集合并运算。而在收集替换项时，为了确保动态语义的确定性，即事件调用期间实例属性最多进行一次修改，会使用不相交集合并运算（用⊎表示）来强制实现不相交的域。在规则EventInvocationReduction中，累积的替换项和新实例通过应用到原始状态来生效，从而达到新的状态：(s ∪s∆)σ。

2. Alloy语言概述

Alloy是一种能够精确且简洁地表达软件抽象的语言。使用Alloy对系统进行建模时，会使用一组称为签名（signature）的类型。每个签名可以有多个字段，还可以添加约束（facts）来表达系统的额外属性。Alloy在严谨性上可与传统的形式化方法相媲美，其独特之处在于Alloy Analyzer工具，该工具可以对系统进行全自动分析，能尽早发现系统中的缺陷，从而鼓励进行增量式开发。

Alloy Analyzer可以执行两种类型的分析：
- 搜索满足谓词的实例（通过为签名填充元素获得）。
- 寻找断言的反例。

这两种分析都依赖于小范围假设，即假设如果存在实例或反例，那么一定存在小尺寸的实例或反例，因此只搜索有限的子空间。

3. 抽象语法和静态语义

Alloy模型可以同时表达抽象语法和静态语义。下面通过与元模型进行对比来解释Alloy模型。元模型中的八个类在Alloy模型中都有对应的签名，且名称相似。例如，元模型中的System类由EPSystem签名表示，元模型中的关联通常由签名的字段表示，如EPSystem中的models字段对应元模型中System类到Model类的聚合关系。元模型中关联端的多重性通常在Alloy模型中表示为约束。

以下是表达抽象语法和静态语义的Alloy模型代码：

sig EPSystem {models: some EPModel} {one (models & Main)}
sig EPModel {properties: set Property, events: set Event}
{one s:EPSystem | this in s.models}
sig Main extends EPModel { }

sig Property { type: EPModel } {one m:EPModel | this in m.properties}
pred Property::sameModel[p:Property] {this.~properties=p.~properties}

sig Event {feedsOn: set Property, params: set Parameter,
  edges: set PushEdge, impactEdges: set ImpactEdge}
fact { all e:Event | { e.feedsOn in (e.~events).properties
  all g:e.edges|{e.sameModel[g.link] && g.link.type=g.into.~events
    conformMapping[g.mappings, g.into.params]
    all m:g.mappings | { m.expr.usesProps in e.feedsOn &&
      m.expr.usesParams in e.params}
    all c: e.impactEdges | { e.sameModel[c.impact] &&
      c.expr.usesProps in e.feedsOn &&
      c.expr.usesParams in e.params }
    one m:EPModel | e in m.events }}}
pred Event::sameModel[p:Property] {this.~events = p.~properties}
pred Event::sameModel[e:Event] {this.~events = e.~events}

sig PushEdge {into:Event,link: Property,mappings:set ParameterMapping}
{ one e:Event | this in e.edges }
fun PushEdge::paramExpr[p:Parameter]: Expression {
  (p.(~param) & this.mappings).expr}
sig ImpactEdge {impact: Property,expr: Expression}
{expr.type =impact.type && one e:Event | this in e.impactEdges}

sig Parameter{type: EPModel} { one e:Event | this in e.params }
sig ParameterMapping {param: Parameter,expr: Expression}
{ expr.type=param.type }
pred conformMapping(m:set ParameterMapping, x: set Parameter) {
  # m = # x && m.param = x }

sig Expression { type: EPModel, usesProps: set Property,
  usesParams: set Parameter }

在这个Alloy模型中，有两个签名在元模型中没有对应的类：
- Main签名表示存在一个名为Main的特殊模型，这在元模型中通过System到Model的关联来表示。
- ParameterMapping签名表示参数和表达式之间的对应关系，在元模型中，每个事件有一个有序的参数序列，每个推送边有一个有序的表达式序列，假设这两个序列是一一对应的。

由于结构属性和格式良好性规则都通过Alloy模型中的约束来表达，且两者之间没有自然的分离，因此选择使用单个Alloy模型来表达示例语言的抽象语法和静态语义。此外，Alloy Analyzer允许以图形方式展示由Alloy模型指定的元模型。

4. 动态语义

为了描述动态语义，在Alloy模型中引入了状态（State签名）和实例（EPInstance签名）的概念。一个实例有一个类型（EPModel），并且对于每个状态，每个属性最多分配一个值。EPInstance的neighbors字段包含在给定状态下该实例的某个属性所引用的所有实例。属性的值可以是null或另一个实例，在Alloy模型中，Value是一个抽象签名（即没有元素可以具有该类型），EPInstance和NullValue是Value的仅有的具体子签名（即子集）。

使用ExpressionValue签名来抽象表达式语言，它给出了表达式（expr字段）在给定属性和参数值（settings字段）下的值（val字段）。系统的实际行为在step谓词中指定，该谓词表示状态s2是由状态s1触发实例事件i而得到的。实例事件（InstanceEvent签名）包含了在哪个实例上触发了哪个事件以及给定状态下的参数值等信息。

以下是描述动态语义的Alloy模型代码：

open meta_small
open util/ordering[State] as SO -- ordered set of states
sig State { }
pred State::init { MainInstance::defaultVal[this] }
sig EPInstance extends Value {
  type: EPModel,
  neighbors: EPInstance -> State,
  valuations: State -> Property -> Value 
}
{ all s: State | {
  this.reachable[s] => all p: type.properties|one this.val[p,s]
  neighbors.s = {x: EPInstance | some p: type.properties |
    s.valuations[p] = x } }}
fact {
  all s: State| all y: EPInstance | all ev:Event |
  ( y.reachable[s] && ev in y.type.events ) =>
  some i: InstanceEvent | ( i.e =ev && i.x =y ) }
fun EPInstance::val [p:Property,s:State]:Value{p.(this.valuations[s])}
pred EPInstance::defaultVal[s: State] {
  all p: this.type.properties | this.val[p,s] = NullValue }
pred EPInstance::reachable[s: State]{
  this in MainInstance.*(neighbors.s) }
one sig MainInstance extends EPInstance { }{type = Main}

abstract sig Value{}
sig NullValue extends Value { }
sig ExpressionValue
{
  expr: Expression,
  setting: (Property + Parameter) -> lone Value,
  val: Value
}
{ setting.Value & Property = expr.usesProps
  setting.Value & Parameter = expr.usesParams }

sig InstanceEvent { e: Event, x: EPInstance,
  v: State-> Parameter -> lone Value,
  succ: InstanceEvent -> State }
{ let exprs = e.impactEdges.expr + e.edges.mappings.expr |
  all s: State | all ex:exprs | one exprVal[this,s,ex]
  e.~events = x.type
  all s: State | {s.v.Value = e.params &&
  {all j: succ.s|some g: e.edges| j.successorOf[this,s,g]} &&
  { all g: e.edges
  | let v = x.val[g.link,s]|
    v != NullValue => some j: succ.s| j.successorOf[this,s,g]}}}
pred InstanceEvent::paramsOk[i:InstanceEvent, g: PushEdge, s:State] {
  all p:i.e.params | let ex = g.paramExpr[p] |
  p.(s.(i.v)) = exprVal[this, s, ex].val }
pred InstanceEvent::successorOf(i:InstanceEvent,s:State,g:PushEdge){
  g in i.e.edges && this.paramsOk[i,g,s] &&
  this.e = g.into && this.x = (i.x).val[g.link,s] }
fun InstanceEvent::exprVal[s: State,e: Expression]:ExpressionValue{
  { ev:ExpressionValue| ev.expr = e
    &&
    (all p: e.usesParams
    | ev.setting[p] = p.(s.(this.v))) &&
    (all p: e.usesProps
    | ev.setting[p] = this.x.val[p,s]) }}

pred step[s1: State, i: InstanceEvent, s2: State] {
  let scope = i.*(succ.s1) | {
    all y: scope.x | let iScope = (y.~x) & scope | {
      all p: y.type.properties| { p not in iScope.e.impactEdges.impact
      => y.val[p,s2] = y.val[p,s1]}
      all j: iScope | all g: j.e.impactEdges |
      y.val[g.impact,s2] = exprVal[j,s1,g.expr].val }
    all y: EPInstance-scope.x | all p: y.type.properties
    |
    y.val[p,s2] = y.val[p,s1] }}

计算实例事件的效果时，只需考虑通过推送边直接或间接继承该实例事件的所有实例事件。这通过计算InstanceEvent签名的后继关系succ在状态s1下的自反和传递闭包来表示，该闭包在step谓词中用scope变量表示。然后考虑在scope中有相关实例事件的所有实例，并将注意力集中在与每个实例相关的scope中的实例事件上，用iScope变量表示。为了表达新状态s2，对于iScope中实例事件所产生的影响边的目标属性，使用exprVal函数计算与该边关联的表达式的值，并将该属性在状态s2中的值设置为该计算值。iScope中未被影响边针对的属性以及不在scope中的实例的属性在s2和s1中的值相同。

下面是动态语义的执行流程mermaid图：

graph TD;
    A[状态s1] --> B[触发实例事件i];
    B --> C[计算scope = i.*(succ.s1)];
    C --> D[遍历scope中的实例y];
    D --> E[计算iScope = (y.~x) & scope];
    E --> F[处理iScope中的实例事件];
    F --> G[计算影响边目标属性的新值];
    G --> H[更新状态到s2];
    D --> I[处理不在scope中的实例];
    I --> J[属性值保持不变];

5. 与传统方法的比较

在定义建模语言的形式语义时，传统方法和基于Alloy的方法各有特点。下面从符号复杂性和语义规范的可分析性两个方面进行比较。

5.1 符号复杂性

• 抽象语法和静态语义 ：传统方法有两种，一种是EBNF和类型检查，另一种是元建模。EBNF和元建模都能简洁地描述抽象语法，但OCL约束提供的静态语义描述比类型检查方法更易于理解。类型检查方法具有更强的数学风格和更高的密度，这可能是其在建模社区中广泛应用的障碍，因为该技术在建模社区中不太为人所知。而元建模和Alloy方法在符号复杂性上相似，从对Alloy方法的解释中可以明显看出它们与元模型的紧密对应关系。
• 动态语义 ：传统方法采用操作语义，而另一种是基于Alloy的方法。操作语义具有很强的数学风格，符号非常紧凑，依赖于许多特殊符号；而Alloy模型更像是用面向对象编程语言编写的模块，这应该会使Alloy在建模社区中更容易被采用。

从整体上看，传统方法至少需要两种不同的符号（例如元建模和操作语义）来指定语言，而Alloy使用单一的符号处理抽象语法、静态语义和动态语义三个部分，这是Alloy方法的一个优势。

语义类型	传统方法	Alloy方法
抽象语法和静态语义	EBNF、类型检查、元建模	单一Alloy模型
动态语义	操作语义	Alloy模型

5.2 可分析性

可分析性指的是使用自动工具分析规范正确性的可能性。验证除最简单语言之外的所有语言的语义都是一项重要的任务，如果没有工具支持来检查形式化描述，对形式化描述的正确性的信心通常不会很强。即时可分析性对于支持语义规范的机会主义设计也很重要，这似乎是人类设计复杂对象（如形式语义）的首选方式。

传统方法有一些工具支持，例如可以使用USE工具检查带有约束的元模型，操作语义的检查通常通过手动证明、使用证明助手证明某些属性成立，或者将其规则实现为代码，然后对代码进行测试或形式验证。但手动证明和代码实现都容易出错，而且传统方法的多样性使得自动检查的难度明显高于Alloy，因为Alloy自带强大的Alloy Analyzer工具。

Alloy Analyzer工具可以立即检查当前（部分）规范的正确性（在有限范围假设的限制内），在实际应用中，该工具帮助发现了形式语义编写过程中的早期错误。具体例子如下：
- 工具执行标准的语法检查，揭示签名的错误使用（例如访问签名中不存在的字段）。
- 通过将OCL约束表述为Alloy中的断言，并使用Analyzer寻找反例，来检查Alloy中静态语义与元模型的一致性。
- 通过“运行”一个示例EP系统（即让Analyzer生成满足step谓词的实例）并观察其是否按预期“行为”，来检查动态语义。

6. 结论

定义建模语言的形式语义对于语言推理和提供工具支持非常重要。当前的形式化语义方法在实践中往往难以使用，这可能解释了为什么许多建模语言缺乏形式语义描述。

基于Alloy语言的方法为定义建模语言的抽象语法、静态语义和动态语义提供了一种新颖的途径。该方法的两个关键优势是符号复杂性低（部分原因是只需处理单一符号，而不是针对不同方面使用多个符号）和自动可分析性。

Alloy是作为一种轻量级的软件开发抽象方法而开发的，它鼓励进行软件模型的增量式开发，并以较低的成本获得传统形式化方法的一些好处。基于实践经验，相信Alloy的这些特点也适用于形式模型语义领域，从而使形式语义在建模语言的定义中更易于理解和广泛采用。

虽然本文通过一个具体示例说明了Alloy在指定形式语义方面的应用，但未来的工作需要分析基于Alloy的方法适用于哪些类型的建模语言。还应该将Alloy与其他竞争的形式化方法（如基于抽象状态机或条件重写逻辑的方法）进行比较，以研究每种方法在不同类别的建模语言中的优缺点。

基于Alloy语言定义建模语言的形式语义

7. Alloy方法的优势总结

基于前面的分析，Alloy方法在定义建模语言形式语义方面的优势较为明显，下面以列表形式详细总结：
- 符号简洁统一 ：使用单一的Alloy符号就能涵盖抽象语法、静态语义和动态语义，避免了传统方法需要多种不同符号的复杂性，降低了学习和使用成本。
- 易于理解 ：Alloy模型的表现形式更接近面向对象编程语言的模块，相较于传统方法中具有强烈数学风格和大量特殊符号的表示，更容易被建模社区的人员接受。
- 自动分析 ：自带强大的Alloy Analyzer工具，能够对规范进行全自动分析，可及时发现早期错误，增强了对形式化描述正确性的信心，支持机会主义设计。
- 与元模型对应紧密 ：在表达抽象语法和静态语义时，与元模型有清晰的对应关系，便于理解和实现。

8. 实际应用案例分析

为了更直观地展示Alloy方法的应用效果，下面通过一个简化的实际案例进行分析。假设我们要设计一个简单的图书馆管理系统建模语言，使用Alloy方法来定义其形式语义。

8.1 抽象语法和静态语义

首先，定义相关的签名和约束：

sig LibrarySystem {
    books: set Book,
    borrowers: set Borrower
} {
    one (books & MainBook)
}

sig Book {
    title: String,
    author: String
} {
    one l: LibrarySystem | this in l.books
}

sig Borrower {
    name: String,
    borrowedBooks: set Book
} {
    one l: LibrarySystem | this in l.borrowers
    all b: borrowedBooks | b in l.books
}

sig MainBook extends Book { }

在这个Alloy模型中， LibrarySystem 签名表示图书馆系统，包含书籍和借阅者。 Book 签名表示书籍，有标题和作者属性。 Borrower 签名表示借阅者，有姓名和借阅的书籍属性。通过约束确保了书籍和借阅者都属于某个图书馆系统，并且借阅者借阅的书籍必须是该图书馆系统中的书籍。

8.2 动态语义

引入状态和实例的概念，定义系统的动态行为：

open util/ordering[State] as SO

sig State { }

sig LibraryInstance extends Value {
    type: LibrarySystem,
    bookStates: State -> Book -> BorrowStatus,
    borrowerStates: State -> Borrower -> BorrowerStatus
} {
    all s: State | {
        all b: type.books | one this.bookState[b, s]
        all br: type.borrowers | one this.borrowerState[br, s]
    }
}

abstract sig Value { }
sig BorrowStatus extends Value { }
sig BorrowerStatus extends Value { }

sig InstanceEvent {
    e: Event,
    x: LibraryInstance,
    v: State -> Parameter -> lone Value,
    succ: InstanceEvent -> State
}

pred step[s1: State, i: InstanceEvent, s2: State] {
    let scope = i.*(succ.s1) | {
        all y: scope.x | let iScope = (y.~x) & scope | {
            all b: y.type.books | {
                b not in iScope.e.impactEdges.impact
                => y.bookState[b, s2] = y.bookState[b, s1]
            }
            all j: iScope | all g: j.e.impactEdges |
                y.bookState[g.impact, s2] = exprVal[j, s1, g.expr].val
        }
        all y: LibraryInstance - scope.x | all b: y.type.books
        |
            y.bookState[b, s2] = y.bookState[b, s1]
    }
}

在动态语义部分，定义了状态、图书馆实例、借阅状态和借阅者状态等概念。 step 谓词描述了状态的转换，根据实例事件的影响更新书籍的借阅状态。

下面是该图书馆管理系统动态语义的执行流程mermaid图：

graph TD;
    A[状态s1] --> B[触发实例事件i];
    B --> C[计算scope = i.*(succ.s1)];
    C --> D[遍历scope中的图书馆实例y];
    D --> E[计算iScope = (y.~x) & scope];
    E --> F[处理iScope中的实例事件];
    F --> G[计算影响边目标书籍的新借阅状态];
    G --> H[更新状态到s2];
    D --> I[处理不在scope中的图书馆实例];
    I --> J[书籍借阅状态保持不变];

通过这个案例可以看到，使用Alloy方法能够清晰、简洁地定义图书馆管理系统建模语言的形式语义，并且可以利用Alloy Analyzer工具进行自动分析和验证。

9. 未来研究方向展望

虽然基于Alloy的方法在定义建模语言形式语义方面展现出了诸多优势，但仍有一些值得深入研究的方向：
- 适用语言类型分析 ：进一步研究基于Alloy的方法适用于哪些类型的建模语言，明确其优势和局限性，为不同类型的建模语言选择合适的语义定义方法提供参考。
- 与其他方法的比较研究 ：将Alloy与基于抽象状态机、条件重写逻辑等竞争的形式化方法进行更全面、深入的比较，分析每种方法在不同类别的建模语言中的优缺点，为实际应用提供更准确的指导。
- 工具功能扩展 ：探索如何进一步扩展Alloy Analyzer工具的功能，提高其分析效率和准确性，以更好地满足复杂建模语言形式语义的验证需求。
- 与现有工具集成 ：研究如何将基于Alloy的方法与现有的建模工具进行集成，方便建模人员在实际工作中使用，促进形式语义在建模领域的更广泛应用。

综上所述，基于Alloy语言的方法为建模语言形式语义的定义提供了一种有潜力的解决方案，但在实际应用和研究中还有许多工作有待开展，未来有望通过不断的探索和改进，使形式语义在建模语言的设计和开发中发挥更大的作用。