MeetMe Planner Design description. Version 2.2

Transcription

1 Design description Version 2.2

2 Revision History Date Version Description Author First version Danijel Sokač Francesco Giarola Mockups update and new use case handling Danijel Sokač Francesco Giarola ER model, update of sequence diagrams Carolina Casali Mohamed Mehdi Kaabi Danijel Sokač Technologies for functionality tests Danijel Sokač Revision Francesco Giarola Milica Jovanovic Final Revision Milica Jovanovic Page 2

3 1. Introduction Purpose of this document Purpose of this document is to capture important design decisions we have made in the project, and should provide a good basis for understanding the code. Document organization The document is organized as follows: Section 1, Introduction, describes contents of this guide, used documentation during developing process etc. Section 2, Short Background, describes who is the customer and what is the purpose of the project from the customer s perspective. Section 3, System overview, describes operational context. Section 4, Software architecture, describes what does the overall decomposition of the software into modules/units/components looks like. Section 5, Graphical user interface, describe the structure and general layout of the interface. Intended Audience The intended audience is: new member joining the group, or someone who will maintain or evolve the system further Definitions Keyword Project Customer User Visitor Event Time slot Planner User private calendar Definitions The customer who requested the software product A client who provided his credential to the system and has been authenticated by the system A non authenticated User User created happening An interval of time for the proposed event, that can be free or occupied The tentative calendar containing events user was invited for shown in the appropriate time slots Calendar provided by an external service connected to the respective user Page 3

4 Attendant A user invited to an event Table 1. Table of definitions 2. Short Background Today's planners do not meet the needs of a user. Person willing to easily schedule an event can stump into many problems in the process of organizing an event. The problem can become even more complex when the number of people willing to attend the event grows. The proposed timeslots can be spread over few different event times, because each of the attendants have their own schedules they have to cope with and they have scheduled before. Because of the many constraints force upon the other attendances it is hard to find appropriate time slot that can work out for everyone. Usually in this situation the event is held over conversation, which can become quite messy. 3. System overview Description Our system will consist of web based application with responsive screen layout which can be opened using any web browser. This way, our app is not limited to any platform. High level design of system can be seen in Figure 3. Figure 3. High level design of application Page 4

5 System features The main functionality for this application is to provide possibility to arrange event using personal calendars of event attendants, with focus on using Google calendar. According to this, all attendants will need to have account in our app and provide access to personal calendars to our system. Main problem we are focusing here is security and privacy. To fulfil this requirement our system will not provide personal calendars to any other user. Personal calendars will only be used during calculation of free time for event. Page 5

6 4. Software architecture 4.1 Conceptual design For this project we will use model-view-controller (MVC) architectural pattern (see. Figure 2). MVC pattern splits application on three logical components and defines interaction among them. This separation of responsibilities allows flexibility down the road. Model stores data that is retrieved according to commands from the controller and displayed in the view. View generates an output presentation to the user based on changes in the model. While controller sends commands to the model to update model s state, it can also send commands to its associated view to change the view s presentation of the model. Figure 4.1. Software architecture Page 6

7 4.2 Technologies used At the front-end we will use HTML5, CSS3, Bootstrap and AngularJS. For the logic layer (back-end), Node.js will be used. As database, we will use PostgreSQL database. To provide high performance of the system we will use more asynchronous calls to prevent unnecessary page loadings. Also APIs to support some functionalities are used such as Google API and SendGrid API. For the functionality testing we are going to use Cucumber + Watir webdriver framework which will be implemented using Ruby programming language. 4.3 Sequence diagrams Registration Visitor fills registration page with his data and clicks Register. Data are contained in View. Controller uses Data contained in View for Registration. After that, a new user is created in the Database. Controller requires registered User s data. If the registration is successful, View receives confirmation recording message; otherwise, it receives an error message. The Visitor has the message in the View. Figure 4.2. Sequence diagram for Registration Login User presses "login" after entering his username and password that are stored in the View. Controller uses login information contained in the View. Database finds user using the data contained in Controler. Controller requires user existence. If the login is successful View is redirected to the home page; otherwise, it receives an error message. User has the message in the View. Page 7

8 Figure 4.3. Sequence diagram for Login Logout User clicks "logout" in View. Controller receives logout information from View and close the session. View is redirected to login page and shows the response. Page 8

9 4.3.4 Edit profile Figure 4.4. Sequence diagram for Logout User clicks edit profile in View. Controller requests setting from the View that is redirected to the setting page. User sees response, updates user settings. Changes are confirmed in the View. Controller receives update setting and then loads it in Database. Controller receives update successful information. If update is successful, View receives a successful message; otherwise, it receives an error message. User has the message in the View. Figure 4.5. Sequence diagram for Edit Profile Add calendar View receives a request to edit user s profile. Controller requests settings page that is shown on View. User sees response and chooses how to link calendar in View. If he chooses importing Google calendar Google API requests enter credentials dialog from View and shows them to User, who enters his Google credentials and loads them in Google API. If there is an error, Google API sends to User an error message; otherwise, View receives the session and sends a message in User. View receives confirmation of the added calendar and adds a new calendar in Controller. Controller creates calendar in Google API and stores calendar in Database. Controller requires calendar registration status. If the calendar registration status is successful, View receives Page 9

10 success message; otherwise, it receives an error message. The User has the message in the View. If the User chooses to import his calendar from File System, a new dialog is requested from the Controller and sent back to the View. User enters the calendar name click on button for importing the calendar. Controller contacts the File System where the user picks the file, if no error the Controller has the chosen calendar. After successful import of the calendar the calendar information are stored in the DB. If the User chooses to import calendar by URL, user enters the calendar name and URL of the calendar, they are sent through View to Controller when user clicks the Add calendar button. Controller contacts the icalparser interface with the URL string, finds the calendar and if successful sends back the info about the calendar back to the Controller which if everything passes without error notifies the user. Afterwards the calendar information are stored in the DB. Page 10

11 Figure 4.6. Sequence diagram for Add Calendar Delete calendar User clicks edit profile in View. Controller requests settings from View that is redirected to the setting Page 11

12 page. User sees response, clicks for deleting calendar and confirms it in the View. Controller receives request to delete calendar and removes it from Database. Controller receives a success message and sends it in View. The Visitor has the message in the View. Figure 4.7. Sequence diagram for Delete Calendar Edit calendar View receives a request to edit calendar from User. View edits calendars in Controller that loads calendar data in Database. Controller edits calendar in View. User receives the response, edits calendar and saves changes in View. Controller receives update calendar data and then loads it in Database. Controller receives successful status message and sends it to View. User has the message in the View. Page 12

13 Figure 4.8. Sequence diagram for Edit Calendar Invite friends User clicks invite friends in View. User obtains the expand view for friend , enters friend and clicks invite in the View. Controller receives the request to invite friends. It sends for friend s invitation and then a successful message in View. User has the message in the View. Page 13

14 Figure 4.9. Sequence diagram for Invite Friends Recover password User clicks forgot password in the View. Controller receives forgot password request and sends the form to View. User enters his and clicks recover password in View. Controller receives the request to recover password via . It sends recover password and then a successful status message in View. User sees response, clicks on link in and recovers password in Controller. View receives recover password form and sends response to User who enters new password and clicks OK in View. Controller obtains changed password and updates password in Database. Controller requires success status. If the status is successful View is redirected to login; otherwise, it receives an error message. User has the message in the View. Page 14

15 Figure Sequence diagram for Recover Password Schedule event View receives the User s request to schedule event and schedules event in Controller. View is redirect to schedule event page. User sees response, enters event data, selects attendants from user list (attendants suggestions), enters of attendants without account, selects mandatory attendants, selects time slots he is proposing for the event, adds tag if he wants and creates event in View. Controller notifies attendants and stores event information in Database. Controller receives status information. If status is successful, View is redirected to home page; otherwise, it receives an error message. User has the message in the View. Page 15

16 Figure Sequence diagram for Schedule Event Choose time slots Attendant selects concerning event in View. Controller gets event from View that receives event details. Attendant sees event details, selects time slots and confirms it in View. Controller receives available time and stores information in Database. Controller is informed about status, calculates event and notifies organizer. Attendant receives response. Page 16

17 Figure Sequence diagram for Choose time slots.3.12 Run calculation manually User clicks run calculation in View. Controller gets event time from View, calculates event time and sends possible event time in View. User has the message and selects best time in View. Controller obtains time chosen and saves event time in Database. Controller receives a successful message and notifies attendants. User has the message in the View. Page 17

18 CalculateMeetingTime() Figure Sequence diagram for Run calculation manually Controller stores all attendants in Database. Controller requests attendants from Database, syncs calendars and updates Calendar in Database. Controller receives a successful message, aligns to same timezone and calculates event time. Page 18

19 Figure Sequence diagram for CalculateMeetingTime() See All events Users opens home page in View. Controller receives get all events request from View and sends gets all events request to Database. Controller obtains events from the Database, adds them to home page and sends home page in View. User sees response. Page 19

20 Figure Sequence diagram for See all events Edit event User selects event in View. Controller receives information about selected event and queries the Database. Controller receives event details from Database and sends them in View. User sees response, edits event and saves changes in View. User sees response and changes are confirmed in the View. Controller receives update event and then stores it in Database. Controller receives successful message and notifies attendants by updating the event data in their calendars. User has the message in the View. Page 20

21 Figure Sequence diagram for Edit event Delete event User selects event in View that sends selected event information to Controller. Controller receives event information and queries the Database that sends requested event details to Controller if the requested event exists in Database. View receives event details from Controller. User has response, clicks delete and confirms delete in View. Delete event request is sent to Controller. Controller forwards the delete event request to Database i.e server side. If the deletion is successful Controller receives a successful message from Database, notifies attendants by changing their calendars and sends a successful message in View of the user that performed the deletion. User has the message in the View. Page 21

22 Figure Sequence diagram for Delete event Page 22

23 Manually sync calendar User clicks synchronize calendar in View that calls the sync calendar function passing parameters of the calendar user wants to sync in Controller. After successful sync, the Controller sends a successful message back to View. User has the response in the respective View. Figure Sequence diagram for Manually sync calendar sync Calendar() Controller loads the sync token from the Database. Controller gets the calendar from Google API using the previously obtained token. Controller stores updated calendar in Database, if the transaction was successful Controller then receives a successful message. Page 23

24 Filtering events by tag Figure Sequence diagram for sync Calendar User clicks on a tag from the list of tags showed in View called eventmodal that calls the method filterbytags by passing as argument tagtitle and userid in Controller. The Controller contacts the server side which extracts the data from the Database and sends the response to the appropriate View (myevents page) which will contain the events of a user with specified tag. Page 24

25 Save back to the everyone s calendars Figure Sequence diagram for Filtering events by tag When all the attendees respond by picking their prefered time slot, the event organizer clicks on Run calculation manually in the View called myevents calls method calculation with appropriate arguments in Controller. Controller contacts the server side which updates data in Database and sends response to the View containing the calendar which now shows the appropriate event in the time slot calculated by the function in Controller. Page 25

26 Figure Sequence diagram for Save back to everyone s calendars 5. Graphical user interface To make our application easy to use for everyone, we will try to provide user interface as simple as possible and also intuitive to use. Home Page This page is composed by three parts, contains general informations about the app and the team. Page 26

27 Page 27

28 Page 28

29 Registration Page From this page, guests are able to register themselves. Page 29

30 Page 30

31 Login Page This is the common login page Page 31

32 Recover Password From here the user can recover his password. Page 32

33 Calendar Page Here the user can view at a glance all the events he is involved in. Page 33

34 Profile Page Within this page registered users can edit all theirs personal informations Page 34

35 New Event Page Here the user can create a new event Page 35

36 My Events Page Here the user can manage all events he created Page 36

37 Page 37

38 Page 38

39 Invite Friend Page Here the user can invite a friend to join the application by specifying his address. Page 39

40 Event Participation Page Here the user can choose as many timeslot as he wants for a specific event. Page 40

41 6. ER model of DB We use the ER model (Entity-Relationship model) to describe information and data of our application. The entities are related to each others and they can have different dependencies. There are nine entities in our model. Each of these entities has attributes that describe it. Page 41

42 Page 42

43 Figure 6. ER model of Just Meet application Page 43