"김진호와아이들"의 두 판 사이의 차이
(→개발 과제 요약) |
(→유스케이스 설계) |
||
(같은 사용자의 중간 판 48개는 보이지 않습니다) | |||
38번째 줄: | 38번째 줄: | ||
◇ 특정 부대시설의 위치 정보를 제공한다. | ◇ 특정 부대시설의 위치 정보를 제공한다. | ||
− | ====개발 과제의 배경==== | + | ====개발 과제의 배경 및 효과==== |
− | + | ||
+ | ◇ 교내 정보를 아예 찾을 수가 없다. | ||
+ | |||
+ | ◇ 교내 정보의 양이 너무 많아서 나에게 필요한 정보만을 얻기가 힘들다. | ||
+ | |||
+ | ◇ 교내 정보가 어디에 있는지 알기 힘들어서 찾기가 힘들다. | ||
+ | |||
+ | ◇ 자신에게 필요한 공지사항 정보를 얻기 위해서 매일 홈페이지에 접속해야 하는 게 번거롭다. | ||
+ | |||
+ | ◇ 지인을 통해 정보를 얻는 과정에서 시간이 많이 소요된다. | ||
+ | |||
+ | ◇ 교내 정보를 얻기 위해서 많은 경로를 거쳐야 한다. | ||
+ | |||
+ | ◇ 학교 정보를 제공하는 매체들이 학교에 대한 모든 정보를 다 제공해주지 않는다. | ||
+ | |||
+ | ◇ 시설에 대한 정보를 한 곳에서 모아볼 수 있는 서비스가 없다. | ||
+ | |||
+ | ◇ 자신이 찾고자 하는 정보가 존재하는지 알 수 없다. | ||
+ | |||
+ | ◇ 사용자는 학교 정보를 한 곳에서 볼 수 있다. | ||
+ | |||
+ | ◇ 사용자는 맞춤 공지사항 알림 서비스를 제공받을 수 있다. | ||
+ | |||
+ | ◇ 사용자는 정보에 접근하기 위한 과정을 줄일 수 있다. | ||
+ | |||
+ | ◇ 사용자는 건물 사진을 찍으면 건물에 대한 정보를 제공받을 수 있다. | ||
+ | |||
+ | ◇ 사용자는 학교 홈페이지에 있는 공지사항 및 교내 시설 정보를 모두 제공받을 수 있다. | ||
+ | |||
====개발 과제의 목표 및 내용==== | ====개발 과제의 목표 및 내용==== | ||
− | + | ||
+ | ◇ 학교 정보를 한 곳에서 볼 수 있게 한다. | ||
+ | |||
+ | ◇ 사용자 맞춤 공지사항 알림 서비스를 제공한다. | ||
+ | |||
+ | ◇ 정보에 접근하기 위한 과정을 줄인다. | ||
+ | |||
+ | ◇ 건물 사진을 찍으면 건물에 대한 정보를 제공한다. | ||
+ | |||
+ | ◇ 학교 홈페이지에 있는 공지사항 및 교내 시설 정보를 전부 가져온다. | ||
===관련 기술의 현황=== | ===관련 기술의 현황=== | ||
====관련 기술의 현황 및 분석(State of art)==== | ====관련 기술의 현황 및 분석(State of art)==== | ||
*전 세계적인 기술현황 | *전 세계적인 기술현황 | ||
− | + | ||
− | * | + | ◇ 크로스플랫폼 앱 프레임워크 |
− | + | ||
+ | 크로스플랫폼 개발은 하나의 프로그래밍 언어로 여러 OS에서 작동할 수 있는 앱을 만드는 것을 말한 다. 2022년 4월 기준 IOS와 Android의 모바일 OS 시장점유율은 99퍼센트 이상이기 때문에 모바일 생태계에서의 크로스플랫폼 개발은 IOS와 Android, 이 두개의 OS에서 잘 작동하는 앱을 만드는 것을 말한다. 클로스플랫폼 프레임워크들 중 현재 native 앱과 성능이 가장 비슷하고, 시장점유율이 높은 프레임워크는 React native와 Flutter이다. | ||
+ | |||
+ | ▶ React Native | ||
+ | |||
+ | - 구조 | ||
+ | |||
+ | - Javascript thread와 UI thread | ||
+ | |||
+ | UI thread는 main thread로 동작하며 event가 발생할 경우 bridge를 통해 Javascript thread에 event를 전달, Javascript thread는 event를 처리하고 변경되는 visual update내용이 있다면 이를 bridge를 통해 UI thread로 전달한다. | ||
+ | |||
+ | ▶ Flutter | ||
+ | |||
+ | - 구조 | ||
+ | |||
+ | - UI thread와 GPU thread | ||
+ | |||
+ | Flutter는 컴파일 시 native code로 변환된다. Flutter앱이 실행되면 UI thread는 Layer tree를 생성 후 GPU thread로 하여금 렌더링하게 한다. | ||
+ | |||
+ | |||
+ | ◇ 건물 인식 기법 | ||
+ | |||
+ | ▶ 이미지 잡음에 강인한 CNN 기반 건물 인식 방법 | ||
+ | |||
+ | - CNN 모델 사용 | ||
+ | |||
+ | - 건물의 특성을 가장 잘 나타내는 부분 이미지로 데이터셋 구성 | ||
+ | |||
+ | - 가로등, 사람, 날씨 등 외부 환경이 변해도 건물의 특징점으로 건물 인식 용이 | ||
+ | |||
+ | - 건물 전체 이미지로 학습한 모델의 정확도는 70.9%, 부분 이미지 데이터셋 사용 시 84.6% | ||
+ | |||
+ | ▶ 건물 특성 정보를 이용한 딥러닝 기반 건물 인식 강화 방법에 관한 연구 | ||
+ | |||
+ | - CNN 모델 사용 | ||
+ | |||
+ | - 건물의 외장재로 데이터셋 구성 | ||
+ | |||
+ | - 건물을 촬용한 거리가 멀어져도 평균 인식률이 98% | ||
+ | |||
+ | |||
+ | ◇ Yolov5 | ||
+ | |||
+ | YOLO는 객체 인식 알고리즘으로, ‘You only look once’의 약자이다. YOLO는 빠른 속도와 높은 정확도로 객체 인식 알고리즘 중에서 가장 인기 있는 알고리즘이다. | ||
+ | |||
+ | |||
+ | YOLO는 2016년 ‘You Only Look Once: Unified, Real-Time Object Detection’라는 논문으로 처음 세상에 소개된다. 논문에 따르면, YOLO가 등장하기 이전에 존재했던 객체 인식 알고리즘인 DPM 및 R-CNN은 classifier를 객체 인식에 맞게 재구성한 알고리즘이다. 그와 다르게, YOLO는 객체 인식을 regression 문제로 프레임화 한다. 이 덕분에 복잡한 파이프라인을 구축할 필요가 없다. 추가적으로, YOLO는 single network evaluation으로 inference를 할 수 있기 때문에 다른 classifier-based method보다 빠르며, 초당 45개의 프레임을 처리할 수 있다. 또한 다른 리얼타임 시스템과 비교했을 때 mean average precision(mAP)가 2배 이상 높다. | ||
+ | |||
+ | |||
+ | YOLO는 분리되어 있는 객체 인식의 컴포넌트들을 single neural network로 결합했다. YOLO의 network는 전체 이미지의 feature로 각각의 bounding box를 예측하며, 모든 class에 대한 bounding box를 동시에 예측한다. 이러한 YOLO의 시스템은 인풋 이미지를 S x S grid로 나누고, 각 grid는 B개의 bounding box와 1개의 class를 에측한다. YOLO의 이러한 특성 때문에 YOLO는 매우 작은 객체들이 적은 개수의 grid에 포함되어 있을 때 예측에 어려움을 겪는다. | ||
+ | |||
+ | |||
+ | (YOLO 네트워크 구조 | ||
+ | 출처: Redmon, Joseph, et al. "You only look once: Unified, real-time object detection." Proceedings of the IEEE conference on computer vision and pattern recognition. 2016. p3.) | ||
+ | |||
+ | (다른 Real-Time System과의 비교 | ||
+ | 출처: Redmon, Joseph, et al. "You only look once: Unified, real-time object detection." Proceedings of the IEEE conference on computer vision and pattern recognition. 2016. p6) | ||
+ | |||
+ | (R-CNN vs YOLO | ||
+ | 출처: Redmon, Joseph, et al. "You only look once: Unified, real-time object detection." Proceedings of the IEEE conference on computer vision and pattern recognition. 2016. p6) | ||
+ | |||
+ | |||
+ | 우리는 ‘이미지 잡음에 강인한 CNN 기반 건물 인식 방법’이라는 논문을 참고해서, 장애물이 건물을 가리더라도 건물을 인식할 수 있게 하기 위해서 건물의 특징점을 담고 있는 부분 이미지를 활용한 객체 인식 알고리즘으로 건물 인식 모델을 구현하고자 한다. 또한, 부분 이미지로 모델을 학습하기 위해서 하나의 이미지로부터 많은 양의 부분 이미지를 추출해야 하므로, 알고리즘의 처리 속도가 중요하다. 더불어 건물의 특징점들은 보통 크기가 작지 않고 작은 grid에 밀집해있을 가능성이 적으므로, 작은 객체들이 가깝게 모여있을 때 인식에 어려움을 겪는 YOLO의 한계가 부분 이미지로 건물을 인식하는 과정에서는 부정적으로 작용하지 않을 것이라고 판단했다. 따라서 ‘어디시립’의 건물 인식 알고리즘으로 YOLO를 선택하고자 한다. | ||
+ | |||
+ | |||
+ | ◇ Message Queue | ||
+ | |||
+ | ▶ kafka | ||
+ | |||
+ | - Kafka는 이벤트 기반의 메시지큐시스템으로, 메시지를 만드는 producer와 메시지를 사용하는 Consumer의 형태를 가지고있다. Kafka는 다른 메시지 큐와 다르게 높은 처리량과 실시간에 가가운 처리 능력을 가지고 있으며, 생산된 메시지를 잃어버리지 않도록 디스크에 log 형식으로 영속화를 한다. 또한, Topic과 partition을 통해 높은 확장성을 가지고 있다. | ||
+ | |||
+ | - Open source message queue는 Apache Kafka, Rabbit MQ 등 다양한 메시지큐 시스템이 있다. 각자 추구하는 방향이 다르기 때문에 어떤 기술이 최고라고 얘기할 수 없다. 그러나, 우리가 사용하려고하는 Kafka는 현재 LINE이나 LinkedIn 같은 대규모 기업에서도 활발히 사용하고 있다. | ||
+ | |||
+ | |||
+ | ◇ 크롤링 | ||
+ | |||
+ | - 크롤링은 웹 페이지의 HTML 파일을 가져와서 원하는 데이터만 추출하는 기법이다. 대표적으로 Python과 Node를 이용해서 크롤링을 할 수 있다. 현재 파이썬에 존재하는 크롤링 관련 라이브러리는 BeautifulSoup과 Selenium이 있다. | ||
+ | |||
+ | - BeautifulSoup: HTML을 파싱해서 원하는 데이터를 추출하는 방식이다. | ||
+ | |||
+ | - Selenium: 로그인이 필요하거나, CSR과 같은 Client에서 먼저 빈 HTML을 받고, JS를 통해 렌더링 되는 사이트에서 BeautifulSoup로만 해결할 수 없기 때문에, Selenium을 통해 Web Driver를 이용 하여 직접 browser를 조작하는 방식으로 해결한다. | ||
+ | |||
+ | |||
+ | ◇ 관계형 데이터베이스 | ||
+ | |||
+ | - 관계형 데이터베이스는 키(Key)와 값(Value)들의 간단한 관계를 테이블화 시킨 데이터베이스이다. 트랜잭션을 보장하기 위해 원자성, 독립성, 지속성의 기능을 제공하여 데이터의 무결성, 완전성, 정확성을 보장한다. 또한 SQL을 사용하여 데이터에 접근하며 여러 OS에서 사용이 가능하다. 현재 가장 많이 사용하는 RDBMS에는 Oracle과 MySQL이 있다. | ||
+ | |||
+ | - Oracle: 1979년 오라클사에서 만든 유로 상업용 DB이다. 대규모 데이터베이스를 지원하기 때문에 대량의 정보관리를 할 때에 가장 좋은 성능을 보인다. 또한 다른 데이터베이스보다 고성능의 트랜잭 션을 지원한다. | ||
+ | |||
+ | - MySQL: 세계에서 가장 많이 쓰이는 오픈 소스의 관계형 데이터베이스이다. 프로시저를 통한 데이 터 레코드 삽입, 삭제와 같은 단계를 하나로 묶어서 사용할 수 있으며 트리거도 존재한다. 5천건 이 하의 데이터를 다루는데 적합한다. | ||
+ | |||
+ | |||
+ | ◇ 스프링부트 | ||
+ | |||
+ | - 기존 자바 기반의 애플리케이션 프레임워크인 스프링은 DI, IoC 등의 특징을 가지고 있다. 하지만 개발 환경 설정에 어려움이 있었고 이를 보완하기 위해 스프링부트가 만들어지게 되었다. 내장 서버를 갖추고 있어 독립 실행이 가능하며 Spring Initializr의 지원을 통해 설정을 단순화 하였다. 또한 스타터를 통해 자동화된 스프링 설정을 제공함으로써 간단한 설정으로 빠른 실행이 가능하게 되었다. | ||
+ | |||
+ | |||
+ | *특허 조사 | ||
+ | |||
+ | ◇ 멀티 프레임 기반 건물 인식을 위한 특징점 분류 방법(A classification method of feature points required for multi-frame based building recognition) 등록특허 10-1741761 | ||
+ | |||
+ | - 한 장 이상의 멀티 프레임을 이용하여 건물 인식에 필요한 특징점을 분류하는 멀티 프레임 기반 건물 인식을 위한 특징점 분류 방법에 관한 것으로서, (a) 상기 멀티프레임 영상의 각 영상에서 특징점을 추출하는 단계; (b) 추출된 특징점들을 대상으로, 각 영상 간에 정합을 수행하여, 정합된 특징점 쌍을 획득하는 단계; (c) 다수의 특징점 쌍들로부터 호모그래피 행렬을 획득하고, 획득된 호모그래피 행렬을 이용하여 특징점을 분류하는 단계; 및, (d) 분류되고 남은 특징점들을 이용하여 상기 (c)단계를 반복하는 단계를 포함하는 구성을 마련한다. | ||
+ | |||
+ | |||
+ | ◇ 웹 크롤링 시스템 및 그 방법(System for web crawling and Method thereof) 공개특허 10-2010-0094263 | ||
+ | |||
+ | - 본 발명은 웹 크롤링에 소요되는 시간을 획기적으로 단축시킬 수 있는 웹 크롤링 시스템에 관한 것이다. 본 명세서에서 개시하는 웹 크롤링 시스템은 웹 크롤링을 위한 기준 웹 페이지들(시드 페이지들(seed pages))을 설정하고, 웹 크롤링을 통해 발견되는(Discovered) 상기 시드 페이지들의 각 시드 페이지(pi)에의 접근 확률(중요도)을 산출하여 상기 각 시드 페이지(pi)에 우선순위를 부여하는 시드 페이지 우선순위 부여부; 상기 부여된 각 시드 페이지(pi)의 우선순위 중 가장 높은 순위를 갖는 시드 페이지(pi,max)를 추출하여 우선적으로 다운로드하되, 상기 시드 페이지(pi,max)에 링크된 외부링크(outlink) 페이지들도 일괄적으로 다운로드하는 다운로드부; 및 상기 다운로드된 외부링크 페이지들의 각 링크 페이지(pj)에 대한 상기 시드 페이지(pi,max)내에서의 접근 확률(중요도)을 산출하여, 상기 각 링크 페이지(pj)에 우선순위를 부여하는 외부링크 페이지 우선순위 여부를 포함하여 본 시스템 발명의 과제를 해결한다. | ||
+ | |||
+ | |||
+ | *특허 전략 | ||
+ | |||
+ | ◇ 건물인식에 중요한 건물 특징들을 자동으로 추출할 수 있는 방법을 제시한다. | ||
+ | |||
+ | |||
*기술 로드맵 | *기술 로드맵 | ||
내용 | 내용 | ||
54번째 줄: | 204번째 줄: | ||
====시장상황에 대한 분석==== | ====시장상황에 대한 분석==== | ||
*경쟁제품 조사 비교 | *경쟁제품 조사 비교 | ||
− | + | ||
+ | ◇ 시대생 | ||
+ | |||
+ | ● 사용자 분석 | ||
+ | |||
+ | - 유저 수 6,000명 이상 | ||
+ | |||
+ | - 서울시립대학교 학생 인증 후 사용 가능 | ||
+ | |||
+ | - 포탈 계정 인증을 통한 인증 | ||
+ | |||
+ | - 학생증 인식을 통한 인증 | ||
+ | |||
+ | ● 주요 기능 | ||
+ | |||
+ | - 커뮤니티 기능 | ||
+ | |||
+ | - 보틀 기능 (유저들 사이의 랜덤 채팅) | ||
+ | |||
+ | - 에듀클래스 공지 등록 알림 기능 (현재는 에듀클래스 서비스 종료로 인해 중단) | ||
+ | |||
+ | - 공지사항 등록 알림 기능 (일반공지, 학사공지, 직원채용, 창업공지) | ||
+ | |||
+ | - 유저 의견을 수렴하여 학생자치기구에 의견 전달하는 기능 | ||
+ | |||
+ | - 학식 정보 제공 기능 | ||
+ | |||
+ | ● 장점 | ||
+ | |||
+ | - 사용자에게 공지사항 알림을 제공해서 홈페이지에 직접 접속하지 않고도 알림을 받아올 수 있게 해줌 | ||
+ | |||
+ | ● 한계 | ||
+ | |||
+ | - 주 기능이었던 에듀클래스 알림 서비스를 더이상 사용할 수 없게 되었음 | ||
+ | |||
+ | - 교내 여러 공지사항들 중 일반공지, 학사공지, 직원채용, 창업공지에 대한 정보만 제공 | ||
+ | |||
+ | - 공지사항 알림에 지연이 있어 선착순 이벤트 등 시간이 중요한 공지 전달에 적합하지 않음 | ||
+ | |||
+ | |||
+ | ◇ 패스파인더 | ||
+ | |||
+ | ● 사용자 분석 | ||
+ | |||
+ | - 부산대학교 학생들 | ||
+ | |||
+ | ● 주요 기능 | ||
+ | |||
+ | - 카메라 어플을 통해 건물을 비추면 건물을 인식하는 기능 | ||
+ | |||
+ | - 로그인 시, 에브리타임 시간표 크롤링하는 기능 | ||
+ | |||
+ | - 건물 인식 시, 사용자가 듣는 수업 정보를 가져오는 기능 | ||
+ | |||
+ | - 로드뷰 API를 통해 건물 데이터를 수집하는 기능 | ||
+ | |||
+ | ● 장점 | ||
+ | |||
+ | - 사진을 찍지 않고 건물이 카메라 앵글에 들어오기만 해도 건물을 인식함 | ||
+ | |||
+ | - 에브리타임 아이디를 이용해 사용자가 듣는 수업만을 제공하기 때문에, 더욱 사용자 맞춤형 정보를 제공함 | ||
+ | |||
+ | ● 한계점 | ||
+ | |||
+ | - 따로 DB를 구상하지 않고, 기계 내의 데이터베이스를 구현했기 때문에 추후 확장성을 고려하기 힘듦 | ||
+ | |||
+ | - 로그인할 때마다 에브리타임 시간표를 크롤링 함. 특정 어플에 종속적이고 비효율적인 로직으로 보임 | ||
+ | |||
+ | - 촬영한 건물에서 이번학기에 듣는 수업의 종류만 알려주기 떄문에 학기 초 빼고는 사용할 이유가 없음 | ||
+ | |||
+ | |||
*마케팅 전략 제시 | *마케팅 전략 제시 | ||
− | |||
===개발과제의 기대효과=== | ===개발과제의 기대효과=== | ||
====기술적 기대효과==== | ====기술적 기대효과==== | ||
− | + | ||
+ | ◇ 기존 교내 건물에 대한 정보를 얻기 위해 걸렸던 과정을 단축시킨다. | ||
+ | |||
+ | ◇ 기존 새로운 공지사항을 확인하기 위해 쓰였던 시간을 단축시킨다. | ||
+ | |||
====경제적, 사회적 기대 및 파급효과==== | ====경제적, 사회적 기대 및 파급효과==== | ||
− | + | ||
+ | ◇ 공지사항을 빠르게 얻을 수 있기 때문에 선착순, 기한이 정해진 이벤트 참여율이 높아진다. | ||
+ | |||
+ | ◇ 학생들이 흩어져있는 공지사항을 한 곳에서 볼 수 있게 되면서 학생들에게 편의성을 제공한다. | ||
+ | |||
+ | ◇ 원하는 공지사항의 알림만을 받을 수 있게 해서 불필요한 웹사이트 접속 시간을 줄이는 경제적인 이점을 제공한다. | ||
===기술개발 일정 및 추진체계=== | ===기술개발 일정 및 추진체계=== | ||
====개발 일정==== | ====개발 일정==== | ||
− | + | ||
+ | [[파일:team1road.png]] | ||
+ | |||
====구성원 및 추진체계==== | ====구성원 및 추진체계==== | ||
− | + | ||
+ | [[파일:team1rntjddnjs.png|{10}px]] | ||
==설계== | ==설계== | ||
===설계사양=== | ===설계사양=== | ||
====제품의 요구사항==== | ====제품의 요구사항==== | ||
− | + | ||
+ | [[파일:team1tkdydwkdyrntkgkd.png]] | ||
+ | |||
====설계 사양==== | ====설계 사양==== | ||
− | + | ||
+ | [[파일:team1thvmxmdnpdjtjfrP.png]] | ||
+ | |||
+ | ◇ 클라이언트가 촬영한 사진은 FastAPI 서버에서 처리된다. | ||
+ | |||
+ | ◇ 클라이언트가 촬영한 사진은 AWS S3에 저장한다. | ||
+ | |||
+ | ◇ 공지사항 정보는 스프링부트 서버에서 처리한다. | ||
+ | |||
+ | ◇ 스프링부트는 카프카 서버에 공지사항이 등록되면 이를 가져와 사용자들에게 알림을 전송한다 | ||
+ | |||
+ | ◇ FastAPI와 스프링부트 서버는 AWS RDS를 공유한다. | ||
===개념설계안=== | ===개념설계안=== | ||
− | |||
− | === | + | ◇ 건물 인식 |
− | + | ||
+ | '''후보군을 좁히는 방법''' | ||
+ | |||
+ | - 사용자가 사진을 찍는 위치를 받아 반경 몇m내의 건물들을 후보군에 포함한다. | ||
+ | |||
+ | - 후보군내의 건물들에 대해 이미지 모델을 돌려 결과를 반환한다. | ||
+ | |||
+ | '''후보군을 좁히지 않고 진행하는 방법''' | ||
+ | |||
+ | - 사용자가 사진을 찍은 이미지를 이미지 모델을 돌려 결과를 반환한다. | ||
+ | |||
+ | |||
+ | ◇ 공지사항 알람 | ||
+ | |||
+ | '''학교에서 지정한 키워드를 이용하는 방법''' | ||
+ | |||
+ | - 학교 공지사항에 지정된 해시태그를 키워드로 선정하여 키워드 목록 중 사용자가 원하는 키워드를 선택하도록 한다. | ||
+ | |||
+ | - 선택된 키워드가 포함된 공지사항만 푸시 알람으로 제공한다. | ||
+ | |||
+ | '''사용자가 지정한 키워드를 이용하는 방법''' | ||
+ | |||
+ | - 사용자가 키워드를 지정하고 지정한 키워드가 포함된 공지사항만 푸시 알람으로 제공한다. | ||
+ | |||
+ | ===유스케이스 설계=== | ||
+ | |||
+ | ====유스케이스 그림==== | ||
+ | |||
+ | [[파일:1whdbtmzpdltmrmfla.png]] | ||
+ | |||
+ | ====유스케이스 시나리오==== | ||
+ | |||
+ | [[파일:1whdbtmzpdltmtlskfldh1.png]] | ||
+ | |||
+ | [[파일:1whdbtmzpdltmtlskfldh2.png]] | ||
+ | |||
+ | ===데이터베이스 설계=== | ||
+ | |||
+ | ====ERD==== | ||
+ | |||
+ | [[파일:1wherd.png]] | ||
+ | |||
+ | ====테이블 및 칼럼==== | ||
+ | |||
+ | [[파일:1whepdlxjqpdltm1.png]] | ||
+ | |||
+ | [[파일:1whxpdlqmf2.png]] | ||
+ | |||
+ | [[파일:1whxpdlqfm3.png]] | ||
− | + | [[파일:1whxpdlqmf4.png]] | |
− | |||
==결과 및 평가== | ==결과 및 평가== | ||
===완료 작품의 소개=== | ===완료 작품의 소개=== | ||
====프로토타입 사진 혹은 작동 장면==== | ====프로토타입 사진 혹은 작동 장면==== | ||
− | + | ||
− | + | [[파일:team1prototype1.png]] | |
− | + | [[파일:team1prototype2.png]] | |
+ | |||
+ | [[파일:team1prototype3.png]] | ||
+ | [[파일:team1prototype4.png]] | ||
===관련사업비 내역서=== | ===관련사업비 내역서=== | ||
− | + | ||
+ | [[파일:1whroqkftkdjqql.png]] | ||
===완료작품의 평가=== | ===완료작품의 평가=== | ||
− | + | ||
+ | [[파일:1 eval 2.PNG]] | ||
===향후계획=== | ===향후계획=== | ||
− | |||
− | + | ◇ 앱 설정 페이지 구현 | |
− | + | ||
+ | ◇ 건물 이미지 데이터 추가 | ||
+ | |||
+ | ◇ 부서에 대한 호수나 위치 데이터 추가 | ||
+ | |||
+ | ◇ 인식 가능한 건물 추가 | ||
+ | |||
+ | ◇ 배포 프로세스 구축 | ||
+ | |||
+ | ◇ 서버 비용 문제 해결 | ||
+ | |||
+ | ◇ 학교 홈페이지로 부터 교내 시설 정보 가져오기 |
2022년 6월 20일 (월) 23:22 기준 최신판
프로젝트 개요
기술개발 과제
국문 : 00000000..
영문 : 00000000..
과제 팀명
김진호와 아이들
지도교수
정형구 교수님
개발기간
2022년 3월 ~ 2022년 6월 (총 4개월)
구성원 소개
서울시립대학교 컴퓨터과학부 2017920018 김진호(팀장)
서울시립대학교 컴퓨터과학부 2017920044 이관희
서울시립대학교 컴퓨터과학부 2017920052 이필세
서울시립대학교 컴퓨터과학부 2017920062 차현철
서론
개발 과제의 개요
개발 과제 요약
◇ 서울시립대학교 학생을 위한 건물 및 시설 정보, 공지사항을 제공하는 애플리케이션이다.
◇ 건물 사진을 찍으면 건물 사진 인식 모델을 통해 건물을 인식하고 건물 내 부대시설 정보를 제공한다.
◇ 학교, 학과, 시설 공지사항을 모두 통합하여 본인이 설정한 키워드에 맞게 알림을 준다.
◇ 특정 부대시설의 위치 정보를 제공한다.
개발 과제의 배경 및 효과
◇ 교내 정보를 아예 찾을 수가 없다.
◇ 교내 정보의 양이 너무 많아서 나에게 필요한 정보만을 얻기가 힘들다.
◇ 교내 정보가 어디에 있는지 알기 힘들어서 찾기가 힘들다.
◇ 자신에게 필요한 공지사항 정보를 얻기 위해서 매일 홈페이지에 접속해야 하는 게 번거롭다.
◇ 지인을 통해 정보를 얻는 과정에서 시간이 많이 소요된다.
◇ 교내 정보를 얻기 위해서 많은 경로를 거쳐야 한다.
◇ 학교 정보를 제공하는 매체들이 학교에 대한 모든 정보를 다 제공해주지 않는다.
◇ 시설에 대한 정보를 한 곳에서 모아볼 수 있는 서비스가 없다.
◇ 자신이 찾고자 하는 정보가 존재하는지 알 수 없다.
◇ 사용자는 학교 정보를 한 곳에서 볼 수 있다.
◇ 사용자는 맞춤 공지사항 알림 서비스를 제공받을 수 있다.
◇ 사용자는 정보에 접근하기 위한 과정을 줄일 수 있다.
◇ 사용자는 건물 사진을 찍으면 건물에 대한 정보를 제공받을 수 있다.
◇ 사용자는 학교 홈페이지에 있는 공지사항 및 교내 시설 정보를 모두 제공받을 수 있다.
개발 과제의 목표 및 내용
◇ 학교 정보를 한 곳에서 볼 수 있게 한다.
◇ 사용자 맞춤 공지사항 알림 서비스를 제공한다.
◇ 정보에 접근하기 위한 과정을 줄인다.
◇ 건물 사진을 찍으면 건물에 대한 정보를 제공한다.
◇ 학교 홈페이지에 있는 공지사항 및 교내 시설 정보를 전부 가져온다.
관련 기술의 현황
관련 기술의 현황 및 분석(State of art)
- 전 세계적인 기술현황
◇ 크로스플랫폼 앱 프레임워크
크로스플랫폼 개발은 하나의 프로그래밍 언어로 여러 OS에서 작동할 수 있는 앱을 만드는 것을 말한 다. 2022년 4월 기준 IOS와 Android의 모바일 OS 시장점유율은 99퍼센트 이상이기 때문에 모바일 생태계에서의 크로스플랫폼 개발은 IOS와 Android, 이 두개의 OS에서 잘 작동하는 앱을 만드는 것을 말한다. 클로스플랫폼 프레임워크들 중 현재 native 앱과 성능이 가장 비슷하고, 시장점유율이 높은 프레임워크는 React native와 Flutter이다.
▶ React Native
- 구조
- Javascript thread와 UI thread
UI thread는 main thread로 동작하며 event가 발생할 경우 bridge를 통해 Javascript thread에 event를 전달, Javascript thread는 event를 처리하고 변경되는 visual update내용이 있다면 이를 bridge를 통해 UI thread로 전달한다.
▶ Flutter
- 구조
- UI thread와 GPU thread
Flutter는 컴파일 시 native code로 변환된다. Flutter앱이 실행되면 UI thread는 Layer tree를 생성 후 GPU thread로 하여금 렌더링하게 한다.
◇ 건물 인식 기법
▶ 이미지 잡음에 강인한 CNN 기반 건물 인식 방법
- CNN 모델 사용
- 건물의 특성을 가장 잘 나타내는 부분 이미지로 데이터셋 구성
- 가로등, 사람, 날씨 등 외부 환경이 변해도 건물의 특징점으로 건물 인식 용이
- 건물 전체 이미지로 학습한 모델의 정확도는 70.9%, 부분 이미지 데이터셋 사용 시 84.6%
▶ 건물 특성 정보를 이용한 딥러닝 기반 건물 인식 강화 방법에 관한 연구
- CNN 모델 사용
- 건물의 외장재로 데이터셋 구성
- 건물을 촬용한 거리가 멀어져도 평균 인식률이 98%
◇ Yolov5
YOLO는 객체 인식 알고리즘으로, ‘You only look once’의 약자이다. YOLO는 빠른 속도와 높은 정확도로 객체 인식 알고리즘 중에서 가장 인기 있는 알고리즘이다.
YOLO는 2016년 ‘You Only Look Once: Unified, Real-Time Object Detection’라는 논문으로 처음 세상에 소개된다. 논문에 따르면, YOLO가 등장하기 이전에 존재했던 객체 인식 알고리즘인 DPM 및 R-CNN은 classifier를 객체 인식에 맞게 재구성한 알고리즘이다. 그와 다르게, YOLO는 객체 인식을 regression 문제로 프레임화 한다. 이 덕분에 복잡한 파이프라인을 구축할 필요가 없다. 추가적으로, YOLO는 single network evaluation으로 inference를 할 수 있기 때문에 다른 classifier-based method보다 빠르며, 초당 45개의 프레임을 처리할 수 있다. 또한 다른 리얼타임 시스템과 비교했을 때 mean average precision(mAP)가 2배 이상 높다.
YOLO는 분리되어 있는 객체 인식의 컴포넌트들을 single neural network로 결합했다. YOLO의 network는 전체 이미지의 feature로 각각의 bounding box를 예측하며, 모든 class에 대한 bounding box를 동시에 예측한다. 이러한 YOLO의 시스템은 인풋 이미지를 S x S grid로 나누고, 각 grid는 B개의 bounding box와 1개의 class를 에측한다. YOLO의 이러한 특성 때문에 YOLO는 매우 작은 객체들이 적은 개수의 grid에 포함되어 있을 때 예측에 어려움을 겪는다.
(YOLO 네트워크 구조
출처: Redmon, Joseph, et al. "You only look once: Unified, real-time object detection." Proceedings of the IEEE conference on computer vision and pattern recognition. 2016. p3.)
(다른 Real-Time System과의 비교 출처: Redmon, Joseph, et al. "You only look once: Unified, real-time object detection." Proceedings of the IEEE conference on computer vision and pattern recognition. 2016. p6)
(R-CNN vs YOLO 출처: Redmon, Joseph, et al. "You only look once: Unified, real-time object detection." Proceedings of the IEEE conference on computer vision and pattern recognition. 2016. p6)
우리는 ‘이미지 잡음에 강인한 CNN 기반 건물 인식 방법’이라는 논문을 참고해서, 장애물이 건물을 가리더라도 건물을 인식할 수 있게 하기 위해서 건물의 특징점을 담고 있는 부분 이미지를 활용한 객체 인식 알고리즘으로 건물 인식 모델을 구현하고자 한다. 또한, 부분 이미지로 모델을 학습하기 위해서 하나의 이미지로부터 많은 양의 부분 이미지를 추출해야 하므로, 알고리즘의 처리 속도가 중요하다. 더불어 건물의 특징점들은 보통 크기가 작지 않고 작은 grid에 밀집해있을 가능성이 적으므로, 작은 객체들이 가깝게 모여있을 때 인식에 어려움을 겪는 YOLO의 한계가 부분 이미지로 건물을 인식하는 과정에서는 부정적으로 작용하지 않을 것이라고 판단했다. 따라서 ‘어디시립’의 건물 인식 알고리즘으로 YOLO를 선택하고자 한다.
◇ Message Queue
▶ kafka
- Kafka는 이벤트 기반의 메시지큐시스템으로, 메시지를 만드는 producer와 메시지를 사용하는 Consumer의 형태를 가지고있다. Kafka는 다른 메시지 큐와 다르게 높은 처리량과 실시간에 가가운 처리 능력을 가지고 있으며, 생산된 메시지를 잃어버리지 않도록 디스크에 log 형식으로 영속화를 한다. 또한, Topic과 partition을 통해 높은 확장성을 가지고 있다.
- Open source message queue는 Apache Kafka, Rabbit MQ 등 다양한 메시지큐 시스템이 있다. 각자 추구하는 방향이 다르기 때문에 어떤 기술이 최고라고 얘기할 수 없다. 그러나, 우리가 사용하려고하는 Kafka는 현재 LINE이나 LinkedIn 같은 대규모 기업에서도 활발히 사용하고 있다.
◇ 크롤링
- 크롤링은 웹 페이지의 HTML 파일을 가져와서 원하는 데이터만 추출하는 기법이다. 대표적으로 Python과 Node를 이용해서 크롤링을 할 수 있다. 현재 파이썬에 존재하는 크롤링 관련 라이브러리는 BeautifulSoup과 Selenium이 있다.
- BeautifulSoup: HTML을 파싱해서 원하는 데이터를 추출하는 방식이다.
- Selenium: 로그인이 필요하거나, CSR과 같은 Client에서 먼저 빈 HTML을 받고, JS를 통해 렌더링 되는 사이트에서 BeautifulSoup로만 해결할 수 없기 때문에, Selenium을 통해 Web Driver를 이용 하여 직접 browser를 조작하는 방식으로 해결한다.
◇ 관계형 데이터베이스
- 관계형 데이터베이스는 키(Key)와 값(Value)들의 간단한 관계를 테이블화 시킨 데이터베이스이다. 트랜잭션을 보장하기 위해 원자성, 독립성, 지속성의 기능을 제공하여 데이터의 무결성, 완전성, 정확성을 보장한다. 또한 SQL을 사용하여 데이터에 접근하며 여러 OS에서 사용이 가능하다. 현재 가장 많이 사용하는 RDBMS에는 Oracle과 MySQL이 있다.
- Oracle: 1979년 오라클사에서 만든 유로 상업용 DB이다. 대규모 데이터베이스를 지원하기 때문에 대량의 정보관리를 할 때에 가장 좋은 성능을 보인다. 또한 다른 데이터베이스보다 고성능의 트랜잭 션을 지원한다.
- MySQL: 세계에서 가장 많이 쓰이는 오픈 소스의 관계형 데이터베이스이다. 프로시저를 통한 데이 터 레코드 삽입, 삭제와 같은 단계를 하나로 묶어서 사용할 수 있으며 트리거도 존재한다. 5천건 이 하의 데이터를 다루는데 적합한다.
◇ 스프링부트
- 기존 자바 기반의 애플리케이션 프레임워크인 스프링은 DI, IoC 등의 특징을 가지고 있다. 하지만 개발 환경 설정에 어려움이 있었고 이를 보완하기 위해 스프링부트가 만들어지게 되었다. 내장 서버를 갖추고 있어 독립 실행이 가능하며 Spring Initializr의 지원을 통해 설정을 단순화 하였다. 또한 스타터를 통해 자동화된 스프링 설정을 제공함으로써 간단한 설정으로 빠른 실행이 가능하게 되었다.
- 특허 조사
◇ 멀티 프레임 기반 건물 인식을 위한 특징점 분류 방법(A classification method of feature points required for multi-frame based building recognition) 등록특허 10-1741761
- 한 장 이상의 멀티 프레임을 이용하여 건물 인식에 필요한 특징점을 분류하는 멀티 프레임 기반 건물 인식을 위한 특징점 분류 방법에 관한 것으로서, (a) 상기 멀티프레임 영상의 각 영상에서 특징점을 추출하는 단계; (b) 추출된 특징점들을 대상으로, 각 영상 간에 정합을 수행하여, 정합된 특징점 쌍을 획득하는 단계; (c) 다수의 특징점 쌍들로부터 호모그래피 행렬을 획득하고, 획득된 호모그래피 행렬을 이용하여 특징점을 분류하는 단계; 및, (d) 분류되고 남은 특징점들을 이용하여 상기 (c)단계를 반복하는 단계를 포함하는 구성을 마련한다.
◇ 웹 크롤링 시스템 및 그 방법(System for web crawling and Method thereof) 공개특허 10-2010-0094263
- 본 발명은 웹 크롤링에 소요되는 시간을 획기적으로 단축시킬 수 있는 웹 크롤링 시스템에 관한 것이다. 본 명세서에서 개시하는 웹 크롤링 시스템은 웹 크롤링을 위한 기준 웹 페이지들(시드 페이지들(seed pages))을 설정하고, 웹 크롤링을 통해 발견되는(Discovered) 상기 시드 페이지들의 각 시드 페이지(pi)에의 접근 확률(중요도)을 산출하여 상기 각 시드 페이지(pi)에 우선순위를 부여하는 시드 페이지 우선순위 부여부; 상기 부여된 각 시드 페이지(pi)의 우선순위 중 가장 높은 순위를 갖는 시드 페이지(pi,max)를 추출하여 우선적으로 다운로드하되, 상기 시드 페이지(pi,max)에 링크된 외부링크(outlink) 페이지들도 일괄적으로 다운로드하는 다운로드부; 및 상기 다운로드된 외부링크 페이지들의 각 링크 페이지(pj)에 대한 상기 시드 페이지(pi,max)내에서의 접근 확률(중요도)을 산출하여, 상기 각 링크 페이지(pj)에 우선순위를 부여하는 외부링크 페이지 우선순위 여부를 포함하여 본 시스템 발명의 과제를 해결한다.
- 특허 전략
◇ 건물인식에 중요한 건물 특징들을 자동으로 추출할 수 있는 방법을 제시한다.
- 기술 로드맵
내용
시장상황에 대한 분석
- 경쟁제품 조사 비교
◇ 시대생
● 사용자 분석
- 유저 수 6,000명 이상
- 서울시립대학교 학생 인증 후 사용 가능
- 포탈 계정 인증을 통한 인증
- 학생증 인식을 통한 인증
● 주요 기능
- 커뮤니티 기능
- 보틀 기능 (유저들 사이의 랜덤 채팅)
- 에듀클래스 공지 등록 알림 기능 (현재는 에듀클래스 서비스 종료로 인해 중단)
- 공지사항 등록 알림 기능 (일반공지, 학사공지, 직원채용, 창업공지)
- 유저 의견을 수렴하여 학생자치기구에 의견 전달하는 기능
- 학식 정보 제공 기능
● 장점
- 사용자에게 공지사항 알림을 제공해서 홈페이지에 직접 접속하지 않고도 알림을 받아올 수 있게 해줌
● 한계
- 주 기능이었던 에듀클래스 알림 서비스를 더이상 사용할 수 없게 되었음
- 교내 여러 공지사항들 중 일반공지, 학사공지, 직원채용, 창업공지에 대한 정보만 제공
- 공지사항 알림에 지연이 있어 선착순 이벤트 등 시간이 중요한 공지 전달에 적합하지 않음
◇ 패스파인더
● 사용자 분석
- 부산대학교 학생들
● 주요 기능
- 카메라 어플을 통해 건물을 비추면 건물을 인식하는 기능
- 로그인 시, 에브리타임 시간표 크롤링하는 기능
- 건물 인식 시, 사용자가 듣는 수업 정보를 가져오는 기능
- 로드뷰 API를 통해 건물 데이터를 수집하는 기능
● 장점
- 사진을 찍지 않고 건물이 카메라 앵글에 들어오기만 해도 건물을 인식함
- 에브리타임 아이디를 이용해 사용자가 듣는 수업만을 제공하기 때문에, 더욱 사용자 맞춤형 정보를 제공함
● 한계점
- 따로 DB를 구상하지 않고, 기계 내의 데이터베이스를 구현했기 때문에 추후 확장성을 고려하기 힘듦
- 로그인할 때마다 에브리타임 시간표를 크롤링 함. 특정 어플에 종속적이고 비효율적인 로직으로 보임
- 촬영한 건물에서 이번학기에 듣는 수업의 종류만 알려주기 떄문에 학기 초 빼고는 사용할 이유가 없음
- 마케팅 전략 제시
개발과제의 기대효과
기술적 기대효과
◇ 기존 교내 건물에 대한 정보를 얻기 위해 걸렸던 과정을 단축시킨다.
◇ 기존 새로운 공지사항을 확인하기 위해 쓰였던 시간을 단축시킨다.
경제적, 사회적 기대 및 파급효과
◇ 공지사항을 빠르게 얻을 수 있기 때문에 선착순, 기한이 정해진 이벤트 참여율이 높아진다.
◇ 학생들이 흩어져있는 공지사항을 한 곳에서 볼 수 있게 되면서 학생들에게 편의성을 제공한다.
◇ 원하는 공지사항의 알림만을 받을 수 있게 해서 불필요한 웹사이트 접속 시간을 줄이는 경제적인 이점을 제공한다.
기술개발 일정 및 추진체계
개발 일정
구성원 및 추진체계
설계
설계사양
제품의 요구사항
설계 사양
◇ 클라이언트가 촬영한 사진은 FastAPI 서버에서 처리된다.
◇ 클라이언트가 촬영한 사진은 AWS S3에 저장한다.
◇ 공지사항 정보는 스프링부트 서버에서 처리한다.
◇ 스프링부트는 카프카 서버에 공지사항이 등록되면 이를 가져와 사용자들에게 알림을 전송한다
◇ FastAPI와 스프링부트 서버는 AWS RDS를 공유한다.
개념설계안
◇ 건물 인식
후보군을 좁히는 방법
- 사용자가 사진을 찍는 위치를 받아 반경 몇m내의 건물들을 후보군에 포함한다.
- 후보군내의 건물들에 대해 이미지 모델을 돌려 결과를 반환한다.
후보군을 좁히지 않고 진행하는 방법
- 사용자가 사진을 찍은 이미지를 이미지 모델을 돌려 결과를 반환한다.
◇ 공지사항 알람
학교에서 지정한 키워드를 이용하는 방법
- 학교 공지사항에 지정된 해시태그를 키워드로 선정하여 키워드 목록 중 사용자가 원하는 키워드를 선택하도록 한다.
- 선택된 키워드가 포함된 공지사항만 푸시 알람으로 제공한다.
사용자가 지정한 키워드를 이용하는 방법
- 사용자가 키워드를 지정하고 지정한 키워드가 포함된 공지사항만 푸시 알람으로 제공한다.
유스케이스 설계
유스케이스 그림
유스케이스 시나리오
데이터베이스 설계
ERD
테이블 및 칼럼
결과 및 평가
완료 작품의 소개
프로토타입 사진 혹은 작동 장면
관련사업비 내역서
완료작품의 평가
향후계획
◇ 앱 설정 페이지 구현
◇ 건물 이미지 데이터 추가
◇ 부서에 대한 호수나 위치 데이터 추가
◇ 인식 가능한 건물 추가
◇ 배포 프로세스 구축
◇ 서버 비용 문제 해결
◇ 학교 홈페이지로 부터 교내 시설 정보 가져오기