［Booch法 言いたい放題］
Booch法のお気軽な紹介を座談会風に語り合うページです。
Rational RoseがVer 2.0までは、Booch法だけをサポートしていたことをご存じでしょうか？
以前からRoseの販売をやっていた弊社にはBooch法の信奉者がたくさんいます。
彼らの熱い思いを是非聞いてやってください。
Booch法のいいところ 発明と発見 私がみたい幻のCaseツール 雲の気持ち 美しきかな Booch法の可視性 ホワイトボードの陰謀 お宝募集! クールな定規 やっぱりOMTが好き！ ビジュアル系モデルなら・・・Booch法 Booch法ってUMLだったのね... シブさの限界 Booch法の多重度は最高！ いろいろ議論はあるでしょうが
※Booch法で描いたクラス図をご覧になったことのない方は、下の赤いボタンを押してください。
Booch法で描いたクラス図 - 例 -（GIF, 9KB）
Booch法といえば誰もが思い付くのがあの雲ですね。手書きでも書きにくいし、通常のグラフィックエディタにもあんな図形は用意されていないし、Roseを買わせるための陰謀か! などと思ったものです。
が、あの表記、メリットもあります。オブジェクトの関連を直角でなくいろいろな方向にはっても、図がそれとなくまとまってみれます。四角ベースだとどうしてもきちんとならべるのが大変になっちゃう。
(俺は直角）
 |
ページのトップへ戻る |
Boochといえば、あの雲。
夏のバカンス。高原の日々。どこまでも澄み切った青空をみて、ふと、この大空に存分に雲をおいてモデリングがしたい! と思ったことはありませんか?
そのような夢をかなえてくれるのではと期待させてくれた、幻のCaseツールが昔存在しました。
その名も "Clouds in the Sky" !! (そのままだ。。。)
子供たちのためのモデリングツールという斬新な発想だったのです。
https://www.rase.com/research.htm
残念ながらプロジェクトは凍結してしまっているようです。UMLになってしまっては、この粋なネーミングも意味をなさないですしねぇ。。
(マシュマロマン)
|
ページのトップへ戻る |
もはや「クラスカテゴリ」の概念などは UML に吸収されてしまっているので、ここで取りたてて持ち上げることは少ないかと思いますが、私が Booch の記法で最もお気に入りだったのは、やはりあの可視性表記でしょうね。
| 可視性レベル | Booch | UML |
| public | . | + |
| protected | | | # |
| private | || | - |
| implementation | ||| | . |
もう何も言葉を必要としない美しさですね。
ソフトウェアの講演なのか建築学の講演なのかよくわからないような先日のセッションでも、しきりに統一された美しさを強調していた（ように私には聞こえた）のがうなづけます。
+ とか # とか、なんだそりゃっっ、って。
とりあえずは、このくらいで ...
(Simula68)
|
ページのトップへ戻る |
Boochといえば、そう、やはりあの雲。
その昔、RoseがまだUnix版しかなかったころ、Rational社は、Boochの雲が簡単にかけるクールな雲形定規をくばっていました。
雲だけでなく、「保有」や「使用」(おおなつかしい響き)も書けるようになっていてなかなかいい仕事をしてました。
ピンク色(多分薔薇の連想でしょう)でペラペラしていましたが、新人のときこの定規を渡され、自分もいつかこの定規を小脇に抱え(あるいは耳にはさんで)設計者としてお客さんのところに出向いていくのだろうか。。 と思ったものです。
そんな思い出の品。あろうことかなくしてしまいました。
どなたかお持ちのかたは? 保存状態がよければいまなら1000円で買います!
(Smalldealer)
|
ページのトップへ戻る |
Boochから他の表記法に移ったときに少し不便に思ったのは、
モデリング要素の主要なプロパティがバックグラウンドの情報にしか記述されず、
図に表そうとすると、ノート連発にせざるを得なかったこと。
例えば、逆三角Aの抽象クラスとか、static 指定
とか
また、少しパッケージ数の多いパッケージ図などを描いて、
依存関係の線がやや込み入ったような図の場合、
（白丸＋直線）の依存関係の方が点線矢印よりも見やすい気がするなあ、
と感じたりしました。
(8man)
|
ページのトップへ戻る |
抽象世界から実体世界への移行が、
点線アイコン、実線アイコンの対比で表されるところが
シブイ... とか
(kiroro)
|
ページのトップへ戻る |
関連は分析や初期設計モデルで用い、
詳細な設計モデルでは、単方向の「保有」や「使用」関係などに
洗練される、といった考え方がわかりやすいように思いました。
(kiroro)
|
ページのトップへ戻る |
キーとなる抽象(key abstraction)を識別するためには、
発見と発明(discovery and invention)という２種類の活動が必要であり、
分析/設計の前半ではdiscoveryが、後半ではinventionが優勢となる、
といったようなところを読んだときは、
なるほど、とうなずかされたような気がします。
このような短いことばにオブジェクト識別やイテレーティブなやり方の
１つのポイントが凝縮されているようで。
(8man)
|
ページのトップへ戻る |
やはりBooch法のよさは、
クラスとインスタンスのメタレベル階層を
破線アイコンと実線アイコンで目に見える形で区別していることでしょう。
これによって、オブジェクトAといってもアイコンを見せれば
概念としてのクラスAなのか、具体的な実体のひとつとしてのインスタンスAなのか
迷うことがない、という点で非常に優れた教育的なビジュアル記法だったと思います。
もう１つ重要なのは雲型のクラスアイコンですが、わたしの評価はもう少し練れば
きっといまのUMLでも使われていただろうに、という残念さです。
すなわち、ブレーンストーミングレベルの見取り図・概念図として対象領域を
「なにか」とそれらのあいだの意味的「つながり」という「グラフ」で表わすときの
「なにか」というノード表現として「雲形」をとっておけばよかったのに
という思いです。
せっかく曖昧な輪郭をもつ雲形のアイコンを導入したのですから
それをまだクラスとして確定していない、属性にも関連にもクラスにもなりうる
概念レベルの対象を名指すのに使えばよいだろうに、と常々思っています。
実際、わたしは正式なクラス図としてOOAモデルを作る前に「ポンチ絵」と称して
問題領域を広くおおざっぱに捉えた概念マップを描くことを心掛けていますが
その際にそこに識別された各ノードが特段クラスを表現しているわけではないから
誤解しないでね、ということを強調したいことがしばしばあります。みなさん、
思い込みが強いですからね。そういうときには雲型アイコンの登場と相成るわけですね。
ですから、私が雲を描いてたら、その気持ちを汲み取ってくださいね。
(Mr. WHO)
|
ページのトップへ戻る |
その昔、アメリカでコンサルタントの方からBooch法のトレーニングを受けたことがあります。
テキストの「雲」は立派なのですが、コンサルタントがホワイトボードに書く「雲」は、うにゃうにゃくしゃくしゃ...右上と左下をつまんで引っ張ったような形になっていました。
CASEツールも雲形定規も使えないホワイトボード...UMLのクラスが長方形になったのは、コンサルタントの意見が反映されたからじゃないかと勘ぐっています。
(6a)
|
ページのトップへ戻る |
Booch法に対して思い入れの強い人ってたくさんいるんですね〜。
私のようなOMT派からすると、Booch法って紛らわしくて困ります。
誰がなんと言おうと、関連の多重度は●と○が最高だったのに、Booch法が違う意味で使ってたりするから、UMLで採用されなかったんですよ、ホントに。
(a-ha)
|
ページのトップへ戻る |
第２版Booch法の本を始めて読んだとき、ずいぶん節操がないな、と思った記憶があります。
何しろ、関連はOMTで、ユースケースはOOSEで、他にもCRCカードやら何やらで、方法論の寄せ集めみたいに思いました。
でも今から思うと、Booch氏はあの頃からUMLを目指していたんですね〜。
「Booch Method = Unified Method Ver 0.7」ってところでしょうか...
(a-ha)
|
ページのトップへ戻る |
Booch法で一番よかったのは関連の多重度で
0..n と 1..n
の区別がしっかりしていたところですね
0..n なら後から関連を付ける
1..n なら最初から関連を付ける必要がある
のように
UMLは 3..* で「3つ以上必要」ということは判っても
最初に関連が必要か、あとからでもよいかが
よくわからないです（ノートで書くんですよね）
(Mt.Fuji)
|
ページのトップへ戻る |
| © 1999 OGIS-RI Co., Ltd. |
|
