A Day In a City

1. A Day In a City Academic Advisor: Prof. Ronen Brafman Team Members: Ran Isenberg Mirit Markovich NoaAharon AlonFurman

2. Introduction • When most people go on a vacation or a day trip, they usually plan a specific schedule. • Planning a day trip isn't always an easy task. • “A Day in city“ project strives to make finding the best schedule and the best activities for each user's unique taste as easy as double clicking.

3. Current Situation Friends Lametayel.co.il Other Sources Lonely Planet

4. The Problem • The “average Joe” needs to search, plan and integrate many information pieces from numerous sources. • It is not customized to the average Joe’s style or desires. The “average Joe” has to plan the schedule by himself. • It takes a lot of time and sometimes it can be very confusing (contradicting data) and not easy.

5. Purposed Solution • A system that recommends itineraries of activities for a day trip in a city by using background knowledge & information about the user (Average “Joe”) it obtains during the session in order to suggest an itinerary.

6. Purposed Solution – How? • Modeling the problem domain and user preferences by creating a corresponding Influence diagram. • User preferences will be determined by answering questions, ranking activities and manual deletion of activities. • Usage of optimization algorithms (one of them a greedy algorithm) in order to find the desired schedule. • Communication with the user is done via a web interface.

7. System Architecture

8. System Architecture - Cont. • GUI interface website – Accessible from an internet webpage • GUI controller –It is the middle man between the projects' core and the user GUI and thus the user himself. • Server Computational unit (SCU) – Runs the various algorithms on the City Model according to the user preferences and input received from the GUI controller and sends the results back to it. • City Model – A predefined influence diagram with all the activities, probabilities, type of activities and user preferences. It is be based on the API of Genie & Smile.

9. System Architecture - Cont. •  Database – Holds information about the places that the user can visit: name, opening hours, time to get from one place to the other etc. Also holds a set of questions that the program can ask the user. • Final Schedule – The final result of the computational unit. It is consisted of the top valued activities that fit into a day and takes Into account the time needed to travel between them.

10. System Flow

11. City Model Example

12. Main Functional Requirements Client User Interface 1. Answering a question. 2. Evaluate an activity 3. Changing the duration of an activity in the schedule. 4. Removing an activity from the schedule. 5. Open activity window 6. Search for an activity 7. An Activity in the schedule details 8. Close the search result window

13. User Interface Example

14. Main Functional Requirements Inner Processing 1. What question should we display the client ? * The program will include an algorithm that will compute the best questions to ask. * “Best question” - means that by answering this question, the program will receive the best information to calculate the best schedule. * The algorithm will use the “value of information” function from the smile API to achieve this knowledge.

15. Main Functional Requirements 2. Which places should the program recommend to the client? Which places the client would like? Our algorithm will use the Smile engine to calculate for each activity the probability that user will like that activity. It will then sort them by that factor and display the top 5 activities so the user could rank them. The places that are shown, will give the user the chance to see other events that are perhaps not included in the current schedule.

16. Main Functional Requirements 3. What happens when a user ranks an activity or answers a question? The system updates the City model through the Smile API, thus adapting the model to the user’s unique taste!

17. Main Functional Requirements 4. How to decide which schedule to offer the client? Greedy algorithm- try every combinations of events. For each combination check that the combination satisfies the time constraints. For each one that does , calculate its “value”. Return the schedule with the highest value that satisfies the constraints. Schedule value – adding the values of all utility nodes using Smile API on the City model. This algorithm run time is an exponential time. One of our project’s goals is to find a faster and better algorithm.

18. Non Functional Requirements • Speed, Capacity & Throughput a. The server will support up to 20 simultaneous connections. b. The desired response time from the server containing the generated schedule is 2-3 seconds; however, a response within 20 seconds will be also acceptable.

19. Non Functional Requirements- Cont • Modularity The database will be generic enough so new cities could be added in the future in an easy way. • Programming Language & External APIs The system will be implemented in the visual C# language in Visual Studio 2010 IDE. The system will use the Smile engine API.

20. Non Functional Requirements- Cont • SE Project constraints • Fully operational demo of the system, demonstrating the functionality of the activities selection and schedule construction algorithms. • Creation of the main schedule builder algorithm as a Greedy algorithm. However, the creation of a better and efficient algorithm (in addition to the greedy) will be considered and researched as the project progresses.

21. Use Cases

22. Use Cases- Actors • The only actor in our system is a guest actor. A guest actor is any person who wants to use the websites functionalities and to create a trip schedule. • That includes: • Answering questions regarding his/her preferences. • Changing the schedule (changing duration or removal of activities). • Rank the value of an activity. • Search for an activity. • Open activity information window.

23. Answer Question • Description: The guest can answer questions presented by the website in order to improve his/her schedule. • Pre-conditions: the website finished loading and the server is up and running. • Post-conditions: the question (or even all of them) will be replaced and the information (the answer) will be used to create a better fitting schedule

24. Change Schedule • Description: The guest can change properties of the schedule suggested such as time or duration of an activity. • Pre-conditions: the website finished loading and the server is up and running. • Post-conditions: the schedule will be changed accordingly.

25. Evaluate Activity • Description: The guest can rank the value of an activity in order to improve his/her schedule. • Pre-conditions: the website finished loading, the activity is presented on the top right window and the server is up and running. • Post-conditions: the information will be used to create a better fitting schedule.

26. Search for an Activity • Description: The guest search for an activity of his/her choice. • Pre-conditions: the website finished loading, the activity is at the specified city and in the database and the server is up and running. • Post-conditions: the activity will be presented on the “top activities” panel (top right window).

27. Open Activity Information Window • Description: The guest opens information window of an activity in order to learn more about it. • Pre-conditions: the website finished loading, the activity is presented on the top right window and the server is up and running. • Post-conditions: activity information window is open with the correct information about the activity.