나그넷길
프로젝트 개요
기술개발 과제
국문 : CodeTour(사용자 맞춤 여행일정계획 앱)
영문 : Code Tour
과제 팀명
나그넷길
지도교수
김성환 교수님
개발기간
2020년 3월 ~ 2020년 6월 (총 4개월)
구성원 소개
서울시립대학교 컴퓨터과학부 2017920022 맹유진(팀장)
서울시립대학교 컴퓨터과학부 2013560033 이태현
서울시립대학교 컴퓨터과학부 2017920006 김대양
서울시립대학교 컴퓨터과학부 2017920007 김바다
서론
개발 과제의 개요
개발 과제 요약
◇ 사용자가 원하는 지역의 여행장소 추천
◇ 사용자가 원하는 테마의 여행장소 주전
◇ 여행일정 자동계획
◇ 여행장소 위치, 여행경로 안내
◇ 지도를 이용한 여행경로 시각화
개발 과제의 배경
오늘날에는 여행지역과 관련된 정보를 인터넷검색을 통해 쉽게 얻을 수 있다.
그러나 여행지에 대한 정보들은 인터넷 여기저기에 파편적으로 위치하며, 사용자가 장소들의 정보들을 직접 모아 여행일정을 계획해야한다.
이러한 방법은 인터넷검색에서 상위에 뜨는 장소만을 추천 해 인기있는 특정장소 이외의 정보는 찾기가 힘들고, 오랜 시간이 소요된다.
CodeTour는 사용자에게 자동여행계획기능을 제공하여 시간 단축과 다양한 여행지 추천효과를 목표로 한다.
개발 과제의 목표 및 내용
현재는 사용자가 직접 검색을 통해 정보를 얻고 계획해야하는 어려움이 있다. CodeTour는 사용자가 기본적인 정보만 입력한다면 추가적인 행동 없이 여행일정을 계획해준다. 이를 위해 사용자가 입력한 여행을 원하는 지역, 원하는 테마 등의 정보에 부합하는 관광지들을 Tour API를 이용하여 자동으로 모아주고, 클러스터링을 이용한 내부 시스템의 추천을 통해 일정을 계획해 보여준다. 또한 Tmap API를 통해 추천된 일정의 경로와 관광지 위치를 시각적으로 쉽게 확인 가능하도록 한다.
관련 기술의 현황
관련 기술의 현황 및 분석(State of art)
- 전 세계적인 기술현황
◇ Clustering (군집화)
- ● Clustering은 주어진 개체들을, 몇 개의 부분 그룹으로 나누는 과정을 의미한다. 이렇게 개체들을 나누는 과정을 통해서 클러스터 내부 개체들 사이의 거리는 가깝게, 서로 다른 두 클러스터의 개체들 사이의 거리는 멀게 하는 것이 clustering의 목표이다.
- ● 위 문장에서 개체 사이의 &거리&는 유클리드, 코사인, 자카드 등으로 클러스터링의 대상이 되는 개체의 특성에 따라 다양하게 정의될 수 있다.
- ● 데이터의 차원이 높아질수록 클러스터링이 어려워 진다. 따라서 고차원 데이터를 2-3차원으로 차원축소 후에 클러스터링을 진행하게 될 수도 있다.
Hierarchical Clustering
특정 알고리즘에 의해 데이터들을 연결하여 계층적으로 클러스터를 구성해나가는 방법이다. 클러스터의 개수를 가정할 필요가 없다는 것이 장점이다.
클러스터 간의 거리를 계산하기 위해서 centroid라는 개념을 이용한다. 유클리드 공간에서는, 클러스터의 중간점이 centroid가 되는데, 그 외에 공간에서는 centroid 대신에 clustroid를
이용한다. clustroid는 클러스터 내의 점들 중에 대표 점을 의미한다. clustroid를 찾는 방법은 다양하지만, 보통 클러스터 내의 각 점으로부터 해당 점까지의 거리의 최댓값을 최소화
하는 점을 선택하거나, 평균을 최소화하는 점을 선택한다.
divisive
- - 데이터 전체의 멤버를 담고 있는 하나의 클러스터에서 시작하여 개별데이터로 분리해나가는 식으로 클러스터를 구성하는 방법이다.
Agglomerative (bottom-up)
- - 주어진 데이터에서 개체 하나를 하나의 독립된 클러스터라고 가정한 후, 제일 가까운 두 개의 클러스터씩 붙여나가는 방식으로 진행된다.
Point assignment clustering
k means clustering
- - 처음에 클러스터의 개수인 k를 정하고, 데이터 중에 임의로 k개의 점을 선택한 후에 초기 클러스터로 삼는다. 그 후에 클러스터를 계속 변화시켜나가면서 클러스터링을 완료하는 방법이다.
- - 초기에 k개의 점을 선택하는 방법으로는 완전히 랜덤하게 선택하는 방법이 있고, 처음에 한 점만 랜덤하게 선택 후에 두번째 점부터는 이전에 선택한 점으로부터 가장 멀리 떨어진 점을 순차적으로 선택해나가는 방법도 있다. 후자의 경우 전자보다 클러스터링이 잘 이루어질 확률이 높다는 장점이 있다.
- - 처음에 선택한 k개의 점을 centroid로 하는 초기의 클러스터 k를 만든 후, 전체 점들에 대해 각 점마다 가장 가까운 centroid를 찾아서 해당 클러스터로 그 점을 넣는다. 이렇게 만들어진클러스터의 경우 centroid를 새로 계산해주어야 한다. 새로 찾은 centroid를 바탕으로 이 과정을 클러스터링한 결과가 달라지지 않을 때 까지 반복한다.
- - 가장 가까운 centroid를 찾는 과정과 조정하는 과정에서 유클리드 거리를 사용하게 되므로 유클리드 공간에서만 사용할 수 있다.
- - 최적의 k를 찾는 방법
- 1. 좋은 품질의 클러스터링 결과를 얻기 위해서는 k를 잘 선택하는 것이 중요하다. k를 너무 작게 설정하면 실제로는 다른 클러스터에 있어야 할 것 같은 점들이 같은 클러스터 내에 위치하게 되고, k를 너무 크게 설정하면 거리가 충분히 가까운 두 점이 다른 클러스터에 속하게 되어 비효율적일 수 있다.
- 2. 클러스터링의 품질을 centroid와 다른 점들 사이의 평균 거리를 이용해서 표현한다고 가정하면, 평균거리가 급격히 작아지다가 그 이후부터 큰 차이를 보이지 않는 k를 최적의 k라고 할 수 있다.
- 1. 좋은 품질의 클러스터링 결과를 얻기 위해서는 k를 잘 선택하는 것이 중요하다. k를 너무 작게 설정하면 실제로는 다른 클러스터에 있어야 할 것 같은 점들이 같은 클러스터 내에 위치하게 되고, k를 너무 크게 설정하면 거리가 충분히 가까운 두 점이 다른 클러스터에 속하게 되어 비효율적일 수 있다.
- - 문제점 : 유클리드 거리를 사용하기 때문에 주로 원 형태로 된 클러스터가 생성된다. 따라서 클러스터의 모양이 원 모양이 아닐 때는, 최적의 결과를 얻을 수 없다.
- - 시간복잡도
- 1. 처음에 k개의 점을 찾는 것은 상수시간 동안에 수행할 수 있다. 그 후 각 점에서 가장 가까운 centroid를 찾는 과정의 시간복잡도는 O(Nk)이고, centroid를 조정하는데에 O(n)만큼의 시간복잡도가 소요된다. 이러한 과정을 t번 반복하게 된다면 전체 시간복잡도는 O(Nkt)가 된다. k와 t값에 따라 수행시간이 달라지지만 대체적으로 수행 속도가 빠른 편에 속한다.
- 2. 최적의 k값을 찾는 과정에서 k-means 클러스터링을 O(logN)번 수행하게 된다. 따라서 최적의 k값을 찾으면서, k-means 클러스터링을 하는 과정의 전체 시간복잡도는 O(NktlogN)이 된다.
- 1. 처음에 k개의 점을 찾는 것은 상수시간 동안에 수행할 수 있다. 그 후 각 점에서 가장 가까운 centroid를 찾는 과정의 시간복잡도는 O(Nk)이고, centroid를 조정하는데에 O(n)만큼의 시간복잡도가 소요된다. 이러한 과정을 t번 반복하게 된다면 전체 시간복잡도는 O(Nkt)가 된다. k와 t값에 따라 수행시간이 달라지지만 대체적으로 수행 속도가 빠른 편에 속한다.
CURE (Clustering Using REpresentatives)
- 클러스터의 모양이 정규화 되어있지 않은 데이터를 대상으로 클러스터링 하기에 효율적인 방식이다.
- 2 pass algorithm으로 구성된다.
- 1. 초기 클러스터 찾기
- - 메인메모리에 올린 데이터로 일단 클러스터링을 진행한다.
- 2. 클러스터 내 대표값 뽑기
- - 각 클러스터별로 n개의 대표값들을 최대한 흩어져있게 sampling한 후에 centroid쪽으로 20%이동해서 사용한다. 어떠한 점에 대해서 centroid가 아니라 대표값과의 거리 기준으로 가장 가까운 대표값이 존재하는 클러스터에 점을 넣는 방식으로 진행된다. (이 부분이 k-means clustering과의 차이점을 불러오는 부분이다.)
◇ Open API
- API란 Application Programming Interface의 약자로, 운영체제와 응용프로그램 사이의 통신에 사용되는 언어나 메시지 형식을 말한다. 말 그대로 Application의 Programming을 위한 Interface라고 할 수 있다. 을 위한 Interface라고 할 수 있다.
- 내부 API는 디바이스를 제어할 수 있는 기능들을 의미하며, 외부 API는 디바이스에 저장되어 있는 기능이 아니라, 서비스회사의 API를 통해 사용하는 기능들을 말한다.
- 사람들은 Open API를 이용해 무료로 다양한 컨텐츠를 쉽게 개발할 수 있다. 즉 누구나 사용할 수 있도록 공개된 API를 Open API라고 부른다. 유용한 API들을 잘 이용하면 지도나 번역기 등의 기능들을 직접 개발하지 않고 가져다 사용할 수 있다.
- 구글, 카카오, 네이버 등의 기업들은 개발자들을 위한 API를 제공하는 사이트를 운영하고 있다. 또한 국가에서도 공공데이터포털을 운영하여 다양한 데이터 및 기능을 활용할 수 있도록 돕고 있다.
지도 API
- - 각 api별로 제공하는 기능은 거의 비슷하다.
- - 지도에 마커를 띄우거나 경로를 표시할 수 있고, 키워드를 이용하여 원하는 장소를 검색할 수 있다. 또한 GPS를 이용하여 현재 위치 기반 기능도 이용할 수 있다. 즉, 사용자의 정보를 기반으로한 인터렉티브한 기능을 제공한다.
- - 카카오, 네이버 구글 등 다양한 기업들에서 지도 API를 제공하고 있다. 총 4개 (카카오지도, 네이버지도, 티맵, 구글지도) API의 장 단점을 비교하여 이번 프로젝트에 사용 할 API를 결정하였다.
- - 아래의 표와 같이 비교한 후에, TmapAPI를 사용하기로 결정했다.
종류 | 장점 | 단점 |
카카오 지도 | 자세하고 깔끔한 설명
30만콜 무료 |
에뮬레이터에서 실행 불가능 |
네이버 지도 | 도보 길찾기 기능 제공x | |
티맵 | 티맵 어플 없이 도보/자동차 길찾기 제공 | 단조로운 그래픽 |
구글 지도 | 국내 길찾기 상대적으로 미흡
무료 제공 건수 적음 |
Tour API
- - 국내 유일의 실시간 다국어 관광정보를 제공하는 API이다.
- - 한국관광공사가 보유하고 있는 전국의 다양한 관광정보, 사진정보를 실시간으로 제공 받을 수 있으며, 국내 최대 관광정보 포털 사이트 Visitkorea(www.visitkorea.or.kr) 홈페이지에서 제공하는 관광정보 중 저작권 등에 구애 없이 자유롭게 활용 가능한 정보만을 선별하여 홈페이지와 동일한 최신정보를 제공한다.
- - 이 API에서 받아온 관광지들을 대상으로 추천을 진행한다.
- 기술 로드맵
시장상황에 대한 분석
- 경쟁제품 조사 비교
- 마케팅 전략 제시
◇ 3C 분석 (Company, Competitor, Customer)
- 이 보고서에서는 ‘자사‘를 정의하지 않고 진행되었기 때문에 Competitor 분석과 Customer 분석만 진행한다.
- Step 01. Competitor 분석
- Competitor 분석은 1.3.가 에서 경쟁제품 조사 비교로 대신한다.
- Competitor 분석은 1.3.가 에서 경쟁제품 조사 비교로 대신한다.
- Step 02. Customer 분석
-
-출처:여행신문 - 현재 사람들은 자유 여행과 패키지 여행, 이렇게 2가지 중 하나의 방식을 선택하여 여행을 한다. 위의 자료를 보면 패키지 여행을 선택하는 이유의 52.46%가 알아서 해준다. 즉, 어디를 여행할지 무엇을 먹을지 여행자가 미리 계획할 필요가 없다는 점이 매우 큰 비중을 차지한다. 대신에, 패키지 여행은 여행사가 정해진 경로대로만 이동을 해야 하므로 여행자의 기호를 반영하는 정확한 여행을 할 수 없다. 또한, 가이드와 여러 사람들이 동행해서 이동해야 하므로 이를 불편하게 여기는 사람들에게는 적합하지 않다.
- 자유 여행을 선택한 이유의 67.54%는 자유롭게 여행하고 싶기 때문이라고 응답하였다. 이는 여행자들이 여행사에서 짜준 일정에 맞춰서 여행하는 것보다 오로지 자신에게 맞는 여행을 하고 싶어한다는 점을 알 수 있다. 그러나, 자유 여행은 본인이 여행의 처음부터 끝까지 다 계획해야 해야 하므로 시간적, 정신적 소모가 크다. 또한, 그 계획이 적절한지 점검해야 하고, 더 나은 대안이 있을 때마다 수정을 해야하는 불편한 점이 있다.
- 우리의 제품은 위 2가지 방식의 장점만을 융합하여 사용자에게 시간적, 정신적 소모도 적으면서 맞춤형으로 여행 계획을 제공해준다는 특징을 적극적으로 어필하는 마케팅 전략을 세운다.
-
◇ STP 분석
- Step 01 Segment : Persona로 시장 세분화 및 타겟 선정하기
- 인구통계학적 구분 : 20~40대, 성별무관, 1인 여행 또는 소규모 여행
- 지리적 구분 : 국내 지역으로 한정
- 심리분석적 구분 : 자유 여행은 하고 싶지만 계획을 세우는 것에 어려움을 느끼는 사람, 정해진 일정에 맞춰 타인과 함께하는 패키지 여행이 불편한 사람
- 인구통계학적 구분 : 20~40대, 성별무관, 1인 여행 또는 소규모 여행
- Step 02 Targeting : User Needs 정의로 목표 시장 고려하기
- Step 03 Positioning
- 첫 번째 기존 여행 포지셔닝을 보면, 편의성이 좋으면 자유도가 떨어지고 자유도가 좋으면 편의성이 떨어지는 경향을 볼 수 있다. 두 번째인 소비자 선호 그림을 보면 편의성과 자유도가 모두 좋은 여행을 원한다는 것을 알 수 있다. 마지막으로 기존 여행 포지셔닝과 소비자 선호의 그림을 합쳐보면 기존의 여행 관련 브랜드와 어떻게 경쟁을 해야하는지 알 수 있다. 패키지 여행을 제공하는 업체들과 경쟁할 때는 자유도를 강조한 마케팅 전략을, 자유여행을 위한 여행지 추천을 해주는 업체들과 경쟁할 때는 여행지 추천 뿐만 아니라 전체적인 일정을 모두 짜주는 편의성을 강조한 마케팅 전략을 채택해야 한다.
개발과제의 기대효과
기술적 기대효과
◇ 정보수집을 위한 검색횟수가 줄어들며 일정계획시 필요한 시간이 단축된다.
◇ 여행장소정보수집, 여행경로확인, 스케쥴링등 여러 앱을 이용해야했던 일정계획이 하나의 앱으로 가능해진다.
경제적, 사회적 기대 및 파급효과
◇ 일정계획에 어려움을 느껴 패키지 여행을 이용하던 사용자가 줄어든다.
◇ 인기있는 몇개의 여행지가 아닌 비교적 지역의 다양한 여행장소를 추천하여 비교적 인기가 없던 여행지가 활성화 된다.
기술개발 일정 및 추진체계
개발 일정
단계별 세부개발 내용 | 담당자 | 개발 기간(월 단위) | 비고 | |||
3 | 4 | 5 | 6 | |||
1. 화면 UI 확정 | 전체 | |||||
2. Tmap API 연결 | 이태현 | |||||
3. Tour API 연결 | 맹유진, 김대양 | |||||
4. 사용자 입력 받기 | 김바다 | |||||
5. 저장 및 불러오기 | 김대양 | |||||
6. 추천 알고리즘 작성 | 맹유진, 김바다 | |||||
7. 일정 편집 기능 | 이태현 |
구성원 및 추진체계
일정 편집 기능 |
Tour API 연결 |
추천 알고리즘 작성 |
추천 알고리즘 작성 |
설계
설계사양
제품의 요구사항
번호 | 요구사항 | D or W | 비고 |
1 | 추천 여행 스케줄을 생성하여야 한다. | D | |
2 | 생성된 스케줄을 사용자에게 시각적으로 보여줘야 한다. | D | |
3 | 종합적인 사용자 정보(여행지역, 여행일자, 여행테마, 식당 취향 등)를 입력받아 추천에 반영해야 한다. | W | |
4 | 여행 스케줄 생성시 5~10초 이상 걸리면 안된다. | D | |
5 | 만들어진 여행 스케줄을 사용자 임의로 편집할 수 있어야 한다. | W |
- 목적 계통도
개념설계안
프로그램 구상
- 사용자의 정보를 받아 적합한 일정을 자동으로 계획한다.
- 계획된 일정은 지도와 일정표를 통해 제공된다.
- 사용자는 계획된 일정을 편집할 수 있다.
- 계획된 일정은 저장되어 불러오기, 삭제가 가능하다.
기능 구상
- 추천 여행지 선택
- 인기순 추천: 해당 지역에서 인기있는 장소들을 추천한다.
- 거리 기반 추천: 출발지와 위치를 비교하여 가까운 거리에 있는 장소들을 우선으로 추천한다.
- 그룹화 후 추천: 장소들을 클러스터링한 후 출발지와 위치를 비교하여 가장 가까운 그룹의 장소들을 추천한다. 요일마다 다른 클러스터의 장소를 추천한다.
- 경로 생성 방법
- 거리 기반 추천: 사용자가 입력한 출발지를 기준으로 거리를 계산해, 가까운 장소부터 먼 장소 순으로 경로를 생성한다.
- 사분할 추천: 출발지를 기준으로 구역을 나눠 한 구역씩 이동하도록 경로를 생성한다.
- TSP 알고리즘: TSP 문제를 풀기 위한 여러 휴리스틱 알고리즘을 이용하여 경로를 생성한다.
- 사용자에게 일정 보여주기
상세설계 내용
S/W 구조 설계
그림1
- 사용자 정보를 바탕으로 TourAPI를 활용하여 사용자맞춤 여행일정과 여행 장소를 추천해준다.
- 추천된 여행일정을 확인할 수 있고 TmapAPI를 활용하여 이동경로와 장소의 위치를 직관적으로 보여준다.
- 로컬저장장소에 추천한 일정을 저장하고 불러올 수 있다.
유즈케이스
- 액터목록
액터 명 | 설명 |
User | 앱을 이용하는 사용자 |
Tour API | 정보 수집을 위한 API |
Tmap API | 경로 시각화를 위한 API |
로컬 저장장치 | 일정 저장위치 |
- 설명
1. User가 코스 생성을 요청한다. 2. 시스템이 User에게 정보(여행일자, 여행지, 테마, 인원, 활동시간, 출발지, 도착지)입력을 요청한다. 3. User는 정보를 기입한뒤 시스템에 보낸다. 4. 시스템은 정보를 받으면 이를 바탕으로 TourAPI에 여행지정보를 요청한다. 5. TourAPI는 시스템에 여행지정보를 전달한다. 6. 시스템은 전달받은 여행지정보를 바탕으로 여행 코스를 생성한다. 7. 시스템은 생성된 코스를 User에게 보여준다. | ||||
1. User가 시스템이 요청한 정보를 전부 입력하지 않으면 시스템은 요청을 거부하고 정보를 다시 입력할것을 요구한다. 2. TourAPI가 반환할 장소 정보가 존재하지 않는다면 시스템은 시스템은 이를 User에게 알린 후 사용자 정보 중 테마정보를 제외한 후 TourAPI에 여행지정보를 요청한다. | ||||
1. User는 코스를 선택해 시스템에 해당 코스를 편집할 것을 요청한다. 2. 시스템은 선택한 코스 정보를 불러와 User에게 제공한다. 3. User는 코스를 편집 해 시스템에 전달한다. 4. 시스템은 편집된 코스를 저장한다. | ||||
코스생성 또는 코스 불러오기 UseCase가 먼저 실행되어야 한다. | ||||
1. User는 시스템에 코스에 포함된 장소중 한 장소를 변경할 것을 요청한다. 2. 시스템은 요청을 받아 TourAPI로 User가 입력한 정보에 맞는 장소들을 찾는다. 3.장소들을 User에게 추천한다. 4.User은 추천 된 장소들 중 하나를 선택한다 5.시스템은 기존에 있던 장소를 삭제하고 선택된 장소로 대체한다. | ||||
코스생성 또는 코스 불러오기 UseCase가 먼저 실행되어야 한다. | ||||
1. User는 시스템에 코스에 새로운 장소를 추가할것을 요청한다. 이때 장소를 추가할 위치가 선택된다. 2.시스템은 요청을 받아 TourAPI로 User가 입력한 정보에 맞는 장소들을 찾는다. 3.장소들을 User에게 추천한다. 4.User는 추천 된 장소들 중 하나를 선택한다. 5. 시스템은 선택된 장소를 추가한다. | ||||
1. TourAPI가 반환할 장소 정보가 존재하지 않는다면 시스템은 시스템은 이를 User에게 알린 후 사용자 정보 중 테마정보를 제외한 후 TourAPI에 여행지정보를 요청한다. | ||||
코스생성 또는 코스 불러오기 UseCase가 먼저 실행되어야 한다. | ||||
1. User는 시스템에 코스에 추천된 장소 중 하나를 삭제할것을 요청한다. 2.시스템은 요청을 받아 코스에서 해당 장소를 삭제한다. | ||||
코스생성 또는 코스 불러오기 UseCase가 먼저 실행되어야 한다. | ||||
1. User가 생성된 코스를 저장할것을 시스템에 요청한다. 2.시스템은 저장 할 코스가 유효한 코스인지 확인한다 3. 유효한 코스라면 시스템은 이를 로컬저장장치에 저장한다. | ||||
1. 코스에 장소정보가 존재하지 않는다면 시스템은 요청을 거부한다. | ||||
코스생성, 코스관리 중 적어도 하나의 UseCase가 먼저 실행되어야 한다. | ||||
1. User는 시스템에 코스에 추천된 장소 중 하나를 삭제할것을 요청한다. 2.시스템은 요청을 받아 코스에서 해당 장소를 삭제한다. | ||||
코스생성 또는 코스 불러오기 UseCase가 먼저 실행되어야 한다. | ||||
1.User가 생성된 코스를 삭제할것을 시스템에 요청한다. 2.시스템은 로컬저장장치에서 코스를 삭제한다. | ||||
코스저장 UseCase가 먼저 실행되어, 저장된 코스가 존재해야 한다. | ||||
1. User가 코스 생성을 요청하면 시스템은 코스를 생성한다. 2.시스템은 생성된 코스의 장소정보를 TmapAPI에 보낸다. 3.TmapAPI는 지도에 전달받은 장소를 마커표시하고 코스의 경로를 User에게 보여준다. | ||||
코스생성 또는 코스불러오기 UseCase가 먼저 실행되어야 한다. | ||||
1. User가 일정목록을 불러올 것을 시스템에 요청한다. 2. 시스템은 이전에 생성된 일정 목록을 로컬저장장치에서 불러온다. 3. User는 확인하고 싶은 일정을 선택한다. 시스템은 선택된 일정의 코스를 User에게 보여준다. | ||||
1. 불러올 일정이 존재하지 않을경우 시스템은 User에게 생성된 일정 없음 메세지를 출력한다. | ||||
코스저장 UseCase가 먼저 실행되어, 저장된 코스가 존재해야 한다. | ||||
UI 정의
화면 목록
화면 ID | 화면명 | 화면 설명 |
UI-001 | 메인화면 | 메인화면 |
UI-002 | 사용자 정보 입력 | 사용자에게 여행일자, 테마, 음식 취향, 예산, 활동시간 등 종합적인 정보를 입력받는 화면 |
UI-003 | 출발지, 도착지 입력 | 사용자에게 각 일별 출발지, 도착지 정보를 입력받는 화면 |
UI-004 | 출발지, 도착지 검색 | UI-003에서 입력할 출발지와 도착지의 목록을 검색을 통해 보여주는 화면 |
UI-005 | 코스 확인 | 생성된 코스를 출력하는 화면 |
UI-006 | 일정 목록 확인 | 생성된 일정 목록을 출력하는 화면 |
화면 흐름도
화면 정의
1. 메인화면(UI-001)
구분 | 항목명 | 항목 속성 | 설명 |
화면 이동 | 일정 계획 버튼 | Link | 사용자 정보 입력(UI-002)으로 이동한다. |
일정 확인 버튼 | Link | 일정 목록 확인(UI-006)으로 이동한다. |
2. 사용자 정보 입력(UI-002)
사용자 정보를 받아온다.
구분 | 항목명 | 항목 속성 | 설명 |
사용자 정보 입력 | 가는 날 | DatePicker Dialog | 여행 시작 일자를 입력받는다. |
오는 날 | DatePicker Dialog | 여행 종료 일자를 입력받는다. | |
활동예산 | EditText | 사용자의 활동 예산을 입력받는다. | |
숙소예산 | EditText | 사용자의 숙소 예산을 입력받는다. | |
음식 취향 | Spinner | 사용자가 선호하는 음식 취향을 입력받는다. | |
테마 | Spinner | 사용자가 선호하는 여행 테마를 입력받는다. | |
인원 | Button | 함께 여행하는 총 인원 수를 입력받는다. | |
활동 시작 시간 | TimePicker Dialog | 하루 일과의 시작 시간을 입력받는다. | |
활동 종료 시간 | TimePicker Dialog | 하루 일과의 종료시간을 입력받는다. | |
화면 이동 | 여행 코스 생성 | Link | UI-003으로 이동한다. |
3. 출발지 도착지 입력(UI-003)
각 여행일자별 출발지와 도착지의 정보를 입력받는다.
구분 | 항목명 | 항목 속성 | 설명 |
출발지 도착지 입력 | n일차 출발지 | TextView | 각 텍스트뷰를 눌러 UI-004로 이동하고, 그 UI에서 받아온 값을 해당 텍스트뷰로 출력한다.
UI-002에서 입력한 날짜를 토대로 일수만큼 동적으로 생성된다. |
n일차 도착지 | TextView | ||
화면이동 | 확인 | Button | UI-005로 이동한다. |
4. 출발지 도착지 검색(UI-004)
Tmap API의 POI 검색을 이용하여 사용자가 원하는 장소를 검색한다.
구분 | 항목명 | 항목 속성 | 설명 |
장소 입력 | 장소 이름 | EditText | 검색할 장소 이름을 입력받는다. |
검색 결과 | 장소 목록 | RecyclerView | 해당 키워드로 Tmap API에 장소검색을 요청해서 받은 결과들을 목록형태로 사용자에게 보여준다.
목록 중에 하나의 장소를 클릭할 경우 UI-003으로 이동하고, 클릭된 장소의 정보를 넘겨준다. |
5. 코스 확인(UI-005)
구분 | 항목명 | 항목 속성 | 설명 |
여행 일정 확인 | 상세 경로 보기 | ImageButton | 여행 경로의 상세 정보를 순서대로 확인한다. |
코스 보기 | Spinner | 여행 일정 중 하나의 날짜를 선택하여 코스 확인한다. | |
일정 저장 여부 | 저장하기 | Button | 추천된 여행 일정을 저장하고 일정 목록 확인(UI-006)으로 이동한다. |
취소하기 | Button | 추천된 여행 일정을 취소하고 메인화면(UI-001)으로 이동한다. | |
장소 표시 | 장소 표시 | TmapMarker | 장소의 위치를 지도에 표시하고, 선택하면 해당 장소의 상세 정보를 팝업으로 띄운다. |
6. 일정 목록 확인(UI-006)
구분 | 항목명 | 항목 속성 | 설명 |
화면 이동 | 홈 | Link | 메인화면(UI-001)으로 이동한다. |
일정 목록 | 여행 일정 확인 | Button | 저장된 여행 일정을 선택하여 확인한다.
일정 하나를 클릭할 경우 코스확인(UI-005)으로 이동한다. |
일정 이름 | Lable | 일정 목록을 확인할 수 있다. | |
일정 삭제 | 삭제 버튼 | Button | 저장된 여행 일정을 삭제한다. |
클래스 다이어그램
시퀀스 다이어그램
결과 및 평가
완료 작품의 소개
프로토타입 사진 혹은 작동 장면
실행(RUN)
1. 메인페이지에서 일정 짜러가기 버튼을 누른다.
2. 여행 조건을 모두 입력한다.(가는 날, 오는 날, 활동 예산, 숙소 예산, 음식 취향, 테마, 인원, 활동 시간)
3. 날짜별로 여행의 출발지 도착지를 입력한다. (숙소 또는 지역 이동을 고려하여 입력한다)
4. 세부적인 여행일정에 대한 정보와 경로를 확인한다
5. 저장된 여행 일정을 확인하며, 여행 일정을 선택하여 해당 일정을 확인, 수정한다.
성과물
- 프로젝트 github 주소
- apk 다운로드 링크
관련사업비 내역서
없음.
완료작품의 평가
평가항목 | 적용기준 | 비중 | 평가결과 |
기능 구현 완전성 | 제안되어 있는 기능들이 모두 구현되어 있는지 여부를 평가한다. | 10 | 활동 시간, 예산, 인원을 고려한 여행 일정을 만드는 기능은 아직 구현하지 못하였다. |
기능 구현 정확성 | 구현된 모든 기능들이 정상적으로 동작하는지 여부를 평가한다. | 30 | 구현된 모든 기능은 문제없이 동작한다. |
상호 운용성 | TourAPI와 Tmap API와의 연동(데이터 교환, 인터페이스 요구 충족 등) 가능 여부를 평가한다. | 10 | Tmap API, Tour API 와의 데이터 통신이 원활히 동작한다. |
기능학습 용이성 | 도움말, 매뉴얼 등을 통해 제품 기능 정보를 제공하여 학습이 용이한지 여부를 평가한다. | 10 | 사용 안내 동영상은 있지만, 프로그램 내에 도움말, 매뉴얼은 현재 만들지 않았다. |
입출력데이터 이해도 | 데이터 입출력 방법 및 절차가 편리하고 요구내용에 적합한지 여부를 평가한다. | 10 | 사용자가 데이터를 입력할 때, 날짜, 여행 테마 등을 선택하거나 숫자를 입력만으로 모든 절차가 마무리된다. |
UI 일관성 | 일관된 인터페이스를 제공하는지 여부를 평가한다. | 10 | 사용자로부터 여행 조건을 입력 받을 때, 일관된 인터페이스를 제공하며, 여행별, 날짜별 경로를 확인할 때도 일관된 인터페이스를 제공한다 |
운영환경 적합성 | 모바일 환경(IOS, Android)에 설치 가능한지 여부를 평가한다. | 10 | 안드로이드에서의 작업은 마쳐서 설치가 가능하지만, iOS는 아직 완료되지 않았다 |
반응 시간 | 시스템 반응시간이 2초 이내인지 평가한다. | 10 | 대부분은 제안요청서의 기준인 2초 이내에 정상 작동한다. 그러나 일정 생성 시에는 2초보다 시간이 더 걸려 속도개선이 필요하다. |
향후계획
1.어려웠던 내용들
- ◇ git-flow를 이용하여 버전관리를 처음 해보았고, 이로 인해 잘못 push된 걸 되돌려야 했던 경우가 있었다.
- ◇ MVP패턴을 적용하여 구현함에 있어, 처음 써보는 패턴이라 적응에 애를 먹었다.
- ◇ API와의 http통신이나 추천 알고리즘 호출시, 시간적 문제로 인해 스레드로 빼내어 구현하였는데 이때 메인 스레드와의 동기화 문제를 해결하는데 어려움이 있었다.
- ◇ 클러스터링을 적용하기 이전에, 추천 알고리즘을 구상하고 구현함에 있어서 시간복잡도가 너무 커서 이를 해결하는데 애를 먹었다. 클러스터링을 적용함으로써 해결했다.
2.차후 구현할 내용
- ◇ 입력받았지만 아직 사용하지 않는 정보들을 활용하여, TourAPI로부터 받아온 정보들에 대한 필터링 추가
- ◇ 클러스터링이 완료된 정보들에 대해서, TSP 문제의 휴리스틱한 해결 방법을 적용하여 최적화된 경로 추천
- ◇ 이미 저장된 일정들에 대해 필요에 따라 이미 저장된 정보들을 수정할 수 있게 변경
- ◇ 자체 데이터베이스를 구축하여, 사용자들로부터 관광지에 대한 만족도를 평가받아 추천에 반영하도록 변경
- ◇ 자체 데이터베이스를 구축하거나, 다른 데이터를 더 수집해서 추천 대상이 되는 관광지의 종류 추가
- ◇ tsp로 장소들의 순서를 정한 이후에 식당이 추천됨으로 인해 경로가 완전히 깔끔하게 보이지 않는 경향이 있다.