=Paper=
{{Paper
|id=Vol-2245/hufamo_paper_3
|storemode=property
|title=The Visual Inheritance Structure to Support the Design of Visual Notations
|pdfUrl=https://ceur-ws.org/Vol-2245/hufamo_paper_3.pdf
|volume=Vol-2245
|authors=Nungki Selviandro,Tim Kelly,Richard Hawkins
|dblpUrl=https://dblp.org/rec/conf/models/SelviandroKH18
}}
==The Visual Inheritance Structure to Support the Design of Visual Notations==
https://ceur-ws.org/Vol-2245/hufamo_paper_3.pdf
The Visual Inheritance Structure to Support the
Design of Visual Notations
Nungki Selviandro∗† , Tim Kelly∗ , Richard Hawkins∗
∗ Department of Computer Science, University of York, UK
† School of Compputing, Telkom University, Indonesia
{ns1162, tim.kelly, richard.hawkins}@york.ac.uk
Abstract—It is a common practice in modelling languages is, explicit reference to theories and empirical evidence for de-
to provide their users with a set of visual notations as a signing the notations [5]. Some approaches exist to support the
representation of semantic constructs. The use of visual notation designer in designing the visual notation such as proposed in
is believed to help communicate complex information, especially
when communicating with non-technical users. Therefore, re- [3], [6], [7]. In this paper, we address the visual inheritance to
search in the design of visual notation continues to evolve, e.g. support the design of a visual notation based on a metamodel.
research to provide an effective and efficient design approach. We show the applicability of this approach by designing a
There are approaches exist to support the designer in designing set of visual notation for the Argumentation Metamodel of
the visual notation such as the Cognitive Dimensions and the the OMG Structured Assurance Case Metamodel (SACM)
Physics of Notations. As the current metamodeling approach is
widely adopted as a mechanism for improving standardisation [8]. This metamodel describes and defines the concepts that
and interoperability in modelling languages, it is important to are required to model structured arguments (e.g. for safety).
provide a guideline that focus on the design of visual notation However, the current version of the SACM Argumentation
for a predefined metamodel. In this paper, we address the visual specification is not equipped with any visual notation.
inheritance structure to support the design of visual notations for
The remainder of this paper is organised as follows: Section
a predefined metamodel. This approach emphasises the design
coherence between classes and sub-classes. To demonstrate that 2 presents related work on the visual notation design theory,
it is possible to apply our approach, we use part of the OMG visual inheritance design, and the concept of structured argu-
Structured Assurance Case Metamodel as a case study. ments in SACM. Section 3 describes the visual inheritance
notation design. In Section 4, we discuss the applicability
I. I NTRODUCTION of the proposed approach. In Section 5, we describes the
In developing a system model using a particular modelling limitations to the current version of the proposed approach.
language, it is essential for the designer to understand the se- Finally, Section 6 gives conclusions and discusses future work.
mantic constructs, the compositional rules, and the constructs
representation (e.g. in textual or visual forms). It is now a II. R ELATED W ORK
common practice in modelling languages to provide users with A. State-of-the-Art of Visual Notation Design Theory
a set of visual notations for the representation of the semantic
constructs. UML, for example, as a general-purpose modelling Visual notations form an integral part of the language of
language, has a visual notation to help the designer visualise computer science and software engineering. Many of visual
system models. notations have been developed to facilitate communicating
The visual communication aspect itself in modelling lan- complex information between technical and non-technical
guages is crucial. It can be seen as the interface of the users. They are also used in different stages of software
modelling language and users, and helps communicate com- engineering, from requirements engineering through to main-
plex information, especially when communicating with non- tenance. Visual notations are also adopted by practitioners
technical users. A well-designed visual notation is also easier in industry for strategic planning in the design of software
to learn and to remember than textual syntax [1], [2]. To systems. In industry, visual notations play a critical role in
be more effective, the design of the visual notation should communicating with internal and external stakeholders [9].
intuitively represent the semantic constructs [3], [4]. This encourages visual notation researchers to conduct studies
In the visual modelling language development process, as to how to maximise the effectiveness of visual notations.
the semantic constructs and the language rules are typically Research in notation design is closely associated with
defined in a metamodel by the language developers together research in conceptual modelling languages, specifically in
with the end-users, who help to refine the language concepts. evaluating the quality of the conceptual model [10]. Several
Based on the defined metamodel, notation will be developed frameworks have been proposed to evaluate and improve
as a representational form of the language [3]. The design of the quality of conceptual models, and some of them, such
the notation should be accompanied by a design rationale, that as SEQUAL [11] and GoM [12], partially paid attention to
the visual notation aspect. However, they were not designed
Supported by Indonesia Endowment Fund for Education (LPDP). exclusively to focus on the visual notation.
Recently, a theory that focuses on visual notation design
has been proposed, which is called The Physics of Notations
(PoN). This theory aimed to ensure that visual notations are
designed to be cognitively effective (i.e. the speed, ease, and
accuracy with which a representation can be processed by the
human mind) [3]. PoN provides nine principles that can be
used either to design or to evaluate the visual notation. There
are numbers of existing notations that has been evaluated
using the PoN principles such as UML [13], I* [14], SEAM Fig. 1. (a) Single Inheritance; (b) Multiple Inheritance
[9], UCM [15], and BPMN [5]. There are also several new
notations that are designed using the PoN principles, such
as VTML (The Visual Traceability Modelling Language)
[16] and Larman’s Operation Contracts [17]. However, this
framework has received some criticism in the literature, mainly
focused on the validation and difficulty in applying the princi-
ples since PoN does not prescribe any systematic method for
the implementation. Several works, such as in [18]–[20], have
been proposed to address this issue.
Besides PoN, the Cognitive Dimensions (CDs) theory is Fig. 2. An Example of Visual Inheritance in UI Design
also frequently discussed in notation design literature. CDs
framework was introduced by Green, who emphasised the
use of this framework as a ”discussion tool” to aid non-HCI when compiling the program. A popular case of this ambiguity
specialists in evaluating the usability of notational systems is known as a ’diamond problem’. The diamond problem can
and information artifacts [6]. To do this, the CDs provides be illustrated as an ambiguity that arises when a parent-class
a vocabulary that can be used by designers when investigating A inherits its attributes and methods to child-classes B and C,
the cognitive implications of their design decisions. Therefore, while there is a sub-class D that inherits from both class B
it does not explicitly provide any guideline or procedure for and C (see Fig. 1(b)). In this case, the problem occurs when
designing or evaluating a visual notation [21]. there exist methods with the same signature in both parent
With the advancement of meta-modelling standards, the and child-classes. On calling the method, the compiler cannot
semantic constructs and grammatical rules of modelling lan- determine which class method to be called and even on calling
guages tend to be defined in the metamodel to facilitate which class method gets the priority [22].
communication and tool support [14]. The notation should In user interface (UI) object-oriented programming, the
be defined afterwards referring to the defined metamodel. concept of inheritance is also being adopted to maximise
Therefore, in this paper we focus on providing a guideline efficiency. For example, in the case when we have a common
to support the design of the notations based on a metamodel. (base) design that can be reused further by inheriting this base
design [24], [25]. For example, in designing a UI frame, we
B. Visual Inheritance can create the base design as a rectangle that has common
The term inheritance is commonly used in object-oriented functionalities (methods), e.g. close. This frame base design
methodology. Inheritance can be defined as a mechanism and functionalities can be reused by more specialised frames
which allows new classes to be defined based on existing (e.g. login frame) by implementing the inheritance mechanism.
classes; a new class can be defined as a specialisation of one This process can be called visual inheritance. An illustration
that has already been defined. In this case, the specialised class of this is provided in Fig. 2.
inherits the characteristics (attributes and methods) of the class The concept of inheritance has inspired the idea of visual
it is created from. This specialised-class is also known as a inheritance design in designing visual notations based on the
sub-class or child-class, while the existing class that inherits metamodel. The implementation of this idea only applies for
its characteristics is also known as a general-class, super-class, single inheritance scenarios because of the ambiguity in the
or parent-class [22]. case of multiple inheritance. The concept of visual inheritance
There are two types of inheritance: single and multiple [22], for designing visual notations will be discussed in Section 3.
[23]. Single inheritance can be described as a condition where
a child-class has exactly one parent-class. For example, in C. Argumentation Metamodel in SACM
Fig. 1(a), a child-class ”B” has only one parent-class ”A”. The concept of an assurance case is that it provides a
Multiple inheritance can be described as a condition where a framework for analysing and communicating the assurance
child-class has more than one parent-class. However, multiple arguments and evidence about a particular system in a specific
inheritance tends to be hard to implement due to ambiguity. environment (e.g. covering safety requirements of the systems)
For example, Java programming language does not support the [8]. In [26], an assurance case is defined as a reasoned and
multiple inheritance mechanism since it could cause ambiguity compelling argument, supported by a body of evidence, that a
system, service or organisation will operate as intended for a a parent-class to its child-classes, this could help the user of
defined application in a defined environment. These structured the notation inferring the semantic meaning of the classes and
arguments, for example in complex systems, sometimes can reduce the cognitive overload [3] in memorising the number
be very large and complicated. Therefore, it is necessary for of the notations.
them to be clearly documented. As an input to start the visual inheritance process, we need a
The Structured Assurance Case Metamodel (SACM) is a predefined metamodel as our main reference for designing the
specification that defines a metamodel for representing struc- visual notation. This process can be applied only for single
tured assurance cases. It is published by The Object Manage- inheritance relationship scenarios, where a child-class in a
ment Group to improve standardisation and interoperability for metamodel only has exactly one parent-class. This condition
assurance cases [8]. Part of the SACM specification defines a is important to avoid ambiguity such as a ”diamond problem”
metamodel for representing structured arguments (see Fig. 3). in programming multiple inheritance. The output of the visual
In SACM, structured arguments are represented explicitly by inheritance process is the visual notation that consists of visual
the Claims, citation of artifacts or ArtifactReferences (e.g. Ev- representations, the visual semantics, and the compositional
idence and Context for claims), and the relationships between rules based on the metamodel.
these elements [8]. The following relationships are defined: Before designing the visual notation, it is important to study
• AssertedInference for relationship between Claims all concepts of the metamodel to capture the core aspects and
• AssertedEvidence for ArtifactReference (as Evidence) elements in the metamodel. We also suggest to observe the
and Claims following elements in the metamodel:
• AssertedContext for ArtifactReference (as Context) and • Type and attributes of each class.
Claims A class in a metamodel could be defined either as an
• AssertedArtifactSupport for ArtifactReference (as Evi- abstract- or concrete-class. Unlike the concrete-class, an
dence) supporting ArtifactReference (as Evidence and abstract-class cannot be instantiated. A certain class can
Context) have one or more attributes. An attribute is a feature
• AssertedArtifactContext for ArtifactReference (as Con- within a class that describes a range of values that the
text) supporting ArtifactReference (as Evidence and Con- instances of the class may hold. The attribute may be
text) grouped by visibility. A visibility keyword can be given
In addition to these core elements, it is also possible to once for multiple features with the same visibility.
provide: • Type of each relationship.
• Description of the ArgumentReasoning associated with A relationship is a semantic connection among model
AssertedInference or AssertedEvidence elements. For example, in UML there are several types
• Counter-Argument and Counter-Evidence (via isCounter: of relationships such as association, generalisation, ag-
Boolean) gregation, and composition.
• Modular structured argument (via ArgumentPackage) in- After studying the overall concept of the metamodel, we
cluding the mechanism to organise a specific selection of can begin the visual inheritance process. At first, we need to
the ArgumentElements contained within the package (via choose a root class. In selecting the root class, we suggest
ArgumentPackageInterface), and a mechanism to bound considering the scope of the concept that needs to be visually
two or more argument packages (via ArgumentPackage- modelled. Note that we only create visual representation for
Binding) the root class and its successors. We then need to see if
• An association of a number of ArgumentElements to a the root class has any attribute that must be inherited from
common group (via ArgumentGroup) its predecessors. An attribute that exists in a class is always
The current version of the SACM argumentation specifi- inherited to its successors.
cation is not equipped with any visual notation. It is believed Because we use visual inheritance approach, we need to
that the visual notation is an integral part of modern modelling start the design process from the root and inherit any base
languages and can help users in communicating their intended design to its child-classes by using depth first traversal. An
message in the form of a model (or models) to the reader [3]. It abstract-class does not have a visual representation, but it
would therefore be beneficial if we provide the visual notation still need to be analysed to see if we can define any design
for the SACM argumentation metamodel, and we shall use this constraint from its semantic. In addition, an abstract class
as an example application of our approach. could have an attribute which must be inherited to its child-
classes. A visual representation of attributes in an abstract-
III. V ISUAL I NHERITANCE AS PART OF N OTATION D ESIGN class might as well be defined based on the semantic of each
In this section, we describe the visual inheritance process attribute. Hence, in analysing an abstract-class we might get a
as part for designing a visual notation based on a predefined design constraint or a base design for attributes to be inherited
metamodel. This approach emphasises the design coherence to its child-classes.
between parent and child-classes, where the basic design On the other hand, a concrete-class must have a visual
characteristics of a parent-class must be inherited to its child- representation. In creating a visual representation of a class,
classes. We hypothesise that by inheriting the base design of we need to consider a base design or a design constraint that
Fig. 3. UML Class Diagram of SACM Argumentation Metamodel [8]
is inherited from its parent-class (if any). Then in creating a 7 to indicate what it represents. So, it must be culturally
visual representation of an attribute in a concrete-class, if there learned.
exists a base design that is inherited from a parent-class, we • Graphic Economy
need to combine the base design with the base design of the It is also essential to keep the number of the visual
concrete-class. If there is no base design of the attribute, then representations as minimal as possible (Graphic Econ-
we need to create a base design from its semantic. The detail omy) [3]. This is to make sure not to overload the total
of the process can be seen in Fig. 4. number of the visual representations that could cause
In designing the visual representations, we can adopt difficulty for the users in remembering all the notations
Bertin’s visual variables that can be used to graphically encode [3]. We suggest to keep the visual representations simple
information: shape, colour, size, texture, orientation, bright- by reusing the same visual representation for sub-classes
ness, position (horizontal and vertical). These visual variables that has close semantic meaning (e.g. relationship-types
can be used to develop numbers of graphical symbols by com- class); meanwhile, we can still distinguish their meaning
bining the variables together in different ways [27]. Besides while implementing them in the diagram by utilising the
that, we suggest to apply the following design principles: compositional rules of the visual representation which is
can be defined based on the relationship between classes
• Semantic transparency in the metamodel.
In creating the visual representation, we suggest cre-
ating the design of visual representation that conveys IV. A PPLICABILITY
the meaning of the semantic definition of the identified In this section, we present a case study to apply the visual
class (Semantic Transparency) [3], [4]. If no visual rep- inheritance. In this case, we adopt the SACM Argumentation
resentation directly conveys the meaning of the semantic Metamodel since currently there is no available visual notation
definition, then create the visual representation design that for this metamodel. A metamodel of SACM Argumentation
can provide a clue to the (majority) of targeted users. (see Fig. 3), that is documented in SACM manual [8], is used
If there is still no visual representation that can provide as an input to conduct the visual inheritance process. This
a clue to the majority of the targeted users, create the argumentation metamodel does not have any multiple inheri-
visual representation design that consensually (as a norm) tance in it, so this approach is applicable for this metamodel.
provides a closer meaning to the domain of the language. To begin the visual inheritance process, we need to choose
Peirce’s theory of signs [28] influences the idea of this a root class. Here, we choose the ArgumentAsset as the root
guideline. Peirce stated that the form of a sign could be class because it contains the core concept of the structured
classified as one of three types: argument. The ArgumentAsset is inherited public attributes
– An Icon has similar characteristics to the object that from the SACMElement class (in the Structured Assurance
is being referred, e.g., a photograph as it certainly Case Base Classes): gid (an element unique ID), isCitation
resembles whatever it depicts. (indicate whether an element cites another element), isAbstract
– An Index shows factual connection or clue to its object, (indicate an abstract element). The ArgumentAsset itself is an
e.g., using an image of smoke to indicate a fire. abstract-class, and there is no design constraint that we can
– A Symbol provides interpretive habit or norm of ref- define from its semantic. However, we still need to see the
erence to its object. Therefore, it needs to be learned, semantic of its attributes to see if we can have a base design
e.g., numbers. There is nothing inherent in the number for each attribute.
Fig. 4. The Visual Inheritance Process
Based on the semantic definition of gid attribute, it is a of the cited Assertion”. Here, we use the same representation
unique identifier for the SACM element. The type of the as +isCitation as both have related semantic meaning. All
gid attribute is string, therefore we decided to represent this attributes in Assertion then must be inherited to all its child-
attribute as a string that indicate the ID of the element. Then classes: Claim and AssertedRelationship.
for the attribute +isAbstract: True, because we could not find
any visual representation that can convey directly the meaning Claim is a concrete-class, so we need to create a visual
of abstract, we decided to use an arbitrary design choice. In representation for this class. In creating the visual repre-
this case, we will consistently use a dashed line to represent an sentation we should consider its semantic definition so we
abstract meaning. Meanwhile, for +isCitation, we consistently can visually convey its meaning: “Claims are used to record
use a closed square bracket to represent a citation, as is the propositions of any structured argument contained in an
commonly used in academic writing. ArgumentPackage. Propositions are instances of statements
that could be true or false, but cannot be true and false
The ArgumentAsset class has three child-classes: Assertion, simultaneously” [8]. Based on the semantic definition of a
ArtifactReference, and ArgumentReasoning. Hence, we inherit Claim, we could not find any visual representation that can
the attributes and their base design to the child-classes. directly infer the meaning of the semantic. Therefore, we
Assertion is an abstract-class, so we do not need to create adopt the visual representation that might provide a cue to
a visual representation for this class. However, in addition to the majority of targeted users that are already familiar with an
attributes that are inherited from its parent-class, this class existing assurance case notation. In this case, we reuse a visual
has an attribute, +assertionDeclaration with six enumeration representation of a Goal from a widely used assurance case
literals: Asserted, Axiomatic, Defeated, Assumed, NeedsSup- notation (i.e. The Goal Structuring Notation (GSN) [26]), that
port, and AsCited. From their semantics, we only can create has similar semantics with the Claim. Hence, we decided the
a base design for Defeated and AsCited. For defeated, it is visual representation for a Claim is a rectangle where the user
“indicating that the Assertion is defeated by counter-evidence can write down the propositional statement in it and the ID as
and/or argumentation”. Hence, we use a cross to convey this its attribute (gid) in the top left. Fig. 5 illustrates the visual
meaning. Then for AsCited, it is “indicating that because representation for a Claim. Then for the attribute +isAbstract:
the Assertion is cited, the AssertionDeclaration should be True, the AbstractClaim is visually represented as a dashed line
transitively derived from the value of the AssertionDeclaration rectangle. Meanwhile, for +isCitation, we place the rectangle
Fig. 5. The visual representation of a Claim
in a closed square bracket.
There is also an attribute (i.e. assertionDeclaration) of the
Assertion class that is inherited to the Claim class. This
attribute has six enumeration literals (Asserted, Axiomatic,
Defeated, Assumed, NeedsSupport, and AsCited) that the Fig. 6. Types of Claim
visual representations of each attribute values need to be
created as instances in the Claim class. In this case, the
instances of the Claim class are: Asserted Claim, Axiomatic definition, this class is an abstract-class, so we do not need to
Claim, Defeated Claim, Assumed Claim, NeedsSupport Claim, create a visual representation for this class. Besides that, the
and AsCited Claim. As mentioned in the visual inheritance semantic definition describes that this class is used to declare
approach guideline process in the previous section, the base a type of association, which then became the design constraint
design for these attribute values need to be inherited from the to be inherited to its child-classes. There are several visual rep-
base design of the class, in this case is the Claim class. Then, resentations that can be used to represents an association e.g.
we need to modify their base design to convey the semantic colours and lines. We decided to adopt a ’line’ to represents
definition of these attribute values. As follows we describe the the AssertedRelationship since it can give information about
semantic definition of each attribute value (based on [8]) along the source and target of the AssertedRelationship. In this case,
with the proposed design of the visual representation and the the types of the line can vary based on the semantic definition
rational behind the design. of the AssertedRelationship concrete child-classes.
• asserted, “the default enumeration literal, indicating that AssertedRelationship class has attributes that need to be
an Assertion is asserted”. Based on this definition, the inherited to its child-classes: isCounter, assertionDeclaration,
default Claim that being asserted is called as as asserted gid, isAbstract, and isCitation. From all these attributes, only
Claim, the visual representation of the asserted Claim is isCounter that has no base design yet. However, from its se-
the visual representation of the Claim. mantic, we can not define its base design without having a base
• axiomatic, “indicating the Assertion being made by the design of the class, so we can not create it in an abstract-class.
author is axiomatically true, so that no further argumen- The AssertedRelationship class has five concrete child-classes
tation is needed”. Here, we use a thick line below the for which visual representations need to be created including
rectangle to indicate a sign of “no further argumentation visual representations as instances of the inherited attributes.
is needed” (i.e. declaring axiomatically true). We proposed design, based on the semantic definition (on
• defeated, we already have a base design for this attribute, [8]) of all the AssertedRelationship’s concrete child-classes.
which is a cross. Hence, we add a cross on top of the In each case, we could not find any visual representation that
rectangle to convey the meaning of defeated Claim. intuitively conveys the semantic definition, so we used either
• assumed, “indicating that the Assertion being made is visual representations from existing notations or proposed an
declared by the author as being assumed to be true rather arbitrary design. As follows we describe the result of the
than being supported by further argumentation”. Here, we design process:
add a gap in the bottom part of the rectangle to represent AssertedInference
that there is no supporting evidence or argumentation. • Definition:“records the inference that a user declares
• needsSupport, “indicating that further argumentation has to exist between one or more Assertion (premise) and
yet to be provided to support the Assertion”. For this, we another Assertion (conclusion)”.
add three dots in the bottom-centre part of the rectangle • Visual representation: We use a solid arrowhead line to
to represent that further evidence or argumentation is visualise an AssertedInference. This visual representation
required. is influenced by a SupportedBy visual representation in
• asCited, we already have a base design for this attribute, GSN that indicating an inferential relationship. Then for
which is a closed square bracket. Therefore, we use the the attributes, we already have a base design for each
same representation as +isCitation. attribute except for isCounter, which has semantic defini-
Fig. 6 shows the summary of all Claim types. tion “indicating that the AssertedRelationship counters its
After designing all Claim types, we continue to the other declared purposes”. We use a hollow-head line to indicate
child-class of the Assertion class: the AssertedRelationship the counter purpose of the AssertedInference and we use
class. The semantic definition of this class is: “the abstract this consistently to represent isCounter attribute for all
association class that enables the ArgumentAssets of any types of relationship. Then to create the visual represen-
structured argument to be linked together” [8]. Based on this tation for each attribute, we only need to combine the
defined base design of each attribute with the base design
of AssertedInference. Note that the other child-classes of
AssertedRelationship also have the same attributes as this
class, so the process of creating the visual representation
of the attributes is similar to this.
AssertedEvidence
• Definition: “records the declaration that one or more
artifacts of Evidence (cited by ArtifactReference) provide
information that helps establish the truth of a Claim”.
• Visual representation: We adopted the visual represen-
tation from GSN, that is a solid arrowhead which is
representing the evidential relationships. In this case, the
visual representation is similar to the visual representation
for AssertedInference, but we can distinguish them by
identifying the source of the relationship (line). The
source is an Evidence for AssertedEvidence (cited by Fig. 7. Types of Relationship
ArtifactReference), and a Claim for AssertedInference.
AssertedContext
• Definition:“can be used to declare that the artifact cited Fig. 8. The visual representation of a MetaClaim
by an ArtifactReference(s) provides the context for the
interpretation and scoping of a Claim or ArgumentRea-
soning element”. ArtifactReference (as described in [8] for AssertedArti-
• Visual representation: We cannot use the existing vi- factContext constraints).
sual representation from GSN visual representation that As the result of the design combinations and as summary
conveys similar meaning (i.e. hollow arrowhead line for of all types of AssertedRelationship can be seen in Fig. 7.
inContextOf ) because we already used this type of visual We have finished designing the visual representations for
representation. Therefore, we decided to create our own classes that are successors of the root. Next, we see if all
design for AssertedContext, with requirements: the design relationships have been represented. From all relationship-
needs to be a line-type to represents a relationship type; types only metaClaim, which is an association relationship
and the type of the line-head can be designed as a solid between Assertion and Claim, has not been represented. The
or hollow. As the result, we use solid diamondhead line +metaClaim association indicates ”references Claims concern-
for AssertedContext and hollow diamondhead line for ing the Assertion”. Therefore, we need to create a visual
representing Counter AssertedContext. representation that can convey the semantic meaning of the
AssertedArtifactSupport +metaClaim, in this case as a type of relationship visual
• Definition: “records the assertion that one or more arti- representation that the source of the relationship is a Claim and
facts support another artifact”. the targeted of is the Assertion types (i.e. the concrete child-
• Visual representation: Here, we reuse the visual represen- classes of the Assertion) [8]. Based on the semantic definition,
tation of AssertedInference since the main idea from its we decided to use a ’line’ to represent the +metaClaim. Here,
semantic meaning also supporting the targeted elements. we use the ”crow’s foot line” since we do not have a constraint
We believed reusing the same visual representation to such as ”counter” +metaClaim that need to be visualised in the
represents different classes that have a closer semantic form of a hollow head-line. The illustration of the +metaClaim
meaning can help to minimise the number of the visual visual representation can be seen in Fig. 8.
representations. To distinguish them, we identify the After designing the visual representation of the Assertion
source and target elements. For AssertedArtifactSupport, class, we need to design the visual representation of the other
the source and target elements must be of type ArtifactRe- child-classes of the ArgumentAsset class: ArtifactReference
ference (as described in [8] for AssertedArtifactSupport and ArgumentReasoning. According to [8], “ArtifactReference
constraints). enables the citation of an artifact as information that relates
AssertedArtifactContext to the structured argument.” This semantic definition inspired
• Definition: “records the assertion that one or more arti- us to create the visual representation of ArtifactReference in a
facts provide context for another artifact”. form of a file or document icon because we think it infers the
• Visual representation: Here, we reuse the visual repre- semantic meaning. Besides that, for the ArgumentReasoning,
sentation of AssertedContext because the main idea from we created a visual representation in a form of an annotation-
their semantic meaning are providing context for the type icon that can be attached to the instances of Asserte-
targeted element. To distinguish them, we can identify the dRelationship class. This is to convey the semantic meaning
source and the targeted elements. For AssertedArtifact- of the ArgumentReasoning: “can be used to provide additional
Context the source and target elements must be of type description or explanation of the asserted relationship”. Fig. 9
[5] N. Genon, P. Heymans, and D. Amyot, “Analysing the cognitive effec-
tiveness of the bpmn 2.0 visual notation,” in International Conference
on Software Language Engineering. Springer, 2010, pp. 377–396.
[6] T. R. Green, “Cognitive dimensions of notations,” People and computers
V, pp. 443–460, 1989.
[7] G. Costagliola, A. Delucia, S. Orefice, and G. Polese, “A classification
framework to support the design of visual languages,” Journal of Visual
Fig. 9. The visual representations of an ArtifactReference and an Argumen-
Languages & Computing, vol. 13, no. 6, pp. 573–600, 2002.
tReasoning
[8] O. M. G. (OMG), Structured assurance case metamodel (SACM),
Version 2.0, 2018, https://www.omg.org/spec/SACM/About-SACM/.
[9] G. Popescu and A. Wegmann, “Using the physics of notations theory
shows the visual representations of the ArtifactReference and to evaluate the visual notation of seam,” in Business Informatics (CBI),
2014 IEEE 16th Conference on, vol. 2. IEEE, 2014, pp. 166–173.
the ArgumentReasoning. [10] D. van der Linden, I. Hadar, and A. Zamansky, “What practitioners
really want: requirements for visual notations in conceptual modeling,”
V. L IMITATIONS Software & Systems Modeling, pp. 1–19, 2018.
There are some limitations to the current version of the [11] J. Krogstie, G. Sindre, and H. Jørgensen, “Process models representing
knowledge for action: a revised quality framework,” European Journal
proposed approach. First, in selecting the root in the meta- of Information Systems, vol. 15, no. 1, pp. 91–102, 2006.
model, the scope of the concept is used as the only consid- [12] R. Schuette and T. Rotthowe, “The guidelines of modeling–an approach
eration. This aspect could be explored further to have more to enhance the quality in information models,” in International Confer-
ence on Conceptual Modeling. Springer, 1998, pp. 240–254.
specific justification in selecting the root. Second, the proposed [13] D. Moody and J. van Hillegersberg, “Evaluating the visual syntax of
approach highly depends on the predefined metamodel, and uml: An analysis of the cognitive effectiveness of the uml family of dia-
the metamodel is depended on the method and style used grams,” in International Conference on Software Language Engineering.
Springer, 2008, pp. 16–34.
by the meta-modeller. Third, currently, the proposed approach [14] D. L. Moody, P. Heymans, and R. Matulevičius, “Visual syntax does
is being applied in a case study since it is part of work in matter: improving the cognitive effectiveness of the i* visual notation,”
progress. It is important to explore the applicability of the Requirements Engineering, vol. 15, no. 2, pp. 141–175, 2010.
[15] N. Genon, D. Amyot, and P. Heymans, “Analysing the cognitive ef-
visual inheritance mechanism in another case study in order fectiveness of the ucm visual notation,” in International Workshop on
to evaluate the validity aspect. System Analysis and Modeling. Springer, 2010, pp. 221–240.
[16] P. Mäder and J. Cleland-Huang, “A visual traceability modeling lan-
VI. C ONCLUSION AND F UTURE W ORK guage,” in International Conference on Model Driven Engineering
Languages and Systems. Springer, 2010, pp. 226–240.
We have outlined the visual inheritance as part of visual [17] A. Algablan, “A visual notation and an improvement for the syntax of
notation design (considered as an extension of the Semiotic larman’s operation contracts,” Ph.D. dissertation, University of Ottawa,
2016.
Clarity principle of PoN [3] regarding a guideline about a [18] M. d. G. da Silva Teixeira, G. K. Quirino, F. Gailly, R. de Almeida Falbo,
complete monosemy [27] through the inheritance mechanism). G. Guizzardi, and M. P. Barcellos, “Pon-s: a systematic approach for
The proposed approach emphasises the design coherence be- applying the physics of notation (pon),” in Enterprise, Business-Process
and Information Systems Modeling. Springer, 2016, pp. 432–447.
tween parent- and child-classes to provide design efficiency [19] H. Störrle and A. Fish, “Towards an operationalization of the ”physics
(in terms of reusability and extensibility) as well as to help of notations” for the analysis of visual languages,” in International
notation users to easily infer the semantic meaning of the Conference on Model Driven Engineering Languages and Systems.
Springer, 2013, pp. 104–120.
visual representations that have a similar base design. We [20] D. van der Linden, A. Zamansky, and I. Hadar, “A framework for
have also described the applicability of the proposed approach improving the verifiability of visual notation design grounded in the
by designing the visual notations for SACM Argumentation physics of notations,” in Requirements Engineering Conference (RE),
2017 IEEE 25th International. IEEE, 2017, pp. 41–50.
metamodel. As the future work, we are planning to conduct [21] T. R. Green, A. E. Blandford, L. Church, C. R. Roast, and S. Clarke,
empirical studies to test the effectiveness [3], [4] of the visual “Cognitive dimensions: Achievements, new directions, and open ques-
inheritance. In this case, we are interested in observing how tions,” Journal of Visual Languages & Computing, vol. 17, no. 4, pp.
328–365, 2006.
effective is the idea of design coherence. We are also interested [22] R. Ducournau and J. Privat, “Metamodeling semantics of multiple
in testing the semantic transparency [3], [4] of the notation as inheritance,” Sci. Comput. Program., vol. 76, no. 7, pp. 555–586, 2011.
a result of adopting the visual inheritance process. [23] G. B. Singh, “Single versus multiple inheritance in object oriented
programming,” ACM SIGPLAN OOPS Messenger, vol. 6, no. 1, pp.
30–39, 1995.
R EFERENCES [24] R. A. Cain, J. A. De Lu, and R. E. Lemke, “Development system with
[1] R. M. A. El-Ghafar, A. M. Ghareeb, and E. S. Nasr, “Designing user methods for visual inheritance and improved object reusability,” Jul. 22
comprehensible requirements engineering visual notations: A systematic 1997, uS Patent 5,651,108.
survey,” in Informatics and Systems (INFOS), 2014 9th International [25] C. P. Jazdzewski, “Development system with methods providing visual
Conference on. IEEE, 2014, pp. SW–10. form inheritance,” Dec. 14 1999, uS Patent 6,002,867.
[2] A. El Kouhen, A. Gherbi, C. Dumoulin, and F. Khendek, “On the [26] GSN, Goal Structuring Notation (GSN) Community Standard, Ver-
semantic transparency of visual notations: experiments with uml,” in sion 1, 2011, http://www.goalstructuringnotation.info/documents/GSN\
International SDL Forum. Springer, 2015, pp. 122–137. Standard.pdf.
[3] D. Moody, “The physics of notations: Toward a scientific basis for con- [27] B. Jacques, “Semiology of graphics: diagrams, networks, maps,” Uni-
structing visual notations in software engineering,” IEEE Transactions versity of Wisconsin Press, Madison, Wisconsin, 1983.
on Software Engineering, vol. 35, no. 6, pp. 756–779, 2009. [28] A. Atkin, “Peirce’s theory of signs,” in The Stanford Encyclopedia of
[4] K. Arning and M. Ziefle, “”it’s a bunch of shapes connected by lines”: Philosophy, summer 2013 ed., E. N. Zalta, Ed. Metaphysics Research
Evaluating the graphical notation system of business process modeling Lab, Stanford University, 2013.
languages,” in Full paper at the 9th International Conference on Work
With Computer Systems, WWCS, 2009.