A Role Accessibility Definition Based Web Application ...

R-Web: A Role Accessibility Definition Based Web Application Generation Yusuke NISHIMURA, Kosuke MAEBARA, Tomoya NORO and Takehiro TOKUDA Department of Computer Science, Tokyo Institute of Technology, Japan Abstract. We present a role accessibility definition based Web application generation. A role accessibility definition specifies what kind of data access can be done by which type of roles of users. From a given role accessibility definition, we can automatically derive data model, business logic and user interface to generate simple Web applications. With additional definitions of page transition and general computation using existing Web service functions, then we can generate more general type of Web applications. We can use fine grained Web service functions for handling tables or external Web service functions on the Web. Our approach will help us (esp. non-programmers) create a variety of Web applications such as questionnaire systems, student assignment evaluation systems, and so on. Keywords. Web application generation, role accessibility, Web service functions, user interacting Web applications

Introduction Traditionally Web applications are constructed by methods such as manual writing in integrated environments or frameworks [1, 2], and automatic generation using diagrams or annotations [3–10]. However, such traditional methods are not suitable for constructing Web applications which deal with different roles of users interacting with data using limited accessibilities. We refer to such Web applications as user interacting Web applications. Examples of user interacting Web applications include questionnaire survey systems, meeting room reservation systems, report submission and evaluation systems, a conference paper review systems, and so on. In general, Web applications have the following four elements: data model, computation definition, appearance definition, and transition definition. In the case of user interacting Web applications, limited access methods are traditionally represented using part of computation definition. Let us take a look at one example of conference paper reviewing system. We have roles of PC chairs, reviewers, and authors. An author can upload a paper and download the uploaded paper. Reviewers can download papers specified by the PC chair and they can upload review reports to the specified papers. Web application developers have to embed such accessibility constraints in the program codes (computation definition) manually. It is hard for non-programmers to develop user interacting Web applications manually although they sometimes need such Web application. In this paper we propose a role accessibility definition based Web application generation. In our approach, we explicitly separate access model from computation definition.

A role accessibility definition specifies what can be done by which type of roles of users to what kind of data. From a given role accessibility definition, we automatically derive data model, business logic and user interface. With additional definitions of page transition and general computation using existing Web service functions, then we can generate more general type of Web applications. We can use fine grained Web service functions for handling tables or external Web service functions on the Web. Our approach will help us (especially non-programmers) create a variety of user interacting Web application easily since it requires minimum amount of accessibility definitions. Note that target of our proposal is creating Web applications used in a small group or for personal use, rather than large-scale, commercial applications such as Amazon, Facebook, and so on, which deal with large amount of data and need to ensure data consistency and scalability. The rest of this paper is organized as follows. In section 1 and 2 we present role accessibility definitions and some examples. In section 3 we explain additional definitions for general computation and transition. Section 4 and 5 describe implementation and evaluation. We discuss related work and provide conclusions in section 6 and 7.

1. Role Accessibility Definitions In our generator, named R-Web, Web application developers define the followings: roles of Web application users, account tables to store information about the Web application users, data tables to store data the Web application deals with, and role accessibility to the account tables and the data tables. In the rest of this paper, we refer Web application developers as “developers”. 1.1. Role and Account Table Developers declare what kind of roles the Web application users have. At least one role is required in R-Web. Each role has its own account table to store information about users of the role, which has to include information about user identification and authentication. The information is used when users log in to the Web application generated by R-Web. Account tables have two mandatory fields, which are used for identifying and authenticating users. In R-Web, either user ID or e-mail address is used for identification, and password is used for authentication. For each of the two fields, developers need to specify its name, maximum and minimum lengths and characters used for it. Developers can add some new fields to the account tables, each of which has a field name and a data type. We have the following data types. e-mail E-mail addresses. It is different from e-mail address for identification. integer Integer values. Maximum and minimum values have to be specified. string Character sequences whose length is less than/equals to 255. Maximum and minimum lengths have to be specified. long text Long character sequences whose length is more than 256. Maximum and minimum lengths have to be specified. date and time Data type to store both date and time. date Data type to store date. time Data type to store time.

selection Data type for allowing users to choose one value from a fixed set of strings. The set of strings have to be defined. In some cases, developers would like to let some users access the Web application without any identification and authentication. Developers can create at most one role to deal with this situation. This role does not have a corresponding account table since users of the role are not identified and authenticated. 1.2. Data Table Data which the Web application deals with is stored in data tables. Data tables have at least one field, each of which has a field name and a data type. There are eight data types: “integer”, “string”, “long text”, “date and time”, “date”, “time”, “selection”, and “file”. The data type “file” indicates file data. File names are stored in the data tble, and the files themselves are stored in a certain directory. Maximum file size has to be specified. The other data types are described in the previous section. 1.3. Role Accessibility After creation of roles and definition of structure of account tables and data tables, for each of the roles, developers define the following accessibility to each of the tables. create (C) It determines whether the role can create records in the account/data table. delete (D) It determines whether the role can delete records in the account/data table. For each of the account tables and the data tables, we also define the following accessibility to each field of the table. read (R) It determines whether the role can read data stored in the field. write (W ) It determines whether the role can edit data stored in the field. exclusive write (X) It determines whether the role can exclusively edit data stored in the field (and upload the corresponding file), and cancel the restriction later. After a user of the role exclusively edit the field, nobody else can edit the field until the restriction is canceled by the user. When a user who has role accessibility C creates a new record, he/she can set data to all fields of the record even if he/she does not have role accessibility W to the fields. Developers can prohibit users from setting data to some fields in creating a new record (users create new records leaving the fields empty). In some Web applications, one record in a data table corresponds to one particular user. Suppose, for example, we are planning to develop a Web application for questionnaire survey as shown in Figure 1. Respondents need to be registered on the system, and they can edit their own answers as many times as needed. Now, a respondent answers the questionnaire for the first time and sends the answer to the server. A record of the answer is created in the data table of the system, which means this record belongs to the respondent. The respondent can read and edit only some fields of his/her own record, and other records stored in the data table are neither readable nor editable. That is also true of account tables. Users can read and edit only their own account information, and they usually cannot neither read nor edit any other users’ account information. In order to deal

Figure 1. Example of a questionnaire survey system and role accessibility

with this situation, we introduce “individual accessibility definition”, which determines whether accessibility D, R, W , and X to each record (or each field in the record) in the data table will be defined for a particular user separately from accessibility definition for the user’s role. Developers determine which role’s user the individual accessibility should be assigned to. After a Web application is generated (i.e. in operation phase), a user who creates a new record in the data table determines a user the accessibility should actually be assigned to. For each role, individual accessibility of the role must be defined in the role’s account table.

2. An Example We take an assignment evaluation system as an example. It is used for a lecture course. A supervisor is the chair of the course, and he/she invites two instructors. Each of them gives an assignment to students after his/her lecture. Students upload their paper files of each assignment. Instructors download and read the files of their own assignment, and input score to a field of each student’s record. The supervisor checks all of the scores. In this system, we need four roles: supervisor, instructor A, instructor B, and student. The system has one data table to store paper files and scores of each student 1 . Each record in the data table has six fields: student ID, stident name, paper file of the 1st/2nd assignment, and score of the 1st/2nd assignment. Role accessibility to the data table will be as follows (Figure 2): 1 Although it also has account tables for each role, the details are omitted in this paper due to space limitation.

Figure 2. A data table for an assignment evaluation system and role accessibility

• Users of the role “supervisor” have accessibility C and D to the data table, and R to all of the fields. • Users of the role “instructor A” have accessibility R to the fields “student ID”, “student name”, “paper file of the 1st assignment”, and “score of the 1st assignment”, and W to the field “score of the 1st assignment”. • Users of the role “instructor B” have accessibility R to the fields “student ID”, “student name”, “paper file of the 2nd assignment”, and “score of the 2nd assignment”, and W to the field “score of the 2nd assignment”. • Individual accessibility definition for the role “student” is determined. ∗ The user of the role “student” whom individual accessibility is assigned to have accessibility R to all of the fields except for “score of the 1st assignment” and “score of the 2nd assignment”, and W to the fields “paper file of the 1st assignment” and “paper file of the 2nd assignment”. ∗ The others do not have any accessibility to all of the fields. 3. Page Transition And General Computation If developers only give role accessibility definition, a simple Web application can be generated. The Web application consists of several Web pages: Web pages for displaying information in the data/account tables, Web pages for editing information in the tables, Web pages for creating/deleting records to the tables, and a top page for logging in the system. Although every user can access each of the data tables and the account tables in the system, how information is displayed in each page depends on users or their role. Only information the user is allowed to read is displayed in displaying pages, and only information the user is allowed to edit (i.e. accessibility W /X) is displayed in editing pages. Only users who have accessibility C/D to a data/account table can go to pages for creating/deleting record/account. In order to be able to generate enhanced Web applications, we can define page transition and general computation as well as role accessibility. In page transition definition, we specify which information (fields of data/account tables) is to be displayed/edited in each page and which page users can go to from each page.

!"#$%&'(% )*+,-".*/#%*/&'0%*/% 12$%)"1"%1"3-$

6@A@BC 9"(#+:%4'-5D/%E%=%F?

678 9"(#+:%;$-)%?

,(-.%'/

,(-.%'0

!"#$%&"'*+

!"#$%&"'&()%

!#)

KL8MN>