State Machines as Mixins.

Abstract

Mainstream object modelling techniques use Statechart Diagrams as a means of modelling object behaviour. Research into how statecharts can be used in the context of class generalization hierarchies has focused on applying the Liskov Substitution Principle (LSP) to statecharts. This approach is problematic, and we describe three reservations.We propose an alternative approach based on mixin-style composition of state transition diagrams. This avoids the problems we note in the LSP based approach; and is also a basis for separating descriptions of behaviour inherent to the modelled domain from behaviour that is not inherent, but a requirement of the system.

Lattice study of the masses of singlet0++mesons

“…Indeed, the standard formalism for determining the masses of hadrons on a lattice may be inappropriate in the presence of open decay channels and special techniques may be needed [20,21,22]. The MILC collaboration reported problems in extracting the masses of non-singlet 0 ++ [23] and 1 −+ [24] mesons, that they at-tributed to open decay channels.…”

Protocol Modelling Semantics for Embedded Systems

“…Observational Consistency and Local reasoning. Suppose that P M 1 and P M 2 are protocol machines and that P M 1 and P M 1 P M 2 are both trace independent, then P M 1 P M 2 is Observationally Consistent [5] with P M 1 . This means that if T is a trace of P M 1 P M 2 and we remove from T the events that are not in the alphabet of P M 1 , we will obtain a trace of P M 1 [1].…”

Aspect-Oriented Development Using Protocol Modeling

“…Protocol models can be directly executed (tested) after any step of model evolution, and this is supported by the ModelScope [6] tool, providing run-time machine composition and a generic (metadata driven) user interface. The input of the tool is the textual presentation of a protocol model described in Section 3, and Figure 9 shows the user interface as it appears when executing the CMS case study.…”

“…If a given sequence of events is presented to a model twice starting from the same initial state, the final state of the model will be the same, as will be the set of events that it could accept next. The reason for requiring determinism is the ability this gives to argue about behavior based on traces 6 . There is, however, no assumption that non-determinism may not be introduced at physical design time if it is decided to distribute the model across multiple (real or virtual) processors; but this must be done in such a way that the behavior of the model is not broken by such a distribution.…”

“…it omits attribute definitions, calculations for derived states and attributes, and the algorithms for generation of automated events. The full source of the model, including the full definition of data handling, can be downloaded from the Metamaxim website [6] 10 . The ModelScope execution tool is also available from this site.…”