こんにちは、赤坂です。
# いまだに表題の理由がきになっています…
On Mon, 08 Apr 2002 10:37:35 +0900
Hidehiko AKASAKA <*******@***.***.*******.**.**> wrote:
> > 平鍋です．
>
> > > 複雑な場合はイベント分析をするのが正論でしょうが、
> > > きっと樋下さん(および開発される皆さん)は頭の中にしっかりあるのではないか
> > > と思ったので、これもあえて省略しました。
>
>
> > なるほど．実は，Realtime UML の第2版からコンテキスト図が消え
> > ています．この理由，先日のUMLフォーラムで Bruce P. Douglas
> > に聞いて見ました(答えは秘密です)．
>
> 第2章要求分析ですね。
> コンテキスト図、イベント 分析がごっそり無くなってますよね。
>
> > 私自身は，組み込み系でのクラス抽出(オブジェクト抽出)には，コ
> > ンテキスト図が一番と思っています．
理由はいまだ謎のままですが…
今月号(2002.6)のInterface(http://www.cqpub.co.jp/interface/)の
連載記事"組込みプログラミングノウハウ入門"
「組込みにおける要求仕様書について──上流工程」藤倉俊幸氏
で以下の様に書かれていました(入力源の特定・分析 page.156)。
| ダグラスのReal-Time UMLの初版では、構造化分析のコンテキスト図を
| ユースケースに取り込んでシステム外部の記述によりユースケースを補
| 強していたが、日本語訳が出ている第二版でコンテキスト図をやめてし
| まったのは、組込み的には後退である。
また、
| 入力アクタのその先に何があるのかをたどることでも、並列性の本質的
| な部分を分析できる。アクタの先を考えることと、ビジネスモデリング
| やドメインモデリングとは似たようなものである。
僕も藤倉さんのご意見の通りだと思います。
# あぁ、そろそろ理由が知りたいな〜(^^;;
P.S.
ちなみにこの記事は、主に組込みシステム開発向けの要求仕様書の書き方について
書かれたものですが、
システム全体としての仕様がないための事故の例(仕様なき設計)：
・高速増殖炉「もんじゅ」の温度計破損によるNa漏れ事故
・名古屋空港での中華航空機墜落事故(エアバス)
などの事故原因がシステム全体としての仕様の不備にあったことなどが
紹介されていますし、
システムがどのように人を扱うか：
・ユーザ中心デザイン
・ユーザ巻き込み型デザイン
後者は、ユーザーはオペレータではなく熟練することを前提としてシステム外部の
モデルの中に取り込むといったものだそうです。
と、組込み関係以外の方にも興味深い内容になっていると感じました。
ご参考まで。
--
赤坂 英彦 (Hidehiko AKASAKA)
*******@***.*******.**.**