Faculty 3: Mathematics and Informatics

Database Systems Group

Master Thesis

Extending Flow-Flow-Flow with

Part-whole-Relationships and
Inheritance

Cyrille Armelle Jike Namegni([email protected]),

Larousse Landry Doumbe Degrandow([email protected])

Matriculation No. 3066567

Matriculation No. 3073527

31. March 2020

First referee: Prof. Dr. Martin Gogolla

Second referee: Dr. Sabine Kuske
Declaration
We hereby declare that we have prepared the present work independently, have not submitted
it for audit purposes elsewhere and have not used any aids other than those indicated. All
deliberately used text excerpts, quotations or contents of other authors were expressly marked
as such.

Bremen, den 31. March 2020

Cyrille Armelle Jike Namegni([email protected]),

Larousse Landry Doumbe Degrandow([email protected])

2
Danksagung

3
Abstract
Flow-Flow-Flow is a concept in modeling designed to improve the developer’s design task through
the ”object to class” tool. The tool is a plugin integrated in a much bigger scope tool call USE
(UML Based Specification Environment). This thesis deals with the improvement of the plugin
in order to extend the multiple possibilities that the Flow-Flow-Flow concept has offered until
now. A quantitative study has been conducted to provide elements of response on the usability
of the new functionality developed during this research work. The study allowed us to obtain
many criticisms to be taken into account regarding the lack of functionality such as keyboard
shortcuts which are unfortunately still absent. Nevertheless, the Plugin Object to class obtained
a very good average score from a survey based on UMUX (Usability Metric for User Experience).

4
Contents

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
1 Introduction 1
2 Technologies and Previous Research Work 3
2.1 Unified Modeling Language (UML) . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1.1 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1.2 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1.3 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1.4 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Object Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Java 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Swing (Java) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 USE : UML-based Specification Environment . . . . . . . . . . . . . . . . . . . . 12
2.3.1 The Object to Class Plugin (O2C) . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1.1 Flow-Flow-Flow : From (imperfect) object Diagrams to (imper-
fect) class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Requirements and Practical Examples 17
3.1 Aggregation in O2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1 “Add an Aggregation Link” . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.2 “Edit an aggregation Link” . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3 “Delete an Aggregation Link” . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.4 “Transform Aggregation Links into Aggregation association” . . . . . . . 19
3.1.5 “Merge similar Aggregation Link” . . . . . . . . . . . . . . . . . . . . . . 20
3.1.6 ”Recognize and inform user for design (regarding UML) errors” . . . . . 20
3.2 Composition in O2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 “Add a Composition Link” . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 ”Edit a Composition Link” . . . . . . . . . . . . . . . . . . . . . . . . . . 24

i
 3.2.3 ”Delete a Composition Link” . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4 “Transform Composition Links into Composition association” . . . . . . . 25
3.2.5 “Merge similar composition link” . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.6 “Recognize and inform user for design (regarding UML) errors” . . . . . 26
3.3 Inheritance in O2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 “Collect information on the superclass” . . . . . . . . . . . . . . . . . . . 31
3.3.2 “Report the presence of Superclass” . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 “Assemble the subclasses and their corresponding superclasses during the
transformation” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.4 ”Recognize and inform user for design (regarding UML) errors” . . . . . . 32
3.3.5 “Link the superclass and the subclass through inheritance relationships
after transformation” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.6 “Organization of attributes between the superclass and the subclass” . . . 34
4 Use Cases of the System 45
4.1 Use case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Use case model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 Concepts 53
5.1 Changes in the Transfomation concepts . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.1 The new General Structure of element . . . . . . . . . . . . . . . . . . . . 53
5.1.2 Status of Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.3 The input Object diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.4 The output Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Regarding the Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.1 From Object to Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.2 The Creation of the Generalization Relationship . . . . . . . . . . . . . . 59
5.2.3 From Links to Associations . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6 Implementation 63
6.1 Parts of the Plugin and their new Features . . . . . . . . . . . . . . . . . . . . . 63
6.1.1 The Meta Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1.2 Input Object Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1.3 Output Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7 Usability Study 73
7.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2.1 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

ii
 7.2.2 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.3 Result and Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8 Conclusion and Future Works 79
A Appendix 81
A.1 List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.2 List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
bibliography 85
B Evaluation sheets 89

iii
Chapter 1

Introduction

Software must be easy to use or produce the expected results without forgetting the ergonomics
of its interface. These are the most important characteristics of a good software according to
the users[LR06]. Beyond these general criteria, the specific requirements of each software design
must not be neglected. The latter being an integral part of the specifications.
“Object to class” is part of this perspective in order to offer any user the possibility to easily
create or design imperfect or incomplete class diagrams based on an imperfect or incomplete
object diagram[And18a]; It will also be nicknamed “Flow Flow Flow” in reference to the fluidity
and freedom of expression of ideas1 .
In 2017 as part of his master thesis Andreas K.2 implemented under the supervision of Professor
Martin Gogolla, the first version of the plugin we call Object to Class. This tool allows the
practice of the concept mentioned above and operating under USE (UML-based Specification
Environment)2.3 a tool for model specification and validation. This plug-in has been developed
in Java and allows the user to model an information system via a graphical interface, but this
time from an object diagram (incomplete or imperfect). To do this, it is necessary to link
previously created objects, which is only possible via a direct or indirect connection. With direct
connection we means for example binary Link and with inderect Connection we mean for example
class name.
Within the framework of this research work, it will be necessary to allow a more in-depth use
of this tool (Object to class) through the development of various other possibilities guaranteeing
the connection between objects while respecting the principles and requirements that the concept
of “Object before class” [And18b] advocates. The purpose of this Work is to determine if our
models or results obtained from (imperfect or incomplete) object diagrams approach or coincide
with the initial idea that any user was relying on his Model.
With the help of a quantitative study we will analyze the different results obtained from a group
of users with a more or less advanced knowledge on model design.

1 This nickname was given by Pr. Martin Gogolla.

2 ”On the Transformation from Incomplete Object Diagrams to Incomplete Class Diagrams”, by Andreas Kaestner.
2017

1
The content of this work is organized as follows. Chapter 2 we will introduce the technologies,
the theoretical bases and especially the previous works that allowed us to initiate this work.
Then in chapter 3 we will define and describe the requirements related to the implementation of
the new functionality in order to set the milestones for the programming work. Then Chapter 4
will describe the use cases of the Plugin after integration of our work. Chapter 5 will focus on
the different axioms that need to be put in place before implementation, which will be described
in Chapter 6. In Chapter 7 we will evaluate the new Plugin in order to highlight possible
improvements and possible future works that will be detailed in the conclusion.

2
Chapter 2

Technologies and Previous Research Work

This chapter describes the relevant technologies and knowledge to build a foundation for the the-
sis. We are going to give a clear definition of UML, Class Diagram, object diagram, Association,
Aggregation, Composition, and Inheritance , then a presentation of the Programming languages
used in the thesis, and finally a presentation of USE and the Plugin O2C.

2.1 Unified Modeling Language (UML)

UML aims to standardize the modelation of software systems and was first published in Novem-
ber 1997 by the Object Management Group (OMG).
“The initial versions of UML (UML1) originated with three leading object-oriented methods
(Booch, OMT, and OOSE), and incorporated a number of best practices from modeling lan-
guage design, object-oriented programming, and architectural description languages. Relative to
UML1, this revision of UML has been enhanced with significantly more precise definitions of its
abstract syntax rules and semantics, a more modular language structure, and a greatly improved
capability for modeling large-scale systems.” [Gro]
UML is a graphical and textual modeling language designed to understand and define needs,
specify and document systems, sketch software architectures, design solutions and communicate
points of view.
UML allows a modelisation of the data and their processing using the different diagrams.
UML 2.4 provides diagrams that can be used in the description of a system. These diagrams are
grouped into two main groups:[uml]

1. structure diagrams :
These diagrams represent the static aspect of a system.
2. behavior diagrams :

3
2.1. UNIFIED MODELING LANGUAGE (UML)

These diagrams represent the dynamic part of a system that reacts to events and produces
the results expected by users.

The overview of UML 2.4 diagrams is presented below.

Figure 2.1 UML 2.4 Diagrams Overview. Source: [uml]

The sub-chapter describes two diagrams: the class diagram and the object diagram. In addition
other elements such as association and part-whole relationships are presented.

4
 CHAPTER 2. TECHNOLOGIES AND PREVIOUS RESEARCH WORK

2.1.1 Class Diagram

“The class diagram models the static of a System, its properties and relationships to each other
and represents the central concept of UML ”[Chr17a]. A class diagram is defined as a collec-
tion of static model elements that shows the structure of a model. As a collection of static
modeling elements there classes, packages, interfaces, relationships and instances such as objects
and links. The classes are linked together by associations. “A class defines the properties and
behavior of a collection of objects. The properties of a class are described by attributes and
associations. As far as behavior is concerned, it is described as operations”[Bal17]. Attributes
are structural properties of a class. An Association is a logical relationship between two classes
(binary association) or more (n-ary association) which defines a set of links between objects in
these classes.“Operations specify the services offered by a class” [Chr17b].
To provide a clearer explanation of the class diagrams we will present the Social Network
[Gog17a] Model implemented by Pr. Martin Gogolla. The Social Network allows the Creation
of a Profile that can be interested in Subjects, furthermore a created Profile can send or
receive invitations for a Friendship. In addition, the Friendship can be accepted or refused.
The Profile can create a Posting and comment on the Posting.
The class diagram Social Network consists of :

• the class Profile has the attributes firstN, lastN,UserN and /initials. These At-
tributes represent here respectively the family name, first name , user name and initials
of the Profile. As Operations we have:
– init( aFirtsN:String, aLastN:String, aUserN:String) which allows to initialize the at-
tributes of the Profile Class.
– invite(anInvitee : Profile) which allows the Creation of friendship between two
profiles.
– accept(anInviter: Profile) which allows a Profile to accept a friendship invitation
from another Profile.
– decline(anInviter: Profile) which allows a Profile to refuse a friendship invitation
from another Profile.
– publish(aPostText: String):Posting which allows a Profile to publish.
– comment(aPosting : Posting, aComment : String) which allows a Profile to com-
ment on Publications.
– friends():Set(Profile) which allows you to modify a Profile.
– friendship(anInviter : Profile) : Friendship which allows to know the Friend-
ship Status( acceptF or declinedF between Profiles.
• the class Posting has only one Atrribut posting. This Attribute saves the publication of a
Profile in the Social Network system.
• the class Subject has for attribute subject and this attribute represents the topic a profile
is interested in.

5
2.1. UNIFIED MODELING LANGUAGE (UML)

• the association class Friendship between Profile and Profile has one attribute status,the
operations acceptF() and declineF(). Furthermore this association class has the role
names invitee ,inviter with the multiplicities “0..*” and “0..*”
– The attribute Status serves the state of friendship between profiles.
– The operations acceptF() and declineF() each allow the acceptance and rejection of
a friendship between profiles.
• The association class Commenting between Profile and Posting has an attribute comment,the
role names commenter ,commented with the multiplicities “0..*” and “0..*”.This attribute
contains the comment of a profile on a publication.
• The association Interest between Profile and Subject has the role names profile and
subject and the multiplicities “0..*” and “0..*”.
• The composition PosterPosting between Profile and Posting contains the role names
poster and posting and the multiplicities “1” and “0..*”.

Other elements of the class diagram such as inheritance and weak part-whole relationship (aggre-
gation) have not been used in the “Social Network” class diagram,but will be clearly explained
in sections 2.1.1.2 and 2.1.1.4

2.1.1.1 Association
An association represents the relationships between different two classes [Oes09]. An association
is represented in the form of a line between classes. In addition, the association contains a name,
multiplicity, and role name. However, there are other specific types of associations namely
aggregation and composition which will be defined in the following sections. The following is an
example of the classes and associations.

Multiplicity is defined as the number of objects likely to occupy the position defined by the
association termination. In the Example Classes in Association two multiplicity is mentioned:

1. several : * or 0..* : That means that a Profile may have an interest in zero
or more Subject.
2. several : * or 0..* : That means that a Subject can be of interest to zero or
more Profile

Role names describe the meaning of the Classes involved in their Objects in more detail. In this
case profile and subject are used for the classes Profile and Subjects respectively.As an
association Name we have Interest.

6
 CHAPTER 2. TECHNOLOGIES AND PREVIOUS RESEARCH WORK

Figure 2.2 Social Network class diagram. Source:[Gog17a]

2.1.1.2 Aggregation
This name is representative of a binary family of association, namely “Part-whole Relationship”.
It is divided into two types according to their characteristics:

• Shared aggregation or Aggregation

• Composite Aggregation or Composition

A shared aggregation (or aggregation) is a binary association and represents a specific kind
of “ part-whole relationship”. This Form is used when the part is independently linked to its
composites or sets [Gog09].
An aggregation is generally represented by a hollow diamond very often called a white diamond
at the end of the line of a simple association, which should not be confused with that of a larger
N-aires relationship.
The characteristics of a shared aggregation are summarized as follows [Gro]:

• binary association

7
2.1. UNIFIED MODELING LANGUAGE (UML)

Figure 2.3 Classes in Association

Figure 2.4 Objects in Association

• whole/part relationship
• Shared- A part can be linked to as many composite instances as possible, and if these are
deleted the property can still be used.
• it is transitive (or acyclic)- aggregations must form direct acyclic graphs so that no composite
can be indirectly or directly a part of itself
• Asymmetric- there’s only one part of an association that can be an aggregation

The example in the following Figure 2.5 shows a quadrillator as an aggregation of exactly four
dimensions. Each segment can be a part of another square or not belong to any quadrillator, so
use a star “*” as multiplicity.

Figure 2.5 Aggregation in UML

2.1.1.3 Composition
An aggregation composite or composition is a binary association that defines a stricter rela-
tionship between a whole and a part, which is why it is referred to as the “strong” form of
aggregation. [Gog09]
A composition can be recognized by its solid diamond (also called black diamond) which is at-
tached to the owning component. The composition points to the class/object which belongs to

8
 CHAPTER 2. TECHNOLOGIES AND PREVIOUS RESEARCH WORK

the owner. the characteristics of a composition are summarized as follows[Gro]:

• binary association
• whole/part relationship
• a part can only be contained in at most one whole at a time
• it is transitive or acyclic. Aggregations relationship must form direct acyclic graphs so that
no composite can be indirectly or directly a part of itself
• it’s asymmetric- there’s only part of an association that can be a composition

The Figure 2.6 shows a tree leaf as an exclusive part of a tree. Since Each leaf can be found in
nature without a tree, this time we will note as multiplicity “0..1” instead of 1.
Two characteristics (acyclic, sharing) will come back later in the work.The table 2.7 summarizes

Figure 2.6 Composition in UML

these properties for an association, aggregation and compositionGogolla2009

it

Figure 2.7 Summary on the characteristics of an association, aggregation and compositon in

UML [Gog14] (Aufruf: 29.11.2019)

2.1.1.4 Inheritance
Inheritance also known as Generalization/Specialization in UML, is represented by an arrow with
an empty triangle. This indicates the superclass or the more generalized class. At the other end
of the relationship we have the specialization classes or subclasses [Gro]. Generalization is also
considered as an “is a kind of” relationship. We will therefore say one thing (like the class Car)
“is a kind of” another more general thing (for example the class Vehicle). The particularity of
this relationship is that ,the characteristics of the superclass ie. the attributes and operations

9
2.1. UNIFIED MODELING LANGUAGE (UML)

are transmitted to the subclass. However, the subclass very often has attributes and operations
that do not come from the heritage, hence the term specialization. This specialization is also
expressed through the concept of polymorphism1 . In object oriented programming this concept
allows for example to privilege the implementation of a method in the subclass at the expense
of its implementation in the mother class [Gog09].

Figure 2.8 Example of inheritance

2.1.2 Object Diagram

An object is an instance of a class. There can be multiple instances of each class. An object
in an object diagram represents the state of an object at a certain point in time . An object
diagram is composed of:

• objects (class instances) and links (association instances).

An object is an instance of a class and represents state of a class at a specific time. A link
represents a relationship between objects at a given time.
Object diagrams are generally used:

• to show a context i.e. the state of object instances before and after an interaction.
1 The concept consists of providing a single interface to entities that may have different types

10
 CHAPTER 2. TECHNOLOGIES AND PREVIOUS RESEARCH WORK

• to facilitate the understanding of complex data structures i.e. recursive structures.

In order to better understand the objects diagram we will give an example of an object Diagram of
the class diagram in Figure 2.2,then the definition of its components. The object diagram Social
Network [Gog17b] contains nine instances all initialized, namely four objects of the class Profile
such as merkel,may,trump,putin,then four objects from the association classes Friendship
and Commenting namely Friendship1,Friendship2,Friendship3 and Commenting1. An ob-
ject Posting1 of the class Posting and at the end a composition link PosterPosting of the
composition association PosterPosting. The diagram object Social Network shows us here
that may:Profile has sent a friendship request to merkel:Profile and this friendship request
is still pending.The friendship request that putin:Profile send to merkel:Profile has been
accepted. However the friendship request that Putin:Profile received from Trump:Profile
was refused. merkel:Profile does a posting 'BMW,we have a problem' and putin:Profile
comments on the posting by saying 'may The Donald be with you'. In the context of our
Work it will be possible that from an object diagram, we can obtain the corresponding class
diagram.

Figure 2.9 Object Diagram of Social Network.Source: [Gog17b]

11
2.2. PROGRAMMING LANGUAGE

2.2 Programming Language

We will give a short description of the Programming languages we use to implement the concept.

2.2.1 Java 9
The Java2 programming language was used for object-oriented programming in the plugin. This
Programming Language was already used for the implementation of the USE tool. For the
implementation of the new functionality we used Java 9.

2.2.2 Swing (Java)

The interfaces of the USE and the Plugin have been developed mostly with the help of Swing.
Swing is a set of component for Java developers which allow to create graphical user interface
(GUI) features such as text field, context menu or button. Notice that These features are
unaffected by the windowing system for a particular operating system. Finally Swing components
are included into the group of features for building graphical user interfaces (GUIs) the Java
Foundation Classes [Ora04].

2.3 USE : UML-based Specification Environment

“ USE is a system for the specification and validation of information systems based on a subset of
the Unified Modeling Language (UML) and the Object Constraint Language (OCL)” [SOU]. The
USE tool helps analysts,designers, and developers to implement UML models and verify OCL
constraints so they can use model-driven techniques for software production. USE has begun as
a doctoral thesis project [Ric02] and the first version of which was already published in 1998.
The Models are described in text form and saved in .use files. The Expressions written in the
.use file contains UML diagram classes (Class, Association,etc) and OCL Language (Object Con-
traints Language). OCL specifies additional integrity constraints on the Model.[Kuh07]. OCL is
identical to expression sub-language of SOIL.SOIL is the imperative programming language of
USE[SOU04]. SOIL is intended to :

• “To create and modify systems states of a specification (i.e., a .use file). Here, SOIL extends
the former command line language of USE.” [SOU04]
• “To imperatively define operations in a .use specification.” [SOU04]

2 www.Java.Com

12
 CHAPTER 2. TECHNOLOGIES AND PREVIOUS RESEARCH WORK

Since 2018 there has been the first version of the Plugin ObjectToClass for USE. This Plugin
aims to convert an object diagram to a class diagram. Since the first version the plugin has been
updated and is now at version 1.3. This version will be the one on which our work will be based.

2.3.1 The Object to Class Plugin (O2C)

In 2017 Andreas Kaestner published his master thesis [Kae17] which provides an first implemen-
tation of a Object Diagram to Class Diagram converter as a plugin(ObjectToClass for the tool
USE. The thesis was created under the supervision of Professor Martin Gogolla. USE is a tool
for model specification and validation. ObjectToClassPlugin has been developed in Java and is
based on the Flow-Flow-Flow Concept. However the main goal of ObjectToClass is to allow the
user to model an information system via a graphical interface. But this time from an object
schema (incomplete or imperfect).

2.3.1.1 Flow-Flow-Flow : From (imperfect) object Diagrams to (imperfect) class

Diagrams
The Concept Flow-Flow-Flow consists in the creation and transformation of an object diagram
(imperfect) to a diagram Class (imperfect) in a developer-friendly,iterative process. During the
creation of the object diagram,objects can be linked to direct or indirect connections. Direct con-
nections are for example Binary Link and indirect connections are for example classname. With
the concept Flow-Flow-Flow there is no concrete UML syntax regarding objects and diagram
classes, i.e. one can have incomplete or contradictory classes before or after the Transformation.
Here incomplete <?> means that parts may be missing while contradictory <!> means that
inconsistencies are allowed [And18a]. Example of a class and object diagram highlighting the
elements “Incomplete” and “Contradictory”.

13
2.3. USE : UML-BASED SPECIFICATION ENVIRONMENT

Figure 2.10 Imperfect Object Diagrams. Source: [And18c]

Figure 2.11 Imperfect Class Diagrams. Source: [And18d]

14
 CHAPTER 2. TECHNOLOGIES AND PREVIOUS RESEARCH WORK

The Transformation according to the Flow-Flow-Flow concept consists of two types of Transfor-
mations and different Steps [And18a]. As type of Transformations we have:

• Transformation from the object diagram to the class diagram: (OTC: Objects to classes);
• Transformation of link to the Association : LTA: Links to associations

The transformation has the following respectively Steps [And18b]:

1. OTC-Step 1: Creation of classes.

2. OTC-Step 2: Solving the attribute conflicts.
3. LTA-Step 1: Creation of associations.
4. LTA-Step 2: Unambiguous merge.
5. LTA-Step 3: Ambiguous merge.
6. LTA-Step 4: Determining the multiplicities.

The following Figure 2.12 will give us an overview of the different Stages of a Transformation.

Figure 2.12 Overview of Transformation. Source: [And18b]

15
Chapter 3

Requirements and Practical Examples

In this chapter we will describe the different needs related to the “ Flow-Flow-Flow” concept for
whole-part and inheritance. These will be the different functions that the plugin O2C must per-
form, in addition to the features related to its ergonomics and robustness. These characteristics
will be accompanied by examples to illustrate their application in the plugin.
The Requirements are grouped into main functionality that the application performs with the
action of the user and other background parts (without direct action of the user).

• add an aggregation link

• add a composition link
• edit the compostion and the Aggregation links created
• delete the compostion and aggregation links created
• collect information on the superclass
• merge similar aggregation Links during transformation
• merge the composition bonds during the transformation
• assemble the subclasses and their corresponding superclasses during the transformation
• transform the aggregation links into an Association of the aggregation type
• transform the composition links into a composition association
• recognize design errors in aggregation and composition
• inform the user of the different design errors in the composition case
• case of aggregation
• the case of heritage
• recognize design errors in the case of heritage
• recognize the attributes of superclasses
• Migrate superclasses attributes
• link superclasses and subclasses through heritage relationships after transformation
• migration of attributes between superclasses and subclass

17
3.1. AGGREGATION IN O2C

3.1 Aggregation in O2C

3.1.1 “Add an Aggregation Link”

Requirement Description

Add Aggregation The user can add an Aggregation link from the context menu after
selecting two objects.

Figure 3.1 Add an aggregation link through the input interface.

3.1.2 “Edit an aggregation Link”

Requirement Description

Edit aggregation link The user can edit an Aggregation link from the context menu after
selection of only one link of this type.

18
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

Figure 3.2 Edit an aggregation link through the input interface.

3.1.3 “Delete an Aggregation Link”

Requirement Description

Delete Aggregation The user can delete an Aggregation link from the context menu
after selection of only one link of this type.

3.1.4 “Transform Aggregation Links into Aggregation association”

Requirement Description

Transform Aggregation link All Aggregation links will be transformed into Aggregation asso-
ciations after a click on the Transformation button.

19
3.1. AGGREGATION IN O2C

Figure 3.3 All aggregation links are changed into Association aggregation during transformation
Process.

3.1.5 “Merge similar Aggregation Link”

Requirement Description

Merging Aggregation Association All similar Aggregation Association will be merged after Transfor-
mation into class diagram.

Figure 3.4 Similar aggregation links are merged after Transformation.

3.1.6 ”Recognize and inform user for design (regarding UML) errors”

Requirement Description

Recognize design Error Conflicts and errors related to Aggregation Associations are rec-
ognized.

20
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

For error detection it is necessary to use the basic characteristics of part-whole relationships
summarized in the table 2.7 of section one: Acyclic and prohibition of sharing. As the table
shows, acyclic is a common characteristic in aggregation and composition. Examples 1-5 show
us an illustration of this detection. On the other hand, the sharing prohibition is a character
unique to the composition. The detection of this type of error will therefore be done exclusively
for the composition 3.2.6.

Figure 3.5 Example 1 for cyclical detection.

The figure 3.5 shows in the left window the object diagram as input, and the right window the
class diagram as output. The object diagram shows two objects of the same class associated by
two aggregations with different name. The reflexive form of the aggregation at the output is an
potential error to be reported. This is done through the broken lines but more clearly in the Log
message area.
Figure 3.6 present the same situation, but this time, The two objects of the same class are
associated by two aggregations with the same name. Once again the output has produced a
potential error to be reported.
In this case, ada is a Teacher. The output clearly shows a direct circle formed by two aggrega-
tions.
Figure 3.8 shows the same situation this time with a new element, namely composition. This
does not eliminate the error detected.

21
3.1. AGGREGATION IN O2C

Figure 3.6 Example 2 for cyclical detection.

Figure 3.7 Example 3 for cyclical detection.

22
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

Figure 3.8 Example 4 for cyclical detection.

If we take back our initial configuration of the objects, we always get an error.

Figure 3.9 Example 5 for cyclical detection.

23
3.2. COMPOSITION IN O2C

3.2 Composition in O2C

3.2.1 “Add a Composition Link”

Requirement Description

Add Composition The user can add a Composition link from the context menu after
selecting two objects.

Figure 3.10 Add a Composition link through the input interface.

3.2.2 ”Edit a Composition Link”

Requirement Description

Edit Composition The user can edit a Composition link from the context menu after
selection of only one link of this type.

3.2.3 ”Delete a Composition Link”

Requirement Description

Delete Composition The user can delete a Composition link from the context menu
after selection of only one link of this type.

24
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

Figure 3.11 Edit a Composition link through the input interface.

Figure 3.12 Delete a Composition link through the input interface.

3.2.4 “Transform Composition Links into Composition association”

Requirement Description

Transform Composition link All Composition links will be transformed into Composition asso-
ciations after a click on the Transformation button.

25
3.2. COMPOSITION IN O2C

Figure 3.13 All composition links are changed into Association composition during transforma-
tion Process.

3.2.5 “Merge similar composition link”

Requirement Description

Merging composition associations All similar Composition Association will be merged into one after
Transformation of composition link.

Figure 3.14 Similar composition links are merged after Transformation.

3.2.6 “Recognize and inform user for design (regarding UML) errors”

Requirement Description

Recognize design Error Conflicts and errors related to composition Associations are rec-
ognized.

26
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

Figure 3.15 Example 1 for share and circle detection.

The example in Figure 3.15 shows on the left, an object diagram with 3 instances of the same
class, two of which are linked to the same object by a composition link. The class diagram (the
window on the right) and the Log report detect errors. These errors are due to the fact that the
composition is prohibited from sharing and acyclic.
However, it should be noted that to correct the error caused by the sharing prohibition, it is
sufficient to modify the owner’s multiplicity. We will therefore write instead of 1, the multiplicity
(0...1).

27
3.2. COMPOSITION IN O2C

Figure 3.16 Example 2 for share recognition.

In 3.16 john and ada are the parents of the student martha. They are connected by two different
compositions: Fatherhood and Motherhood. the class Student is therefore shared through these
two compositions. the message of the Log confirms this.

Now in Figure 3.17 let’s assume that, ada is a teacher. We always get an imperfect diagram
(with errors).

28
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

Figure 3.17 Test 3 for circle recognition.

Figure 3.18 represents a complex but conceivable situation of two students connected by parental
relationships using composition. This situation is therefore, due to sharing and circle, subject to
errors after transformation.
Finally we have the Figure 3.19 whose less complex situation (more conceivable) always pro-
duces errors, because of the sharing.

29
3.2. COMPOSITION IN O2C

Figure 3.18 Test 4 : sharing and circle detection.

Figure 3.19 Test 5 : sharing and circle detection.

30
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

3.3 Inheritance in O2C

3.3.1 “Collect information on the superclass”

Requirement Description

Filling in the field Superclass name The user can enter the name of the superclass in the field. So that
he can get the Inheritance after the transformation.

Figure 3.20 Filling in the Field Superclass name

3.3.2 “Report the presence of Superclass”

Requirement Description

Notice the presence of superclass on The appearance of the object should indicate the symbol ”<”
the object. to indicate if there is a superclass and differentiate it from the
subclass.

31
3.3. INHERITANCE IN O2C

Figure 3.21 Report the presence of Superclass

3.3.3 “Assemble the subclasses and their corresponding superclasses during

the transformation”

Requirement Description

Group the superclass and their sub- The superclass and their subclass are summarized after the trans-
class after the transformation. formation (merge).

3.3.4 ”Recognize and inform user for design (regarding UML) errors”

Requirement Description

Conflict detection After the transformation,conflicts between the attributes are de-
tected and displayed.

32
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

Figure 3.22 Conflict detection

3.3.5 “Link the superclass and the subclass through inheritance relationships
after transformation”

Requirement Description

Display the edge of the inheritance The edge of the inheritance is shown after the transformation.
after the transformation.

Figure 3.23 Edge of the inheritance

33
3.3. INHERITANCE IN O2C

Figure 3.24 Inheritance edge in an incomplete class diagram

3.3.6 “Organization of attributes between the superclass and the subclass”

Requirement Description

The migration of attributes between The attributes of the superclass are assigned to their classes after
the superclass and the subclass the transformation and merge.

• Case1 : Instances of the subclass and superclass have attributes

– “If the attribute names of the instances of the same subclass and the attribute names
of the instances of the same superclass are the same and the same type”

* Migration and Merge Of Attributes.

34
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

Figure 3.25 Case1: Migration and Merge Of Attributes

Figure 3.25 shows the organization of the attributes between the superclass and its
subclass at the end of the transformation from the attributes filled in two instances of
the same subclass and two instances of the same superclass in the input object diagram
before the transformation.

– “If the attribute names of the instances of the same subclass and the attribute names
of the instances of the same superclass are the same and are of different type”

* No Migration and Merge of Attributes of Types(Contradictory)

Figure 3.26 Case1: No migration and Merge of Attributes Types(Contradictory)

Figure 3.26 shows the non-migration of attributes to the superclass and attribute conflicts
of contradictory type after transformation from attributes filled in two instances of the same

35
3.3. INHERITANCE IN O2C

subclass and two instances of the same superclass in the input object diagram.

• Case2: An instance of the superclass has attribute names and instances of the
same subclass also have attribute names Or an instance of the subclass has attribute
names and instances of the same superclass subclass also have attribute names

– “If the attribute names of the instance or instances of the same subclass and the at-
tribute names of the instance or instances of the same superclass are identical and are
of the same type”

* Migration and Merge of Attributes

Figure 3.27 Case2: Migration and Merge of Attributes

Figure 3.28 Case2: Migration and Merge of Attributes

36
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

– “If the attribute names of the instance or instances of the same subclass and the at-
tribute names of the instance or instances of the same superclass are the same and have
different types”

* No migration and Merge of Attributes of Types(Contradictory)

Figure 3.29 Case2: No migration and Merge of Attributes of Types(Contradictory)

Figure 3.30 Case_2: No migration and Merge of Attributes of Types(Contradictory)

37
3.3. INHERITANCE IN O2C

• Case3:an instance of the superclass and an instance of the subclass have attribute
names
– “If the attribute names of the instance of the subclass and the attribute names of the
instance of the superclass are identical and have the same type”

* Migration and Merge of Attributes

Figure 3.31 Case3: Migration and Merge of Attributes

– “If the attribute names of the instance of the subclass and the superclass are the same
and have different types, or simply if the attribute names of the instance of the subclass
and the superclass are different”

* No migration of attribute

38
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

Figure 3.32 Case3: No migration of attributes

Figure 3.33 Case3: No migration of attributes

• Case4:An instance of the subclass has attribute names and the instance of the
superclass has no attribute names.

– No migration of attribute

39
3.3. INHERITANCE IN O2C

Figure 3.34 Case4: No migration of attributes

• case5: Instances of the same subclass have the same attribute names with different
types and an instance of the superclass has no attribute names.

– Merge types(Contradictory)And No migration

Figure 3.35 Case5: Merge types(Contradictory) And No migration

– Case6: Instances of the same subclass have the same attribute names with
identical types and an instance of the superclass has no attribute names

* Merge And No migration

40
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

Figure 3.36 Case6: Merge And No migration

• Case7: an instance of the subclass does not have attribute names and an instance
of the superclass has attribute names

– No migration of attribute

Figure 3.37 Case7: No migration of attributes

• case8 :Instances of the same superclass have the same attribute names with different
types and an instance of the subclass have no attribute names

– Merge types(Contradictory)And No migration

41
3.3. INHERITANCE IN O2C

Figure 3.38 Case8: Merge types(Contradictory) And No migration

• Case9: Instances of the same superclass have the same attribute names with identical
types and an instance of the subclass has no attribute names

– Merge And No migration

Figure 3.39 Case9: Merge And No migration

42
 CHAPTER 3. REQUIREMENTS AND PRACTICAL EXAMPLES

• Case10: Two instances of different subclass that inherit the same superclass

– If the attribute names of these two instances are identical and of the same
type

Figure 3.40 Merge And Migration

– If the attribute names of these instances are the same and of a different
type

Figure 3.41 No migration

43
Chapter 4

Use Cases of the System

The chapter describes the use cases of the whole system. These Use Cases summarize the different
functionalities related to the requirements stated in the previous chapter.

4.1 Use case Diagram

The use case diagram is shown in the figure 4.1

45
4.2. USE CASE MODEL

Figure 4.1 Use case diagram of the System.

4.2 Use case model

In the following section, the elements illustrated in the Use case diagram will be detailed.

46
 CHAPTER 4. USE CASES OF THE SYSTEM

4.2.1 Actors
All System Actors are Developers.

4.2.2 Use cases

Name Add object

Actor Developer
Sequence of events
1. the developer opens a context menu with the right click of
the mouse and selects "add object".
2. an object is created in the partial object diagram view.

Starting condition The plugin is already running (the input object diagram window
is active).
Ending condition the object has been successfully created.

Table 4.1 Use case: ”add object”

Name Select object/link/comp/agg

Actor Developer
Sequence of events
1. the developer selects an object, a link, an aggregation link or
a composition link in the ”input object diagram” interface.

Starting condition An object,a link,an aggregation link or a composition link has

been successfully created.
Ending condition The object ( link, aggregation link or composition link) has been
successfully selected and is highlighted.

Table 4.2 Use case: ”select object/link/comp/agg”

47
4.2. USE CASE MODEL

Name Add superclass

Actor Developer
Sequence of events
1. The developer double-click (left click) on an object, or the
developer opens a context menu with the right click of the
mouse and selects "edit object".
2. Edit the "superclass name field” in the new opened window.

Starting condition An object is selected.

Ending condition The developer clicks on "Apply" in the property windows

Table 4.3 Use case: ”add Superclass”

Name Edit object

Actor Developer
Sequence of events
1. The developer double-click (left click) on an object, or the
developer opens a context menu with the right click of the
mouse and selects ”edit object”.

Starting condition An object is selected.

Ending condition The developer clicks on "Apply" in the property windows.

Table 4.4 Use case: ”Edit object”

Name Clone object

Actor Developer
Sequence of events
1. The developer click (left) on an object.
2. Select "clone object" in the context menu.

Starting condition An object is selected.

Ending condition The object (clone) has been successfully created.

Table 4.5 Use case: ”clone object”

48
 CHAPTER 4. USE CASES OF THE SYSTEM

Name Add a link/comp/agg

Actor Developer
Sequence of events
1. The developer opens a context menu with the right click and
selects as required "Insert link", "Insert composition"
or "Insert aggregation".
2. a link respectively composition link or aggregation link is cre-
ated in the partial object diagram view.

Starting condition Exactly two objects have been selected.

Ending condition the relationship or part-whole relationship has been successfully
created.

Table 4.6 Use case: ”add link/comp/agg”

Name Edit link/comp/agg

Actor Developer
Sequence of events
1. The developer double-click (left click) on the link’s (or part-
whole link) name or even one of the role’s name.
2. Edit the information in the opened view.

Starting condition The target link (or part-whole link) is selected.

Ending condition The developer clicks on "Apply" in the property windows.

Table 4.7 Use case: ”Edit link/comp/agg”

Name Destroy object/link/comp/agg

Actor Developer
Sequence of events
1. The developer select (left click) an object (link or part-whole
link).
2. Select ”destroy object (link or part-whole link)” in the context
menu.

Starting condition An object (link or part-whole link) is selected.

Ending condition The object (link or part-whole link) has been successfully de-
stroyed.

Table 4.8 Use case: ”Destroy object/link/comp/agg”

49
4.2. USE CASE MODEL

Name Construct partial object diagram

Actor Developer
Sequence of events
1. The developer start the plugin by selecting (left click) the
plugin icon in the tools menu.
2. The window input object diagram opens .

Starting condition Use has been successfully started.

Ending condition The window input object diagram has been successfully
opened.

Table 4.9 Use case: ”construct partial object diagram”

Name Revise partial object diagram

Actor Developer
Sequence of events
1. The developer opens The window input object diagram.
2. Revise in order to improve the partial object model .

Starting condition The partial object diagram view has already been started.
Ending condition

Table 4.10 Use case: ”Revise partial object diagram”

Name Transform to partial class diagram

Actor Developer
Sequence of events
1. The developer opens the context menu (Right click on the
input object diagram view).
2. The partial class diagram view opens.

Starting condition The partial object diagram view has already been started and is
active.
Ending condition

Table 4.11 Use case: ”Transform to partial class diagram”

50
 CHAPTER 4. USE CASES OF THE SYSTEM

Name Export model

Actor Developer
Sequence of events
1. The developer opens the context menu (Right click on the
partial class diagram view).
2. The save specification view opens.
3. Choose the directory for the backup.
4. give a name to the model.
5. click (left) on ”save”

Starting condition The partial class diagram view is active.

Ending condition The specification file as been successfully created.

Table 4.12 Use case: ”Export model”

Name Identify uncritical items

Actor Developer
Sequence of events
1. The developer check the uncritical element on the partial class
diagram window.

Starting condition The partial class diagram view is active and shows uncritical ele-
ments.
Ending condition

Table 4.13 Use case: ”Identify uncritical items”

Name Identify missing items

Actor Developer
Sequence of events
1. The developer check the missing items on the partial class
diagram window.

Starting condition The partial class diagram view is active and shows missing items.
Ending condition

Table 4.14 Use case: ”Identify missing items”

51
4.2. USE CASE MODEL

Name Identify contradictory items

Actor Developer
Sequence of events
1. The developer check the contradictory items on the partial
class diagram window.

Starting condition The partial class diagram view is active and shows contradictory
items.
Ending condition

Table 4.15 Use case: ”Identify contradictory items”

52
Chapter 5

Concepts

In this Chapter the new general Structure of Elements and the new aspect of transformation are
described. The changes made are in line with the basic design idea. Finally, the New Aspects of
Transformation presented in the examples of the previous chapters will be described in a formal
way.

5.1 Changes in the Transfomation concepts

5.1.1 The new General Structure of element
The transformation is carried out from elements that define its core. The structure of these
elements has been modified in order to respond to the new idea to be integrated in the trans-
formation. The Figure 5.1 shows the new structure of the elements. The Prefix “T” was used
in the previous structure and shows the affiliation to the transformation [Kae17]. In this new
structure there is still an inheritance relationship between the class TElement and its different
subclasses. Thus, Objects, class, associations and attributes are elements. However, changes
have been made to some subclasses, in particular to additional or specialization attributes.

Specialization attributes of objects

From now, objects become a new attribute, SuperclassName in addition to its other character-
istics. This attribute can also be empty as the attribute className.

Specialization attribute of Link

The idea is to be able to distinguish or recognize the different types of links. To do this we will
use Kind, whose values vary from zero to two. So we will use zero for simple links, one for weak

53
5.1. CHANGES IN THE TRANSFOMATION CONCEPTS

Figure 5.1 The new General Structure of Elements.

aggregation links, and finally two for strong aggregation links or composition links.

Specialization attribute of Associations

There are always two adjacent classes, two sets of role names and two cardinalities in addition
to the new attributes, kind, IsShared and isCyclic. IsCyclic and isShared are used for
error detection while kind plays the same role as with links.

5.1.2 Status of Elements

Some basic design has been modified but there are always 3 possible states for one element:
Complete , Incomplete and Contradictory.

Status of Association
Associations of the type part-whole relationship are not only contradictory if there is more than
one role name at either end, but yet also when the connection between the classes forms a di-
rect cycle made up exclusively of the part-whole relationship (Figure 3.8), or when two or more
Composition relationships start from a single class (Figure 3.17). In this case, the status of the
concerned associations will be displayed in the log window.

54
 CHAPTER 5. CONCEPTS

Status of other Elements

The status of other elements remain unchanged and follow the same rules as before, i.e. :

• An object is incomplete when it has no class name or at least one attribute that is incomplete
and contradictory when at least one attribute that is contradictory.
• For the classes the previous rules are applied.
• When a link name is missing the link has the status incomplete otherwise it is complete
• The use of more than one type for an attribute is contradictory for the attribute its self,
elsewhere the absence of the name of an attribute is considered as incomplete.

5.1.3 The input Object diagram

The main goal of the input object diagram is to free the developer from errors related to for-
malism when creating an object diagram. The idea is to support the developer throughout the
creation process by facilitating the use of the plugin as much as possible.The previous input
object diagram was certainly in this perspective but remained incomplete. New features where
since introduce and from now, it is possible to create links of the type aggregation or composition
between objects, and to create an inheritance relationship between a class and its subclass(es).
the generalisation relationship is created in this interface by simply entering the name of the
super class present in each object’s attributes view, like illustrated in Figure 3.20. The integra-
tion of inheritance in the input diagram required the development of an attribute recognition
method. Remember, the developer must always be kept in mind. That’s why a method that is
both efficient and the easiest to use is recommended. Hence, the analysis of the Attribute during
the transformation already used in the previous work will be exploited and modified. This will
allow to assign, according to the membership to a superclass, an attribute, or to recognize a
specialization attribute.
Moreover for a better exploitation, errors regarding missing elements are indicated directly on
each element concerned, this is also implemented on the new features like illustrated in Figure
3.10. This is how objects or links will be represented as a dotted line when they are incomplete.
Part-whole relationship are incomplete when the link’s name is missing. No contradiction situa-
tion can be shown on this interface for all the new feature.

5.1.4 The output Class diagram

The Output class diagram is an important part of the plugin. Despite it is informal, the class
diagram is based on the fundamentals of UML. It should not be seen as a perfect class diagram,
which allows to model a system, but as a step in an iterative process [Kae17].

55
5.2. REGARDING THE TRANSFORMATION

Its role in this process remains the same, i.e. to display the interpretation of the object diagram
introduced in the input. Apart from the layout of the elements, no changes can be made in
this interface. However, one can go back to modify the input and make a new transformation.
Some changes have been made at this stage with the same goal: to interpret in the best possible
way without changing the developer’s thinking. The class diagram now allows to display the
inheritance, as well as the migrated attributes, after interpretation of the input object diagram.
It is also possible to display other types of associations: The part-whole relationship (aggregation
and composition). The log window, already present in previous versions of the Plugin, will be
used to display error messages regarding the sharing and cyclical characteristics of this type of
association.

Note that the transformation process is very important for this part ,it is about understanding
as much as possible the developer input object diagram and producing a(n)(imperfect) class
diagram. The following section will provide more detail on this topic.

5.2 Regarding the Transformation

The transformation developed since its creation is divided into two main phases, due to new
features we now distinguish one intermediary phase :

• The creation of classes from objects.

• The creation of Generalization Relationship between classes.
• The creation of Associations from links.

Figure 5.2 Overview of the transformation’s steps

It is in this model that the new updates of the transformation are based. It should be noted
that these three Processes are well executed in the order presented. Concerning inheritance, the
Transformation is done respectively by creating superclasses and subclasses from the objects. i.e.
by filling in the fields Class name and Superclass name or the field Superclass name only. Then

56
 CHAPTER 5. CONCEPTS

moving the attributes filled in the objects to the corresponding classes, i.e. to the superclass
or subclass. In addition to this, a Generalization Relationship has been developed between the
Superclass and subclass in order to obtain the Edge of inheritance between the Superclass and
its subclasses. Aggregations and compositions are created during the third phase, i.e. during the
creation of associations. As a result, some modifications have been made in this phase. These 3
phases are subdivided into several steps summarized in the state diagram (Figure 5.2).

5.2.1 From Object to Class

Creation of Superclasses and Subclasses based on the input Objects.
In the case of inheritance, the Superclasses and Subclasses are first created, then comes the move
or Migration of the Attributes to their corresponding class,i.e. to superclass or subclass.

Figure 5.3 Creation of Superclasses and Subclasses based on the input Objects.

In order to obtain Superclasses and Subclasses there are two alternatives:

1. The fields Class name and SuperClass name of the object must have values.
(a) if the Superclass and subclass do not already exist, then two classes are created.
(b) if the Superclass or subclass already exists, then a merge into the existing Class will
be done.
(c) if the Superclass and the subclass already exist, then a Merge into the existing
Superclass and subclass will be done.
2. the SuperClass name field of the object must have value and the Class name field of the
object has no value.

57
5.2. REGARDING THE TRANSFORMATION

(a) In this case two classes are created: a class with a name and another one without a
name.

However if the SuperClass name field of the object has no value and the Class name field of
the same object has a value or not, then only one class will be created.

Organization of attributes between Superclass and Subclass

The organization of the attributes is about the migration or move and Merge of the attributes
between the subclass and the superclass. This organization of the attributes is defined in several
cases.

• Instances of the superclass and subclass have Attributes.

If the attribute names of the instances of the same subclass and the attribute names of the
instances of the same superclass are identical and have different types, then there is no attribute
migration to the superclass after the transformation, but rather the merging of the attributes
with the contradictory type in either thesuperclass and the subclass. Concrete examples of non-
Migration and the merging of attributes that have the contradictory type are presented by Figures
3.26,3.29, 3.30. However,if the Attribute names of the instances of the same subclass and the
Attribute names of the instances of the same superclass are identical and have the same types.
In this case,we have a merge and a migration of the attributes to the superclass. The Figures
3.25, 3.27, 3.28 are a concrete examples that shows the Merging and Migration of Attributes to
the superclass after the transformation. We can also observe that if the attribute names of the
instances of the same subclass and the attribute names of the instances of the same superclass are
not identical. In this case there is no merging and attribute migration after the transformation.

• An instance of the superclass and an instance of the subclass have Attributes

If the attribute names of the instance of the subclass and the attribute names of the instance of
the superclass are identical and have different types or if the attribute names of the instance of the
subclass and the attribute names of the instance of the superclass are not identical then there is
no attribute migration to the superclass after the transformation. Figures 3.31, 3.32 are concrete
examples of this non Attribute Migration. However if the attribute names of the instance of the
subclass and the instance of the superclass are identical and have the same types, then we obtain
a merge and a migration of the attributes to the superclass after the transformation. Figure 3.31
is a concrete example of Attribute Migration and Merge.

• The instances of the subclass have attributes

if the names of the attributes of the instances of different subclasses that inherit from the same
superclass are identical and have the same type, then there is merging and migration of these at-
tributes to the superclass after the transformation. Figure 3.40 shows the merging and migration

58
 CHAPTER 5. CONCEPTS

of attributes to the superclass after the transformation from attributes filled in two instances of
the same subclass in the Input Object Diagram.However in the case where the attribute names
of the instances of different subclasses that inherit the same superclass are identical and have
different types. Then there is no migration of attributes to the superclass at the end of the
transformation. The Figure 3.41 shows that there is no attribute migration to the superclass.

5.2.2 The Creation of the Generalization Relationship

Since there are no direct links between Class Instances in case of inheritance. Then the creation
of a generalization relation will be done during the creation of the Classes(Superclass and its
subclass or subclasses)and the organization of the attributes between the superclass and its
subclass or subclasses. The figure 3.20 shows an example of creating a generalization relationship
from the input of a diagram object on which the name of the subclass and the name of the
superclass can be filled in.

5.2.3 From Links to Associations

Aggregation and Composition links are transformed through several mechanisms. Since aggre-
gation and composition links have similar characteristics to standard links, we can practically
distinguish the same steps (Links To Associations steps or LTA-steps developed in the previous
versions)for their transformation. However, three new steps will be integrated. Thus, aggrega-
tions , compositions and links are first changed into associations according to their type (creation
of association). Then associations with similarity, with no conflict and with complete informa-
tion are merged, this step was called Unambiguous merge , after this merge, Associations that
have conflicts or were incomplete are merged [Kae17]. Fourthly, composition Associations are
check for sharing , fifthly part-whole relationships are check for cyclical connections. In The next
step, part-whole relationships with no name are automatically rename. It is obvious that the
3 last steps are concerning part-whole relationships in particular. At the end multiplicities are
evaluated and applied to the corresponding association. In summary, there are now 7 steps in
the transformation of links into associations.

1. LTA-Step 1: Creation of Associations.

2. LTA-Step 2: Unambiguous merge.
3. LTA-Step 3: Ambiguous merge
4. LTA-Step 4: Sharing check of composition associations
5. LTA-Step 5: Cyclical check of part-whole relationship
6. LTA-Step 6: Naming unnamed part-whole relationship
7. LTA-Step 7: Determining the multiplicities

59
5.2. REGARDING THE TRANSFORMATION

Our focus is on the 3 new steps.

LTA-Step 4: Sharing Check of Composition Association

This step allows to check whether the prohibition of sharing the characteristic of this type of
association, has been violated. At this stage, all the composition associations are included,
the other associations are simply excluded till the next step. Then, the first end class of each
composition association is compared to each other, all the compositions with the same first
adjacent class (the class not connected to the black diamond) are considered as sharing that
class (Figure 5.4).
The errors are stored and will be shown when displaying the Output class diagram like presented
in the Figure 3.17.
However, there are real cases where this property violation is circumvented when replacing the
multiplicity of the Classes adjacent to the black diamond with 0...1 . Depending on the desired
model the multiplicity adaptation allows to correct this error. That could not be done through
the plugin, since multiplicities are automatically calculated.

Figure 5.4 Presenting a sharing situation.

60
 CHAPTER 5. CONCEPTS

LTA-Step 5: Cyclical check of part-whole relationship

The idea is to detect any group of cyclic connection made exclusively from part-whole rela-
tionships. This is made by recursively check end classes and see if they form, together with
Composition and/or aggregation, a direct cycle (Figure 5.5).
The Purpose remain the same, we save any detection and display it while showing the output

Figure 5.5 A case where a cycle is created.

class diagram. e.g: Figure 3.8

LTA-Step 6: Naming Unnamed Part-whole Relationships

At this stage there can be associations without names. This would complicate the iterative
task of the developer when analyzing and understanding the class diagram in order to improve
his object diagram in the input. Indeed after the transformation, errors related to missing
information and various conflicts are displayed in the output class diagram, but the display of
errors related only to the part-whole relationship is done in the Log part. The missing of name
at some associations could make this idea useless since the associations concerned will not be
distinguished or differentiated from each other, an example is shown in Figure 5.6. Thus to
remedy this, a systematic naming of unnamed compositions and aggregations will be operated
(Figure 5.7).

61
5.2. REGARDING THE TRANSFORMATION

Figure 5.6 Example of transformation when no names were given.

Figure 5.7 Example of transformation when names were systematic given.

62
Chapter 6

Implementation

This part will focus on the application of the modelling carried out in the requirement chapter.
It will introduce the new metamodel and the new functionalities provided to the system, without
forgetting the ergonomic aspect. The source code used for the implementation will not be
presented here but will be made available to the Database group of the Bremen University.

6.1 Parts of the Plugin and their new Features

The plugin in order to work, requires several elements, each with a well-defined role.

• The Metamodel
• Object diagram of USE
• Input object diagram
• Output class diagram

6.1.1 The Meta Model

The implementation of the concept has imposed the consideration of some mechanisms specific
to USE. The creation of a model in USE is generally done by modifying in a text editor some
file of type (.use). Once the modification of the file is finished, it is necessary to load the file
in the USE application in order to be able to create objects. In order to follow the same logic,
the plugin uses a predefined model (the Meta model) in a file that will be loaded in the USE
class diagram view (not the output view) each time the plugin starts. This Meta model has also
been modified for the needs of the integration of the new concepts. The Figure 6.1 gives an
illustration.
For the Inheritance an attribute superclass has been added to the Object class . This will
allow any object in the Input to store a superclass name as a String value. The Object class

63
6.1. PARTS OF THE PLUGIN AND THEIR NEW FEATURES

is linked to 4 other classes, two of which are new. Indeed the class Complink and AggLink are
both newly integrated in the meta model. These two classes have the same attributes as the
Link class. Every composition and aggregation link is represented by its equivalent graphical
entity in the UML input object diagram. Each entity has a name and role names. The difference
is made at the multiplicity level. If there are so many similarities on some characters of these
links, it is nevertheless to be noted that a difference is necessary at the level of multiplicity in
the meta-model. Indeed if each link (including aggregation and composition) must be connected
to exactly two objects each time (ternary links are not yet available), each object can only be
connected to one instance of the CompLink class in the ownedObject-ownedComposition asso-
ciation.This is to model the prohibition of sharing for composition links in the meta model.
The Attributes of these two classes (AggLink and CompLink), indicate respectively, from top to
bottom, the name of the link, and the name of its 2 roles in the input diagram.

Figure 6.1 The new Meta Model.

Moreover, when creating objects in the Input object diagram , another object diagram is created
in parallel, this one is meta model-specific and is generated by USE. The Figure 6.2 gives an
overview of this interface during the creation of the objects in the example of our test in the next
chapter in the Figure 7.1.

64
 CHAPTER 6. IMPLEMENTATION

Figure 6.2 Back-end view of the test example.

65
6.1. PARTS OF THE PLUGIN AND THEIR NEW FEATURES

6.1.2 Input Object Diagram

It is in this interface that most of the new features of the plugin are concentrated.

Input Object Properties

Since generalization (inheritance) relationship is represented only on class-level and not between
instance,we simply choose to provide a field in order to specify (when it exist) The superclass of
the class’s instance (Figure 6.3).

Figure 6.3 Superclass field in the input object properties.

The creation of the superclass field in the input of the diagram object was done using a GUI
toolbox for the Java programming language called Swing(Java).

The Shortcut Menu

This Menu appear until a right-click. Depending on the selection before the right click, using
the new options :

• After a selection of exactly two objects, Insert aggregation and Insert composition.
• After a selection of an aggregation link or a composition link, display destroy for the selected
element .

Insert aggregation / Insert a composition link

As explained in the previous paragraph the aggregation and composition links are created be-
tween two selected objects. This occurs after choosing of their corresponding option in the
context menu (Figure 6.4) . However, it is important to specify that the order of selection of

66
 CHAPTER 6. IMPLEMENTATION

these objects is taken into account when creating these part-whole links. Indeed the first object
of the selection will designate the part and the second object of the selection the whole.
It should be emphasized that the order of selection of the objects involved in the part-whole
relationship follows a direction identical to that of a conventional composition, i.e. from the
container or whole element (object 1) to the contents or part element (object 2) [Gro]. The
transformation of the part-whole relationship into an association follows the procedure described
in the section 5.2. Part-whole relationships are treated as simple links and therefore are im-
plemented from the same class. However a distinction is made for the implementation of other
uses such as the detection functionality of aggregations and compositions. Consequently, the
attribute kind will be used in the Java class of links as well as at the Java class of associations.

Figure 6.4 Context menu when two objects were selected.

67
6.1. PARTS OF THE PLUGIN AND THEIR NEW FEATURES

Destroy aggregation link / Destroy composition link

Like illustrated In Figure 6.5 and Figure 6.6, it will only be possible to delete the selected link
through the contextual menu.

Figure 6.5 Context menu when an aggregation link was selected.

Edit aggregation link / Edit composition link

Here too, only the selected link can be edited. The difference is that the link to edit, will not be
available in the context menu, but will be done in three independent steps. An aggregation or
composition link has 3 editable elements, the two role names and the name of the link. To edit
these three elements, it will be necessary to double click on each of these elements (Figure 6.8,
Figure 6.7 and Figure 6.9).

68
 CHAPTER 6. IMPLEMENTATION

Figure 6.6 Context menu when a composition link was selected.

6.1.3 Output Class Diagram

We now introduce the new features of this part of the plugin dedicated to the interpretation
and transformation of an object diagram into a class diagram.The graphical notation of the
inheritance relationship is now used each time to link an superclass to a subclass. Figure 3.23
presents this inheritance relationship notation. Note that the name of this superclass must have
been explicitly entered at least once in the properties of one of the objects of its subclass which
is available only in the input object diagram.Also in the case of inheritance a feature has been

69
6.1. PARTS OF THE PLUGIN AND THEIR NEW FEATURES

Figure 6.7 Input view to edit aggregation link name.

Figure 6.8 Input view to edit composition link name.

developed that allows after the creation of classes to switch to the organization of attributes
between the superclass and its subclass. Figures 3.40 ,3.25, 3.31, 3.32 and 3.33 show how this
organization of attributes between the superclass and its subclass or subclasses is represented.The
figures 3.15 and 3.8 show, using the Log view, the errors or conflicts that occurred after the
transformation into a class diagram. The presentation of those errors related to the aggregation
and composition associations is done with the help of the isShared and isCyclic parameters
quoted in Figure 5.1. Thus, each Aggregations and Compositions having a conflict related to these
Two characteristics will be detailed in this view, but will also be represented as a discontinuous
line. Each parameter intervenes in a well-defined detection process.

• Thus to detect a cycle in a class diagram, we needed to introduce the depth-first search
(DFS) technique. The depth-first search (DFS) is an useful technique for analyzing graphs,
Determine the connected components of a graph,find cycles in a directed or undirected graph
[Uni17]. To detect a cycle or a back edge, an eye can be kept on the nodes that are currently
in the recursion function for DFS traversals. When a vertex that is already in the recursion
stack is reached, there is a cycle in the diagram. The edge connecting the current vertex to
the vertex to the vertex in the recursion stack is a back edge.

70
 CHAPTER 6. IMPLEMENTATION

Figure 6.9 Input view to edit part-whole link role names.

• To check if an object is involved more than once as a part in a part-whole relationship,

we perform a loop on composition associations. The purpose of this loop is to compare
each FirstEndClass of each composition association. When more than one composition
relationship have the same class as FirstEndClass, there is a sharing conflict.

71
Chapter 7

Usability Study

In the previous chapters the design and implementation were presented. But does the Object-
ToClass plugin fulfills the needs of the user? Does the result of the transformation match with
the user expectations? Are there any usability issues in using the plugin? This question will be
answered in this chapter.

7.1 Methods
In order to achieve the objectives defined for this thesis and to determine whether the developed
features meets the needs of the developer or whether there are still improvements to be made
on this plugin, a survey to measure the usability of the user experience on the new features
of the Plugin has been carried out. This study is divided into two parts: A practical phase
and a feedback phase. The practical phase will consist of the use of the plugin by the different
participants. The Feedback will be an opportunity for us to gather important information about
the experience with the application. For this step we will need to use a tool designed for this
purpose called UMUX (Usability Metrics For User Experience). UMUX is a tool for measuring
the usability of the user experience and has been developed on the basis of SUS (System Usability
Scale). But UMUX focuses on the usability definition of ISO 9241-11 and measures the subjective
assessment of perceived usability by test persons using a seven-level scale (!!!quelle!!!). In contrast
to SUS (System Usability Scale), UMUX has four Questions, three Questions are targeting the
components effectiveness, efficiency and satisfaction and the other question targeting the general
aspect. This tool has been developed in order to overcome the weaknesses noted on the System
usability scale (SUS). Indeed, the elements of SUS did not correspond well to the concepts that
constitute usability according to ISO 9241-11 (1998), i.e. effectiveness, efficiency and satisfaction
(!!!Quelle!!!). So UMUX was set up and proposes a shorter questionnaire, as effective as SUS but
above all appropriate as a usability component of a broader experience index [Fin10a]. Table 7.1
shows the different UMUX Questions.

73
7.1. METHODS

1. This system’s capabilities meet my requirements.

1 2 3 4 5 6 7
Strongly Disagree Strongly Agree
2. Using this system is a frustrating experience.
1 2 3 4 5 6 7
Strongly Disagree Strongly Agree
3. This system is easy to use.
1 2 3 4 5 6 7
Strongly Disagree Strongly Agree
4. I have to spend too much time correcting things with this system.
1 2 3 4 5 6 7
Strongly Disagree Strongly Agree

Table 7.1 Questions of UMUX. Source: [Fin10b]

The object diagram of Figure 7.1 was given on a sheet of paper to the different participants of
the evaluation so that they could propose on another paper a class diagram corresponding to
that object diagram. Then this participants should reproduce the object diagram in Figure 7.1
in the input object diagram of the Plugin and perform a transformation. The evaluation took
place from 06 to 09 January between 11:00 and 17:45 in room 1240 of the MZH (a building of the
University of Bremen), managed by the FB03 department. The evaluation lasted approximately
45 minutes:

• The first 15 minutes served to inform the participant on how the evaluation would be
conducted.
The last 30 minutes were used as follows:
• 10 minutes for the participant to draw a class diagram on a piece of paper in relation to the
object diagram in Figure 7.1 that has been proposed to him.
• 20 minutes for the participant to introduce the object diagram of Figure 7.1 that has been
proposed to him in the plugin, then to carry out the transformation of this object diagram
into a class diagram.
• The last 10 minutes have been reserved for the participant’s feedback on the Plugin.

74
 CHAPTER 7. USABILITY STUDY

7.2 Procedure
7.2.1 Participants
Participants were selected on the basis of their knowledge of UML. For this purpose we decided
to choose two Software developers and testers who have a Master’s degree in Computer Science
at the University of Bremen, then a Research Assistant at the University of Bremen in the
field of Computer Science, and finally two students in Master of Computer Science who already
participated in the course Design of Information Systems in the summer semester 2019 taught
by Martin Gogolla [Gk19].

7.2.2 Schedule
In order to ensure the anonymity of the participants we decided to name them by p1, p2, p3, p4
and p5. Participants p1 and p2 carried out the evaluation on 6 January 2020 in room 1240 of
the MZH from 11:00 to 11:45 and 17:00 to 17:45 respectively. p1 and p2 are Master Students in
Computer Science at the University of Bremen. Participants p3 and p4 participated respectively
in the evaluation on 07 January 2020 from 16:00 to 16:45 and 17:00 to 17:45. p3 and p4 are
software developers and testers who have a Master’s degree in Computer Science at the University
of Bremen. Finally participant p5 carried out the evaluation on 09 January 2020 from 16:00 to
16:45. Participant p5 is a research assistant at the University of Bremen in the field of computer
science.

75
7.3. RESULT AND ANALYSES

7.3 Result and Analyses

During the evaluation,subjects were asked to derive a class diagram from an object diagram.
The result was then compared with the result of the transformation from the plugin. It turned
out that the majority of the test persons created the same class diagram. From this it can be
deduced that the result of the plugin meets the expectations of the users. However it should
be noted that there were some discrepancies. These will now be discussed. In the comparison,
the cardinality is not taken into account. Therefore, if there are differences between the actual
and the target chart regarding cardinality, this is not considered an error. This is because the
interpretation of the cardinality is not clear from the plugin. When setting the multiplicities in
the previous research work of the plugin Andreas K. stated that “It is because an object diagram
always displays a specific state in time of the modeled system. Therefore it can not describe the
whole system at all times. No matter how many links are projected on the same association, the
* multiplicity can never be reached.” ([Kae17], P.28) For example: if a student has two homework
assignments,in the object diagram, the cardinality 2 will be interpreted as cardinality in the class
diagram. In this case the plugin assumes 2. This implementation also has his weakness. The
created class diagrams of the test persons can be seen in the appendix B. The discrepancies are:

• to P1:
– Association “Examination” has no identifier.
– Association “Homeworking” has no identifier.
– Association “Homework” to “Event” is wrong. (correct would be “Project”)

• to P2
– Link from “Course” to “Course” has no aggregation but a simple association.

• to P3
– The association of “project” to “homework” is missing.

• to P4
– Role name for “Prerequisite” missing.
– Association name from “Project” to “Homework”. missing

• to P4
– Role name and identifier for composition from “Course” to “Homework” missing.

The class diagram of the plugin has 17 elements (classes and associations). If you consider the
missing identifiers and role names as transient errors, there are 3 deviations left, which affect the
structure of the class diagrams. Or in other words, out of a total of 17 × 5 elements, 3 would have
errors (where 5 is the number of subjects). This results in an error rate of (3/85) ∗ 100 = 3.53%.
This deviation is minimal. Therefore it is assumed that the result of the plugin is highly consistent
with the developer’s expectations.

After having explained the quantitative representation and evaluation of the manually created

76
 CHAPTER 7. USABILITY STUDY

class diagrams, we now turn to the results of the UMUX survey. The results can be seen in the
following table.

The O2C Plugin’s Using the plugin is The plugin is I have to spend too Score
capabilities meet a frustrating expe- easy to use much time correct-
my requirements rience ing things with the
plugin
p1 5 4 4 2 62.5%
p2 6 1 6 2 87.5%
p3 7 2 6 1 91.67%
p4 6 1 7 5 79.17%
p5 6 2 5 2 79.17%

Table 7.2 Result of the Participants’ evaluation based on the UMUX Questions

It should be noted that the test persons are also anonymous here. Therefore, p1 is not equal to
P1 from section 7.3. The score was calculated with the following formula [Meh16]:

(scoreItem1 − 1) + (scoreItem3 − 1) + (7 − scoreItem2 ) + (7 − scoreItem4 )

score = × 100
24

The average score is 80. Compared to the SUS rating, the usability is between “good” and
“excellent” [TEC16].

77
7.3. RESULT AND ANALYSES

Figure 7.1 The evaluation object diagram

78
Chapter 8

Conclusion and Future Works

This work is based on the results of Andreas Kaertner. In his work ”On the Transformation from
Incomplete Object Diagrams to Incomplete Class Diagrams” he had developed a plugin for the
tool USE, which automatically transforms an object diagram into a class diagram. Therefore,
objects were transformed into classes and links into associations.
Even though this work laid a foundation stone, some important features were still missing. So
it was not possible to derive generalizations and Part-Whole-Relationship from the object di-
agrams. The task of this work was to extend the plugin with these two features according to
specific requirements. Therefore concepts for the interpretation of the object diagram had to be
created and implemented for the tool USE.
For this purpose the GUI was extended so that a superclass could be specified for each object.
Furthermore, new relationship types were added to the editor for aggregation and composition.
So that objects could be linked with these relationships. From this additional information it was
now possible to derive the generalizations as well as the Part-Whole-Relationship between the
generated classes. To realize this, besides the above described syntactic information, a semantics
must be created. Therefore, it has to be said how this additional information can be found in
the class diagram. These rules were created and the transformation was adapted accordingly.
With this extension, it is now possible for a developer to use aggregation and composition, as
well as generalization of the plugin. It should be noted that, as in the work of Andreas Kaertner,
errors are tolerated by the developer. Therefore, it is sufficient to specify an incomplete object
diagram. In this case the class diagram will be created as far as possible (incomplete). Any
incorrect entries made by the user are taken into account.
In order to test the usability, an evaluation was carried out. For this purpose 5 test persons
were asked to transform an object diagram by hand into a class diagram. It turned out that the
diagrams created by hand were highly consistent with the result of the automatically created
class diagram. At this point, however, it should be noted that there were deviations in the car-
dinalities. This is due to the fact that an object diagram is only a snapshot of a class diagram.
Therefore, the cardinalities cannot be uniquely identified. Furthermore, a UMUX survey was

79
conducted. The plugin was scored with a value of 80%, which indicates a high level of user-
friendliness.
Even though the plugin has been extended in this work, there are more features that can be im-
plemented in the future. For example, it is currently not possible to generate enumerations from
the objects. This could be realized by the developer specifying a value like ”color::red” for the
corresponding attribute. The enumeration ”color” could then be derived from this information.
In addition, The keyboard shortcut function has not been implemented yet, but it is one of the
features to be developed in the future work on the plugin. Indeed during the tests it would have
been easier to create an object, to copy it with the combination “CTRL+C” then to duplicate
it with “”CTRL+V””. Note that the above example is one of the many possibilities offered by
the shortcut function.
In summary, it is to be noted that the goal of our work has been achieved, i.e. a consequent
and useful improvement of the plugin in spite of the multiple improvements that are still to be
made.

80
Appendix A

Appendix

A.1 List of Figures

2.1 UML 2.4 Diagrams Overview. Source: [uml] . . . . . . . . . . . . . . . . . . . . . 4

2.2 Social Network class diagram. Source:[Gog17a] . . . . . . . . . . . . . . . . . . . 7
2.3 Classes in Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Objects in Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Aggregation in UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Composition in UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7 Summary on the characteristics of an association, aggregation and compositon in
UML [Gog14] (Aufruf: 29.11.2019) . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.8 Example of inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.9 Object Diagram of Social Network.Source: [Gog17b] . . . . . . . . . . . . . . . . 11
2.10 Imperfect Object Diagrams. Source: [And18c] . . . . . . . . . . . . . . . . . . . . 14
2.11 Imperfect Class Diagrams. Source: [And18d] . . . . . . . . . . . . . . . . . . . . 14
2.12 Overview of Transformation. Source: [And18b] . . . . . . . . . . . . . . . . . . . 15

3.1 Add an aggregation link through the input interface. . . . . . . . . . . . . . . . . 18

3.2 Edit an aggregation link through the input interface. . . . . . . . . . . . . . . . . 19
3.3 All aggregation links are changed into Association aggregation during transforma-
tion Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Similar aggregation links are merged after Transformation. . . . . . . . . . . . . . 20
3.5 Example 1 for cyclical detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Example 2 for cyclical detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.7 Example 3 for cyclical detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.8 Example 4 for cyclical detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.9 Example 5 for cyclical detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

81
A.1. LIST OF FIGURES

3.10 Add a Composition link through the input interface. . . . . . . . . . . . . . . . . 24

3.11 Edit a Composition link through the input interface. . . . . . . . . . . . . . . . . 25
3.12 Delete a Composition link through the input interface. . . . . . . . . . . . . . . . 25
3.13 All composition links are changed into Association composition during transfor-
mation Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.14 Similar composition links are merged after Transformation. . . . . . . . . . . . . 26
3.15 Example 1 for share and circle detection. . . . . . . . . . . . . . . . . . . . . . . . 27
3.16 Example 2 for share recognition. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.17 Test 3 for circle recognition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.18 Test 4 : sharing and circle detection. . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.19 Test 5 : sharing and circle detection. . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.20 Filling in the Field Superclass name . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.21 Report the presence of Superclass . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.22 Conflict detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.23 Edge of the inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.24 Inheritance edge in an incomplete class diagram . . . . . . . . . . . . . . . . . . 34
3.25 Case1: Migration and Merge Of Attributes . . . . . . . . . . . . . . . . . . . . . 35
3.26 Case1: No migration and Merge of Attributes Types(Contradictory) . . . . . . . 35
3.27 Case2: Migration and Merge of Attributes . . . . . . . . . . . . . . . . . . . . . 36
3.28 Case2: Migration and Merge of Attributes . . . . . . . . . . . . . . . . . . . . . 36
3.29 Case2: No migration and Merge of Attributes of Types(Contradictory) . . . . . . 37
3.30 Case_2: No migration and Merge of Attributes of Types(Contradictory) . . . . . 37
3.31 Case3: Migration and Merge of Attributes . . . . . . . . . . . . . . . . . . . . . . 38
3.32 Case3: No migration of attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.33 Case3: No migration of attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.34 Case4: No migration of attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.35 Case5: Merge types(Contradictory) And No migration . . . . . . . . . . . . . . . 40
3.36 Case6: Merge And No migration . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.37 Case7: No migration of attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.38 Case8: Merge types(Contradictory) And No migration . . . . . . . . . . . . . . . 42
3.39 Case9: Merge And No migration . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.40 Merge And Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.41 No migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1 Use case diagram of the System. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1 The new General Structure of Elements. . . . . . . . . . . . . . . . . . . . . . . . 54

5.2 Overview of the transformation’s steps . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Creation of Superclasses and Subclasses based on the input Objects. . . . . . . . 57

82
 APPENDIX A. APPENDIX

5.4 Presenting a sharing situation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5 A case where a cycle is created. . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.6 Example of transformation when no names were given. . . . . . . . . . . . . . . . 62
5.7 Example of transformation when names were systematic given. . . . . . . . . . . 62

6.1 The new Meta Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2 Back-end view of the test example. . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3 Superclass field in the input object properties. . . . . . . . . . . . . . . . . . . . . 66
6.4 Context menu when two objects were selected. . . . . . . . . . . . . . . . . . . . 67
6.5 Context menu when an aggregation link was selected. . . . . . . . . . . . . . . . 68
6.6 Context menu when a composition link was selected. . . . . . . . . . . . . . . . . 69
6.7 Input view to edit aggregation link name. . . . . . . . . . . . . . . . . . . . . . . 70
6.8 Input view to edit composition link name. . . . . . . . . . . . . . . . . . . . . . . 70
6.9 Input view to edit part-whole link role names. . . . . . . . . . . . . . . . . . . . . 71

7.1 The evaluation object diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A.2 List of Tables

4.1 Use case: ”add object” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Use case: ”select object/link/comp/agg” . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Use case: ”add Superclass” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Use case: ”Edit object” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 Use case: ”clone object” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6 Use case: ”add link/comp/agg” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.7 Use case: ”Edit link/comp/agg” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.8 Use case: ”Destroy object/link/comp/agg” . . . . . . . . . . . . . . . . . . . . . . 49
4.9 Use case: ”construct partial object diagram” . . . . . . . . . . . . . . . . . . . . 50
4.10 Use case: ”Revise partial object diagram” . . . . . . . . . . . . . . . . . . . . . . 50
4.11 Use case: ”Transform to partial class diagram” . . . . . . . . . . . . . . . . . . . 50
4.12 Use case: ”Export model” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.13 Use case: ”Identify uncritical items” . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.14 Use case: ”Identify missing items” . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.15 Use case: ”Identify contradictory items” . . . . . . . . . . . . . . . . . . . . . . . 52

7.1 Questions of UMUX. Source: [Fin10b] . . . . . . . . . . . . . . . . . . . . . . . . 74

7.2 Result of the Participants’ evaluation based on the UMUX Questions . . . . . . . 77

83
bibliography

[And18a] Bran Selic Andreas Kästner Martin Gogolla. “From (Imperfect) Object Diagram (Im-
perfect) Class Diagrams”. In: Publications of the University of Bremen Database Sys-
tems Group (2018), p. 2. doi: http://www.db.informatik.uni-bremen.de/publications.
[And18b] Bran Selic Andreas Kästner Martin Gogolla. “From (Imperfect) Object Diagram (Im-
perfect) Class Diagrams”. In: Publications of the University of Bremen Database Sys-
tems Group (2018), p. 7. doi: http://www.db.informatik.uni-bremen.de/publications.
[And18c] Bran Selic Andreas Kästner Martin Gogolla. “From (Imperfect) Object Diagram (Im-
perfect) Class Diagrams”. In: Publications of the University of Bremen Database Sys-
tems Group (2018), p. 3. doi: http://www.db.informatik.uni-bremen.de/publications.
[And18d] Bran Selic Andreas Kästner Martin Gogolla. “From (Imperfect) Object Diagram (Im-
perfect) Class Diagrams”. In: Publications of the University of Bremen Database Sys-
tems Group (2018), p. 4. doi: http://www.db.informatik.uni-bremen.de/publications.
[Bal17] Heide Balzert. UML2 in 5 Tagen Der schnelle Einstieg in de Objektorientierung
3.Auflage. 3rd ed. Springer Campus, 2017, p. 11. isbn: 9783961490141.
[Chr17a] Ralf Hoffmann-Elbern Christoph Kecher Alexander Salvanos. UML 2.5 Das um-
fassende Handbuch. 1st ed. Rheinwerk Computing, 2017, p. 37. isbn: 9783836260183.
[Chr17b] Ralf Hoffmann-Elbern Christoph Kecher Alexander Salvanos. UML 2.5 Das um-
fassende Handbuch. 1st ed. Rheinwerk Computing, 2017, p. 48. isbn: 9783836260183.
[Fin10a] Kraig Finstad. “The Usability Metric for User Experience”. In: Interacting with Com-
puters 22 (Sept. 2010), pp. 323–327. doi: 10.1016/j.intcom.2010.04.004.
[Fin10b] Kraig Finstad. “The Usability Metric for User Experience”. In: Interacting with Com-
puters 22 (Sept. 2010), p. 326. doi: 10.1016/j.intcom.2010.04.004.
[Gk19] Martin Gogolla and Andreas kaestner. “Design of Information Systems UML Mod-
eling Concepts and Introduction to USE”. In: 2019, p. 97. url: http : / / www . db .
informatik.uni-bremen.de/teaching/courses/ss2019_eis/.
[Gog09] Martin Gogolla. “Unified Modeling Language”. In: Encyclopedia of Database Systems.
Ed. by LING LIU and M. TAMER ÖZSU. Boston, MA: Springer US, 2009, pp. 3232–
3239. isbn: 978-0-387-39940-9. doi: 10.1007/978- 0- 387- 39940- 9_440. url: https:
//doi.org/10.1007/978-0-387-39940-9_440.

85
BIBLIOGRAPHY

[Gog14] Martin Gogolla. “Once again on Association, Aggregation, and Composition”. In:
ss2019eis (2014), p. 3. doi: http : / / www . db . informatik . uni - bremen . de / teaching /
courses//4d-assoc-agg-comp.pdf.
[Gog17a] Martin Gogolla. “Design of Information Systems UML Modeling Concepts and In-
troduction to USE”. In: 2017, p. 9. url: www.db.informatik.uni-bremen.de/teaching/
courses/ss2017_eis/1-dis-2017-Part1.pdf.
[Gog17b] Martin Gogolla. “Design of Information Systems UML Modeling Concepts and Intro-
duction to USE”. In: 2017, p. 18. url: www.db.informatik.uni-bremen.de/teaching/
courses/ss2017_eis/1-dis-2017-Part1.pdf.
[Gro] Object Management Group. OMG Unified Modeling Language(OMG UML) version
2.5.1. url: https://www.omg.org/spec/UML/2.5.1/PDF. (accessed: 06.11.2019).
[Kae17] Andreas Kaestner. “On the Transformation from Incomplete Object Diagrams to
Incomplete Class Diagrams,Master Thesis,Fachbereich Mathematik und Informatik”.
In: 2017.
[Kuh07] Mirco Kuhlmann. “A UML-based Specification Environment”. In: (2007). url: http:
//www.db.informatik.uni- bremen.de/projects/USE- 2.3.1/#overview. (accessed:
16.12.2019).
[LR06] Bernhard Lahres and Gregor Raýman. Praxisbuch Objektorientierung: von den Grun-
lagen zur Umsetzung. 1st ed. Galileo Computing, 2006. isbn: 3898426246.
[Meh16] Dilek Karahoca Mehmet Ilker Berkman. “Re-Assessing the Usability Metric for User
Experience (UMUX) Scale”. In: 2016. url: http : / / uxpajournal . org / wp - content /
uploads/sites/8/pdf/JUS_Berkman_May2016.pdf.
[Oes09] Bernd Oestereich. “Analyse und Design mit UML 2.3 Objektorientierte Softwareen-
twicklung”. In: Deutsche National Bibliothek, 2009. Chap. 2.9.
[Ora04] Oracle. “About the JFC and Swing”. In: (2004). url: https : / / docs . oracle . com /
javase/tutorial/uiswing/start/about.html. (accessed: 27.02.2019).
[Ric02] Mark Richters. “A precise approach to validating UML models and OCL constraints,
Ph.D. Thesis, Universitat Bremen, Fachbereich Mathematik und Informatik, Logos
Verlag, Berlin, BISS Monographs, No. 14”. In: 2002.
[SOU] SOURCEFORGE. USE: UML-based Specification Environment. url: https://sourceforge.
net/projects/useocl/. (accessed: 16.12.2019).
[SOU04] SOURCEFORGE. “SOIL”. In: (2004). url: http://useocl.sourceforge.net/w/index.
php/SOIL. (accessed: 16.12.2019).
[TEC16] TECFA. “Échelles d’utilisabilité”. In: 2016, p. 11. url: https://tecfa.unige.ch/tecfa/
maltt/ergo/articles/P3/echelles_utilisabilite_(Lallemand2016).pdf.
[uml] uml-diagrams.org. UML 2.4 Diagrams Overview. url: https://www.uml- diagrams.
org/uml-24-diagrams.html. (accessed: 06.11.2019).

86
 BIBLIOGRAPHY

[Uni17] Carnegie Mellon University. “Depth First Search and Strong Components”. In: 2017,
p. 10. url: https : / / www . cs . cmu . edu / ~15451 - f17 / lectures / lec11 - DFS - strong -
components.pdf.

87
89
Appendix B

Evaluation sheets

90

P1
APPENDIX B. EVALUATION SHEETS

91
 P2

92
APPENDIX B. EVALUATION SHEETS

93
 P3

94
APPENDIX B. EVALUATION SHEETS

95
 P4

96
APPENDIX B. EVALUATION SHEETS

97
 P5

98
APPENDIX B. EVALUATION SHEETS

99
  )ORZ)ORZ)ORZ6XUYH\

]avå]avå]av1pluMx
;IPGSQIXSXLMWWYVZI]-RSVHIVXSLEZIJIIHFEGOJVSQ]SYVI\TIVMIRGIYWMRKXLI4PYKMR3'
[I[ERX]SYXSERW[IVXLIJSPPS[MRKWXEXIQIRX[MXLSRISJXLITSWWMFPIGLSMGIW
6IQIQFIVXLIVIMWSRP]SRIKSSHERW[IV=SYVERW[IV
6IUYMVIH

 3mU_SoTMi]pSU_Um@Rlpmol@oU_SMwiMlUM_IMÈÓ

1EVOSRP]SRISZEP

      

-WXVSRKP]HMWEKVII -WXVSRKP]EKVII

 2TM%š -]pSU_õmI@i@HU]UoUMm^MMo^xlMkpUlM^M_omÓ

1EVOSRP]SRISZEP

      

-WXVSRKP]HMWEKVII -WXVSRKP]EKVII

 2TMi]pSU_UmM@mxoapmMÓ

1EVOSRP]SRISZEP

      

-WXVSRKP]HMWEKVII -WXVSRKP]EKVII
100
APPENDIX B. EVALUATION SHEETS

101
  )ORZ)ORZ)ORZ6XUYH\

 T@uMoamiM_Koaa^pIToU^MIallMIoU_SoTU_SmvUoToTMi]pSU_ÈÓ

1EVOSRP]SRISZEP

      

-WXVSRKP]HMWEKVII -WXVSRKP]EKVII

8LMWGSRXIRXMWRIMXLIVGVIEXIHRSVIRHSVWIHF]+SSKPI

8ad_e

102