Applying OntoUML for structural definitions of Normalized Systems Expanders

8/11/2019 Applying OntoUML for structural definitions of Normalized Systems Expanders

1/79

Insert here your thesis task.


2/79


3/79

Czech Technical University in Prague

Faculty of Information Technology

Department of Software Engineering

Bachelors thesis

Applying OntoUML for structural

definitions of Normalized SystemsExpanders

Vincenc Kolark

Supervisor: Ing. Robert Pergl, Ph.D.

13th May 2014


4/79


5/79

Acknowledgements

Greatest thanks go to Ing. Robert Pergl, Ph.D. for introducing me to theseinteresting topics, as well as his encouraging consultations and inspirationalguidance. Another great deal of gratitude belongs to ir. Paul Adriaenssens for prompt responses to my fiddly questions about NSE and for the time spentperforming my case study, even on Sunday nights. Thanks to my family andmy friends, for staying my family and my friends. And finally, thanks to mycat Sarah, for keeping me company during sleepless nights.


6/79


7/79

Declaration

I hereby declare that the presented thesis is my own work and that I havecited all sources of information in accordance with the Guideline for adheringto ethical principles when elaborating an academic final 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, inparticular 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 underthe provisions of Article 60(1) of the Act.

In Prague on 13th May 2014 . . . . . . . . . . . . . . . . . . . . .


8/79

Czech Technical University in PragueFaculty of Information Technologyc 2014 Vincenc Kolark. All rights reserved.

This thesis is school work as defined by Copyright Act of the Czech Republic.

It has been submitted at Czech Technical University in Prague, Faculty ofInformation Technology. The thesis is protected by the Copyright Act and itsusage without authors permission is prohibited (with exceptions defined by theCopyright Act).

Citation of this thesis

Kolark, Vincenc. Applying OntoUML for structural definitions of NormalizedSystems Expanders. Bachelors thesis. Czech Technical University in Prague,Faculty of Information Technology, 2014.


9/79

Abstrakt

Prace se zabyva moznostmi vyuzit OntoUML pro strukturaln definice Ex-panderu Normalizovanych systemu. Analyzuje vyrazove schopnosti obou kon-ceptu a porovnava je. Jejm klcovym prnosem je navrh metody pro transfor-maci OntoUML modelu do souboru pro popis datovych elementu ExpanderuNormalizovanych sytemu. Implementacn cast prace je prototyp nastroje re-alizujc tento prevod. Navrzena metoda a vytvoreny nastroj jsou predvedenyna prpadove studii.

Klcova slova Expander Nomalizovanych systemu, generovan kodu, in-

formacn system, Normalizovane systemy, OLED, ontologicky model, On-toUML

ix


10/79

Abstract

Thesis is engaged in possibilities of utilizing OntoUML for structural defini-tion of Normalized Systems Expanders. It analyses the expressive capabilitiesof both concepts and compares them with each other. A key contributionof this work is to design a method for transformation OntoUML model intothe element descriptor files of Normalized Systems Expanders. Work includesa prototype tool implementing this transformation. The designed method andtool functionality are also demonstrated in a case study.

Keywords code generation, information system, Normalized Systems, Nor-

malized Systems Exapnder, OLED, ontologic model, OntoUML

x


11/79

Contents

Introduction 1

1 Goals and Approach 3

1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Thesis Structure and Tasks . . . . . . . . . . . . . . . . . . . . 4

2 Theoretical Background 72.1 Unified Foundation Ontology . . . . . . . . . . . . . . . . . . . 7

2.2 OntoUML Overview . . . . . . . . . . . . . . . . . . . . . . . . 82.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 . . . . . . . . . . . . . . . . . 213.3 Conversion of OntoUML to NSE . . . . . . . . . . . . . . . . . 25

3.4 Summary of the Proposed Method . . . . . . . . . . . . . . . . 30

4 Prototype Implementation 33

4.1 Basic Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 Internal Structure . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4 Formal Grammars of Generated Files. . . . . . . . . . . . . . . 36

4.5 Application Usage . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Case Study 41

5.1 Case Study Description . . . . . . . . . . . . . . . . . . . . . . 415.2 Execution Environment . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Processing Case Study . . . . . . . . . . . . . . . . . . . . . . . 41

xi


12/79

Conclusion 43

Evaluation of Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Thoughts on Method Utilisation . . . . . . . . . . . . . . . . . . . . 43Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Bibliography 45

A Acronyms 49

B OntoUmlDistiller User Guide 51B.1 Model Design Guidelines. . . . . . . . . . . . . . . . . . . . . . 51B.2 Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . 52B.3 Launching the Application. . . . . . . . . . . . . . . . . . . . . 53

C Case Study Model Diagrams 55C.1 Component Music . . . . . . . . . . . . . . . . . . . . . . . . . 56C.2 Component Object . . . . . . . . . . . . . . . . . . . . . . . . . 57C.3 Component Organization . . . . . . . . . . . . . . . . . . . . . 58C.4 Component Person . . . . . . . . . . . . . . . . . . . . . . . . . 59

D NSE Descriptor File Examples 61D.1 Application Descriptor . . . . . . . . . . . . . . . . . . . . . . . 61D.2 Component Descriptor . . . . . . . . . . . . . . . . . . . . . . . 61D.3 Data Descriptor. . . . . . . . . . . . . . . . . . . . . . . . . . . 62

E Contents of enclosed CD 63

xii


13/79

List of Figures

2.1 Typology ofSubstantials . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Combinatorial effects explained[1] . . . . . . . . . . . . . . . . . . 14

3.1 Ambiguous relationship in conceptual model . . . . . . . . . . . . 253.2 Examples of relationship interpretation . . . . . . . . . . . . . . . 253.3 Possible implementations of generalization set . . . . . . . . . . . . 30

4.1 Direct descendants of DataModelEntity class . . . . . . . . . . . . 344.2 Hierarchy ofelement classes . . . . . . . . . . . . . . . . . . . . . . 354.3 Hierarchy ofrelationship classes. . . . . . . . . . . . . . . . . . . . 35

C.1 Component MusicOntoUMLdiagram . . . . . . . . . . . . . . . . 56C.2 Component Music ER diagram after expansion . . . . . . . . . . . 56C.3 Component ObjectOntoUMLdiagram. . . . . . . . . . . . . . . . 57C.4 Component Object ER diagram after expansion. . . . . . . . . . . 57C.5 Component OrganizationOntoUMLdiagram . . . . . . . . . . . . 58C.6 Component Organization ER diagram after expansion . . . . . . . 58C.7 Component PersonOntoUMLdiagram. . . . . . . . . . . . . . . . 59C.8 Component Person ER diagram after expansion. . . . . . . . . . . 59

xiii


14/79


15/79

List of Tables

2.1 Cardinalities in OntoUML . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Conversion of many-to-many associations . . . . . . . . . . . . . . 273.2 Conversion of one-to-many associations . . . . . . . . . . . . . . . 273.3 Conversion of one-to-one associations. . . . . . . . . . . . . . . . . 28

xv


16/79


17/79

Introduction

Information systems have overcome a major milestone in their development.Software engineers conquered the problem of creating newinformation system(IS) in all its extent. Sophisticated software development methodologies andmodular programming paradigms allow to design, implement and deploy ISof unprecedented size. With the increasing systems complexity and ageing,new batch of issues arise.

Since the beginning of implementation IT to business, companies becomemore and more dependent on information and communication technology(ICT) infrastructure. With insignificant effort,IS serves the company as a re-

liable workhorse. When there is no need to change, the current system runssmooth. But the company needs to adapt to the ever changing market andthe system requires modification to suit new functionality. Using current soft-ware development methodologies, every change in theIS increases its overallcomplexity. That leads to increasing costs for every subsequent change, there-fore economic gain provided by the system decreases. Such problem cannotbe solved by current approaches, resulting in a demand for new principles.

Problem of increasing software complexity is theoretically solved by theNor-malized Systems(NS). This theory addresses issues related to software evolv-ability and defines 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 patternsto re-defining responsibilities of participants, extending to business processesautomation and modelling. NSis currently being developed at the Universityof Antwerp. Its theoretical foundations are based on formal proofs as well asstatistical data.

Normalized Systems is primarily IT oriented and does not specify howto describe the problem domain for which is the ISbuilt. Unified ModellingLanguage(UML) is a common graphical language used for this purpose, how-ever in its pure form is intended for depicting code hierarchy, not real-worldentities and relations. To suit ontological needs, Dr. Giancarlo Guizzardi cre-

1


18/79

Introduction

atedUML profile for ontological modelling(OntoUML). Its strong expression

power and solid theoretical background makes it a potent tool for ontologicalmodelling.

This work aims to broach the ambitious task to connect these two theoriesand thus make a contribution to next generation of software development.

2


19/79

Chapter 1

Goals and Approach

1.1 Goals

In accordance to thesis assignment the following goals were set:

Design a theoretical method transformingOntoUMLdiagrams (in extentofUFO-A) toNSE element descriptors.

Create a prototype tool implementing designed method.

Demonstrate method and tool functionality onOntoUMLdomain model.

1.2 Approach

1.2.1 General Rules

In an effort to make this work conceptually coherent, there were defined 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 toNSE,so the userexperience 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 withvalid data models and will posses minimal or none validation mecha-nisms.

3


20/79

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 thistool, can be transformed as-is or with minimal modifications. Modeldesign 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,OntoUMLandNSEare quite new technologies and are developedat 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 defines

UFOmodule for structural aspects(UFO-A) withUML profile for ontologicalmodelling(OntoUML). The graphic notation has been significantly extendedfor other Unified Foundation Ontology(UFO) varieties[3], but the core wasnot changed.

Normalized Systems Expander are fixed to version 2.3. It is the mostcurrent stable release and has the most documentation available. Some newfeatures and changes of the next version are already known. They are takeninto account, but do not directly affect any of the set goals.

1.3 Thesis Structure and Tasks

To reasonably cover topic of this thesis, following tasks were set. The finalstructure of this work is derived from this task list.

1. Provide an overview of utilized theories and technologies (Chapter2)

Introduce key concepts of Normalized SystemsandUnified Foun-dation Ontology

Describe essentials features ofNormalized Systems ExpanderandUML profile for ontological modelling(OntoUML)

2. Analyze OntoUML and Normalized Systems Expander (NSE) (Chap-ter3)

Explore expressive power of both instruments

Compare instruments with each other

Theoretically design a transformation method from OntoUMLdi-agram toNSE element descriptors

3. Create a prototype tool for convertingOntoUMLdiagram toNSE tem-plate (Chapter4)

ParseOntoUMLmodels created in one ofOntoUMLdesigners

4


21/79

1.3. Thesis Structure and Tasks

Generate syntactically correct code according toNSEspecifications

4. Prove the method design on a case study (Chapter5)

Demonstrate tools functionality on example domain model

Comment differences between theoretical and implemented method

5. Summarize successes and failures (Chapter Conclusion)

5


22/79


23/79

Chapter 2

Theoretical Background

2.1 Unified 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 ofentitiesandrelations.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. Geneontology for representation of gene and gene product attributes across allspecies [5]). On the other side are ontologies able to describe very generalconcepts shared across all domains. Those are calledtop-level ontologies(alsoknown asupper ontologiesor foundation ontologies). TheUnified FoundationOntology(UFO) is a representative of top-level ontologies.

2.1.2 UFO and OntoUML Synopsis

The Unified Foundation Ontology (UFO) is developed by Giancarlo Guiz-zardi and associates fromOntology 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 andCognitive Engineering(DOLCE) and OntoClean [2].

TheUFOmodule for structural aspects(UFO-A) have been formalized anddefined in Giancarlo Guizzardis Ph.D. thesis [2]. It features conceptual mod-elling constructs for structural definitions. Since it is in primary focus of thisthesis, it will be closely presented in section 2.2. Unified Foundation Ontol-ogy has been already extended to incorporate an extension for event-related

7


24/79

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].TheUnified Modelling Language(UML) is used for graphical representa-

tion ofUFO.Its profilemechanism[6]allows to extend the UML metamodelfor various purposes. The profile created for ontological modelling (OntoUML)is originally defined in[2]. It was later refined in [7] while creating aOntoUMLcomputer modelling infrastructure.

2.2 OntoUML Overview

This section provides very simplified overview ofOntoUMLnotation, within

extend ofUFO-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 considerUMLas fully assimilated base ofOntoUML. Conceptsfrom bareUMLare explained alongside those fromOntoUMLprofile withoutexplicit differentiations.

2.2.1 Classes and Entities

Classdescribes the common features (e.g. intrinsic and relational properties)shared by entities. Individual entity is instance of appropriate class. Theseterms common in conceptual modelling are equivalent touniversal(class) andindividual(instance) used inUFO terminology.

Attribute of a class represent property shared by members of a class. Allinstances must contain values for each attribute that is defined for that class,in accordance with the characteristics of the attribute (e.g. data type andmultiplicity).

Each class can be assigned to an object type depending on its ontologi-cal characteristics. This categorization is described in greater detail furtherin sections2.2.4and2.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 specializationchain.

The specialization relation is anti-symmetric (if A specializes B then Bcannot specialize A) and transitive (if A specializes B and B specializes C,then A specializes C).

8


25/79

2.2. OntoUML Overview

2.2.2.1 Specialization Sets

Specializations directing to one common superclass can be grouped into agen-eralization set. Such set can provide stronger semantics, because it can beartwo meta-attributes: disjoint and complete.

If a generalization set is disjointif all the subclasses participatingin the generalization are mutually exclusive. [2]

In other words: All instances of superclass can be instances of maximum of onesubclass.

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 oneof 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 superclassis 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 specified how many instances of itsclass can hold (cardinality). For possible cardinality notations see2.1.

Type-reflexiveassociations are associations with both ends connected to the sametype.

Multiplicity Alt. Notation Cardinality

0..0 0 Empty collection0..1 No instances or one instance

1..1 1 Exactly one instance0..* * Zero or more instances1..* At least one instance4..4 4 Exactly 4 instancesm..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 formthe implementation point of view:

9


26/79


derivedvalue can be computed from other information

ordered elements are sequentially ordered

uniqueeach value in the collection must be unique

read onlyonce the instance is assigned, it cannot be changed

2.2.4 Substantials

Substantials are entities that persist in time while keeping their identity (asopposed to events). It is similar to term objectintuitively 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}

Category

{disjoint}


PhaseRole


KindCollective

Anti-Rigid Mixin

Non-Rigid Mixin Rigid MixinRigid Sortal

{disjoint}

Sortal Universal Mixin Universal

Substantial Universal

Figure 2.1: Typology ofSubstantials

2.2.4.1 Sortal vs. Mixin Types

At the top level (see fig.2.1), types are categorized according to whether theyare endowed with object identity. The object identity enables to distinguish iftwo class instances are identical.

Objects endowed with identity are called Sortal types. The object typesPerson,ChairorTeacher are examples of Sortal types. All subtypes of Sortalinherit its identity via specialization chain.

Other types, that are not Sortal, are called Mixin types. Good exampleof Mixin types isRedObject when two red objects are perceived at differenttime, it is not possible to distinguish whether those two objects are identicalor not. Another examples may be SeatableItem or InsurableItem.

There are two postulates about Mixin types [8]:

10


27/79

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 bythe instances of M.

A Mixin type cannot be a subtype of a Sortal type. This is a consequenceof the fact that all subtypes of a Sortal type are again Sortal types sincethey inherit its object identity condition.

2.2.4.2 Sortal Types

The meta-propertyrigidityis used to distinguish different 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 Tin every world w. [2]

Anti-Rigidity:A type T is anti-rigidif for every instance x of T,x is possibly (in the modal sense) not an instance of T. In otherwords, if x instantiates T in a given world w, then there is a possibleworld 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, deckof cards, pile of bricks or pack of wolves).

Substance Sortals can be specializedSubKinds(e.g. Woman and Man arespecializations of Kind Person and inherit its identity principle).

2.2.4.4 Anti-Rigid Sortal Types

Anti-Rigid Sortalcan be specialized to a Phase or a Role.

Phaseconstitutes possible stages in the history of a Substance Sortal(e.g. Alive and Deceased are possible stages of a Person, Town andMetropolis development stadiums of a City). Phases implydisjoint andcompletemeta-attributes to their specialization set.

11


28/79


Roledepends on extrinsic (relational) properties of specialized Substance

Sortal. As intuitively perceived, an entity plays its role in specific con-text defined by interacting entities (e.g. Person is a Student in relationto some School and the same person could be a Customer in relationto some Shop).

2.2.4.5 Mixin Types

Mixin Universal can be specialized to a Category, a RoleMixin or a Mixin.Mixins are always defined 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, generalizingthe Role PersonalCustomer (which specializes a Person) and the RoleCorporateCustomer (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 typesto one entity (e.g. Mixin Seatable generalize Kind Chair and IceThronewhich is a Phase of Water).

2.2.5 Moments

Momentsare entities that they can only exist in other individuals they areexistentially dependent on their bearers. For example, electrical charge canexist only in some conductor.

Moments can be divided into Intrinsic MomentsandRelational Moments.

2.2.5.1 Intrinsic Moments

Qualityis a single- or multi-dimensional representation of a measurableproperty (e.g. weight, RGB color)

Modeis a representation of a non-measurable property, often used to de-fine state of a entity (e.g. issue of a book, translation of a document)

2.2.5.2 Relational Moments

Relational moment, called Relatoris a artefact attached to material relation-ship (e.g. a covalent bond, purchase order, business contract or flight betweentwo airports).

Relators are connected to both end entities of the material relationship(via mediation) and to the material relationship itself (via derivation).

12


29/79

2.3. Normalized Systems Theory

2.2.6 Parts and Wholes

The theory of parts and wholes is considered as a significant part of the foun-dational ontology. To maintain brevity of this section, this topic is consid-erably simplified. There exist many implications among parthood relationsand related meta-attributes, that are defined in UFO. Focus of this work isto deal with only effect of these implications, so the implications itself are notmentioned.

UFOdefines multiple parthood relations forming different types of aggre-gates:

SubQuantityOf for Quantities (e.g. alcohol wine)

MemberOf for Collectives (e.g. aSpecificTree theBlackForest) SubCollectiveOf for Collectives (e.g. theNorthPartOfTheBlackForest

theBlackForest)

ComponentOffor 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 meronymicmeta-attributes present at the relationship:

essentialpart cannot be changed without affecting 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. humanbrain cannot be separated from the body without losing its essence)

immutablepart/whole is part/whole with de-dicto necessity (e.g. boxernecessarily 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 bemember in several families; versus one engine can be part of only singlecar at time)

2.3 Normalized Systems Theory

Normalized Systems(NS) is a theoretical frameworkapplicable to design andengineer information system exhibiting proven evolvability. It aims at re-creating information technology based on defined laws for software evolvabilityin infinite 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


30/79


on this theory. NS is based on previous research on software architectures

by Herwig Mannaert and research on evolvability of conceptual and designmodels of information systems by Jan Verelst. [11]

NScurrently covers and redefines whole software development process andhas extends even to business process modelling. Because it highly exceedsscope of this thesis, following section will present only key features necessaryfor this work, i.e. features related software development.

2.3.1 Essential Principles

Normalized Systemsstate that contemporaryIT problems are manifestationsof fundamental flaws in currently used methodologies. The greatest vulnera-

bility lies in the evolvability of the IS. Adding functionality to existing systemgeneratescombinatorial effects, that lead to increase of system complexity (seefig. 2.2). Such effects cause increase of costs for future changes and decreaseoverall software quality [12]. This idea was first stated by Manny Lehmanin 1980:

As an evolving program is continually changed, its complexity,reflecting deteriorating structure, increases unless work is doneto maintain or reduce it. [13]

In spite of that,Normalized Systemstry to realize vision uttered by Dou-

glas McIlroy in 1968:

Expect families of routines to be constructed on rational principlesso that families fit together as building blocks. In short, [the user]should be able safely to regard components as black boxes. [14]

NSassume the change of the system to be natural and unavoidable phe-nomenon, therefore all principles and methodological elements are designed

Figure 2.2: Combinatorial effects explained[1]

14


31/79

2.3. Normalized Systems Theory

to respect that fact. The theory defines set of rules how to engineer theISar-

chitecture as structure of independent modules, which can be added, removedor changed. Sufficiently granular architecture will eliminate any combinatorialeffects during modification of the system.

The normalized design theorems prescribe strict separation of data and ac-tions manipulating such data. This segregation contradicts the essence ofOOprogramming, 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 ofNS. A proficient software developer will be familiar with these rules,because they are based on heuristic design knowledge. Value added by NSare theoretical proofs, that elevate these empirical experiences to defensibletheorems.

At the beginning, it is necessary to clarify several terms used in laterdefinitions:

Adata entity refers to a software entity that contains various at-tributes or fields, including links to other data entities. Therefore,a data entity only contains data (as in a structure or record) anddoes not have an interface.[1]

Anaction entityrefers to a software entity that represents an op-eration at a given modular level in a hierarchy.[1]

Ataskis part of an action entity and is a set of instructions thatperforms 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 identification and separation of every single task.Correct separation of tasks will induce separation of concernsin the big pic-ture.

This is a well known good practiceamong software architects, but it is alsovery general in its formulation. Current manifestations in software develop-ment include for examplemulti-tier architectures (MVC,MVVM,etc.) or useofintegration bus for inter-application communication.

15


32/79


2.3.2.2 Data Version Transparency

Data entities that are received as input or produced as output byaction entities, need to exhibit version transparency in normalizedsystems.[12]

Version transparency is instrument to cope with addition or removal a datafieldin entity. It implies encapsulation of the data fields. Wrapping the dataentity allows co-existence of various versions of such entity.

This can be easily implemented by usingget&setmethods and 0-parameterconstructor inOO programming.

2.3.2.3 Action Version TransparencyAction entities need to exhibit version transparency in normalizedsystems.[12]

Analogously to previous theorem, various versions of data entities needto 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 (undefined) state.When a state is kept for every call or instance of an action entity, the wholesystem behaves as a deterministic state machine. This eliminates the need forcomplicated recovery from undefined error states.

An example of manifestation of this design theorem is database transac-tion mechanism. The commit (rollback) action guarantees atomic transitionfrom one defined state to another. Another common example is asynchronouscommunication between systems.

2.3.3 Impacts on Software Development

In orderNSprinciples to be effective, therules of evolvabilitymust be strictlyobeyed. The system must be free of combinatorial effects 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 versiontransparencyrules also imply a lot of ballast (non-logic) code (e.g. wrapperclasses, accessor methods). For a human programmer writing code complyingwithNS is boring and frustrating.

16


33/79

2.4. Overview of Utilized Software Technologies

On the other hand,NS presents a set ofsoftware design patterns, that are

solution to these challenges. The design patterns (called elements) are de-fined comprehensively enough, that are suitable for code generation. The coreof created isis composed only from following elements:

a data element for storing data

an action elementfor the execution of a calculation or algorithm

a workflow elementfor the execution of sequences of action elements

a connector elementfor input and output functionality

a trigger elementfor 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 effects.

Element Composition Class inheritance may violate NS theorems, be-cause of following reasons:

Where member variables lead to an implicit and to some extenthidden 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 severalpossiblylargeexternal libraries or frameworks. Invoking an inherited methodresults in execution of apossibly largeset of instructions, havingaccess to a common set of member variables, and may result in apossibly largeset of initializations and allocations.[12]

For the purposes ofontological refinement, the principle of element com-positionis preferred. The the superelement is specialized by another elementwith simple connection of other element, instead of any dependence betweeneach other.

2.4 Overview of Utilized Software Technologies

2.4.1 OLED

OntoUML Lightweight Editor(OLED)[15]is an open source editor developedunder the supervision ofOntology and Conceptual Modelling Research Group(NEMO).

OLEDwas chosen for this work for several reasons. First, it has the richestOntoUMLandObject Constraint Language(OCL) editing capabilities among

17


34/79


other editors. Second, it uses thereference metamodeldefined by Roberto Car-

rareto in [7]. It is based on Eclipse Modeling Framework metamodel (ECORE)and is currently the most advancedOntoUMLinfrastructure[16]. This meta-model can be exported toXMLfiles (with .refontoumlextension) and easilymanipulated.

OLEDalso features model syntax verification, anti-pattern management,instances simulation via Alloy and model tranformation to OWL/SWRL andSBVR.

The editor is still in development and its use is quite experimental. Withrespect to production grade tools, OLED capable of importing models fromSparx SystemEnterprise Architect(EA). Developers also provideOntoUMLprofile for modelling directly inEA.

2.4.1.1 Using NSE

The software development life-cycle(SDLC) has been re-designed in the NSand 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 define the data-elements and the corresponding database model. This version should bea direct result of the expansion of the descriptors without any customi-

sation. At this phase the application is minimally configured.

2. Implement Business-rulesThe goal is to guarantee the data-quality re-quested by the end-user in the system.

3. Introduce user-friendlinessIntroduce the necessary user-friendliness. Thegenerated system gives the end-user the possibility to work with the ap-plication. The application provided after the previous phase requiresfrom the end-user a good understanding of the system (both function-ally as structurally).

Data model, as well as workflow definitions, are provided by descriptor

files. Descriptor file is simple XML or plain text document defining single NSelement (see2.3.3). The expanders generate skeleton source code from thesefiles, together with all deployment and configuration files required to constructa working application on selected technology stack.[17]

Alongside creating the application from users input, NSE provides pre-pared modules for common functionality used inIS (e.g. user accounts, inputfields validation).

18


35/79

Chapter 3

Analysis and Design

3.1 Comparison of OntoUML and NSE Concepts

This section provides and overview of OntoUML and NSE features fromthe methodological point of view. Then are both concepts compared to eachother.

3.1.1 OntoUML

OntoUMLprovides means to depict conceptualization of a real-world domain.Due to its ontological focus, it is implementation independent and conceptualmodels does not bear any implementation details. Its crucial features weresummarized in section2.2.

UFO-Aprovides information related only to structural definitions. Poten-tial utilizing OntoUML for workflow definition could be possible with UFOmodule 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 realizingNSelements expansiondeveloped by NSE bvba, Belgium.

Although the theory of element expansion in platform independent, theNSEis currently being developed for Java Enterprise Edition (JEE). Generated ap-plications are able to use all major databases. The framework is able to runon Linux, Windows and MacOS.

The generated application uses a web frontend, which is can be createdusing Knockout or Cocoon & Struts2 frameworks. Supported deploymentapplication servers are JOnAS, TomEE and Websphere.

19


36/79

3. Analysis and Design

3.1.2.1 Customizations

The generated application may need some modifications before deployingin production. As theNormalized Systems theory assumesIS to be changed,such change requires the whole source code to be regenerated. To preservecode modifications between regeneration of code, the harvesting mechanismis introduced.

While editing the generated source files, the modified code is put betweenspecial anchor marks. Before regenerating the application, the code embracedby those anchors is saved to special harvestfiles. After the new source codeis generated, the harvested modifications are injected back to its original lo-cation.

Developer performing the customizations must be aware of the NS designtheorems, to avoid creating combinatorial effects by his intervention.

3.1.2.2 Descriptors

Normalized Systems Expandercurrently recognizes several types of descriptorfiles, serving various purposes.

Data descriptor files of the Normalized Systems Expander describe pat-terns defined by Normalized Systems, alongside with many implementationdetails (e.g. database schema for persisting specific element, visualizationoptions, etc.)

The following types could be used for defining data model are analysed

in detail in section3.2.2:

application descriptor (.ad) for definition 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 files are used to define workflow(flow and task descriptor) or validating use input (value type descriptor).

3.1.2.3 Linking Mechanisms

NSEprovides following linking mechanism:

many-to-one in two variants, differing in implementations. May be usedat 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


37/79

3.2. Input and Output Files Analysis

3.1.2.4 Indirect Fields

Indirect field is an instrument to visualise contents of one element inside an-other. It is defined as a data field in the data descriptor.

It is stated by the developers, that the Indirect field mechanism will bereplaced in further versions ofNSE 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

CombiningOntoUMLandNormalized Systems Expanderis a clash of two ap-proaches. The implementation orientedNSEare pragmatic and tends to be as

simple as possible. The conceptual orientedOntoUMLstands on the oppositeside. It endeavours to be as descriptive as possible.

Instruments offered out-of-the-boxby are not able to cover the whole ex-pressive power ofNSE. Much valuable information will be lost primarily in as-sociation and part-whole relationship transformation (see3.3.2).

On the other hand, OntoUML in the extent of UFO-A can cover onlythe first step of the NSE development process (see 2.4.1.1), since diagramsinUFO-Aonly is capable of structural definitions.

Description of workflows may be possible withOntoUMLin extent ofUFO-B.But researching this issue is definitely out of scope of this work.

3.2 Input and Output Files Analysis

The following section describeOLEDand NSE file formats.

3.2.1 RefOntoUML file format

As it is a XML standart format, it is not necessary to analyse the structureverbosely. This section contains only noteworthy insights.

This file format contains all information about the whole model. Hence,it does not contain any information about graphical representation of the di-agrams.

Therefore graphical definition of generalization sets[2] cannot be derivedfrom this file format. The sets must be defined (also) as generalization setdata structure in theOLED,otherwise they will not be recognized.

3.2.2 NS Expander file formats

Descriptor files related to data model definitions were closely analysed forthe purposes of generation. Information provided is based on NSE userguides [18, 17] and clarified by communication with Paul Adriaenssens fromNSE bvba, Belgium.

21


38/79


Note that the analysis includes only those syntax constructs, that was

considered useful for further work.

3.2.2.1 Application Descriptor

style=

(...)

style=

component-

(...)

component-

optionDataBaseSchema-(...)

optionDataBaseSchema-

(testApp)

Short name of the application, which will correspond to the name of the ex-panded directory tree in the expansions applications folder.

(TestApplicatie)

Full name of the application.

style=

Styles of the presentation layer that will be generated.

component-

Enumeration of the different components that are used inside the application,both base and user-defined.

optionDataBaseSchema-

Optional database schema setting. is also optional in the lineitself; must be inserted in uppercase.

3.2.2.2 Component Descriptor

depends-(...)

depends-

MTM-

(...)

MTM-

(testComp)

Name of the component, which will correspond to the name of the expandeddirectory tree in the expansions components folder.[18]

22


39/79

3.2. Input and Output Files Analysis

(testElement1-view)

Specifies the default URL that will be invoked when clicking on the compo-nents menu in GUI. [18]

depends- (depends-account)

Indicates a dependency on some other underlying component.

MTM- (MTM-basisComp)

Indicates, that some elements from current component has many-to-manyrelationship with some elements in .

3.2.2.3 Data Element Descriptor

(...)

Ln[0-6]#

(...)

Ln[0-6]#

findBy_

(...)

findBy_

optionIndirect_

(...)optionIndirect_

(sitenet net.palver.uams Purchase)

Line defining data element name and location.

(sitenet)

The name of elements component.

(net.palver.uams)

Elements Java package name.

(Purchase)

Name of the element.

(productCode yny10 20 30 40 50)

Line defining a data attribute or field.

(String)

Name of used data type. SpecialNSEdatatypes must be used[17]ofr all datatypes. It also includes the Indirect for indirect fieldsmechanism.

23


40/79


Name of the attribute.

Ln[0-6]

(Ln01site.jar#net.palver.site.Site ynn)

Element link.

(site.jar)

Optional Java package name, if the linked element is located in another com-ponent.

(net.palver.site.Site)

Full java name of the linked entity.

Boolean value specifying attribute visibility inoverview screen.n: the attribute will be visible only in detailscreen of data element

Depracted in current version of NSE. Value will be neglected, but y ot n mustbe present.

Boolean value specifying whether attribute has enumerated values.y: list of possible values follow; Values are separated by (underscore)

symbol.

findBy

(findByNameEq YearGt)

Specifies which finder(search) methods will be generated. Name has to haveprefix findByfollowed by name of searched attribute and modifier.Modifier can currently assume values:

Eq: equal toGt: greater thanLt: less than

Multiargument search methods are possible by chaining several pairs (at-

tribute and modifier) separated by (underscore) symbol.

optionIndirect

(optionIndirectperson net.palver.person.Person)

(person)

Name of the Indirect data field.

(net.palver.person.Person)

Full Java name of the inserted element.

24


41/79

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 defined at all.Therefore no existing methodology can be used as example. The successof the conversion of the conceptual model of the implementation dependsentirely on the experience of implementer.

0..* 0..*

parks a t ParkingPlaceCar

Figure 3.1: Ambiguous relationship in conceptual model

Information necessary for implementation can be different from the infor-mation provided by conceptual model. This can be illustrated with followingexample: Figure3.1 represents a relationship in a conceptual model: unspec-ified number of cars park at unspecified number of parking places. The figure3.2shows possible implementations of this relationship: when creating a bookof 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 carsparked at the given place. In some cases, both records should be kept.

ParkingPlaceCar

ParkingPlaceCar

ParkingPlaceCar

Figure 3.2: Examples of relationship interpretation

Transformation method in this thesis is designed to cover the majorityof possible cases. When a ambiguous situation appears, it is preferred to haveexcess rather than lacking. If necessary, the generated code could be sim-ply modified. And deleting line of code is easier operation than generatinga proper one.

25


42/79


3.3.2 Proposed Transformation of OntoUML Phenomena

This method is the key concept and contribution of this work. It coversall 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 offer any other object-likeelement.

Object inheritance(generalizaitonspecialization relationship) is covered

in section3.3.3.2.

3.3.2.2 Associations

Associations are transformed toNSElinkmechanism. Some special cases wereidentified 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 tables3.3,3.2, 3.1 and respective paragraphs.

The name of theOntoUMLrelationship is used as the name ofNSElinkfield. This guarantees that naming collisions among the links will be avoided.Because, by definition in[2], all model elements must have unique names.

By default,NSElinks does not require any element to be connected. To ac-complish mandatory connection end (mandatory element), code customizationis necessary. Implementer will by notified about these necessary customiza-tions by comments in descriptor files.

In general, it is not recommended to enforce creating link at instantiationof the element. This may cause unsolvable situations if this mechanism is usedon both sides. Safe solution is to verify presence of the connected element atthe 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 specific rules:

1. In case the many to many link is between two components, link tothe othercomponent (e.g. MTM-targetComponent) must be mentionedin component descriptor.

2. There is a field name restriction at the Ln03 side:

26


43/79


the name of the Ln03 field needs to be identical to the name

of the element where the corresponding Ln06 link is specified fol-lowed by the character s (e.g. Ln03be.provant.basis.Materiemateries nyn)[18]

one-to-many (Table3.2)NSE provides two one-to-many/man-to-one link-ing mechanismsout-of-the-box. From the users point of view, they act equally.Bu they differ in implmentation:

1. Ln02-Ln04 pair is container managed relationship. Because of this, it isnot able to connect entities from different components.

2. Ln01-Ln05 pair is managed byNSE itself. Therefore, it is able to makeinter-component links and is generally more versatile. This pair waschosen to be implemented.

one-to-one (Table3.3) Two possible conversions were designed, both withpros 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 Ln03s

1..* 0..* Ln06p Ln03s

1..* 1..* Ln06p Ln03p, s

p mandatory elements restricted field 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 Ln041..1 0..* Ln01p Ln05 Ln02p Ln040..1 1..* Ln01 Ln05p Ln02 Ln04p

1..1 1..* Ln01p Ln05p Ln02p Ln04p

p mandatory element

Table 3.2: Conversion of one-to-many associations

27


44/79


OntoUML NS Expander alternative

end A end B end A end B end A end B0..1 0..1 Ln01 Ln01 Ln01 Ln05o

1..1 0..1 Ln01p Ln01 Ln01p Ln05o

1..1 1..1 Ln01p Ln01p Ln01p Ln05p, o

p mandatory elemento maximum of one element

Table 3.3: Conversion of one-to-one associations

sides. Nevertheless customization on both sides would be necessaryto enforce mutual linking. Although, this approach is considered most

elegant and will be implemented.

2. (column alternative) May be used when mutual linking (managed byNSE) is preferred. This uses many-to-onerelationship, where mutualityis assured byNSE. Customization is necessary on single side (maximumof one element), to allow maximum of one element.

Metaatribudes of association ends:

derived is considered as irrelevant to implementation.

ordered, unique, read onlycould not be utilized by any means providedbyNSE framework. To utilize this metadata, customization of the gen-erated code must be performed. Implementer may be notified aboutpresence 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-wholerelationships are considered as plain associations and transformed in samemanner decribed in3.3.2.2.

Meronymic metaatributesessential,inseparable,immutable,shareablecouldnot be utilized by any means provided by NSE framework.

3.3.2.4 Data Attribute Fields

Single valuedata attributes field are simply transcribed to the syntax of datadescriptors.

Multiple values attribute fields are, in common programming languages,solved by a containing data structure (e.g. an array). Since theres no suchthing inNSE, the proposed solutions is to create a separate data descriptorcontaining a single value data attribute and link the via one-to-may links.

As the multiple values attribute is equal

28


45/79


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 theNSE.

3.3.3.1 Qualities

Qualities are, because of its dependence on the bearer, transformed in differentmode.

In case the quality is connected by one-to-one relationship, the instancecan be accessible directly using the indirect fields mechanism. Otherwise itslinked 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 ofelementcompositionprinciple described in section2.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 fields do not visualize indirect fields of other elements. The followingsolutions are proposed:

1. Recursively scan the generalization chain and the specialization chainform the current element and visualize all found generalized / specializedelements directly in the current element.

2. Allow parametric definition (at application level) how many levels canbe scanned and visualised.

3. Visualize only the directly generalized / specialized elements.

The fist two solutions would require a lot of runtime constraints, to assurethat no element in the chain is skipped. For example in chain sparrow

bird animal creation of sparrow animal without instantiation of the birdmust be forbidden. Also the fist solution can cause entities grow to enormousdimensions, 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 field can contain only single instance of element. But can beconfigured to fit several different element types. This feature can be utilizedin realization of the generalization set metaattributes.

29


46/79


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 leftside of figure3.3 is used. It will allow both specialization to be instan-

tiated. {complete} The left mechanism is used, but implementer must be no-

tified about disabling instantiation of the bare superelement.

{disjoint} The right mechanism is used. This solution is more orless 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 beconnected 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 defini-tion ofNSE,even though much auxiliary information will be lost.

It was possible to design the method to be executed without any humanintervention 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 structuraldefinitions. Their possible utilization for workflow is questionable and outof scope of this work.

Conceptual model could provide integrity constraints exceeding theUML,that are not utilized right now. OLEDallows defining rules via Object Con-straint Language(OCL)[19]. After examining the expression power ofNSE,such rules would have to be realized via code customizations.

30


47/79

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). Althoughconceptual models (by their nature) will never provide this information, it canbe 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 willbe written to descriptors as comments. A file summarizing all the proposedcustomization will be created for comfortable overview of necessary changes.

31


48/79


49/79

Chapter 4

Prototype Implementation

4.1 Basic Concept

Program simply transforms input text files to output text files, without anyuser intervention during the process. Therefore it is realized as a commandline tool.

Application is designed using the object-oriented paradigm. Although the-matic focus of this work isNormalized Systemstheory, it serves only as a looseinspiration 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 first authors encounter with NS, itwould be a very bold to state that the program complies with all the desiredrequirements.

Java was chosen as implementation language, because of rich string ma-nipulation capabilities, overall ease of use and multi-platform support. It isalso the programming language ofOLEDand some components ofNSE, thuspotential integration into those present tools would be straightforward.

4.2 Internal Structure

Application is composed of the main data model skeleton and supportingclasses.

The data model skeleton is a hierarchy of classes imitating theOntoUMLentities. It is able to read information from given XML document and printitself toNSE files.

The other packages contain supporting classes, that are responsible forservice tasks (e.g. run control, logging, parsing application configuration file,writing files to file system).

33


50/79

4. Prototype Implementation

4.2.1 Data Model Specification

Class hierarchy is based on taxonomy of ontological entities described in [2].Model used in the application is adapted from graduation thesis of RobertoCarraretto [7]. Carrarettos model is used for defining the RefOntoUML.Because OntoUmlDistiller use the model in slightly different way, its structurehad to be changed. Most significant differences are mentioned in this text, butmany minor changes (e.g. renaming data properties) are omitted.

Java package cz.cvut.fit.bp.ontoumldistiller.modeland its subpack-ages contain the code of whole data model. Top level of this package containsthree classes:

DataModelis the main standalone model class; registers all components,

entities and application settings (via AppSettings class)

DataModelComponentregisters 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 figure 4.2.1).(Carrarettos model[7] does not define such super-entity.)

GeneralizationEntity

ElementEntity

RelationshipEntity

DataTypeEntityDataModelEntity

Figure 4.1: Direct descendants of DataModelEntity class

This abstract root entity implements two interfaces: RefOntoUmlParsing(for parsing RefOntoUML XMLdocuments) and Nse23Writing (for writingNSEv2.3 descriptor files). Implementation of interface methods can be foundat descendants. Utilising polymorphism, method implementation is simplyoverridden where is more specialization necessary. Interfaces also improvesoverall structure of code. Prospective functionality can be added as anotherinterface, while keeping the code tidy.

DataTypeElement and GeneralizationElementare concrete class and arenot further specialized. TheElementEntityand RelationshipEntityramify

34


51/79

4.3. Configuration File

Moment

Mode

Relator

Mixin

RoleMixin

SemiRigidMixin

AntiRigidMixin

CategoryRigidMixin

NonRigidMixin

MixinUniversal

Role

Phase

SubKindCollective

Quantity

Kind

SubstanceSortal

AntiRigidSortal

RigidSortal

SortalUniversal

ElementEntity

Figure 4.2: Hierarchy ofelement classes

to large trees depicted in figures 4.2.1and4.2.1. Abstract classes are plottedwith white background, concrete classes with gray.

Association

Derivation

Formal

Material

Mediation

Characterization

ComponentOf

MemberOf

SubCollectionOf

SubQuantityOf

DependencyRelationship

Meronymic

DirectedBinaryAssociation

RelationshipEntity

Figure 4.3: Hierarchy ofrelationship classes

In Carrarettos model [7], moments (from figure 4.2.1) are independentgroup. In this model are placed under the ElementEntity, because theyexhibit object characteristics and are treated as objects in further processing.

4.3 Configuration File

Along the RefOntoUML files, it is necessary to provide XML configurationfile to the application. The settings can be divided into two groups.

35


52/79


4.3.1 Application Control Settings

Several settings control the behaviour of OntoUmlDistiller itself and does notaffect the content of generated descriptor files. These settings include: loglocation, logging level and location of the destination folder for generatedfiles.

In the root folder is created the data descriptorand another folders, bear-ing the name of each component. Into these componentfolders are generatedthe respective component descriptors and data descriptors.

There is also option to write summary of all customization notes to onefile, for comfortable overview of necessary changes.

4.3.2 Model Complementary InformationAnother group of settings contains supplementary information for the gen-erated data structures, that cannot be captured in the model files, but arerequired for proper generation of the descriptor files. This data include: sup-ported data types, generated applications Java package, short applicationname and full application name.

4.3.3 Data Types Definition

Data types could be defined in two ways: basic data types and enumerateddata types. The basic ones are defined only by their names. These should

correspond to those supported by the underlying framework used by the NSE.The enumerated data type is defined by its name, representation and enu-

meration values. Representation value must be one from the basic data typeslist (ergo one of the types supported byNSE framework).

During the parsing process are data elements attributes compared to namesof supported data types. When no match is found, the application reportsan error and exits. Representation values of the enumerated types are testedin the same manner.

4.4 Formal Grammars of Generated Files

All output files are generated by their respective grammars presented in thissection. Notation usesExtended BackusNaur Form(EBNF) syntax definedin [20]. The special sequence symbols (?...?) are used for describing dataextracted from the applications model. EOLis a terminal symbol representingend-of-line.

36


53/79

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


54/79


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, comparatorsuffix, 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


55/79

4.5. Application Usage

4.5 Application Usage

This section roughly describes how the OntoUmlDistiller is used. Completeuser guide is located in appendixB.

Converting OntoUMLmodels consists of the following steps:

1. Data models prepared in OLED must be saved as RefOntoUML. Onediagram file will be transcribed into one NSE component. The nameof file without the .refontouml extension will be used as componentname.

2. Configuration file has to be adjusted. Attention should be given espe-

cially to the definition 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

...

Linking among diagrams is possible using the :: operator; for examplecomponent1::SomeElement will be resolved to element named SomeElementfrom file 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 identifies by their names, hence creating two componentswith same name will result to a fatal error. This unique names rule complywith essential OntoUML principles [2]. Nevertheless, the OLED does notverify this rule, so uniqueness is not guaranteed even inside single componentmodel.

39


56/79


57/79

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 informationsystem, but to comprehensively verify the proposed method on a sufficientlycomplex example.

Problem domain model was adapted from [2] and contains all UFO-Aphenomena. It was divided to four components. For specific testing purposes,several many-to-many inter-component relations were added. Model was also

enhanced with a sufficient number of data fields to test data fields conversion.Adapted component diagrams are included in Appendix C.

5.2 Execution Environment

Conversion ofRefOntoUMLfiles (included on attached CD) was accomplishedaccording to user guide (AppendixB). Java Runtime Environment version 1.7was used.

Expansion of the generated descriptors was executed by Paul Adriaenssensat the NSE bvba in Belgium. The Normalized Systems Expanderversion 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 insufficien-cies in prototype features. Provided feedback was incorporated into the pro-totype tool. Errors were fixed, necessary functionality implemented. Therewas also a change in transforming the one-to-one links: TheLn01-Ln01mech-

41


58/79

5. Case Study

anism was reconsidered as more elegant and therefore preferred (see 3.3.2.2).

Next expansions helped to iteratively fix all errors.The last run of expansion was syntax error free. By this, the final 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 AppendixCfor comparison with theOntoUMLdiagrams.Note that the indirect linkmechanism is not shown in the diagrams.

Expansion logs provided by the developers are included on the attachedCD (see sectionE).

42


59/79

Conclusion

Evaluation of Goals

Design a theoretical method transforming OntoUML diagrams to NSEelement descriptors.

Accomplished transformation method has been proposed for all On-toUMLphenomena. The proposed transformation were discussed. Whenseveral transformation methods were available, the chosen solution wasargued.

Create a prototype tool implementing designed method.Accomplished the prototype tool was implemented in quality sufficientto perform a case study test. And hence prove proposed theoreticalmethod.

Demonstrate method and tool functionality onOntoUMLdomain model.

Accomplished as the last expansionwas error free, the case study canbe considered as successful. It also proves, that the previous two goalswere formally correct.

Thoughts on Method Utilisation

Presented conversion method is definitely not bulletproof. Case on largerreal-world cases could reveal weak spots from the users point of view.

Without direct access to theNormalized Systems Expander(NSE), eval-uation of the user experience is impossible. I would be also impossible toachieve this in the time frame of this the bachelors thesis. Therefore is the

formalcorrectness satisfactory goal and a solid base for further development

Obstacles, that were experienced during creation of this thesis, may serveas input for improvements of the Normalized Systems Expander(NSE). The

43


60/79

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 butnot in the dry theory. Now, the method must be used, discussed, evaluatedand improved again and again. It should keep pace with the two bleeding-edgetechnologies, between which is stretched. Hopefully, after enough evolution,it would form into a solid bridge.

During the development, even specific objectives were daydreamed. Forexample, if theNSEdevelopment will head toontological 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 benefit would be thatuser can convert conceptual to implementation model in the GUI. He could seethe visualized implementation draftand even customize it to suit his needs.Then, with a click of a button, the application would write well prepared datadescriptors.

Another undoubtedly useful feature is iteration modelling. It would al-low user to preserve changes made to the generated descriptor files whilere-generating the model by the application. Similar problem is solved byhar-vesting + injection in the NSE framework. This mechanism may serve as

a good example.

44


61/79

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 aCommitment-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 Handbookon Ontologies, edited by S. Staab; R. Studer, International Handbookson 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. D440D444, 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 Unified 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
http://dx.doi.org/10.1002/spe.1051http://dx.doi.org/10.1002/spe.1051http://dx.doi.org/10.1002/spe.1051http://dx.doi.org/10.1002/spe.1051http://dx.doi.org/10.1002/spe.1051http://dx.doi.org/10.1002/spe.1051http://dx.doi.org/10.1002/spe.1051http://dx.doi.org/10.1002/spe.1051http://dx.doi.org/10.1002/spe.1051http://doc.utwente.nl/50826/1/thesis_Guizzardi.pdfhttp://doc.utwente.nl/50826/1/thesis_Guizzardi.pdfhttp://doc.utwente.nl/50826/1/thesis_Guizzardi.pdfhttp://doc.utwente.nl/50826/1/thesis_Guizzardi.pdfhttp://doc.utwente.nl/50826/1/thesis_Guizzardi.pdfhttp://doc.utwente.nl/50826/1/thesis_Guizzardi.pdfhttp://doc.utwente.nl/50826/1/thesis_Guizzardi.pdfhttp://doc.utwente.nl/50826/1/thesis_Guizzardi.pdfhttp://dx.doi.org/10.1007/978-3-540-92673-3_0http://dx.doi.org/10.1007/978-3-540-92673-3_0http://dx.doi.org/10.1007/978-3-540-92673-3_0http://dx.doi.org/10.1007/978-3-540-92673-3_0http://dx.doi.org/10.1007/978-3-540-92673-3_0http://dx.doi.org/10.1007/978-3-540-92673-3_0http://dx.doi.org/10.1007/978-3-540-92673-3_0http://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.abstracthttp://nar.oxfordjournals.org/content/36/suppl_1/D440.abstracthttp://nar.oxfordjournals.org/content/36/suppl_1/D440.abstracthttp://nar.oxfordjournals.org/content/36/suppl_1/D440.abstracthttp://nar.oxfordjournals.org/content/36/suppl_1/D440.abstracthttp://nar.oxfordjournals.org/content/36/suppl_1/D440.abstracthttp://nar.oxfordjournals.org/content/36/suppl_1/D440.abstracthttp://nar.oxfordjournals.org/content/36/suppl_1/D440.abstracthttp://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/http://nar.oxfordjournals.org/content/36/suppl_1/D440.abstracthttp://nar.oxfordjournals.org/content/36/suppl_1/D440.abstracthttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://nar.oxfordjournals.org/content/36/suppl_1/D440.full.pdf+htmlhttp://dx.doi.org/10.1007/978-3-540-92673-3_0http://doc.utwente.nl/50826/1/thesis_Guizzardi.pdfhttp://doc.utwente.nl/50826/1/thesis_Guizzardi.pdfhttp://dx.doi.org/10.1002/spe.1051


62/79

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

Documents

Applying OntoUML for structural definitions of Normalized Systems Expanders