Mercurial > hg > Papers > 2009 > pin-gn
view introduction.tex @ 2:4742b1e4da3a default tip
modify merge,
and remove eclipse, debug
author | one |
---|---|
date | Thu, 19 Feb 2009 01:26:01 +0900 |
parents | 78a12584e841 |
children |
line wrap: on
line source
\section{はじめに} %\pagenumbering{arabic} %CやJavaのプログラムの開発には、IDE(Integrated Developing Environment 統合開発環境)などが使われるようになってきているが、その中心は、依然、プログラムを入力するエディタである。 % %汎用のエディタの開発も依然続いており、Emacs やviなどのUnixベースの古典的なエディタは、もちろん、mi や秀丸などのGUIベースのエディタも広く使われている。 % %これらのエディタで作成された文書やプログラムは、大規模なソフトウェアプロジェクトの一部であることが多く、ソフトウェア開発者同士の協調作業の中心である。 %一つの文書は複数人で作成あるいはチェックされるものであり、一つの文書やプログラムを共有して作業することも必要となる。これらの協調作業をコンピュータによってサポートすることは、CSCW (Computer Supported Corporated Work)と呼ばれている。 % %Extreme Programming\cite{bib:xp}では、ペアプログラミング、リファクタリングなどのプラクティスが重要とされている。ペアプログラミングは、一つの画面を見ながら二人で一つのプログラミングを行なうものであり、技術レベルの同じ、あるいは異なる人で行なうことにより、教育的、あるいは、プログラムの理解を深める手法として有効とされている。 %我々の研究室で 我々の研究室で提案しているRemote Editing Protocol(REP)は、テキスト編集に特化したアプリケーション間通信プロトコルである。 REPを汎用のテキストエディタへ実装し、そのエディタ同士を接続することで、相互にデータの編集作業を行うことが可能になる。 %最初のREPは、一つのエディタをサーバとして、クライアントからの編集を可能にするものであり、1997年に新垣将史によって、pico エディタに実装された\cite{bib:arakaki3}。その後、Emacs 上にも実装された\cite{bib:arakaki}。 %この版のREPでは、変更は一方向であり、サーバはクライアントからの %変更を受け付けるだけであった。 % %宮里忍、安村恭一は、二つのエディタ間でREPコマンドを巡回させることにより、二つのエディタ間での双方向の編集を可能にするマージアルゴリズムを作成した\cite{bib:yasumura}\cite{bib:miyazato}。 %この時に、REPはvimにも移植されている。 % %\begin{figure}[htpb] % \begin{center} % \includegraphics[scale=.8]{figure/edit_command.pdf} % \end{center} % \caption{REPコマンドによる双方向のテキスト編集} % \label{fig:edit_command} %\end{figure} ソフトウェア開発において、複数人での協調作業を行う際、問題となるのが、距離的な制約や、アプリケーションの違いや、キーボードの違い(USキーボードと日本語キーボードの差など)の様な環境の違いであると考える。また、同じアプリケーション同士であっても、カスタマイズの方法によって、操作方法が大きく異なることもある。 REPはこのような距離的な制約や、環境の違いなどを吸収し、協調作業の効率化を図ることにより、ソフトウェア開発の生産性、信頼性の向上を目指している。 %プログラミング教育にもペアプログラミングが有効であり、大学や専門学校で、 %学生の編集しているプログラムを、先生が修正するなどの基本的な作業にも %REPは、有効であると考えられる。 %2007年にはEclipseへの実装を行なった。これにより、Eclipse同士、あるいは、 %Eclipse 上のファイルをEmacs/vimなどで編集することが可能になる。 % %この時点で、エディタ同士を直接 %接続する手順が複雑すぎることが明らかになった。エディタのIPアドレスや %ファイル名をユーザがエディタから直接入力するのは、かなり繁雑である。 %そこで、エディタ間の接続を管理するGUIを独立に作ることを提案した。 % %\begin{figure}[htpb] % \begin{center} % \includegraphics[scale=.8]{figure/one_session_manager.pdf} % \end{center} % \caption{REPコマンドによる相互のテキスト編集} % \label{fig:one_session_manager} %\end{figure} % %エディタは、まず、二種類のコマンドにより、Session Manager に接続する。 %第一のコマンドは共有するファイルを提供するコマンドでありputと呼ばれる。もう %一つのコマンドは、共有するファイルにアクセスするコマンドであり、joinと %呼ばれる。Session Manager はGUI上で、join してきたエディタが、 %putされたファイルのどれに接続するかを決定する。 % %Session Manager にはネットワーク経由でどこからでも接続できるが、 %その場合は、やはり、エディタの方でIPアドレスなどを指定する必要がある。 %それよりはSession Manager はコンピュータ上に一つあると言う方が %望ましい。そうすれば、エディタは決まったポートでデフォルトの %Session Manager に接続できる。 % %複数のコンピュータ間で接続する場合には、Session Manager 同士を %接続する。この場合の接続は、IPアドレスを指定した手動接続と、 %Session Manager を探すプロトコルを用いた自動接続が考えられる。 % %\begin{figure}[htpb] % \begin{center} % \includegraphics[scale=.8]{figure/many_session_manager.pdf} % \end{center} % \caption{REPコマンドによる相互のテキスト編集} % \label{fig:many_session_manager} %\end{figure} % %このようにSession Managerを導入することで、エディタ側に複雑な %ユーザインタフェースを実装することなくREPを実装することが %可能となる。このユーザインタフェース部分は、Emacsでは10\%程度、 %vim では30\%程度を占めており無視できない大きさである。 以前のREPは\cite{bib:arakaki3,bib:miyazato, bib:yasumura}エディタ同士を直接接続し、データの相互編集を行っていた。 その場合、エディタ側から相手のIPアドレスやファイル名の入力などの操作を行わなければならなかったため、ユーザ操作が煩雑であった。 そこでREPでは、エディタの接続や、テキスト編集(Session)を管理するためのSession Managerの導入を行った\cite{bib:miyagi}。 しかし、この場合でも、リモートホスト上にある他のエディタとの編集作業を行う際にはそのIPアドレスを入力しなければならない。 %本研究では、REPの接続プロトコルの改善やマージアルゴリズムの改善を提案し実装を行った。 本研究では、Session Mnager同士の接続を導入した。%リモートホスト同士の接続の際のエディタからのIPアドレスの入力などの煩雑な操作をなくし、ユーザ操作を簡略化した。%さらにこUIの排除により、エディタ側への実装の負荷も軽減した。 Session Managerはそれぞれのコンピュータに1つずつ存在し、エディタはデフォルトのSession Managerへの接続操作を行うだけよくなった。リモートホストとの相互の編集を行う際にはSession Manager同士を接続し、Session Managerを介して編集を行うプロトコルに変更し、実装した。 REPではエディタ同士の編集の衝突を解決するために、エディタ間でのデータの不整合を解消するマージの導入を行っている。 以前までのマージアルゴリズムは、1対1の通信に対応したアルゴリズムであったため、これを複数人で同時に編集を行うアルゴリズムに変更した。 また、以前のプロトコルではマージの処理をエディタ側で行っていたが、マージの処理はREPのプロトコルにおいて共通の機能であるため、Session Manager側へ実装することが望ましいと考え、Session Managerへ移行した。 %これらのプロトコル改善により、ユーザの入力処理の煩雑さを軽減させた。 %また、REPを実装する際の負荷を軽減し、実装手法の確立を行い、様々なアプリケーションへの実装を促進させることを狙う。 %マージに関しては、初期の巡回トークンを用いた手法、さらにNOPを挿入する手法、ACKを巡回させる手法の三つの手法を実装した。 しかし、マージの処理をSession Manager上で行なうために、マージコマンドとエディタコマンドとの間に衝突が起こる可能性がある。マージの処理をしている最中にユーザが入力する可能性があるためである。 この問題点の解決方法についても考察する。 %これらのプロトコルはかなり複雑であり、正しく動いているかの %検証が欠かせない。マージアルゴリズムの検証方法については、PathFinder %を導入して検証を行なった。PathFinder用には独自のNetworkSimulator %を導入し、直接ソケットを呼び出すことなくPathFinderによる検証を %可能とした。 %また、様々なEditor上のREPの実装を助けるために、 %デバッグツールとして %Java版簡易エディタを導入している。