Bachelor Degree Project
Developing a UML extension for the GUI.
Author: Andreas Constantinou, ac222qf Supervisor: Diego Perez
Semester. HT 2019 Subject: Computer Science
ii
Abstract
The graphical user interface (GUI) could have a major impact on the success of an application. Like any other software component, the GUI is designed before being developed. The software design process usually starts with an abstract design that is illustrated via a modeling language and narrows down to more specific details during the process. However, there are not any modeling languages that are explicitly focusing on designing the blueprint of the GUI. Developing a modeling language that is specialized in designing the skeleton of the graphical user interface could offer the software designers, architectures and clients the means of obtaining a better communication and understanding. Thus, developing a better product. In this report, the development of such a modeling language was made. The modeling language can illustrate the blueprint of the GUI. The development process was made after researching and finding the most suitable development procedures for our modeling language.
Keywords: Software architectures, software designers, software design, modeling language.
iii
Contents
1 Introduction 1
1.1 Background 1
1.2 Related work 2
1.3 Problem formulation 2
1.4 Motivation 3
1.5 Objectives 3
1.6 Scope/Limitation 3
1.7 Target group 4
1.8 Outline 4
2 Method 5
2.1 Modeling languages 5
2.2 Developing the DSML 6
2.3 How to create the DSML 7
2.4 Process 8
2.5 Reliability and Validity 8
2.6 Ethical Considerations 9
3 Results 10
3.1 Set the Requirements 10
3.2 The type of diagram 12
3.3 Refining the diagram 12
3.4 Metamodeling 13
3.5 How to overcome metamodeling disadvantages 13
3.6 OCL 13
4 Domain model 13
4.1 Defining the domain model 14
4.2 Designing the domain model 14
15
5 Defining the concrete presentation 16
5.1 Instantiating the modeling language 16
5.2 Profiling 16
5.3 Mapping 18
5.4 OCL 20
6 Getting feedback and improving the modeling language 22
iv
6.1 Satisfying the requirements 22
6.2 Setting an example 23
6.3 Analysing and solving the example with the modeling language 23
6.4 Evaluation 25
6.5 Improving the modeling language 26
6.6 Results of the upgrade 29
6.7 Comparing the requirements 29
7 Discussion 31
8 Conclusion and Future Work 32
References 33
A Appendix - Interviews 35
A.1 Interview with the computer science graduate 35 A.2 Interview with the business administration graduate. 35
A.3 Interview with the senior developer 36
B Appendix - Metamodel development 38
B.1 How to overcome metamodeling disadvantages 38
B.2 Gathering the modeling elements 38
B.3 Defining the content of the metamodel 39
B.4 Description of the metamodel 42
1
1 Introduction
Before creating software, before implementing it, to coordinate all the developers and distribute the workload among them, the designing of the software is taking place. The design of the software also helps for defining methods, objects, functions or the overall structure of the software.
Furthermore, a visual representation of the software as a whole, or different representations of the components of the software would provide better communication among the developers and the clients [1]. After all, this graphical representation is made to simplify the complexity of the hole software, or the parts of the software by visualizing them in a specific and defined language, this type of language is named modeling language (ML).
The GUI (Graphical User Interface) of an application, depending on what that application is intended for, might have a huge impact on the success of that application. Therefore, to build a desirable GUI, a careful design of the GUI should take place. As a part of the software, the GUI should be modelled before being created with the use of a modeling language in order to beget easier communication between the stakeholders, in our case developers and clients. Since the most common modeling language is the Unified Modeling Language (UML), a type of diagram could exist born from that language that would be used strictly for visualizing the GUI at a high level. This thesis explores such a possibility.
1.1 Background
Software design is a phase in the software development that takes place before the implementation. Moreover, it is the process of analysing and, defining methods objects or the overall structure of the intended software.
There are numerous reasons behind the importance of this process being followed, for example, preventing redundancy, increasing reusability, helping the owners and the developers to get a clear idea of how the software would be functioning, as well as improving the communication [1].
Graphical visualizations help by visually representing complex parts of software, these visualizations in other words diagrams, are part of the design process. Thus, by using them, the clients and the developers can have a better understanding that leads to better communication.
These diagrams are made by using any Modeling Language (ML), one of
the most used ML, and also the ML that this research would focus on
extending is the Unified Modeling Language (UML). UML has the ability to
categorize its diagrams into two different views of a system model, which are
the static and dynamic view [2]. The dynamic view emphasizes the run-time
view of the represented system, while the static view emphasizes the static
structure of the system [3].
2
1.2 Related work
Mock-ups are full-sized or scaled models that can be used to demonstrate the GUI of an application. Mockups can represent the basic functionality or the basic notation principle of an application before its creation [4]. They are mainly used to acquire feedback from users. Furthermore, mockups are created by the use of tools, and, depending on the intended model those tools may differ. However, there is no standardized graphical modeling language that these mockup tolls use in order to model the GUI of an application [4];
every mockup tool has its own stereotypes. Moreover, the graphical modeling language that this thesis develops is intended to be used for the development of the GUI, not to present the GUI when it is completed.
Maria (Model-based lAnguage foR Interactive Applications) is an XML- based user interface markup language that is used for modeling interactive applications. Moreover, the language has an Abstract User Interface (AUI) level that describes a User Interface (UI) [5]. The description of the UI is managed through the semantics of the interaction. The language does not present any execution methodology, device ability or implementation technology [5].
An extension of the UML language that adds support for representation commonly occurring in user interfaces is named UMLi [6]. UMLi models the GUI in terms of its internal structure and objects comprising it. The extension is not explicitly focusing on the GUI as it visualizes other aspects of the software, for example, the interaction with how the GUI is interacting with other components of the system [6]. In other words, UMLi also represents other components of the application. Unlike the indented graphical modeling language of this thesis that is only focusing on the GUI thus, be able to be used by a wider audience that does not have any knowledge in computer science. Moreover, UMLi does not have the necessary stereotypes for visualizing a GUI in detail it is more focused on in the integration of the GUI with other components.
IFML [7] is a graphical modeling language that can be used to express the user interaction, expressing the content and control behavior of the front- end of software applications. The language is very similar to WebML [7] as it is inspired by it. However, the language requires some software development knowledge to be clear as it includes some software related terminology and visualization. For example, what kind of event is triggered when an option is clicked, or what kinds of data type can an input take.
1.3 Problem formulation
A graphical modeling language should exist, that only focuses on presenting
the GUI frames and the interaction between them. The modeling language
3
should present the GUI at a high level, in order to be understandable, easy to use and more time-efficient. The modeling language could be used to make the client or the software developers have a better understanding of the content, the abilities and the possible notation of every frame. The result would be visualizing the bone structure of the GUI. The language would also have a navigation system to display which frames are related to each other and how can the user navigate through them. Moreover, it would not include any internal components of the software it would only be focusing on displaying the GUI’s skeleton.
1.4 Motivation
The modeling language could save time by minimizing the chance of future changes in the GUI. It could also help the customer, the GUI designers, and the developers to get a better understanding of the finalized product. The extension would help to make sure that the GUI would be designed as the customer desires. It could also help the designers of the GUI to communicate, specify and construct the visualization of each frame. Developing such a language would be challenging since it would be created to be easy to understand and used, it should have similar simplicity with a domain model and being able to visualize the blueprint of the GUI.
1.5 Objectives
O1 Find a list of current difficulties for GUI design modeling with IFML, UMLi, UsiXML.
O2 Set the requirements.
O3 Research on how UML extensions can be created.
O4 Create a domain model of the extension’s design features.
O5 Create the UML extension.
O6 Take feedback for it from software developers and non-software developers.
O7 Use feedback to improve the extension.
The expected result of this thesis is creating a new modeling language that would be able to visualize any GUI at a high level.
1.6 Scope/Limitation
The scope of this thesis is to develop a modeling language that would be able
to visualize the blueprint of the graphical user interface of an application
before creating it. This thesis is not making a comprehensive comparison of
already existing modeling languages that are focusing on the same area.
4
1.7 Target group
The target groups of this thesis are the clients, software designers will use this language to communicate with clients in the early stages of the development.
1.8 Outline
The following chapter (Chapter 2) describes the methodology that was
followed for developing the modeling language. In Chapter 3 the
requirements of the language are set. In Chapters 4, 5 and 6 the development
process and the results are presented. In Chapter 7 the development is
finalized, followed by Chapter 8 that includes the discussion and Chapter 9
that presents the conclusion and the future work.
5
2 Method
For a better understanding and better results on how to develop our modeling language, we conducted a literature review on this area. After gathering the results and developing our own modeling language we conducted closed interviews with software developers and students that study in the field of computer science, to get feedback on our modeling language and improve it.
2.1 Modeling languages
Modeling languages are adjusted tools specialized for providing designers the ability to formalize their contemplations and conceptualize their ideas in models that are textual or graphical. This thesis is focusing on creating a graphical modeling language. Moreover, there are two modeling language concepts:
Domain-Specific Modeling Languages (DSMLs or DSLs) are languages that are planned deliberately for a particular area, setting, or organization, to facilitate the errand of individuals that need to portray things in that area [8].
General-Purpose Modeling Languages (GPMLs or GMLs/GPLs) are more general modeling languages that can be connected to any segment or area for displaying purposes [8].
A modeling language can be defined by three core aspects:
● Abstract syntax: Describing a language’s structure, also how the various natives can be joined together, freely of a specific portrayal or encoding.
● Concrete syntax: Describing explicit portrayals of the displaying language, covering encoding or potentially visual appearance issues. This syntax can be either literary or graphical. In our case where the language structure is visual, one or more diagrams would be required.
● Semantics: Describing the significance of the components
characterized in the language and the importance of the various methods for
joining them.
6
Figure 2.1: How are the three core aspects of a modeling language connected.
Furthermore, since this thesis is focusing on creating a new modeling language that would represent the blueprint of an application’s GUI, the outcome is a DSML. The scope of the intendant language is focusing particularly on the graphical user interface of an application and the modeling language could only be used for its intended purpose.
2.2 Developing the DSML
The lack of an established theory of modeling language design is a major impediment and should be taken into account when considering whether or not to define a brand-new DSML, even if there is adequate domain expertise available. A more prudent approach would be to model a DSML on an already established and proven modeling language. There are three primary methods for defining a DSML, two of which are based on reusing an existing modeling language:
1. Refinement of an existing more general modeling language by specializing in some of its general constructs to represent domain-specific concepts [9].
2. Extension of an existing modeling language by supplementing it with fresh domain-specific constructs [9].
3. Definition of a new modeling language from scratch. The last of these has the potential for the most direct and succinct expression of domain-specific concepts. However, it suffers from the serious drawbacks described previously [9].
Defining a new modeling language from scratch is not as practical and
efficient as the other two options. An augmentation based on an existing
modeling language permits the reuse of the tooling frameworks of the base
language, access to a more extensive base of trained experts, and less
specialized training is required. Also, creating a brand new modeling
language would have less chance to succeed than integrating a new interface
modeling technique with an existing modeling language. Since the new
language would be infamous, and, it would require learning effort, it is
7
highly unlikely to be preferred.
Alternatively, integrating the interface modeling technique with UML, is an elegant solution, since most of the university graduates and experienced software developers are familiar with UML [10]. Moreover, UML gives a wide arrangement of augmentation instruments which are stereotypes, constraints, tagged values, and profiles. These angles are dealt with inside the profile diagram, which expressly centres around the extensibility viewpoints.
It works at the metamodel level to demonstrate generalizations as classes and profiles as bundles. The expansion connection demonstrates what metamodel component a given generalization is broadening.
However, the solution of refining a specific more general modeling language would also be beneficial in many ways. Using UML will benefit our modeling language for the reasons that are presented in the previous paragraph. Furthermore, using one of the UML diagrams as a base and specializing some of its general constructs to represent the domain-specific concepts of the new modeling language will be an efficient and elegant solution. Moreover, since most of the university graduates and experienced software developers are familiar with UML and the UML diagrams are refining an already existing diagram, refining was considered to be the best thus the chosen option.
2.3 How to create the DSML
In order to create an extension of UML, the new means of the extension have to be supported by profiles. One of the most popular approaches to designing profiles is by defining stereotypes and by dividing them into two stages.
The first stage is to define the conceptual constructs required to cover a specific domain the product of this stage is usually called the conceptual domain model of the profile.
The second stage is conducted by implementing UML extensions in the form of stereotypes and their properties and constraints. The downside of structuring conceptual domain models for profile configuration is the required time. The design would most probably need cumbersome refinement procedures to ensure DSML language structure and semantics that agree to the reasonable model. Building theoretical area models and keeping up recognizable mapping with the profile are therefore accomplished at the cost of impressive exertion [11].
A different approach is the systematic model approach. This approach
suggests an orderly change of area portrayals (caught in a metamodel) into
profile (caught in stereotypes and requirements) [11]. Moreover, in order to
design a UML profile, the domain model should be created, followed by a
definition of its skeleton by providing stereotypes, and, lastly getting
feedback and improving. This approach was found to be the most efficient,
effective and most suitable for our modeling language. Getting feedback
from computer scientists for improvement was considered extremely
beneficial since the language should be acceptable and used by them. This
technique was chosen for designing our DSML. For better results the
diagram that was used for refinement was chosen after gathering the
8
requirements, the choice for that diagram is presented and discussed in the section after the requirements are presented. The process is displayed in greater detail in the next section.
2.4 Process
• Step 1: Modeling domain analysis: Three perspectives must be considered in the main period of building up the modeling language: the reason, acknowledgment, and substance of the language [12]. Thus, the modeling domain was developed first.
• Step 2: Profile Skeleton Definition: The definition and the mapping of the stereotypes were conducted in this phase. Furthermore, the followed process consists of developing the abstract and concrete syntax of the modeling language with the usage of OCL and profiling.
• Step 3: Modeling language approval: The resulted modeling language is instantiated by displaying the reference guides to approve the fulfilment and rightness of the created metamodel. Moreover, other general standards of language plan, for example, effortlessness, consistency, versatility, and coherence likewise must be considered [12]. The consequence of this progression gives significant criticism to the following cycle of the metamodel improvement process.
Figure 2.2: The figure illustrates the process.
2.5 Reliability and Validity
The strategy that was followed in this task is a literature review and closed interviews for feedback. Furthermore, due to the approach of this technique, the unwavering quality of this theory depends on the work that has been researched. It comes without inquiry that we utilized reliable audited sources, which have been additionally sifted and judged, contingent upon the nature of their substance just as the unwavering quality of their relating distributor.
The outcome of this venture ought to be substantial since they avoid
incorporating any closely-held conviction or estimation. Rather the outcome
is an accumulation of information, in view of the consequences of past
research. Potential estimations and theories about the nature of this subject
were conducted in the discussion segment, as a feature of an individual
comprehension of what may occur in this field later on.
9
2.6 Ethical Considerations
The data collected from the interviews were handled according to the
Swedish personuppgiftslagen(PuL) to protect the participants. All the sources
that were utilized are distributed on the web. Past work has been
appropriately referred to and the source material has been treated with
deference.
10
3 Results
This section sets the requirements and the tools for improving the development are presented.
3.1 Set the Requirements
The goal of the language is to provide system architects, software engineers, software developers and software owners with apparatuses for portraying the essential elements of the Graphical User Interface of an application.
Moreover, the visual objects that would be included in the GUI, the visual outcome of user interaction with them, and, the possible notation between them, with respect to the perspective of a user. To reach that goal, the language should be comprehensible for both, people with and without any software development knowledge, the software owners. Moreover, in the following tables, the requirements that the modeling language should satisfy are presented.
Non-functional requirements
1. Improve the development procedure, by cultivating the division of the concerns within the user interaction processes.
2. Empower the communication between software developers and non- technical stakeholders.
3. The specification can be used for the early phases of product development.
4. It does not require a computer science background to be comprehensible.
Table 3.1: The table presents the non-functional requirements.
Functional requirements
1. Provide a high-level visualization of the GUI’s composition and content, possible user interaction points, routes and route
alternatives.
2. Visualize the dynamic behaviour of the visible elements included in
the GUI, with respect to the user's view.
11
3. The synthesis of the view, as far as its segment into autonomous representation units, which can be shown simultaneously or in shared avoidance, and, can be settled progressively.
4. Visualize the view content, as far as both, the visualization objects distributed from the application to the user, and, the possible direct information inputs from the user to the application.
5. The possible user interactions with the GUI, possible user inputs.
6. The actions that can be triggered in the GUI from the user's interaction, with respect to the user’s inputs.
7. The possible notations between the GUI frameworks.
Table 3.2: The table presents the non-functional requirements.
Moreover, being able to provide an effective, easily operated, and, easily understandable modeling tool, the following factors should be applied:
Extensive functional requirements
1. It is brief, dodging repetition and decreasing the number of diagram types and ideas expected to express the striking interface and cooperation structure choices.
2. It incorporates extensibility in the meaning of new upcoming innovative or alternated ideas.
3. It includes a standard set of visualization tools, that are set to visually remind their representative elements.
Table 3.3: The table presents the extensive functional requirements.
By satisfying the given aspects, and, requirements the new modeling language would not be too broad or specific. Thus, its usability would increase. Since we are working with UML, after researching on how to integrate a modeling technique with UML, the following principles have been found necessary:
UML requirements
1. The incorporated proposition should be inconspicuous, by sustaining standard UML aspects
[13].
2. The incorporated proposition should bolster the desires for GUI
modelers who have experience utilizing existing interface-
12
modeling systems
[13].
3. The incorporated proposition should bolster the desires of current UML modelers, whose involvement with UML should help when utilizing interface-explicit augmentations
[13].
4. The new UML models provided by the proposition should be as few as possible
[13].
Table 3.4: The table presents the requirements that a modeling language must follow in order to be considered as UML.
3.2 The type of diagram
UML diagrams are divided into two categories structural and behavioral [3].
The structure diagrams are illustrating the structure of the system being modelled; they are widely used in documenting the software architecture of systems. On the other hand, behavior diagrams focus on what must happen, they represent the behavior. The use of behavior diagrams is for describing the functionality of a system.
After gathering and analysing the requirements we concluded that the best option for our modeling language is to belong in the structure diagrams family.
Moreover, our modeling language would be visualizing the view content, providing a high-level visualization of the GUI’s composition and content, the possible notations between the GUI frameworks. These attributes are illustrating the structure and not the behavior. Thus, the decision of following the structure diagrams family was taken.
3.3 Refining the diagram
Since we decided refining a UML diagram, and narrowed our options into structural UML diagrams, after researching the structural diagrams of UML we have chosen the object and the class diagram to be the better options for our purpose. Since, the diagrams are describing the structure of a system, and have the right modeling elements for our purpose.
By refining the object diagram, the GUI could be demonstrated by using
the interaction objects. The object diagram can provide the right base for our
modeling language since it can be used for demonstrating a “road map”, fill
with frameworks instead of objects [14]. However, choosing these interaction
objects will in general, be significantly more challenging when it comes to
GUI design. Since, UML does not give graphical refinement among space
and association objects. Moreover, visualizing the GUI with the object
diagram leaves some important parts of the GUI not included. It is generally
hard to model these undertakings because of the substantial number of
interaction objects with various functionalities given by the graphical user
interfaces.
13
On the other hand, using the class diagram would be more beneficial.
The class diagram already acquires the ability to present the notation and the content of a class [14]. Thus, refining the class diagram would be an efficient and elegant solution. Furthermore, the structure of the class diagram allows the description and presentation of the content of the GUI more freely than the object diagram (for example, by using attributes and the type of the values). Refining the class diagram would provide a specific, flexible and solid modeling language.
3.4 Metamodeling
Models need to pursue an unmistakably characterized structure (precisely like program code), i.e., they need to comply with the related metamodel representing the abstract syntax of the demonstrating modeling language.
Having a well-defined structure is the reason for applying activities on models, for example, stacking/putting away models from/to demonstrate archives, questioning and changing the substance of models, and checking the well-formedness of models to give some examples conceivable tasks. The fundamental purpose behind this is other language viewpoints going past the language's conceptual linguistic structure, for example, the meaning of the visual documentation to be utilized when displaying, are intensely founded on metamodels
[8]. Moreover, the implementation of the desired DSML can be achieved by using metamodeling as the central technique.
3.5 How to overcome metamodeling disadvantages
In appendix Section B we show the procedure that we followed in the first attempt of creating the modeling language and we discuss in detail about this matter.
3.6 OCL
A disadvantage of profiling is the modeling constraints. Some limitations on
the future created models cannot be described just by using graphical
elements. OCL was used to resolve this issue. OCL is a part of the UML
standard and it is a declarative language that is used for describing the rules
of UML models. By using OCL to describe the rules that are not possible to
describe with the graphical elements, several issues might be avoided. OCL
invariants can also describe modeling rules. Rules that are not displayed,
instead they are followed when the modeling language is used. For example
naming, an OCL invariant could be used to explain the rule that all the
attributes names need to begin with a lowercase letter.
14
4 Domain model
This section presents the development of the domain model.
4.1 Defining the domain model
The first step was defining the domain model which would be the baseline of the intendant UML extension. In spite of the fact that the domain model can manage the description of the modeling language advantages, for example, understandability, the reuse of existing modeling elements is vital for a detailed description of the goal, in the objective DSML. Furthermore, the domain models description abilities are distinguished in four classifications:
1. Theoretical ideas, which are extra ideas that assistance to clear up other existing ideas in the area of intrigue [11];
2. Firm ideas, which are constantly utilized as language builds [11];
3. Dubious ideas, whose definite job is "uncertain" inside the visualized expansions [11];
4. Parametric ideas that can change, contingent upon the diverse sub-issues of an area (for example semantic variety focuses) [11].
4.2 Designing the domain model
Language purposes - Theoretical ideas: The language was designed to be used for modeling the GUI of an application. In advance, it was decided to include all the frameworks or views of the GUI and their content (including popup windows, warnings, etc.) that are visible to the user. The notation between the GUI frameworks would also be included.
Language realization - Firm ideas: To support the modeling of different GUI types a graphical syntax and a textual syntax were decided to be provided. The graphical syntax in combination with the textual syntax should be able to describe various types of GUIs, from smartphone applications to web applications.
Language content - Parametric - Dubious ideas: As it is noted in the previous sections the intended modeling language would be constructed to visualize the GUI of an application depending on the user’s perspective. It should not include any internal components of the application nor any functionality aspects. Having that in mind, the domain model of the extension is presented below in figure 4.1 as with the following explanation behind the reasoning of this domain model.
The model was designed to contain an unrestricted number of classes,
the classes are representing the frameworks. The classes would include the
content of the frameworks, representing it with fields that would have name
and type assigned to them. For better organization and management the
frameworks can be extended, thus one or more classes can represent a
15
framework. Moreover, the classes can be held into a group entity if they represent the same framework and it is needed for better organization.
Possible notation between frameworks would be visualized as associations between classes and input attributes as an effect from the input attributes.
The corresponding attribute would be directly associated with the framework that it is leading to, since the input would dictate the notation between the classes/frameworks. The pop-up windows would be the result of the input fields.
Furthermore, the buttons were designed to consist of three types of close window, parametric and button. The close window type of button was designed to be included in any pop-up window to demonstrate and emphasize its nature. The close button imprics the discretion ability of the pop-up windows. The parametric button as shown the figure 4.1 follows the verification; the usage of the parametric button is when evaluating the input fields is needed. In combination with the verification, the decision of the destination would be applied. The button is any button that could be included in the GUI, without any navigation abilities.
Figure 4.1: The domain model.
16
5 Defining the concrete presentation
In this section, the presentation and definition of the language’s stereotypes were performed.
5.1 Instantiating the modeling language
A common technique to visualize frameworks, attributes, and associations in object-oriented metamodeling languages for defining metamodels are object diagrams
[8]. Moreover, this technique is promoting further and better illustration of relations between metamodel and model level and abstract with concrete syntax. The frameworks would be represented by objects, the attributes by values and the associations by links.
5.1: Instantiating the modeling language with an object diagram 5.2 Profiling
The following figures were used for illustrating the profile diagrams of the
modeling elements in our modeling language.
17
Figure 5.2: The association types that were chosen for our modeling language and the exceptions that they include.
Figure 5.3: The content element of our modeling language and the types of content the fields and buttons.
Figure 5.4: The figure illustrates the framework stereotype.
18
Figure 5.5: The figure illustrates the group entity stereotype.
Figure 5.6: The figure illustrates the popup stereotype.
5.3 Mapping
In this section the concrete syntax of the modeling language is present. Since the class diagram was used to be refined in order to construct our modeling language, the modeling elements that are used are refined modeling element of the class diagram modeling elements.
Stereotype Constraints UML
Metaclass
Icon
<<Framework>> UML::Kernel
::Class
19
<<Group Entity>>
Can only contain two or more classes.
UML::Kernel ::Package
<<Content>> UML::Kernel
::Attribute
<<Notation>> UML::Kernel
::Notation
<<Parametric Notation>>
UML::Kernel ::Dependency
<<PopUp>> UML::Kernel
::Object Table 5.1.: Presenting the modeling elements
Framework: They visualize the frameworks of the GUI. If a framework does not extend another framework then it has a unique name. Frameworks can have relationships with other frameworks. One or more framework can extend a single framework; they can have parts of it. One framework can navigate to another framework, and also represent a popup window. Since we are refining the class diagram the class modeling element was chosen to represent the frameworks due to their similarity. They both are unique, can be extended and can include content.
GroupEntity/Package: If two or more classes are representing the same framework, they can be held into a package. The package, in that case, symbolizes the one framework that the classes are representing. The class diagram includes packages with a different meaning. The class diagram is made to visualize object-oriented languages which can include a set of classes in the same package. This does not imply that the classes are the same class or that they are inheriting from a superclass that is the package. The role of the package was changed in our modeling language since its role is to represent a class only if one or more classes are inheriting from the main class which is symbolized by the package itself.
Content/Attribute: They are services a class provides. They represent the
interactive or non-interactive content of a framework, if a given type is given
to them they can be declared if they can have an input from the user and what
20
kind of input f.e. <<type = input-String>>. Attributes are parts of a class. An attribute can navigate to another class if that attribute takes an input and that input is responsible for navigating to another class. The attribute was chosen to represent any content, as a unique. Furthermore, every type of button, list, input, etc. can be visualized as an attribute in a class, we chose the attribute to represent the content for the reason that similar to the class diagram which displays the functions in a class the best and more reasonable candidate for representing the content is the attribute. A class has functions, and the GUI has content elements.
Inheritance: When one framework is extending another framework, the notation type inheritance is used. The extended framework is inheriting from the main framework. The inheritance association is the best candidate for representing the inheritance of frameworks in our modeling language, it applies the same logic.
Notation: The notation visualizes the possible navigation from framework to framework. If a notation is named and the first letter is a capital letter then the notation is representing a button when it is triggered. In addition, a notation may also include a short, two-word description of the notation that starts with a lowercase letter. There are two types of notation parametric and navigational, the parametric was designed to be used if the input fields need verification before proceeding to the next framework. The navigational was designed in order to illustrate the simple navigation without any needed verification. The association for notation was chosen for the notation between the frameworks in our modeling language, for the reason that it has the same reasoning with the notation of the class diagram. The distinguishing characteristic between the navigational and the parametric notations is that the parametric notation refines the dependency of UML instead of the notation.
Popup: The popup is presenting any popup windows that may occur in the GUI. The popup does not contain any content except a close button.
5.4 OCL
As we discussed in the previous section OCL would be employed for describing the limitations that cannot be characterized by metamodeling.
Well-formedness rules:
Rule 1: Every framework must have a unique name.
context Diagram inv:
self.frameworks -> forAll( x,y | x <> y implies x.name <> y.name)
21
Rule 2: frameworks can not have non-contextual associations that start from the same framework and end in the same framework. This would result in an infinite loop and disrupt the notation.
context Framework inv:
not self.association -> select(l | l. association) -> exists (l | l.target = self) Rule 3: Any attribute that is contained in a framework must also belong to the content of the representing framework.
context Framework inv:
self.attribute -> includes(framework.Content) Modeling guidelines:
Rule 4: All framework names must start with a capitalized letter.
Context Framework inv:
if self.name.size() >= 1
then self.name.substring(1,1).toUper() = self.name.substring(1,1) else false
endif
Rule 5: The attribute names must start with a lowercase letter.
context Attribute inv:
if self.name.size() >= 1
then self.name.substring(1,1).toLower() = self.name.substring(1,1) else false
endif
Rule 6: The notations that start with a uppercase letter represent a button.
context Framework inv:
if self.notation.name.size() >= 1
Then if (self.notation.name.substring(1,1).toUper) Then self.notation.oclIsKindOf(self.content.button) Else false
Endif
Endif
22
6 Getting feedback and improving the modeling language
In the following section, we discuss how our modeling language satisfies the requirements that we set in Chapter 3. The requirements that cannot be answered yet (for example, the language to be preferred) are not included.
In order to see if the new modeling language is up to the standards that we proposed, firstly we evaluate the language by answering how it is satisfying the requirements that we proposed. Further, as means of verifying the proposed language, we provided an example of the language and analysed the feedback from the interview participants and came to a conclusion on what do we need to improve or change in our modeling language. This step verifies the proposed language.
6.1 Satisfying the requirements
From the second Section (table 3.2) in Chapter 3.
R1: This requirement is satisfied since the language is giving the ability to represent any content; interaction points routes and the route alternatives with the use of classes and associations.
R2: Visualizing the dynamic behavior with respect to the user's view is accomplished by using the notations and the attributes; in combination, they represent the possible transition or any dynamic behavior the GUI can have that would be visible to the user.
R3: The synthesis of the view and the autonomous representation units that can be displayed simultaneously can be visualized by frameworks and contextual associations.
R4: The visualization objects are represented by frameworks, the possible input of input can be represented by attributes in the frameworks.
R5: This requirement is satisfied by the use of attributes. The attributes can display the type of input and the input point.
R6: The visible actions that can be triggered by the user are viewed by notations and frameworks.
R7: The possible notations between the GUI frameworks are represented by associations.
From the fourth Section (table 3.4) in Chapter 3.
R1: Sustaining standard UML aspects was achieved by using standard UML procedures for the development.
R4: The modeling language does not introduce any new modeling elements.
It is refining existing ones.
23
The discussion and evaluation of the ability of the language to satisfy each given requirement has shown that the language is able to satisfy the given requirements.
6.2 Setting an example
Example: The example is a web application; the example is taking place in the browser. Simple email application, (SED).
Description: In order for a user to use the email application (SED), the user must have an account. If the user already possesses an account they can log in by using their credentials, otherwise, they have to create one. When the user is logged in they can see their latest inbox (25 emails per page) the option to create a new one and the option to search for an existing email.
In order to see more inbox emails there is a small arrow on the bottom of the page that points to the right (->) and if it is clicked the previous 25 received emails would be displayed. If the user wishes to go even further they follow the same pattern.
If the user wishes to write and send an email they can click on the create a new email button. They are taken to a new page and synthesize their email.
If the email is lacking the receiver a warning appears that declares that they did not include any receiver.
When they are done with the email and have included a receiver they can click the send button and the email would be sent. As soon as the email is sent it will be listed in the sent emails, and the users are guided back to the previous page. If the user clicks on that option then the last 25 sent emails would appear instead of the received emails (replace them). If the user wants to see more they can follow the same procedure as the received emails.
If a user wants to search for an email, they write a key work on the searching bar and click on the search button, if an email exists that includes the same keyword it would appear by replacing the received list. If no email exists that includes that keyword the list would be empty.
The user should be able to see the option of logging out within the page, if they click on it they log out and go back to the first page where they had to add their credentials to log in.
6.3 Analysing and solving the example with the modeling language
After analysing the text we see that we have four different pages Login,
Register, Homepage, Create-Email, Warning. Since the modeling language
applies that every framework/page should have at least one framework
representing it, we would have three different frameworks and one warning
at first. The Login page would ask for the credentials of the user if they have
24
an account they can log in with them and move to the Homepage. If they do not have they would have to register, so they would be guided to the Register framework. Thus, the Registration framework should have two notations, one to the Register framework and, since the credentials of the user will be evaluated, one parametric notation to the Homepage.
The Registration framework can only lead to the Login page after the user subscribes to the SEP they guided to the login page and there they input their credentials to log in. Thus, the Registration framework should have a notation with the Login framework.
When the users are logged in they would have the options to see their received, sent, search for an email or create an email.
Creating an email would lead them to a different page, so notation should exist from the Homepage to the Create-Email framework. When the user synthesis an email and tries to send it from the Create-Email framework the possibility of not including a receiver exists, so if they do not include any receiver a Warning window appears that declares that. The Create-Email framework should have a parametric notation to the Warning, the Warning could just have the close attribute in order to close. After the user is done with sending the email they are led back to the Homepage, thus annotation should exist from the Create-Email to the Homepage.
The Homepage as a default displays the latest 25 received emails and gives the possibility to navigate to older emails. The same list is replaced with sent emails if the users click to see their sent emails and searched emails if the user searches for an email. Moreover, the options to navigate to the sent, received, search and create email could be placed in one main framework that is representing that page. The lists will be presented in other frameworks that inherit from that framework in order to have an explanatory graphical visualization of the abilities of that list.
Since the sent and search lists are replacing the received list they could inherit from the received list framework. This would enforce the representation of the nature of the list. In addition, since the user will be able to see older emails that have been sent, received, or share the same searched keyword, a notation to the framework to itself would display that ability.
Since the framework received is the default one and is extending the Homepage the Login could just navigate to the received framework.
The diagram below (Figure 1.4) displays a diagram of our modeling
language with what we explained in this section.
25 Figure 6.1: The example diagram.
6.4 Evaluation
As it is presented in Chapter 3 the final step is dedicated to finding
weaknesses and improving our modeling language. In order to achieve this,
closed interviews were conducted from us to one computer science graduate,
one senior software developer, and one business administration graduate. The
reasoning behind choosing these three participants is that as we specified in
the requirements section, the language should be understandable by non-
computer scientists also. In addition, having the opinion of a university
graduate could acquire helpful suggestions since UML is one of the most
popular modeling languages that is been taught in universities. The opinion
on improvements and feedback of a professional software developer could
help with the improvement of our modeling language, in order for it to be
used in the industry. The evaluation is made according to the requirements
that we mentioned in Chapter 3, the evaluation also included the opinion and
update proposals from the participants. The requirements section was given
to the participants with a computer science background and they were asked
to judge and give feedback if the language satisfies them. The following table
is representing the results of the interviews with respect to the requirements.
26
1st Section 2nd Section
3rd Section 4th Section
Computer Science graduate
Satisfied Satisfied Satisfied Satisfied
Senior Software Developer
Satisfied R3 is not satisfied
Satisfied Satisfied
Economics Graduate
- Satisfied Satisfied Satisfied
Table 6.1: The requirements satisfaction.After the interviews were conducted, we came to the conclusion that the language’s associations needed some improvement. Moreover, the interview with the senior software developer and the computer science graduate shows that the associations between the frameworks are not explicit. The software developer added “It is clear how the classes are associated if they navigate to each other or inheriting. However, what drives these associations is not clear, in other words in what conditions are these associations used.” The interview with the senior developer also showed that it has not clear were the navigation flow starts or ends. The conclusion that we had from the interviews is that:
● The associations must improve, they have to be given some ability that describes when are they going to be used.
● The hierarchy of the navigation flow should be presented.
6.5 Improving the modeling language
In order to overcome the first issue, we came with the idea that the contextual notation names must share the same naming or describe the event that triggers that notation. The event that triggers a notation could be for example the click of a button; in that case, the notation should contain a text that declares the name of that button.
For the hierarchy to be improved the senior developer suggested that the numbering of the frameworks could be a sufficient approach. Furthermore, starting from the landing page the frameworks could be numbered increasingly depending on how many framework to framework notations exist from the first framework to them.
In order for us to display the different upgrades that our modeling
language needs to include we decided to upgrade the metamodel and add
modeling guidance rules. Furthermore, upgrading the metamodel would be
27
necessary since the solution that was chosen numbering the frameworks is included in the abstract syntax of the language. The second upgrade along with the first upgrade is satisfied by modifying the concrete syntax. Since we have chosen OCL for describing our modeling constraints, adding a modeling guidance rule that enforces every notation to include a short textual description of the event that causes that notation and adding the framework numbering depending on the number of notations can be achieved by writing the rules in OCL.
There were two choices for updating the metamodel in order to satisfy the new upgrade.
The first choice was to add a separate framework from the element class in the metamodel, that would represent the numbering in every framework.
This number class would be associated with the framework class with a one to one directed association.
The second upgrade that was chosen to be applied in the metamodel contains adding an attribute to the class element, the attribute is a number with the type value Integer. This approach describes that every framework includes a number which has an integer value.
The first approach enforces the uniqueness of the numbering of every
framework, in other words, that every framework would have a different
number. The second approach focuses on the fact that every framework
should have a number, the uniqueness of the value does not matter. The
choice that we made was to apply the second approach. The numbering can
be the same if one framework is simply inheriting another framework or two
or more frameworks have the same notation number from the landing/first
framework. Since the update that we have chosen is starting from the landing
page the classes must be numbered increasingly depending on how many
class to class notations exist from the first framework to them, the notation
number can be the same for two or more frameworks.
28
Figure 6.2: The updated metamodel.
OCL rules: The new added OCL rules are presented below.
Rule 7: The contextual notation names must be the same with the attribute that triggers that notation.
context Framework inv:
if result(self.attribute) -> self.notation then self.attribute.name = self.notation.name else false
endif
Rule 8: The numbering of a framework must be the same with the minimum amount of notations that have to be taken to guide from the first framework to the given Framework:
context Diagram inv:
self.frameworks -> select(1 | 1.name) ->
min(self.frameworks.notation.number) = 1.target
29
6.6 Results of the upgrade
After upgrading our modeling language the following diagram was produced including the new features of the modeling language. The diagram models the same GUI that we gave an example in Section 6.1. The added constraints can be seen in the class naming and the contextual notations. The number that is in front of the names of the frameworks represents the numbering constraint that has been added and all the notations are including the name of the event that can trigger them.
Figure 6.3: Example modeling diagram.
6.7 Comparing the Requirements
In this section, a comparison of the scope and requirements between the already existing UI modeling languages that were chosen in the related work section and our new modeling language is made.
IFML: The language is targeting similar aspects as our modeling language.
The scope of IFML is to give instruments for the meaning of Interaction Flow
30
Models that depict the elements of an application front-end: the view part of the application, made of view containers and view components; the objects that encapsulate the condition of the application, and the references to business rationale activities that can be executed; the control rationale that decides the activities to be executed after an occasion event; and the circulation of control, information, and business rationale at the various levels of the engineering.
Moreover, the IFML instead of visualizing the blueprint of the GUI is made for designing the GUI in detail and its components. However, this thesis is developing a modeling language which has a much more narrow scope and usage, it does not include any data objects or events neither the logic behind any actions that are executed.
UMLI: In UMLi the GUI is modeled in terms of its internal structure and objects comprising it [2]. The extension is not explicitly focusing on the GUI as it visualizes other aspects of the software, for example, the interaction with how the GUI is interacting with other components of the system.
As it is specified in the requirements section, the integrated modeling language should provide a high-level visualization of the GUI’s composition and content.
Maria: MARIA is able to describe interactive applications with various kinds
of collaboration strategies, modalities of utilization, and registering stages that
can be portrayed such that it saves the plan autonomously from
unconventional qualities of the physical figuring stage [8]. Moreover, the
language´s features cannot describe possible user interactions, user inputs,
and, the user potential impacts on the GUI, which are important characteristics
for our modeling language.
31
7 Discussion
The modeling language has been created considering the satisfaction of the requirements that were gathered to reach the desired result. The objectives are promoting the development of the modeling language. In general, since I did not found much documentation on how to develop a modeling language, the development process choices are discussed and through the discussion, the most appropriate approach is chosen. The next step is discussing and justifying the choices that are made for the modeling language.
Firstly, choosing the modeling language to be an extension of UML instead of developing the language from scratch. As it is mentioned in Chapter 2 the choice comes from the fact that UML is already widely used.
Since the target of the group of the language is software developers and architects, thus the industry, extending a widely accepted modeling language is a more appropriate and efficient than creating a new modeling language, which may be infamous.
Secondly, choosing the DSML development process is made after discussing the process choices. Since there is not much available documentation regarding the procedure of developing a modeling language, two options were found to be efficient. Developing the modeling language into two stages, by defining the conceptual constructs and implementing the UML extensions in the form of stereotypes and their properties. This strategy is discarded since structuring conceptual domain models for profile configuration is less time-efficient than the second approach. The used approach is divided into three stages as we see through the report, defining the domain analysis, defining the abstract and concrete language and getting feedback for improvement. Considering that the language target of usage is the industry, getting feedback for improvement from industry-related participants is bolstering the chance of the language being used in the industry.
Finally, setting the requirements is a fundamental factor that would
affect the language’s success and reliability. The requirements are generated
with consideration of other already widely used modeling language
requirements. In addition, the requirements are also formed through the scope
of the modeling language and the objectives.
32
8 Conclusion and Future Work
In this thesis, we have developed a modeling language. We researched how to develop a modeling language and argued about which of the researched results would be better for developing the new modeling language.
The result of every step during the language development process was discussed and argued if it was sufficient in order to be used in our modeling language. The result is a specific modeling language that only tackles the development phase of designing the GUI of an application. The result could be used for software design processes. The development of the modeling language could use frameworks that are specified for developing different modeling language aspects (f.e. Ecore for the development of the metamodel).
Future work may focus on refining the language in order to be used in a specific project, a specific product (f.e. Adjusted for Mymoodle). Secondly, modifying the modeling language and adjusting it for a specific environment would also be possible (f.e. Android applications).
This would result in a more restricted and less general modeling
language that targets a specific more precise target.
33
References
[1] Sea.ucar.edu. (2019). Software Design and Modeling | SEA. [online]
Available at: https://sea.ucar.edu/best-practices/design [Accessed 28 Apr.
2019].
[2] Kempe, S. (2019). The Top Information and Data Modeling Languages - DATAVERSITY. [online] DATAVERSITY. Available at:
https://www.dataversity.net/the-top-information-and-data-modeling- languages/ [Accessed 28 Apr. 2019].
[3] Booch, G., Jacobson, I. and Rumbaugh, J. (2005). UML: The Unified Modeling Language user guide. Upper Saddle River, NJ: Addison-Wesley.
[4] The Interaction Design Foundation. (2010). Mock-ups. [online] Available at: https://www.interaction-design.org/literature/book/the-glossary-of- human-computer-interaction/mock-ups [Accessed 16 Jan. 2020].
[5] Paterno’, F., Santoro, C., and Spano, L. D. “MARIA: A universal, declarative, multiple abstraction-level language for service-oriented applications in ubiquitous environments.” in Comput.-Hum. Interact. 16, 4, Article 19 (November 2009).
[6] P. Silva and W. Paton, ” User Interface Modeling in UMLi”, July 2003, [online] Available: http://www.cs.man.ac.uk/~norm/papers/umli.pdf [Accessed 28 Apr. 2019].
[7] M. Bambila and P. Franternali, Interaction Flow Modeling Language:
Model-Driven UI Engineering of Web and mobile apps with IFML, 1st edit, Wyman street, Walham, USA :Elsevier Inc., 2015.
[8] Brambilla, M., Cabot, J. and Wimmer, M. (2012). Model-driven software engineering in practice. [San Francisco]: Morgan & Claypool Publishers.
[9] Selic, B. (2007). A Systematic Approach to Domain-Specific Language Design Using UML. 10th IEEE International Symposium on Object and
Component-Oriented Real-Time Distributed Computing (ISORC'07).[10] Kempe, S. (2012). The Top Information and Data Modeling Languages. Education Resources For Use & Management of Data. [online]
Available at: https://www.dataversity.net/the-top-information-and-data-
modeling-languages/# [Accessed 4 May 2019].
34
[11] Lagarde, F., Espinoza, H., Terrier, F. and Gérard, S. (2007). “Improving uml profile design practices by leveraging conceptual domain models.”
Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering - ASE '07.
