Model Interface Specification Diagrams

• Model Interface Specification Diagrams (MISDs) are formal notations that represent UI states, transitions, and dynamic behaviors using unified graphical elements.
• They integrate informal interface sketches with formal semantics, enabling automated verification via tools like PVSio-Web and LTL model checking.
• MISDs support both UI prototyping and dynamic architectures by mapping transitions, guard predicates, and actions into machine-checkable models.

A Model Interface Specification Diagram (MISD) is a formal visual notation used for describing, analyzing, and verifying the high-level behavioral and structural characteristics of interactive systems and dynamic software architectures. MISDs synthesize both informal interface sketches and rigorous formal specification, enabling seamless transitions from design prototypes to machine-checkable models (Watson et al., 2018, Marmsoler, 2017).

1. Fundamental Notation and Syntax

The MISD notation encodes system states, transitions, user events, data variable manipulations, and conditional logic in a unified diagrammatic form. Originating in the context of user interface prototyping within PVSio-Web, the MISD is rendered as a visual Presentation Interaction Model (PIM) using the Emucharts (state-flow) editor. The key graphical and syntactic elements are:

• State nodes: Each rounded-rectangle labeled with a distinct screen or presentation model (PM), e.g., LoginScreen.
• Transitions (I-behaviours): Directed edges labeled with eventName [ guardPredicate ] / action indicating possible screen changes. The edge may specify:
  • Event: Corresponds to user input (e.g., button press), automatically generated from UI hotspots.
  • Guard predicate: Boolean condition over UI state or variables, in square brackets [ ... ].
  • Action: State update or system call, following a /.
• General transition syntax:

$D = \{ D_v \mid v \in V \}$6

• Example:

$D = \{ D_v \mid v \in V \}$7

This formalism also extends to configuration diagrams in dynamic architectures, where components, their activation intervals, and required connections are shown as labeled boxes, port circles, and annotated arrows (Marmsoler, 2017).

2. Formal Semantics

The semantics of an MISD is presented as a labeled transition system with an explicit treatment of state, events, data variables, and state updates:

• $S$: finite set of interface states (screens)
• $E$: finite set of input events (user actions)
• $V$: finite set of data variables associated with widgets
• $D = \{ D_v \mid v \in V \}$: each variable's domain (e.g., $\text{string}$, $\text{int}$)
• $s_0 \in S$: initial state
• $$G: S \times E \rightarrow \{\text{true}, \text{false}\}$$: guard predicate function
• $A: S \times E \rightarrow (V \rightarrow D_v)$: action/update function
• $\delta: S \times E \rightarrow S$: transition function

The transition relation is: $E$0 where $E$1 is the current valuation of data variables.

• Each input widget spawns a unique $E$2, with domain $E$3 determined by widget type.
• Actions may be the identity mapping or overwrite $E$4 with a specific value $E$5.

When extended to specification of dynamic architectures, MISDs (as configuration diagrams) induce a single Linear Temporal Logic (LTL) formula $E$6, interpreted over traces $E$7. These capture constraints on instance multiplicities, rigid instance sets, and connection relations, enabling explicit temporal reasoning (Marmsoler, 2017).

3. Transformation and Generation Algorithms

In PVSio-Web, the MISD is automatically synthesized from a prototype described as a set of screens with associated widgets and hotspots:

• States: $E$8, $E$9
• Events: Each hotspot becomes an event; $V$0
• Data variables: $V$1, domains assigned by widget type
• Guards and actions: Parsed from optional expressions in hotspots, defaulting to $V$2 and the identity mapping, respectively
• Transition function: $V$3

The algorithm enforces determinism (at most one outgoing transition per $V$4) and reachability (every state except $V$5 has an incoming transition) (Watson et al., 2018).

When used as configuration diagrams for dynamic architectures, the transformation captures:

• Activation bounds $V$6
• Rigid sets $V$7
• Connection requirements $V$8
• LTL constraints ensuring these invariants across all traces (Marmsoler, 2017).

4. Application Examples

A canonical example is a login dialog:

• Prototype:
  • Screens: LoginScreen, WelcomeScreen
  • Widgets: username/password fields; login/logout buttons
• MISD:

$D = \{ D_v \mid v \in V \}$8

• Formal PVS theory encoding:
  • $V$9
  • $D = \{ D_v \mid v \in V \}$0
  • $D = \{ D_v \mid v \in V \}$1
  • Guards and actions as in the diagram, directly translatable to PVS logic (Watson et al., 2018).

For dynamic architectures:

• Configuration Diagrams: Boxes for each interface, port circles, activation bounds, rigid sets, and explicit connection arrows.
• LTL semantics: Constraints like $D = \{ D_v \mid v \in V \}$2 (at most one server active); $D = \{ D_v \mid v \in V \}$3 (mandatory connections) (Marmsoler, 2017).

5. Verification, Workflow, and Tool Integration

The MISD paradigm tightly integrates informal design and formal analysis:

• Bridge from design to formalism: Designers create UI prototypes using screen sketches and hotspots; MISDs are generated automatically, eliminating manual encoding (Watson et al., 2018).
• Interactive feedback: The “view mode” allows designers to simulate navigation, exposing dead-ends or unreachable states.
• Formal verification: MISDs are translated into machine-checkable PVS theories. The PVS theorem prover checks proof obligations, including invariants (e.g., nonempty username), safety (impossibility of accessing screens without preconditions), and liveness (eventual logout availability).
• Test-case generation: Animated MISDs generate abstract UI test sequences.
• Multi-disciplinary workflow: Designers operate in familiar environments; formal methods experts obtain models directly suitable for verification and simulation.

For dynamic architectures, verification involves parsing the configuration diagram, extracting all annotated invariants, generating the global LTL assertion $D = \{ D_v \mid v \in V \}$4, and checking satisfaction $D = \{ D_v \mid v \in V \}$5 using temporal logic model checking (Watson et al., 2018, Marmsoler, 2017).

6. Expressiveness, Limitations, and Relation to Other Formalisms

MISDs, whether used for UI modelling or dynamic architectures, offer the following:

• Expressiveness: They capture both static interface definitions and dynamic constraints (state transitions, activation multiplicities, connection requirements), all with a direct formal semantics.
• LTL integration: The translation to LTL allows expressing time-based properties (e.g., “eventually,” “always,” and “until”).
• Limitations: The graphical notation primarily supports simple min–max bounds and global connection patterns. More complex structural or topological patterns necessitate additional formal annotation. MISDs presuppose an agreed-upon messaging or event semantics.
• Comparison to related techniques:
  • Traditional UML static diagrams can encode provided/required port wiring but lack support for dynamic multiplicity and temporal constraints.
  • Interface automata/modal I/O automata encode behavior but not reconfiguration constraints graphically.
  • Other formalisms (OCL, Alloy) provide analogous assertions, but not the concise diagrammatic interface of MISDs (Marmsoler, 2017).

In conclusion, MISDs provide a rigorous, semantically grounded bridge between informal interface design and formal system verification, applicable both in interactive system prototyping (PVSio-Web) and in the formal specification of reconfigurable, dynamic architectures (Watson et al., 2018, Marmsoler, 2017).