[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1198] オブジェクト指向の OS への適用(Re: スケジュールについて)
隆一です。
# 長いです。
From: Hideaki Suzuki <h1suzuki@bridgew.edu>
Subject: [b-free: 1192] Re: スケジュールについて
Date: Mon, 30 Mar 1998 23:56:18 -0500
> まあ、大抵は、お互いの誤解なんですが、、、。
誤解、というか、スケジュールの話をするときに、オブジェクト指向 OS にし
ようというのは、読み筋が違っているのではないかと。
確かにこーゆー話はしていて楽しいです。けど、実装に入った段階でする話で
はないのでは? それをするなら、「今の B-Free OS はダメダメだから、一か
ら作り変えよう」ということを言わないと。
> Ryuichi Naitoh wrote:
>
> > > というあたりでしょうか。
> > > こう云った大きな program(OS) では、topdown と bottomup を同時にやらなければ行け
> > > ないので、しんどいのですね。<と分かり切ってることを繰り返してみる。
> >
> > えっ、トップダウンでやっているところって何かありましたっけ?
> > 確かに話はたくさんしていますが、実際にモノを作ろうというところまでいっ
> > ているのはまだないと思いますよ。
> > # いや、アプリケーションレベルでいうと落合さんの作られているフリーキャ
> > # ビネットがありましたか。
> >
> > ボトムアップ的というと、中心核から順々に作るという作業は細々ながら動い
> > ていますから、たしかに何かしらの作業はしていますけど。
> >
>
> 実際にやっているという話ではなく、design の中での、topdown-bottomup です。
うーん、デザインですか?
> > うーむ、というか先のメイルで私が書いたのは、結局のところ、「手を動かす
> > 人がいない」(からいつまでたってもモノができない)ということなんですけど。
> > レイヤ分けということでは、一応周辺核のレベルまでは機能別に分離していま
> > す。
> > 問題は、その周辺核を作るという作業が実質進んでいないということで、これ
> > はオブジェクト指向を使えば簡単にできる、というものではないです。
> > 結局、オブジェクト指向は技術にすぎないので、プロジェクトでの遅れをとり
> > もどすために、オブジェクト指向を使うというのは無理でしょう。
> >
> > 結局、ここでも「銀の銃弾(silver bullet)はない」んです。
> >
> > いや、オブジェクト指向で OS を書こというアイデアはいいんです。
> > ただ、実際にオブジェクト指向言語の元で OS を実装というのは簡単ですが、
> > どの位の作業量になるか考えています?
>
> まず第一に、OOP にするかどうかで、Manager の割方とか、全部、違ってきます。何故かという
> と、それが、OOPだからとしか、、、、。(笑)
それそれ、そこをちゃんと説明しないと。
まず、前提としてオブジェクト指向が優れているということがあって、そ
こが議論の出発点になっていませんか?
Manager の割方が違ってくるということは、OS の全体の構成を変えるという
ことですよね? その構成を変えるためにはどのくらいの労力が必要になるで
しょう?
> で、みんなが、OOPにしようとか突然(というか最近)言い出したら、Manager 作る人は、
> 「一寸待った。それじゃあ、実装をどうしようか?」ということになると思ったのです。
はい、その予想は正しかったと思います。
メモリマネージャを作っている人(つまり私)が、「一寸待った。それじゃ、実
装には、これこれの問題があるけど、どうしようか?」と言っているわけです
から。
# GCC の話なんかは、まさに「実装」だ。
もちろん、オブジェクト指向言語には色々利点があると思います。ただ、その
利点は OS の作成においては、あまり目立ってこないと思います。ましてや、
スケジュール問題の解決にはとても役に立ちそうにありません。
> # 単に人手かもしれませんが。(暴)
> 第二に、Object Oriented には、最低二つの level があると思うんですね。一つは「OSをO
> O化する。」これは、ここで話していることです。もう一つは、「OSの上に、OOPな言語を
> 被せる。」これはたぶん、Night さんが話していることだと思います。
私の書いたのは OS をオブジェクト指向言語でオブジェクト指向の機能を使っ
て記述する話とアプリケーションレベルのクラスライブラリの話です。
OS をオブジェクト指向化するというのはいろいろ視点があると思います。そ
の中にはオブジェクト指向の機能を使って、オブジェクト指向言語で書くとい
うのも含まれるでしょう。
> で、OS自体をOOにするには、また、いろいろと考えなきゃいけないことがあるでしょうし、
> 現在の B-free は明らかに、OOとしては作られていないわけです。
>
今の B-Free OS のデザインは、非常に粗いレベルのオブジェクト指向とも言
えますよね。
オブジェクトとして各マネージャがあって、オブジェクト同士のメッセージ通
信によって処理をしているわけですから。
# しかも、各マネージャは ITRON のタスクとしてそれぞれ自律的に動いてい
# ますから、並列オブジェクト指向になります。おぉ、なかなか時代の最先端
# ではないですか ^^)
> 実際には、(もしOOにすると言うのなら)
> 1.class 間の関係で、OSの内部を理解(再認識)する。
> 2.class 間の関係から、class に必要な interface を定義する。
> 重複があれば、継承や所有による単純化を考える。
> 3.interface と class から、module を考える。
> module は、class の為に何を提供したらいいのかを考える。
> class が module のよりどころになる可能性あり。
> 4.module の提供する物が決まれば、自然と、内部でとれる
> 選択肢が限られてくる。
>
> こんな感じです。
えーと、これだと全然イメージが湧かないのですが、もう少し具体的に説明し
ていただけませんか?
想像するに、すでに非オブジェクト指向な OS があるという状態で、オブジェ
クト指向言語で書き換えるということを考えているみたいですね。
単に処理をブロック毎に分け、ブロック間のインタフェースを制限するだけな
らば、オブジェクト指向である必要はないと思います(というか既存の構造化
プログラミングの範疇に入ってしまう)。OS が使うデータ型で親子関係にある
ものが少ないことを考えると、継承というオブジェクト指向言語の機能も使う
必要もないですし。
また、OS のすべてをを言語レベルでクラス分けして、そのクラス間のデータ
のやりとりはメソッド呼び出しで行うという話ならば、全体としては旧来の
Monolithic 型の OS になってしまいませんか?
(Java OS はどうだったかな?)
> ただ、thread と class の関係は、Java を見れば分かるように単純ではないので、module の割
> り振りはしんどいかもしれません。
?
> > さらに、オブジェクト指向の場合、ライブラリ化が重要になります。このオブ
> > ジェクト指向のライブラリについては、使う方も作る方もそれなりの労力がか
> > かります。使い物になるオブジェクトライブラリを作るには、2、3年かかるで
> > しょう。ソースの量も、数万ステップを越えるものになります。
>
> この件については、OSがOO化された場合、大分低減されると思います。
そのココロは?
OS が OO 化されたからといって、自動的にクラスライブラリが作りやすくな
るとはとても思えません。何か作りやすくなるような理由があるのでしょうか?
今回の議論では、クラスライブラリの対象として、アプリケーション側のクラ
スライブラリと OS 側のクラスライブラリの 2 つがあると思います。
OS 側のクラスライブラリは、それ自体 OS をオブジェクト指向で作る作
業に含まれますから、OO 化された後で楽になることはないですよね?
もうひとつのアプリケーション側のクラスライブラリについては、OS がオブ
ジェクト指向だからといって、作成の手間が減るとは思えません。なぜかとい
うと、内部がオブジェクト指向で作ってある OS でも、アプリケーション側か
らは、OS の内部構造は見えないからです。逆にいうと、API がオブジェクト
指向的ならば、OS の内部が非オブジェクト指向的でも、アプリケーションか
らは OS がオブジェクト指向のものとして見えるでしょう。
オブジェクト指向の言語で書き、アプリケーション側からもその OS のオブジェ
クト指向の機能を使っているものがあります。しかし、それらは単一言語系の
もので(Lisp マシンとか Prolog マシン)、汎用なものではありません。
中身をオブジェクト指向の OS というと、何があったかな? 少なくとも研究
室レベルではいくつかあったと思いますが。。。
# Spring はそうだったのかな?
> > 実際、C++ により OS を書き換えるというのは、UNIX でも試みられたことが
> > あります(system V の後継)。しかし、最終的には C++ への書き換えは失敗し
> > てしまいました。このときは、SUN と AT&T の技術者が共同で作業したはずで
> > す。AT&T といえば、C++ の総本山で、C++ に詳しい技術者もいたはずです。
> > しかしながら、そういうところですら OS を C++ で記述することに失敗した
> > わけです。
>
> うーむ。内部構造から、洗い直したのでしょうか。それとも、、、、。
> ちょっと、どういう目的の書き換えだか分からないので、comment を控えます。
もちろん、AT&T が具体的にどういう作業をしたのかは分かりません(失敗した
プロジェクトだし)。昔の UNIX Magazine の Bill Joy のインタビューを読ん
だ限りでは、ほとんど作り直しに近いことをやったみたいです(部分的な改良
ではない)。
目的としては、Unix の決定版! を作ることだったということですが。
> > また、API (実際にはライブラリになると思いますが)、にオブジェクト指向を
> > 使うことも懐疑的です。アプリケーションを書く時に使いものになるオブジェ
> > クト指向のライブラリを作るのは、非常に大変な作業になります。
>
> BTRON2 の API は、関数の多重定義などを使い、対象を実身・仮身として抽象化し、かなり、O
> Oな気がします。
>
> # BTRON2 は実装が困難を極めて、棚上げになったという話も、、、。
坂村先生自体はオブジェクト指向が好みじゃないみたいですね ^^)
BTRON2 は、Generic 関数としての API がありますが、ちょっとオブジェクト
指向とは違う気がします(クラスもないし、もちろん継承もない)。
データ抽象レベルのものではないですか?
> > オブジェクト指向のライブラリは、個々の関数がクラスという関係でつながり
> > があります。個々の関数のことを考えればいいライブラリに比べ、クラス階層
> > という別の見方でも考えなければいけないオブジェクト指向ライブラリを構築
> > するのは、作り直しを何回も行う必要があるでしょう。MCF などを見ると、何
> > 回作り直されたか。。。。
>
> 作り直しが、App に影響しないと言うのが、OOPの見せ場ですが、、、。まあ、初期段階では
> 作り直しは必要ですね。;_;
しかも、作り直しには、ある程度使われたフィードバックが必要になります。
確かにインタフェースを変えなければ、内部を作り変えても大丈夫というのが
オブジェクト指向の長所ですが、クラスライブラリのクラス階層を変えるよう
な大きな変更には、やっぱりアプリケーションも影響が出ます(というよりちゃ
んとやるには、アプリケーションも作り直しが必要)。
> 追伸:
> 実際の OOP の Programming の課程は、「C++ プライマー」の "Template Class の設計" の
> 章が、とても分かり易い導入になっていると思います。僕は、OOP と、C++ の多くを、この本か
> ら学びました。結構真剣に読むと、時間が掛かる厚い本です。そのあと僕は言語に対する興味
> (その当時、Programming Language にすごくはまっていた)から、「注釈 C++」に行ってしま
> ったけど、、、。<こっちは、OOP を学ぶ本じゃない。
>
C++ プライマーは、新版が出ているんじゃなかったでしたっけ?
日本語訳があるかは知らないです(トッパンから出ていたかな?)
Stroustrap の書いた C++ の本も第 2 版には、クラス設計というか C++ 言語
でのプログラムデザインについて書いた章があったと思います。
ただ、ちゃんと使われるクラスライブラリの設計、というのはなかなか定式化
できないのがつらいところです。本を読んでそのまま設計したから、OK とは
いきませんから。
オブジェクト指向でない構造化設計については、かなり実用的になっているみ
たいですが、オブジェクト指向の設計法となるとなかなか。。。
一番欲しいのは、C++ 版の「ソフトウェア作法」なんですが、なかなかそうい
う本はないですね。
p----------------------------------------------------------------------q
| FROM R.Night |
| E-mail: |
| rnaitoh@st.rim.or.jp |
| Key fingerprint = 89 EB 77 95 40 C0 3C CC 37 A1 A7 FA 1C 66 FF D0 |
b----------------------------------------------------------------------d