umlsemantics011.htm

软件开发文档大全

    <p>紧接在效果求值结束后，状态机实例执行到迁移实例的目标状态顶点实例，有下列三种情形。</p>         
    <p>第一种情形：迁移实例有且仅有一个目标，该目标是实例化状态或动作状态（但不能是组合状态的实例）。状态机实例执行进入待入的状态实例。如果该状态实例有关联的entry内部迁移实例，则对迁移实例的迁移条件属性进行求值。若迁移条件取值为真，则对entry内部迁移实例的效果进行求值。在此之后，称状态机实例处于此状态实例。然后状态机实例处于等待，直到状态迁移的条件发生，参见后面部分说明。这时，如果有do内部迁移，则开始与do迁移相关联的动作实例。</p>         
    <p>第二种情形：迁移实例有且仅有一个目标，该目标是组合状态的实例化。状态机实例执行进入待入的组合状态实例。如果该组合状态实例有相关联的entry内部迁移，则对该迁移的迁移条件属性进行求值。如果该迁移条件取值为真，则对entry该内部迁移实例的效果进行求值。在此之后，称状态机实例处于此组合状态实例。这时，如果有do迁移，则开始与do迁移相关联的动作实例。并且，状态机实例执行到作为组合状态实例部件的初始化伪状态实例。该初始化伪状态实例必须是没有触发的迁移实例的源。如果迁移实例带有效果，则继续进行迁移实例的求值。这样，称状态机实例既处于组合状态实例又处于某些子状态。然后状态机实例处于等待，直到状态迁移的条件发生，参见后面部分说明。</p>         
    <p>第三种情形：迁移实例的目标多于一个。这种情形下，这些目标必须体现状态实例，除了一个目标外其余体现并发组合状态实例。同上，状态机实例执行到进入这些并发组合状态实例，不同之处在于这种迁移体现了控制流程的分支，产生并发流程。</p>         
    <p>在上述三种情形下到达稳定状态后，状态机实例的执行依赖于是否有未决的事件实例以及以当前状态实例为源的迁移实例的属性，有下列三种情形。</p>         
    <p>第一种情形：状态实例是几个迁移实例的源，其中恰好有一个没有触发。触发的迁移条件求值次数恰为一次。如果迁移条件取值为假，则并不离开该状态实例，状态机的执行被挂起，下一个事件实例也被挂起，。如果迁移条件取值为真，则执行退出此状态实例。如果状态实例有相关联的exit内部迁移实例，则对迁移实例的迁移条件属性进行求值。如果迁移条件取值为真，则对exit内部迁移实例的效果进行求值。在此之后，状态机实例继续执行对唯一的无触发的迁移实例（亦称为自发迁移）的求值，方法同上（迁移条件不再求值，但如果带有效果，同上求值）。隐含地，有一个临时状态实例；状态机实例处于此状态实例的时间很短（即，只在对状态实例的entry、do和exit的效果进行求值时）。</p>         
    <p>第二种情形：状态实例是几个迁移实例的源，其中有多于一个的迁移实例没有触发。每个无触发的迁移实例的迁移条件只进行一次求值，求值次序不由UML指定。如果所有的迁移条件取值为假，则不离开该状态实例，状态机实例的执行同上。如果恰好有一个迁移条件取值为真，则按照此无触发的迁移实例继续执行。如果有多于一个迁移条件取值为真，则状态机实例的执行是不固定的：执行同上，只选一个迁移条件为真的无触发迁移实例，选择方法由具体实现决定。</p>         
    <p>第三种情形：状态实例是几个迁移实例的源，所有迁移实例都有触发。状态机实例在该状态实例等待事件实例。一旦接收到一个事件实例，状态机实例执行对所有以该状态实例为源、以该事件实例为触发的迁移实例的求值。求值产生三种可能。第一种为接收到一个事件实例，但没有被该事件实例触发的迁移实例。这时，该事件实例被忽略（效果上表现为舍弃），状态机实例保持在激发前的稳定状态实例。第二种可能为接收到一个事件实例，并且恰有一个迁移实例被该事件实例触发。对此迁移实例的迁移条件进行一次求值。如果迁移条件取值为假，则状态机实例保持在原状态实例，忽略接收到的事件实例（效果上表现为舍弃）。如果取值为真，则状态机实例离开原状态实例，按照事件实例触发的迁移实例继续执行。第三种可能为接收到一个事件实例，并且有多于一个迁移实例被该事件实例触发。对这些迁移实例的迁移条件求值，求值顺序不由UML规定。如果有且仅有一个迁移条件取值为真，则状态机实例离开原状态实例，按照事件实例触发的迁移实例继续执行。如果多于一个迁移条件取值为真，则状态机离开原状态实例，只按照事件实例触发的一个迁移实例继续执行，选择哪个迁移实例由实现决定。</p>         
    <p>对于触发内部迁移实例（预定义的entry、do和exit以外的内部迁移实例）的事件实例，状态机的执行同上，不同之处在于内部迁移实例的求值不再对与原状态实例关联的entry、do和exit内部迁移实例进行求值。这表明状态实例不是面向内部迁移实例的。</p>         
    <p>内部迁移实例与自迁移有区别，自迁移是非内部迁移的迁移实例，但其源和目标是相同的状态实例，自迁移的求值会导致对状态实例的entry、do和exit内部迁移实例的再求值（如果存在这些内部迁移实例）。</p>         
    <p>如果状态实例是组合状态实例化的子状态，或者状态实例是有子状态的组合状态，有下列补充说明。</p>         
    <p>先考虑状态实例是组合状态的子状态的情形。如果状态机实例接下去执行的迁移实例是从子状态迁移到包含它的外层组合状态，则状态机实例离开子状态，同时离开组合状态。也就是说，在对子状态的exit内部迁移实例（如果有）求值之后，立即对外部的组合状态的exit内部迁移实例求值，继续进行下去，直至最外层的到达迁移实例目标的组合状态实例。</p>         
    <p>如果状态实例是有子状态的组合状态，如果状态机实例执行一个以超状态为源的迁移实例，则先退出子状态（按照嵌套的层次，从最里层到最外层），依次对其exit内部迁移实例求值（如果有）。         
    <font face="Times New Roman"></p>         
    </font><p>在时空中同一时刻子状态和超状态都能响应同一事件实例时，最里层的迁移实例优先。</p>         
    <p>上述语义说明了对等状态实例和从里层到外层状态实例的状态变化。如果迁移实例的源是外层状态实例，目标是里层状态实例时，有隐含语义。如果状态机实例执行以子状态为目标的迁移，则先进入超状态（按照嵌套层次，从最外层到最里层），依次对其entry内部迁移实例求值（如果有）。</p>         
    <p>另外，还有两条附加动态语义与上述语义互相影响。</p>         
    <p>第一条、终止伪状态实例可以是一个或多个迁移实例的目标。当状态机实例执行到终止伪状态实例时，状态机实例称为已结束，以后所有到该状态机实例的事件实例都被忽略，状态机实例不再产生影响（体现了外部实例类实例的析构）。</p>         
    <p>第二条、历史连接伪状态实例可以是一个或多个迁移实例的目标。历史连接伪状态实例不能是迁移实例的源。组合状态实例至多有一个直接的历史连接伪状态实例。当迁移到一个包含历史连接伪状态实例的组合状态实例时，同上执行到该组合状态实例的初始化伪状态实例。当迁移到组合状态实例的历史连接伪状态实例时，并不继续进行初始化伪状态实例，而是迁移到离开组合状态时最后离开的最里层的子状态。最初，组合状态实例没有历史连接，这时组合状态实例本身看作是最后离开的状态实例.<font face="Times New Roman"></p>         
    </font><b><font face="Arial" size="5"><p></font></b><font size="5">10.3<a name="10.3"></a>         
    </font>导出语义</p>         
    <p>模型元素的语义参见第二节。</p>         
    <p>名字、布尔值、表达式和定时的参见第四节。</p>         
    <p>实例的语义参见第五节。</p>         
    <p>关系的语义参见第六节。</p>         
    <p>信号、属性和操作的语义参见第七节。大多数情况下信号实例没有关联的操作实例。</p>         
    <p>附注：本节中的信号和操作有连接到事件的，也有连接到动作的。连接到动作时，信号和操作表示激发；连接到事件时，信号和操作表示接收。这些关系提供了条件：一个状态机实例的事件或操作可在另一个状态机实例中使用。         
    <font face="Times New Roman"></p>         
    </font><p>如第五节所述，信号是类的子类型（因此是类型的子类型）。如第六节所述，类型实例可以参加一般化关系。因此，可以定义信号实例的层次关系。同上，此语义与触发迁移实例的语义互相影响。特别是通过信号事件实例触发迁移实例是多态的。例如，考虑一个简单的层次结构，有一个信号实例S和S的两个子类型S1和S2，迁移实例T的触发由信号事件实例指定。如果T的触发是S1，仅当接收到S1的实例时迁移实例才启动（因此，接收到S或S2的实例时不启动）。另一方面，如果T的触发是S，则接收到S或S的子类型S1、S2的实例时都启动迁移实例。这时，对信号实例触发的响应称为多态的。</p>         
    <p>表达式不是模型元素的子类型，因此动作表达式、布尔表达式和时间表达式也都不是。</p>         
    <p>行为类/行为实例类是UML中本质/现象结构的一部分。</p>         
    <p>行为类是模型元素的子类型，因此行为类的实例可有附着的构造型、标志值、附注和限制条件实例（也可以参加依赖关系）。</p>         
    <p>行为类还出现在元模型的另外两部分中：在第五节中作为类型（和实例类）实例的一部分，在第九节中作为协同实例的一部分。作为类型实例的一部分时，行为类的实例说明了类型实例的与实现无关的语义。此时，关联的状态机实例中的动作实例可能没有目标，这时目标被假定为外层类型实例的实例类的实例。作为协同实例的一部分时，行为实例说明协同实例中协同的类型实例组成的集合的语义（因此也常用于说明类型或操作实例的实现）。</p>         
    <p>行为类只有两个子类型，分别是状态机和交互作用。交互作用的语义见第十一节。这两种行为类的实例都可用于说明行为类的实例附着的类型或协同实例的语义，但方式不同。状态机实例指定行为的语义，而交互作用实例反映这些行为化的语义。或者说，状态机实例指定它所附着的类型或协同实例的可能行为，而交互作用实例只说明在特定情形下行为通过的单条路径。因此，状态机实例可以产生很大数量的对应的交互作用实例（每一个交互作用实例显示所有可能的行为路径中的特定路径）；并且，交互作用（每个实例说明一个原型行为）的实例的集合可以指定一个由各交互作用实例中出现的参加者组成的状态机实例。通过这种方式，附着在同一类型或协同实例上的状态机实例和交互作用实例互相补充。理论上，只需要一个行为类的子类型就能绑定类型或协同实例的行为化语义，但实践中这两种子类型都有用，为建模者提供选择的余地。</p>         
    <p>状态机和交互作用的语义的另一个重要区别在于状态机实例一般用来指定单个类型的行为，而交互作用实例通常涉及很多类型。</p>         
    <p>如第十一节所述，行为类的实例可包括由协同实例指定的簇。这些协同实例通常用于指定相应视图元素实例中的“泳道”。</p>         
    <p>状态机实例体现状态图实例的模型，参见第十二节说明；这些图体现了按状态组织的行为化图。顶点只有动作状态实例（而没有状态或组合状态实例）的状态机实例体现了活动图实例的模型，参见第十二节说明；这些图体现了按动作组织的行为化图。</p>         
    <p>由于迁移是关系的子类型，每个迁移实例的名字实例必须唯一，参见第六节关系实例名字的语义部分。第六节中还说明了析构迁移实例的源和/或目标保证了不存在悬空的迁移实例。</p>         
    <p>与迁移相关联的名字实例通常为空。如果非空，该名字实例可用于状态机实例范围内的限制条件实例，以指定时间限制条件。并且，这些名字还可用于时间表达式。这两种情形下，迁移名字都可用于说明迁移时间。例如，名字实例N体现迁移的开始（事件实例的发生），N’体现迁移效果的结束（在所有动作实例完成后）。使用这些名字，可以创建复杂的限制条件和时间表达式实例，包含与事件有关的时间（例如，N         
    + 30微秒体现了在N后30微秒的时刻）。</p>         
    <p>与迁移相关联的迁移条件布尔表达式实例可以包括任意复杂的表达式。表达式实例的条件可以包含对状态机实例的状态的引用。特别是，迁移条件布尔表达式中出现状态顶点实例的名字实例体现了对状态机实例是否处于该状态的测试。</p>         
    <p>因为事件语义和结点语义的交互作用，事件定义为指定在时空中而不仅仅是时间上重要的发生。如第八节所述，结点实例体现了构件实例所用的部件。隐含地，每个结点实例体现分布式协同中独立的处理元素。在这样的系统中适用相对语义，没有同时发生的事件：每个观察者看到的是不同的事件。基于这个原因，事件实例需要在时空环境中保证唯一，而不仅仅是时间环境中。</p>         
    <p>如第八节所述，每个活动类实例定义一个事件队列。此语义保证了在活动类实例范围中，任一时刻有且仅有一个事件实例被关联的状态机实例处理。因为状态实例是不可中断的，这意味着在执行动作实例过程中激发的事件实例被送入队列。可以用动作表达式实例操作队列（例如，删除队列、从队列中移去一个事件或查询队列），但这些操作不是UML核心的组成部分，而必须模型化为外部活动类实例的组成部分。</p>         
    <p>以事件实例为发生的信号或操作实例必须是状态机实例可见的，或者直接可见（通过拥有行为实例的类型实例），或者间接可见（通过拥有行为实例的协同实例）。类似地，动作实例激发的交互或操作实例是状态机实例可见的，或者直接可见，或者间接可见。最后，作为动作实例的目标或实际参量的实例类实例是状态机实例可见的，或者直接可见，或者间接可见。这些实例类的实例包括状态变量、状态机实例可见的操作实例的形参、包含状态机实例的类型实例的属性实例，但不只限于这些。这些实例类的实例不未具体实现，但体现了原型化的命名实例。</p>         
    <p>状态机实例可以包含发送信号实例到包含本状态机实例的相同实例类实例的动作实例。这种自引用的触发是允许的；任一这样的信号实例成为同一状态机实例中触发迁移实例的事件实例的发生。所有这些事件都在包含状态机实例的最里层的活动类实例中排入队列，信号实例本身也排入队列。</p>         
    <p>如第六节所述，类型实例可以参加一般化关系。因此类型实例所拥有的状态机实例本身是继承的。子类型的类型实例继承其超类型的类型实例的状态机实例。UML除在第六节中指出要保持可替代语义外，不规定解决有关继承的状态机实例冲突问题的规则；指定形式化模型不属于实用范围。UML允许子类型的类型实例向继承来的状态机实例中添加新的状态顶点和迁移实例，但仍需要保持可替代语义。</p>         
    <p>发送信号或操作实例到作为组合类型实例化的实例类的实例（指类型实例有到其它类型实例的组合聚集关系）并不意味着给实例的所有部分发送事件实例。为达到给所有部分发送事件实例的效果，类型实例（实例类的实例是它的实例化）关联的状态机实例必须显式地说明一个动作表达式实例，用于给各部分发送相同的触发实例。</p>         
    <p>状态机实例运行至结束的语义与预定义的do迁移的语义相互影响。与do迁移关联的动作实例实际上是不可中断的；但与do动作实例关联的操作实例可以定期查看是否有未决的事件（使用预定义的_hasEvent操作），如果有这样的事件，则结束当前处理，转去处理这类事件。附注：此语义并不指定隐式可中断性－状态机实例运行至结束，但建模者可以指定测试事件存在的点。</p>         
    <b><font face="Arial" size="5"><p></font></b><font size="5">10.4<a name="10.4"></a> </font>标准元素</p>         
    <p>没有标准构造型、标志值或附注应用于本图描述的元模型类。</p>         
    <p>如第10.3节所述，有三个为迁移实例预定义的名字，即entry, do, and         
    exit。</p>         
    <p>有一个同义词应用于本图所描述的元模型类：</p>         
    <table border="1" cellspacing="1" bordercolor="#000000" width="534" align="center">         
      <tr>         
        <td width="22%">同义词</td>         
        <td width="78%">定义</td>         
      </tr>         
      <tr>         
        <td width="22%">激活</td>         
        <td width="78%">激活是操作的执行。</td>         
      </tr>         
    </table>         
  </blockquote>         
   
  <p><b><a href="umlsemantics001.htm">返回目录</a></b></p> 
  
</body>