Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.CheapestOnlineUSpharmacy(2008-05-17 14:27)
2.Kir(2008-05-08 15:52)
3.Hero(2008-05-06 16:49)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
ソフトウェアの「インタフェース」にまつわる、もろもろの呼び名について、以前から一つ気になっていることがある。今回はそれに関する お話を。
■ 「インタフェース」にまつわる既存の用語を整理・図示してみる
まず用語を整理するところから始めよう。ユーザに対するインタフェースにはGUI(Graphical User Interface)とCUI(Character User Interface)があり、かたやプログラミングのインタフェースとしてはAPI(Application Programming Interface)というものがあり…というのを図にしてみると、こんな風になる。
だが出来上がった図を見るとなんだか、しっくりとこない。そもそもUIのとなりがAPIというのはどうも座りが悪いのだ。APIの定義 は、例えば
（APIとは）標準化され、文書化されたプロトコルとデータ構造のことを指す。APIは外部のソフトウェアアプリケーションによ る、一 次(primary)ソフトウェアシステムへの一貫性のあるインタフェース(consistent interfacing)をサポートするものである。
(BBN Technologies Glossaryより、やさぐれ訳)
にあるように、（大まかには）外部に提供することを意図したプログラミングインタフェースのことを指す。だが実際のプログラムでは、外 部から使われる部分だけでなく、内部に閉じた部分でもインタフェースを意識する必要がある。具体的には一般に公開することのない箇所でも、例えば構造体や 関数、あるいはクラスやメソッド、などをきちんと定義し、それを使うということだ。しかしその「内部向けプログラミングインタフェース」 に対 応する名前というものを僕は今までに見たことがない…
■ 図の修正と新しい用語の導入
…ということを考えながら書き直した図がこれだ。
PI(Programming Interface)とか、IPI(Internal Programming Interface)とかいう、怪しげな名前を捏造してしまった。でも少なくともUIのとなり にくるなら ばPI(Programming Interface)というのがあってもいいんじゃないかな。で、APIはその下に座るという構図は、バランスとしては正しいように見える。
問題はIPI(Internal Programming Interface)という名前だ。ここはAPIとバランスをとるならばSPI(System Programming Interface)とするのが妥当なのかも知れないのだが、APIが事実上「外部プログラミングインタフェース」を意味するのに対し、SPIでは「内部 プログラミングインタフェース」という印象を持たせにくいことから、ここでは仮に"IPI"としている。
■ まとめ
ともあれ、今回の話で言いたかったのは、
ということ。IPIという名前自体は必要ならば後で修正すれば良いが、少なくともPI(Programming Interface)という呼び名と、その下に展開される階層構造は、UI(User Interface)に対置する存在として必要なのではないかと思う。いかがだろうか。
文字通りのツッコミになりますが、CUI/GUIに相当するのは（函の位置を合わせている点から考えると）リモートインターフェイスとローカルインターフェイスというような区別になるのではないでしょうか。CUI/GUIと同じ層に見えるのは違和感があります。
IPIはむしろ、GUI/CUIとは別にUIの中でSI（system interface−でたらめな名前ですが意図はsyslogへの書き出しや管理インターフェイスなどinternal UIかなとするとGUI/CUIはpublic UI）というのを置き、そこと対応するように思います。
UI | PI
I-UI - P-UI | I-PI - P-PI
N/A GUI CUI | ?
ツリーのノード間の意味的なバランス(対称性)を確保しようとすると厄介なことになるので、しばらくはごまかそうかと思っていましたが、やはりそうそう簡単にはいきませんよね ;-)
それはともかく、いただいたツッコミについて、しばらく考えてはみたのですが、まだすぐに決定的な答えは出てこない（というか、そうあるべきなのかも）という状態であります。ただしこのまま忘れてしまうことは決してないはずで、これから時間をかけて探っていくことになるのでしょう。
現状で思うところをあえてダンプしてみると、こんなところでしょうか。でも来年あたりになると正反対のことを言っているかもしれません。 :)
a)内部向け(Internal)と一般・外部向け(Public、もしかしたらExternal)という
概念でUIを区分けするのは妥当かどうか、分からない
(Programming Interfaceとの対称性は確保できるのは確かですが、
直感的にまだしっくりこない)
b)「syslogへの書き出しや管理インタフェイスなど」という視点は確かに加える
余地があるかも知れません。例えばUNIXのストリームを対象にした
読み込み/書き出しについて、そのプロトコルやファイル形式を指して
SI(System Interface)と呼んでしまうというのは、もしかしてアリかも。
一方で「管理インタフェース」というのが、管理者向けのGUI/CUIを指すならば、
それはa)に述べたように(Internal/Publicの区別をしない)GUI/CUIに含めて
しまうのが妥当かなと思う次第です。
この件については本格的に考えようとすると、
1)「インタフェース」と呼べるものには何があるかを洗い出す(ここで結構モメるかも)
2) それを整理・分類する(上よりもさらにモメるか)
という手順をふむことになりそうです。その過程で怪しげな用語が沢山生まれそうですが、それもまた面白いかと。用語の多くはどこかの時点で淘汰されるでしょうが、残ったものが、ものの役に立つということもあるかもしれない、と思っています。
僕も少し考えてみましたが、内部向けUIというのは確かに定義そのものが矛盾していたかも知れません。UIはプログラム外部に対するものなので内部向けといってもUIはUI（a）。
どのような実例があるか考えてみると、Webサーバーの管理画面とサーバー上のアプリケーションの画面（しかしこれは異なるアプリケーションがたまたま1つのプロセスになっていると見たほうが正しそう）、デスクトップアプリケーションで特殊なキーシーケンスでポップアップする開発者用のダイアグ用ウィンドウ（あまりにも特殊な事例のように感じる）、それから（B)に分類されると思いますが、Windowsでのレジストリ、Javaのリソースバンドルなどの外部パラメータ（これらはプログラムからはAPIを利用するとしても、設定する人間にとっては、そのプログラムとのUIのうちではないかと思える）、最初に上げたsyslogなど。
ところが、これらはいずれも、そのインターフェイスを操作する主体との関係を示しているに過ぎないので、プログラムの持つインターフェイスという意味では怪しげな分類なように思えてきました。
#確かにインターフェイスに何があるか、どう分類するかが肝だというのは納得です。が、確かに面白い。