A Classification Framework to Support the Design of Visual Languages

Costagliola, Gennaro; DeLucia, Alan A.; Orefice, Sergio; Polese, Giuseppe

doi:10.1006/jvlc.2002.0234

Cited by 67 publications

(45 citation statements)

References 32 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…al. [3] present a framework of visual language classes in which the analogy between textual and visual characters, words, and sentences becomes apparent. Visual languages are those languages whose concrete syntax is visual (graphical, geometrical, topological, .…”

Section: Dissecting a Modelling Languagementioning

confidence: 99%

Domain-Specific Modelling With Atom

Vangheluwe¹,

Sun²,

Bodden³

2007

Proceedings of the Second International Conference on Software and Data Technologies

View full text Add to dashboard Cite

Abstract. Using domain-specific modelling environments maximally constrains users, matching their mental model of the problem domain, and allows them to only build syntactically correct models. Anecdotal evidence shows that domainspecific modelling can drastically improve productivity as well as product quality. In this paper, the foundations of (domain-specific) modelling language design are presented. Our guiding principle is to "model everything". It is indeed shown how all aspects of language design can be explicitly (meta-)modelled enabling the efficient synthesis of domain-specific, visual, modelling environments. The case of AToM 3 , A Tool for Multi-formalism and Meta Modelling, is elaborated. Concepts are illustrated by modelling, analysis, simulation, and eventual synthesis of software for Traffic networks. Dissecting a Modelling LanguageTo explicitly model domain-specific modelling languages and ultimately synthesize visual modelling environments for those, we will break down a modelling language into its basic constituents. The following is based on a description by Harel and Rumpe [1], taking common programming language concepts and putting them in a more general modelling context. An earlier version of this section appeared as a tutorial at a 2006 MoDELS workshop [2].The two main aspects of a model are its syntax (how it is represented) on the one hand and its semantics (what it means) on the other hand. The syntax of modelling languages is traditionally partitioned into concrete syntax and abstract syntax. In textual languages for example, the concrete syntax is made up of sequences of characters taken from an alphabet. These characters are typically grouped into words or tokens. Certain sequences of words or sentences are considered valid (i.e., belong to the language). The (possibly infinite) set of all valid sentences is said to make up the language. Costagliola et. al.[3] present a framework of visual language classes in which the analogy between textual and visual characters, words, and sentences becomes apparent. Visual languages are those languages whose concrete syntax is visual (graphical, geometrical, topological, . . . ) as opposed to textual. For practical reasons, models are often stripped of irrelevant concrete syntax information during syntax checking. This results in an "abstract" representation which captures the "essence" of the model. This is called the abstract syntax. Obviously, a single abstract syntax may be represented using multiple concrete syntaxes. In programming language compilers, abstract syntax of models (due to the nature of programs) is typically represented in Abstract Syntax Trees (ASTs). As in the context of general modelling, models are often graph-like, this representation can be generalized to Abstract Syntax Graphs (ASGs). Once the syntactic correctness of a model has been established, its meaning must be specified. This meaning must be unique and precise (to allow correct model exchange and code synthesis for example). Meaning can be expressed by specifyin...

show abstract

Section: Dissecting a Modelling Languagementioning

confidence: 99%

Domain-Specific Modelling With Atom

Vangheluwe¹,

Sun²,

Bodden³

2007

Proceedings of the Second International Conference on Software and Data Technologies

View full text Add to dashboard Cite

show abstract

“…If the language is based on relative positions (spatial relationships) then both sentences would be described by the fact that the square is placed to the right of the circle. Some of the most frequently used spatial relationships are right, up, contain, overlap (see [7] for a more complete list). It heavily depends on the visual language which of the spatial relationships are considered to be important.…”

Section: Visual Language Theorymentioning

confidence: 99%

“…For some languages, classified in [7] as geometric-based languages, the position of visual elements is an important information. Other languages ignore the position of elements but focus on the connections between them (connection-based languages).…”

Section: Visual Language Theorymentioning

confidence: 99%

See 1 more Smart Citation

Making Metamodels Aware of Concrete Syntax

Fondement

Baar

2005

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Language-centric methodologies, triggered by the success of Domain Specific Languages, rely on precise specifications of modeling languages. While the definition of the abstract syntax is standardized by the 4-layer metamodel architecture of the OMG, most language specifications are held informally for the description of the semantics and the (graphical) concrete syntax. This paper is tackling the problem of specifying the concrete syntax of a language in a formal and non-ambiguous way. We propose to define the concrete syntax by an extension of the already existing metamodel of the abstract syntax, which describes the concepts of the language, with a second layer describing the graphical representation of concepts by visual elements. In addition, an intermediate layer defines how elements of both layers are related to each other. Unlike similar approaches that became the basis of some CASE tools, the intermediate layer is not a pure mapping from abstract to concrete syntax but connects both layers in a flexible, declarative way. We illustrate our approach with a simplified form of statecharts.

show abstract

“…Approach Overview In order to clearly frame the set of possible visualizations definable using our approach, we designed a Visual Language Model (VLM) as generic as possible in Alloy, such that a large variety of domain specific visualizations can be supported. Works in [2] provide notions on how such a visual language can be defined. This VLM contains basic visual elements such as shapes and texts which can be composed or related to each other via connectors and can be arranged through the definition of layouts.…”

mentioning

confidence: 99%

Domain-Specific Visualization of Alloy Instances

Gammaitoni

Kelsen

2014

Lecture Notes in Computer Science

View full text Add to dashboard Cite

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.

show abstract

A Classification Framework to Support the Design of Visual Languages

Cited by 67 publications

References 32 publications

Domain-Specific Modelling With Atom

Domain-Specific Modelling With Atom

Making Metamodels Aware of Concrete Syntax

Domain-Specific Visualization of Alloy Instances

Contact Info

Product

Resources

About