Implementing OntoUML Models with OntoObject-Z Speciﬁcations: A

Proof of Concept Relying on a Partial Ontology for VLANs

Mohamed Bettaz

Faculty of Information Technology, Czech Technical University in Prague, Thakurova 9, Prague, Czech Republic

Keywords:

Ontology, UML, UFO, OntoUML, Object-Z, OntoObject-Z, Descriptive Language, Metamodel, EBNF,

VLAN.

Abstract:

OntoObject-Z is a descriptive language inspired by OntoUML. Just as OntoUML is a proﬁle for the Uni-

ﬁed Modeling Language (UML), OntoObject-Z is an extension of the Object-Z notation. The objective of

this article is threefold. We ﬁrst deﬁne a metamodel for OntoObject-Z and an EBNF-like notation formal-

izing the syntax of OntoObject-Z speciﬁcations. Second, we construct a partial ontology for Virtual Local

Area Networks (VLANs) and describe it by OntoUML models. Third, we implement our OntoUML models

with OntoObject-Z speciﬁcations. The OntoObject-Z metamodel is expressed in OntoUML and the proposed

EBNF rules are based on OntoUML concepts. Thanks to this, each syntactically correct OntoObject-Z speci-

ﬁcation corresponds de facto to a correct implementation of an OntoUML model.

1 INTRODUCTION

OntoObject-Z (Bettaz and Maouche, 2023a) is a de-

scriptive language inspired by OntoUML, an onto-

logically well-deﬁned language used for conceptual

modelling (Guizzardi, 2005). Just as OntoUML is

a UML proﬁle, OntoObject-Z is an extension to the

Object-Z notation (Smith, 2000). Our interest in

UML and Object-Z is motivated by the fact that, de-

spite their relative longevity, both continue to attract

interest from the academic and industrial communi-

ties. In addition, these two languages appear promi-

nently in several undergraduate and graduate pro-

grams. Finally, both are equipped with modelling and

veriﬁcation tools (TOZE for Object-Z, and OpenPonk

for UML and OntoUML). TOZE was used to edit the

OntoObject-Z speciﬁcations presented in Section 7,

and OpenPonk to edit and verify the OntoObject-Z

metamodel presented in Section 5 and the OntoUML

models presented in Section 6. Our interest in On-

toUML and OntoObject-Z is motivated by their status

of prescriptive languages acquired thanks to their an-

choring in ontologies (cf. Section 4 and Section 5).

For a good discussion on the prescriptiveness and

descriptiveness of models and ontologies, the kind

reader may consult the excellent work of (Aßmann

et al., 2006). The basic ingredients of OntoObject-

https://orcid.org/0000-0003-1346-0244

Z were introduced in (Bettaz and Maouche, 2023a)

and (Bettaz and Maouche, 2023b), where it was in-

formally shown how to map some of the basic On-

toUML constructs into OntoObject-Z. In this paper,

we address one of the main points announced as “fu-

ture work” in (Bettaz and Maouche, 2023a), which

is to provide OntoObject-Z with a metamodel, aim-

ing to be the very ﬁrst step towards the formaliza-

tion of this language. Second, we construct a partial

ontology for VLANs and describe it with OntoUML

models. Third, we implement our OntoUML models

with OntoObject-Z speciﬁcations. The OntoObject-

Z metamodel is expressed in OntoUML and the pro-

posed EBNF rules are based on OntoUML concepts.

Thanks to this, each syntactically correct OntoObject-

Z speciﬁcation corresponds de facto to a correct im-

plementation of an OntoUML model. Equipped with

a relatively “diverse” set of OntoUML constructs,

we believe that our VLANs’ ontology can serve as

a proof of concept for such an implementation. A

ﬁrst motivation behind the idea of implementing On-

toUML models with OntoObject-Z speciﬁcations is to

describe ontologies in a formal descriptive language.

A second motivation is to address most of the phases

of the Software Development Life Cycle (SDLC) in a

language equipped with a reﬁnement method. Indeed

OntoObject-Z, based on Object-Z, “beneﬁts” from

such a method. In (Bettaz and Maouche, 2023b), we

deﬁne a reﬁnement approach that can be exploited in

Bettaz, M.

Implementing OntoUML Models with OntoObject-Z Speciﬁcations: A Proof of Concept Relying on a Partial Ontology for VLANs.

DOI: 10.5220/0012854500003758

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 14th International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2024), pages 407-414

ISBN: 978-989-758-708-5; ISSN: 2184-2841

407

this sense. A third motivation is to express speciﬁ-

cations and constraints on them in a single language.

Indeed like UML, OntoUML uses OCL (Object Con-

straint Language) to express constraints on domain

descriptions. The construction of an ontology for

VLANs is motivated by our interest in domain knowl-

edge (Bettaz, 2024), a concept known from the soft-

ware engineering discipline. Indeed, to develop an

application or system for a domain, you need a cer-

tain expertise (knowledge) of the domain. In this con-

text, to develop “high quality” protocol-speciﬁc ap-

plications, you need in-depth knowledge of protocol-

based VLANs (not just port-based or address-based

VLANs). In this sense VLANs can be considered as

a domain in their own right. More details about the

motivation behind our choice of building an ontology

for VLANs are given in Section 6.

The rest of this paper is organized as follows. Sec-

tion 2 presents our research method. In Section 3 we

discuss some related works. Section 4 gives succinct

information about the Uniﬁed Foundation Ontology

(UFO) and OntoUML. In Section 5 we present our

metamodel for OntoObject-Z and the EBNF rules for-

malizing the syntax of OntoObject-Z speciﬁcations.

Section 6 is devoted to the ontology for VLANs and

its description by OntoUML. The implementation of

the OntoUML models describing our VLANs’ ontol-

ogy with OntoObject-Z speciﬁcations is presented in

Section 7. Concluding remarks and future work are

presented in Section 8.

2 RESEARCH METHOD

This paper uses a formal approach (Roggenbach et al.,

2022) to provide OntoObject-Z with a metamodel

and OntoObject-Z speciﬁcations with a formal no-

tation describing their syntax. The OntoObject-Z

metamodel is expressed in OntoUML and the for-

mal notation (describing the syntax of OntoObject-

Z speciﬁcations) is expressed by EBNF rules based

on OntoUML concepts. Thanks to this, each syn-

tactically correct OntoObject-Z speciﬁcation corre-

sponds de facto to a correct implementation of an On-

toUML model. For the construction of our VLANs’

ontology we use an analytical method and a “reverse-

engineering” approach relying on material from spe-

cialized literature such as, (Comer, 2015), (Odom,

2016), (Seifert and Edwards, 2008), and sometimes

on our long-life experience in teaching and research.

3 RELATED WORKS

Mapping between UML and Object-Z dates back to

the work of (Kim and Carrington, 2000). An institu-

tion based on ideas from to this work gives a formal

syntax and semantics to Object-Z (Baumeister et al.,

2015). The work in (Bettaz and Maouche, 2017)

shows how a “combination” of UML and OCL can

be mapped into Object-Z. The objective was to show

that Object-Z can serve as an implementation lan-

guage for “UML + OCL”. Indeed, thanks to its pred-

icate part, Object-Z can implement the constraints

expressed in OCL. From an SDLC perspective, this

leads to the adoption of an “evolutionary” approach

instead of a “discrete” approach. This applies mainly

in the context of Model Driven Requirements Engi-

neering (MDRE) (Assar, 2014). In an evolutionary

approach, most of the SDLC phases are processed us-

ing a single language, where we proceed through step-

wise reﬁnement. For this, a reﬁnement idea based on

the transformation of inheritance into delegation can

be exploited for OntoObject-Z (Bettaz and Maouche,

2023b). In a discrete approach a different language

is used to process each phase, which raises the prob-

lem of “correct” mapping of speciﬁcations expressed

in various languages.

4 UFO AND OntoUML

OntoUML is a language for conceptual modelling,

conceived as a proﬁle of UML based on UFO. Report-

ing on OntoUML and UFO is out of the scope of this

paper; the reader interested in more detail is kindly

directed to the rich bibliography treating on both sub-

jects - cf. for instance (Guizzardi et al., 2021) and

(Pergl, 2023). In a nutshell, UFO classiﬁes “entities”

into two broad “categories” named sortals and non-

sortals. Instances (individuals) of sortals (types) al-

ways have one and the same identity principle, and

each instance must have exactly one identity. In-

stances of non-sortals can have different identity prin-

ciples. Indeed, non-sortals are abstract classes. Sor-

tals and non-sortals can be either rigid or anti-rigid.

Rigidity is a qualiﬁer for entities that are unable to

adapt to change, while anti-rigidity is a qualiﬁer for

entities that do. The concepts of rigidity and anti-

rigidity are formalized in modal logic; cf. for instance

(Guizzardi et al., 2021) and (Pergl, 2023). Exam-

ples of rigid sortals, anti-rigid sortals, rigid non-sortal,

and anti-rigid non-sortal are given in Section 6. On-

toUML uses sortals and non-sortals in their rigid and

anti-rigid form as stereotypes for its classes (in the

sense of UML classes). Moreover, in OntoUML, as-

SIMULTECH 2024 - 14th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

408

sociations are also stereotyped. These stereotypes and

others (cf. Section 5) bring a noticeable change in the

semantics of UML models. A stereotype is placed be-

tween << and >>. Stereotype (Kind), for instance,

is written as <<Kind>>.

5 OntoObject-Z

The basic ingredients of OntoObject-Z were intro-

duced in (Bettaz and Maouche, 2023a). In this sec-

tion, we present a metamodel for OntoObject-Z (cf.

Figure 1) and an EBNF-like notation formalizing the

syntax of OntoObject-Z speciﬁcations.

Figure 1: An OntoUML metamodel for OntoObject-Z.

Since OntoObject-Z borrows stereotypes from

OntoUML, it is quite “natural” to build the very ﬁrst

OntoObject-Z metamodel in OntoUML. Another rea-

son is that OntoUML is supported by a tool (Open-

Ponk) allowing to verify OntoUML models. For sake

of readability, we will write between braces the names

used in the different ﬁgures when they are mentioned

in the text. Our metamodel (cf. Figure 1) shows

that an OntoObject-Z class (OntoObject-ZClass) is a

“whole” having a name and a stereotype. It consists

of three “parts”: a basic attribute part (BasicAttribute)

representing its basic attributes, a reference attribute

part (ReferenceAttribute) representing its reference

attributes, and a predicate part (Predicate) represent-

ing its predicates. A basic attribute has name and a

type. A reference attribute has a name, a type and a

stereotype. The types of the various attributes relat-

ing to the whole and to the various parts are deﬁned

by enumeration type declarations, which are nothing

more than UFO stereotypes used in OntoUML. A for-

mal deﬁnition for basic and reference attributes (in-

cluding the signiﬁcance of stereotyping for reference

attributes) is given in (Bettaz and Maouche, 2023a).

The OCL constraint associated with the association

(subclasses) states that an OntoObject-Z class cannot

be its own subclass. Similar OCL expressions can

be formulated to specify constraints on relationships

between the various stereotypes deﬁned for class

stereotypes (Cls stereotype). Also, the OntoObject-

Z metamodel deﬁnes an OntoObject-Z speciﬁcation

(OntoObject-ZSpeciﬁcation) as a collection of several

OntoObject-Z classes.

We deﬁne the formal syntax for OntoObjectZ

speciﬁcations with the following EBNF-like rules.

<OntoObject-Z speciﬁcation> ::= {OntoObject-

Z class}+

<OntoObject-Z class> ::= <header> <state>

<header> ::= <header of sortal class> |

<header of sortal class> ::=

<<<cls stereotype>>>

<cls name> [{<cls name>}]

<header of nonsortal class> ::=

<<<cls stereotype>>> <cls name> : abstract

<cls stereotype> ::= category | collective | kind |

| relator | role | rolemixin | subkind

<state> ::= [<declaration>] [<predicate>]

<declaration> ::= {<basic attribute> |

<reference attribute>}

<basic attribute> ::=

<<<cls stereotype>>>

<cls name> :

<type name> ::= boolean | integer | . . .

<ref attribute> ::=

<<<cls stereotype>>>

<cls name> :

<<<ref stereotype>>> <ref attribute name> :

P <<<ref stereotype>>> <cls name>

<ref stereotype> ::= characterization | componentof

mediation | memberof | subcollectionof | subquanti-

tyof

<predicate> ::=

{<multiplicity predicate> |

<navigability predicate> |

| isDisjoint | isComplete}

<multiplicity predicate> ::=

# <ref attribute name> <rel operator> <value>

<rel operator> ::= >= | <= | = | < | > | !=

<value> ::= 0 | 1 | 2 | ...

<is whole for predicate> ::= <cls name> isW-

holeFor <cls name>

<is part of predicate> ::= <cls name> isPartOf

<navigability predicate> :: = ∀ <var name> :

The formal deﬁnition for the predicates (isWhole-

Implementing OntoUML Models with OntoObject-Z Speciﬁcations: A Proof of Concept Relying on a Partial Ontology for VLANs

409

For) and (isPartOf) can be deﬁned using the predicate

logic in the same way as (isDisjoint) and (isComplete)

were deﬁned in (Bettaz and Maouche, 2023a).

6 DESCRIPTION OF THE VLANS’

ONTOLOGY

In this section we present our ontology for VLANs

and its description with OntoUML. Describing

VLANs in OntoUML allows to have a shared con-

ceptualization not only for various (hardware / soft-

ware) entities composing a VLAN but also for the

knowledge (implicitly) deﬁned by their interrelation-

ships. So, while it is probably obvious to list all

the concepts revolving around VLANs such as broad-

cast domains, collision domains, LANs’ generations,

computing devices, transmission media, virtual LAN

switches, port-based VLANs, address-based VLANs,

Layer 3-based VLANs, native VLANs, VLANs using

separate physical links, VLANs using trunks, Dot1q

protocol, routing between VLANs, VLANs using

routers or Layer 3 switches, bridged LANs, bridged

LANs containing cycles, spanning trees, spanning

tree protocols, forwarding tables, forwarding algo-

rithms, blocked ports, root ports, designated ports,

disconnected bridges, designated bridges and so forth,

nothing is less obvious than establishing all the in-

terrelationships in a concise, complete and consis-

tent manner. For sake of readability, our model for

VLANs’ ontology is decomposed into four (ontol-

ogy) “fragments”. The ﬁrst fragment presents vari-

ous generations of LANs. The second fragment de-

scribes the concept of VLAN switch and various types

of VLANs (port-based, address-based, and Layer 3-

based). The third fragment addresses the notion of

routing between VLANs. The fourth fragment intro-

duces the concept of bridged LANs, the notions of

spanning tree, and Spanning Tree Protocol (STP) as

well. Classes that are “replicated” serve to “glue” the

various fragments.

6.1 LAN Generations

The ontology fragment depicted in Figure 2 should

be read as follows. A LAN (<<Kind>> LAN)

is seen as a kind of the category of computer net-

works (<<Category>> Computer Network). Kinds

(stereotype <<Kind>>) are rigid sortals, while cat-

egories (stereotype <<Category>>) are rigid non-

sortals. Non-sortals in UFO (and in OntoUML) are

abstract classes (in the sense of object-oriented pro-

gramming), and they are written in italic. The rigid

sortal (<<Mode>> Broadcast Domain) expresses

Figure 2: LAN Generations: an OntoUML representation.

the fact that a LAN is deﬁned as a broadcast do-

main. Stereotype <<Mode>> is used to empha-

size the importance of a given characteristic of the

“bearer” (<<Kind>> LAN) in our case. The associ-

ation between a mode and a bearer should be “dec-

orated” by the stereotype (<<characterization>>).

The various LAN generations are all seen as LANs,

and are de facto also broadcast domains, since they

all inherit the relationship (<< characterization >>

deﬁned as). As expected, the various generations of

LANs are distinguished just by the type of the used

transmission medium (<<Relator>> Thick Cable),

(<<Relator>> Thin Cable), etc. The relationships

ending by a diamond describe a “whole-part” rela-

tionship. A “ﬁlled” diamond expresses the fact that

a “part” is not shareable (a thick cable is not shared

by two different LANs, and so on.) The multiplici-

ties written next to the diamonds express the fact that

the “whole” is not mandatory for the “part” (while a

ﬁrst generation LAN necessitates two or more com-

puting devices, a ﬁrst generation LAN is not manda-

tory for a computing device). The various kinds of

transmission media are seen are relators (stereotype

<<Relator>>). A thick cable, for instance, relates

(mediates) two or more connected computing devices.

A connected computing device (<<Role>> Con-

nected Computing Device) is seen as a role played

by a computing device ( <<Kind>> Computing De-

vice).

6.2 VLAN Types

The ontology fragment depicted in Figure 3 should be

read as follows. A VLAN (<<Subkind>> VLAN) is

a switched LAN (<<Subkind>> Switched), which

is itself a LAN (<<Kind>> LAN). As a LAN,

a VLAN is also deﬁned as a broadcast domain.

A VLAN can be created or removed at any time.

Thus, we have two phases: (<<Phase>> Cre-

SIMULTECH 2024 - 14th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

410

Figure 3: VLAN Types.

ated VLAN) and (<<Phase>> Removed VLAN).

(<<Subkind>> VLAN) is an abstract class because

these two phases deﬁne a generalization set that is

complete and disjoint. This is expressed by the

meta-attribute {complete, disjoint}. A VLAN in the

ﬁrst phase (<<Phase>> Created VLAN) consists of

one or more VLAN switches (<<Kind>> VLAN

Switch), where a VLAN switch is seen as an “in-

separable part” of a LAN switch (the meta-attribute

{inseparable} is used for this purpose). Inseparable

here means that an instance of (<<Kind>> VLAN

Switch) cannot exist without the same instance of

(<<Kind>> LAN Switch). The various types

of VLAN (<<Role>> Port-based), (<<Role>>

Address-based), and (<<Role>> Layer3-based) are

modelled as roles played by a created VLAN. As ex-

pected, a port-based VLAN is associated with two

or more ports, an address-based VLAN is associated

with two more MAC addresses, and a Layer3-based

VLAN is associated with two or more network ap-

plications. A conﬁgured VLAN switch (<<Role>>

Conﬁgured VLAN Switch) and a connected comput-

ing device (<<Role>> Connected Computing De-

vice) are related by twisted pairs (<<Relator>>

Twisted Pair).

6.3 Routing Between VLANs

The ontology fragment depicted in Figure 4 should be

read as follows. A switched VLAN (<<SubKind>>

VLAN) using a trunk (<<Role>> Using a Trunk)

and a switched VLAN using separate physical

links (<<Role>> Using Separate Links) can be

seen as two different roles played by a VLAN

(<<SubKind>> VLAN). In such a situation the

router plays also two roles (<<Role>> Connected

to Trunk) and (<<Role>> Connected to Separate

Links). The relators (<<Relator>> Trunk) and

Figure 4: Routing between VLAN.

(<<Relator>> Separate Physical Links) mediate, re-

spectively, both of these material relations. As we

know, when a VLAN is using a trunk, the frames are

tagged before crossing the router. This is represented

by (<<Mode>> Tagged Frame).

6.4 Bridged LAN

The ontology fragment depicted in Figure 5 should

be read as follows. A bridged LAN (<<Kind>>

Figure 5: Bridged LAN.

Bridged LAN) consists of a bridge (<<Kind>>

Bridge) and two or more LAN segments (<<Role>>

LAN Segment). The bridge is “characterized” by a

forwarding table (<<Quality>> Forwarding Table),

with a distinguished attribute deﬁning its size, and

a forwarding algorithm (<<Quality>> Forwarding

Algorithm) with a distinguished attribute deﬁning its

performance. A bridged LAN, as a LAN, is also seen

as a broadcast domain (<<Mode>> Broadcast Do-

main). Both bridged LAN with cycles (<<Role>>

Bridged LAN with Cycles) and bridged LAN with no

cycles (<<Role>> Bridged LAN With no Cycles)

are seen as roles of a bridged LAN. The spanning

tree protocol (<<Relator>> Spanning Tree Proto-

col) is used to associate a spanning tree (<<Role>>

Implementing OntoUML Models with OntoObject-Z Speciﬁcations: A Proof of Concept Relying on a Partial Ontology for VLANs

411

Spanning Tree) with a bridged LAN with cycles. All

spanning trees form a collective (<<Collective>>

All Spanning Trees). A bridge in a spanning tree

(<<Role>> Bridge in Spanning Tree) possesses one

root port, one designated port, and can have one or

more of its ports blocked. In case that all of the ports

are blocked, the bridge is merely disconnected. These

are modelled as attributes of (<<Role>> Bridge in

Spanning Tree).

7 IMPLEMENTATION OF THE

VLANS’ ONTOLOGY

For lack of space, only the implementation of the

ﬁrst fragment is presented in this Section. For sake

of readability, the implementation of our ﬁrst on-

tology fragment is represented by several pieces of

OntoObject-Z speciﬁcations (cf. Figures 6, 7, 8, 9,

and 10).

<< category >> ComputerNetwork : abstract

<< kind >> (WAN, MAN, LAN)

<< category >> ComputerNetwork

<< kind >> LAN : (broadcastDomain :

P << Mode >> BroadcastDomain) :

<< characterization >>

(WAN, MAN, LAN)isDisjoint

Figure 6: Networks kinds.

The piece of OntoObject-Z speciﬁcation depicted

in Figure 6 describes an OntoObject-Z abstract

class (<<category>> ComputerNetwork: abstract)

implementing the OntoUML abstract class of the

same name, and an OntoObject-Z class (<<kind>>

(WAN, MAN, LAN)) implementing the three On-

toUML classes of the same name (cf. Subsection 6.1).

OntoObject-Z “enriches” Object-Z with a new

notation that consists in regrouping the speciﬁca-

tion of two or more “child” classes together with

their “parent” class. The motivation behind this,

is to write concise and more readable speciﬁca-

tions. Next, our piece of OntoObject-Z speciﬁ-

cation declares a reference attribute (broadcastDo-

main) for (<<kind>> LAN). This reference attribute

has the type (PBroadcastDomain) and the stereo-

type (<<characterization>>). (<<Mode>>) is the

stereotype of the class (BroadcastDomain). The pred-

icate part of our piece of OntoObject-Z speciﬁcation

<< category >> ComputerNetwork : abstract

<< subkind >> (First, Second, Third, Switched)

<< kind >> LAN

<< subkind >> First :<< compOf >> thick :

P << relator >> Thick

<< subkind >> First :<< compOf >>

compDevice : P << kind >> CompDevice

<< subkind >> Second :<< compOf >>

thin : P << relator >> Thin

<< subkind >> Second :<< compOf >>

compDevice : P << kind >> CompDevice

<< subkind >> Third :<< compOf >>

hub : P << relator >> Hub

<< subkind >> Third :<< comOf >>

compDevice : P << kind >> CompDevice

<< subkind >> Switched :<< compOf >>

lanSwitch : P << relator >> LanSwitch

<< subkind >> Switched :<< compOf >>

compDevice : P << kind >> CompDevice

isDisjoint(First, Second, Third, Switched)

Thick isPartOf First ∧ #thick = 1

CompDevice isPartOf First

#compDevice ≥ 2

Thin isPartOf Second ∧ #thin = 1

CompDevice ispartOf Second

#compDevice ≥ 2

Hub isPartOf Third ∧ #hub = 1

CompDevice isPartOf Third

#compDevice ≥ 2

LANSwitch isPartOf Switched

#lanSwitch = 1

CompDevice isPartof Switched

#compDevice ≥ 2

Figure 7: LAN generations.

consists of one predicate stating that the three sub-

classes (WAN, MAN, and LAN) are not overlapping.

A formal speciﬁcation of (isDisjoint), is given in (Bet-

taz and Maouche, 2023a).

The piece of OntoObject-Z speciﬁcation de-

picted in Figure 7 deﬁnes an OntoObject-Z

class (<<subkind>> (First, Second, Third,

Switched)) regrouping three “children” of

(<<Kind>> LAN) implementing, respectively,

the four OntoUML classes (<<SubKind>> First

Generation), (<<SubKind>> Second Genera-

tion), (<<SubKind>> Third Generation), and

(<<SubKind>> Switched). The declaration part

of this piece of speciﬁcation deﬁnes the attributes

SIMULTECH 2024 - 14th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

412

for each “child” as follows. The declaration of each

reference attribute (stereotype, name, and type) is

indexed by the name of the “child” (stereotype,

name). For sake of readability the declaration of the

attributes are regrouped by “child”. For instance,

the “child” (<<subkind>> Switched) has two

attributes:

i) a ﬁrst attribute (thick) with stereotype

(<<CompOf>>) and type (P<< relator >>Thick).

The index is (<<subkind>> First).

ii) a second attribute (compDevice) with stereotype

(<<CompOf>>) and type (P<<kind>> CompDe-

vice). The index is the same, i.e., (<<subkind>>

First). The predicate part of our piece of speciﬁcation

(Figure 7) states several constraints that might be

commented as follows. The meaning of the predicate

(isDisjoint(First, Second, Third, Switched)) states

that the set-theoretic models of the classes (First,

Second, Third, and Switched) as not overlapping.

(Thick isPartOf First), a notation for (isPartOf(Thick,

First)), expresses the fact that in the whole-part

relationship between the classes (ThickCable) and

(FirstGeneration), (ThickCable) is the part and

(FirstGeneration) is the whole. (#thick = 1) states that

a thick cable is a mandatory part for a ﬁrst generation

LAN.

The piece of speciﬁcation depicted in Figure 8 de-

ﬁnes an OntoObject-Z class (<<kind>> CompDe-

vice) implementing the OntoUML class (Computing

Device). The declaration part deﬁnes four reference

attributes that all are stereotyped as (<<compOf>>).

Each attribute is typed by the power-set of the cor-

responding whole (i.e., First, Second, Third, and

Switched). The predicate part can be commented as

follows. (First isWholeFor CompDevice) is an ex-

pression for (isWholeFor(First, CompDevice)) stating

that a ﬁrst generation LAN is a whole for each com-

puting device connected to it. (#ﬁrst = 0 ∨ #ﬁrst = 1)

states that a ﬁrst generation LAN is not mandatory

for a computing device that could be connected to it.

The predicate (∀f : ﬁrst • self ∈ f .compDevice) de-

ﬁnes the navigability of the association relating (First)

and (compDevice).

The piece of speciﬁcation depicted in Figure 9

deﬁnes an OntoObject-Z class (<<role>> Con-

necCompDevice) implementing the OntoUML class

(Connected Computing Device).

The declaration part deﬁnes four reference at-

tributes that all are stereotyped as (<<mediation>>).

Each attribute is typed by the power-set of the ref-

erenced class. The predicate part can be com-

mented as follows. (#twisted = 1) means that a

twisted pair is mandatory for a computing device con-

nected to a LAN. The predicate (∀t : twisted • self ∈

<< kind >> CompDevice

<< compOf >> ﬁrst : P First

<< compOf >> second : P Second

<< compOf >> third : P Third

<< compOf >> switched : P Switched

First isWholeFor CompDevice

#ﬁrst = 0 ∨ #ﬁrst = 1

∀f : ﬁrst • self ∈ f .compDevice

Second isWholeFor ComDevice

#second = 0 ∨ #second = 1

∀s : second • self ∈ s.compDevice

Third isWholeFor CompDevice

#third = 0 ∨ #third = 1

∀t : third • self ∈ t.compDevice

Switched isWholeFor CompDevice

#switched = 0 ∨ #switched = 1

∀s : switched • self ∈ s.compDevice

Figure 8: Computing device.

<< role >> ConnecCompDevice

ComputingDevice :<< kind >>

<< mediation >> twisted : P Twisted

<< mediation >> thick : P Thick

<< mediation >> thin : P Thin

<< mediation >> hub : P Hub

<< mediation >> lanSwitch : P LANSwitch

#twisted = 1

∀t : twisted • self ∈ t.connecCompDevice

#thick = 1

∀t : thick • self ∈ t.connectCompDevice

#thin = 1

∀t : thin • self ∈ t.connectCompDevice

#hub = 1

∀h : hub • self ∈ h.connectCompDevice

#lanSwitch = 1

∀l : lanSwitch • self ∈ l.connectCompDevice

Figure 9: Connected computing device.

<< category >> Switch

<< kind >> NetSwitch, << relator >> LANSwitch

<< category >> Switch

Figure 10: Category of switches.

t.connecCompDevice) deﬁnes the navigability of the

association relating a connected computing device to

Implementing OntoUML Models with OntoObject-Z Speciﬁcations: A Proof of Concept Relying on a Partial Ontology for VLANs

413

a twisted pair.

The piece of speciﬁcation depicted in Figure 10

deﬁnes two OntoObject-Z classes (<<kind>>

NetSwitch) and (<<relator>> LANSwitch) imple-

menting the OntoUML abstract class (Switch).

8 CONCLUSIONS

The ﬁrst result of this contribution consists in deﬁning

a metamodel for OntoObject-Z and formalizing the

syntax of the speciﬁcations written in this language.

This paves the way for a “sound” formalization of this

promising language.

Building an ontology for VLANs and describing

it in OntoUML is a second result of this work.

The third result is the implementation of our

OntoUML models with OntoObject-Z speciﬁcations.

The motivation behind the idea of implementing On-

toUML models with OntoObject-Z speciﬁcations is

given in Section 1 and Section 3. It is important to

emphasize here that the approach used to build the

metamodel and to write the EBNF rules makes it pos-

sible to achieve an implementation that is correct by

construction.

Providing formal semantics for the implementa-

tion of OntoUML models with OntoObject-Z speciﬁ-

cations can be approached in two ways. Using an On-

toUML metamodel expressed in OntoUML and writ-

ing the rules mapping this metamodel into the On-

toUML metamodel of Object-Z, or providing both

OntoUML and OntoObject-Z with metamodels ex-

pressed in OntoObject-Z and writing the rules for

mapping the ﬁrst metamodel into the second one.

This task is left for future work.

Another more elaborated future work is to provide

OntoUML and OntoObject-Z with appropriate insti-

tutions (Diaconescu, 2023), (Baumeister et al., 2015)

formalizing both the syntax and the semantics of the

two languages and implementing OntoUML models

with OntoObject-Z speciﬁcations through the map-

ping of one institution into the other.

ACKNOWLEDGEMENTS

The author thanks four anonymous reviewers for their

valuable comments that helped improve the ﬁnal ver-

sion of this article.

REFERENCES

Assar, S. (2014). Model Driven Requirements Engineering:

Mapping the Field and Beyond. In 4th International

Model-Driven Requirements Engineering Workshop

(MoDRE), Karlskrona, Sweden. IEEE.

Aßmann, U., Zschaler, S., and Wagner, G. (2006). Ontolo-

gies, Meta-models, and the Model-Driven Paradigm.

Springer Berlin Heidelberg, Berlin, Heidelberg.

Baumeister, H., Bettaz, M., Maouche, M., and

Mosteghanemi, M. (2015). An Institution for

Object-Z with Inheritance and Polymorphism. In

LNCS 8950 (2015). Springer.

Bettaz, M. (2024). Towards an OntoObject-Z Based Ontol-

ogy for Virtual Local Area Networks, Keynote Speech

- Amity Institute of Information Technology.

Bettaz, M. and Maouche, M. (2017). UML/OCL or Object-

Z? In 2017 International Conference on Infocom

Technologies and Unmanned Systems (ICTUS’2017).

IEEE.

Bettaz, M. and Maouche, M. (2023a). Towards a New

Ontology-Based Descriptive Language: OntoObject-

Z. In 2023 6th International Conference on Contem-

porary Computing and Informatics (IC3I). IEEE.

Bettaz, M. and Maouche, M. (2023b). Towards an Ontol-

ogy for Network Management: Analysis and Reﬁne-

ment. In 2023 10th IEEE International Conference

on Electrical, Electronics and Computer Engineering

(UPCON). IEEE.

Comer, D. (2015). Computer Networks and Internets. Pear-

son, Edinburgh Gate, 6th edition.

Diaconescu, R. (2023). Preservation in Many-valued Truth

Institutions. Fuzzy Sets and Systems, 456:38–71.

Guizzardi, G. (2005). Ontological Foundations for Struc-

tural Conceptual Models,. Phd thesis, University of

Twente, The Netherlands.

Guizzardi, G., Benevides, A., Fonseca, C., Porello, D.,

Paulo, J., Almeida, A., and Sales, T. (2021). UFO:

Uniﬁed Foundational Ontology. In Applied Ontology

1 (2021). IOS PRESS.

Kim, S. and Carrington, D. (2000). A Formal Mapping Be-

tween UML Models and Object-Z Speciﬁcations. In

LNCS 1878 (2000). Springer-Verlag.

Odom, W. (2016). CCENT/CCNA ICND1 100-105 Ofﬁcial

Certiﬁcation Guide, Academic Edition. Cisco Press,

Indianapolis, 2nd edition.

Pergl, R. (2023). Lectures on Conceptual Modelling, Fac-

ulty of Information Technology - Czech Technical

University in Prague.

Roggenbach, M., Cerone, A., Schlingloff, B.-H., Schneider,

G., and Shaikh, S. A. (2022). Formal Methods for

Software Engineering. Springer Cham.

Seifert, R. and Edwards, J. (2008). The All-New Switch

Book. Wiley, Indianapolis, 2nd edition.

Smith, G. (2000). The Object-Z Speciﬁcation Language.

Springer.

SIMULTECH 2024 - 14th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

414