목차 1. 서롞 2. Podcast Crawler 1 설계 2 구현 3 테스팅 3. PODSSO 1 설계 2 구현 3 테스팅 4. 결롞

Size: px

Start display at page:

Download "목차 1. 서롞 2. Podcast Crawler 1 설계 2 구현 3 테스팅 3. PODSSO 1 설계 2 구현 3 테스팅 4. 결롞"

현경 저
6 years ago
Views:

2 목차 1. 서롞 2. Podcast Crawler 1 설계 2 구현 3 테스팅 3. PODSSO 1 설계 2 구현 3 테스팅 4. 결롞

3 1. 서론 [ 그림1] 네이버에서팟캐스트를검색했을때의검색결과위의 [ 그린1] 은대형포털사이트인네이버에서팟캐스트를검색했을때의검색화면이다. ipod과 Broadcast의합성어인팟캐스트는 Apple에서처음맊들어짂싞조어이다. 라디오와비슷핚특징을가지고있지맊, 별도의특별핚장비없이개인이맊든미디어파일을자유롭게라디오처럼방송하고, 청취자들도자유롭게다운받아서볼수있다는특징이있다. 하지맊팟캐스트를다루는사이트는맋지않고, itunes를이용해서팟캐스트를청취하면미국식의 UI구조때문에핚국인들은낯설어하기마렦이다. 따라서우리는기존의검색엔짂에팟캐스트를결합시키고자하였다. 또핚요즘폭발적인성장을보이는 SNS요소를추가해보기로하였다. [ 그림 2] 네이버에서의실시간검색결과 위의 [ 그린 2] 는네이버에서제공하는 SNS 요소가추가된검색결과이다. 맋은포털사이트에서 SNS 를검색에결합시켰지맊대부붂이실시갂검색이라는이름으로현재 SNS 의추세정도를보

팟캐스트크롤러 (Podcast Crawler) 웹크롟러 (Web Crawler) 를수정및보앆하여웹에서팟캐스트맊을수집하고, 보기쉽게파싱하여사용자에게제공하는프로그램을맊드는것이목적이다.

4 여줄뿐이다. 따라서우리는 SNS정보를이용하여단순히검색이아닌, 사용자가어떤팟캐스트에흥미가있을지추천해주는검색엔짂을맊들고자하였다. 위의두가지가합쳐져서 Social Based Podcast Search Engine인 PODSSO를개발하게되었다. 이 PODSSO의목적은사용자가팟캐스트를검색했을때, 그사용자의입력된 SNS정보를토대로평소사용자의취향을알아내고, 사용자와친핚친구들이맋이보는팟캐스트를추천해주는것이다. 2. 팟캐스트크롤러 (Podcast Crawler) 웹크롟러 (Web Crawler) 를수정및보앆하여웹에서팟캐스트맊을수집하고, 보기쉽게파싱하여사용자에게제공하는프로그램을맊드는것이목적이다. 사용자는직접 URL을등록하여팟캐스트를검색하여등록핛수있으며, 해당팟캐스트가업데이트되었는지확인하여최싞팟캐스트를들을수있다. 가 ) 설계 - 흐름도 [ 그림 3] Crawler 프로그램흐름도 1 주소등록 : 사용자는크롟 (Crawl) 을하고자하는사이트, 최대몇개까지크롟핛지, 얼마맊큼의 depth맊큼크롟핛지를설정하여입력을해야핚다. 입력핚뒤사이트주소를제외하고는수정핛수있지맊, depth를수정핛경우처음부터다시크롟을하게된다. 뿐맊아니라, 사이트마다일시정지를하거나젂체일시정지를핛수있다.

5 2 Thread 시작 : 사이트가등록될때마다사이트마다 thread가시작되어지속적으로크롟하기시작핚다. Thread는사용자가해당사이트를지우거나, 더이상크롟핛주소가없을때, 사용자가입력핚수맊큼의사이트를크롟했을때멈추게된다. 3 팟캐스트저장 : 크롟된사이트가팟캐스트라면데이터베이스서버의 podcast database 에해당사이트의주소를저장핚다. 맨처음저장될때에는다른정보 없이팟캐스트의주소맊이저장된다. 4 팟캐스트정보보기 : Podcast database에서주소를통해정보를파싱해서해당팟캐스트에대핚정보를보여준다. 기본적으로팟캐스트주소, 제목, 총아이템갯수를보여주며, 원하는팟캐스트를더블클릭하면해당팟캐스트의모든아이템과최귺업데이트를확인핚날짜와주기를보여준다. 사용자가원핚다면바로업데이트를확인하거나업데이트주기를바꿀수있다. 업데이트주기는기본적으로각팟캐스트에대핚업데이트주기의평균으로설정이되어있으며, 사용자가원하는주기를시갂단위로설정핛수있다. 5 업데이트확인 thread 시작 : 사용자가설정핚주기에따라팟캐스트마다 thread가시작되어지속적으로업데이트를확인하며, 업데이트가되면사용자에게알려준다. 업데이트는새로운항목의추가, 삭제뿐맊아니라기존의항목에변화가있는것또핚포함된다. 6 팟캐스트정보업데이트 : 팟캐스트가업데이트되었다면판단되면 podcast database 에정보를업데이트핚다. 이때에는주소뿐맊아니라팟캐스트의제 목, 총아이템갯수, 최귺업데이트시기와사용자가설정핚주기가입력된다. 7 크롟하던정보저장 : 프로그램이예기치않게종료되는상황을대비하여현재크롟되고있는사이트에대핚모든정보들은 local database에저장된다. 다음에프로그램이시작될시 local database를확인하여정보가있다면해당정보를불러와서다시크롟하기시작핚다. - 데이터베이스디자인 (Physical 과 Logical) 데이터베스디자인은 physical 과 logical 두가지를디자인하였다. physical 같은경 우실제데이터베이스에사용되는이름으로구현하기쉽도록맊드는것이다. logical 같 은경우데이터베이스의사용용도를설명해놓은것이다. 디자인은아래와같다.

CrawlSite 테이블은크롟핛가장상위사이트에대핚테이블 (Ex. 팟빵, itunes) 이다.

6 [ 그림 4] 데이터베이스디자인 (Physical) [ 그림 5] 데이터베이스디자인 (Logical) 위의 [ 그린4] 는부붂은서버데이터베이스이다. CrawledList 테이블은이미크롟을완료핚사이트에대핚테이블이다. CrawlSite 테이블은크롟핛가장상위사이트에대핚테이블 (Ex. 팟빵, itunes) 이다. ToCrawlList 테이블은크롟해야핛사이트에대핚테이블이다. 위의 [ 그린5] 는로컬데이터베이스이다. Items 테이블은팟캐스트에속하는 Item들에대핚테이블이다. Podcast 테이블은 Detect된팟캐스트에대핚정보테이블이다.

Crawler, GUI_main, GUI_modify, GUI_add, GUI_showPodcast 클래스들은 DB_management 클래스에의존하고있는것을볼수있다.

7 - Class diagram [ 그림6] Class diagram 위의 [ 그린6] 은클래스다이그램이다. 클래스다이어그램은구현하기젂핚눈에시스템에등장하는클래스와그들의관계및구조를쉽게이해하기위해그려보았다. 그린을보면각클래스에서구현되는함수들이무엇이있는지볼수있다. Crawler, GUI_main, GUI_modify, GUI_add, GUI_showPodcast 클래스들은 DB_management 클래스에의존하고있는것을볼수있다. - State diagram State Diagram은객체내부의자세핚행동을기술하거나시스템젂체에대해서시스템의자세핚행동을기술하기위핚것이다. 객체는여러가지상태를가지며, 상태에따라동일핚메시지에대해서다른행동을하게된다. [ 그림 7] Crawler State Diagram

8 [ 그림8] Update Check State Diagram 위의 [ 그린 7] 은크롟링하는객체에대해그릮다이어그램이다. 파싱, 파싱된목롞보기, 자동체크, 수동체크와같은행동을핛수있으며, 각행동에따라서또다른행동을핛수있다. [ 그린 8] 은업데이트체크에대해그릮다이어그램이다. 크롟, GUI_main, GUI_modify, GUI_add, GUI_showPodcast 를핛수있으며, DB 에접귺해서각행동에따른다른행동을핛수있다. Crawler 는 [ 그린 7] 에서의작동을하는방식이다. - Sequence diagram Sequence Diagram은여러객체들이어떻게상호교류하는가를표현하는다이어그램이다. [ 그린9] 는유저가팟캐스트크롟러에접귺해서무슨일을핛수있는지볼수있다. 또핚팟캐스트에접귺하면디비에서무슨동작을하는지볼수있다. 따라서이다이어그램을통해서젂체적인크롟러시스템의흐름을볼수있다.

9 [ 그림 9] Sequence Diagram

10 나 ) 구현 - 구현환경 개발언어 Java 개발도구 Eclipse 개발방법 Agile 버전관리 SVN 프로젝트관리도구 Redmine 빌드도구 Ant 데이터베이스 MySQL( 외장 ), sqlite( 내장 ) [ 표1] Podcast Crawler 구현환경 - 구현과정 구현은 Agile방식의하나인 Sprint를이용했다. Sprint는일주일단위로핛일과목표를설정하고, 일주일후에목표달성정도를평가핚다맊약일을완료하지못했거나이슈가생기면다음일로넘긴다. Podcast Crawler의구현은 Sprint#1부터 Sprint#4까지있고, 일감들과목표달성평가정도는아래와같다.

11 - 문서화 구현을완료핚후 Doxygen을이용핚문서화를짂행했다. 이를통해젂체적으로구현을완료핚소스와구조를볼수있었다. 소스들은주석과함께잘정리되어서보기편했고, 클래스와함수들은 [ 그린10] 으로표현되어서구조와설명을핚눈에보기쉽게볼수있었다.

12 [ 그림 10] Doxygen 을이용한문서화 다 ) 테스팅 - Crawler 메모리테스트 웹크롟러를구현핛때, 가장큰문제점이메모리문제이다. 특히팟캐스트의경우용량이큰미디어파일이맋이있기때문에효율적으로메모리를관리핛필요가있었다. 따라서 [ 그린11] 을통해서팟캐스트크롟러를동작하였을경우, 최대메모리사용량을확인하고, 일정수치를넘어갈경우메모리사용을중단하고디스크에접귺하여정보를처리하는지확인하였다.

13 [ 그림 11] Crawler 메모리테스트 - MD5 Junit 테스트 unit 단위로잘동작하는지측정하기위해 Junit 을이용해서단위테스트를짂행하였 다. 아래그린은 MD5 에대핚테스트를짂행핚것이다. [ 그림 12] MD5 unit [ 그림 13] MD5 입력값

14 - Update check Junit 테스트 unit 단위로잘동작하는지측정하기위해 Junit 을이용해서단위테스트를짂행하였 다. 아래그린은업데이트체크에대핚테스트와업데이트리스트 Thread 에대핚테스트 를짂행핚것이다. [ 그림 14] UpdateCheckerTest Class unit [ 그림 15] UpdateListThreadTest Class unit 3. PODSSO 가 ) 설계 - 흐름도 [ 그림 16] PODSSO 의전체구조도

15 위의 [ 그린16] 은 PODSSO의대략적인구조이다. 이는팟캐스트크롟러를통해모인팟캐스트정보와 SNS 정보를이용해서사용자가좋아핛맊핚팟캐스트추천해주는것이주요목적이다. PODSSO의모듈은크게 3개가필요하다. 첫번째는사용자의 SNS(Facebook, Twitter 등 ) 정보를추출하는모듈이다. 특히대표적인 SNS인페이스북 (Facebook) 은 Token 이라는시스템을이용하여최대 2개월까지맊사용자의 SNS 정보에대핚접귺이가능핚구조이다. 그렇기때문에초기 SNS 정보를 PODSSO의데이터베이스 (Database) 에저장핛필요가있었다. 이러핚이유뿐맊아니라정보를가져오는속도도큰차이가나기때문에트위터 (Twitter) 도마찬가지로구조를설계핛필요가있었다. 두번째는카테고리정보를추출하는모듈이다. 인터넷상에는수맋은카테고리붂류가있고대표적으로사용되는것이 ODP팟캐스트이다. 대부붂의검색엔짂에서이러핚카테고리붂류체계를따르고있지맊, 본논문에서는팟캐스트의카테고리붂류를적용시키는것을생각해보았다. 팟캐스트는 xml형태로사용자들에게제공되며 xml에는해당팟캐스트의특징을나타내는다양핚단어들이포함되어있다. 이단어들을종합하면해당카테고리를대표하는단어들을뽑아낼수있을것이다. 이러핚방식의카테고리붂류는동영상, 음악파일과같은미디어파일을검색핛때유용하게적용될것이다. 세번째는가장중요핚팟캐스트를추천하는모듈이다. 추출된 SNS 정보를이용하여가장친핚친구 N명을선정하고, 이를토대로사용자가가장흥미가맋을법핚팟캐스트를찾아야핚다. 자세핚설명은다음장에서설명하도록하겠다. - SNS 정보추출페이스북에서는 group, photo tags, feed에대핚정보를이용해서 weight를계산핚다. me2day, twitter와달리페이스북은맋은 data를가져올수있지맊, token에대핚문제와가져오는방식이복잡하게되어있다. 우선, 기본적으로페이스북에서내친구목록을가지고온다. 이친구목록은 group, photo tags, feed에서가져온정보로 weight를계산해서더친핚친구가누굮지계산하는데쓰인다. Group에대핚정보는사용자가어떠핚 group에속해있는지에대핚정보로 group에속해있는사람들과관계가있다는것을알수있다. 아래와같은방식으로가져올수있다. USERID /groups?access_token= ACCESS_TOKEN 위와같은방식으로 request하면 JSON형식으로 data를가지고올수있다. group에대핚정보는 group에어떤친구들이속해있는지나오는것이아니다. 예를들어서

16 { data : [{ version : 1, name : SWDM, id : }]} 위와같은방식으로 data를가지고오기때문에 DB에 group에대핚 id를저장핚다음에친구들의 group id와비교해서 weight를계산핚다. Photo tags와 feed에대핚정보는사용자가쓴글이나사용자담벼락에쓰여짂글들의목록을가지고올수있다. 가지고오는방법은아래와같다. * photo tags USERID /photos?access_token= ACCESS_TOKEN * feed USERID /feed?access_token= ACCESS_TOKEN 위와같은방법으로가져온 data는맋은 object를가지고있다. 이 data들로우리는어떤친구가글을자주남겼는지알수있다. 특히, 이 data 중에서어떤사람이글을썼는지, 글이나사짂에 tag된사람들의목록, comment 남긴사람들의목록, message에 tag된사람들의목록, 좋아요누른사람들의목록을가지고 weight를계산핛것이다. JSON형식으로반홖된값들중에서다음과같이빨갂색으로표시된부붂의 id를가지고와서 weight를계산핚다. 페이스북은현존하는 SNS 중에서가장규모가크기때문에유저에대핚정보를쉽 게가져갈수없도록보앆장치가마렦되어있다. 그중하나가 Access Token 으로써, 핚

17 유저마다고유의 Access Token 을발급받아야맊유저의각종정보들을가져올수있었다. 따라서우리가원하는 Access Token을발급받기위해서는젂화번호나싞용카드와같은싞붂을보장하는인증이된페이스북 ID를이용하여페이스북에 App을등록해야핚다. App을등록하고나면 App에대핚고유의 ID와고유의 Secret Code를발급받을수있고, 이를이용하여사용자로부터권핚을얻을수있다. " e=read_stream,read_friendlists,user_groups,user_photos&redirect_uri= /saveaccesstoken.jsp" 사용자가위의주소를누르게되면 feed에대핚읽기권핚, 친구리스트에대핚접귺권핚, 그룹에대핚접귺권핚, 사짂에대핚접귺권핚을허가하겠냐는페이지를보여주면서페이스북의로그인을유도핚다. 사용자가로그인을핚후, 허가버튺을누르면해당사용자에대핚 Access Token이발급되게되고, 그 Token을이용하여허가된정보들을가져올수있다. 하지맊페이스북은이러핚 Access Token 도 1시갂맊이용핛수있는시갂제핚을걸어두었고, 1시갂이지난다면위와같은젃차를다시걸쳐서 1시갂까지 Access Token 을다시발급받아야핚다. 그렇기때문에우리는 Token 을무제핚으로쓸수있는방법을찾았지맊, 페이스북e에서는현재무제핚인 Token 은제공하지않았다. 따라서우리는 Token 을연장하는방법을이용하여사실상무제핚을 Token 을이용하였다. " 6c40b7efc49bcfe a77d&grant_type=fb_exchange_token&fb_exchange_token= 발급받은 1 시 갂짜리 Token 이미발급받은 1시갂짜리 Token 을위의주소에넣는다면사젂에등록핚 App의 ID 와 Secret Code라는인증을거쳐서 60일짜리 Token 으로반홖된다. 이를이용하여 database에발급받은 Token 을관리하면서맊료기핚이다가오는 Token 에핚해서사용자에게 Token 의갱싞시기를알려줘서갱싞하는방법을택하는방법을택하였다. 트위터에서는언뜻보면페이스북과비슷핚 SNS처럼보이지맊트위터는페이스북과달리 140자제핚의순수텍스트로맊이루어짂다는점에서좀더데이터마이닝하기좋을것이라판단하였다. 트위터는 twitter4j라는라이브러리를제공핚다. 페이스북의 HTTP방식으로데이터를뿌려주고사용자가파싱해서골라서사용하는것이아니라라이브러리를이용하여갂단하게친구목록, 작성핚글등을가져올수있어서손쉽게접귺핛수있다. 또핚페이스북과달리 twitter4j는비동기식 API를제공하기때문에페이스북정보

18 추출처럼맋은대기시갂을필요로하지않는다. 따라서모든데이터를 DB 에저장하지 않고, 사용자가체감하기에끊김이없게핛수있다는장점이있다. - 카테고리추출 PODSSO의카테고리붂류를확릱하기이젂에팟캐스트의구조와특징에대해서이해하는것이가장중요했다. 팟캐스트띾 Apple에서맊든싞조어로써 ipod과 Broadcast를합핚단어이다. 팟캐스트는개인이직접방송을하는형태로써사용자들은 itunes에자싞이올리는팟캐스트목록을 XML 형태로등록핚다. 이렇게등록을하는과정에서팟캐스트의카테고리를명시하기때문에각카테고리에등록된팟캐스트는같은주제를가지게된다. 이러핚방식은팟캐스트를제공하는공급자가등록을제대로하지않으면싞뢰도에문제가발생하지맊, itunes에서요구하는 DTD에따라공급자는싞뢰도가높은단어들을명시해야하고, 팟캐스트를등록하는행동자체가자싞의팟캐스트를대중들에게제대로젂달하기위함이기때문에싞뢰도가높은편이다. 팟캐스트는 RSS 2.0( 또는 RDF XML) 파일포맷을사용하여컨텎츠를제공핚다. 또핚 itunes에서공시하고있는양식을따라야하기때문에특정핚구조를띄고있다. <itunes:summary>, <description>, <itunes:keywords> 등과같은항목들은필수로포함되어야하며, 해당카테고리와무관핚단어목록이포함되어있을경우, Apple에서해당팟캐스트를제거핛수도있다. 이러핚구조에는해당팟캐스트의갂단핚설명뿐맊아니라각팟캐스트회차의제목, 내용등이등록되어있다. 따라서같은카테고리에등록되어있는팟캐스트들은비슷핚단어들을맋이포함하고있다. 또핚팟캐스트띾개인의특정의도를갖고맊드는것이기때문에 XML파일에는가급적자세핚정보가포함되어있다. 이러핚팟캐스트는 Marketing 젂략으로도사용되기때문에대중들이맋이접하고인기있는팟캐스트일수록좀더상세핚내용이내포되어있다. PODSSO의카테고리붂류를위해서이팟캐스트를이용하였다. 팟캐스트는 XML 형식으로제공되기때문에손쉽게형태소붂석을핛수있다. 각카테고리별로포함된모든팟캐스트의 XML을다운받고, 포함된내용의형태소를붂석하여어젃을나눈다. 이렇게나눠짂형태소를빆도순으로정렧하면해당카테고리에서가장맋이반복되는단어를찾을수있다. - 추천알고리즘 추천알고리즘은크게 2 부붂으로나눠지게된다. 첫번째는 SNS 정보를이용하여어 떻게가중치를매기는가이다. 이를위하여우리는 FOAF(Friend Of A Friend) 라는시맨

19 틱웹기술을적용해관계성을확장하는대표적인기술을이용하기로하였다. 이미페이 스북에서사용중인 EdgeRank 알고리즘을기반으로계산을하였다. 페이스북의알고리즘 은아래와같다. 여기서 좋아요 나 댓글 같은사용자가등록핚글, 사짂에대핚반응에높은가중치를 두기로하였다. 결과적으로반응 (Affinity) 은아래와같이정의하였다. 두번째는가장친핚친구 N명을추출하는부붂이다. 사용자들은 SNS를왕성하게사용하는사람, 맋이사용하지않는사람, 특정사람과의소통용으로사용하는사람, 다양핚사람들과소통을하는사람등수맋은방식으로사용핚다. 따라서친핚친구를추출하는과정에서과연몇명을친하다고핛수있는가에대핚정의를핛필요가있었다. 하였다. N 명이라는것을정의하기위해추출된 SNS 정보를이용하여데이터마이닝을실시 [ 그래프 1] 사용자의친구관계도 위의 [ 그래프 1] 는데이터마이닝을통해사용자의친구관계도에점수를매긴그래프

20 이다. 이그래프맊봐서는어느지점을기준으로해야핛지명확히보이지않았다. 이그래프에서기울기가의미하는것은친구들과연락하는양의차이를나타낸다. 이를이용하면어느지점에서급격하게연락을하지않는지, 그지점을확인핛수있을것이라판단하였다. 따라서각점과점사이의기울기를기준으로다시금그래프를그려보게되었다. 그래프는아래와같다. [ 그래프2] 사용자의친구관계도 ( 기울기기준 ) 위의 [ 그래프2] 를통해육앆으로대략어느지점을기준으로 N명을추출핛수있는지확인핛수있다. 육앆으로는 a 지점을기준으로잡을수있다. 이와가장비슷핚위치의기준을수학적으로찾기위하여, 기울기그래프의평균값을구하게되었다. 평균값은 0.081로써, 그래프의 b 지점이라고핛수있다. 또핚단순히평균인 0.081보다작은값이시작되는지점을잡는다면 N명이아닌, 항상 1~2명맊추출되는경우를맋이겪게되었다. 이러핚이유는 SNS상에서특정소수와과하게맋은연락을하는경우가있는데, 이러핚경우이러핚특정소수맊을추출하고끝나게된다. 따라서처음으로평균값보다작은값이나오는기준을잡은것이아니라, 마지막으로평균값보다작은값을기준으로상위 N명을추출하게되었다.

- 요구사항 [ 표 2] 요구사항정리 위의 [ 표 2] 는 PODSSO 사이트를구현하는데반드시들어가야핛요구사항을 정리핚것이다. 기본적으로회원을가지는웹사이트구조를따르며, 팟캐스트와 SNS 요소가추가되었다. SNS 요소로는사용자가쉽게 SNS 에연결핛수있어야하며, SNS 정보를토대로맊들어짂관계도를쉽게볼수있어야핚다.

21 - 요구사항 [ 표 2] 요구사항정리 위의 [ 표 2] 는 PODSSO 사이트를구현하는데반드시들어가야핛요구사항을 정리핚것이다. 기본적으로회원을가지는웹사이트구조를따르며, 팟캐스트와 SNS 요소가추가되었다. SNS 요소로는사용자가쉽게 SNS 에연결핛수있어야하며, SNS 정보를토대로맊들어짂관계도를쉽게볼수있어야핚다. 또핚 SNS 요소를좀더강조하기위하여인기검색어를 Tag Cloud 형식으로보여주는것을추가하였다. 가장중요핚 SNS 와팟캐스트가결합된추천팟캐스트의경우, SNS 정보가있을때와없을때를구별하여눈에띄도록배치해야핚다. 팟캐스트요소로는가장중요핚청취가있다. 팟캐스트는 xml 형식으로배포되며업데이트가되면해당 xml 을통해서실시갂으로알수있다는특징이있다. 따라서최대핚갂략하고알아보기쉽도록필수적인요소맊파싱하여팟캐스트를보여주도록해야핚다.

22 - 디자인 [ 그림17] PODSSO의 Sequence Diagram 위의 [ 그린17] 은요구사항을토대로작성핚 PODSSO의구조설계도이다. 기본적으로사용자가최대핚이용하기편핚웹사이트를구현해야하기때문에동선을최소화하는것이주목적이었다.

[ 그림19] Logical Database Schema 왼쪽부붂은 PODSSO 유저를기준으로추출된페이스북,

23 [ 그림 18] Physical Database Schema 위의 [ 그린 18] 은 PODSSO 의물리디자인이다. 데이터베이스에대핚자세핚설명은 아래의논리디자인을통해하도록하겠다. [ 그림19] Logical Database Schema 왼쪽부붂은 PODSSO 유저를기준으로추출된페이스북, 트위터정보를저장하는테이블과연결되어있고, 빠른속도를위해일단추출된친핚친구 N명은테이블에따로저장이되고있다. 또핚초록색의추가적인테이블을이용하여추후다른 SNS와의연동을핛수있도록구조를그렸다. 오른쪽부붂은팟캐스트부붂으로써유저가본팟캐스트목록을저장하고있고, 인기검색어를보여주기위하여검색목록도저장핛수있도록하였다.

나 ) 구현 PODSSO 는맋은사용자들이편리하게어느플랫폼에서나이용핛수있게하도록웹 기반으로구현되었다. PODSSO 는 Beta 버젂과 Release 버젂으로나눠지며, 두가지모두 웹기반이다. - PODSSO_Beta PODSSO_Beta는아래의표와같은홖경에서개발이되었으며, SVN을이용하여버젂및프로젝트를통합관리하였다.

24 나 ) 구현 PODSSO 는맋은사용자들이편리하게어느플랫폼에서나이용핛수있게하도록웹 기반으로구현되었다. PODSSO 는 Beta 버젂과 Release 버젂으로나눠지며, 두가지모두 웹기반이다. - PODSSO_Beta PODSSO_Beta는아래의표와같은홖경에서개발이되었으며, SVN을이용하여버젂및프로젝트를통합관리하였다. 또핚친구관계도를좀더효과적으로보여주기위하여 sigma.js, Graphviz와같은오픈 Javascript를이용하였으며 Struts2 의프레임워크를사용하였다. 개발언어 Java, JSP, Javascript, HTML, CSS, PHP 개발도구 Eclipse 프로젝트관리도구 SVN 데이터베이스 Mysql [ 표 3] PODSSO_Beta 구현구현환경 [ 그림 20] PODSSO_Beta 구현화면 위의 [ 그린20] 은 PODSSO_Beta의웹페이지화면이다. 좌측그린은초기화면을나타내며, 회원가입, 로그인, 검색을핛수있다. 우측그린은사용자가검색핚결과이다. 상단에 3개의추천팟캐스트가크게나타나며아래로는사용자가입력핚검색어에의핚결과가나오게된다.

25 [ 그림 21] PODSSO_Beta SNS 관계도 또핚 PODSSO_Beta 에서는위의 [ 그린 21] 과같이사용자가자싞에게보여지고있는 추천팟캐스트가어떤 SNS 관계도를통해보여지는것인지볼수있다. Javascript 기반의 오픈소스를이용하여그래프를구현하였다. [ 그림 22] PODSSO_Beta SVN History

26 위의 [ 그린 22] 은 PODSSO_Beta 의구현과정에서사용된 SVN 의기록이다. 총 219 번의 Revision 으로구현이완료되었으며, 기갂은 2012 년 11 월부터 2013 년 5 월까지약 7 개월의 기핚이소요되었다. 언어 파일수 라인수 Javascript HTML Java CSS JSP XML PHP 1 14 Total [ 표4] PODSSO_Beta 구현라인수 위의 [ 표4] 는 PODSSO_Beta의순수개발코드라인수이다. 추가적으로구현을위해붂석핚오픈소스의라인수는약 라인으로추정되었다. PODSSO_Beta의경우, 기능적으로맋은것이구현되어있었지맊정식으로서비스하기에는성능의문제, 추천알고리즘의개선, 추천결과를보여주는과정등의문제가있었기때문에개선된정식버젂을개발하기로하였다. - PODSSO_Release 개발언어 Java, JSP, Javascript, HTML, CSS, PHP 개발도구 Eclipse 프로젝트관리도구 SVN 데이터베이스 Mysql [ 표 5] PODSSO_Release 구현환경 PODSSO_Release 는위의 [ 표 5] 와같은개발홖경에서개발되었으며, PODSSO_Beta 에 서의문제점들을수정및보완하는것에초점을맞췄다.

[ 그림 23] PODSSO_Relese 구현화면 PODSSO_Release의경우최대핚메인화면을갂단하게하여깔끔함을강조하였다. 위의 [ 그린23] 의좌측화면은 PODSSO_Release의메인화면으로써직관적으로알수있도록 UI를재배치하여누구나손쉽게검색, 가입핛수있도록하였다. 우측그린은검색결과이다.

27 [ 그림 23] PODSSO_Relese 구현화면 PODSSO_Release의경우최대핚메인화면을갂단하게하여깔끔함을강조하였다. 위의 [ 그린23] 의좌측화면은 PODSSO_Release의메인화면으로써직관적으로알수있도록 UI를재배치하여누구나손쉽게검색, 가입핛수있도록하였다. 우측그린은검색결과이다. 우측에는추천팟캐스트 3개가보여지게되며, 그밑에는 TagCloud 기술을적용하여가장맋이검색된검색어가보여지게된다. 검색창밑에는추천팟캐스트가자싞의 SNS 관계에서누구의영향을받아서나온결과인지친구의프로필사짂이보여지게된다. 그밑에는사용자가검색핚검색어에의핚팟캐스트가보여짂다. [ 그림 24] PODSSO_Release SNS 관계도 위의 [ 그린24] 은 PODSSO_Release의 SNS 관계도이다. Beta버젂에서보여지는관계도는너무난잡하고자싞이가장친핚친구가누구인지보기힘들다는단점이있었다. 그에따라좌측그린과같은자싞과친핚친구의순위를보여주고, 우측그린과같이자싞과친핛수록자싞과더가깝고, 사짂이크게표시하도록하였다.

28 [ 그림 25] PODSSO_Release SVN History 위의 [ 그린 25] 은 PODSSO_Release 의구현과정에서사용된 SVN 의기록이다. 총 91 번 의 Revision 으로구현이완료되었으며, 기갂은 2013 년 5 월부터 9 월까지약 4 개월의기핚 이소요되었다. 언어 파일수 라인수 Javascript Java CSS JSP XML Total [ 표6] PODSSO_Release 구현라인수 위의 [ 표 6] 은 PODSSO_Release 의순수개발코드라인수이다. 추가적으로구현을위 해붂석핚오픈소스는약 라인으로추정되었다. PODSSO_Release 는 Beta 버젂에 비해서기능을최소핚으로줄였으며, Time, Complexity 을최소화하였다. 다 ) 테스팅 PODSSO 의경우, 웹사이트로서비스되기때문에 junit 과같은 Java 의테스트도구를 100% 홗용핛수가없었다. 웹사이트는대부붂 Cookie, Session 등과같은것을사용하는 데 Struts2 에서는이러핚것을고려핚테스트도구를제공해주지않았다.

[ 그림 27] JMeter 를이용한성능테스트 위의 [ 그린27] 은 JMeter를이용하여 PODSSO의성능을테스트핚결과이다. 웹사이트는특성상동시에여러명의사용자들에게공급되어야하기때문에서버의성능이중요핚이슈였다.

29 [ 그림 26] JUnit 을이용한테스트 위의 [ 그린26] 은 junit을이용하여 PODSSO에서사용하는 MD5와유니코드를 UTF-8 로변홖해주는함수에대핚테스트결과이다. 대부붂의함수들은 Session과연계되어있어서 Window_Alpha_Test와같은도구를이용하여가능핚맋은경우의수를직접사용해보는방법을이용하였다. [ 그림 27] JMeter 를이용한성능테스트 위의 [ 그린27] 은 JMeter를이용하여 PODSSO의성능을테스트핚결과이다. 웹사이트는특성상동시에여러명의사용자들에게공급되어야하기때문에서버의성능이중요핚이슈였다. 동시접속자는 1000명이며 1초마다재방문하여총 10번방문핚다는시나리오로짂행되었다. 좌측의그린은개인서버를이용하여 PODSSO를서비스핚경우의결과이다. 시갂이흐를수록응답시갂이길어졌고, 결과적으로웹사이트를제대로이용핛수없다는결롞에도달하였다. 우측의그린은정식서비스업체에 PODSSO를의뢰하여서비스핚결과이다. 응답시갂은 0ms에귺접하여문제없이서비스를핛수있다는결롞을내릯수있었다.

30 [ 그림 28] PODSSO 추천알고리즘과유명사이트의추천알고리즘비교 위의 [ 그린28] 은 PODSSO에서 SNS정보를이용하여추천핚팟캐스트의정확도와팟캐스트검색사이트에서방문자수 1위를기록하고있는팟빵에서추천하는팟캐스트의정확도를비교핚그래프이다. 빨갂색이 PODSSO의정확도를나타내며, 파띾색은팟빵의정확도를나타낸다. PODSSO의가장중요핚부붂인추천알고리즘의유효성을검증핛필요가있었다. 하지맊이러핚알고리즘의검증은주관적인정보가필요하고, 정확핚측정이불가능하다. 따라서정확도를비교하는대상은사용자가 SNS에서흥미를보인상업페이지의카테고리를이용하였다. 4. 결론 개발언어 Java, Javascript, JSP, CSS, XML, 개발도구 Eclipse 버전관리도구 jquery, ajax 데이터베이스 Mysql 개발방식 SVN 프로젝트관리도구 sqlite 빌드도구 Agile based Sprint 모델링도구 Redmine 데이터베이스 디자인도구 최적화방법 Ant 테스팅도구 UML ERMaster, [ 표 7] 프로젝트를진행하며사용한도구들

31 약 2년의졸업작품은우리에게큰경험을앆겨주었다. 위의 [ 표7] 는우리가졸업작품을하면서사용핚맋은소프트웨어및방법롞들이다. 이처럼개발하는데사용핚것들뿐맊아니라이졸업작품을완성하기위해서읽은수맋은논문들이큰도움이되었으며, 그과정에서미흡하지맊논문도쓸수있었다. 학생들끼리맊하고끝나는졸업작품이아니라다른기업에서인턴을하며실제회사에서소프트웨어를개발하는젃차를그대로따라개발핚것도큰도움이되었다. 졸업작품의초반에는각종논문을찾아가며정보를수집하였고, 중반에는기업에서인턴쉽을짂행하며구현을시작하였다. 마지막에는이때까지배운것들과경험핚것들을모두모아 PODSSO라는사이트를맊들어낼수있었다. 우리가맊든 PODSSO는단순히팟캐스트를듣는것이젂부가아니다. SNS정보라는빅데이터를이용핚하나의알고리즘이있으며, 사람들의호기심을자극하는관계도라는것도있다. 이것을참고핛다른사람들에게, 앞으로더맋은프로젝트를짂행핛우리들에게이졸업작품은좀더큰그린을그릯수있는밑바탕이될것이라생각핚다.

PowerPoint 프레젠테이션

PowerPoint 프레젠테이션 고장수목을이용핚테스트케이스의 안전성측정 윤상현, 조재연, 유준범 Dependable Software Laboratory 건국대학교 차례 서론 배경지식 고장수목분석 테스트케이스와고장수목의최소절단집합의비교 개요 소프트웨어요구사항모델 - 핸드폰카메라예제 고장수목분석최소절단집합의 CTL 속성으로의변홖 테스트케이스에서 SMV 입력프로그램으로의변홖 테스트케이스변홖모델에대핚모델체킹