Domain-Specific Visualization of Alloy Instances

Abstract

Motivation Alloy is a modelling language based on first order logic and relational calculus combining the precision of formal specifications with powerful automatic analysis features [3]. The automatic analysis is done by the Alloy Analyzer, a tool capable of finding satisfiable instances for given Alloy models in a finite domain space using Sat-solving.The utility of this instance finding mechanisms relies on the small scope hypothesis that claims that most design errors can be detected in small model instances. Those design errors can be identified by evaluating expressions in the instances generated, but also through the direct visualization of those instances. In the latter case, the intuitiveness and expressiveness of the instance visualization play a key role to efficiently diagnose the validity of instance.The current visualizations offered by the Alloy Analyzer produce visual diagrams that are close to the structure of instances. These low level visualizations become difficult to read when instances become more complex.To highlight this lack of intuitivity, let us consider the formalisation of a Finite State Machine (FSM). Figure 1 is the visualization of a FSM instance provided by the Alloy Analyzer, while fig. 2 is an intuitive domain-specific visualization produced by Lightning, a tool implementing the approach described in this paper.

Agile validation of model transformations using compound F-Alloy specifications

“…This tool and approach has been successfully applied in the validation of software systems [17,21], and generally contributed to close the gap between the engineer modeling the system in Alloy, and their client, the domain expert for which the system is designed [3]. However, it has been highlighted in [9] that despite recent advances in Alloy instances representations [25], intuitive visualization of large instances can only be achieved using the knowledge of their domain of application, namely domain specific visualization.…”

“…Note that Alloy natively offers a visualization of model instances as graphs, with each element of the instances being represented by a node and relations between those by edges. Yet it has been shown in [9] that this native visualization falls short in providing an intuitive visual feedback, hence preventing effective involvement of domain experts. We showcase the VBV approach by letting a domain expert (without F-Alloy knowledge) validate an F-Alloy specification of the benchmark model transformation CD2RDBMS [5].…”

RPSL meets lightning: A model-based approach to design space exploration of robot perception systems

“…In this work, we have defined in Lightning domain models and design alternatives as fullfledged languages with well defined concrete syntax. This enables us to provide intuitive [17] (domain specific) visual feedback for the domain space exploration we propose to carry out.…”

“…For the specification of design spaces, we propose to use an extended version of an existing robotics language, the Robot Perception Specification Language (RPSL) [14], allowing the definition of both functional and architectural variability of robot perception systems. We also propose a new approach to DSE consisting in importing domain models expressed in RPSL into a framework based on Lightning [15], an Alloy [16] based tool allowing, given Alloy models, the generation of conforming instances and their depiction using a domain specific visualization [17].…”

F-Alloy: An Alloy Based Model Transformation Language

“…In an earlier publication [8] we already showed that the concrete syntax of a language can be defined as a transformation using Alloy. The current work opens up the possibility to integrate the specification of general model transformations (e.g., for specifying operational semantics of languages) into the Alloy based language workbench.…”