Mobile based environment for foreign language learning: Use cases and sequence diagrams

1. Introduction

In our previous article we presented a high level definition for a mobile based system for foreign language learning. We presented the system’s architecture and the different user roles involved in the system along with the basic functionality for each of these roles. In the current articles, we continue the analysis of the system by providing an initial set of UML use cases and sequence diagrams for the core functionality of the proposed system, divided into four broad categories. For each category a general description is given followed by the use case diagram and their specification.

2. Registration / Authentication

2.1. Use Cases
As we need the system to be safe from unauthorized access, the system should employ an advanced authentication/registration mechanism as shown in Figure 1. In its basic form, a new user’s registration should be approved by a teacher and the login procedure should be based on the typical username/password combination.

User registration and authentication use case diagram

Figure 1. User registration and authentication use case diagram

2.1.1. Register

Name: Register

Identifier: A1

Actors: User

Description: Describes the user’s registration procedure.

Preconditions:

1. No active login exists in the application that is running in the user’s device.

Basic Flow:

1. User chooses the option “Create a new account”

2. User enters the required information (username, password and an email account).

3. The server validates the data making sure the username is unique, the email address has not been used for another registration and the password meets predefined complexity rules (length etc.).

4. The server creates the new user’s account.

5. The server notifies the user that his registration is complete.

6. Include Use Case A3 “Approve Registration”

7. The use case ends in success condition.

Alternate Flow:

3.1. The server fails to validate one or more fields.

3.2. The server notifies the user about the field failed to validate.

3.3. The use case ends in failure condition.

Post conditions:

Success: The user is logged in to the system.

Failure: The user returns to the login screen.

2.1.2. New Registration Approval

Name: Approve Registration

Actors: User, Teacher

Identifier: A2

Description: Describes the user’s registration approval by a teacher.

Precondition: A user has submitted her details in order to create a new user’s account.

Basic Flow:

1. The server sets the user’s account in disabled state and send a notification containing an approval link to the teacher.

2. The teacher approves the new account.

3. The server enables the user’s account and notifies the user.

4. The use case ends in success condition.

Alternate Flow:

2.1. The teacher doesn’t approve the new account (i.e. she ignores the notification)

2.2. The use case ends in failure condition.

Post conditions:

Success: The user has a valid account and can now login to the system.

Failure: The user cannot login to the system.

2.1.3. Reset Password

Name: Reset Password

Actors: User

Identifier: A3

Description: Describes how the user can reset her password in case she forgot it.

Precondition: A user isn’t logged in the client application.

Basic Flow:

1. The user choose the “Forgot my Password” option.

2. The user enters his email address.

3. The server verifies that the provided email address is associated with a user’s account.

4. The server disables the current password.

5. The server sends an email to the user’s email address containing a one-time password reset link, and her user name.

6. The user clicks on the link in the email.

7. The server verifies the one-time link and asks from the user a new password.

8. The server updates the user’s account with the new password.

9. The use case ends in success condition.

Alternate Flow:

3.1. The provided email address is not associated with a user’s account.

3.2. The server notifies the user.

3.3. The use case terminates in Failure 1 condition.

6.1. The user doesn’t click on the provided one-time password reset link.

6.2. The use case terminates in Failure 2 condition.

Post conditions:

Success: The user’s password is reset and she can now use the new password login to the system.

Failure 1: The user’s password is not changed.

Failure 2: The user’s password is disabled and she cannot login to the system.

2.1.4. Login

Name: Login

Actors: User

Identifier: A4

Description: Describes how the user logs in to the system.

Precondition: A user isn’t logged in the client application.

Basic Flow:

1. The user enters her username and password.

2. The server verifies that the provided information is correct.

3. The server creates a new session for the user and destroys any other active sessions for the same user.

4. The use case ends in success condition.

Alternate Flow:

2.1. The provided username/passwords combination is not correct.

2.2. The server notifies the user.

2.3. The use case terminates in Failure condition.

Post conditions:

Success: The user is logged in to the system.

Failure: The user is no logged in to the system.

2.2. Discussion

We deliberately didn’t include a typical “Remember me” functionality in order a user to be able to login without providing a username/password, as this could impose a security risk in case of stolen or lost mobile devices. In that case a malicious user could be able to use the system and impersonate the devices’ owner.

We understand that the fact that a teacher should authorize every registration and that a user should always provide a username/password in order to gain access to the system, may be inconvenient in many application’s scenarios, so the system should be designed in such way that it can be easily extended with other registration approval and authorization mechanisms.

Such mechanisms, may include context based approaches like proximity based authentication and registration approval where a user can register without approval or can login without providing a username/password combination, if a teacher is in proximity. In this case, the location proximity can be inferred by the system, using knowledge of the shared radio environment in a way similar to the work of Varshavsky et al. [1]

Furthermore, we propose the notion of trusted locations in which a user can login without providing a username/password combination. Such trusted locations, could be for example a user’s home. Our concern here is that as the system needs to store user’s location information, this should be done in a way that respects user’s privacy, using approaches as those described in the work of Narayanan et al. [2] or Puttaswamy et al. [3]. In [2] several secure protocols that support private proximity testing at various levels of granularity are described and is also studied the use of “location tags” generated from the physical environment in order to strengthen the security of proximity testing. In [3] LocX is introduced, which is a novel alternative that provides significantly improved location privacy without adding uncertainty into query results or relying on strong assumptions about server security. Our key insight is to apply secure user-specific, distance-preserving coordinate transformations to all location data shared with the server. The friends of a user share this user’s secrets so they can apply the same transformation.

3. Collaborative Activities

In this section we describe the use cases and the sequence diagram for the collaborative activities that are performed utilizing the BigBlueButton Server. We use the BigBlueButton’s term “meeting” for describing any type of collaboration activity.

3.1. Use Cases

Figure 2 provide the general use case diagram for the collaboration activity. As the system may contain different types of meetings in which users can interact with each other, we don’t describe each meeting’s use case but a general (abstract) use case.

Collaboration activities use case diagram

Figure 2: Collaboration activities use case diagram

3.1.1. Schedule Meeting

Name: Schedule Meeting

Actors: Teacher or Student

Identifier: C1

Description: Describes how the user can schedule a Meeting for a collaboration activity.

Precondition: The user is logged in to the system as either a Student or a Teacher.

Basic Flow:

1. The user selects the “Schedule a Meeting” option.

2. The server provides the user with a list of available meeting types according to the user’s role.

3. The user selects a meeting type from the available list and enters a date/time for the schedule.

4. The server creates in the user’s calendar a pending new entry for the scheduled meeting.

5. Include Use Case C2 “Invite Users”

Post conditions:

Success: A new schedule for a meeting is entered in the participants’ calendars.

Failure: Nothing changes.

3.1.2. Invite Users

Name: Invite Users

Actors: Teacher or Student

Identifier: C2

Description: Describes how a user can invite users to join a scheduled meeting, she has created.

Precondition: The user has scheduled a meeting.

Basic Flow:

1. The user selects the scheduled meeting and chooses the “Invite Users” option.

2. The server provides the user with a list of users according to the user’s role (list of Teachers/Students in case she is a Student and additionally list of Parents in case she is a Teacher).

3. The user selects from the list the users she want to invite.

4. The server creates in the invited users’ calendars a pending new entry for the scheduled meeting, and sends them a notification.

5. For each invited user include Use Case C3 “Accept Invitation”

Post conditions:

Success: A new schedule for a meeting is entered in the participants’ calendars.

Failure: Nothing changes.

3.1.3. Accept Invitation

Name: Accept Invitation

Actors: User

Identifier: C3

Description: Describes how a user accepts the invitation to join a scheduled meeting.

Precondition: The user has received an invitation to join a scheduled meeting.

Basic Flow:

1. The user accepts the invitation.

2. The server updates the status of the meeting in user’s calendar as confirmed.

3. The use case ends in success condition.

Alternate Flow:

1.1. The user rejects the invitation

1.2 The use case ends in failure condition.

Post conditions:

Success: A new confirmed schedule for a meeting is entered in the participants’ calendars.

Failure: The pending scheduled meeting is removed from the user’s calendar.

Extension points:

2: Use Case C4: Approve Meeting.

3.1.4. Approve a Scheduled Meeting

Name: Approve Meeting

Actors: Teacher or Parent

Identifier: C4

Description: Describes how a Teacher or a Parent can approve a meeting in which only Students are participating.

Precondition: A Student has scheduled a new meeting and only other Students are invited.

Basic Flow:

1. A notification is send to the Student’s parent and teacher, informing her about the scheduled meeting.

2. The Teacher and the Parent approve the Student’s participation in the meeting.

3. The server updates the status of the meeting in Student’s calendar as confirmed.

4. The use case ends in success condition.

Alternate Flow:

2.1. The Teacher and the Parent rejects the Student’s participation in the meeting.

2.2 The use case ends in failure condition.

Post conditions:

Success: A new confirmed schedule for a meeting is entered in the Student’s calendar.

Failure: The pending scheduled meeting is removed from the user’s calendar.

3.1.5. Join Meeting

Name: Join Meeting

Actors: User

Identifier: C5

Description: Describes how a User joins a meeting.

Precondition: A confirmed schedule for a meeting exists in the User’s calendar.

Basic Flow:

1. A predefined amount of time before the meetings scheduled time the server send a reminding notification to the User.

2. The User clicks on the link in the notification.

3. The server joins the user to the meeting with the appropriate role (either a moderator or viewer) according to the meeting’s creator or type.

4. The use case ends in success condition.

Alternate Flow:

1.1. The User views the list of his scheduled meeting in the calendar.

1.2. The User selects to join a meeting scheduled to begin in a predefined amount of time from now.

2.1. The User ignores the notification.

2.2 The use case ends in failure condition.

Post conditions:

Success: The User is joined in the meeting.

Failure: The User is not joined in the meeting.

3.2. Sequence Diagram

As we saw in our previous article when describing the system’s architecture [4], in the collaboration activities except from the client initiating the request, there are several involved servers for fulfilling it. The coordinator is the Management Server (MS) and the sequence of the exchanged messages is shown in Figure 3. The MS server’s message exchange with the BS server should be either through BigBlueButton’s API [5] (e.g. getMeeting, create and join meeting API calls) or by using Red5’s Remote Shared Objects [6] (e.g. the “meeting destroyed” message).

Collaboration Activities Sequence Diagram

Figure 3: Collaboration Activities Sequence Diagram

4. E-learning Activities

In this section we describe the use cases and the sequence diagram for the E-learning activities that are performed utilizing the E-learning (Moodle) Server (ES).

4.1. Use Cases

Figure 4 provide the use case diagram for the course and test e-learning activities.

E-learning Activities Use Case diagram

Figure 4: E-learning Activities Use Case diagram

4.1.1. Manage Course

Name: Manage Course

Actors: Teacher

Identifier: E1

Description: Describes how a Teacher can manager (create, edit, delete, assign to Students) a Course.

Precondition: The Teacher is logged in to the system.

Basic Flow:

1. The Teacher selects a Course from the list of available Courses.

2. The client application opens a web browser window pointing to the Moodle Server’s Course page.

3. The Teacher makes the modifications she needs to the Course.

4. The Teacher saves the modifications.

5. The use case ends in success condition.

Alternate Flow:

1.1. The Teacher creates a new Course.

3.1. The Teacher doesn’t perform any modifications.

3.2. The use case ends in failure condition.

4.1. The Teacher doesn’t save the modifications.

4.2. The use case ends in failure condition.

Post conditions:

Success: The Course is updated according to the Teacher’s modifications.

Failure: The Course is not updated.

4.1.2. Manage Test

Name: Manage Test

Actors: Teacher

Identifier: E2

Description: Describes how a Teacher can manager (create, edit, delete, assign to Students) a Test.

Precondition: The Teacher is logged in to the system.

Basic Flow:

1. The Teacher selects a Test from the list of available Tests.

2. The client application opens a web browser window pointing to the Moodle Server’s Test page.

3. The Teacher makes the modifications she needs to the Test.

4. The Teacher saves the modifications.

5. The use case ends in success condition.

Alternate Flow:

1.1. The Teacher creates a new Test.

3.1. The Teacher doesn’t perform any modifications.

3.2. The use case ends in failure condition.

4.1. The Teacher doesn’t save the modifications.

4.2. The use case ends in failure condition.

Post conditions:

Success: The Test is updated according to the Teacher’s modifications.

Failure: The Test is not updated.

4.1.3. Study Course

Name: Study Course

Actors: Student

Identifier: E3

Description: Describes how a Student can study a Course assigned to her.

Precondition: The Student is logged in to the system.

Basic Flow:

1. The Student selects a Course from her list of available Courses.

2. The client application opens a web browser window pointing to the Moodle Server’s Course page.

3. The Student is navigated to the point she has stopped last time, or to the beginning of the course if it is the first time she opens it.

4. The Student studies the Course’s material.

5. The Users stop studying and exits the selected Course.

6. The server keeps track of the point the User has stopped.

7. The use case ends in success condition.

Post conditions:

The Course’s progress is marked for the current Student.

4.1.4. Take Test

Name: Take Test

Actors: Student

Identifier: E4

Description: Describes how a Student can take a Test assigned to her.

Precondition: The Student is logged in to the system.

Basic Flow:

1. The Student selects a Test from her list of available Test.

2. The client application opens a web browser window pointing to the Moodle Server’s Test page.

4. The Student completes the Test.

6. The server scores the Students performance and marks the Test as completed for the current Student.

7. The use case ends in success condition.

Post conditions:

Test is scored and marked as completed for the current Student.

4.2. Coordination between the Client Application, Management and E-learning (Moodle) Server.

As in case of the collaboration activities, also in the e-learning activities except from the client initiating the request, there are several involved servers for fulfilling it. Given the web based nature of Moodle, the MS server’s role is limited to logging in to the ES server the current user through Moodle’s API [7] and then instructing the client application to navigate to the relevant Moodle’s web page. The client web browser should be integrated into the application similar to the example implementation provided at [8].

5. Other (management) Activities

In this final section we describe the rest of core uses cases that just involve the Client Application and Management Server and are related to various management activities like user profile, calendar and notes management as described in the system’s high level description [4].

5.1. Use Cases

The use case diagram is depicted in Figure 5.

Management activities use case diagram

Figure 5: Management activities use case diagram

5.1.1. Manage

Name: Manage

Actors: User

Identifier: M1

Description: Describes how a User can manage her profile, calendar, notes or (if she is a Teacher) other users’ profiles.

Precondition: The User is logged in to the system.

Basic Flow:

1. The User chooses either “Manage Profile”, “Manage Calendar”, “Manage Notes”, or (if she is a Teacher) “Manage Users”.

2. The server returns a list of manageable objects according to the user’s role and choice (profile fields, calendar’s events, notes, or list of users).

3. The Users selects a manageable object from the list.

4. The User modifies the selected object.

5. The Users saves the modifications.

6. The use case ends in success condition.

Alternate Flow:

1.1. The User creates a new object if it is applicable according to her current choice (new note or calendar event).

4.1. The Users doesn’t perform any modifications.

4.2. The use case ends in failure condition.

5.1. The User doesn’t save the modifications.

5.2. The use case ends in failure condition.

Post conditions:

Success: The selected object is updated according to the User’s modifications.

Failure: The selected object is not updated.

Extension points:

2: Use Case M3: Share Note.

5.1.2. View Online Users

Name: View Online Users

Actors: User

Identifier: M2

Description: Describes how a User can view who is online according the User’s role rights.

Precondition: The User is logged in to the system.

Basic Flow:

1. The User chooses the “View online users” option.

2. The server returns a list of online users according the User’s role rights.

3. The use case ends.

5.1.3. Share Note

Name: Share Note

Actors: User

Identifier: M3

Description: Describes how a User can share a Note he owns with other Users.

Precondition: The User has selected a Note he owns.

Basic Flow:

1. The User chooses the “Share Note” option.

2. The server returns a list of Teachers and Students.

3. The User selects from the list the user(s) she wants to share the Note with.

4. The server notifies the users with which the Note is shared.

3. The use case ends in success condition.

Alternate Flow:

3.1. The User doesn’t select any user from the list.

3.2. The use case ends in failure condition.

Post conditions:

Success: The Note is shared with the selected users.

Failure: The Note is not shared.

5.1.4. Review My Child(ren)

Name: Review My Child(ren)

Actors: Parent

Identifier: M4

Description: Describes how a Parent can review her child(ren)’s activities in the system.

Precondition: The Parent is logged in to the system.

Basic Flow:

1. The Parent chooses either “Review Notes”, “Review Calendar” or “Review Activity”.

2. The server returns a list of objects according to the Parent’s choice.

3. The use case ends.

Extension points:

2: Use Case M5: Add Restriction.

5.1.5. Add Restriction

Name: Add Restriction

Actors: Parent

Identifier: M5

Description: Describes how a Parent can add a restriction to her child(ren)’s calendar.

Precondition: The Parent has selected her child(ren)’s calendar (in “Review Calendar”), or a scheduled meeting (in “Review Activity”).

Basic Flow:

1. The Parent selects a date (or date range) in the calendar and chooses “Add restriction”

2. The Parent adds time restrictions for the selected date or date range.

3. The system notifies the Student and her Teacher about the restriction.

3. The use case ends.

Alternate Flow:

1.1. The Parent selects a scheduled meeting.

1.2. The Parent disapproves her child(ren) joining that meeting.

1.3. The system notifies the Student and her Teacher about the restriction.

1.4. The use case ends.

Post conditions:

A restriction for a Student is applied by her Parent.

6. Conclusion

In this article, we provided an initial set of UML use cases for the core functionality of the proposed system, trying to be as concise as possible by omitting obvious details such as CRUD operations in the various modification related use cases. We also provided a sequence diagram for the coordination of the collaborative activities and finally we raised some concerns related to securing the system from unauthorized access.

The described use cases and concerns raised would be good candidates for inclusion in the electronic survey which would be circulated to foreign language teachers.

7. References

[1] Varshavsky, A., Scannell, A., LaMarca, A., & De Lara, E. (2007). Amigo: Proximity-based authentication of mobile devices (pp. 253-270). Springer Berlin Heidelberg.

[2] Narayanan, A., Thiagarajan, N., Lakhani, M., Hamburg, M., & Boneh, D. (2011, February). Location Privacy via Private Proximity Testing. In NDSS.

[3] Puttaswamy, K. P., Wang, S., Steinbauer, T., Agrawal, D., El Abbadi, A., Kruegel, C., & Zhao, B. Y. (2014). Preserving location privacy in geosocial applications. Mobile Computing, IEEE Transactions on, 13(1), 159-173.

[4] Salatas, J. A proposal for developing a mobile based environment to help children learning a foreign language. ICT Research Blog. Retrieved July 28, 2014.

[5] API – bigbluebutton – Using the BigBlueButton 0.81 API. Retrieved July 28, 2014.

[6] Gong, S., Gregoire, P., Rossi, & D. Red5 – Reference Documentation Version 1.0. Red5 Open Source Flash Server. Retrieved July 28, 2014.

[7] Core APIs – MoodleDocs. Retrieved July 28, 2014.

[8] Carr, D., & Gonzale, D. Using Flash CS4 and Adobe AIR to build custom browsers for e-learning and social networking. Adobe Developer Connection. Retrieved July 28, 2014.

Creative Commons Attribution-ShareAlike 3.0 Greece
This work by John Salatas is licensed under a Creative Commons Attribution-ShareAlike 3.0 Greece.