Insert here your thesis task.

Czech Technical University in Prague

Faculty of Information Technology
Department of Software Engineering
Bachelors thesis
Applying OntoUML for structural
denitions of Normalized Systems
Expanders
Vincenc Kolark
Supervisor: Ing. Robert Pergl, Ph.D.
13th May 2014
Acknowledgements
Greatest thanks go to Ing. Robert Pergl, Ph.D. for introducing me to these
interesting topics, as well as his encouraging consultations and inspirational
guidance. Another great deal of gratitude belongs to ir. Paul Adriaenssens
for prompt responses to my ddly questions about NSE and for the time spent
performing my case study, even on Sunday nights. Thanks to my family and
my friends, for staying my family and my friends. And nally, thanks to my
cat Sarah, for keeping me company during sleepless nights.
Declaration
I hereby declare that the presented thesis is my own work and that I have
cited all sources of information in accordance with the Guideline for adhering
to ethical principles when elaborating an academic nal thesis.
I acknowledge that my thesis is subject to the rights and obligations stip-
ulated by the Act No. 121/2000 Coll., the Copyright Act, as amended, in
particular that the Czech Technical University in Prague has the right to con-
clude a license agreement on the utilization of this thesis as school work under
the provisions of Article 60(1) of the Act.
In Prague on 13th May 2014 . . . . . . . . . . . . . . . . . . . . .
Czech Technical University in Prague
Faculty of Information Technology
c 2014 Vincenc Kolark. All rights reserved.
This thesis is school work as dened by Copyright Act of the Czech Republic.
It has been submitted at Czech Technical University in Prague, Faculty of
Information Technology. The thesis is protected by the Copyright Act and its
usage without authors permission is prohibited (with exceptions dened by the
Copyright Act).
Citation of this thesis
Kolark, Vincenc. Applying OntoUML for structural denitions of Normalized
Systems Expanders. Bachelors thesis. Czech Technical University in Prague,
Faculty of Information Technology, 2014.
Abstrakt
Prace se zab yva moznostmi vyuzit OntoUML pro strukturaln denice Ex-
panderu Normalizovan ych systemu. Analyzuje v yrazove schopnosti obou kon-
ceptu a porovnava je. Jejm klcov ym prnosem je navrh metody pro transfor-
maci OntoUML modelu do souboru pro popis datov ych elementu Expanderu
Normalizovan ych sytemu. Implementacn cast prace je prototyp nastroje re-
alizujc tento prevod. Navrzena metoda a vytvoren y nastroj jsou predvedeny
na prpadove studii.
Klcova slova Expander Nomalizovan ych systemu, generovan kodu, in-
formacn system, Normalizovane systemy, OLED, ontologick y model, On-
toUML
ix
Abstract
Thesis is engaged in possibilities of utilizing OntoUML for structural deni-
tion of Normalized Systems Expanders. It analyses the expressive capabilities
of both concepts and compares them with each other. A key contribution
of this work is to design a method for transformation OntoUML model into
the element descriptor les of Normalized Systems Expanders. Work includes
a prototype tool implementing this transformation. The designed method and
tool functionality are also demonstrated in a case study.
Keywords code generation, information system, Normalized Systems, Nor-
malized Systems Exapnder, OLED, ontologic model, OntoUML
x
Contents
Introduction 1
1 Goals and Approach 3
1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Thesis Structure and Tasks . . . . . . . . . . . . . . . . . . . . 4
2 Theoretical Background 7
2.1 Unied Foundation Ontology . . . . . . . . . . . . . . . . . . . 7
2.2 OntoUML Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Normalized Systems Theory . . . . . . . . . . . . . . . . . . . . 13
2.4 Overview of Utilized Software Technologies . . . . . . . . . . . 17
3 Analysis and Design 19
3.1 Comparison of OntoUML and NSE Concepts . . . . . . . . . . 19
3.2 Input and Output Files Analysis . . . . . . . . . . . . . . . . . 21
3.3 Conversion of OntoUML to NSE . . . . . . . . . . . . . . . . . 25
3.4 Summary of the Proposed Method . . . . . . . . . . . . . . . . 30
4 Prototype Implementation 33
4.1 Basic Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Internal Structure . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Conguration File . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Formal Grammars of Generated Files . . . . . . . . . . . . . . . 36
4.5 Application Usage . . . . . . . . . . . . . . . . . . . . . . . . . 39
5 Case Study 41
5.1 Case Study Description . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Execution Environment . . . . . . . . . . . . . . . . . . . . . . 41
5.3 Processing Case Study . . . . . . . . . . . . . . . . . . . . . . . 41
xi
Conclusion 43
Evaluation of Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Thoughts on Method Utilisation . . . . . . . . . . . . . . . . . . . . 43
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Bibliography 45
A Acronyms 49
B OntoUmlDistiller User Guide 51
B.1 Model Design Guidelines . . . . . . . . . . . . . . . . . . . . . . 51
B.2 Conguration File . . . . . . . . . . . . . . . . . . . . . . . . . 52
B.3 Launching the Application . . . . . . . . . . . . . . . . . . . . . 53
C Case Study Model Diagrams 55
C.1 Component Music . . . . . . . . . . . . . . . . . . . . . . . . . 56
C.2 Component Object . . . . . . . . . . . . . . . . . . . . . . . . . 57
C.3 Component Organization . . . . . . . . . . . . . . . . . . . . . 58
C.4 Component Person . . . . . . . . . . . . . . . . . . . . . . . . . 59
D NSE Descriptor File Examples 61
D.1 Application Descriptor . . . . . . . . . . . . . . . . . . . . . . . 61
D.2 Component Descriptor . . . . . . . . . . . . . . . . . . . . . . . 61
D.3 Data Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
E Contents of enclosed CD 63
xii
List of Figures
2.1 Typology of Substantials . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Combinatorial eects explained [1] . . . . . . . . . . . . . . . . . . 14
3.1 Ambiguous relationship in conceptual model . . . . . . . . . . . . 25
3.2 Examples of relationship interpretation . . . . . . . . . . . . . . . 25
3.3 Possible implementations of generalization set . . . . . . . . . . . . 30
4.1 Direct descendants of DataModelEntity class . . . . . . . . . . . . 34
4.2 Hierarchy of element classes . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Hierarchy of relationship classes . . . . . . . . . . . . . . . . . . . . 35
C.1 Component Music OntoUML diagram . . . . . . . . . . . . . . . . 56
C.2 Component Music ER diagram after expansion . . . . . . . . . . . 56
C.3 Component Object OntoUML diagram . . . . . . . . . . . . . . . . 57
C.4 Component Object ER diagram after expansion . . . . . . . . . . . 57
C.5 Component Organization OntoUML diagram . . . . . . . . . . . . 58
C.6 Component Organization ER diagram after expansion . . . . . . . 58
C.7 Component Person OntoUML diagram . . . . . . . . . . . . . . . . 59
C.8 Component Person ER diagram after expansion . . . . . . . . . . . 59
xiii
List of Tables
2.1 Cardinalities in OntoUML . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Conversion of many-to-many associations . . . . . . . . . . . . . . 27
3.2 Conversion of one-to-many associations . . . . . . . . . . . . . . . 27
3.3 Conversion of one-to-one associations . . . . . . . . . . . . . . . . . 28
xv
Introduction
Information systems have overcome a major milestone in their development.
Software engineers conquered the problem of creating new information system
(IS) in all its extent. Sophisticated software development methodologies and
modular programming paradigms allow to design, implement and deploy IS
of unprecedented size. With the increasing systems complexity and ageing,
new batch of issues arise.
Since the beginning of implementation IT to business, companies become
more and more dependent on information and communication technology
(ICT) infrastructure. With insignicant eort, IS serves the company as a re-
liable workhorse. When there is no need to change, the current system runs
smooth. But the company needs to adapt to the ever changing market and
the system requires modication to suit new functionality. Using current soft-
ware development methodologies, every change in the IS increases its overall
complexity. That leads to increasing costs for every subsequent change, there-
fore economic gain provided by the system decreases. Such problem cannot
be solved by current approaches, resulting in a demand for new principles.
Problem of increasing software complexity is theoretically solved by the Nor-
malized Systems (NS). This theory addresses issues related to software evolv-
ability and denes laws to maintain complexity unchanged during system in-
novation. It outlines a solution by re-creating the entire software develop-
ment life-cycle (SDLC), from prescribing mandatory software design patterns
to re-dening responsibilities of participants, extending to business processes
automation and modelling. NS is currently being developed at the University
of Antwerp. Its theoretical foundations are based on formal proofs as well as
statistical data.
Normalized Systems is primarily IT oriented and does not specify how
to describe the problem domain for which is the IS built. Unied Modelling
Language (UML) is a common graphical language used for this purpose, how-
ever in its pure form is intended for depicting code hierarchy, not real-world
entities and relations. To suit ontological needs, Dr. Giancarlo Guizzardi cre-
1
Introduction
ated UML prole for ontological modelling (OntoUML). Its strong expression
power and solid theoretical background makes it a potent tool for ontological
modelling.
This work aims to broach the ambitious task to connect these two theories
and thus make a contribution to next generation of software development.
2
Chapter 1
Goals and Approach
1.1 Goals
In accordance to thesis assignment the following goals were set:
Design a theoretical method transforming OntoUML diagrams (in extent
of UFO-A) to NSE element descriptors.
Create a prototype tool implementing designed method.
Demonstrate method and tool functionality on OntoUML domain model.
1.2 Approach
1.2.1 General Rules
In an eort to make this work conceptually coherent, there were dened es-
sential principles with which this thesis is created:
Energy will be devoted to be theoretically correct, complete and com-
pliant with both instruments.
The method has been designed without direct access to NSE, so the user
experience cannot be simulated. Therefore its considered as secondary
aspect.
Flexibility will be the major requirement for both theoretical and prac-
tical parts.
Implemented prototyped should serve as proof of concept, not a produc-
tion grade tool.
Theoretical method as well as prototype tool will presume working with
valid data models and will posses minimal or none validation mecha-
nisms.
3
1. Goals and Approach
Transformation method will endeavour to avoid any changes in design
of the model. So the model, created without any intention of using this
tool, can be transformed as-is or with minimal modications. Model
design guidelines will be created to cover those inevitable design rules
(e.g. using only data types supported by the NSE).
1.2.2 Relation to the Development Versions
Since both, OntoUML and NSE are quite new technologies and are developed
at a rapid pace, it was necessary to settle down to particular versions.
For the ontological part, Giancarlo Guizzardis PhD thesis [2] was chosen,
as it is the most comprehensive work about this topic. It exhaustively denes
UFO module for structural aspects (UFO-A) with UML prole for ontological
modelling (OntoUML). The graphic notation has been signicantly extended
for other Unied Foundation Ontology (UFO) varieties [3], but the core was
not changed.
Normalized Systems Expander are xed to version 2.3. It is the most
current stable release and has the most documentation available. Some new
features and changes of the next version are already known. They are taken
into account, but do not directly aect any of the set goals.
1.3 Thesis Structure and Tasks
To reasonably cover topic of this thesis, following tasks were set. The nal
structure of this work is derived from this task list.
1. Provide an overview of utilized theories and technologies (Chapter 2)
Introduce key concepts of Normalized Systems and Unied Foun-
dation Ontology
Describe essentials features of Normalized Systems Expander and
UML prole for ontological modelling (OntoUML)
2. Analyze OntoUML and Normalized Systems Expander (NSE) (Chap-
ter 3)
Explore expressive power of both instruments
Compare instruments with each other
Theoretically design a transformation method from OntoUML di-
agram to NSE element descriptors
3. Create a prototype tool for converting OntoUML diagram to NSE tem-
plate (Chapter 4)
Parse OntoUML models created in one of OntoUML designers
4
1.3. Thesis Structure and Tasks
Generate syntactically correct code according to NSE specications
4. Prove the method design on a case study (Chapter 5)
Demonstrate tools functionality on example domain model
Comment dierences between theoretical and implemented method
5. Summarize successes and failures (Chapter Conclusion)
5
Chapter 2
Theoretical Background
2.1 Unied Foundation Ontology
2.1.1 Brief Introduction to Ontologies
Ontology (in the computer-related meaning) is an instrument to formally de-
scribe the structure of a system. By observing the given real-world system,
an ontology engineer extracts its key characteristics relevant to desired pur-
poses. Characteristics are transformed into structure of entities and relations.
The foundation of an ontology consists of a generalization/specialization hi-
erarchy of entities, so called taxonomy [4].
Some ontologies were developed just for narrow scope of use (e.g. Gene
ontology for representation of gene and gene product attributes across all
species [5]). On the other side are ontologies able to describe very general
concepts shared across all domains. Those are called top-level ontologies (also
known as upper ontologies or foundation ontologies). The Unied Foundation
Ontology (UFO) is a representative of top-level ontologies.
2.1.2 UFO and OntoUML Synopsis
The Unied Foundation Ontology (UFO) is developed by Giancarlo Guiz-
zardi and associates from Ontology and Conceptual Modelling Research Group
(NEMO). Authors also collaborate with Laboratory for Applied Ontology
(LOA) and Gerd Wagner from the Brandenburg University of Technology.
UFO assimilates and discusses knowledge from many related concepts:
General Formal Ontology (GFO), Descriptive Ontology for Linguistic and
Cognitive Engineering (DOLCE) and OntoClean [2].
The UFO module for structural aspects (UFO-A) have been formalized and
dened in Giancarlo Guizzardis Ph.D. thesis [2]. It features conceptual mod-
elling constructs for structural denitions. Since it is in primary focus of this
thesis, it will be closely presented in section 2.2. Unied Foundation Ontol-
ogy has been already extended to incorporate an extension for event-related
7
2. Theoretical Background
concepts (UFO-B) and for social and intentional aspects (UFO-C). Currently
is being developed an extension for service-related concepts (UFO-S) [3].
The Unied Modelling Language (UML) is used for graphical representa-
tion of UFO. Its prole mechanism [6] allows to extend the UML metamodel
for various purposes. The prole created for ontological modelling (OntoUML)
is originally dened in [2]. It was later rened in [7] while creating a OntoUML
computer modelling infrastructure.
2.2 OntoUML Overview
This section provides very simplied overview of OntoUML notation, within
extend of UFO-A. Its purpose is to extract key concepts necessary for under-
standing further analysis.
All information is based on various Guizzardis publications, especially [2,
8, 9, 10].
The text consider UML as fully assimilated base of OntoUML. Concepts
from bare UML are explained alongside those from OntoUML prole without
explicit dierentiations.
2.2.1 Classes and Entities
Class describes the common features (e.g. intrinsic and relational properties)
shared by entities. Individual entity is instance of appropriate class. These
terms common in conceptual modelling are equivalent to universal (class) and
individual (instance) used in UFO terminology.
Attribute of a class represent property shared by members of a class. All
instances must contain values for each attribute that is dened for that class,
in accordance with the characteristics of the attribute (e.g. data type and
multiplicity).
Each class can be assigned to an object type depending on its ontologi-
cal characteristics. This categorization is described in greater detail further
in sections 2.2.4 and 2.2.5.
2.2.2 Specializations
Specialization relation is used to organize classes into a taxonomic structure.
All properties of a class are inherited by its subclasses through a specialization
chain.
The specialization relation is anti-symmetric (if A specializes B then B
cannot specialize A) and transitive (if A specializes B and B specializes C,
then A specializes C).
8
2.2. OntoUML Overview
2.2.2.1 Specialization Sets
Specializations directing to one common superclass can be grouped into a gen-
eralization set. Such set can provide stronger semantics, because it can bear
two meta-attributes: disjoint and complete.
If a generalization set is disjoint if all the subclasses participating
in the generalization are mutually exclusive. [2]
In other words: All instances of superclass can be instances of maximum of one
subclass.
If a generalization set is complete then the subclasses exhaust
the instances of the common direct superclass. [2]
In other words: Every instance of superclass also have to be an instance of one
of the subclasses participating in the generalization (or it cannot exist).
If a generalization set is disjoint and complete then the sub-
classes participating in this generalization set form a partition. [2]
In other words: Every instance of the common superclass is an instance of ex-
actly one of the subclasses. This fact also implies that the common superclass
is an abstract class.
2.2.3 Associations
An association indicates possible links between instances of respective classes.
Every link has two ends. Every end has specied how many instances of its
class can hold (cardinality). For possible cardinality notations see 2.1.
Type-reexive associations are associations with both ends connected to the same
type.
Multiplicity Alt. Notation Cardinality
0..0 0 Empty collection
0..1 No instances or one instance
1..1 1 Exactly one instance
0..* * Zero or more instances
1..* At least one instance
4..4 4 Exactly 4 instances
m..n At least m but no more than n instances
Table 2.1: Cardinalities in OntoUML
Every end can bear several meta-attributes, that are interesting form
the implementation point of view:
9
2. Theoretical Background
derived value can be computed from other information
ordered elements are sequentially ordered
unique each value in the collection must be unique
read only once the instance is assigned, it cannot be changed
2.2.4 Substantials
Substantials are entities that persist in time while keeping their identity (as
opposed to events). It is similar to term object intuitively used in colloquial
speech [2]. President, stone, river or Vincent van Gogh are possible examples.
{disjoint, complete}
Substantial Universal
Subkind Quantity
Anti-Rigid Sortal
Mixin RoleMixin
{disjoint, complete}
{disjoint}
Category
{disjoint}
{disjoint, complete}
Phase Role
{disjoint, complete}
Kind Collective
Anti-Rigid Mixin
Non-Rigid Mixin Rigid Mixin Rigid Sortal
{disjoint}
Sortal Universal Mixin Universal
Substantial Universal
Figure 2.1: Typology of Substantials
2.2.4.1 Sortal vs. Mixin Types
At the top level (see g. 2.1), types are categorized according to whether they
are endowed with object identity. The object identity enables to distinguish if
two class instances are identical.
Objects endowed with identity are called Sortal types. The object types
Person, Chair or Teacher are examples of Sortal types. All subtypes of Sortal
inherit its identity via specialization chain.
Other types, that are not Sortal, are called Mixin types. Good example
of Mixin types is RedObject when two red objects are perceived at dierent
time, it is not possible to distinguish whether those two objects are identical
or not. Another examples may be SeatableItem or InsurableItem.
There are two postulates about Mixin types [8]:
10
2.2. OntoUML Overview
A Mixin type cannot have direct instances. This means that a Mixin
type M must have Sortal subtypes, which are directly instantiated by
the instances of M.
A Mixin type cannot be a subtype of a Sortal type. This is a consequence
of the fact that all subtypes of a Sortal type are again Sortal types since
they inherit its object identity condition.
2.2.4.2 Sortal Types
The meta-property rigidity is used to distinguish dierent categories of Sortals.
Rigidity: A type T is rigid if for every instance x of T, x is
necessarily (in the modal sense) an instance of T. In other words,
if x instantiates T in a given world w, then x must instantiate T
in every world w. [2]
Anti-Rigidity: A type T is anti-rigid if for every instance x of T,
x is possibly (in the modal sense) not an instance of T. In other
words, if x instantiates T in a given world w, then there is a possible
world w in which x does not instantiate T. [2]
2.2.4.3 Rigid Sortal Types
A Rigid Sortal can be a Substance Sortal or a SubKind.
Substance Sortals:
Kind is the only type that can provide an identity principle to its in-
stances (e.g. Person, Sand or Forest).
Quantity is a nominalization of amount of matter (e.g. water, sand,
sugar).
Collective is representation of collection in general (e.g. forest, deck
of cards, pile of bricks or pack of wolves).
Substance Sortals can be specialized SubKinds (e.g. Woman and Man are
specializations of Kind Person and inherit its identity principle).
2.2.4.4 Anti-Rigid Sortal Types
Anti-Rigid Sortal can be specialized to a Phase or a Role.
Phase constitutes possible stages in the history of a Substance Sortal
(e.g. Alive and Deceased are possible stages of a Person, Town and
Metropolis development stadiums of a City). Phases imply disjoint and
complete meta-attributes to their specialization set.
11
2. Theoretical Background
Role depends on extrinsic (relational) properties of specialized Substance
Sortal. As intuitively perceived, an entity plays its role in specic con-
text dened by interacting entities (e.g. Person is a Student in relation
to some School and the same person could be a Customer in relation
to some Shop).
2.2.4.5 Mixin Types
Mixin Universal can be specialized to a Category, a RoleMixin or a Mixin.
Mixins are always dened as an abstract class.
Category is mixin of Rigid types (e.g. Category LivingCreature may
generalize Kind Person and Kind Cat).
RoleMixin is Mixin of Roles (e.g. RoleMixin Customer, generalizing
the Role PersonalCustomer (which specializes a Person) and the Role
CorporateCustomer (which specializes an Organization)).
Mixin bear a meta-property is called non-rigidity (that is weaker con-
straint than anti-rigidity). It allows to group rigid and non-rigid types
to one entity (e.g. Mixin Seatable generalize Kind Chair and IceThrone
which is a Phase of Water).
2.2.5 Moments
Moments are entities that they can only exist in other individuals they are
existentially dependent on their bearers. For example, electrical charge can
exist only in some conductor.
Moments can be divided into Intrinsic Moments and Relational Moments.
2.2.5.1 Intrinsic Moments
Quality is a single- or multi-dimensional representation of a measurable
property (e.g. weight, RGB color)
Mode is a representation of a non-measurable property, often used to de-
ne state of a entity (e.g. issue of a book, translation of a document)
2.2.5.2 Relational Moments
Relational moment, called Relator is a artefact attached to material relation-
ship (e.g. a covalent bond, purchase order, business contract or ight between
two airports).
Relators are connected to both end entities of the material relationship
(via mediation) and to the material relationship itself (via derivation).
12
2.3. Normalized Systems Theory
2.2.6 Parts and Wholes
The theory of parts and wholes is considered as a signicant part of the foun-
dational ontology. To maintain brevity of this section, this topic is consid-
erably simplied. There exist many implications among parthood relations
and related meta-attributes, that are dened in UFO. Focus of this work is
to deal with only eect of these implications, so the implications itself are not
mentioned.
UFO denes multiple parthood relations forming dierent types of aggre-
gates:
SubQuantityOf for Quantities (e.g. alcohol wine)
MemberOf for Collectives (e.g. aSpecicTree theBlackForest)
SubCollectiveOf for Collectives (e.g. theNorthPartOfTheBlackForest
theBlackForest)
ComponentOf for Functional Entities (e.g. heart circulatorySystem)
Nuances among the part-whole relationship can be hardly utilized, there-
fore are not further explained. More interesting are again the meronymic
meta-attributes present at the relationship:
essential part cannot be changed without aecting the identity of the whole
(e.g. human after brain transplant would not be considered the same
human before the transplant)
inseparable part is existentially dependent on its whole (e.g. human
brain cannot be separated from the body without losing its essence)
immutable part/whole is part/whole with de-dicto necessity (e.g. boxer
necessarily has at least one hand to be a boxer, therefore hand is im-
mutable part)
shareable entity can be part of several wholes (e.g. one person can be
member in several families; versus one engine can be part of only single
car at time)
2.3 Normalized Systems Theory
Normalized Systems (NS) is a theoretical framework applicable to design and
engineer information system exhibiting proven evolvability. It aims at re-
creating information technology based on dened laws for software evolvability
in innite time.
The theory originates from University of Antwerp, the department Man-
agement Information Systems of the faculty Applied Economics. Later, the uni-
versity has established the Normalized Systems Institute for further research
13
2. Theoretical Background
on this theory. NS is based on previous research on software architectures
by Herwig Mannaert and research on evolvability of conceptual and design
models of information systems by Jan Verelst. [11]
NS currently covers and redenes whole software development process and
has extends even to business process modelling. Because it highly exceeds
scope of this thesis, following section will present only key features necessary
for this work, i.e. features related software development.
2.3.1 Essential Principles
Normalized Systems state that contemporary IT problems are manifestations
of fundamental aws in currently used methodologies. The greatest vulnera-
bility lies in the evolvability of the IS. Adding functionality to existing system
generates combinatorial eects, that lead to increase of system complexity (see
g. 2.2). Such eects cause increase of costs for future changes and decrease
overall software quality [12]. This idea was rst stated by Manny Lehman
in 1980:
As an evolving program is continually changed, its complexity,
reecting deteriorating structure, increases unless work is done
to maintain or reduce it. [13]
In spite of that, Normalized Systems try to realize vision uttered by Dou-
glas McIlroy in 1968:
Expect families of routines to be constructed on rational principles
so that families t together as building blocks. In short, [the user]
should be able safely to regard components as black boxes. [14]
NS assume the change of the system to be natural and unavoidable phe-
nomenon, therefore all principles and methodological elements are designed
Figure 2.2: Combinatorial eects explained [1]
14
2.3. Normalized Systems Theory
to respect that fact. The theory denes set of rules how to engineer the IS ar-
chitecture as structure of independent modules, which can be added, removed
or changed. Suciently granular architecture will eliminate any combinatorial
eects during modication of the system.
The normalized design theorems prescribe strict separation of data and ac-
tions manipulating such data. This segregation contradicts the essence of OO
programming, which beliefs that data and respective actions should be con-
solidated into one entity.
2.3.2 Rules of Evolvability
This section introduces four rules of software evolvability, that are the building
blocks of NS. A procient software developer will be familiar with these rules,
because they are based on heuristic design knowledge. Value added by NS
are theoretical proofs, that elevate these empirical experiences to defensible
theorems.
At the beginning, it is necessary to clarify several terms used in later
denitions:
A data entity refers to a software entity that contains various at-
tributes or elds, including links to other data entities. Therefore,
a data entity only contains data (as in a structure or record) and
does not have an interface. [1]
An action entity refers to a software entity that represents an op-
eration at a given modular level in a hierarchy. [1]
A task is part of an action entity and is a set of instructions that
performs a certain functionality. A task is located at the submod-
ular level. [1]
2.3.2.1 Separation of Concerns
An action entity can only contain a single task in normalized sys-
tems. [12]
This theorem implies identication and separation of every single task.
Correct separation of tasks will induce separation of concerns in the big pic-
ture.
This is a well known good practice among software architects, but it is also
very general in its formulation. Current manifestations in software develop-
ment include for example multi-tier architectures (MVC, MVVM, etc.) or use
of integration bus for inter-application communication.
15
2. Theoretical Background
2.3.2.2 Data Version Transparency
Data entities that are received as input or produced as output by
action entities, need to exhibit version transparency in normalized
systems. [12]
Version transparency is instrument to cope with addition or removal a data
eld in entity. It implies encapsulation of the data elds. Wrapping the data
entity allows co-existence of various versions of such entity.
This can be easily implemented by using get & set methods and 0-parameter
constructor in OO programming.
2.3.2.3 Action Version Transparency
Action entities need to exhibit version transparency in normalized
systems. [12]
Analogously to previous theorem, various versions of data entities need
to co-exist in single system.
This can be achieved by using wrapper functions/methods or polymor-
phism.
2.3.2.4 Separation of states
The calling of an action entity by another action entity needs to ex-
hibit state keeping in normalized systems. [12]
It is a formalization of instinctive avoiding the transition (undened) state.
When a state is kept for every call or instance of an action entity, the whole
system behaves as a deterministic state machine. This eliminates the need for
complicated recovery from undened error states.
An example of manifestation of this design theorem is database transac-
tion mechanism. The commit (rollback) action guarantees atomic transition
from one dened state to another. Another common example is asynchronous
communication between systems.
2.3.3 Impacts on Software Development
In order NS principles to be eective, the rules of evolvability must be strictly
obeyed. The system must be free of combinatorial eects at compile time,
deployment time and run time. This requires the code to be absolutely er-
ror free, which is not an easy task to achieve. The data and action version
transparency rules also imply a lot of ballast (non-logic) code (e.g. wrapper
classes, accessor methods). For a human programmer writing code complying
with NS is boring and frustrating.
16
2.4. Overview of Utilized Software Technologies
On the other hand, NS presents a set of software design patterns, that are
solution to these challenges. The design patterns (called elements) are de-
ned comprehensively enough, that are suitable for code generation. The core
of created is is composed only from following elements:
a data element for storing data
an action element for the execution of a calculation or algorithm
a workow element for the execution of sequences of action elements
a connector element for input and output functionality
a trigger element for time-based or status-based execution of action el-
ements
These patterns are proven to exhibit high cohesion and loose coupling,
therefore the generated application will be be free of combinatorial eects.
Element Composition Class inheritance may violate NS theorems, be-
cause of following reasons:
Where member variables lead to an implicit and to some extent
hidden coupling with data attributes, the mechanism of inheri-
tance introduces an implicit coupling with entire methods. Such
inherited methods become an integrated part of the class or object-
oriented module, and may introduce dependencies on severalpossibly
largeexternal libraries or frameworks. Invoking an inherited method
results in execution of apossibly largeset of instructions, having
access to a common set of member variables, and may result in a
possibly largeset of initializations and allocations. [12]
For the purposes of ontological renement, the principle of element com-
position is preferred. The the superelement is specialized by another element
with simple connection of other element, instead of any dependence between
each other.
2.4 Overview of Utilized Software Technologies
2.4.1 OLED
OntoUML Lightweight Editor (OLED) [15] is an open source editor developed
under the supervision of Ontology and Conceptual Modelling Research Group
(NEMO).
OLED was chosen for this work for several reasons. First, it has the richest
OntoUML and Object Constraint Language (OCL) editing capabilities among
17
2. Theoretical Background
other editors. Second, it uses the reference metamodel dened by Roberto Car-
rareto in [7]. It is based on Eclipse Modeling Framework metamodel (ECORE)
and is currently the most advanced OntoUML infrastructure [16]. This meta-
model can be exported to XML les (with .refontouml extension) and easily
manipulated.
OLED also features model syntax verication, anti-pattern management,
instances simulation via Alloy and model tranformation to OWL/SWRL and
SBVR.
The editor is still in development and its use is quite experimental. With
respect to production grade tools, OLED capable of importing models from
Sparx System Enterprise Architect (EA). Developers also provide OntoUML
prole for modelling directly in EA.
2.4.1.1 Using NSE
The software development life-cycle (SDLC) has been re-designed in the NS
and is applied to development using the expanders technology. Whole devel-
opment process puts emphasis on intensive communication between the de-
veloper and the responsible end user (stakeholder).
The main phases of the development are [17]:
1. Identify Data-elements The goal of this activity is to dene the data-
elements and the corresponding database model. This version should be
a direct result of the expansion of the descriptors without any customi-
sation. At this phase the application is minimally congured.
2. Implement Business-rules The goal is to guarantee the data-quality re-
quested by the end-user in the system.
3. Introduce user-friendliness Introduce the necessary user-friendliness. The
generated system gives the end-user the possibility to work with the ap-
plication. The application provided after the previous phase requires
from the end-user a good understanding of the system (both function-
ally as structurally).
Data model, as well as workow denitions, are provided by descriptor
les. Descriptor le is simple XML or plain text document dening single NS
element (see 2.3.3). The expanders generate skeleton source code from these
les, together with all deployment and conguration les required to construct
a working application on selected technology stack. [17]
Alongside creating the application from users input, NSE provides pre-
pared modules for common functionality used in IS (e.g. user accounts, input
elds validation).
18
Chapter 3
Analysis and Design
3.1 Comparison of OntoUML and NSE Concepts
This section provides and overview of OntoUML and NSE features from
the methodological point of view. Then are both concepts compared to each
other.
3.1.1 OntoUML
OntoUML provides means to depict conceptualization of a real-world domain.
Due to its ontological focus, it is implementation independent and conceptual
models does not bear any implementation details. Its crucial features were
summarized in section 2.2.
UFO-A provides information related only to structural denitions. Poten-
tial utilizing OntoUML for workow denition could be possible with UFO
module for event-related concepts (UFO-B). But investigation of this inter-
connection is out of scope this work.
3.1.2 Normalized System Expander
Normalized Systems Expander (NSE) is a technological framework realizing
NS elements expansion developed by NSE bvba, Belgium.
Although the theory of element expansion in platform independent, the NSE
is currently being developed for Java Enterprise Edition (JEE). Generated ap-
plications are able to use all major databases. The framework is able to run
on Linux, Windows and MacOS.
The generated application uses a web frontend, which is can be created
using Knockout or Cocoon & Struts2 frameworks. Supported deployment
application servers are JOnAS, TomEE and Websphere.
19
3. Analysis and Design
3.1.2.1 Customizations
The generated application may need some modications before deploying
in production. As the Normalized Systems theory assumes IS to be changed,
such change requires the whole source code to be regenerated. To preserve
code modications between regeneration of code, the harvesting mechanism
is introduced.
While editing the generated source les, the modied code is put between
special anchor marks. Before regenerating the application, the code embraced
by those anchors is saved to special harvest les. After the new source code
is generated, the harvested modications are injected back to its original lo-
cation.
Developer performing the customizations must be aware of the NS design
theorems, to avoid creating combinatorial eects by his intervention.
3.1.2.2 Descriptors
Normalized Systems Expander currently recognizes several types of descriptor
les, serving various purposes.
Data descriptor les of the Normalized Systems Expander describe pat-
terns dened by Normalized Systems, alongside with many implementation
details (e.g. database schema for persisting specic element, visualization
options, etc.)
The following types could be used for dening data model are analysed
in detail in section 3.2.2:
application descriptor (.ad) for denition of basic application skeleton
component descriptor (.cd) for declaring application component
data descriptor (.dd) for describing individual data elements
The list is not complete, other descriptor les are used to dene workow
(ow and task descriptor) or validating use input (value type descriptor).
3.1.2.3 Linking Mechanisms
NSE provides following linking mechanism:
many-to-one in two variants, diering in implementations. May be used
at single side bidirectional.
many-to-many only one variant. Also may be used as single side or bidi-
rectional.
Those links has always optional ends unable to achieve mandatory rela-
tionship.
20
3.2. Input and Output Files Analysis
3.1.2.4 Indirect Fields
Indirect eld is an instrument to visualise contents of one element inside an-
other. It is dened as a data eld in the data descriptor.
It is stated by the developers, that the Indirect eld mechanism will be
replaced in further versions of NSE with similar functionality. This is consid-
ered as implementation related. Since the functionality will be maintained,
the implementation syntax can be easily replaced with a new one.
3.1.3 Comparison
Combining OntoUML and Normalized Systems Expander is a clash of two ap-
proaches. The implementation oriented NSE are pragmatic and tends to be as
simple as possible. The conceptual oriented OntoUML stands on the opposite
side. It endeavours to be as descriptive as possible.
Instruments oered out-of-the-box by are not able to cover the whole ex-
pressive power of NSE. Much valuable information will be lost primarily in as-
sociation and part-whole relationship transformation (see 3.3.2).
On the other hand, OntoUML in the extent of UFO-A can cover only
the rst step of the NSE development process (see 2.4.1.1), since diagrams
in UFO-A only is capable of structural denitions.
Description of workows may be possible with OntoUML in extent of UFO-B.
But researching this issue is denitely out of scope of this work.
3.2 Input and Output Files Analysis
The following section describe OLED and NSE le formats.
3.2.1 RefOntoUML le format
As it is a XML standart format, it is not necessary to analyse the structure
verbosely. This section contains only noteworthy insights.
This le format contains all information about the whole model. Hence,
it does not contain any information about graphical representation of the di-
agrams.
Therefore graphical denition of generalization sets[2] cannot be derived
from this le format. The sets must be dened (also) as generalization set
data structure in the OLED, otherwise they will not be recognized.
3.2.2 NS Expander le formats
Descriptor les related to data model denitions were closely analysed for
the purposes of generation. Information provided is based on NSE user
guides [18, 17] and claried by communication with Paul Adriaenssens from
NSE bvba, Belgium.
21
3. Analysis and Design
Note that the analysis includes only those syntax constructs, that was
considered useful for further work.
3.2.2.1 Application Descriptor
<shortApplicationName> <fullApplicationName>
style=<style1>
(...)
style=<styleN>
component-<component1>
(...)
component-<componentN>
optionDataBaseSchema-<dbSchema1>
(...)
optionDataBaseSchema-<dbSchemaN>
<shortApplicationName> (testApp)
Short name of the application, which will correspond to the name of the ex-
panded directory tree in the expansions applications folder.
<fullApplicationName> (TestApplicatie)
Full name of the application.
style=<style>
Styles of the presentation layer that will be generated.
component-<component>
Enumeration of the dierent components that are used inside the application,
both base and user-dened.
optionDataBaseSchema-<componentName> <SCHEMANAME>
Optional database schema setting. <SCHEMANAME> is also optional in the line
itself; must be inserted in uppercase.
3.2.2.2 Component Descriptor
<componentName> <componentURL>
depends-<baseComponent1>
(...)
depends-<baseComponentN>
MTM-<targetComponent1>
(...)
MTM-<targetComponentN>
<componentName> (testComp)
Name of the component, which will correspond to the name of the expanded
directory tree in the expansions components folder. [18]
22
3.2. Input and Output Files Analysis
<componentURL> (testElement1-view)
Species the default URL that will be invoked when clicking on the compo-
nents menu in GUI. [18]
depends-<baseComponent> (depends-account)
Indicates a dependency on some other underlying component.
MTM-<targetComponent> (MTM-basisComp)
Indicates, that some elements from current component has many-to-many
relationship with some elements in <targetComponent>.
3.2.2.3 Data Element Descriptor
<componentName> <javaPackage> <elementName>
<dataType1> <dataAttributeName1> <b11><b21><b31>
(...)
<dataTypeN> <dataAttributeNameN> <b1N><b2N><b3N><enumListN>
Ln[0-6]<interComp>#<dataTypeO> <dataAttributeNameO> <b1O><b2O><b3O>
(...)
Ln[0-6]<interComp>#<dataTypeP> <dataAttributeNameP> <b1P><b2P><b3P>
findBy<attributeName1><findModifier1>_<attributeName1><findModifier1>
(...)
findBy<attributeNameN><findModifierN>_<attributeNameN><findModifierN>
optionIndirect<fieldName1>_<elementName1>
(...)
optionIndirect<fieldNameN>_<elementNameN>
<componentName> <javaPackage> <elementName>
(sitenet net.palver.uams Purchase)
Line dening data element name and location.
<componentName> (sitenet)
The name of elements component.
<javaPackage> (net.palver.uams)
Elements Java package name.
<elementName> (Purchase)
Name of the element.
<dataType> <dataAttributeName> <b1><b2><b3><enumList>
(productCode yny10 20 30 40 50)
Line dening a data attribute or eld.
<dataType> (String)
Name of used data type. Special NSE datatypes must be used [17] ofr all data
types. It also includes the Indirect for indirect elds mechanism.
23
3. Analysis and Design
<dataAttributeName>
Name of the attribute.
Ln[0-6]<interComp><entityName><b1><b2><b3>
(Ln01site.jar#net.palver.site.Site ynn)
Element link.
<interComp> (site.jar)
Optional Java package name, if the linked element is located in another com-
ponent.
<entityName> (net.palver.site.Site)
Full java name of the linked entity.
<b1>
Boolean value specifying attribute visibility in overview screen.
n: the attribute will be visible only in detail screen of data element
<b2>
Depracted in current version of NSE. Value will be neglected, but y ot n must
be present.
<b3><enumList>
Boolean value specifying whether attribute has enumerated values.
y: list of possible values follow; Values are separated by (underscore)
symbol.
findBy<attributeName><findModifier> <attributeName><findModifier>
(findByNameEq YearGt)
Species which nder (search) methods will be generated. Name has to have
prex ndBy followed by name of searched attribute and modier.
Modier can currently assume values:
Eq: equal to
Gt: greater than
Lt: less than
Multiargument search methods are possible by chaining several pairs (at-
tribute and modier) separated by (underscore) symbol.
optionIndirect<fieldName> <elementName>
(optionIndirectperson net.palver.person.Person)
<fieldName> (person)
Name of the Indirect data eld.
<elementName> (net.palver.person.Person)
Full Java name of the inserted element.
24
3.3. Conversion of OntoUML to NSE
3.3 Conversion of OntoUML to NSE
3.3.1 General Issues of Converting Conceptual Model
to Implementation
Conversion from conceptual to implementation models is not dened at all.
Therefore no existing methodology can be used as example. The success
of the conversion of the conceptual model of the implementation depends
entirely on the experience of implementer.
0..* 0..*
parks at ParkingPlace Car
Figure 3.1: Ambiguous relationship in conceptual model
Information necessary for implementation can be dierent from the infor-
mation provided by conceptual model. This can be illustrated with following
example: Figure 3.1 represents a relationship in a conceptual model: unspec-
ied number of cars park at unspecied number of parking places. The gure
3.2 shows possible implementations of this relationship: when creating a book
of rides for cars, it necessary to keep information where the car parked. But
when an IS for parking house is created, its necessary to know which cars
parked at the given place. In some cases, both records should be kept.
ParkingPlace Car
ParkingPlace Car
ParkingPlace Car
Figure 3.2: Examples of relationship interpretation
Transformation method in this thesis is designed to cover the majority
of possible cases. When a ambiguous situation appears, it is preferred to have
excess rather than lacking. If necessary, the generated code could be sim-
ply modied. And deleting line of code is easier operation than generating
a proper one.
25
3. Analysis and Design
3.3.2 Proposed Transformation of OntoUML Phenomena
This method is the key concept and contribution of this work. It covers
all OntoUML phenomena and proposes possible transformation principle(s)
of every phenomenon.
3.3.2.1 Substantials and Moments
All Substantials and Moments are converted to individual data descriptors.
There is nothing to discuss since NSE does not oer any other object-like
element.
Object inheritance (generalizaitonspecialization relationship) is covered
in section 3.3.3.2.
3.3.2.2 Associations
Associations are transformed to NSE link mechanism. Some special cases were
identied and are mentioned further.
As the OntoUML considers relationships to be mutual between entities,
its impossible to identify necessary linking directions. Therefore are all rela-
tionships realized as bidirectional.
Association are distinguished only by cardinalities, the conversion is de-
scribed in tables 3.3, 3.2, 3.1 and respective paragraphs.
The name of the OntoUML relationship is used as the name of NSE link
eld. This guarantees that naming collisions among the links will be avoided.
Because, by denition in [2], all model elements must have unique names.
By default, NSE links does not require any element to be connected. To ac-
complish mandatory connection end (mandatory element), code customization
is necessary. Implementer will by notied about these necessary customiza-
tions by comments in descriptor les.
In general, it is not recommended to enforce creating link at instantiation
of the element. This may cause unsolvable situations if this mechanism is used
on both sides. Safe solution is to verify presence of the connected element at
the moment of using the link.
many-to-many (Table 3.1) NSE provides many-to-many linking mecha-
nism. Conversion is straightforward, although it has some specic rules:
1. In case the many to many link is between two components, link to
the other component (e.g. MTM-targetComponent) must be mentioned
in component descriptor.
2. There is a eld name restriction at the Ln03 side:
26
3.3. Conversion of OntoUML to NSE
the name of the Ln03 eld needs to be identical to the name
of the element where the corresponding Ln06 link is specied fol-
lowed by the character s (e.g. Ln03be.provant.basis.Materie
materies nyn) [18]
one-to-many (Table 3.2) NSE provides two one-to-many/man-to-one link-
ing mechanisms out-of-the-box. From the users point of view, they act equally.
Bu they dier in implmentation:
1. Ln02-Ln04 pair is container managed relationship. Because of this, it is
not able to connect entities from dierent components.
2. Ln01-Ln05 pair is managed by NSE itself. Therefore, it is able to make
inter-component links and is generally more versatile. This pair was
chosen to be implemented.
one-to-one (Table 3.3) Two possible conversions were designed, both with
pros and cons:
1. (column NS Expander) Using two ends of many-to-one mechanism.
When used used separately, the link is able to connect to only one ele-
ment. This approach guarantee connection to single element on both
OntoUML NS Expander
end A end B end A end B
0..* 0..* Ln06 Ln03
s
1..* 0..* Ln06
p
Ln03
s
1..* 1..* Ln06
p
Ln03
p, s
p
mandatory element
s
restricted eld name
Table 3.1: Conversion of many-to-many associations
OntoUML NS Expander alternative
end A end B end A end B end A end B
0..1 0..* Ln01 Ln05 Ln02 Ln04
1..1 0..* Ln01
p
Ln05 Ln02
p
Ln04
0..1 1..* Ln01 Ln05
p
Ln02 Ln04
p
1..1 1..* Ln01
p
Ln05
p
Ln02
p
Ln04
p
p
mandatory element
Table 3.2: Conversion of one-to-many associations
27
3. Analysis and Design
OntoUML NS Expander alternative
end A end B end A end B end A end B
0..1 0..1 Ln01 Ln01 Ln01 Ln05
o
1..1 0..1 Ln01
p
Ln01 Ln01
p
Ln05
o
1..1 1..1 Ln01
p
Ln01
p
Ln01
p
Ln05
p, o
p
mandatory element
o
maximum of one element
Table 3.3: Conversion of one-to-one associations
sides. Nevertheless customization on both sides would be necessary
to enforce mutual linking. Although, this approach is considered most
elegant and will be implemented.
2. (column alternative) May be used when mutual linking (managed by
NSE) is preferred. This uses many-to-one relationship, where mutuality
is assured by NSE. Customization is necessary on single side (maximum
of one element), to allow maximum of one element.
Metaatribudes of association ends:
derived is considered as irrelevant to implementation.
ordered, unique, read only could not be utilized by any means provided
by NSE framework. To utilize this metadata, customization of the gen-
erated code must be performed. Implementer may be notied about
presence of this metadata by comments in descriptors.
3.3.2.3 Part-whole Relationships
Since there is no other suitable linking mechanism available, the part-whole
relationships are considered as plain associations and transformed in same
manner decribed in 3.3.2.2.
Meronymic metaatributes essential, inseparable, immutable, shareable could
not be utilized by any means provided by NSE framework.
3.3.2.4 Data Attribute Fields
Single value data attributes eld are simply transcribed to the syntax of data
descriptors.
Multiple values attribute elds are, in common programming languages,
solved by a containing data structure (e.g. an array). Since theres no such
thing in NSE, the proposed solutions is to create a separate data descriptor
containing a single value data attribute and link the via one-to-may links.
As the multiple values attribute is equal
28
3.3. Conversion of OntoUML to NSE
3.3.3 Abstract Class
Instantiation of abstract elements must be forbidden by customisation of the ex-
panded code, not by any mean provided by the NSE.
3.3.3.1 Qualities
Qualities are, because of its dependence on the bearer, transformed in dierent
mode.
In case the quality is connected by one-to-one relationship, the instance
can be accessible directly using the indirect elds mechanism. Otherwise its
linked by one-to-many mechanism described in section 3.3.2.2.
3.3.3.2 Generalization and Specialization
Generalizations and specializations are transformed to the Indirect Fields.
This allows one element to be visualized in another. It is realization of element
composition principle described in section 2.3.3.
One level of generalizationspecialization relationship is a simple situation.
Both elements could be directly visualized in each other.
Problem is a multiple level generalizationspecialization chain, since in-
direct elds do not visualize indirect elds of other elements. The following
solutions are proposed:
1. Recursively scan the generalization chain and the specialization chain
form the current element and visualize all found generalized / specialized
elements directly in the current element.
2. Allow parametric denition (at application level) how many levels can
be scanned and visualised.
3. Visualize only the directly generalized / specialized elements.
The st two solutions would require a lot of runtime constraints, to assure
that no element in the chain is skipped. For example in chain sparrow
bird animal creation of sparrow animal without instantiation of the bird
must be forbidden. Also the st solution can cause entities grow to enormous
dimensions, therefore it is not considered optimal.
The one level solution will be implemented, to prove this concept.
3.3.3.3 Generalization Sets
One indirect eld can contain only single instance of element. But can be
congured to t several dierent element types. This feature can be utilized
in realization of the generalization set metaattributes.
29
3. Analysis and Design
indirect indirect
element
Sub Element
indirect indirect
element
Super Element
element
Sub Element
indirect indirect
element
Sub Element
indirect
element
Super Element
element
Sub Element
subkind
Sub Element
kind
Super Element
subkind
Sub Element
Figure 3.3: Possible implementations of generalization set
{no attributes } When no metaattributes are present, mechanism on the left
side of gure 3.3 is used. It will allow both specialization to be instan-
tiated.
{complete} The left mechanism is used, but implementer must be no-
tied about disabling instantiation of the bare superelement.
{disjoint} The right mechanism is used. This solution is more or
less satisfactory. The superelement may connect to both subelements,
but only one at the time. Both subelements have link to superelement.
This is the weak spot of this mechanism, as several subelements may be
connected to one superelement.
{disjoint, complete} Combination of the right mechanism and the code
customization note.
3.4 Summary of the Proposed Method
3.4.1 Method Capabilities
Essence of the conceptual model can be transformed to the structural deni-
tion of NSE, even though much auxiliary information will be lost.
It was possible to design the method to be executed without any human
intervention during the process, therefore it will be suitable for iterative de-
velopment.
3.4.2 Limitations
Operations on elements will be ignored, since they are unrelated to structural
denitions. Their possible utilization for workow is questionable and out
of scope of this work.
Conceptual model could provide integrity constraints exceeding the UML,
that are not utilized right now. OLED allows dening rules via Object Con-
straint Language (OCL) [19]. After examining the expression power of NSE,
such rules would have to be realized via code customizations.
30
3.4. Summary of the Proposed Method
Descriptors currently must be completed with information that conceptual
models do not provide (e.g. database schemas and visual styles). Although
conceptual models (by their nature) will never provide this information, it can
be blended in during the transformation process form another source.
Customization note is a workaround mechanism, informing the imple-
menter about crucial code customizations. Those customization notes will
be written to descriptors as comments. A le summarizing all the proposed
customization will be created for comfortable overview of necessary changes.
31
Chapter 4
Prototype Implementation
4.1 Basic Concept
Program simply transforms input text les to output text les, without any
user intervention during the process. Therefore it is realized as a command
line tool.
Application is designed using the object-oriented paradigm. Although the-
matic focus of this work is Normalized Systems theory, it serves only as a loose
inspiration for the implementation part. The theory implies excessive gran-
ularity of code [12], which is very challenging to achieve by human imple-
mentation. Also, since this work is the rst authors encounter with NS, it
would be a very bold to state that the program complies with all the desired
requirements.
Java was chosen as implementation language, because of rich string ma-
nipulation capabilities, overall ease of use and multi-platform support. It is
also the programming language of OLED and some components of NSE, thus
potential integration into those present tools would be straightforward.
4.2 Internal Structure
Application is composed of the main data model skeleton and supporting
classes.
The data model skeleton is a hierarchy of classes imitating the OntoUML
entities. It is able to read information from given XML document and print
itself to NSE les.
The other packages contain supporting classes, that are responsible for
service tasks (e.g. run control, logging, parsing application conguration le,
writing les to le system).
33
4. Prototype Implementation
4.2.1 Data Model Specication
Class hierarchy is based on taxonomy of ontological entities described in [2].
Model used in the application is adapted from graduation thesis of Roberto
Carraretto [7]. Carrarettos model is used for dening the RefOntoUML.
Because OntoUmlDistiller use the model in slightly dierent way, its structure
had to be changed. Most signicant dierences are mentioned in this text, but
many minor changes (e.g. renaming data properties) are omitted.
Java package cz.cvut.fit.bp.ontoumldistiller.model and its subpack-
ages contain the code of whole data model. Top level of this package contains
three classes:
DataModel is the main standalone model class; registers all components,
entities and application settings (via AppSettings class)
DataModelComponent registers all data model entities for particular com-
ponent
DataModelEntity is an abstract superclass for all data model entities
(both element and relationship)
The DataModelEntity class is root for spreading tree of data model en-
tities. At the top level, it forks to four building blocks (see gure 4.2.1).
(Carrarettos model [7] does not dene such super-entity.)
GeneralizationEntity
ElementEntity
RelationshipEntity
DataTypeEntity DataModelEntity
Figure 4.1: Direct descendants of DataModelEntity class
This abstract root entity implements two interfaces: RefOntoUmlParsing
(for parsing RefOntoUML XML documents) and Nse23Writing (for writing
NSE v2.3 descriptor les). Implementation of interface methods can be found
at descendants. Utilising polymorphism, method implementation is simply
overridden where is more specialization necessary. Interfaces also improves
overall structure of code. Prospective functionality can be added as another
interface, while keeping the code tidy.
DataTypeElement and GeneralizationElement are concrete class and are
not further specialized. The ElementEntity and RelationshipEntity ramify
34
4.3. Conguration File
Moment
Mode
Relator
Mixin
RoleMixin
SemiRigidMixin
AntiRigidMixin
Category RigidMixin
NonRigidMixin
MixinUniversal
Role
Phase
SubKind
Collective
Quantity
Kind
SubstanceSortal
AntiRigidSortal
RigidSortal
SortalUniversal
ElementEntity
Figure 4.2: Hierarchy of element classes
to large trees depicted in gures 4.2.1 and 4.2.1. Abstract classes are plotted
with white background, concrete classes with gray.
Association
Derivation
Formal
Material
Mediation
Characterization
ComponentOf
MemberOf
SubCollectionOf
SubQuantityOf
DependencyRelationship
Meronymic
DirectedBinaryAssociation
RelationshipEntity
Figure 4.3: Hierarchy of relationship classes
In Carrarettos model [7], moments (from gure 4.2.1) are independent
group. In this model are placed under the ElementEntity, because they
exhibit object characteristics and are treated as objects in further processing.
4.3 Conguration File
Along the RefOntoUML les, it is necessary to provide XML conguration
le to the application. The settings can be divided into two groups.
35
4. Prototype Implementation
4.3.1 Application Control Settings
Several settings control the behaviour of OntoUmlDistiller itself and does not
aect the content of generated descriptor les. These settings include: log
location, logging level and location of the destination folder for generated
les.
In the root folder is created the data descriptor and another folders, bear-
ing the name of each component. Into these component folders are generated
the respective component descriptors and data descriptors.
There is also option to write summary of all customization notes to one
le, for comfortable overview of necessary changes.
4.3.2 Model Complementary Information
Another group of settings contains supplementary information for the gen-
erated data structures, that cannot be captured in the model les, but are
required for proper generation of the descriptor les. This data include: sup-
ported data types, generated applications Java package, short application
name and full application name.
4.3.3 Data Types Denition
Data types could be dened in two ways: basic data types and enumerated
data types. The basic ones are dened only by their names. These should
correspond to those supported by the underlying framework used by the NSE.
The enumerated data type is dened by its name, representation and enu-
meration values. Representation value must be one from the basic data types
list (ergo one of the types supported by NSE framework).
During the parsing process are data elements attributes compared to names
of supported data types. When no match is found, the application reports
an error and exits. Representation values of the enumerated types are tested
in the same manner.
4.4 Formal Grammars of Generated Files
All output les are generated by their respective grammars presented in this
section. Notation uses Extended BackusNaur Form (EBNF) syntax dened
in [20]. The special sequence symbols (?...?) are used for describing data
extracted from the applications model. EOL is a terminal symbol representing
end-of-line.
36
4.4. Formal Grammars of Generated Files
4.4.1 Application Descriptor
ad file = header line, style def note, {component def},
component def, db schema def note;
header line = short app name, " ", full app name, EOL;
component def = "component-", component name, EOL;
db schema def note = "# ADJUSTMENT OPTIONAL", EOL,
"# optionDataBaseSchema-", EOL;
short app name = ? short name of the application ?;
full app name = ? full name of the applicaiton ?;
component name = ? name of used user/base component ?;
4.4.2 Component Descriptor
cd file = header line, {comp dependency}, {mtm links};
header line = component name, " ", component name,
"-view", EOL;
comp dependency = "depends-", base dependency, EOL;
mtm links = "MTM-", mtm component name, EOL;
component name = ? name of data model component ?;
base dependency = ? name of base component used
in application ?;
mtm component name = ? name of component which has many-to-many
relations with current one" ?;
37
4. Prototype Implementation
4.4.3 Element Descriptor
dd file = header line, {customization note}, EOL,
{attribute}, EOL, {indirect field}, EOL, {relationship link}, EOL, {option};
header line = component name, " ", java package name,
" ", data element name, EOL;
customization note = "# CUSTOMIZATION NECCESSARY: ",
note message, EOL;
attribute = data type, " ", atrribute name, " yn",
values enumeration, EOL;
indirect field = "Indirect ", indirect prefix, element name,
" ynn", EOL;
relationship link = {customizaton note}, link prefix, java
package name, ".", counter element name,
" ", counter element name, " ynn", EOL;
option = find method | indirect option ;
find method = "findBy", attribute name, comparator
suffix, EOL;
indirect option = "optionIndirect", indirect prefix, element name,
"_", java package name, ".", element name;
values enumeration = "n" | "y", {(enum value, "_")}, enum value;
link prefix = "Ln", ("1" | "2" | "3" | "4" | "5" | "6");
comparator suffix = "Eq" | "Lt" | "Gt";
indirect prefix = "gen" | "spe" | "gs" | "";
atrribute name = ? name of some of elements attribute?;
component name = ? name of elements component ?;
indirect field = ? name of the defined indirect field ?;
java package name = ? name of elements Java package ?;
enum value = ? possible value of the enumerated type ?;
element name = ? name of element inserted by indirect field?;
counter element name = ? name of the element on the opposite
side of the relationship ?;
note message = ? instruction to customization to comply
with OntoUML model ?;
38
4.5. Application Usage
4.5 Application Usage
This section roughly describes how the OntoUmlDistiller is used. Complete
user guide is located in appendix B.
Converting OntoUML models consists of the following steps:
1. Data models prepared in OLED must be saved as RefOntoUML. One
diagram le will be transcribed into one NSE component. The name
of le without the .refontouml extension will be used as component
name.
2. Conguration le has to be adjusted. Attention should be given espe-
cially to the denition of the data types. As mentioned in section 4.3.3,
data types must match those used by NSE framework.
3. Application is launched from terminal with following command:
java -jar OntoUmlDistiller.jar <app.distillerConfig>
<c1.refontouml> ... <cN.refontouml>
Linking among diagrams is possible using the :: operator; for example
component1::SomeElement will be resolved to element named SomeElement
from le component1.refontouml. Using this mechanism, it is possible to cre-
ate large scale domain models while maintaining clarity. This mechanism is
used in [21].
Model entities are identies by their names, hence creating two components
with same name will result to a fatal error. This unique names rule comply
with essential OntoUML principles [2]. Nevertheless, the OLED does not
verify this rule, so uniqueness is not guaranteed even inside single component
model.
39
Chapter 5
Case Study
5.1 Case Study Description
Case study was intended to verify designed method and implemented proto-
type. It was not intended to imitate the development of a true information
system, but to comprehensively verify the proposed method on a suciently
complex example.
Problem domain model was adapted from [2] and contains all UFO-A
phenomena. It was divided to four components. For specic testing purposes,
several many-to-many inter-component relations were added. Model was also
enhanced with a sucient number of data elds to test data elds conversion.
Adapted component diagrams are included in Appendix C.
5.2 Execution Environment
Conversion of RefOntoUML les (included on attached CD) was accomplished
according to user guide (Appendix B). Java Runtime Environment version 1.7
was used.
Expansion of the generated descriptors was executed by Paul Adriaenssens
at the NSE bvba in Belgium. The Normalized Systems Expander version 2.3
was used.
5.3 Processing Case Study
The expansion was performed in several iterations:
First expansion revealed errors in the implementation as well as insucien-
cies in prototype features. Provided feedback was incorporated into the pro-
totype tool. Errors were xed, necessary functionality implemented. There
was also a change in transforming the one-to-one links: The Ln01-Ln01 mech-
41
5. Case Study
anism was reconsidered as more elegant and therefore preferred (see 3.3.2.2).
Next expansions helped to iteratively x all errors.
The last run of expansion was syntax error free. By this, the nal goal
of this thesis was reached.
5.3.1 Expansion Artefacts
During the expansion, basic ER diagrams for each component were created.
The are included in Appendix C for comparison with the OntoUML diagrams.
Note that the indirect link mechanism is not shown in the diagrams.
Expansion logs provided by the developers are included on the attached
CD (see section E).
42
Conclusion
Evaluation of Goals
Design a theoretical method transforming OntoUML diagrams to NSE
element descriptors.
Accomplished transformation method has been proposed for all On-
toUML phenomena. The proposed transformation were discussed. When
several transformation methods were available, the chosen solution was
argued.
Create a prototype tool implementing designed method.
Accomplished the prototype tool was implemented in quality sucient
to perform a case study test. And hence prove proposed theoretical
method.
Demonstrate method and tool functionality on OntoUML domain model.
Accomplished as the last expansion was error free, the case study can
be considered as successful. It also proves, that the previous two goals
were formally correct.
Thoughts on Method Utilisation
Presented conversion method is denitely not bulletproof. Case on larger
real-world cases could reveal weak spots from the users point of view.
Without direct access to the Normalized Systems Expander (NSE), eval-
uation of the user experience is impossible. I would be also impossible to
achieve this in the time frame of this the bachelors thesis. Therefore is the
formal correctness satisfactory goal and a solid base for further development
Obstacles, that were experienced during creation of this thesis, may serve
as input for improvements of the Normalized Systems Expander (NSE). The
43
Conclusion
ontological theory behind proposed method implies validity and necessity of
mentioned problems.
Future Work
There is a lot of space for improvements in the presented method itself but
not in the dry theory. Now, the method must be used, discussed, evaluated
and improved again and again. It should keep pace with the two bleeding-edge
technologies, between which is stretched. Hopefully, after enough evolution,
it would form into a solid bridge.
During the development, even specic objectives were daydreamed. For
example, if the NSE development will head to ontological completeness, Object
Constraint Language (OCL) constraints should be supported.
Implementation to a drawing tool (e.g. OLED), would not just introduce
user-friendliness, but it also enable new features. Major benet would be that
user can convert conceptual to implementation model in the GUI. He could see
the visualized implementation draft and even customize it to suit his needs.
Then, with a click of a button, the application would write well prepared data
descriptors.
Another undoubtedly useful feature is iteration modelling. It would al-
low user to preserve changes made to the generated descriptor les while
re-generating the model by the application. Similar problem is solved by har-
vesting + injection in the NSE framework. This mechanism may serve as
a good example.
44
Bibliography
[1] Mannaert, H.; Verelst, J.; Ven, K. Towards evolvable software architec-
tures based on systems theoretic stability. Software: Practice and Experi-
ence, volume 42, no. 1, 2012: pp. 89116, ISSN 1097-024X, doi:10.1002/
spe.1051. Available from: http://dx.doi.org/10.1002/spe.1051
[2] Guizzardi, G. Ontological Foundations for Structural Conceptual Mod-
els. Dissertation thesis, University of Twente, Netherlands, 2005, [ac-
cessed: 10. 12. 2013]. Available from: http://doc.utwente.nl/50826/1/
thesis Guizzardi.pdf
[3] Nardi, J.; De Almeida Falbo, R.; Almeida, J.; et al. Towards a
Commitment-Based Reference Ontology for Services. In Enterprise Dis-
tributed Object Computing Conference (EDOC), 2013 17th IEEE In-
ternational, Sept 2013, ISSN 1541-7719, pp. 175184, doi:10.1109/
EDOC.2013.28.
[4] Guarino, N.; Oberle, D.; Staab, S. What Is an Ontology? In Handbook
on Ontologies, edited by S. Staab; R. Studer, International Handbooks
on Information Systems, Springer Berlin Heidelberg, 2009, ISBN 978-3-
540-70999-2, pp. 117, doi:10.1007/978-3-540-92673-3 0. Available from:
http://dx.doi.org/10.1007/978-3-540-92673-3 0
[5] The Gene Ontology Consortium. The Gene Ontology project in 2008.
Nucleic Acids Research, volume 36, no. suppl 1, 2008: pp. D440
D444, doi:10.1093/nar/gkm883, http://nar.oxfordjournals.org/
content/36/suppl 1/D440.full.pdf+html. Available from: http:
//nar.oxfordjournals.org/content/36/suppl 1/D440.abstract
[6] Object Management Group (OMG). OMG Unied Modeling Language
(OMG UML), Superstructure. Object Management Group, Inc., Need-
ham, MA, USA, 2011. Available from: http://www.omg.org/spec/UML/
2.4.1/Superstructure/PDF/
45
Bibliography
[7] Carraretto, R. A Modelling Infrastructure for OntoUML. Bachelors the-
sis, Federal University of Esprito Santo (UFES), Brazil, 2010, [accessed:
10. 1. 2014]. Available from: http://rcarraretto.googlecode.com/
files/aModelingInfrastructureForOntoUML.pdf
[8] Guizzardi, G.; Wagner, G. Tutorial: Conceptual simulation model-
ing with Onto-UML. In Simulation Conference (WSC), Proceedings of
the 2012 Winter, Dec 2012, ISSN 0891-7736, pp. 115, doi:10.1109/
WSC.2012.6465328.
[9] Guizzardi, G.; Wagner, G.; Sinderen, M. A formal theory of conceptual
modeling universals. Technical report, Deutsches Forchungszentrum fur
Kunstliche Intelligenz, 2004.
[10] Guizzardi, G.; Wagner, G. Using the unied foundational ontology (UFO)
as a foundation for general conceptual modeling languages. In Theory
and Applications of Ontology: Computer Applications, Springer, 2010,
pp. 175196.
[11] Wikipedia. Normalized Systems. [ONLINE], 2014, [accessed: 1. 3. 2014].
Available from: http://en.wikipedia.org/wiki/Normalized Systems
[12] Verelst, J.; Mannaert, H. Normalized Systems: Re-creating Information
Technology Based on Laws for Software Evolvability. Antwerp, Belgium:
Koppa, 2009, ISBN 978-90-77160-00-8.
[13] Lehman, M. M. Programs, life cycles, and laws of software evolution.
Proceedings of the IEEE, volume 68, no. 9, 1980: pp. 10601076.
[14] McIlroy, M. D.; Buxton, J.; Naur, P.; et al. Mass-produced software com-
ponents. In Proceedings of the 1st International Conference on Software
Engineering, Garmisch Pattenkirchen, Germany, sn, 1968, pp. 8898.
[15] Ontology and Conceptual Modelling Research Group (NEMO). On-
toUML Lightweight Editor (OLED). [APPLICATION], 2014, [accessed:
12. 5. 2014]. Available from: https://code.google.com/p/ontouml-
lightweight-editor/
[16] Ontology and Conceptual Modelling Research Group (NEMO). On-
toUML Support. [ONLINE], 2014, [accessed: 1. 3. 2014]. Available from:
http://nemo.inf.ufes.br/en/ontoumlsupport
[17] Adriaenssens, P.; Mannaert, H. Normalized Systems Expanders v2.3 De-
velopment Guide. 2013, working copy provided by NSX bvba.
[18] Adriaenssens, P.; Mannaert, H. NS Expanders v2.3 Element Expanders
Reference Guide. 2013, working copy provided by NSX bvba.
46
Bibliography
[19] ISO/IEC 19507. Information technology Object Management Group
Object Constraint Language (OCL). International Organization for Stan-
dardization, Geneva, Switzerland, 2012.
[20] ISO/IEC 14977. Information technology Syntactic metalanguage Ex-
tended BNF. International Organization for Standardization, Geneva,
Switzerland, 1996.
[21] Goncalves, B.; Guizzardi, G.; Pereira Filho, J. G. An electrocardiogram
(ECG) domain ontology. In Workshop on Ontologies and Metamodels for
Software and Data Engineering, 2nd, Joao Pessoa, Brazil, 2007, pp. 68
81.
[22] Leahy, P. Java Naming Conventions. [ONLINE], 2014, [accessed: 25.
3. 2014]. Available from: http://java.about.com/od/javasyntax/a/
nameconventions.htm
[23] Oracle corp. Java Language Keywords. [ONLINE], 2014, [accessed: 25.
3. 2014]. Available from: http://docs.oracle.com/javase/tutorial/
java/nutsandbolts/ keywords.html
[24] World Wide Web Consortium (W3C). Extensible Markup Language
(XML) 1.0 (Fifth Edition). International Organization for Standardiza-
tion, Geneva, Switzerland, 2008. Available from: http://www.w3.org/
TR/2008/REC-xml-20081126/
47
Appendix A
Acronyms
UFO-A UFO module for structural aspects
UFO-B UFO module for event-related concepts
UFO-C UFO module for social and intentional aspects
UFO-S UFO module for service-related concepts
ASCII American Standard Code for Information Interchange
DOLCE Descriptive Ontology for Linguistic and Cognitive Engineering
EA Enterprise Architect
EBNF Extended BackusNaur Form
GFO General Formal Ontology
ICT information and communication technology
IS information system
IT information technology
LOA Laboratory for Applied Ontology
MVC Model-View-Controller architecture
MVVM Model-View-ViewModel architecture
NEMO Ontology and Conceptual Modelling Research Group
NS Normalized Systems
49
Glossary
NSE Normalized Systems Expander
OCL Object Constraint Language
OLED OntoUML Lightweight Editor
OntoUML UML prole for ontological modelling
OO object oriented
RefOntoUML XML representation of OntoUML data model
SDLC software development life-cycle
UFO Unied Foundation Ontology
UML Unied Modelling Language
XML Extensible Markup Language
50
Appendix B
OntoUmlDistiller User Guide
OntoUML Distiller is able to process les in XML representation of OntoUML
data model (RefOntoUML) format. This fomat can be exported from On-
toUML Lightweight Editor (OLED). Models created in Sparx Systems En-
terprise Architect can be converted OLED to RefOntoUML as well.
System requrements: Java version 1.7 or later.
B.1 Model Design Guidelines
OntoUmlDistiller is designed to inuence conceptual modelling as little as
possible. Nevertheless, there are some design limitations and principles have
to be followed.
B.1.1 Diagrams and Entities Structure
The diagram is meant one RefOntoUML le. Each of these les will be tran-
formed into one NSE application component. The component name is derived
from the diagram le by removing the .refontotuml extension.
Entities can be shared among diagrams. Each entity has its base diagram.
It can be linked to other diagrams by using the :: operator. Linked entity
name consist of component name, the dot operator and name of the entity
in base diagram (e.g. baseDiagramName::linkedEntityName). Attributes
of this entity must be dened in its base component, otherwise they will be
ignored.
B.1.2 Data Type Denitions
Attribute data types are identied in the model by their names. By their
nature, they can be divided into two groups:
51
B. OntoUmlDistiller User Guide
Simple data types are dened only with its name. This name must by
one of the list of data types supported by the NSE. Every attribute data type
is checked by the OntoUmlDistiller. When the attribute is not present on
the list, error message is logged.
Enumerated data types are data types with dened list of possible val-
ues. It can be dened with custom name, representation data type (that has
to be one of the simple) and a list of possible values. Unlike enumerations
in common programming languages, this enumerated value is not encoded.
Therefore the chosen representation data type must accommodate all submit-
ted values.
B.1.3 Naming Regulations
Generally, only ASCII alphanumeric characters and a - (minus) are safe
to use for naming purposes.
Characters that will cause error or unpredicted behaviour are: (space),
# (hash), (underscore) and ; (semicolon). Those character have to be
replaced, if used anywhere in the model.
Attribute elds must comply with the Java naming conventions [22]. The most
critical rule: rst letter of the attribute name must be in lower case.
Reserved Java keywords [23] should be avoided, as they can cause errors
during the expansion process by NSE.
B.2 Conguration File
Sample conguration (example.distillerConfig) le is provided in the ap-
plication release pack.
Data are organized in simple XML structure. Customized values must not
violate the naming regulations and the XML standard [24].
Following section explains used nodes and their attributes:
node output
attr folderLocation path to the generation output folder. If the folder
or whole path does not exist, it is created.
attr customizationSummary is boolean value describing whether all
customization notes should written into one summarizing le.
node logging
attr level describes the desired login level. Possible values: ERROR,
WARN, INFO, DEBUG, TRACE.
attr outputFile path to the log le.
52
B.3. Launching the Application
node application
attr fullName is the full name of the generated application shown in the in-
terface. Further information can be found in [17].
attr shortName is the name of the folder in expansion folder. Further
information can be found in [18].
node baseComponents
node value contains text value representing base component dependency.
node dataTypes is enclosing tag for data type denitions.
node dataType contains single data type denition.
attr name is mandatory attribute dening the data type name, used
as an identier in model.
attr representation is optional attribute. When it is present,
the data type is considered as enumerated data type, otherwise
simple data type.
node value contains text value representing one of possible enu-
meration values.
B.3 Launching the Application
Application is launched from command line with following command:
java -jar OntoUmlDistiller.jar <app.distillerConfig>
<c1.refontouml> ... <cN.refontouml>
<app.distillerConfig> path to the conguration le. It has to be the rst
argument.
<c1.refontouml> ... <cN.refontouml> are paths to RefOntoUML les
to be processed. Their order does not matter.
53
Appendix C
Case Study Model Diagrams
55
C. Case Study Model Diagrams
C.1 Component Music
Figure C.1: Component Music OntoUML diagram
Band
BandMember
bandMembers
Authorship
PerformerArtist
mediationM1
Album
mediationM2 mediationM1
Recording
mediation4 Track
tracks
performerArtists
mediation3
componentOf1
IndividualArtist
mediationM2
AlbumTrack
albumTrack album records
mediation3
Figure C.2: Component Music ER diagram after expansion
56
C.2. Component Object
C.2 Component Object
Figure C.3: Component Object OntoUML diagram
HumanOrgan Coordinates
SpatialThing
thingLocation
PhysicalObject
physicalObject
BiologicalEntity
Person
person coordinatess
locatedIn
Gallery
coordinates
locatedIn
MaterialEntity
constitutedBy
HumanHeart
person
GeographicalSpace geographicalSpaces spatiallySubSumes Museum InanimateEntity
constitutedBy
Statue SurgeryRoom
persons
Figure C.4: Component Object ER diagram after expansion
57
C. Case Study Model Diagrams
C.3 Component Organization
Figure C.5: Component Organization OntoUML diagram
Belief ActiveOrganization Group
Organization
organization
Agent
agents
ActiveAgent
MentalState
mentalState
PriorityLevel priorityLevelshigherThan
Intention
intention
ExtinctOrganization Desire
activeAgent priorityLevel
intentionsmoreImportantThan
group
agent
memberOf31
organization
Figure C.6: Component Organization ER diagram after expansion
58
C.4. Component Person
C.4 Component Person
Figure C.7: Component Person OntoUML diagram
Female
BirthCerticate
Ospring
material2
Parent
parent
Father
Person
HumanHeart
humanHeart
SurgeryRoom
isOccupiedBy
BiologicalEntity
biologicalEntity material2
parent
LivingPerson DeceasedPerson DateObject
issueDate dateOfBirth
Male
birthCerticate
ospring
Mother
Figure C.8: Component Person ER diagram after expansion
59
Appendix D
NSE Descriptor File Examples
D.1 Application Descriptor
ontoDistApp OntoUmlDistillerTestApplication
#ADJUSTMENT NECESSARY: set styles
# style=
style=nsx
style=nsxbootstrap
component-account
component-utils
component-music
component-organization
component-person
component-object
#ADJUSTMENT OPTIONAL: set database schemas
# optionDataBaseSchema-
D.2 Component Descriptor
object object-view
depends-account
depends-utils
MTM-person
61
D. NSE Descriptor File Examples
D.3 Data Descriptor
person cz.cvut.fit.bp.ontodistapp.person Person
Integer ssn ynn
String name ynn
Indirect speParent ynn
Indirect speSetGsSex ynn
Indirect speSetGsLifePhases ynn
Indirect speIndividualArtist ynn
Indirect speOffspring ynn
Indirect dateOfBirth ynn
Ln06cz.cvut.fit.bp.ontodistapp.object.SurgeryRoom isOccupiedBy ynn
Ln05cz.cvut.fit.bp.ontodistapp.object.HumanHeart humanHeart ynn
Ln05cz.cvut.fit.bp.ontodistapp.object.BiologicalEntity biologicalEntity ynn
optionIndirectspeParent_cz.cvut.fit.bp.ontodistapp.person.Parent
optionIndirectspeSetGsSex_cz.cvut.fit.bp.ontodistapp.person.Female
optionIndirectspeSetGsSex_cz.cvut.fit.bp.ontodistapp.person.Male
optionIndirectspeSetGsLifePhases_cz.cvut.fit.bp.ontodistapp.person.LivingPerson
optionIndirectspeIndividualArtist_cz.cvut.fit.bp.ontodistapp.music.IndividualArtist
optionIndirectspeOffspring_cz.cvut.fit.bp.ontodistapp.person.Offspring
optionIndirectspeSetGsLifePhases_cz.cvut.fit.bp.ontodistapp.person.DeceasedPerson
optionIndirectdateOfBirth_cz.cvut.fit.bp.ontodistapp.person.DateObject
62
Appendix E
Contents of enclosed CD
readme.txt....................................CD contents description
Case Study..............................case study related documents
Data Descriptors............................generated descriptors
Expansion ....................... descriptors expansion artefact les
Model...................................case study model diagrams
Implementation...........................implementation related les
OntoUmlDistiller.jar.........................application JAR le
src.....................................implementation source code
Text.......................................................thesis text
BP Kolarik Vincenc.pdf..................PDF version of the thesis
src.................................L
A
T
E
X source codes of the thesis
63