Traverser: A method and a tool to extract user’s traverses within web systems from ontology

Abstract

People explore specific services or information to accomplish their goals within a web system. Efficient visitors’ exploration routes must be defined as requirements to guide them through a good experience. In order to define these requirements, we focused on links from one object to another and developed a method named Traverser to guide the visitors from the starting point to the destination. In our study, these links are within the ontology of a service domain. The set of links to guide visitors from a certain object to the destination is referred to as a “traverse.” A traverse is inferred from the ontology by tracing associations and inheritance relationships between domain items, taking the rights of each user group into account. The ontology for extracting traverses is developed as a conceptual model with a class diagram of UML, while the roles of an association are diverted as a user group’s permissions. We also developed a tool to define the conceptual model and extract traverses. The effectiveness of Traverser is evaluated by comparing the requirements derived by Traverser with those of the use case approach.

Keywords

Requirements elicitation ontology web system permission user experience

1. Introduction

People explore specific services or information to accomplish their goals within a web system. In order to provide a good user experience in the web system, the most efficient visitors’ exploration routes must be defined as requirements. When a user begins her/his exploration from an object, their traced links between objects and target objects will remain as the breadcrumbs of a trail, in other words, the “Berrypicking” process [1]. We have to define the efficient breadcrumb trails as requirements in the requirement engineering process. We call the breadcrumbs’ trail, a traverse.

In this paper, we propose a method named Traverser to extract traverses to define requirements for guiding visitors from starting points to the destinations of their goals. A traverse is inferred from the ontology of a service domain by tracing associations and inheritance relationships between domain items, taking into account the access rights of each user group. Hence, the ontology has enough objects to extract traverses within a web system. The ontology is built by a modeler, but the knowledge to build the ontology is acquired from domain experts.

How can a traverse contribute to proper user experiences? This is because visitors do not click on links between objects at random, but click on links, as the thinking is that, the clicking action will bring them closer to the target object. If so, the traverse extracted from the ontology [2] that represents the meaning structure of the real world should be an itinerary close to the mental model of the visitors in the real world. We applied class diagrams to represent the ontology of the application domain. The roles of an association in class diagrams are diverted as a user group’s permissions. Hence, the associations in the ontology can represent visitors’ permitted activities; i.e. create, read, update, and delete. We also defined rules to interpret the class structure in order to extract traverses. Then, Traverser can infer and construct traverses with the added advantage of taking into account the visitor’s permitted activities.

In our previous study, we were able to get traverses from the conceptual model, in other words, the “ontology” of a web-based education management system, and further, find some missing links that were ignored by the real system [3].

The purpose of this study is to show the inferred results produced by Traverser tool, and how these inferred results can contribute to the eliciting requirements as itineraries for users. In this paper, we introduce inference rules to extract traverses from the ontology and, evaluate the effectiveness of Traverser.

The structure of this paper is as follows. In Section 2, we introduce related work. Section 3 gives an overview of the method Traverser. Section 4 shows the method semantics. Section 5 introduces Traverser tool, which supports engineers in defining ontology and extracting traverses. Section 6 provides experimental studies and evaluation results for Traverser. To evaluate the effectiveness of Traverser, we chose the car sharing system as the case. In section 7, we answer the research questions and discuss the weaknesses and strengths of Traverser compared to the use case approach. This paper concludes with the last section.

2. Related work

When it is anticipated that a wide range of various users will use the system, interviewing all kinds of users is not a viable solution. A persona is a typical user with a name, personal history, work, goals, and other properties, that provide the developers with an imagination or a rationale for the persona’s objectives or situational requirements for using the system [4]. Persona analysis is effectively applied to games [5], and smartphone apps [6]. However, it is hard to define personas for web shopping sites, because there are various users. In order to elicit requirements of various users, we need to analyze the users’ behavior more logically. Since an ontology has inference rules with knowledge, we can derive users’ behavior, and traverses, automatically.

In requirements engineering, a persona activity is defined as a scenario [7] or a user story [8]. Use case approach [9] is a more abstract approach. One of the advantages of these natural language approaches is that they are easy to read and can be understood by everyone, however it is difficult to apply them with the goal of contributing to the integrity of the requirements. In our method, the traverse is written in natural language, so that, end users can evaluate the traverses whether traverses correctly describes their requirements or not.

In the Robotic Process Automation (RPA) area, researchers utilize bot logs and process logs in order to elicit requirements for addressing exceptions and/or new opportunities for bot and process redesign [10]. Process mining is a way to explore new services or improve existing services, including web systems. [11]. If we apply the process mining approach, we explore the actor’s real traverses within the usage logs recorded after the system release, and extract scenarios where the actor gets lost in the process. This approach is effective after developing a system. If we can predict efficient traverses, we must define them as requirements before building a system. In our approach, requirements on the customer journey are elicited from the conceptual model that is defined in the early stage of the software development, rather than after the system release.

An ontology is defined as a structure of domain knowledge with objects and relations between objects. The ontology is interpreted to understand the domain with inference rules. Applying ontology is an important approach for requirements elicitation [12]. For example, Haruhiko Kaiya applied an ontology to find incompleteness of requirements [13]. According to improving the technologies of artificial intelligence, ontologies have come to be applied to various applications and/or engineering domains. In the semantic web, a computer understands the meaning described within a web page by interpreting the metadata of the web page using the ontology [14]. AI (Artificial Intelligence) chatbots are a typical example for our daily lives [15, 16]. Some AI chatbots can answer questions in natural language with a domain ontology.

In recent software development projects, requesters are expected to make significant contributions [17]. T. Rietz et al. developed a self-induction system called “Ladder Bot” [18], in which, Conversation Agents (CAs) mimic the capabilities of professional interviewers, allowing end users to define their needs and requirements. “Ladder Bot” may be effective for end users, but completeness issues remain. Since we developed a tool to extract traverses from the ontology automatically, traverses cover the scope of the model completely. We expect traverses to contribute to the completeness of requirements of users’ itineraries.

An ontology is a formal and explicit specification of a shared conceptualization [19]. A conceptual model is sometimes treated as an ontology. E. Insfr’an et al. applied conceptual models for the prediction and elicitation of requirements [20]. S. Nalchigar et al. also introduced a conceptual modeling framework by focusing on information systems that mainly manipulate data [21]. T. Nakatani et al. explored a method to predict requirements changes and find undefined requirements with a conceptual modeling technique [22]. K. Goto et al. developed an event list generation system by extracting scenarios from class diagrams [23]. These studies presented the effectiveness of a conceptual model in order to elicit requirements. In this paper, we introduce inference rules to construct traverses from an ontology. Furthermore, from the ontology, we extract traverses as requirements on efficient user experiences.

3. Overview of method traverser

3.1 Approach

The traverses are extracted from an ontology by tracing associations, aggregations, and inheritances by taking into account the actor’s permissions. Here is an example of a traverse.

An actor StandardStudent who accesses a/an Lecturer object can access(read) the Article objects from the Lecturer object.

UML class diagrams are utilized to represent the ontology. There may be another path for the actor to access the Lecturer object in the traverse example: it may be acceptable for the actor to use a search engine to find the Lecturer object. We added “open” and “closed” stereotypes to the ontology. These stereotypes indicate whether the objects of the class can be accessed from anywhere, or not.

Furthermore, we added an actor model that represents an actors’ permission inheritance structure, so that the permissions on each path can be defined for each actor. The report output from Traverser tool contains requirements in the form of a traverse.

3.2 Users of traverser

A process of Traverser requires the following two users:

•
A modeler

A modeler has skills in object-oriented modeling techniques and knowledge of UML.
•
A domain expert of the application domain

Modeling techniques are not mandatory for the domain expert, but it is recommended to have the skills to understand class diagrams. Traverser tool helps domain experts understand traverses by presenting them in textual and animated styles. We will briefly introduce the tool in section 5.

The modeler and the domain expert work together in order to complete the ontology.
3.3 A process of traverser

The process of Traverser is as follows:

1.
A modeler builds an ontology with a domain expert.
2.
The domain expert defines actors’ groups within an actor model.
3.
The domain expert defines permissions for every actors’ category on every association/aggregation in the ontology.

By picking up actors one by one, the expert analyzes the actor’s permissions for each association and/or aggregation.

Traverser tool provides a dialog box as shown in Fig. 1 in order to define permissions.

Figure 1.
A dialog box to define the permissions for an actor.

4.
The domain expert reviews the traverses that the tool extracted.

The permitted traverses and prohibited traverses are output from the tool for each actor.
5.
The domain expert validates the traverses as requirements of the developing system.
6.
If the ontology or permissions are incorrect or needs to be updated, the modeler restarts from 1 or completes the process.

4. Semantics and inference rules

4.1 Semantics of an ontology for traverser

Figure 2.

A metamodel of Traverser.

Figure 2 represents the metamodel of Traverser. It has the following elements.

•

Class: Class represents a concept.

Each concept appears on a web page. However, it does not mean each concept should be implemented within one web page. In general, web pages contain multiple concepts, because of their usability and/or readability. How many concepts a web page consists of is a typical design issue. The scope of Traverser is, for example, to suggest a requirement that one access path has to be implemented within the system. $\textit{Class}=$ {stereotype, name, is-a}

$\textit{Class.stereotype}=\{\textit{open}\mid\textit{closed}\}$

Traverser treats Class as a set of instances of the class.

•

Is-a: inheritance structure between classes.

${\textit{Is-a}}\subset\textit{Class}\times\textit{Class}$

$(\textit{child},\textit{parent})\in{\textit{Is-a}}$

where $\textit{child},\textit{parent}\in\textit{Class}$ .

•

Actor: Actor is a visitor of a web system and is a subset of Class.

$\textit{Actor}\subset\textit{Class}$

•

CRUD: It represents the accessing rights of actors. It is defined as a set of access rights.

$\textit{CRUD}=\{\textit{create},\textit{read},\textit{update},\textit{delete}\}$

•

Permission: a permission is defined on the edges of a relation to allow actors to access the object of a class.

$\textit{Permission}\subset\textit{Actor}\times 2^{\textit{CRUD}}$

$\textit{perm}\in 2^{\textit{Permission}}$

$\textit{perm}=(\textit{actor},\textit{crud})$

$\textit{actor}\in\textit{Actor}$

$\textit{crud}\subset\textit{CRUD}$

It means that an actor is permitted to access with the rights defined in crud that is a subset of CRUD.

•

Mult: It follows the semantics of “multiplicity” in UML. It represents a collection of values. The basic format of “multiplicity” is as follows:

$<$ lower-bound $>$ [“..” $<$ upper-bound $>$ ]

If it has a fixed number, only $<$ low-bound $>$ is the mandatory. “*” is used to represent unlimited upper bound.

•

Relation: Relation is a kind of association, aggregation, or association class in UML.

$\textit{Relation}\subset\textit{Class}\times\textit{Class}\times 2^{\textit{% Permission}}\times\textit{Mult}\times(\textit{Class}\cup\{\perp\})$ ,

where $2^{\textit{Permission}}$ represents a power set of Permission. An instance rel of Relation has five attributes. They are elements of the following sets, respectively.

$\textit{rel}\in\textit{Relation}$

$\textit{rel}=\{\textit{from},\textit{to},\textit{perms},\textit{mult},\textit{% assocClass}\}$

$\textit{from},\textit{to}\in\textit{Class},$

$\textit{perms}\in 2^{\textit{Permission}}$

$\textit{mult}\in\textit{Mult}$

$\textit{assocClass}\in\textit{Class}\cup\{\perp\}$

Figure 3.

An example of an association-class.

Figure 3 is the example of a relation with an association class drawn with the Traverser tool. The figure represents two links $r_{1}$ and $r_{2}$ as instances of Relation in the ontology. For example, $r_{1}$ is a relation from class $N1$ to $N2$ with $\textit{Permission}2$ and $N3$ as an association class. An instance of class $N1$ has $\textit{Mult}2$ instances of class $N2$ . The structure is interpreted as follows:

•

$r_{1},r_{2}\in\textit{Relation}$

•

$r_{1}=(N1,N2,\textit{Permission}2,\textit{Mult}2,N3)$

•

$r_{2}=(N2,N1,\textit{Permission}1,\textit{Mult}1,N3)$

4.2 Inference rules of traverser

Traverses are generated by tracing relations between classes with actors’ permissions by taking into account the inheritance structure of classes. The rules of tracing the relationship within the ontology are as follows.

•
Ancestors, descendants, and relatives

$TC({\textit{is-a}}$ ) is a transitive closure of is-a relation between classes. When $R$ is a set of relations between classes. $TC(R)$ is a minimal set that satisfies the following conditions. Where $R\subset\textit{Class}\times\textit{Class and }a,b,c\in\textit{Class}$ ,

$R\subset TC(R)$

Transitivity rule: if $(a,b),(b,c)\in R$ , then $(a,c)\in TC(R)$

If there are inheritance relations, the traverse can transit via the relations.

–
Ancestors

$\textit{ancest}(c)=\{n\in\textit{Class}\mid(c,n)\in TC({\textit{is-a}})\}$ $\textit{ancest}^{}(c)=\textit{ancest}(c)\cup\{c\}$
–
Descendants

$\textit{descend}(c)=\{n\in\textit{Class}\mid(n,c)\in TC({\textit{is-a}})\}$ $\textit{descend}^{}(c)=\textit{descend}(c)\cup\{c\}$
–
Relatives $\textit{relatives}(c)=\textit{ancest}(c)\cup\textit{descend}(c)$ $\textit{relatives}^{}(c)=\textit{relatives}(c)\cup\{c\}$

•
Permitted relation

The permitted relation, $\textit{PermRel}(a,x)$ , is a function from $a$ and $x$ to a subset of Relation, where $a\in\textit{Actor}$ and $x\in\textit{CRUD}$ .

$\displaystyle\textit{PermRel}:\textit{Actor}\times\textit{CRUD}\to 2^{\textit{% Relation}}$

For Actor $a$ and CRUD $x$ , $\textit{PermRel}(a,x)$ is a set of relation such that the relation contains a permission that $a$ or an ancestor of $a$ can do $x$ .

$\displaystyle\textit{PermRel}(a,x)=\{\textit{rel}\in\textit{Relation}\mid% \exists(\textit{act},\textit{crud})\in\textit{rel.perms},\textit{act}\in% \textit{ancest}^{}(a)\ \text{and}\ x\in\textit{crud}\}$
•
Traverses sequence

Traverser is a function from $a\in\textit{Actor}$ , $x\in\textit{CRUD}$ , and $c\in\textit{Class}$ as a start point of a traverse to a set of finite sequence of relations ( $\textit{Relation}^{}$ ).

$\displaystyle\textit{Traverse}:\textit{Actor}\times\textit{CRUD}\times\textit{% Class}\to 2^{\textit{Relation}^{}}$

$\displaystyle\textit{Traverse}(a,x,c)=\{\textit{rel}_{1},\textit{rel}_{2},% \ldots,\textit{rel}_{n}\in\textit{Relation}^{}\}$

The output of Traverser satisfies the following six conditions.

–
A traverse starts from a class of which stereotype is “open”, in other words, everyone can access the start class of the traverse from the web.

$\displaystyle\textit{c.stereotype}=\textit{open}$
–
The output is a finite sequence of relations in which each relation occurs only once.

$\displaystyle\forall i,j(1\leqslant i<j\leqslant n):\textit{rel}_{i}\neq% \textit{rel}_{j}$
–
All relations appearing in the output are elements of $\textit{PermRel}(a,x)$ .

$\displaystyle\forall i(1\leqslant i\leqslant n):\textit{rel}_{i}\in\textit{% PermRel}(a,x)$
–
The from-element of the first relation of the traverse is a start class $c$ or its relatives.

$\displaystyle\textit{rel}_{1}.\textit{from}\in\textit{relatives}^{}(c)$
–
The from-element of each relation in a traverse is equal to the to-element or the assocClass-element of the previous relation, or its relatives.

$\displaystyle\forall i(1<i\leqslant n):\textit{rel}_{i}.\textit{from}\in% \textit{relatives}^{}(\textit{rel}_{i-1}.to)\cup\textit{relatives}^{}(% \textit{rel}_{i-1}.\textit{accosClass})$
–
The traverse is terminated by the $\textit{rel}_{n}$ , if there is a $\textit{rel}_{i}$ of which from-element is equal to the to-element or the assocClass-element of the $\textit{rel}_{n}$ or its relatives, or there are not any permitted relations for $(a,x)$ of which from-element is equals to the to-element or the assocClass-element of the $\textit{rel}_{n}$ or its relatives.

$\displaystyle\exists i(1\leqslant i\leqslant n):\textit{rel}_{i}.\textit{from}% \in\textit{relatives}^{}(\textit{rel}_{n}.to)\cup\textit{relatives}^{}(% \textit{rel}_{n}.\textit{assocClass})$

or

$\displaystyle\forall\textit{rel}\in\textit{PermRel}(a,x):\lnot\textit{rel.from% }\in\textit{relatives}^{}(\textit{rel}_{n}.to)\cup\textit{relatives}^{}(% \textit{rel}_{n}.\textit{assocClass})$

•
The rules of traverse report

A traverse report derived from relations within Traverse (a, x, c) where $a\in\textit{Actor}$ , $x\in\textit{CRUD}$ , and $c$ which is a class of the start element of the traverse. As the basis of the following template, the report is generated in a simple text by a tool: Traverser.

–
If there are relations $\textit{rel}_{1},\textit{rel}_{2},\ldots,\textit{rel}_{n}$ in $\textit{Traverse}(A,X,C)$ and $C$ has some descendents, then the following statement is generated first by applying rule1.

rule1: Descend (x) is the name of a class of descendants of x. The text is generated repeatedly as the same number of times as the number of the descendants.

An actor A who accesses a/an C object [or a/an Descend(C) object] …can access ( $X$ )

–
Each rel(From, To, Perms, Mult, Assoc) is used to generate the following statement by applying rules.

rule2: To is a name of the class of $\textit{rel}_{i}.to$ .

rule3: If the multiplicity of $\textit{rel}_{i}$ is 1 or 0..1, “object” is inserted, otherwise “objects” is inserted.

rule4: If the multiplicity of $\textit{rel}_{i-1}$ is a single, { $\textit{the}\mid\textit{each}$ } is set “the,” otherwise “each.” When “each” is inserted into { $\textit{the}\mid\textit{each}$ }, the word of $\textit{rel}_{0}$ is inserted in singular.

rule5: If $\textit{rel}_{i}.\textit{from}$ is equal to $\textit{rel}_{i-1}.to.\textit{anscestors}$ , the word for From is the name of a class of $\textit{rel}_{i-1}.to$ , otherwise $\textit{rel}_{i}.\textit{from}$ .

rule6: If $\textit{rel}_{i}.\textit{multiplicity}$ is 1 or 0..1, then “the” is inserted, otherwise “each” is inserted.

the To [object [or the Descend(To) object] …from { $\textit{the}\mid\textit{each}$ } From object [, and the Assoc object of { $\textit{the}\mid\textit{each}$ } To object].

Here is an example text that Traverser generated as a traverse.

An actor Administrator who accesses a/an Vehicle object or a/an ManagedVehicle object or a/an ShareableVehicle object can access(read) the VehicleTax objects from the Vehicle object.

5. Traverser tool

5.1 Overview

Traverser tool1

¹
Traverser tool is available at http://www.s-lagoon.co.jp/Traverser/.

extract traverses from a class diagram with inference rules. It is an editor of UML class diagrams, but is modified for Traverser. The tool supports modelers and domain experts with the following operations.

•

Defining an ontology and an actor model.

•

Extracting permitted traverses and prohibited traverses with regard to the actor’s access permissions from the ontology.

•

Presenting traverses in text and graphic styles.

•

Generating a summary of a use case description with name, actor, preconditions, and postconditions.

Modelers and domain experts review the generated traverses to verify whether any of the traverses contradict the requirements. Therefore, traverses should be presented in a style that is easy for non-technical people to read and understand.

5.2 Visualization styles

Traverser tool was developed to support a review process with visualization styles. In the Traverser’s review process, reviewers are expected to read all of the concepts, actors, and their permissions. The traverses of actors with certain accessing rights are visualized in text and graphic styles. The graphical style presentation of traverses is shown in Fig. 4. In the figure, the traverses are presented as the reachable scope of an actor “non-member” who starts from SearchVehicleKey. We were able to get four traverses within the scope. The tool also gives us the traverses in a text style. One of the traverses is shown in a text style as follows.

Figure 4.

The highlighted scope for Non-member with a read right from SearchVehicleKey.

An actor Nonmember who accesses a/an SearchVehicleKey object or a/an Model object or a/an Grade object or a/an Displacement object can access(read) the ShareableVehicle objects from the SearchVehicleKey object, and the ParkingCertification objects from each ShareableVehicle object as association object.

5.3 Prohibition of accesses

Traverser tool generates requirements of the prohibition of actor’s access, so that the tool helps a domain expert eliminate errors of permissions and/or the structure of the ontology by reviewing the traverses. The requirement of prohibition accesses is similar to “inverse requirement” that Berry, D. et al. proposed [24]. The permitted and prohibited accessing requirements are as follows.

•
An actor Nonmember can access (read) the PhysicalParking object from the Area object.
•
An actor Nonmember is prohibited from accessing (read, create, update, delete) the ManagedVehicle object from the LogicalParking object.

6. Experimental evaluation

6.1 Overview of the experiments

The case of our experimental evaluation is a car-sharing management system (CSMS). The CSMS is designed as a web system to manage not only rental records, but also the state of the vehicles in three periods: i.e. (1) from when the company orders a vehicle to when it becomes available as a sharable vehicle, (2) when the vehicle is available as a sharable vehicle, and (3) from when the vehicle is no longer a sharable vehicle until it is removed from the database. Because vehicles are legally required to have a garage certificate in Japan, the CSMS has data of a parking lot for every vehicle. LogicalParking is the data of a logical parking lot within the system for the first and the third states of the vehicle. Therefore, instances of LogicalParking are managed electronically only by the staff of the car-sharing company, not at a specific address or physical parking lot.

The scope of the ontology covers the objects with the following functions.

•
Manage the conditions of each vehicle including its three states, scratches, insurance, as well as yearly tax payments.
•
Manage the rental records of registered members.
•
Manage reservations, as well as cancellations of applications.
•
Provide data for searching the available sharable vehicles.

Figure 5 shows the ontology of the system.

Figure 5.
The ontology of a car-sharing system (part) and its actor model.

6.2 The design of experiments

In order to answer the two research questions, the experiments are designed as follows.

1.
Request a UML modeler and a domain expert for cooperation.
2.
Select two subjects of the experiments.

Two subjects are joined to our research project in order to evaluate the effectiveness of Traverser. The first subject is the domain expert of the CSMS, and the application of Traverser. The other subject is a requirement analyst, and is assigned to apply use case analysis to elicit requirements.
3.
A domain expert lectures a UML modeler on the CSMS.

After the lecture, the UML modeler provides a class diagram of the target system as an ontology. In order to eliminate any differences between subjects in the level of knowledge, we provide the complete ontology for the subjects. Therefore, the Traverser approach needs to come first. The ontology is built by the UML modeler and is reviewed by a domain expert.
4.
The first experiment: Traverser approach

Prior to the experiment, we explain to the subject, who is the domain expert, the process of Traverser described in Section 5 and how to utilize Traverser tool. The domain expert defines permission information into the ontology with the Traverser tool. The ontology is reviewed by the expert with the traverses’ output from the tool. The subject repeatedly reviews and updates the model until the Traverser tool outputs the proper traverses, in other words, requirements. The final version of the ontology will be served to the second subject.
5.
The second experiment: use case approach

In order to evaluate the effectiveness of Traverser, we chose the use case approach as the method for comparison. First of all, use case approach is a popular method in defining functional requirements. The traverses of visitors are also functional requirements. However, there is a difference in the perspective of requirements analysis between the two methods. In these two experiments, we reveal the weaknesses and strengths of the two methods. The subject of this experiment receives the ontology from the UML modeler. Note that, for the second subject, the provided ontology is a simple class model as it does not contain permissions data. After the question and answer session, the subject gets more information from general documents on the car-sharing business and defines use cases.
6.
Evaluation

We evaluate the effectiveness of Traverser and its tool by comparing and analyzing the results of both experiments.

6.3 The experiment of traverser approach

The domain expert had over ten years’ experience in developing the CSMS. First, he reviewed the ontology. Second, he defined an actor model and added permissions on each association in the ontology. For example, he selects the concept SearchKey to start the review and browses the visualized scope to review all the concepts, actors, and their permissions. Third, he reviewed the textual based traverses. He took eight hours to define the permissions and review both the allowed and prohibited traverses generated by the tool. During the experimentation, he reported defects to the UML modeler; e.g. errors in attributes, relationships between classes including associations and inheritances, as well as inconsistencies in the ontology with the real world. With reference to his report, the modeler updated the ontology within the hours prior to a web meeting with the domain expert. As we mentioned in Section 6.1, Fig. 5 shows the ontology as the final version of this experimentation. The ontology was provided to the following experiment after the permission data was deleted.

Finally, Traverser tool could output 76 requirements including prohibited requirements for each actor on a read permission. In total, we were able to get 304 requirements. Table 1 shows the number of read requirements extracted as traverses. Table 2 shows the number of traverses from SearchKey object for each actor.

Table 1
The access requirements derived from traverses

Actor	#permitted accesses	#prohibited accesses
Non-member	7	69
Member	22	54
Operator	44	32
Administrator	65	11

Table 2

The number of traverses from SearchKey object for each actor

Actor	#create	#read	#update	#delete
Non-member	0	9	0	0
Member	0	13	0	0
Operator	1	25	1	1
Administrator	26	43	26	26

6.4 The experiment of the use case approach

The subject of this experiment had more than twenty years of experience in use cases and object-oriented methodologies. In defining use cases with reference to the ontology without permission data, he considered phenomena shared between the real world and the system world of use cases. He said that interaction between an actor and the system means sharing real-world phenomena. He defined the situation of use cases in consideration of shared phenomena [25]. Subjects spent approximately a week on the experiment. The functional requirements are told in the web meeting. Table 3 shows the major use cases and the shared phenomena with the real world and the system.

Table 3
The major use cases and implied situation

Use case	Shared phenomenon
Set the start time of a reservation	The shared vehicle must be scheduled in the parking lot at
	the time.
Return the sharable vehicle	The vehicle is parked in the designated physical parking.
Move a vehicle from a logical parking to a physical parking	The vehicle becomes a sharable vehicle.
Move a vehicle from a physical parking to a logical parking	The vehicle will be deregistered as a sharable vehicle.
A sharable vehicle has defects.	Someone reports the defects to the car-sharing company.

The requirements elicited by the subject were different requirements from the requirements generated by Traverser. The subject elicited functional requirements of the system and the conditions for those functions to operate appropriately. Though the number of requirements could not be quantitatively compared to the number of requirements extracted by Traverser tool, the requirements defined by the use case approach are qualitatively different from the requirements defined by the Traverser approach.

7. Discussion

7.1 Weaknesses and strengths of traverser

The weaknesses and strengths of Traverser compared to the use case approach are as follows.

•
The strengths of Traverser

–
Because the traverses are written in natural language, it was easy for the domain experts to discover incorrect traverses.
–
The ambiguities of traverses that come from the natural language are mitigated by the prohibited traverses.
–
More than 300 requirements for “read permissions” alone could be elicited automatically.
–
The precondition of a permitted action is incorporated within traverses for use case descriptions. Traverser provides preconditions for each use case that derived from traverses.

•
The weaknesses of Traverser

–
The ontology of an application domain is mandatory to apply Traverser. However, the ontology can be built step by step by reviewing the extracted traverses.
–
Traverser does not help analysts consider the real world around the requirements, because the tools automatically output the traverses from the ontology. Therefore, we cannot realize the situation when an actor reserves a shared vehicle in which the return of a shared vehicle is behind schedule with Traverser.

As analyzing the weaknesses and strengths of Traverser, Traverser can complement the use case approach.
7.2 The threats of internal validity

One threat of internal validity is that the observed effectiveness of Traverser and its tool depends on the domain expert. Because the domain expert who participated in the experiment was able to read the ontology, he was able to review the ontology. However, in order to mitigate the threat, the tool provides two kinds of output, i.e. natural language based text and graphical styles. The domain expert reviewed traverses in the text style. Even if a domain expert cannot read a conceptual model, they can point out the defects of traverses written in natural language.

7.3 The threats of external validity

Is every engineer able to build the complete ontology? If the tool outputs wrong traverses, there are errors in the ontology. Thus, the tool will be able to help engineers fix errors within the ontology. There is however another threat. If the size of the ontology becomes too large, the number of traverses will explode. That being the case, if the size of the model does become too large, the ontology can be divided into smaller sized ontology as sub-ontologies.

7.4 Limitations of traverser

The Traverser approach has some limitations. Since the ontology is an abstract model, we cannot generate scenarios with concrete objects. The tool can generate only possible traverses as an ordered list of classes. An actor who is allowed to read a <<closed>> object is not defined well enough in the Traverser. Traverser only mentions permissions on associations/aggregations between classes, not the links between objects.

8. Conclusion

In this paper, we have proposed a method and a tool to extract traverses from a conceptual model, and an actors’ inheritance structure based on their permissions. The focus of our research was to solve a problem of web systems by defining requirements on “Berrypicking” activities. The novel point of our research is that we have introduced the structure of the conceptual model, and have developed Traverser tool, that can extract traverses from the conceptual model automatically. By experimental studies, we concluded that the method and tool can contribute to complementing the use case approach. In our future work, we will extend Traverser to generate use case descriptions and take into account the structure of the services based on the user experience.

Footnotes

Acknowledgments

We thank Mr. Hideo Goto and Prof. Taichi Nakamura who gave us insightful comments at National Institute of Informatics. We would also like to thank Mr. Terunobu Fujino for his cooperation in the experimental evaluation and Mr. Shigenori Takeda for giving us the opportunity to discuss the ontology. This work was supported by the president’s discretion of OUJ in 2018. This work has been also supported by JSPS KAKENHI Grant Number 19K11905 since 2019.

References

Bates

. The design of browsing and berrypicking techniques for the online search interface. Online Review. 1989; 13(5): 407-24.

Uschold

Gruninger

. Ontologies: Principles, methods and applications. Knowledge Engineering Review. 1996; 11: 93-136.

Nakatani

Goto

Nakamura

Shigo

. A Method to Generate Traverse Paths for Eliciting Missing Requirements. In: Proceedings of the Australasian Computer Science Week Multiconference. ACSW 2019. New York, NY, USA: ACM; 2019. pp. 54:1-54:10. Available from: doi: 10.1145/3290688.3290697.

Cooper

. The Inmates are Running the Asylum. SAMS; 2004.

Rosenberg

Collins-Cope

Stephens

. Agile Development with ICONIX Process: People, Process, and Pragmatism. Apress; 2005.

Aoyama

. Persona-and-Scenario Based Requirements Engineering for Software Embedded in Digital Consumer Products. In: The IEEE International Requirements Engineering Conference. IEEE Computer Society; 2005. pp. 85-94.

Carroll

. Making Use: Scenario-Based Design of Human-Computer Interactions. MIT Press; 2000.

Benyon

Macaulay

. 11. In: Alexander IF, Maiden N, editors. A Scenario-based Design Method for Human-Centered Interaction Design. John Wiley & Suns; 2004. pp. 211-35.

Jacobson

Christerson

Jonsson

Overgaard

. Object-Oriented Software Engineering. Addison-Wesley; 1992.

10.

Egger

ter Hofstede

AHM

Kratsch

Leemans

SJJ

Röglinger

Wynn

. Bot Log Mining: Using Logs from Robotic Process Automation for Process Mining. In: et al GD, editor. Proc. of the 39th International Conference, ER 2020 (LNCS 12400). Springer; 2005. pp. 51-61.

11.

v d Aalst

. Service mining: Using process mining to discover, check, and improve service behavior. IEEE Transactions on Services Computing. 2013; 6(4): 525-35.

12.

Rolland

. From Conceptual Modeling to Requirements Engineering. In: Proceedings of the 25th International Conference on Conceptual Modeling. ER’06. Berlin, Heidelberg: Springer-Verlag; 2006. pp. 5-11.

13.

Kaiya

Saeki

. Using Domain Ontology as Domain Knowledge for Requirements Elicitation. In: 14th IEEE International Requirements Engineering Conference (RE’06). IEEE; 2006. pp. 189-98.

14.

Knublauch

Oberle

Tetlow

Wallace

. A Semantic Web Primer for Object-Oriented Software Developers. W3C; 2006.

15.

Ayyagari

Mohaghegh

. Dynamic Chatbot for Parking Service. In: 2021 International Conference on Engineering and Emerging Technologies (ICEET); 2021. pp. 1-6.

16.

Al-Zubaide

Issa

. OntBot: Ontology based chatbot. In: International Symposium on Innovations in Information and Communications Technology; 2011. pp. 7-12.

17.

Beck

, et al. Manifesto for Agile Software Development; 2001. http://agilemanifesto.org/.

18.

Rietz

Maedche

. LadderBot: A Requirements Self-Elicitation System. In: 2019 IEEE 27th International Requirements Engineering Conference (RE); 2019. pp. 357-62.

19.

Studer

Benjamins

Fensel

. Knowledge engineering: Principles and methods. Data & Knowledge Engineering. 1998; 25(1–2): 161-97.

20.

Insfrán

Pastor

Wieringa

. Requirements engineering-based conceptual modeling. Requirements Engineering. 2002; 7(2): 61-72.

21.

Nalchigar

Ramani

. A Conceptual Modeling Framework for Business Analytics. In: Comyn-Wattiau I, Tanaka K, Song IY, Yamamoto S, Saeki M, editors. Conceptual Modeling. Cham: Springer International Publishing; 2016. pp. 35-49.

22.

Nakatani

Tsumaki

. Predicting Requirements Changes by Focusing on the Social Relations. In: Proc. of the 10th Asia-Pacific Conference on Conceptual Modeling. Australian Computer Society; 2014. pp. 65-70.

23.

Goto

Ogata

Shirogane

Nakatani

Fukazawa

. Support of scenario creation by generating event lists from conceptual models. In: 2015 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD). Springer; 2015. pp. 376-83.

24.

Berry

Kamsties

. Chapter 2: Ambiguity in Requirements Specification. In: Leite JCSDP, Doorn JJH, editors. Perspectives on Software Requirements. Kluwer Academic Publishers; 2004. pp. 7-44.

25.

Jackson

. Problem Frames. Addison-Wesley; 2001.

Traverser: A method and a tool to extract user’s traverses within web systems from ontology

Abstract

Keywords

1. Introduction

2. Related work

3. Overview of method traverser

3.1 Approach

3.2 Users of traverser

4.1 Semantics of an ontology for traverser

5.1 Overview

1 Traverser tool is available at http://www.s-lagoon.co.jp/Traverser/.

• An actor Nonmember can access (read) the PhysicalParking object from the Area object. • An actor Nonmember is prohibited from accessing (read, create, update, delete) the ManagedVehicle object from the LogicalParking object. 6. Experimental evaluation

6.1 Overview of the experiments

Table 1 The access requirements derived from traverses

Table 3 The major use cases and implied situation

7.1 Weaknesses and strengths of traverser

7.3 The threats of external validity

7.4 Limitations of traverser

8. Conclusion

Footnotes

Acknowledgments

References

¹
Traverser tool is available at http://www.s-lagoon.co.jp/Traverser/.

•
An actor Nonmember can access (read) the PhysicalParking object from the Area object.
•
An actor Nonmember is prohibited from accessing (read, create, update, delete) the ManagedVehicle object from the LogicalParking object.

6. Experimental evaluation

Table 1
The access requirements derived from traverses

Table 3
The major use cases and implied situation