MoriokaWorkshopReport

SeamaHVol.6 , No.8-9-10・ 11

5. 中間発表

1.PWB&Hyperbook グループの発表

90

2.00A/OOD グループの発表

9
2

3.CASEBench グループの発表

9
3

4.StP グループの発表

9
6

5.Team.work グループの発表

9
6

6. 全体の感想と討論

98

‑89‑

F

MoriokaW orkshopReport

SeamanVo1. 6 , No.8-9-10・11

中間発表
報告者

中尾博司・方学芸(静岡大学)

中間発表の討論の経過を時間順に報告する.

1.PWB& Hyperbook グループの発表
われわれは，まず課題の中から，ガス給湯システムを選択しました.図書館システムにしょうかという案も出たりして，途中いろいろ考えたんですが，多分内容の説明が詳しい方が簡単だろうということで，ガス給湯シス
テムを選択しました .

問題を最初眺めたときは，手がかりがまったく掴めませんでした.そこで，モデルを選んでみようということになりましたPWB では，昨日の説明にあったように. 6 つのモデルが用意されています.まず，最初は(難しい) FSM モデルから入るのがふつうだという話が出て，システムの機能構造のモデル化を試みました.

しかし，実際に考えはじめてみると，なかなか理解しがたく，構造記述がうまく行きません.それでは他のモデルで試してみようということになり. EOPM モ デルに移りました.そのほうが書きやすいのではないかと思われたからです.これは，システムをユ ーサ'の立場か らモデル化するものです . 具体的には，状態遷移図を書いて行くわけですが，これもなかなかうまくいきませ んでした . 全体の書き方がよくわからなかったのです.
そこで .給湯 システムを 3 つの部分に分けました

給湯する部分(図1)と，お湯はりする部分(図 2) と追いだき部分(図 3) です.みんなで各部分ごとに状怒遷移図を作成して. PWB に入力しました.

年)

伯尚 o rt'る
国 1給渇する部分 (PWB)‑90‑

SeamallVol.6 , No.8-9-10・11

MoriokaWorkshopReport

おiJ..l はり，<ィ，ミス 1f

θ-6Y
国 2

I~ I

お湯はりする部分 (PWB)司、，，'< J))Il ) tJI H~ r I;lI H2)， <ィ，ミスヲ f I~I
1 イッチ OFF燃 m ;:ilI! V~rl1i

o
r1
0
01
1

¥‑

2) バイパス弁 I~ I
3) ランプ O ド ド~ )比例す r J:ll

\1 ) 燃悦ランプ OH\\〆ム勿ねh ………v状Jλ;/一予/一一守
T…イツチOHI~

1)J
r1;11 怜2) バイパスヲ f 1<13)川 16 ランプ O H
.nl~~

-、

1 ) 刷 1 正 ~~~~ .!l!

I~ iV
,I ~ ""(
1
1)1
f1 11 付¥¥¥!)バイパス 1 r" 1:
11
jD しだきスイッチ O H I
1):~11 込ラノプ a1 す 1)μ l正投泌氏 止l

国 3

遣いだき部分 (PWB)‑91‑

SeamaﾟVol.6 , No.8-9-10・11

MoriokaWorkshopReport

ツールの操作に慣れていなかったので，なかなか仕事が進まず.入力し終わった時点で予定の時闘がきてしまいました. PWB にはなかなかよいアニメーション機能が用意されているので，それを使って一応の動作を確認しました.
さらに，この状態遷移図が本当に正しいかどうかを検討したかったのですが，そこまでの時聞はありませんでした . 以上です .
落水浩一郎{静岡大) : 状態遷移図をちょっと説明していただけませんか?

PWB: いや，まだあまり検討していないので，あとで検討がすんでからの方が.議論がより豊かなものになると思います.

2.00A/OOD グループの発表
われわれのグループもやはり給湯システムを選ぴ， OOA ツールを使つての分析を試みました . われわれが今回目標にしたのは F 昨日の青木さん (FXIS) の話にあったオブジェクトの確定 ・ 属性の定義 ・ サービスの定義という段階までです.今日はこのうちの確定作業から始めたのですが，ご覧になったようなところまでできました(図 4) .次にオブジェクト聞に Îs-a 関係と has-a 関係を定義しました.三角がついている線が has-a 関係，丸がついている緩が Îs-a 関係を示します.

国
自

3

拶
す

し、

そ

国 4

確定されたオプジェクト (OOA/OOD-l)タ

苦労をした点ですが ， 湯わかしシステムには沢山の名前が出てきます.問題に直接あらわれる名前は簡単に決定できたんですが，抽象化することで得られる概念，たとえば，スイ ッ チ群に対して，それらは状懸を 2 つ持つので . バイナリ ・ ステイトという上位のオブジェクトを認識する，これがものすご く 難し く て，イ ン ストラクタの青木さんの顔色を窺いながら，いろいろキイワードをポンポン並べ，難しい顔をした場合には取り下げ，当ったものを案とするよ う な結果になりました . 残りの部分は完成度が 多 分まだあまりよくないと思います .
あえず，現在の合意を形にしよ う とい う ところまで行きまして.中間発表にしました

‑92‑

とり

てコ

た

MoriokaW orkshopReport

SeamallVo1. 6 , No . 8-9-10・ 11

浴糟が一人寂しく孤立しているのですが，これが明日の発表までにどんな風に変って行くか，それとも消えているか，何となくわからない部分が残っていますが，そのへんがポイントだと思います

人数が多いので，グループを 2 つに分けたのですが，もう 1 つのグル ー プもまったく同じ問題と同じツ ー ルを使っています.

最初に進め方を議論しました . 詳しく中身を読んでからやろうか，それともオブジェクトとしてのキ ー ワードを取り出してからやろうか，ということをまず話し合って，その結果，キーワ ー ドからオブジェクトを決めて行
くアプローチを採用しました

一応キ ー ワードを 4 人で考え，どういうものがあるかを決めました(図 5) .今のところ，まだ is - a 関係までしかできていません.

国 5

確定されたオプジェクト (OOA /OOD ・ 2)

3
.CASEBench グルーアの発表
われわれのグル ー プが選んだ課題は，酒屋倉庫問題です. CASEBench のデ ー タフロ ー 図から構造図への変換機能が強力であるということを信じて，明日の昼までにゆっくり完成しようというふうに考えて進めていま
す，

まず，今日綾初にやったことは要求内容の検討ですが，問題の中の「受付け J というのは実は在庫管理じゃな
いかとか，倉庫という言葉があるがこれは実は運搬係じゃないかとか，課題に文句をつけることから始めました

その後データの洗い出しをやりました.その結果をちょっとだけ見ていただきます(図 6).
それから予備的なデータフロー図を書きましたが，この時「ピックパン」という手法だそうですが，まずデ ー

タフロ ー 図を書くんじゃなくて，とにかくバブル(処理)をまず書いて，それをあらかじめ洗い出したデ ー タでつないで行くという方法をアドバイスしていただきました.その後で，コンテキスト・ダイアグラムを書きました(図 7) .これが皆の統一見解ということになっています.

‑93‑SeamaUVo1. 6 , No.8・9-10・11

MoriokaWorkshopReport-デ ータを l却すfi!
l{,:j ~~I!

U¥
.
f
l
l
j
f
<~!n

党 1 &M1 臼 1 1:

三、

Jar

じけ

i

‘rt

空 コ ンラ ナ ìiJj ~:II:~ j 、! これ が

(
f)
i
j
[M
党 引先リ スト
il日品名

不足辿柿

j
f
<~;Si指名?の- 受 付{系はれ )i\t 係 で もある

国 6

まい出されたデータ (CASE

B
e
n
c
h
)

=d

宝右右右耳仕仕+陸一度入

~古書

順~~

空コフモ竺一

納 発不

ym
区す一一一一国 7

コンテキスト・ダイアグラム (CASE B
e
n
c
h
)

‑94‑

MoriokaWorkshopReport

SeamallVo1. 6 , No.8-9-10・11

現在，コンテキスト・ダイアグラムはパージョン 1 ですが，第 2 階層までできました(図 8) .その後でデータ辞書を登録しました(図 9) . 私がやったのではありませんが.入力が大変だったそうです.内容については，このあと第 3 階層まで詳細化して，みんなでレビューし，正当性を検証しようと考えています .

依頼者名寄

、

在府珂=足リスト

コンテナ

国 8

データフロー困 (CASE B
ench)

コンテナ= コンテナ番号+ {品名千数量)
依頼者名簿= 依頼者番号+依頼者名+依頼者住所+依頼者電話番号
空コンテナ通知=コンテナ番号
在庫=品名+ (数量+コンテナ番号)
在庫状況=品名+数量
在庫不足リスト= 送り先名+品名+数量
取引先=閥抗名+関|先住所+取引先電話番号
出庫依頼票=品名+数量+送り先名

出庫指示=注文番号+送り先名+ {コンテナ番号+品名+数量+空コンテナ+搬出マーク)
商品銘柄= 品名+品名コード
商品問い合せ=
品名+数量
入出庫内容=コンテナ番号+ (品名 +数量)
納品書=コンテナ番号+ (品名+数量)
発注書=品名+数量
不足連絡=品名+数量
国 9

データ定義 (CASE B
ench)

‑95‑

SeamaUVol.6 , No.8-9-10・11

MoriokaWorkshopReport

4.StP グループの発表
われわれのグループは図書館システムに取り組んでいます.いま，コンテキスト・ダイアグラムの入力が終
わったところです. StP が乗っているマシ ンが 2 台があるので.グル ープを 2 つに分けて ，それぞれが独 自に分析・設計を行なう予定です.いまのところ，進度は大体同じぐらいです.明日以降は 2 つの分析結果をマージして，それをもとにステップを踏んで設計を進めて行きたいと思っています.
いまできているコンテキスト・ダイアグラムは.図 10 に示す 2 通りのものです..これまでにぶつかった主なトラブルは，記法へのとまどい，たとえば入出力の線の書き方などです.それから，私のグループで特に注意した点は，たとえば図書館では，本というものが動くのではなくて，たとえば貸し出し帳にあたるもの，そのような概念をデータとして取り扱うということを，順次確認して行きました.苦労した点は記法につきます.たとえば，例外処理はどう書けばいいのか，入出力の線をどういうふうに書けばいいのか，そうしたことがらに.何しろ初めてなので，とまどいを感じています.明日の最初の作業は.今日の結果を統合して，レビューすることです
主主

Ftの限 』

貸出 ri~
メッセージ l¥¥メッセ ージ 2

*:リスト
人リスト

'duum

2 種類のコンテキスト・ダイアグラム (StP)

たるし

国 10

マ、

5
.Teamwork グループの発表
われわれのグループは制御系の経験者が多かったので，給湯システムを選択しました.まず，問題を十分認識しようということで，モデルを読みこなすという作業をはじめにやりました.そこで，ちょっとした意見の対立がありました.一方は ， ハードウェアの構成をしっかり確認したいという意見であり，他方は，システム分析を
DFD を使 ってやっていこうという意見です.結局，後者の考えにしたがって，システム分析を進めて行くことになりました.

そこで. Teamwork でデータを入力しつつ.すべて画面の前でみんなで議論しながら，問題を解決して行こうという話になりました . 9 人の メンバ全員が Teamwork に触れるよ うにしたいということで. DFD を少しづっ作りながら，オペレ ー ションを交替で行いました.こうし てできたのが，図 11 に示す給湯システムのコ ンテ
キスト・ダイアグラムです .

‑96‑SeamailVo1. 6 , No.8・9-10・11

MoriokaWorkshopReport

l

渇主

-U廿戸

幻火 {g 号

/

〆

一弁一

一一イ

¥¥

­

‑zｭ
J
J

b

j
J

g

切

ンプ{!号

/
'‑
Iz

i

j 育問
;

. 担当続{!号

j'

一一戸

:
k
.t

:
'

Eバルブ開~ *:6l:/(J.:;f

コンテキスト・ダイアグラム (Teamwork)

国 11

この段階までは，まあ順調に，割合スムーズに話し合いが進みました.ところが，この後，第 2 階層自に入っ心)たところで，ちょっと話がもめました.給湯システムを外側から見て，給湯栓に給湯する機能. ?谷清にお湯をはる機能，それから追いだきをする機能，この 3 つの主要な機能に分解しようとしたのですが(図 12) .こ れに対して，データを付けていこうとした時にうまくいかない.

ノ

tUI
'
l
!
t
・­

ib l'r.: .r，:・，

t

石f

"ゆ

…ァ

1

、.

u

‑s

/守二i:~';' ごヂ\人\可'同的信舟/ノ•.
1，，~u 叫・ーがノ~"_........

iII~'~. '、制民~......vヘぷご弘、r勺'

J女史ごミ巧二
準 ..‑‑‑‑¥

/

-可
弐 k\
「
合

闘問…館
n........{\f岱
vμFプ
¥

•

ん 'è>、 シげ7河Q'

\午/\\

国 12

3 つの篠髭分解 (Teamwork)‑97‑

SeamailVol.6 , No.8-9・ 10・11

MoriokaW orkshopReport

温度を調整する機能がそれぞれの場所にある.これはまずいのではないかという意見が出ました . また，もう少し内部実現に関わる機能を含めて考えたほうがいいのでは，という意見も出て，外側から見た機能を主体にしてプロセスを考える派と.内部実現も考慮して機能とプ ロセスを決める方がよいとい う派に分かれたわけです.
そこで，温度を調節するとか水量を監視するといったプ ロセス ， それから，お湯をわかすというプロセスもこ

こで出してしま っ た方が，下部で重複がなくなるのではないかという話が出て . ごじゃごじゃともめてしまいま
した.現時点では，まだうまい解決策が見つかっていません.明日の朝，頭が冴えたところでまた考えなおして，
どち らか を取るか，あるいはグループを 2 つに分けてそれぞれのやり方で進めて行くか決めたいと思っています.

6. 全体の患想と討論

佐原仲 (SRA ， OOA/OOD グループ):

最後の Teamwork グループのような形で発表をしていただくと，他のグループの方にも，だいたいどんなプ ロセス で事態が推移したのかがトレ ー スしやすいと思います.最終報告のときも，この線に沿って.どんな手順で，どんなところまで行ったのか，結果はどうだったのかを報告していただければ，非常にありがたいと思います . その他のグループの状況は，私には何となくが想像できるのですが，多分 他の人には あまりわからなかったんじゃないかと思 います . 最終発表では，そのあたりを考慮して発表して
く ささい.よろし くお 願いします .

野村行憲(岩手電子計算セ ンタ ー ，実 行委員長) : 思いのほか，早く発表が進んだので時聞があります.もう少し時聞がかかるだろうという想定で，このあとの「わんこそば」は. 7 時ス タートでお店にお願いしてあります
ので ，まだ，お そばはゆだっていないと思いますから(笑い) .

落水活一郎(静岡大，プログラム委員長):

一般に. CASE ツールに対する不信感が存在します.たとえば，方法論そのものが役に立たない.教科書にはいろいろ書いてあるけれども.具体的なことがわからないし ，教科 書で指定されたやり方は，自分のこれまでのやり方と遣っているので，結局方法論なんか使いたくない，ということになってしまう . また. JJIJ の形の不信感は. CASE ツール って，ただ，お絵書き機能のついたワープ ロではな
いか. JJIJ にそんなもんを使わなくても設計はできるという意見です.

私がこのワークショ ッ プを通じて知りたかったのは，ある課題を特定の方法論にしたがって. CASE ツール
を用いて解決する時に.それによって得られるメリ ッ ト，たと えば黒板に書いたり，頭の 中で考えたりする場合に比べて. CASE ツールの枠組みにしたがって，自分が考えたことをコ ンビュ ータの中にどんどん投入していった時に，その見返りとして，環境つまりツールの方から，自分自身の思考が整理されて返ってくる.そのような現象が，いつどういうところで起こるのか，そのような感想を，最後にお聞きしたいと思っています.
今 回の 発表は.全体として，順調にスタ ートしました，とにか く手 揚かりを掴みましたとい う ことなので，まだ議論できる状態ではないと思います.それにしても，単なる状況報告にとどまらず，もう少し何かを話していただきたかった感じがします.発表の後に質疑を入れるべきだったかもしれません

少し議論してみたらどうでしょう?

それとも，今日は止めにしますか?

そのあたりについて.もう今のところではまあいいじゃな

いか」という顔のほうが多いみたいですね.

佐原 :ちょっと ， いまのレベルでは，まだ CASE ツールの効果とか方法論の限界とかを云々するのは，早すぎるのではないですか?

落水:

いや，今の時点でも議論できることはあるし，またすべきであるという意味です.このまま食事に行くのでは，ちょっともったいない.他のグル ーフ・に質問をしておきたいとか，確認してみたいとか ， 何かあ るでし ょう?

たとえば . 1 番目の グル ープでしたら.なぜうまくいかなかったのかとい う質問が出て然るべきかと 思 うのです. PWB を利用す るにあたって， 一番適切なモデルを選択して進めれば ，後はまあ順調に行くというお話でしたが.モデルの選択がキーポイントなのかな?

と私は思うわけです.私がもともと理解しているのは.

PWB

は，いくつかのモデルに並行的に情報を入れながら，システムのコンセプトを作りあげていくという方法を支援するツールであるはずなので，このままではうまくいかないのではないかと.私は思います.

それから. 2 番目の グル ープ で は，バイナリ状態のオブジェクトを発見するところで，皆さんすごく苦労され

‑98‑

,

MoriokaWorkshopReport

SeamaﾟVo1. 6 No.8‑9‑10‑11

た，というお話があったかと思います.

Smalltalk との関係はどうなっているのでしょう?

Smalltalk 環境に準備されたクラス階層を Top-down にブラウジングしていって，目的のものに近いもの，またはその手がかりをみつけるというようなことはやられたのでしょうか?

3 番目の発表の中ではいろいろ考えました.大事なことは全部考えました.そのあとで，何かを CASE
ツールに打ち込みました.しかし面倒くさいですから私はやりませんでした J という発言が ， すごく印象的でした.すでにわかったことを，なぜわざわざあらためて CASE ツールに入力しなければならないのだろう，とうふうに考えていらっしゃるとすれば，それは.やはり CASE ツールを信用していないというようにも，受けとら れます .

4 番目の StP グループでは，コンテキスト

ダイアグラムを一応作られたという状態でしたねマージする Jというのはどういうことなのでしょう.全体の活動を，最後に一つにまとめあげようという意味で，おそらく，設計というよりは，グループの協調という観点から，マージという言葉をお使いになったかと思いますけれども，一見したかぎりでは，簡単にマージできるような図ではないような気がします.
それから，最後の Teamwork グループですが，このグループの発表が遅れてしまったことについては.私がちょっとお詫びしなければならないことがあります.そろそろ中間成果ができあがって，あと 30 分ぐらいでまとめに入らなければ.という時に，私が横を通ってコードを足にひっかけ.電源をポ ン と引っこ抜いてしまいま

した.申し訳ございませんでした.私のほうにそういう弱味があるので，あまりいえません(笑い).
全般的に CASE ツールを使いこなす活動に専念していくなかで，中間発表や.最終発表という節目では，事例にしたがってやってきたことを少しまとめ直してみたり.もし問題点があるなら，それを見つけてみようというように話を進めていただきたいのです.

みなさんがワークショップに参加された目的はいろいろだと思いますが，全体の共通の目標は .4 つの課題を解くというだけではなく，その問題解決過程の中で. CASE ツールを使った時にどういうところに有効性がある
か，どういうところに問題点があるか，そのへんを少し見通しを付けるということだとい う ことを忘れないでいただきたいのです.

佐原:

現状は.何がど う 役に立ったかを考える以前の状態でしょう.モヤモヤといろいろ試行錯誤している段階ですから.もう少し先に進むと，エラーチェックその他の活動が出てくるはずです.
Teamwork はそういう状態ですし ，

こちらの Smalltalk のグループはまだほとんど仕事が進んでいなくて ，「オブジェクトは何か? J を議論しているところです. Smalltalk のクラス階層とか ， あと，ど う うまくいくかという話はまだ全然出ないですね.たぶん，その見当や評価は，皆さんの中には.まだほとんどないんじゃないかと思います.

落水

そうですか. . ..

CASEBench: 私たちのグループは ，ちょっと Teamwaork グループに似ていますけれども，いま DFD をやっと作ったところです実情はまだその前の段階なんですけれども .

われわれのグループは . イ ン スチラクタの渡部さん(ソニーテクトロニクス)のご指導で，まず情報の流れに着目して，情報とは何だろうかというアプローチをしました . そうすると，比較的に順調に，一応 DFD ができあがりました.ところで . Teamwork のグループは，どのよ う なアプローチしたのか?

その辺をちょっと教

えていただきたいのですが .

Teamwork: われわれのグループも，基本的にデータの方から入りました.ハードウェアを押さえてやろうという意見は一応引っこめまして. DFD で全部分析しようということになっています.最初は私もこんがらがっていたんですが，ハードというか，物理的なものと情報の区別をはっきりと明らかにして，情報というものをベ ースにやっています . また DFD の作り方としては，システムに流れる情報が何かということについて，全員で 画面を眺めながら，誰かが案として挙げたものをたたき台にして討論するという進め方をしています . 基本的にはデータをベースでや っ てきました.

CASEBench: ぞうすると，あらかじめデータを全部洗い出したわけですか?
Teamwork: そうですね.コンテキスト ・ ダイアグラムの中で，データを全部出しつ く したということです.
CASEBench: 先ほどうまく行かないとおっしゃ っ ていましたね‑99‑

あれはどこが う まく行かなかったんです

o
.
8
‑
9
‑
1
0
‑
1
1
SeamallVol.6 , N

MorlokaWorkshopReportか?

Teamwork

お湯の量とか，温度とか，こういったデータは，いずれの機能にも関係してくる.いずれの機能にも入ってくるということになると， 1 つのデータがいくつかのところに分散されて行くことになります.ということは，さらに機能分解していくと，同じような機能があらわれてくることになる.それはまずいのではないか，という意見が出たのです.

CASEBench: 線の中に埋めちゃうと，全部に入っちゃうと，そういう意味ですか?

Teamwork: はい，そうです.たとえば，ここにも入るし，ここにも入ります.ですから，そういうふうに書いていって，あとで分割しでもいいのではないかという意見と，それはちょっとまずい，後々になって，共通の同じような機能を持ったものがこの下にそれぞれできてくるのだはないか，という意見の 2 つに分かれたわけです.

CASEBench: ああ，そういうことですか!

いまはそういうふうに意見が分かれていて，先ほど説明があったように 2 グループに分けている.どちらをとるかはまだ決心がついていないが，とりあえず並行的にアプロー
チをしたいということですね?

Teamwork: 明日の朝，もう一度考えてみようということです.
野村:

よろしいですか?

CASEBench: 制御系のプロセスにとって何か必要か.それが大体見えてきた.ということですね?

Teamwork: そうですね，実際 3 つの機能に分けていた段階で，

1 つコントロールがいるだろう.このコント

ロールを一緒に合わせて考えて行くと.温度が全部に入ったりして，えらいややこしくなる.そういうイメージもあったと思いますけれども

CASEBench: はい.大体わかりました.
落水 :成果物でまだ十分でないものをあまり説明するのはまずいという配慮があったようですがー・・，つまりPWB のグループです .このことは，やはり，ちょっと討論した方がおもしろいんのではないかなと思います.
というのは，実は 3 年程前に，私は学生たちに「状態遷移図の手法を使ってヒーティングシステムを解け」という課題を出したことがあります.そうしたらできました」といって持ってきた一番厳初の状懸遷移図は，たしかに丸と線がたくさんあり，入力(トリガー)と出力(レスポンス)も書いてあるが.およそシステムイメー
ジとは程遠いわけです.問題の世界をそのまま丸と線の世界に書き直した形になっていました.
その時私が学生に説明したことは状怒とは一体何か? J ということです .つまり問題の 中に含まれている言葉の中で，将来プログラムの変数になるもの，つまり状態を決めるものをまず列挙しなさい.そのようなス
テートベクトルが.どのように変化するかというシステムの動作イメージを摘きなさい.その時，設計のポイン

トになるような変数の値の変化に注目して，それを丸にしなさい」というふうに説明しました.
次に提出してきた状態遷移図は，あっという聞にプログラムになりました.状態遷移図を書くところまでが難
しい，すなわち状態を認識するところが難しいのです.私が学生に教えたアプローチがよいかどうかは別として，結 局 CASE ツールは.状態遷移図を書いたり編集したりする作業は支媛してくれるわけですが，状態を発見するところを支媛させるかどうかというところが議論のわかれ目になります.
PWB グループの発表で状態遷移図は一応できましたが，どうもうまくいきません」というのは.まさにそのへんを議論するきっかけになります.そういう意味で.状懸遷移をちょっと説明してほしいと先程質問したのですが，どうですか?

お答えいただけませんか?

PWB: まことにもっともな御質問ですが，一応の狙いとしては.とりあえず書いてみようということでした.
いま，まだ見せられないという理由は，だれが見ても，ちょっとどうかなという感じのするものがいまできあがっているので(笑い) ，これか らもう少し検討を加えて人に見せられる ようにしたいということなのです .
まだ部分的に 3~4 人ずつで書いて，それらを入力しただけの状懸で，だれも他のグループの書いたものをほどんと見ていない状態なんで，一応一通り検討してからだったら，みんなが納得して，この場に出せるようになると思います.

野村 .

わかりましたあと，先程の落水先生のコメントの中で， StP グループのマージが云々ということがあ‑100‑MoriokaWorkshopReport

SeamailVo1. 6 , N
o
.
8
‑
9
‑
1
0
‑
1
1

りましたが . . ..

荻原剛 (大阪大 ，

StP グル ー プ) :先程は コ ンテキスト・ ダ イアグラムだけしか見せなかったんですが ， 実は

A ,B 2 つのグル ー プに分かれて.最上層の記述までは ， 両方とも進んでいます . コンテキスト・ ダ イアグラムだ
けではな く ，その先の階層とか.あるいはデ ー タの定義のところまで，ある程度はで き たいます(図 13 ， 1
4
).

トラン .
.
y クシ ョ

!
lf3ドーー-ント ラ ン

ユ ー ザ ー ファイル

l刈 ;'17 .，イ Jレ

データフローダイアグ ラ ム (1)

山山
ふ
\

¥

iJ!!:比レ コ ード
、冶、

\

山町

利 m 省官以 I1干

fLD/

国 13

凶沼 町!の一-\
利用主主主/国 14

データ フ ローダイアグラ ム (2)‑101‑SeamaUVol.6 , No.8-9-10・11

MoriokaWorkshopReport

先程，マージという表現をしましたが，要するにどこで詰まっていたかといえば，見ている感じでは，自分の頭の中でもやもや考えていることを，コンテキストダイアグラムという明 確な形式に 置きかえるという作業に慣れていないせいもあって，どうやって表現したらいいかわからない，なぜこのように図形に書かなければならな

いのか，とか，データの階層表現にとまどっているとか.そのへんでちょっと詰まっているという感じがしました.

実は，最初のうちは， 2 つのグループがやっていることが全然違っていて，もしかしたら，まったく別個の，全然考え 方の違うシステムができあがってくるのではないかなと思っていたのですが，しだいに似たような格好になってきて，両方のコンテキストダイアグラムを比較すると，遣いは入力源が 1 っか 2 っかということです.ところが中身の具体的な処理の部分でやっていることはだいたい似ていて.要するにトランサ' クション分析になっているわけです.システムに到着した処理要求をトランザクションと見て.それを振り分けて.貸し出しとか返却とか登録・削除とか検索などという処理をして，結局それぞれが図書ファイルという，情報が入ったデータを読んだり書いたりする.というような仕組みになっています.

先程，一見マージができるようには思えないといわれたのですが，詳細部分を書きすすめているうちに，かな
り似通ったシステムになってしまったということです.

今日の段階では， DFD を 書いて，設計上の思考を DFD に反映させるというトレーニングをしたということ

で，その点ではかなりの成果があがったと思います.実際に問題を解くということに関しては，明日以降の進捗
がどのぐらいかにかかっています.そういうことなんですけれども....
務水.

たいへんよくわかりました.歳初からそういうふうに説明してくださればよかったのに(笑い) .

野村.

いまの説明に対して，ご質問は?

いいですか?

ありがとうございました.あと ， Teamwork グルー

プは何か補足とかコメントがありますかっ佐藤千明(長野県協同電算， Teamwork グループ):

途中経過について一言だけコメントしますと，先程，落水先生がいわれたワークショ ッ プの目的の中の，方法論や CASE ツールの有効性しついてですが，これは明後日の最後のパネルにならないと，まだいまはみなさん意見が出せない状況だろうと思います.というのは， CASE
ツールというのは，佐原さんもいわれましたが，ある程度のところまで設計を進めた上で，その後やり直しが効

くとか，チェックできるとか，そういった点で有用性なわけです.ものを考える時に，ツールが自分の思考を助けてくれるかというと ， はっきりいって，まだ，いまのツールはそこまでいっていないと思います .

ですから，最初はみんな机上でやってしまったわけですけれども，機械に取りかかる以前の問題として，ある方法論でその問題を解くことがまだ自分の技術として身についていないために，ツールにそのまま飛び付いても，ツールが何の答えもメリットも返してくれないという状況ではないかと思います.今回のワークショップ
は，そもそもツールを使うということなんで，最初から機械に向かおうということで始めたわけです.結果として，コンテキストダイアグラムまでなんとか行きました.

これはある意味では，ツールがよかったからそこまで行ったわけではなく，ものの考え方として，今までのところ構造化手法の第一歩のところまでやっと理解を得たということです.問題はその次です.先程，いっぱいあるバブルをどうしたらいいかというところでもめた理由はですね，必ず解が得られる方法論というものはなかな
かなくて，ほとんどの方法論はいろいろ経験しなければ解が出てこないわけで，恐らくそれが今日から明日にかけてみんなで苦しんで.ああでもない，こうでもないとやってみた結果になると恩います.
そこで仕事をやり直す必要があるとみんなが思い.その時途中まで戻ってやり直せるという点でツールのメ
リットが出てくる，というのが最終的な落ちなのかなという気がします.ただ今の進捗からいうと ， まだそういう意味で，ツールの本当のメリットというのは出てきていない.そういう意味で，方法論という壁にぶちあたっているわけです.どっちにしょうかな，おそらくどっちでやっても最終的にはできるもんですけれども，そこでこっちがいいよ，というように，チューターみたいな役割をしてくれるツールが出てくれば，もっと使いやすいだろうという感じを持っています.

落水:

皆さんお疲れで，そろそろ終わりだなと思われた時に，私がわざわざ議論をふっかけた意図は，いま佐藤さんにお答えていただいたようなことを，一応議論しておきたかったのです .

このワークショップは ， よいツールを探すのが目的ではないし，ツールの講習会て‘もないわけです.ですから，方法論という枠組みにしたがって，ツールを使いながら，問題を解決して‑102‑

SeamaﾟVo1. 6 , No.8-9-10・11

MoriokaWorkshopReport

とにかく，今の時点で何か話ができるようなこと，または今後考えなければいけないこと.そのへんのところをし少し整理しておきたいと思ったので，あえて挑戦的ないい方をしました.いまの佐藤さんのコメントで満足し
ています.

野村:

あと何人かの方にコメントをお願いしたいと思いますが. Smalltalk グループからは何か?

佐原:

私自身もオブジェクト指向の方法論をよく知らなかったのですが，青木さんの話を聞きながら考えていたのは. Smalltalk に依存しすぎた OOA/OOD になってないか，たとえば.具体化を o bjectPascal とか
O
b
j
e
c
t
i
v
eC とかを用いて行った場合でも，分析や設計のプロセスが変わらなければ，それは完成された技法だといえるが，いまのところ ， まだどうもそうでもないかな，という気がしています.そのへんは明日あたりに見きわめたいと思います.

最初に，青木さんから説明があった時.

rSmalltalk にはこれくらいの記述力があるんですよ」といいながら，

ちょこちょこつと細工して ， あるウインドウが線に沿って動くプログラムを 10 行ぐらいで作られましたね.あ
れですごいなあ! J と.グループのみんなが意識したと思います.それから.

O
b
j
e
c
tWorks についても，やはり，青木さんが作ったツールをまとめて. Smalltalk の動きを視覚的に表現しました.それを見てやはり全員が，すごいと感じたはずです.つまり. Smalltalk の方法論的原理は，イメージ的には好感をもって理解されていた .

しかし，実際に練習問題にぶつかって，オブジェクトをどう決めればよいかを考えようとすると，インスタン
スレベルのオブジェクトは. (問題にほとんど書いてありますから)すぐにリストアップできるのですが ， 青木さんに「もっと抽象化しなければいけない」といわれたとたんに.みんな頭を抱えて. (私も含めて) r うう~ん」とうなっていたわけで，その抽象化レベルが Smalltalk に依存するのか，何か他の処理系に依存するのか，そのへんがまだ，見えないということですね.

それから，ツール自体も. Mac のツールとしてはまだ未完成で，操作のやり方にもいくらか苦しみましたオ

ブジェクトの配置とか，並べかえとかは，人閣の側で一生懸命努力しました.以上です.
青木 :いま佐原さんがいわれたことは，ほとんどその通りだと思います.オブジェクト指向アプローチが他と決定的に違うのはまず，何かの処理を決めて，その入出力を見て..... J とかいうものではないということです.
f 状態を考える」ということでもない . オブジヱクトの確定というところから始まる HOwTo だけをみなさんにお示しし ， それにしたがって仕事を進めてもらっています .
しかし，たとえば，私が最初に例題として取り上げた大学のモデル化ですが，そこに出てくる「教員」や「学生」というオブジェクトは ， この問題領域には必ず存在する自明なものですから，簡単に定義できます.ところが，その繕造関係を is-a とか has-a に分けて行くとき，その上に，ぽこつと「人」という抽象的なオブジェクトが出てくる.この抽象化プロセスにみなさん慣れていないように見える.

実際には，最初そうした抽象オブジェクトなしに属性やサービスを定義して行って，その後であちこちに同じものが存在することに気.づいて，抽象化の階段を 1 段上がるわけですが，慣れていないとなかなかむずかしい.

そこで，グループのみなさんの心理状態としては，それとはなしに私の顔色を窺うんですね . そのことがこっ
ちにはわかっているから ， おもわず「ニヤッ」と笑うとうん，そうか」という感じでやっているのが現状です(笑 い).

それから，佐原さんがいわれたように. Smalltalk には豊富なクラスライブラリがあるので，それを有効に利用しないのは損だというのが，私のスタンスです.その知識が分析 ・ 設計のアプローチに影響を与えることは，

やはり否定できない.ですから.私はあまり口出ししないようにしているのですが，私のそうした知識や経験を
どんどん提供してほしいというメンバーも多い.むしろ，何とか聞き出そうとする感じです .

給湯システムでいいますと，ラ ン プとかスイ ッ チとかパルプというものが，みんなすべて開閉するものだ.つまり ， 開いているか閉じているか，いずれかの状態を必ず持っているということに気づいて，このバイナリス
テート(二値状態)とい う 抽象オブジェクトを上に配置しました.この時，私がいったアドバイスはラ ン プだのスイ ッ チだのというのは.そのプログラムを作った時の財産にはならない.会社の知的財産として残るのは ，このバイナリステートとい う 抽象クラスなのだ」ということです.まあ，現状はそんなふうに進んでいます.

落水

そうした上位のオブ ジ ェクトを見つけるというのは .

思いますが... . ?

‑103‑

Howto じゃダメだと思います.訓練しかないとSeamaﾟVol.6 , No.8‑9‑10‑11

MorlokaWorkshopReport

F

ふんヲ々、

そうですね.

落水:

何か有効な訓練手段があるのですか?

青木:

やはり ， まずは全部作ってみることだと思います.そうすると.同じ情報があちこちに散在していて，い

nν

青木:

ざシステムを動かした時に，何か変えたいと思ったら，それら全部いじらなければならないという悲惨な状況を，実際に何度か経験する.そのプロセスを踏まない限り，こういうノウハウはなかなか身につきません.私自身
も，そうした経験を何度も繰り返してきています.

足
、.

、ー

佐原 :

それから，また. Smalltalk の基礎文法に通じていれば，結果がうまく行くかどうかの見通しもつくので

青木 :それはそうです.これらがバイナリステートだと気がつけば，その上に Smalltalk のスイッチというクラスがあって ， まさにぴったりあてはまる.ぞうすると，あとはもう簡単にシステムが動かせる状懸に持って行L‑ZHEdoはないですか?

ける.まあ，そんなふうにいうと，ずいぶん Smalltalk を意識しているなあ，と見られでも仕方がないのですが .

仁き

他の言語で，そういう抽象化のライブラりが提供されていない現状の方が .CASE ツール云々よりも問題だと思います.

このまま行くと，またチュートリアルに戻ってしまいそうなので，ドクター・ストップをかけます(笑い) .

あと他にコメントをいただいていないのは.天池さんのところですか?

天漣学(カシオ計算機.

AH4F 会

野村:

CASEBench グループ) : 先ほど落水先生から御指摘があったように.われわれのグ

ループは，最初のコンテキストダイアグラムを作るさいに，全員の意志を統一するために，紙の上で作業しました .そ れは，別に私の独断でやったわけではなく.インストラクタの渡部さんと御相談して J まあ，最初はいい

つんじゃないか? J という判断でしたが，渡部さん，そのあたりのことをちょっとコメントしてください.
渡部健次(ソニー ・ テクトロニクス.

CASEBench グループ) ): なぜ紙を使ったかということですが，それは台あれば. 3 人ずつグループに分かれてということもできたかもしれませんが....

とういう状況を考えて.最初のコンテキスト図は紙で作りました.多分 CASE ベンダの方はみなさんそう

カ隠るるグ

9 人ものメンバが全員で 1 台のワークステーションを使うのは，とうてい無理だったからです.もしマシンが 3

す

思っていらっしゃると思うんですが，日本語変換とか，ツールの使い方がよくわかっていれば，最初からマシンの前に座って. 1 人で入力しながら考えるのがよいと思います.今日はそういう状況ではなかったということで
，

藷

す.

あと他に ， 何かいい忘れたこととか.いいたいこと，どこかのグループに聞きたいことなど，あります

か?

落水 :

HE か

野村:

せっかくですから，田中さんと桜井さんにも，ご感想とかコメントをお聞きたいのですが .
.
L〆

田中貌市(東陽テクニカ. Teamwork グループ)・

渡部さんも少し触れておられましたが，やはり，ツールを提を供させていただく側としては，そのツールを教授しながら，お使いいただきたいと思っています.ただ，最初は書くところまでしか行っていないということでしょうか.
落水 :

実は ，私 はも っと悲惨 な状況を想像していたのです方法論を理解する ， ツールの操作法を覚える」と

い うとこ ろで，一日の時間を消費して.とても設計どころではない .

謁帽覇落す

操作になれるというところがありますので.今日はまだ愚初の小競り合いということで，簡単なダイヤグラムをそんな状況を予想していた.ところが，これまでの報告をうかが う と，結構方法論をそれなりにこなしている.多分インストラクタその他の方の指導もよ
はそんなに難しくないんだなと感じました.もちろん ， エキスパートになるには，ちょっと時聞がかかるかもしれませんけども ， 昨日のチュトリアルからいきなり始まって .CASE ツールも初めてだという方が多かった割には.予想以上のスピードで成果が出ています.

桜井腐里 (SRA. StP グル ープ) :われわれのところは，グループの人数を考えて. X-Window 端末を 2 台用意したのですが，ところが.そのうち片方の日本語入力の設定がうまくできていなくて，最初は，ツールを使わずに ， 紙の上で問題を考えていただき ， その聞にマシンの設定していょうかなと思っていました.
し かし ， メンバ ーの方 々から「 せっか くツ ールがあるんだから ， 使いたい」という強い希望が出て，またせっ

‑104‑

落番佐野

かったのかもしれませんが，方法論にしたがって作るということ . CASE ツールを使うということは，基本的に

SeamailVo 1. 6 , No.8・9-10・ 11

MoriokaW orkshopReport

かく 2 台あるなら，やはり 2 台とも使ってやろう」ということになりました.グループを 2 つに分け る と，双方それぞれ 5 人ぐらいですから，全員でワークステーションを阻んでも，画面が見えるんですね . 最後にそれぞれのやったことを，お互いに発表しようということで， 2 つのサブグループで作業をしました.結局 ， 片方の端末

は漢字の設定がうまくいかなくて.アルファベットでの入力ということになりましたが.. ..
一応，データフロ ー 図を書きながらデータ構造図を書くというあたりは，みなさん体験できたにではなし、かと思います.私は，ある程度話が進み始めたら.ほとんど何もしないでボー ッ としていた ので すが，印 象 とし て は ，
このように 1 つのツールを何人かで囲み，1 つの画面を見ながら討論し，入力するとい う やり方は一応 う まく

いったんのではないかと思います.

野村 .

それでは，さっきか ら 手を上げていた佐原さん，どうぞ佐原:

構造化分析に挑戦したグル ー プの方 々 のやり方を聞いていて，少し定石と遣うなと思った点が 2 つあります

1 つは ， 構造化分析では，あらかじめ最後の具体化段階を予想してこうなりそうだから，こうしたらいいん

じゃないか? J という議論をしないように，あるフェイズでは.あまり先のことを考えずに，そこだけで収束できるようにする

少しづっスライドして，そこである基準で決めたら ， 次におろしてい く. そ う い う 段階的詳細化をしている時に，具体化の時にまずいんのではないかなどと考 え たりすると，考える範囲がどんどん広が っ て，

大きなシステムになると，結局わからなくなってしまいます . そのあたり，ちょっと考え直した方がいいんじゃ
ないかなと思いました
もう 1 つは，プロセスをあらわす丸い記号，あれをポンボンポ ン と作って，データフローでつないでいるということですが，実は，それをやっていると ，モジュール構造図を作っているのとほとんど同じになってしまう.

つまり，記法は違うけど，従来通りのモジュ ー ル構造を作っていることになってしまうので，これもちょ っ とまずいのではないかと思いました
構造化分析は，どちらかといえば，データ中心の方法論であり，そのデータフロ ー を出すためには，何が必要かといえば，デ ー タフロ ー の出力 t に対して，入力として何が必要とかを考えながら，それらをつないでいって ，聞に糊として丸印の記号がある.それらの丸印には名前を付けずに置いておき，一番最後になって ， ここを流れるのはどういうものかを考慮して名前を付けるのが，たぶん定石だろうと思います.別に，定石をいつも固執する必要はなく ，時に ははずしてもいいと思いますけれども，基本的には ， 定石に沿った進め方をしたほうがいいのではないかなと思います.

落水:

それはどうしてですか?

佐原:

理由は，いわゆるモジュール構造を作ってしまうと，結局，人聞は，どうしても，うまく具体化ができるかどうか，ハードウェアの特性なんかを 一 生懸命考えてしまうんですね.そうすると.対象となっている l つのシステムだけを作るだけならいいのですが，そのシステムを他の環境に移植しようとか，他のシステムとの連携を考える場合にうまく行かなくなってしまう

しれないんです.

システムのハ ー ドウェア的な特性を早めに考慮するのは，そうい う 理由で，よくありません .
ff 水:

わかりました.

野村:

何となく，みなさんもう課題の回答を出してこれで終りというような雰囲気になりかけていたところを.

落水先生に修正していただいて，このワークショップの本来の目的が何かということが，明確になったと思いま
す 目 その意味で，貴重な議論だったのではないでしょうか?
あと最後に何かいいたい方があれば.話をうかがいます.なければ，これで議論を打ち切りたいと思います.

落水

1 つお願いがあります.いまのプレゼンテーションで使われた OHP シ ート に，グループの名前と通し番号を記入していただいて，提出してください.記録のためです.よろしくお願いします.
佐原:

通し番号の他に時間を書いておくといいですね.何日の何時ごろとか . . ..

野村:

では，このセッショ ン を終りにします.

6 時半にわんこそば大会に出発します.

‑105‑SeamallVo1. 6 , No.8・9・10-11

MoriokaWorkshopReport

6. 最終発表

1.PWB&Hyperbook グループの発表

10
8

2.00 AlOOD グル ー プの発表

1
1
1

3
.CASEBench グループの発表

1
1
4

4
.StP グル ー プの発表

1
2
0

s
.Teamwork グループの発表

1
2
3

‑107‑

MoriokaWorkshopReport

SeamaHVo1. 6 , No.8-9-10・11

最終発表

t

報告者

下津直武・方学芽(静岡大学)

1.PWB& Hyperbook グルーアの発表
われわれのグループでや っ てきたことは ， 図 1 に示す状態遷移図を作ったということにつきます . その製作過程で，われわれの CASE ツールである PWB の持つ強力なアニメーショ ン 機能を利用し，内容を序々に洗練させながら，ここまできました.

だいたいの経過を説明すると，初日は，まずツールの説明を受け.午後半日ぐらいでこの状態遷移図を作りました . 次の日の午前中に入力を始め，午後にかけてアニメーショ ン ができるような段階までもって行きました.
状態遷移図は，御存じのように ， システムがある状態のときにあるイベントが起こると，システムはどんな挙動を示しどの状態に移行するかということを.一枚の絵に書いたものです.
われわれが選択した課題は給湯 シ ステムで，図 1 が ， システム全体の状態遷移図を示します給湯 J. r お湯

はり J ・「追いだき 」 などの状態があって，それらの状態においてお湯はりスイッチを ON にする」とか給
湯栓をひねる」とかい っ て外部イ ベン トが発生する可能性があります . そうしたことすべてを表したのがこの図
です.

ミ~(J

初電弁

OJ
た

を|

イ湯

mu. り状日

J7i

し出か栓をも

JJJ

A

E"1

渇 11 りお~~

、
ー

国 1

給渇システムの状怒遷移図 (PWB)

L 可さ

そ。

‑108‑

SeamailVo 1. 6 , No.8・9-10・ 11

MoriokaW orkshopReport

少し小さくて見にくいので追いだき J 状態の部分を中心に拡大したものを，次にお見せします(図 2)

もちろん，状態遷移図を作るにあたっては，課題 に述べられた仕様をまず第 一 基準にして，あまり明確に示されていない部分については，全員で討論して，こういうふうにしようということを決めました.

お 55う
1. ~Iltl~ J..û.:改定双山/
二百 tF，はりヌイッチ oN1. ;;;11丘公定変更
す7 火!なJ}J

1o 0

リット Jレ

1. ¥
:
IJ
{
.
Hr
‑
t
JJ
!
:
'
i
2 パイパス 1 r- e
:J

3. ラ ン プ o F F
1 .I .Ir.ll イ併ド n

-An ，
b つω

バ

門 2

国 2

遣いだき状怒 (PWB)

さて ， 中央の 2 つの状態(燃焼監視と追いだき)ですが，これらの状態に遷移することが可能な状態としては，初期状態があげられます.またお湯はり J . r 給湯 J の各状態からも，ここに遷移する可 能性が あります

まず，

電源 ON だけの状態. つまり初期状態にあるときに追いだきスイッチが入ると，切り換え弁を 切り換 え，パルプ
弁を聞き.点火操作を行って燃焼監視」の状態に行きます .

この状態では，本当に火がついたかどうかを見ていて，もし火がつかなければ初期状態に戻ります.そのときには当然，切り換え弁を切り換えてバイパス弁を閉じるという操作をします.着火成功であれば.燃焼ランプをON にして.追いだき状態に行きます.

この状態では，温度を 93C の一定値に保ってお湯を出し続けます . ただ.このときにスイッチが OFF されたり，あるいは 100 リ ットルを越えたら，切換弁を切り換えてバイパス弁を閉じ，ランプを OFF にし，比例弁を閉じ，火を消して，初期状態に戻ります.

一方，追いだき状怒でお湯はりスイッチが押されれば，今度はお湯はり状態に移行します . そこで追いだきス
イッチが ON されれば，再び追いだき状態に戻ります.この状態 のときに給湯，すなわち蛇 口が関かれれば ，給湯状態に移行します.給湯が終わる ，つまり蛇口の栓が閉じられれば ，また当然追いだき状態に戻ります.
設計にあたって，仕様書に定義されていない不明確な部分は，一応安全サイドでものごとを考えるようにしました . この給湯システムでは，最高 93 度というお湯が出ます.給湯栓を開いたとき，いきなり 93 度のお湯が出たのではたいへんですよね.そんなシステムを，もしソ速に輸出したりすると，また火傷の治療のために札幌から飛行機を飛ばさなければならなくなるので(笑い).そういう事態は極力避けたいということです.
たとえば，燃焼監視という状態が設けてありますが，この状懸のときに追いだきスイッチが押されたり，給湯栓がひねられるという可能性も十分考えられます

しかし，この段階では，点火操作の後に火がついたかどうかを確認することが主要な動作であり，また ， 時間的にいえばそういうイベ ン トが来る可能性は非常に少ないので，もしそういうイベントが来ても，それを無視してまた自分の状態に戻るように考えています.それから，電源がいきなり OFF にされるとか，停電になってしまうとかいう場合もあり，本当にこのシステムを作るのであれば，そのへんも考慮しなければいけないのですが，今回はそこまではやりませんでした.

‑109‑

SeamanVo1.6 , No.8-9-10・11

1、

デモ用のマシンがここにおいてあります . 百聞は一見に如かずですので，後で見てください.その前にちょっとMoriokaW orkshopReportと簡単にデモの内容，つまりアニメーションがどういう感じになるかを説明しておきます.
全体の状怒遷移図の上で，まず入り口から電源、 ON の状態に入って，次に初期状態に移ります.この状態にお吸

いて ， いろいろなイベントが起こる可能性があります.アニメーションにさいしては，現在の状態を示す黒い丸も1 つのウインドウが開き，その中に可能なイベントがリストアッたしがピビビッと動いて行ってこの状態に来ると，フーされています.そこで，たとえばマウスを給湯のところに持って行ってクリックすれば，給湯燃焼監視の状態に移るわけです

Q 遷トる

そこでもまたウインドウが開かれます.このウインドウに示されたイベントは，実際に燃焼しているかあるい

は燃焼に失敗したかということで，これは本来ならばシステムが適当なセンサーによって判定するのですが，アニメーションでは人聞が選択して入力します.燃焼失敗の場合は初期状態に戻りますが.ここでもし燃焼 ON
をクリックすると，次に給湯状態に移ります.するとまた新しいウインドウが開き.その中から適当なイベント

Aを選んで先に進むといったぐあいです

初めはずいぶんとまどいました.あらかじめ勉強しておくべきだったと反省しています.つまり，どういう状態ののてメ

最後にまとめですが，回われわれのグループで使った方法論は，状態遷移図によってシステムの構造を把握し，分析しようというものでした.グループ・メンバの中で，そういう方法論に慣れていた人間はほとんどいなくて，をまず切り出すか，そのときの外部イベントとして何を考えたらよいか，このへんでちょっと時閣がかかりました.それと，グループでの仕事の進め方ですが，いきなり最初に 3 つのグループに分けて，給湯，お湯はり，追いだきの 3 つの部分を解析しようということだったのですが，さきほど述べたような事情から，あまりうまく行
かなかったかなあというのが感想です.

2.

次に， PWB ツール自体の評価ですが，利点から列挙していきますと，まず， undo が何段階か使えること，当然それに対して元に戻すための redo が使えることが，まちがいを犯しやすいわれわれのような初心者に対して

番1は，有用だったと思います.

まわれわれの場合は.一昨日足立さんが説明されたユーザ向け

果

アニメーションがレビュ一時のチェック漏れをなくしてくれ

5たわけですが，そういう意味で非常に有効でした属

それから，分析段階での検証支援も有効でした

プレゼンテーションというよりは，システム設計者自身によるレビューというか，設計作業の成果の検証に使っます.それもほとんどの仕事を自動的にワークステーションがやってくれるので.ずいぶん楽だなあと感じましでiた.

それから，状態遷移図を書くのに使ったエディタ EOPM と.スイッチを書くエディタ UIM についてですが，制御系のシステムの設計には有効だなと感じました.マウスでコマンドが選べるというか，ウインドウ

ドリブ

ンになっていて使いやすいし.また，エディタ自身が文法を知っていて，誤った入力をチェックしてくれるので，記法とかをあまりよく知らない初心者にも使えます.また，このツールは Smalltalk の上で動くのですが，Smalltalk を全 然知らなくても使うことができるようになっています.
さて，次に欠点ですが， UIM エディタの機能がそれほど強力でなく，つまり簡単な図しか作れないことがあげられます.それから，チュートリアルというか，ツール自身のガイダンス機能が用意されていないので，初めて使う人にはちょっと使いづらいように思いました.他にもいろいろ欠点はあるでしょうが，まだそれが見えるまで使いこなしていないというのが本音です.

最後に全体的な感想、を述べさせていただくと，今回の演習では，アニメーションが使えてよかったと思うのですが，実際の場面でどれだけ有効かはまだよくわかりません.今回は制御系のシステムを課題に選んだのですが，事務処理系とかバッチ系なとに，この分析・設計アプローチがうまく適用できるかどうかは疑問です.

状態遷移図の形に作ったモデルの検証を自動的に支援するシステムも欲しい.今は，とにかくモデルを作り，アニメーションで動かして，おかしければ人聞が直すというスタイルですが，たとえば，仕様を最初に打ち込んでおくとそれがルールとしてシステムに記憶され，設計者が書いた状懸遷移図を，システムがそのルールにてら
し合わせてチェックし，ここは遣うんじゃないのと自動的に注意しくれるようであれば，もっと便利で

‑110‑

オ発ま生間

中を全部埋めると，それをもとに C プログラムのスケルトンを出してくれるようなツールがあれば，非常にうれしい.

O 第プ表すオ懸か

それから，ちょっと思ったのですが，状態遷移図はまあ何とか書けます.すると，当然そこには，状態とか外部からのイベントが全部記述されているので，それをもとにして状態遷移表を自動的に作ってくれて，その表の

SeamaUVol.6 , No.8-9-10・11

MoriokaWorkshopReportと思いました.まあ，わがままな意見ですね
ツールのメリットを十分に知る前にタイムアップになってしまったので. PWB そのものの設計意図をすべて吸収できなかったのが残念です

まあ，今回は時間も 2 日間しかなかったし，使ったエディタも 1 つだし，課題

も 1 つしかこなせなかったので，それはやむを得な L 功3 もしれません.
以上で発表は終わりですが.せっかくワークステーションがありますので，是非われわれの成果を目で見ていただきたいと思います.デモ自体は短時間で終わりますので. 2~3 グループに分かれて見ていただけばよいでしょう .
Q( 高橋秀行.

SRA): ふつう，状態遷移図では，ある状態から別の状態へ遷移するとき，どんなトリヌ7 でその遷移が起こり，どんなアクションが実行されるかを記述するはずですが，いま見せていただいた図では，イベントの名前のようなものが書いてありますね

PWB で，この種の状態遷移図を作るときのルールはどうなっているのですか?
A( 小林透.

NTT): 丸印は 1 つの状態を示し，その下に書いてあるのが状態の名前です

それらをつなぐ矢印のまん中に書いであるのは，すべてイベント名です.作成の手順は.まず，丸印の状態をどんどん書いて行き，その後でそれらの間のリレーションを張り，そのトリガとなるイベントの名前を記入します.そうすることによって，さっきのアニメーションを実現できるわけなんです

それぞれのイベントがどんな機能を果たすかは，アニメ ーションに必要がないので，ここでは 書きま せん.

2.00A/OOD グループの発表
われわれが使ったのは. Smaltalk-80 上の OOA ツールで，分析対象は前のグループと同じ給湯問題です.一番最初にツールの解説をしていただき，このときに OOA ツールとか. G
rapherGear のデモを見せていただきました.

GrapherGear はすば らしいものだと感じましたが，実際の作業では OOA ツールを使 っただけです

どんな方法論かは，すでに初日に説明がありましたが，図 3 に示すように，オブジェクトの確定，構造の確定，
属性-サービスの定義という手 )1頂で仕事を進めて行きます.中間発表のときに，この OOA のフェーズ 1 から5 までを実施することを目標にしたいとお話しましたが，そのあと佐原さんから OOD までや らない と，その効果がわからないだろうというアドバイスを受け，希望としてはそこまでは行きたいと考えていましたが.実際にできたのは OOA だけでした.

1

OOA

OOD

オブジェクトの確定

1.ハードウェアアーキテクチャの決定

2. 構造の確定

2. ソフトウェアアーキテクチャの決定

3. サブジェクトの定義

3. 特殊化4. 属性の定義

4. 組み立て5. サービスの定義

5. 抽象化6

要 素分解

7. サービスの詳細化
国 3

OOA と

OOD

OOA の各フェーズをたどって行く過程で感じたことが らをいくつか挙げてみます.
第 1 は，オブジェクトの確定についてです.このフェーズでは.問題文中に出てくる名詞をキーワードとしてオブジェクトにして行くのですが，それが本当に必要なものなのかどうかの判断に.ずいぶん悩みました

中間

発表のときに浴槽というオブジ ェクトの候補があり，その取り扱いがよくわからないという話をした覚えが あります

このように，候補を 挙げるのは簡単ですが，それが本当に必要かどうか， 判断に困りました.

オブジェクト指向の「ぐにやぐにや J した雰囲気(笑 L けが好きで集まったグル ー プだったのですが ，割に一生懸命突き進む雰囲気があり，適当なとこでけりをつけることができませんでした.そういうことで，ここに時聞かけすぎてしまいました.グループ内の同意を求めすぎたことも問題です‑111‑

佐原さんからも指摘されましたSeamaDVol.6 , No.8・9-10・11

MoriokaWorkshopReportがいいよね，いいよね? J といってるとなかなか先へ進めません.
次は構造の確定についての問題です . 構造の確定というのは，オブジェクト聞にどういう関係があるのかを知ろうとする活動です.このフェーズでの問題点は，機械の見た目にごまかされたということです.今回の課題は給湯システムだったのですが，スイッチとかコントローラのイメージをなんとなく想像していたのですけれど
も ， 分析のとき，外から見たイメージにとらわれすぎてしまって.そういう状懸で関係を定義して行くのはなか

なか大変でした.
抽象化がうまくできないし，やり方がわからないんです.初日に.バイナリステイトという抽象化の案を出したとき，このときだけ青木さんが笑顔を見せてくれたので，うまくできたと思ったんですが，逆にのぼせてしまったというか ， ものすごくそれにとらわれてしまって，他の面ではちょっと力不足の結果になったと思います.
また，オブジェクト聞の is-a. has-a という関係を定義していく段階で.

1 の「オブジェクトの確定」の不備に気づいて後戻りするということもありました.それから is-a. has-a の関係を結ぶのに

is-a のほうはそれほど難しくなかったのですが. has-a の関係を定義するのは，ずいぶん難しかったなあと全員が感じました.その原因は，オブジェクトの確定が不十分だったというか，自信が持てなかったということがあると思います.
サブジェクトの定義は必要がなかったので，やっていません .
最後のフェーズとしては，属性定義とサービス定義をやりました.ここまでは「これはこれでいいかねえ? Jという風に，みんなの同意を求めながらやってきたのですが.それではなかなか作業が進まないので.
がまず考えて ，

1 人 1 人それぞれのアイデアを出し合って討論する形に切り替えました .

このフェーズでの問題点は ， 構造の確定が各自まちまちであったこと，そして.何が属性かわからなかったことです.バイナリステイトの属性とはいったい何だろうと考え出すと，あとどうしょうもなくなってしまう.また，いったんオブジェクトとして挙げたものが，別のオブジェクトの属性になってしまうというようなこともあり，よくわかりませんでした.
サービスの定義は，属性の定義より簡単でした.いったん消したオブジェクトがまた復活することもあり，これを僕なんかは「湯釜の復活」と呼んでいるんですが.

1 回湯釜を消したんですが，途中でやはりそれがどうしても欲しくなって.復活させたというようなことがありました.また，サービスの属性を定援するとき.単にツールで提供されている枠の中に.言葉を埋めていくだけのレベルで仕事が終わってしまったという反省があります .

それから，悪戦苦闘しているときに，青木さんがペトリネットとか. GrapherGear のシミュレーションをしてくれて，頑張れよとはげましてくれました.
ツールと方法論についての感想ですが，線を自動的に引いてくれれるのですけども，それが見にくかった場合，

きれいに直すのがなかなか大変でした.今回使ったのは，ツールのごく一部の機能でしかなかったので，全体の感想は述べられません.抽象化については相当苦しんだのですが，そういうところでは.やはり青木さんがいっておられましたけども，第 6 感みたいなものが必要で，それがなかなか働かなかったという気がします.方法論の有用性については ， まだそれをうんぬんするまでの経験を積むには至りませんでした.
記録係の方の感想、 はツールを使うというよりも方法論に振り回されていたみたいだ」ということと，「フェーズの切り換えがうまくできない，ある程度のところで止めることができずにズルズルやってしまっている」といったところですえらいグループに入ってしまった」という方もいました(笑い) .
で，われわれの最 終 成果は図 4 に示す通りです.時間がないので.詳細の説明は省かせていただきます.
Q( 発言者不明):

さ っ きオブジェクトが属性に変わったという話がありましたが，具体的に何がどうなったのですか?

A( 発表者) : WlJ り込みラ ン プは 1 つのオブジェクトなんですが.同じものが別のオブジェクトの属性のところに入っているということです .

Q( 佐原伸.

SRA)

属性の中にラ ン プが入るのではなくて，ランプの種類という属性があって ， それが何々ラン プという値を持っているというほうが普通ですね .
A( 発表者):

そういわれるとそんな気がしてきます.

‑112‑

ラ

な定温l! は?
t合議開始
.
L
.
=
:
.
.
.
:
.
.
.
. ....ノ

a・，

市日前日
品鯵都町

国

君。『E-E同
Mm唱。ュ

i!t:;ランプ怠定温度
i!伝スイッチ

冨耳目。E

コ ン トロ

電源
総統ランプ

お湯はりスイッチ;;:定本量l!~込みランプ
一時給洛停止/開始
水量11:定E お 這はり中の給場
l ìJlいだき中の1[;:島il ìJlいだき
1:お浩はりω0
白岡田旦-4 。--a-z七
e-Em・ロ

4uw也、ゆト(。。 hF
。~
。。)

-H-u・

UH
叫下y
』hq。。降、Z\8 コントロ ーラ
追いだきスイッチ

o
.
8
‑
9
‑
1
0
‑
1
1
SeamaﾟVo1. 6 , N

MoriokaWorkshopReport

3.CASEBench グル ープの発表
われわれが経験した試行錯誤をみなさんにいっしょに追っていただいて.その過程で CASE ツールがどんなふうに役立ったかをお話する予定で いたのですが，時聞の関係で結果中心の報告に変えさせていただきます.分
析対象は酒屋倉庫問題です.

われわれが 使 った CASE Benchは構造化分析のツールですので， DFD を作るのが 1 つの大きな目標になります . 最終的なコンテクストダイアグラムは図 5 のようになったのですが，その作成にあたっては，まずデ ー タを 抽出しよ うというアプロ ーチをとりました.これはたい へんうまく行って ，コ ンテクス ト ダ イアグラムはかな
り簡単に作成できました.名前の付け方でちょっと苦労はありましたが .

まずまずスム ー ズに決まりました.

医号一一~=
国 5 酒屋倉庫の DFD 一 全体 (CASE

B
e
n
c
h
)

次に詳細化のステップですが，図 5 の「酒屋倉庫の入出庫を確認する」というバブルを 2 つに分けると，図 6のようになります.

丁也原信示さ

否定フ ァイル・ーーー-ーーー『ー司・ーー

国 6 酒屋の入出庫を管理する DFD (CASEB
e
n
c
h
)

‑114‑

SeamaUVo1. 6 , N
o
.
8
‑
9
‑
1
0
‑
1
1

MoriokaWorkshopReport

さらに，その中の「商品を管理する J というバブルを詳細化したものが図 7 です.ここで，この図で「出庫を管理する」というバブルの入出力がかなり多いので，それを図 8 のように分割しました.ここまで詳細化が進んだとき. ER 図を使ったデータの分析と，データ辞書登録の作業を行いました.この作業はなかなか難しく感じ
ました
取吉氏

;倉庫係;

活寸、芸Z

会I主写
- -て

¥

ミ
壱耳Lファイルa 事主ヨ!t'

B
e
n
c
h
)

U
一骨

一倍一

国 7 商品を管理する DFD (CASE:右主石::~~する'

ーミ」一一一ーーー­~.=J!;:'ファイル

取引先i

B
e
n
c
h
)

国 8 出庫を管理する DFD (CASE

結局こういう事務処理の問題では(というより，そもそも構造化分析では) .データが非常に大切なので，まずERD を使って，エ ンティティが何かをはっきり 把提してか ら作業を始めるべきだと思います.また，デ ータ

ディクショナリの作成にさいしては. 1 つのコ ンテクストを作ったら，すぐそれに関するデ ー タディクショナリ
登録を行なうようにするのがよいと思います.機能分割という面では，階層化のやり方について，いろいろとわ
からないことがありました.

‑1
1
5‑

SeamaUVol.6 , No.8-9-10・11

MoriokaWorkshopReport

次の問題は，各階層でのファイルの扱い方です.図 6 のレベルで，すべてのファイル(在庫ファイル，在庫不足リスト，依頼者名簿，行き先)を書いてしまったのですが J 商品の管理をする」というバブルの意味合いがはっ

きりしていません.取り引き先との具体的な関係がこの図からは読めないのです.もちろん.さらに下のレベルへ落ちていくにしたがって.詳細はわかってくるのですが..

完成したデータディクショナリと ER 図は，図 9 および図 10 のようになりました.
依級者名簿{MJi者 m号+ It-;中iiill名す (州1i，白住rfr +{，占級者11rHi~品号
在庫不足リスト= 送り先名+品名+数日
取引先=取引先名+取引先住nfi + 取引先電話芯号

山政依*.ID喫=品名+数民1 t 送り先名
出店街示む =注文l!ì号+送り先名 t (コンテナおr::-+♂，名+数日 +ZE コ ンテナ搬出マーク lm晶画=コ ン テナ訪号.;. l
品名 ?LI211
発注i!f=品名+数量
不足辿~1I =品名+数五l
在店 77 イル=品名コード+品名 t (紋凶+コンテナ世号 l

出瓜tF'r~主主~ = 品名 t (コンテゴ前号+数民 l

出庫命令書= 品名 t (コンテゾ前号+数出 l
入l車内容紫=コンテナl!ì号 t J，q仏fド n ..日時十 l 品名 t l
i
X
l
i
11
不足商品= 注文番号+送り先名+品名+数hl
不足分出w命令書= 品名 t (コ ンテナ番号+数111
不足報告=品名+数út
送り先名= {:配中H省名
コンテナ苔号数字. *コメン l 舎{MJ\者住所住p}r

依級者電話l!ì号"1LI~~aì 号'

依頼者醤号数字・

依級者名氏名'笠コンテナ l般出マーク 2.1己号・取引先住所位fiir
取引先盟諸号包括百問・取引先名会社名.
数血数字・

注文香号数字"
品名= .S81目・品名コード z

国 9 データディクショナリ(CASE B
ench)

③
の

巴

や\⑦
ヨ

バ θ

⑦

:ょ冶

国 10 ER 国 (CASE B
ench)

‑116‑

SeamailVo1. 6 , No.8-9-10・11

MoriokaW orkshopReport

CASE Bench の I つ の強力な機能に，エラ ー・ チェック，つまり DFD やデ ー タディクショナリが正しいかどうかを評価してくれる機能があります . 図 11 はその結果を示します.

D
D'
d
d
' を n・師'1'です.
1frHI I...T)i:~~されている名前・
jÎ!干i文が未定筏となっている名前.

Dド 0'1'1こ存在しているに L かかわらず;己認されれ沿い名前.
他町)i!叙文やDFO'I'で民川 さ れていないt.ñ ;J:
jl!注文' 1 'て.'JJlIt， jlj定誌の世:l!.{のある名前.
コンテす訴守

1
:
"J
l
/;
WW

tkml~ 高守

U\:iJ1 I~ ぉ

取引先位所

取引先屯ir.:r.号

l
1
f
t

DFO ‘ ùrùo'笠コン r-)・

送り先名

.
f
:
.
1
:
.

m: l: マーク出)11;む.~~J}.I(l(引先包
i 主主苫:}

dl，色コード

をi，;f.(，国[IJ です。

' drùo' の釘'日叫l に{会 LB された iÈ!N，の自1I いフロー安正~ :コンテナお号
送り先名
コンテナ IIÝ 号

依争責者住所{MJi者電話11t号

UX'級者番号{剣賞者名
取引先百1認訴号
送り先名
品名

空コンテナ
取引先名
注文百?号
ぷ名コ ー ド

取引先住所

l
i
t
i
i
l

i臼山マーク

データ項目、 û8Iの自1持管制る・ l司、j し 5:;防総えるデータフローが前E していま ~.oデー タ 羽目、 mi品銘柄目 が読み山し WITJ になっています。

データ項目、取引先・カ)~é み :li し nm になっています。
データ項目 1火!f'Ìi者名f0'が11 き込み WJlJになっています。
デーテ巧日 γEIむ不足リスト・が訴さ込み引用になっていま 3\1

国 11 エラー ・チ エヴク結果 (CASE B
e
n
c
h
)

上半分は，デ ー タディクショナリに対するチェックの結果です.定義文中に現れ再定義が必要である名前のリストが出力されています

下半分は DFD に対する評価です.これはと同じ時点でのものですから ，先 ほどと同

じエラ ー メッセ ー ジがまず出ています

もう一つのエラーメッセ ー ジはあるバブルに対し 5 本を越えるデ ー

タフ ローが存在する J とい うもので，バブルをもう一段分解すべきだという警告です.
次の手順としてはミニスペック作るはずだったのですが，時聞が足りなくて，途中で終わりました.図 12 は，

DFD から自動的に作成された構造図です .これはコマン ドを 3 つ打ち込むだけでできてしまいます .

・

8

'

• “"

‑
7
‑
1

処!:láJfシス?ム

Uuc t;・

国 12 モジュ ー ル構造園 (CASE B
e
n
c
h
)

‑117‑

SeamaﾟVol.6 , No.8-9-10・11

MoriokaWorkshopReport

この図には ，

まだいくつかの問題が残っています出庫の指示」モジュールからいくつかの下位モジュールを呼び出していますが，それ ら の下位モジュール聞に相互呼び出しの関係があるとういう点です . にやっていただいたきました.

図 13 はモジュールのミニ仕様書の一部です.これをもとに .C プログラムの枠組みが作れます

中身が空でパラメ ータだけのスケルト ン ができてきます .

出店の指示 50在mIを管理する 2 (入力カプル: .
L1国[内容以・)
在庫ファイル(入力カプル:、. )倉JilI係から納品古を読み出す出n1IIä示症を書き込む(山力カプル: 'Wl品世・)
在庫フ 7 イル(出力カプル:‘・)

山町の窓口業務をする 1 (山力カプル:‘山niï命令書・)

依~~l者から tlwi(依ü以を読み出す不定通絡を告さ込む{出ノj7J プJレ:‘出店依:m京・.入力みプル;‘不足述絡・)
依頼者名市(入力カプJ レ:、\出力カプル:、. )倉庫係から納品古を読み出す出席指示告を書き込む (入力カプル:‘出席指示Üf)
不足の確認 3 (出力カプル:、不足分出席命令書・)在庫を管理する 2 (出力カプル:‘入J!l[内容以・)在庫ファイル(入力カプル:‘・)

倉日f係から納品ill を読み出す出席指示告を書き込む (出力カプJレ : ‘納品iL~・)
在庫不足リスト(山カカプJレ:‘・)不足の登録 4 (入力カプル: ‘不足商品・)業者へ発注:与を書き込む(入力カプル:‘発注ún
在民可ミ足リスト(入力カプル;‘・)
取引先(出力カプル:‘・)出席の窓口業拐をする 1 (入力カプル:‘不足報告・)依頼者から出店依組京を読み出す不足辿絡を告さ込む(出力カプル:‘出席依頼諜・.入力カプル:‘不足連絡・){舵買者名簿(入力カプル:、\出力カプル:‘・)

国 13 ミニスペ守ク (CASE

B
e
n
c
h
)

時閣がなくなったので，あと少し感想、 を述べて終りにします .
まず第 l は，思ったより作業が進まなかったということです.

1 日目は簡単に進んで.この分では明日の昼にはできあがるなとかいってたんですが，いろいろな試行錯誤(やり直しとか)が発生して.予想通りには行きませんでした .
2 番目にツール操作ですが .
それから.

これはもう大変簡単でした.

3 番目ですが. CASE ツール以前の問題が多かったよ うに思います.方法論の習熟度が低かったための誤りやムダが多かったように感じました.もっと事前にみんなが勉強してきていれば，より大きな成果がえら れたのではないかと思います.
それから，人数が多すぎました.これは，どこのグル ープでもそ う感じられたと思います. CASE ツールを使ったという満足感が得られなかったのです.システム分析というのは非常に感動的な仕事で.何かごちゃご

ちゃしたもの.どろどろしたものが.ある瞬間にパッときれいにまとまっ てそうだ，これで行こう! J という感動があるはずだなのですが，今回は.何かいちおうできあがったんですけれどもああ，こんなもんか! J という程度の感覚でした .

それが方法論のせいなのか，人数が多かったせいなのかは，わかりませんが .... ですが，

「 もっとツールを使いたかった J. r 成果物の検討をもう少しやりたかった J. r プリントアウトの操作が不便だった」等の感想も出ました.これは，人数が多かったせいで，レビューのためにいちいち中間結果をプリントアウトするのですが.それには.いったんエディタから抜けてコマンドを打ち込む必要があり.そのあたりもう少し楽にできないのかなという意見です .あと 「 いまの自分の仕事には生かせない」という感想もありました.
最後に，私自身の個人的意見をいわせていただくと，構造化分析の方法論自体がほんとうに役立つのかどうかについては，研究者の方 々 はいろいろおっしゃっていますが.まだ確信を持つにはいたっていません(笑い) . た‑118‑

SeamaUVo1. 6 , No.8・9-10・11

MoriokaWorkshopReport

だ.もしこの方法論を使うということが決まった場合には，ツールというのは大変ありがたい存在だと感じました.

Q ( 奥村吉彦，

CSK)
: CAS
EBe n ch そのものに関する質問です.

1 つのバブルに出入りするフローについて，

たとえば 5 っとかいう制限を設けているというお話でしたが.それはどういった仕組みになってるのですか?
A ( 渡部健次.ソニーテクトロニクス):

5 個というのは，あくまでデフォルトの値にすぎませ ん .ユーザが自由に 1 0 個とか 2 個とかに変えることができるようになっています.
Q ( 奥村吉彦) : 今回与えられた演習問題のシートは.一種のインタビュ ー シ ー トのようなものだと思います .
それを D F D のような道具を使って整理して行く過程で.問題のいろいろな側面が見えてくる.整理が一段落したら ， それをモジュール構造図に落とし，さらに C プログラムのスケルトンを生成するという手順ですが，その過程で ， 手作業でやる部分と，コンビュ ー タで自動化する部分との切り分け分けが必要になってきます.そのへんはどうしたらいいのでしょうか?

A ( 渡部健次) : 何の切り分けですか?

Q ( 奥村吉彦) : マニュアルでやる仕事とコンビュータ化できる仕事との切り分けです.

A(渡部健次):コンビュータ化というのは，ツ ー ルによる機械的チェックとか.自動生成とかいうことですか?

Q ( 奥村吉彦):
でしょう?

そうではなく.対象業務の中でどの部分をコンビュータ化するかです . 何らかの区分けが必要

今の発表だと，全部が最後にはソースコードになってしまうような印象ですが，そうではないん

じゃないかと思うのですが..

A(渡部健次) : 一応，ト ッ プダウンで DFD を作り.仕様を書いて構造図を作るという設計プロセスが.上から下まできれいに涜れることを前提として.ツールが作られているんですが，実際には，もちろん.そんな風に

は仕事は進まないわけで.要求仕様が完成したら，自動的に設計ができるなんてことはありえません.
ですから.あそこで出てきた構造図のスケルトンは，大まかな設計書のひな型だと思ってください.ところで，その構造図の源になってるのは要求仕様そのものなので，それは ， 一応構造図の形はしていますけれども，要求仕様のある表現だと見ていただきたいのです.ですから，最終的には構造図をエディタの上でバラバラに分解していただいて，そこで人為的な，おっしゃるような，つまり大まかな設計書の完成という作業が次に始まります.
それからスケルトン的なものを作るということになります .

Q ( 奥村吉彦) : モジュール図まで行ってから.そこで選択するわけですか?

たとえば.その制御精進を見て，たいていマニュアルでやる部分.機械化する部分に分けますよね.その後で，機械化する部分をモジュ ー ル構造まで最終的には落としていくんですけど.そこあたりで，どの部分を機械化するかを選択することによって，全部がソ ー スコ ー ドになるというわけじゃなくて，その見切りができるような仕組みは別にないのでしょうか?
A( 佐原伸) : 難しいですね.

CA SE ツールといっても.すべて自動的に判断してくれるようなことは期待できません.どの部分を構造図に落とすべきかどうかは.歳終的には人聞が判断せざるを得ないでしょう .

いまから100 年後はどうか知りませんが.現在の C A SE ツールには.そんな仕翁けはありません.
Q ( 奥村吉彦) :私がいいたかったのは.とりあえず全部自動化するということを前提として分析を進めるとして，ある時点で人聞がチェックをかけて，それに従っていく部分をどこに入れたらいいのかなということです .

A (発言者不明) : 私も事務系のシステムをやっていますが，分析というフェーズでは，ある程度業務の全体が見えています.そして，分析対象業務の中でここを機械化しようというタ ー ゲット.つまりドメインも決まっていて.それを詳細に分析して行くと.当然機械化すべきところもあるし ， 人間の手作業が必要な部分もある .
つまり.分析の結果を D FD に落として行ったときにできあがるバブルの中には.もしかしたら機械化しなくてもいいプロセスが交じっています. D F D をそのまま構造化チャートに変換すると.それぞれのバブルから 1
つのボックスができ.入力と出力が決まり.ミニスペックも，さらにはモジュール仕様書もできてきますが，必ずしもそれらをすべてコ ン ビュータ・プログラムにするわけではなく，どこかで切り分けをしなければなりません.
そういう意味でいえば， D F D から構造化チャートへの変倹は，ある種の論理的モデルの作成であって.実際‑119‑

SeamaUVol.6 , No.8-9-10・11

MorlokaWorkshopReportに開発すべきソフトウェアの精進を表す物理的モデルを作る作業は，それとは別に必要だというような気がします.
Q( 天池学.カシオ計算機) :CASBBench にはそういう切り分けを支援する機能があるのかということですね?
A( 渡部健次) :われわれのツールはただ，ふつうの構造化分析の手順を機械的に支媛するだけのものです . デマルコの教科書に書かれているのは . 何をどう変換するか，あるいは構造図に落とすか，それをどうフォーマッ
トしどう分解するか . そういった手続きだけです . 構造図が意味しているのは.あるモジュールの機能が全体の中でどのように位置づけられるかということだけであって，それをそのままコードに落としていいかどうかということではありません . 構造図の中のマンマシンのバウンダリを自動的に分析し判断してポンとプログラムに変換する，そんな夢のようなツールは.まだまだ当分でてこないと思いますが . .
Q( 奥村吉彦) : 渡部さん自身は ， そうした自動化の方向はそれほど重要だと考えていないんですか?
A( 渡部健次) : ツールを使う人聞のほうがちゃんとわかっているわけですから，切り分けて使えばそのように使えるということでしょう . 論理モデルと物理モデルとの区別は，あくまでも人聞の側の認識の問題で，どんなツールを持って来ても不可能だと思います.す .
Q( 奥村吉彦) : 実際に.私自身がシステム分析とか要求定おとかをする場合には.まず最初は物理的に見て現状がどうなっているかをモデル化しします.その結果を眺めながら，ここはこういうふうに変えた方がいいのではないかという形で，新しい論理モデルを作る . 次に.それぞれの徳能をどこの部署がやるのか，誰が担当するのかという話になって，再び物理的なモデルに変えて行く.
そういった論理的なものと物理的なものとの切り換えを.たとえばワープロ的なイメージでもいいから，はた
して CASB Bench というツールが.どこまで支媛してくれるのかという疑問が頭にあったので.こんな質問をしたのです . そのへんは，あとで個人的にお話を聞きたいと思います .
3 つ自の質問ですが . グループの方の感想の中に.今の仕事には生かせないという意見がありましたが，具体的にど う い う ことなのでしょうか?
A( 上回賢一.

SRA): 私自身. CASB ツールについてあまり予備知識がなかったので，短時間でそれを使いこなせるレベルにまで到達できなかったということが 1 つです .

それと，現在の CASB ツール自体の完成度がまだそれほど高くないよ う に感じました . 私はいま ， 証券取引業務を担当していますが，一応それなりの設計支媛
ツールがあります.それに代えて CASB ツールを導入し.ほんとうに仕事に生かせるようになるには.まだかなり時聞がかかるのではないかというのが.私の意見です .
Q( 落水浩一郎，静岡大学):

必ずしも否定的な意見でないことはよくわかりましたが，ただ，新しい技術が出てきたとき，いますぐ使えないからといってつぶしてしまったら.いつまでたっても現状から脱却できないわけで，そのへんについては.どういうふうにお考えですか?

A( 上回賢一) : 昨夜 ， 飲みながら渡部さんとお話したのですが，仕事に導入するのではなくて

1 人 1 台ずっ

そ う したツールを載せたマシ ン を与えておいて，遊びながらでも一応の使い方を覚えさせ，それから自然発生的に仕 事 に生かしてみよ う という考えが生まれるのを待つ.そうしたアプローチが最適ではないかと考えています.

Q( 天 池 学 ) :A( 上回賢一):

環境が整わないとできないということですか?
いや .

ちがいます.個人の能力とか意欲の問題だと思います.

‑120‑

SeamaUVol.6 , N
o
.
8
‑
9
‑
1
0
‑
1
1

MorlokaWorkshopReport

4.StP グループの発表
時間もないので，簡単に報告します .

まず作業経過ですが，中間発表でいったように， 2 グループに分かれて作業を進めました.最初は，コンテクストダイアグラムとダイアグラム O の聞をを行ったり来たりしながら.作業を進めていたのですが.いまから考えると，ツールをただエディタとして使っていただけではなかったかと思います.つまり，ツールの使い方をみんなで覚えたという段階でした.

最初は，方法論を何も考えずにとりあえずスタートし.外部エンティティの洗い出しについても . 何を基準に洗い出したらよいかわからないまま.思いつきにしたがってやっていました.データフローから考えるという原則を無視して.機能からデータフローを考えるプロセス中心のアプローチです .

ファイルについても同様に.プ

ロセスに必要なデータを入れようという考え方でした.あとデータフローの本数ですねいくつかの線を l 個にまとめていいのではないか? Jr いやそうではない! J というあたりでもめていたのが 1 日目です .
中間発表でも述べたように.次の日には 2 グループの成果をマージするということになっていて，これは比較的簡単に終わるとと思っていました.その時点で，インストラクタの桜井さんおよび荻原先生のほうから ， 名前の付けかたについて注意がありました.
たとえば.プロセスに関しては何々を処理する」とかいう名前ではだめだ.処理するというのは「する J と一緒なので.何をするのかということを考えなさい.また.データフローについても何々情報」では何のことだかわからない.何のデータなのかをはっきり示す名前を考えなさい.また，それぞれのダイアグラム単独で何のことかわかるような名前をつけなければいけない .
このような指摘をうけました.

それまで.なぜみんなが安易な名前をつけてたかといえば，プロセスから考えてデータフローを作り，名前をつけようとしたので，それぞれの名前がはっきりしなかったのです.
そこで.コンテクストダイアグラムを書き直しました.今度は.ダイアグラム O を作る時点で，まずそれぞれのデータ定義をはっきりさせることにしました.データ中心で考えたコンテクストダイアグラムは図 14 ，それを詳細化してできたダイアグラム O は図 15 のようになりました.あとはもう時間もなかったので.ツールを使っていろいろなチェックをしただけです.

コンテキストダイアグラム
北国内リ乍

者一一
出知者前

{ f { : 守口
のののの

本本本本

V

¥

、

ノ

最後に借りた人に関するリスト

貸出の不可

国 14 コンテクストダイアグラム (StP)

‑1
2
1‑

o
.
8
‑
9
‑
1
0
‑
1
1
SeamallVol.6 , N

MoriokaWorkshopReport

?

可
<

式

本に関する11) スト A
本に関本の{司出者!本

最主主

国 15 ダイアグラム o (StP)

全体的な感想、を以下に述べます .

まずツールについてですが.箇条書きにすると次の通りです:(1)操作が少しまどろっこしかった(ツールの操作性に問題があったのか.それとも習得の容易性に問題があったのか.はっきりとした答は 2 日間では出ませんでした) .
(2) ダイアグラムを同時に 2 つ開いて，比較しながら設計を進めたかった .

(3) 何のために CASE ツールを使うかという問題意識を持った人聞が使わないと意味がないような気がする.

(4) ナビグーションの支援が必要だ.
(5) グループの中に l 人だけ，

2 年半ほど前に StP を使った人がいた.かれによれば，ユーザインター

フェースは以前より大分改善されている .

(6)CASE ツールが保守作業をどこまでカバーできるのかは疑問である.
(
7)CASE ツールは .ワープロとして見ると非常にすばらしい!
(8) いまの CASE ツールは制御系への応用を中心に作られているように見える.
次に.記法についての感想を.やはり箇条書きでまとめます:(1)DFD の記法で システムの概念を完全に表現することはできないのではないか?
(2) 方法論を理解せずには， DFD は美しく書けない .まともな物ができあがらない.

(
3) CASE ツール自身の標準化が必要である.ツールごとに それぞれ独自の方言のような記法が出てくるのはまずい.統一的な記法をはっきりさせたほうがよい.

(
4) DFD はなじめない，人に説明しに くいー

これに対しては反対意見も出て.議論を呼びました

記

法をユーザが理解できるのか(一般的でない)という意見や，ユ←ザもやはりプロセス中心の考え方をしているので，データ中心の記法でよいのかという疑問も出ました.
方法論については，初日に説明を受けて，一応はわかったつもりでいたのですが.ほんとうのところは理解できていなかったので，実作業でいろいろと悩みました . 分析者とユーザの 2 役を演じたのですが.どこが方法論‑122‑SeamallVo1. 6 , No.8・9-10・11

MorlokaWorkshopReport

でサポートされている範囲なのかがうまくつかめず ， その結果として，自分がいま何をしているのかがわからな
く なったことが ， 途中で何度かありました.同じようなことですが . 分析と設計がごちゃごちゃにな っ てしまった(たとえば. DFD を書いてるつもりが . 実際は構造図を書いていた)といったことがあります .
グループ編成についてですが.

1 つの課題に 9 人は多すぎたと思います.われわれのところは.

ws が 2 台あったので，それぞれ 4 人と 5 人で使わせていただきましたが.それでもまだ人数が多かったように感じました .

課題の選択にあたって ， 私たちは図書館システムを選んだのですが，結果的には，問題使用書の日本語の少なさにだまされてしまったような気がしました(笑い) .
最後に，グループの中でアンケートを取りましたので，結果を報告します .

まず.課題の数や難易度は.ちょ

うどよかったのではないかという意見が圧倒的多数を占めました.記法と日程については次の表を見て く ださ

1.記法は?
わかりにくいわかりやすい自分自身にとって8

ユーザにとって

4

5

開発者にと っ て

5

4

2. 日程に関して

短すぎる

ちょうどよい

長すぎる

全体

4

5

。

チュートリアル

2

5

2

課題演習

5

4

。

討論

9

。

。

5
.Teamwork グループの発表
最初に経過説明をします.課題としては ， 給湯システムを選択しました(図 16) .
給湯水疏スイッチ

噌自給水

ー←ガス

‘遍‘スイヲチ

lmg J

遭‘スィ 7~:1
8CC三 ::;:;|MCM 烈度:‘~.Ilつ重み‘~追いだ・ s・L---・」

国 16 jf ス給渇システム

‑123‑

・

SeamaUVol.6 , No.8-9-10・11

Mor1
okaWorkshopReport

中間報告で簡単に紹介したように，まず課題を理解してコンテクストダイアグラムを作成しました.そのあと第 1 版の DFD 作成の過程でいくらか紛糾しましたが， 2 日自の午前中に DFD およびコントロールスペックの一部ができあがりました.すべてツールを前提として作業を進めようという方針で.コンテクストダイアグラムの作成にさいしては，外と内との切り分けをまず行い，それからデータフロー.次に構造図を考えるという教科
書通りの手順にしたがいました.

全体としては順調に仕事が進みましたが， 2 点ほどちょっとした問題がありました.

1 つは，ハードウェアモ

デルとの混同.たとえば，風呂がまとか給水といったような部分についても.コンテクストダイアグラムに書こ

うとしたことです.実際にはそれらは情報として必要がありません.もう 1 つはデータです.最初は，ふつうのアナログデータと (0 ， 1) の信号だけで，データとコントロールフローを切り分けながら奮いていたのですが，ほんとうにそれでいいんだろうかということが ，あとで議論になりました.
こうしてできあがったのが図 17 (中間発表の図 11 と同じ)に示すコンテクストダイアグラムですが，このあと，第 1 階層の DFD を作るときに ，大きな意見の 相違が生じました.つまり.中間発表の図 12 に示したように，お湯をはる ， 追いだきする ， 給湯するという 3 つの主要機能をペースとして.機能主体で考えて行こうという方針で進もうとしたのですが.これに対して.どうもそれでは具体化にさいしてムダが多いとか.やはりデー
タ主体で考えるべきだとか.いろいろな意見が出て.議論が発散しかけました.

ぉ迦 1

ぉ i誌の，畠I主

ノ柑//

可渇の

-1<渇 UI

一..c:火信号.

国 17 :1ンテクストダイヤグラム (Teamwork)

そこで，この日は，各自が第 1 階層の DFD を見直し.ちょっと頭を冷やしてみようということになりました .

結果的には，佐原さんが忠告されたように.最初から具体化のことを考えるのはあまりよくないということがわ
かり.そうした反対意見は取り下げられました.一晩考えた結果.ある程度は意見の統ーができたわけです.

しかし，みなさんが考えてきた案を見ると.やはり 2 つのパターンに分かれる.幸いマシンが 2 台ありましたので，2 つのチームを作り，それ ぞれ独立に DFD の完成を目指すことにしました.

まず， A チーム.これは.機能に着目して ， まずプロセスを決めています.コンテクストダイアグラム中の給湯システムというバブルを，給湯，追いだき.お湯はりという 3 つの機能に分割し .それぞれの プロセスがどういうデータを変換しているかを考えるという手順ですin と out は.すでにコンテクストで全部決まっているので，その 3 つの機能がどういうふうに振り分けられるかを考えます.まずデータフローに着目してその処理を‑124‑

SeamaUVo1. 6 , No.
8
‑
9
‑
1
0
‑
1
1

MoriokaW orkshopReport

考え，コントロールスペ ッ クは後で考えるという形で作業を進めました.
一方の B チーム .

こちらは . データの涜れに着目し，まずデータを out から i n の方向でトレースして考えています.こちらに in が全部あり.コンテクストで out が全部決まっているので，それぞれの o ut データが変換されるプロセスとしては何が必要かを.逆方向から考えて行きました

そして.入出カデータができるだけ少な

く(できれば入力 1 で出力 1 に)なるように.プロセスを構成して行きました . A チ ー ムとはちがって，データ
フローとコ ン トロールスペックを並列的に作って行きました.

それぞれのチームが作成した DFD を図 1 8 ~図 1 9 に示します.図 18 ~ 21 が A チーム，図 22 ~ 25 がB チームです . 図の形式だけでなく，内容的にもかなりかけ灘れたものにな っ ています.
まず . A チームですが.こちらは . 給湯・お湯はり ・ 追いだきという 3 つの軽量能を中心にしてデータを集中させ . DFD を 段階的に階層分解しています .

~~官 珂 f~ 号

追いだき f~ 号

nv・­

H伊

モ二ド. .

向田町

n
h
J

川崎

信

f

涜

，、

4・

‑
'

,

.

渇
・
・

火k\\可

.
.

.
.
.
.

\お

木嵐ハル 7 開度

“u

・実

・

開閉f~月/ノ~
ノ/ー.....--

1
.E

-・ 木

木皿鳩山信号

d

.
.

R
,

.
.
.

ルブ悶r

\主主
ーーー-!宣定

国 18 A チームの第 1 階層 DFD (Teamwork)

‑125‑

‑4

‑ｭ

‑
‑

• •• ., .••.
•
お渇 U り雪~t 信号

.
.
.
.
.
.
‑

.
1

'
SeamaUVo1. 6 , No.8‑9‑10‑11

MoriokaW orkshopReport

、

水定

/ーー、、

¥¥
オt

'1 - カー-ーテl1 鎗渇を開始す苦手，逼 iè ~ ~耐 i5 ~O ………ー削""雪ゐ“ íRl.!.

‑…

国 19 A チームの jß2 階層 DFD: 給泌する (Teamwork)

・E
B-

白骨 \

は

湯

お

お湯 1: り完7守重号

.
.
.
.
3
>

J
!

国 20 A チームの第 2 階層 DFD: お湯をはる (Teamwork)

11J

白守\
信.

L

'c

追

.だ

・

.追いだき美寺f!号

信号--争

..・.

- ・・ふ

\可刊と\

少逗ベベ之町主::;レブ提言\、

国 21 A チームの第 2 陪層 DFD: 遣いだきする (Teamwork)‑126‑SeamailVo1. 6 , No.8‑9‑10‑11

MoriokaWorkshopReport

一方 B チームのほうは.データを中心に考えて.火力だとか出入量だとかを処理するようなプロセスは何か ，

たとえば弁を開閉する ・ セ ン サを監視する ・ 湯釜を制御する(温度を制御する)とい う よ う なプロセスを作っています.このグループでは. DFD と並行してコントロールも考 え ています .

/~水量 〆
/
BhJ

Jg

掴/

火

切笛信号戸-

ち，

出本完了信号
号
偲H

rp ‑ ‑

号

モ\

帥
.

、.号

、

プ\

J

也

一

ラ

E

r匂崎
t

信

A

..

..

プ\九

l

J

J

f

・ ・
.
F
7
.
1
ヘ ロu

，

;

/

/

'
J

-h

J

j

き

偲

3

、

f

tJ

・

:limi--

J

/

4
J

凶

沼

骨

刻

司

J

国 22 B チームの第 1 階層 DFD (Teamwork).~度各--々戸--戸戸戸火 "ペーよりレブ限度~不E

国 23 B チームの第 2 階層 DFD: 湯釜を制御する (Teamwork)

‑127‑

一・

一

~ itH

4

'

I

J/

日

/

.

白J
gJ

〆

ι-

f

¥

14
「斗ペバ

J

♂

山

一

…

6F
・

電J/f

-

戸

一号部号
~
悶

E

白

号戸

引

剛酬・・・・

置

浪

宮小.

相叫.遺

l ¥ ¥

•

4

\ [/・

~制定温

/

品、
川
.
飴/

〆

J

渇量差

翠皮革

SeamaUVol.6 , No.8-9・10-11

MorlokaWorkshopReport

違反差

。営住\\

¥

号
'e

山』

ゥ，
E戸
水 J

す叶寸川
号

才

J
・

a
'

ιτ~i，
-，号戸引

お退水

活~定信・オJ4

目白~w- き.・
日日時ごはり ~J

5- 濃い・涜

国 24 B チームの第 2 暗層 DFD: 弁を制御する (Teamwork)

違:f~霊一一人寸心\「
湯量差~ ・国 25 B チームの第 2 階層 DFD: センサーを監視する (Teamwork)‑128‑

MoriokaW orkshopReport

SeamailVol.6 , No.8・9-10-11

それから，状態遷移図は，図 26 (A チーム)および図 27 ~ 2
8(B チーム)のようになっています . A チームのほうは，だいたい第 1 階層( 1 番上のレベル)で制御がほとんど終わってます . 一方 . B チーム のほうの状態遷移図を見ると .

2 階層目で重要な制御が行われるような感じになっています.

l'llulti
孟 -

以

n吋

s
‑

m

'

茸雫

-【岨­

且守 vF

電/

z
‘

i
罰則

R

rP

出

リ

‘R， ・

P唱幽

‑n/

h

l

，今--­

E

2同

2

2
守 A1

-可・

.
っ Illi--x

2b

ln

-市/

‑
a
z
‑

お二h\

'
z

3Ef

Z 口町民認l，;thl
S電量三リ信号/モード・."昆ロリ"'.

国 26A チームの第 1 階層設建遷移国 (Teamwork)

・

Hdd

f

JリJ

J 考
-

li‑‑

・-シ

世号
室正
言韮

出草案

JI 理之り官"t.....シ・ J

eC::3oランプ・・7:〆・

追いだき宮号制7:ン :1

EC~ ::tラ〆 7・・...シ，

‑J

・

吾4 ・

z
=

・

•

百 d， 7，，同-，1

3 官J 7

C

，
，，
.，
--n
・

':・

7

山
Z

主 'lι1111
不•\:γ;':.;. ，; : '
副

H ・4

ア aク

J
・

ト
ua ，
， 『，
一
E，

d ゐ
〆 -

~ラ込

・

三りリ〆
山MEM-/
=c 逼/

本 Em/

一一一山泊

uw
泊予
2-リゐ
E込
京J7J
=白区，
RR11ili--

理埠

‑CRS

•

,,

i!?五三ヤイ

遣いだき ll"

互主三 1 .1 ~l 主

国 27 B チームの第 1 階層状建遷移国 (Teamwork)

‑129‑

i

Seama8Vo1. 6 , No.8-9・ 10・11

MoriokaW orkshopReport
t22事!~号..オン，l~~=j オフ. /方. .-三. .才ン./

バイパスヂ千..院'

バイパユ F=' 院じイ'l持 J信号オン /勿容信号=信槽，

切否定号 : .;::g 返せ ん，

追いだき信号..オン・/切号 j1;吾..~~量1lψ

*~さ..オフ./

穴才す支署士宮￨1:L

出増〈完 7

lm 減給

''

・!

ンア
オ亡

zE

-同支

芸，=

・

活=一
一

〈、

『λ T'

E1
4
7
p‑ｭ
i:

,

J
-

国 28 B チームの第 2 階層状態遷移図何回 mwork)

この状態遷移図と一緒に，プロセスをどの順番で起動するかというテ ープルも作りました.これで，データフ
ローと状態遷移図，それからプロセス起動テープルが全部そろったので.ここまでで SA は一通り終わったということで，ミニスペックと DD はまだ空のまま .ツ ールを使 ってス トラクチャチャートを出してみました .

さて ， 以上の作業を振り返って. 2 つのチームの聞の違いを比べて見ると，だいたい次のような感じになります.

A チームは.作業を進めて行 く上であまり考え込むことなく.定められた手順に乗っかった形で徴械的に」先へ進んで行きました.ところが .B チームのほうは.非常に苦しみながら.それぞれの図を作っていました.
1 つには，非常に細かいところまで気を配っていたといえるでしょう . コントローラと DFD を一緒に作っていたので，双方に矛盾がないかどうかを一々検証しながら.仕事を進めました.
A チームのほ うは.そのへんを全然気にせず， DFD だけをまず一気に完成させ.後からコントローラを入れるという感じでやっていました

その結果，機能を後でいろいろ手直ししたり， DFD を修正したりということが結構出てきました.いわば，試行錯誤というか.プロトタイピングというか.そういったアプローチだったといえます

ただ，その試行錯誤は結果として発散することなく ， 除々に除々にシステムの全容が見えてくるような感じで進行しました.

たとえばコントローラを追加すると，今まで静止していた DFD が生き物のように動くなあ! J と感心した
りここをこう変えたらうまくバランスがとれるのではないか? J と考えたり.といった感じでした .しかし ，

残念ながら時間切れで最後まで行けなかったので，この設計で正しくシステムが動くかどうかの検証は終わっていません .

それに対して， B チームのほうは.そのへんをかなり第 1 階層のレベルで詰めているので.完成度が高いような感じです.ほんとうなら両方のチームとも.最後まで SA のステップを完了し，結果を sc に落としてどうなるかを比較することができれたら，おもしろかったと思いますが.今回は途中で終わってしまったので，これ以上の議論は推測でしかありえません.

たとえば， A チームの仕事をつきつめていくと，最後には B チームのようになるかも知れないのです.また.

パルプの制御その他の機能が上のレベルにあがってくるかも知れませ ん.そのへんは最後まで行かなかったのでなんともいえないですが， 2 つのチームのアプローチの違いが最終成果にどうあらわれるかが見えなかったのがちょっと残念です .

以上，それぞれのチームの活動内容を報告しましたが.最後に，全員で方法論とツールについて少し意見を交‑130‑SeamaﾟVol.6 , N
o
.
8
‑
9
‑
1
0
‑
1
1

MorlokaWorkshopReport

換しました . 時聞がずいぶん押し詰まってから討論に入ったので.十分な議論はできなかったのですが.次のような意見が 出ています .
まず方法論についてですが J 次第にデータの意味がはっきりしてくる」という意見がありました .

これは，設計のプ ロセスを通じて .徐々に，あいまいだ ったデータや名前だけだったデータの意味がはっきりしてくるということです厳密な設計ができることがわかった」という感想もありましたこれほど厳密な設計はいままで

現場ゃったことがない J という声もありました(笑い) . これまではテスト段階でいつも苦しんでいたが，それが防げのではないかという意見です.否定的な意味ではありませんが .
あ J という意見もありました .

rSA/SD は思ったよりに時聞がかかるな

まあ，今まであいまいにしておいたことがらを全部細かく涜い出そうとしている

わけですから，時聞がかかるのはあたりまえです .

それからすべてが SA/SD で片付くわけではない」という意見もありました.他にも，もっとやるべきことがあるのではないかという意味です.
最後にツールについてですが試行錯誤がサポートされる J. r 知らず知らずに構造化設計ができている J. r ラ
フスケッチを正式ドキュメントに変換してくれる J.

こういうことはずいぶんありがたいという意見が圧倒的でした . rCASE ツールなしでは SA/SD をやる気がしない」という意見もありました.それからたった 2 日間
では初心者にとっては効果まで計ることができない」という声もがありました協調作業自然に支媛される J.
「 その意味で CASE ツールはコミュニケーションツールである J という意見も出ました.
ちょっと時聞をオーバーしましたが ， 以上で発表を終わります.

‑1
3
1‑

SeamaUVol.6 , No.8・9・10-11

MorlokaWorkshopReport

7. パネルディスカッション
報告者

古川勝也・太田勝(静岡大学)

落水浩一鼠(普岡大学):

昨日のアンケートの結果を 3 項目の論点に整理してみました.それをもとに，こちらに並んでいらっしゃるプ
ログラム委員・グループの代表・ベンダの方々に私が代表質問する形で.パネルを始めさせていただきたいと思います.

巌初の論点は「方法論の教育法」です.必ずしも十分ではありませんが.今回のワークショップで.ここに集まったすべての方々が CASE ツールに直接手を触れるチャンスを持ちました. CASE のねらいは.一定の手順・枠組みの中で.共通の言語を用い，コンビュータの助けを借りながら仕事をしようということです .

ところが，昨日のアンケートの回答でも，また，先程の最終報告でも.方法論が 1 つのネックになっているように感じられます . 方法論が役に立っか立たないかという議論は無意味だと思うので.角度を変えてずばりお聞きしま
す : 方法論を使いこなすためには.何をどの程度訓練すればよいのでしょうか?

2 番目の論点は「チーム作業の支媛」です.お互い共通の言語でしゃべれることは CASE ツールの一つの効
果でしょう .

しかし，より基本的な問題があります.設計は 1 人でやるのか?それとも何人かで分担するのか?

もちろん.どちらの場合ももあり得ます.

1 人で設計を行った場合には，その内容または結果を他人に伝達することが必要になります . CASE ツールはそのときどの程度有用なのでしょうか?記法が標準化さ れていること

は 1 つの利点ですが，それ以外に何かを期待できるのでしょうか?一方，複数で設計する場合には，仕事を分割して分担するわけですが . CASE ツールはそのとこをいったいど ういうふうに支援してくれるのでしょう?
最後の論点は rCASE ツールの効果」です.ずばり成功例と失敗例を知りたい.また，さしあたりどんな分野で効果があるのかも教えて戴きたい.ドキュメンテーション.リパースエンジニアリング等のキーワードが，このワークショップを通じて議論されてきましたが，ここでは，ベンダの方々から.御経験にもとづく情報を提供していただきたいと思います .

以上 3 つの論点について.壇上に並んでいる全員にお聞きすると . 1 人 5 分としても 2 時聞かかります(笑い) .
そこで，積極的に情報を提供してくださる方にどんど発言いただく形で進めたいと思います.
青木淳(富士ゼロックス情報システム):

オブジェクト指向の方法論について，何をどのように訓練すればいいかを，若干お話したいと思います.

まずみなさんに認識していただきたいことがあります.たとえば，今回の演習で使われた図書館問題を考えてみましょう. StP グ ル ープがこの問題に挑戦し . その結果，さきほどの愚終発表で示されたコンテクストダイア
グラムができあがりました.これをもとに図書館システムを設計することは，やろうと思えば，どんな方法でもできるでしょう .

しかし.ほんとうは，設計ができたあとが問題なのだと思います.オブジェクト指向の考え方

でこの図書館問題を分析すると.結果は図 1 のようになります.

オブジェクト指向特有の抽象化プロセスの結果として，問題に依存したオブジェクトの上位に，いくつか抽象的なオブジェクトが生まれてきます . これらが，次にまた遣うシステムを作るときの財産になるというのが，オブジェクト指向のメリットです . つまり.オブジェクト指向による分析・設計は，まずじっくりキャスティング
をして，それから映画をとるような感じです.そういう考え方に慣れてほしいと思います .

‑132‑

MoriokaWorkshopReport

SeamanVol.6 , No.8・9-10・11

R
円

z
h

宅年 駅

氏 三世

自老 町
忠 作 品ι

ム'~Iiの追加 .削 除
亘書の貨出 . 返王J
作者でリスト作尽
分野でリスト作足引鳥者でリスト f乍 ぽ
:t:で最終和j 局者の挨冥

国 1 図書館システムのオプジェクト指向分析

それはどうすればやれるようになるかといえば，やはり . ヒュマンインテグレーションを考えられる人が.オ

ブジェクト指向には向いていると思います . これができない人は構造化手法でやっていてくださいということになります .

天港学(カシオ計算標):

ヒューマンインテグレーションとおっしゃいましたが，具体的にはどういうことですか?
青木淳:

登場してくるオブジェクトの役割を決めて.きちんとヱンカプセレーションし.それらの間での円滑なコミュ
ニケーションを考えなければなりません.それは，ちょうど.複数の人聞を集め . チームを組んで協調作業を計画するモデルと非常によく似ています . そういうことをうまく考えられる人が.オブジェクト指向に向いているということです.
天漣学:なるほど，キーワードは協調ということですか.
平尾一浩(ヒラタ-ソフトウェア・テクノロジー):

青木さんのチームにいたのですが，抽象化で非常に悩みました.いまの図書館システムの例で ， たとえば「書ii J を抽象化して「著作物」という概念を出されましたが， 一 歩まちがえると紙」とかいうような変な抽象化をしてしまうと思うんです.そのへんの思考のポイントっていうか . 何かあれば教えていただきたいんです
が. .

青木淳:

抽象化で出てくるクラス階層には.その人が考えている概念のカテゴリみたいなものが ， 正確にマ ッ プされてしまう . そのさい注意しなければいけないのはやっぱり協調の問題であって.関係者がそれを妥当だと思うかど
うかにかかっています紙」という抽象化は，問題ドメインを経済的に表現していないので，明らかにまちがい‑133‑

SeamaUVol.6 , No.8-9-10・11

MoriokaWorkshopReport

です . この例では図書を著作物の一種だ考えていますが，たとえばプログラムも著作物の一種であり.それをだ

れが作 っ て，どうい う 題目でという属性が付属しているわけです.その意味でこの抽象化は非常に経済的であり ， 応用範囲が広い . そういったことを考えなければならないということです.
平尾一浩:

自然な思考の涜れの中でオブジェク トを切り出して .そ れか ら構造や属性を決めていくときに 抽象化をするのがふつうですよね?しかし.いまの青木さんの話だと.最初のうちにに属性まで先に考えておかないと.抽象化が難しいような気がするんですが....
青 木淳:

そうです.その通りです.だから.分析のプ ロセスをウォーターフォールて' 考えてはいけません.オブジェク
トを完全に全部洗い出してからどうこうするというではなくて. 1 回すうっとやってみる.で，何かが足りないことがわかって元に戻る.まさにこの反復のプ ロセスが必要だという話です佐原仲 (SRA):

SA/SD の教 育に関して述べます.この 方法論を使いこなすには ， 基本的には.日本語能力そして鏑象化能力があることが，たぶん要求されると思います.

そうした能力は ， それぞれの人に勉強して もらうしかありませんが.では .構造化技法を 何日で学べるかとい
えば ，

まずテキストブ ッ クを 1~2 冊読む必要がある.これはまあふつうのエンジニアなら 1 週間で読めるでしょう.もちろん人によっては 1 ヶ月くらいかかるかも知れません.次に，それらの本の中の演習問題を ， ツー
ルを使ってトレースしてみることが重要です.本を書くような人は.だいたいそれなりにできる人ですから.その人の考えた解法をたどってみると，それなりの効果があります.これはたぶん 1~2 日でできるでしょう . 当
然、一緒に CASE ツール の使い方も学べる わけです .

逆説的にいえば J 問題を解くときに自分の頭で考えない」というのが.アマチュアとしての正しいやり方です.
つまり，教科書のどこかに図書館問題があったなと探してみる.そうするとたいてい出てくるんですね

その解答をなぞることで.かつてそれを解いた人のレベルにまでは行けるわけで.それ以上何か新しいアイデアが必要になった場合に，初めて自分でもう少し考えてみる.

すばらしい設計をするのには，たぶん.さきほど青木さんがいわれたような適性がないとだめでしょうが，ほどほどの設計をする程度のレベルになら.一生懸命やれば 1~2 週間，仕事のかたわらやって 1~3 ヶ月ぐらいで到達できるだろうと，私は思います.もちろん，大きな問題にアタックするときには，方法論がよくわかってる人の論義を聞く(あるいはセミナーを受ける)という形で力を補うことが必要です.そうやって行くうちに.もう 6 か月くらいたてば結構ベテランになってきます.

オブジェクト指向に関しても一言いわせていただくと，私は実はいまオブジェクト指向を勉強中なのですが.
さっきの青木さんの意見には反対です.この方法論も. Smalltalk の中にすでに用意されているクラス階層を勉強したり，すでに解かれた例題を勉強することによって，かなり早くそこそこのレベルに到達できます.最終に作ったものがすばらしいか，さほどでもないかというところで，能力の差が出てくると思います. Smalltalk 中のクラス階層を知っていれば ， だれでも.そこにコントローラというものがあるのだからこの制御スイッチは
コ ン トローラの下に入れればいい」という程度の判断はできるでしょう.ゆっくり勉強して 3 ないし 6 ヶ月.

6 ヶ月たてばかなりのベテランといえる感じになると思います青木淳:

OOA/OOD を習得す るための期間ですが，私の例でいうと，何もないところから独学で約 2 年かかりました

いま，そういう人を育てるのには，やはり 3 ヶ月はかかるでしょう.つまり.よいナビグーターがついたとして3 ヶ月かな?という感じです.

落水浩一郎:

では ，次の話題に移ります . 大規模システムを作る場合とか.複数人で作業するときに. CASE ツールがサポートしてくれる機能は何かということですが，どなたか.... ?

田中錫市(東陽テクニカ):

‑134‑

o
.
8
‑
9
‑
1
0
‑
1
1
S
e
a
m
a
l
lVol.6 , N

M
o
r
l
o
k
aWorkshopReport

Teamwork の場合.基本的にはワークステーションをベースに動いていますので，ネットワーク上で一元化された(分散ではなく集中型の)データペースを持っています . それをチーム全員で共有して作業するというのが基本です.そういう意味で，協同作業を支媛しています.それからもう 1 つは，モデルが途中まで(ある階層まで)できたときに，そこからいくつかに分割された徳能をグループごとに分担して詳細化するさいに ， 作業用のモデルを簡単にコピーできるようになっています.そしてグループ別に作業を進め.最終的にそれぞれの部分が完了したらそれらをマージするという徳能があります.
務水着 -JII:

情報格納庫というかデータペースを通じて支媛するということですね?
田中観市:
はい.データペースを一元的に管理するということと.世代管理をきちっと行うこと，それから派生的にモデルをコピーして作業を進められること.そして，結果のマージについても ， 衝突を回避しながらマージするというような徳能が用意されています.
落水浩一郎:

伝達についてはいかがですか?だれかが設計した結果を他人に教えるさいの支鑓機能はありますか?
闘中錫市:

それについては，日本ではまだお客さまからそういった要求はありませんが，アメリカの場合には，ある大会
社で.会議にワークステーションを持ち込んで，直接ビデオプロジェクターに投影して討論し，変更箇所が出たらその場で直していくといったことをしています.グラフィックスが中心になっているので，そうした場合変更
箇所が見つけやすいというのも. SA の手法の特徴だと思いますが ， それを生かしているということです.

それぞれのツールが，文書化に関しては DOD の 2167 とか 2167a という標準形式にしたがっており.そうしたスタンダードも，また，紙の上でのコミュニケーションを円滑にする働きをすると思います .
蓑原剛(大阪大学):
共同作業や意思伝達については.一般には.数人で作業をやって行く中で.何か問題が起こったときに.ごちゃ
ごちゃ集まってどうしょうかつて相談をすることの支鑓(いわゆる CSCW) が.話題の中心になっている感じですが，作業の進行とか進惨状況自体の管理まで CASE ツールで支援できているのか?あるいはするつもりがあるのか?そのときどんな支援機能を考えているのか?そのへんについて.ベンダの方々から少し情報をいただけたらうれしいのですが.. ..
桜井廓里 (SRA):

現状では . StP の場合でいうと ， チーム・メンバの作業の進惨状況を見ょうと思ったら.データベースの内容を見に行き，そのメンバが担当したモデルがいまどこまでできているかを調べる以外にやり方はありません.もちろん，作られたモデルや図の一覧とかは出ますけども ， 作業の進捗を正確に把握するには.データベースの内容を調べる以外にないと思います .
落水浩一郎:
モデルっていうのはプロダクトのモデルですか?
桜井康里:

はい.そうです.作られた DFD とかがディスクに入っていますから . 管理者がエンジニアと同じツールを使ってそそれを見て行く以外には方法はないと思います.それから.さっきの作業分割の話ですけども，分割はもちろんいつでも可能ですが，概観図というか.全体のコ ン テクストダイアグラムのところは，やはりだれかが統一見解を強引に出さなければいけません .

ツールの話ではなく.どうしても基本のモデルをきちんと決める必要があります.
落水浩一郎:
では次に，成功例と失敗例について.これは，ベンダ全員にお答えいただきましょう .
田中錫市:
たぶん ， 落水先生が満足される答えにはならないと思いますが.現材. 具 体例として私どもが資料をお出しし‑13S‑

SeamaHVol.6 , N
o
.
8
‑
9
‑
1
0
‑
1
1

MorlokaWorkshopReport

Eているのは.英国のドレッシーという会社の例です . この会社は . 軍事システムを作ってる会社ですが，マイクロプロセッサを 10 台ぐらい並列で処理するようなシステムを開発し，出荷後に問題になったパグがわずか 3 つ

話

ふい、問問

ぐ らいに押さえられたというケースです.これは ， ヨーロッパの雑誌に報告されています.

SA/SD を使って非常に うまく行きました . CASE ツールががまだ導入される以前の成功例です .ですから. CASE ツー ルを使えば.生産性・信頼性がさらに向上するというので，ボ ーイング社には .すでにいろいろ

同担 4M

で.

a
、， ，

それから，たぶんハートレーだと思いますが ， 構造化手法の成果として取り上げていた例として.ボーイング
737 のケースもあります.その システムはやはり，マイクロプロセッサが 150 個ぐらい組み合わせたシステム

信

な会社のツ ールが，それ ぞれかなりの本数入ってるそうです.

合憲夫そ

務水港一郎:

日本での例はありませんか?
問中錫市:

私どもの場合にはまだありません .
渡書Z 健次(ソニーテクトロニクス):

何をもって成功 / 失敗というかですが. CASE ツールがシステムのライフサイクルの中に銀づいて ， 企業のやはり，ある企業に CASE が導入されたとして，その後継続的に利用され運用されて行く，そうすれば. CASE
ツール自体が 1 つの系統的な手法を持っていますから，ライフサイクル全 体の中で一定の効果を生み出す，そうよてら含

中でずっと使われていくことが大切だと思います. B-737 みたいなワンショ ット的なケースもさることながら .

育いうことが基本だといえましょう.逆に失敗というのは，ワークステーションがあり .CASE もあるだけで機械があるだけだれもさわらないという状懸です.
ィ、そういった意味では，われわれの場合は，コーディングなどの原状の作業を大事に考えています.あちこちで再三申し上げていますけども.現在あるコードから構造図に落とすという単純な機能をベースに.データフロー

図を仕上げる.そして，そのデータフローに新しい周辺部を加えて設計仕様・構造図を再構成するというサイク
ルが組めます.

してお|

議水清一郎:

それは ， 原状から CASE の世界に移って行くための 1 つの手段として.すでにあるコードを仕様の世界に逆果は保証されますか?

のまころ

変換し.そこで新しいコードを開発するというリパースエンジニアリングのアプローチだと考えられますが，成佐

渡宮Z 健次:

それはやはり問題意識ですね.問題意識を持って，こういった手法でやっていこうと考える.こういう 方なら必ず成功します.

本ほ

務水溶一郎:

ユーザーの責任にされるのはいいんですけれども.一方，導入したら必ず成功するという保証がないと，ユー

fcSPOOL

SA/SD は方法 論としてはすでに確立されていて.アメリカなどでもかなりの実績があるわけですから，その点についててはまったく疑いを持っていません.

重厚

渡部健次:

渡かうそ法でザーとしてはなかなか踏み切れない.そういうジレンマがあると思いますが.

桜井康里:

いま 2 人の方がいわれたことを受けて，お話したいと思います .

ワークステーショ ン上の CASE ツールは .

現在は.まだ導入・試用段階です .

StP のユーザの場合もさまざまです.うまく使っているところもあれば，全然使わなくなったところもあります，どういう場合にうまく使われないかというと，まず，問題意識も何なくてただ単に買ってみただけのところ

‑1
3
6‑

・ を

とか，担当者がたった 1 人だけで周囲から源立しているところです.そういったユーザの場合は.最初いろいろ聞いてくるのですが，その う ちまったく質問が来なくなってしまう(笑い)

444 、ての成果はまだでていないと思います

青いい人

日本では 2 年前位から使われ始めていますが，それをを使ったソフトウェア・プロダクトがうんぬんという形で

SeamaUVol.6 , No.8・9-10・11

MoriokaWorkshopReport

うまく行っているユーザ.とにかく積極的に使って下さっているところは.まず複数( 3 人位)の担 当者がいます.そうすると.わからないことがあればお互いに相談できるし.それでもわからなければベンダに問い合わせるといった環境になります.特に，方法論上の問題や分析の進め方などに関して，よい指導者がいるとか，仲間どうしで相談しあえるということが大切でしょう.試験導入とはいっても.録低 2~3 人の人がは使えるよ
うな環境設定と周囲の理解，そして問題意識.それだけ整えば，技法的には確立されていますし.みなさんも今度のワークショップで実感されたと思いますが . いままでできなかった設計時点でのテストとか，誤りの発見とかができるわけですから..
佐原伸:

成功例ですが，われわれがが自分自身で StP を使った時には成功しました(笑い) . それから，まったく問い
合わせも質問も来ないユーザーの中に，アメリカで StP を作った先生の弟子だったという人がいて，これはある製薬会社なのですが.ここも明らかに成功しています(笑い).つまり.方法論をよく知っている人が使えば大丈夫.他のユーザーで成功しているのは，基本的にワークステーションやツールを使うことに慣れているところ.

そういった会社の場合は.比較的スムースに CASE の世界に入れるようです.
青木淳:

オブジェクト指向を使った成功例ですけども.オブジェクト指向で作られたシステムと従来のものとの遣いをよく見て下さい . 明らかに.みなさん強烈なインパクトを感じるはずです.それが成功例です.失敗例はまだ出てきていません(笑い) . 私自身がこれからやろうとしているのは.構造化のアプローチが行き詰まったあたりからオブジェクト指向が出てきたわけですから，いずれはオブジェクト指向もさらに上位のより強力な方法論に包含されて行くだろう.そのあたりを追求して行きたいと考えています.
小事事透 (NTT):

私はいま. CASE ツールについて調査しているのですが .プロダクトはアメリカ製が圧倒的に多く.また導入しているユーザもアメリカのほうが多い.日本で CASE を導入しているユーサ'はごく少ない.その原因としては.文化の違いその他いろいろ考えられると思いますが，どうしてこうなのかということに関して，御意見をお聞かせ願えますか?
佐原伸:

日本ユーザが外国で成功したものでないと買わないということが 1 つですね.それから，ワークステーションの普及率が日本の方が低いということもあります.つまりそもそも CASE を導入する基盤ができていない.
また.方法論についていえば.従来からあるような要求仕様書を作って下流工程に流れて行くという開発手法でこり閏まってしまっているということですね，これまではそれで何とかうまく行っていたのですが，もうそろそ

ろかなり危なくなってきた.しかし，大半はまだそれに気づいていない.
笑は.アメリカでも CASE はそれほど普及してはいないのです .軍関係とか.航空宇宙産業とかを除けば， 日本のコンビュータ・ユーサ'の主涜である事務処理系のユーザに対応するあちらの MIS コミュニティでは.まだほとんど採用されていない.

..健次:
日本国内でどうして CASE が爆発的に普及しないかといえば，それは.仕事がきちんと分業化されていないからだと思います.

1 人の人間が設計からコーディングまで手がける.それはまあ極端な例ですが. !tJ とそうい

う傾向にあるんじゃないでしょうか?それが，分業化されて.たとえばアナリストという職種が確立されれば，その人が何かの出力を出さなければならなくなり，そのために必要な支媛ツールを捜すと思うんです.構造化手法の CASE ツールは.そうしたアナリストのための道具です .

日本ではまだソフトウェア開発の分業化が進んでいない .それが 1 つの原因だと考えま す.
青木淳:

もっと人間的な話をすると，日本ではプログラマが会社を苦手めないからです .

アメリカだと非常に転職率が高いですから，各個人の頭の中にたまったノウハウを外部に取り出して，回定化しておかなければどうしようもな
い . ところが日本は終身雇用制度で.システムの生き字引きみたいな人が必ずいる
人を頼 ればよいという状況が ある.多分こ んな所につきるでしょ う(笑い) .

‑137‑

図ったときはいつでもそのSeamaUVol.6 , No.8・9・10-11

MoriokaWorkshopReport桜井癖里:

たしかにそのことは大きいと思います.
天港学:
社会的な問題とい うこ とですね .
桜井康里:

それに関連して.日本のソフトウェア技術者は，自分の考えを人に説明するのに慣れていないということもあげ ら れます.その必要性がないからだと思うんですけれども.. ..
藍原千尋(日本ラ 7 ド):

いまのことに関する質問ですが，他の分野，つまりソフトウェア開発以外の分野では ，たとえば QC とかで嘗!

と成功して.逆にアメリカに技術を輸出するというパターンもありますよね? SA や OOA についても .今後日
本的な手法が開発され発展して行く可能性は感じられませんか?
青木淳:
やっぱり，いつかは B29 を撃 墜しようと思っているわけですか?笑い)佐厭仲:

QC は別に日本独自 の技術ではなく.もともとアメリカから来たものでしょう?ただ.こちらではアメリカ人
よりしつこくやっただけの話だと思います. CASE については.完全に日本語化されたツールがまだできていないので，それができさえすれば.方法論自体別に変える必要はないと思います . いま， SmallTalk を使っていて困るのは，メソ ッ ドの名前をどうつけるかというところです.つまり.英語力がもろに効いてきて，方法論以

前に英語で悩んでしまう(笑い).完全に日本的なオブジェクト指向言語なら.もっと設計雅やりやすいだろうなと感じることがあります . その意味で.文化的な差を乗り越えた CASE ツールが必要だと思います.現状では.
たとえば StP の場合にも.日本語化されているとはいえ，ある部分では英語を使わなければいけないところがあったりする .

もっと完全な日本語化が望ましいと思います .

PWB グループのだれか:

青木さんにうかがいます.導入の成功例-失敗例について.オブジェクト指向で作られたものを見てほしいといわれましたが，具体的には SmallTalk 上のアプリケーションと考えてよいのでしょうか?
青木淳:
SmallTalk 自身が SmallTalk で書かれていますんで，SmallTalk がみなさんに与えるイ ンパクトはその通りです.それ以外では，オブジェクト指向で作られたユーザーインタフェース.たとえばマックとか X-Window
とか，そういったものをごらんになってください.
PWB グループのだれか:

そうしたユーザ ーイ ンタ ー フェ ー スの設計には，オブジェクト指向は大変すぐれていると思いますが，もっと泥くさいソフト，たとえば最後はどうしてもアセンプラでプログラムしなければならない場合 ， OOA/OOD で設計したものと最終イ ン プリメンテーションとの整合性はどうなるのでしょうか?
青木淳:

私は.たとえば C でプログラムを書くときも，オブジェクト指向風に書きますよという考え方です.明日からアセンプラで書けといわれたら，アセンプラでオブジェクト指向風に書いていくでしょう.
落水港一郎:

まだまだ議論はっきませんが.時間が来ましたので終わりにします.

‑138‑

S
e
a
m
a
l
lVo1. 6 , No.8-9-10・11

MorlokaWorkshopReport

8. 各グループの討論経過

1.PWB&Hyperbook グループの討論経過

1
4
0

2.00 A/OOD グループの討論経過

1
4
4

3
.CASEBench グループの討論経過

1
?
?

4
.StPグループの討論経過

1
?
?

S
.Teamwork グループの討論経過

1
?
?

‑139‑

SeamaﾟVol.6 , No.8-9-10・11

MorlokaWorkshopReport

1.PWB グループの討論経過
前津岡

武制
措直大

事下細川

O. 参 加メンバ

問題解決者

木村茂和

日商 エ レクト ロ ニクス

池川哲夫

アスキー

飯塚宣男

カシオ計算織藤井康範

MHI エアロスペースシステムズ

似内均

岩手電子計算センター

青柳和久

東北 SR A館山純

インストラクタ

足立太郎

SRA
CSK
NTT
PFU

コンサルタント

菅野卓矢

岩手電子計算センタ ー

奥村吉彦

小林透

1.ツ ー ル譲明

前日の解説では説明が十分でないということで. PWB のデモ(病院の受け付けシステ ム )を見て PWB に対する理解を深めることになった . 足立さ ん のデ モ 操作を 見 ながら.参加 者 が質問をするという形式で行なわれた . 以下のような質問が出た:(
1)UIM の時計は処理時間と関係があるのか?
(
2)UIM と E OPM 聞のリンクのはり方はどうするのか?
(3) 遷移に関係あるものだけリン ク するのか?

(
4)UIM の細かい設定(数字の 比 較，入力条件の検査)は可能か?
(5) 開始から終了までのチェックはどのエディタでも 可 能か?

(
6)IOPM において並列同期のアニメーションは可能か ?
また，全体的なツールの印象としてユ ー サ'の見えないニーズを生み出してしまわないか? J という意見が出された .
2. 課題の決 定
課題は多数決の結果ガス給湯システム」に決定し た .
3 . 課題の理解

全員で問題を一通り読 ん だ後，どのように課題を解いて行くかについて議論がなされた.インス ト ラク タ の足立さんから「巌初は F SM を用いて解析するのがよいのでは? J という提案があり，その方向で分析を始めることにな っ た .

そのさい，次のような意見が出た :(1)F SM で順序関係を記述する能力は?
(2) コントローラに関する徳能を洗い 出 そう.

( 3) 主要機能(給湯 ・ お湯はり・追いだき・追いだき中の給湯)を出発点にしよう .
( 4) 機能聞に何か関係はないのか?

問題中の 4 つの大きな機能(お湯はり・追いだき ・ 給湯・お湯はり，追いだき中の給湯)を出発点として考える‑140‑

SeamallVo1. 6 , No.8-9-10・11

MorlokaWorkshopReportという方針に決まった.最初に「給湯」の機能から分析を始めた . そのさい.次のような意見・質問が出た :(1)FSM に階層構造は?

(2)FSM の文法がわからない.
(3) 条件を FSM でど うやって書くのか?

(
4)r 給湯 J という仕事をいくつかの機能に分割するほうがよいのではないか?
(5) 状態遷移に機能とオブジェクトを加えるという方向で考えてはどうか?

(
6)FSM にこだわらずにあげてみよう .
結局状態の遷移だけ取り出してその間の関連づけをしてみよう」ということになった .
4. 状態遷移国の作成
4.1~. の認書

とりあえず， FSM による分析を断念し.給湯機能の状懸を並べてみて状態遷移図 (EOPM) を作ることにした . 給湯，お湯はり，追いだきの 3 機能に関して，次のような状態を認識した :口給湯・電 源 ON.電 源 OFF.給湯栓を開く

・燃焼ランプ点灯.電源 OFF.お湯はりスイッチ ON

口お湯はり-電 源 ON- バーナー点火・ 燃焼ランプ ON

・設定温度オーバー.切替弁が 浴槽側

. お湯はりスイッチ OFF・バイパス弁開く.湯量設定オーバー・設定温度内・ 追いだきスイッチ OFF

口追いだき

・追いだきスイ ッチ ON・システム停止

切替弁が浴槽側

・ 出湯 93C. 出湯 93C 外・バイパス弁開く

・バ ーナ一点火-燃焼ランプ点灯

・追いだ きスイッチ OFF

4.2 各穏健の状建遷移国の作成

3 つの機能に関して，それぞれグループに分かれて状態遷移図を作ることになった.そのさい「給湯 J グル ープでは次のような議論があった:(1) 電源 ON は前提ではないのか?
(2) 比例弁とは何か?
(3) 状懲を初期状態と点火状態の 2 つにくまとめるのがよいのではないか?
(4) 状態遷移図は階層化しでもよいものなのか?

(5) わずかな時間内の事象はどう表現すればよいのか?
(6) 水量センサーは湯量の調節になぜ必要なのか?
(7) 温度に関して 「高 ・適 ・ 低」とい う状態を作る のか?
(8) 温度を下げるためには水量を多くしなければならない.
(9) 給 湯の優先度がもっとも高い.
(1 0) フレームロッドとは着火を検出するものなのか?
4.3 各~.遷移国を EOPM で記述する

各グループの状態遷移図が一応完成した段階で， EOPM エディタを使 っ て状態遷移図を 書くことになった.
参加者が本格的に PWB を操作するのはこの時が初めてだったので .次のような点が掻いにくいとの意見が 出た:(1)全体像を把握できないのでわかりにくい .

(2) 1 ページにすべての状態遷移を書いたほ うがわかりやすのではないか?
(3) 図の配置の最適化機能が欲しい.

.
1
4
1
.

o
.
8
‑
9
‑
1
0
‑
1
1
SeamaUVo1. 6 , N

MoriokaWorkshopReport(4) 紙に印刷する機能がない .
(5) 階層の ツリ ーを 一気に見る方法が欲しい.

(
6)EOPM エディタは他のエディタに比べて使いにくいのではないか?
(7) 事務処理系の場合 . IOPM エディタは必要ないのではないか?
このような意見に対して，足立さんから，今回のツールは開発パ ー ジョンなのでまだ実現されていない機能(印刷機能等)もあるが.製品では実現する予定であるとのコメントがあった.

状慾遷移図を打ち込んだ後 ， アニメーション機能を用いて動作の確認を行った . ここまでの結果を中開発表で報告した .

4.4t走態遷移国の検討
次に，中間発表の OHP で 示した個々の状態遷移図について検討した .最初に「給 湯」に関して検討した.この時，以下のような議論があった .
(1)スイッチは外部イベントなのか内部イベントなのかつ•外部からのイベントも書くべきだ.

(2) 自分自身に戻る遷移を書かないのはおかしいのではないか?
(3) 適温に保つ機能は内部状態だが，スイッチが押されたというのは外部イベントではないか?
(4) 割込み状態という状態は書かなくてよいのか?

•

矢印が割込みを示している.

(5) 状態遷移図ですべての割り込みを記述するのは難しいのではないか?
(6) 給湯準備中という状態はあいまいではないか?
またスイッチが押されていても何もしないという仕様が明記されている以上.そのイベントも書くべきだ」という意見に対し.足立さんから J 下位レベルの状態遷移図で書けばよいのではないか」というコメントがあったが，それに対して下位レベルに落とすとかえってわからなくなる J との意見も出た.

次にお湯はり」に関する状態遷移図の議論ではお湯はり中から 他のイベ ント(追いだき)への状態変化

もこの時点で書くのか? J という質問に対し現段階ではまだ番かなくてもよいのでは」という意見がだされた .
最後に追いだき」に関する状態遷移図の検討を行った.そこでは次のような意見が出た:(1 )3 つの状態遷移図の中では一番わかりやすい .

(2) 電源 ON の状態は電気がコントローラに通じているだけで別に何もしていないのではないか?
(3) 電源 ON と 待機中を分ける必要はない.

(
4) 燃焼準備中での外部イベントも書いた方がよい.
(5) 燃焼準備状態という 1 つのイベントにできないのか?
(6) 各ハードの状況をいちいちイベントとして書くのは意味がない.
(7) 追いだき給湯中という状態は給湯」とは別の状態か?

•

状態遷移図としては別にしたほうがわかりやすい.プログラミングの立場で考えると同じだ.

また，点火しなかった場合に関して次の意見が出た.

(1)点火しなかったら戻るというループでいいのではないか?
(2) 点火しなかったら別の状態を作ったほうがいいのではないか?

(3) 点火しなくても給湯栓を開くという状態に移ってもいいのではないか?

, ti +1 以上のような議論を経て，最終的に 3 つの状態遷移図をまとめて. 1 つの図とし.その図を EOPM エ
ディタを用いて書いた.

‑1
4
2‑

S
e
a
m
a
l
lVol.6 , No.8-9-10・ 11

MorlokaWorkshopReport

5. ヱーザインタフェースの作成
状態遷移図が完成した後，この図を起動するようなユーザインタフェーズを作ろうということになった.ユー

ザインタフェ ース構築には UIM エディタを使用した . まず.黒板を使って給湯システムの操作パネルの設計を行った . この時次のような意見が出た:(1)ボタンは複数にリンクして使えるのか?

(2) たいしたことのないものでも画面にでるとよく見える .
(3) システムの涜れと関係ない作業が多い .

(4)UIM と EOPM のリンクはバブルとボタンをリンクするのか?
6. ペトリネヲト作成

ユーザインタフェースを作成して動作を確認した後，次に何をやるかということになって， IOPM エディタを使って「適温に保つ J という処理をペトリネットを用いて記述してみようということになった.この際，次のような 質問がでた.
(1)トークンとは何か?

•

アニメーションで動いている黒い丸がトークンの動きを示している .

(2) ペトリネットをど う使えばよいの?

(3) 同期処理や並列処理がこのシステムの場合あるのか?

(
4)r 適温に保つ J という処理以外でも IOPM が利用できのではないか?
(
5)r 適温に保つ」という機能はどのモデルを使って表現するのが適当か ?
(6) フローチャートになってしまうのでは?

結局，質問は出たが議論は発散してしまい， IOPM エディタを使うことは断念した.新しい作業を行うには時聞が残り少かったので最終報告の準備に入った.

‑143‑

SeamaUVol.6 , No.8‑9‑10‑11

MorlokaWorkshopReport

2.00A/OOD グループの討論経過
報告者

小淳一彰
(静岡大学)
O. 参加メンバ

問題解決者

井上忠則

シスプラン

遠藤晋

アスキー

高橋秀行

SRA

田口秀成

新日鉄情報通信システム

平尾一浩

ヒラタソフトウェアテクノロジー

前雄介

中央システム佐藤琢美

岩手電子計算センター

松本幸三

CSK

DabinM
a
t
t
h
i
e
u

静岡大学

インストラクタ青木淳

富士ゼロックス情報システム

コンサルタント

佐原伸

SRA

1.問題選択

問題選択にあたって.対象を制御系-事務系のいずれにするかが論じられた.しばらく話し合いが行なわれた後，青木さんのから次のようなコメントがあった.

「オブジェクト指向に向いているとさ れる制御系の設計の確認.または事務系の仕 事がオブジェクト指向でできることの確認のどちらでもよい J
話し合いの結果.制御系の問題「給湯システム」を対象として選ぴ，事務系の問題である「図書館システム」については，青木さんから解説してもらうことで合意ができた.

2
.S
m
a
l
l
t
a
l
k
8
0& GrapherGear についての詳細な義明
問題解決に入る前に，青木さんから Smalltalk80 および GrapherGear の操作法についての詳細な説明が行なわれた . そのさい，参加者から次のような質問が出た :(1)既存のオブジェクトに.新しいメソッドをつけることは可能か?

(2) 機能を付加していったとき，誤りの所在が自分が定義したのではない部分にあったとき，それは発見可
能か?

さらに.それは修正できるのか?

また，ソースには見えない部分はあるか? (要するに Smalltalk システムのすべての既存のオブジェ
クトを鉱張・修正できるのか?という質問)(3) オブジェクトは，マルチタスクのように常時動いているが，デバッガは，そのオブジェクトの動きを止めて見るものなのか?

青木さんの答えは， (1)， (2) に対しては Yes ， (3) に対しては No であった .
3. 給渇システムのオプジェクト指向解析
青木さんが説明した方法にしたがって.実際に給湯システムのオブジェク ト指向解析を行なっていくことになった.そのさい，

MacintoshII-fx に加え，佐原さんのご厚意により Portable Mac を利用させていただくことになった.以後.グループを 2 つの班に分けて作業を進めることになり.記録係はパニックにおちいった.そこで，班を特定せず，おもしろそうな話をしている方に耳を傾けるという方針でのぞんだ.
3.1 オブジェクトの認書作業

まずオブジェクトの認識を行なった.最初は問題文や図中で目につく言葉をあげ.ぞれがオブジェクトであろうということで.ツールに登録していった.一通りめぼしいオブジェクト候補がリストアップされつくすと，次のような疑問が出てきた:‑144‑

SeamaUVol.6 , No.8‑9‑10‑11

MoriokaWorkshopReport(1) r 浴槽の排水 J はオブジェクトかどうか?
(2P 給水」はオブジェクトかどうか?
(3) 物理的なものだけでなく，データもオブジェクトではないか?
(3-a) 水や湯はオブジェクトか?そうだとしたら水と湯は異なるオブジェクトか?

(4) 湯の温度はオブジェクトにできるか?もしできるならセンサはいらないのでは ?

(a)r 温度」と「センサ」は同じものではないか?
青木さんは参加者にすべてをまかせ.議論が出つくしたところでコメントを与えるという援し方であった . この議論の終りには次のようなコメントがあった:「本来属性として定義されるべきものまでオブジェクトになっている. (オブジェクトという)カプセルの中に入れるべきものまで外にでている J

その結果，軌道が修正され.ある程度話が整理されたように思う.

オブジェクトの認識の作業が一段落した時点で.オブジェクト認識の方法についての討論があった . 最初に.
次のような疑問が出た:(1)次のどちらのアプローチをとるのがよいのだろう?
(a) 問題を理解してから解析を行なう.
(b) 問題は軽く読むにとどめ.先に思いつくオブジェクトを選定する .

これに対して「最初からこの例題のようにシステム全体がきちんと与えられることは少ないのではないか?だから，あまり問題を詳しく理解しない方がよい J という声が聞かれた.すなわち，問題を完全に理解しないまま解析を始める方が，現実に近い感覚になってよいだろうということである . 結局 (b) のアプローチをとることになり，作業が続行されることになった.
その他に提案された方法は以下の通りである:(2) オブジェクトの認識だけでは，それらの聞の関係がわからないので.ツール上でオブジェクトを描く場
所までは決められないのではないか?
(3) とにかく名詞をあげてみて，その後オブジェクトでないと思われるものをけずる方法でよい .
この過程で認識されたオブジェクトを表 1 に示す .
3.2 オプジェクト聞の関係づけ

一通りオブジェクトが出そろったと思われたところで，オブジェクトの選定作業に一応の決肴をつけ，オブ

ジェクト聞の関係を定義する作業に入った.オブジェクト聞の関係 is-a と has-a に関し，以下のような疑問が出た(ただし is-a は一般化と特殊化を反映したクラスの分類を表現し. has-a は全体と官官分を反映した集団を表現する関係である.討論の中で「あるクラスのスーパークラスを見つける」とはあるクラス」を一般化したク
ラスを見つけ.あるいは新しく導入し，両者聞に is-a 関係を定義することである):(1)二つのオブジェクト.パルプ A とパルプ B が共通のスーパクラスとしてパルプを持つ場合 :(a) パルプ A に対するメッセージの受信者はパルプ.パルプ A のどちらか?

(b) パルプ A とパルプ B が遣う機能を持つ場合，クラスーインスタンスの関係で処理できるのか?

(2)is・ a ， has-a の関係の引き方は?また is-a ， has-a の切りわけは?ツールを使用しながらの討論のため.
is-a 関係の認識はエディタ上での「線を引き方」という表現になっている)(3)r 上にひっぱる J ということの意味とやり方は?
(3) の質問に対し，青木さんが以下のような説明を述べた:「いろいろな状懸を表すオブジェクトとして State がある.その下には，特に二値状懲を表すオブジェクト

BinaryState がある.さらに，この下に例えばパルプのような on-off で表せるようなオブジェク
トがあると考えられる」‑145‑

SeamaﾟVol.6 , No.8-9-10・11

MoriokaWorkshopReport

1 班

2班

コントローラコントローラメインコントローラ

メインコントローラ

風呂コントローラ

風呂コントローラ

出湯サーミスタ

サーミスタ

水量センサ

水量センサ

フレームロッド

水涜スイッチ

燃焼ランプ

水量パルプ

運転ランプ

切り替え弁

割り込みランプ

給湯栓

運転スイッチバイパス弁

給湯水涜スイッチ

湯釜

お湯はりスイッチ

浴槽

水量パルプ

水

切り替え弁
給湯栓
バイパス弁

比例弁
点火プラグ
バーナー
湯釜

浴槽
表 1 認議されたオプジェクト

これは，抽象化のやり方について，非常に本質的な示唆であった.ここで議論はクラス階層を意識した方向に足並みが揃ってきた .青 木さんによって示されたオブジェクト聞の関係の例(図1)を参考にしながら，たとえば以下のような問いかけがあった:(4) 終端的(セ ンサなど )なもののスーパークラスを見つけられないか?
(5) 温度は量であらわされるか?
(6) 水のサブクラスに ，それを計るものがあるのでは?

(7) 図 1 のゲージと並んで計測器というクラスがある.
(8) スイッチやツマミ，

LED のスーパークラス(すなわち is-a の関係の親)は入力(出力〉装置かそれともコントローラかどちらがよいのだろう.
(9) コントローラーの下に入力装置がある.

(
10)xx ゲージ(たとえば音量グージ)は，図 1 のどこにつけられるか?
ここで.青木さんから次のようなコメントがあった:

ris-a 関係では子は親との速いだけを記述すればよい J (したがって新しいオブジェクトは，最も性質が近い
オブジェクトの子となるように is-a 関係を結べばよい)(1
1)r コントローラ」が何か(センサ.スイッチなど)を持っているのではないか?
(a) r コントローラ」は「入力装置 J r 出力装置」を持っている(b) セ ンサ，スイッチ， LED が「入力装置 J r 出力装置」ではないか?

(
1
2) r コントローラ」は「計測器」か?
(1 3) センサやスイ ッチが「入力 J r 出力 J と分けられるなら「パルプ」はどうするか?
ここまで議論が進んだところで全体による中間発表が行なわれた . このグループは， 2 つの班が独自に定義したオブジェクト関係図をそれぞれ発表した.

‑146‑

SeamaﾟVol.6 , No.8-9-10・11

MorlokaWorksbopReport
物

集まり

大きさ

順序てー

数一日数

ゲージ

国 1 オブジェクト間の関係の例

3.3 丙グループの成果の盤り合わせここまでの作業は 2 つの班がそれぞれ独自に行なってきたが.ここで成果の探り合わせを行ない，一本化することになった . 以下，それぞれの図についての発言を挙げる.

(1)第 1 班の図はセンサ，パルプという分類でなく.
(2) 第 2 班の図は，終端部の上に，統ーされた上位概念センサ，パルプを用いているバイナリステート」という 2 値動作に注目した分類になっている.

この 2 つの点が爾班の成果の最も大きいちがいで，他はほぼ同ーの結果であった.第 2~ の参加者もオブジェ
クト「バイナリステート J に納得したため.第 1 班の結果を採用することで合意した.以下は ， 第 1 班の成果に対する第 2 メンバのコメ ン トや疑問である:(3) フレームロッド等は Îs-a と has-a を持っている.

(4) この時点ではコントローラなど ，

まだ不足書官がある.

(5) バイナリステートとその下で ， 持ち上げているレベルが遣い過ぎるのではないか?

(
6)r 計測器」は全て{デバイスが異なっても)値を返すだけである .
(a) どんな値を返すのか?
(b) フレームロ ッ ドは「バイナリステート」の下にあるのではないか?

(7) サーミスタの働きは二値動作ではないか?

これらの疑問に対し ， サーミスタは温度の計測だけを行ない .on-off はコントローラが行なうということにな
り ， サーミスタおよび水温センサは「バイナリステート」ではないことが確認された.この議論を皮きりに.オ
ブジェクトの抽象化の議論が再燃した.
(8) 温度や水量を表わすオブジェクトがいるのではないか?

(a)r 大きさ」の下に温度や水量があり，サーミスタや水温センサはそれを has-a している .
= > 大きさと温度や水量の関係は?
(9) サーミスタや水量セ ン サではなく計測器」が温度や水量を has-a するのでは?

(a)r 計測器」が「数 J を has-a するのでは?
(
10)r 大きさ」の下に「数 J や「計測器」がつくのでは?
以上のような抽象化の議論に対して整数という話(抽象化)は設計に関係ないのでは? J.r こんなところまで論じていたら仕事にならない.どこで止めるのか?終りを認識する必要がある」という意見が出された .
(11) 数と計測器は Îs-a 関係か?そうでないのか?
(1 2) 正しいかどうかは別として，少なくとも 一 段階は抽象化されているので .

‑147‑

も う いいのではないか?

SeamaUVol.6, N
o
.
8
‑
9
‑
1
0
‑
1
1

MorlokaWorksho Report(1 3) バイナリステートというのがあるのだから.アナログステートというレベルの抽象化が必要になるのでは?

(a) しかしサーミスタなどとうまくつながらないようだ.

(14)r バイナリステート」というのは抽象化しすぎだったのではないか?
(
1
5)r コントローラ」は制御するだけだから.特に拍象化はいらないのでは?
続いて，オブジェクト「コントローラ」が必要かどうかの議論が行なわれた . 以下のような発言が行なわれ，「コントローラ」は必要であるとされた.

(
16)r コントローラ」はいらないのでは?
(a) 制御動作はデバイス自身が知っているので.不必要では?

(b)r コントローラ」は「センサ J や「ランプ」の集合にしかすぎない.
(17)r コントローラ J は必要 =>まとめ役がなくなってしまう(
1
8)r コントローラ」は単なる中継点.だがまとめ役としては必要.
(
19)r コントローラ J を作っておくメリットはある.
(a) 少しの変更で.種々のコントローラを作れるのでは?
3.4 図書館システムの解誕

ここで青木さんが.参考のために「図書館システム」について解説を行なった.以下は，それに関する質問である:(1)職員と図書館はつながらないのか?

(2)r サービス」が「利用者 J から「図書館」へ継承されているのか?
(3) メッセージの送受は has-a に対して行なわれるのか?
3.5 オプジェタト関係国の完成

一

計測器

よ

上
'，，み
コ‘
ン

且呂コントローラ

ププシ

、，

，

プ

.Rb
・"

-w-n

EF-L

メインコントローラ

、，

a

プ

-w バ
パ
・・ リイ例
旬パ比

''

一幸ト

-w

随'
川崎隆
a

a‑‑a‑AnトIL--「lLlll,lBELI

7

fam

打

,

‘F

-

制

J14

ド.
1h1H

ス

,,‘

テャ

一

tJA747

一

-，

!?下“

Tll

z一」

ナ

ぺ

j

; ;
;
:
:
...

青木さんの説明を参考に，オブジェクト関係国 の決定が行なわれた .

卒b..-a 同国i岬

固 2 オプジェクト関係国

以下は図 2 に示されるオブジェクト関係図についての発言である :(1)これではコントローラはバイナリステートの機能しか使えない?
(2) スイッチ.パルプ等は「入力 J r 出力」として分けられる?
(3) バイナリステートから下は趣味の問題で，ぞれほど重要ではない?
(4) 湯釜はパーナ等の組合せだから入らない?
3.6 オプジェクトの属牲とサービス

オブジェクトの属性とサービスの決定を行なっていった.残念ながら時聞の都合ですべてのオブジェクトについてはできなかった.

‑148‑

SeamallVol.6 , No.8-9-10・11

MorlokaWorksbopReport

バイナリステート状態 (1 ， 0)ランプ

「光る」のは属性かサービスか?
属性はバイナリステートから継承= > スイ ッ チやセンサなども同様

計測器

数量

サーミスタ

(温度)

温度単位

水温センサ

(水量)

水量単位

コントローラロジ ッ クを属性とするか.それともサービスにするか?

計測器については.次のような議論が行なわれ，カッコ内の属性は削除された.
(1)サーミスタが温度を知っていれば計測器は.それを知らなくてもよいだろう .
(2) 計測器の属性に量や範囲があれば.その下にはいらない .
(3) 数が計測器であれば，サーミスタや水量センサは，その意味(単位など)を持つ必要がある
ここで時間切れとなり.最終報告を行なうためのまとめの作業に入った.
4. 終わりに最後に報告者からの感想を述べる . まず，参加メンバのほとんどがオブジェクト指向の方法論は初体験だった
ためか，ツールを使って例題を解いて行くというよりは.オブジェクト指向の勉強会といった雰囲気であった.
そのためか，最初から最後まで方法論に綴りまわされる感じになってしまった .

しかし.その過程で，第一線のソフトウェア技術者の方々が，言葉によっていかにコミニュケーションを行なう
かを見聞きすることができ，たいへん興味深かった.

‑149‑

1
¥
1

SeamaUVol.6 , No.8-9-10・11

Mor
i
okaWo
r
ks
hopReport

聞と行3.CASEBench グループの討論経過
報告者

古川勝也
(静岡大学)
O. 参加メンバ

係
問題解決者

阿部和弘

富士ゼロックス情報システム

だ

藤原千尋

日本ラ ッ ド先泉田昭義

岩手電子計算センター

思幼田和典

日本電気ソフトウェア

松浦光哉

中央システム

上回賢一

SRA

斉藤基

富士通ピーエスシー

と
タ

財団雅史

ケーシーエス

大岡俊之

東北コンビューターサービス

インストラクタ

渡部健次

ソニー・テクトロニクス

コ ン サルタ ン ト

天池学

カシオ計算機目圃・・

た1.CASEBencb についての詳細な護明
渡部さんから C ASE Bench の操作法についての説明が行われた.そのさい.参加者から次のような質問があった:(1)階層が進んだ時点で ， 上の階層を見ながら書くことはできるのか?

(2) バブル(プロセス)の数が 10∞個というように多くなってもよいのか?

4.

(
3)undo や remove の機能はどうか?
(4) データが大量になったようなときの整理はどうなのか?

渡部さんの答えは. (1)と (2) については Yes. (3) と (4) については No であった . 参加者の大勢は「使ってみないとまだ何ともいえない」ということであった .

た4.

2. 問題 の 選 択

問題選択にあたって.何問解くか?また，どの問題を選択するかが話し合われた .ft 初に渡部さんから次のよ
うなコメントがあった :r2 問解くのは時間的にも難しい.問題は制御系と事務系とあるが. CASEBench は制御系の問題に向いている」

これを受けて藤原さんから，制御系の問題をやってみたいという希望が出たが.日頃仕事で事務系のものを行っている人が多かったため .結 局，多数決で事務系問題が選択され.もし時聞が余ればもう 1 問制御系の問題をやってみようとい うこ とになった .事 務系の 2 つの問題のうちどちらにするかは，多数決により酒屋倉庫問題と決定した .

3. 酒屋倉庫問題 の 解析

CASE Bench を使って酒屋倉庫問題を解くにあたり，データフロー図を使った経験者が 2 人と少なかったた
め ， 渡部さんから少しコメントいただいた :・データフロー図 (DFD) におけるプロセスが酒屋の仕事に fJ りつけられる.

・ データがシステムの内部のものか外部のものかを.問題文から識別する.
・ データの区分をした上で.まずコンテクスト・ダイアグラムを作る.

4.

3 . 1 データ の 洗い出しと分類

まず，酒屋問題におけるデータの洗い出しと ， それらのデータのシステムに対する内外の区分が行われた(この時点で，システム化対象範囲についても議論された).歳初に，倉庫への品物の入庫情報をどうするかという

‑150‑

、y

SeamaHVol.6 , No.8-9-10・11

MorlokaWorkshopReport

問題が議論されたが.話がまとまらず，リーダーの大岡さんの意見で ， 問題文から忠実にデータの嫡出をしようということになった.問題で与えられた図ではデータ不足だという人もいたが，とりあえずデータを書き出して行くことになり.それぞれが考えた結果を泉固さんが次のようにリストア ッ プした:

- 積荷票

-出庫依頼(票)- 出庫指示書- 在庫不足リスト

・空コ ン テナ通知

・ 在庫不足連絡

このリストに対し . システム化対象範囲も考慮して電話連絡はどうおさえるのか? J という問題や受付係は在庫の有無の状況を把握し管理する必要があるから在庫係を兼ねており，倉庫係はただ肉体労働をするだけだ」といった意見が出て . 電話については出庫依頼粟に含まれるとし，受付係と倉庫係の仕事の範囲については先にいった意見にしたが う うこととして.話が進められた .
このデータ-リストに対し，一応の形を見る上での簡単な DFD を(すべてのデータを使って)作ろうということになった.渡部さんからそのやり方について，先にバブルを固定しそれにデータの涜れをつける方法と，データの流れを考えからその交点にパプルをつけて行く方法の 2 通りがあるという注意があった .
こうして作られた第 O パージョ ン の ， 簡単な DFD について . データの確認をも含めて以下のような意見が出た :-入庫時の納品書はデータに入れなくてもよいのか?
.納品書=積荷票と考えてよいのではないか?
- コンテナをどこの部所で管理するか?
- コンテナへの商品の出し入れは.どちらを中心に考えるのか?

.コンテナ中心で考えるのが問題に忠実では?
- 在庫確認は商品について行うものではないか?
-受付係で在庫管理しないと笠コンテナ通知が出せない?
・ 入庫通知，入庫依頼がない?
4. データフローダイアグラム (DFD) の作成

データの分析が完了したところで.次にツールを使つてのデータフローダイアグラム (DFD) の作成を行った . その過程での討論を以下に記す .
4.1 コンテタストダイアグラムの作成作業を始める前に，渡部さんから.ガイドラインについて.以下のような説明があった:(a) エクスターナルの決定:
エクスターナルに名前をつけて行く(b) データフローを書く :データの涜れを書き入れて行く(c) プロセス(バブル)を入れる
説明が終った時点で ， 以下のよ う な参加者からの質問や意見が出た:(1)ガイドラインはどうやって定めたのか?
(2) プロセスになぜ名前をつけないのか?

(
3)0 や口はその中に書く名前の長さによって自動的に拡大縮小してくれるほうが便利だ.
渡部さんの回答は以下の通り :(1)図を繍く上でのわかりやすさを考えて定めた .
(2) もちろん名前をつけることはできる.しかし，無理な名前をつると後で支障が出るので ， 慎重に!
こうしてできあがったたコンテクストダイアグラムについては ，

中間報告参照 .

4.20 階層のダイアグラムの作成
この段階では ， 最初に泉国さんによって提案された DFD をツールによって書くだけであった.参加者から，ツールの使い方に関してコメントまたは質問がいくつか出た:

‑1
5
1‑

SeamaﾟVol.6 , No.8-9-10・11

MorlokaWorkshopReport(1)エディタで:文章を打った後 [space] を入れれた方が便利だ.
(2) エディタで:プロセス等の名前を英文字にするには?
(3) いきなりツールを使うことはできなかったのか?

(4) データストアをどの階層で書けばよいのか?
これらの質問に対する渡部さんの回答は以下の通り :(2) 英文字のときは無変換を選択する.
(3) 人数等のことを考え，ある程度の前置きがあった方がよいと考えた.
(4) 必要なときに必要な階層で行えばよい .

できあがったた O 階層ダイアグラムについては，中間報告参照.
4.3 データディクショナリの作成

データディクショナリ (DD) は DFD に対してデータを定義づけるもので，ここでは未定尊重のデータに対し(エディタを用いて)定義づけをして行った .

例 : コンテナ = コ ン テナ番号 + .
まず ， 渡部さんから「データディクショナリを書けば DFD の間違いもわかり.不必要なプリミティプが削れる 」 というコメントがあった . 参加者の疑問は次のようなものであった:.DD での入力が DFD での階層化に影響があるのか?
-依頼者名簿は何?

また，依頼者の Tel No. は?

ここまでの議論と作業によって DFD および DD が一応の完成をみた . 中間報告では，これらの内容についての報告を行った.
5. データフローダイアグラムの再設計
参 加者から中間報告における DFD に不満足の声が多かったため.再設計を行うこととなった.それにさいして ， 渡部さんから次のような注意点が上げられた :-データストアの位 置 確認 .
- データベースとファイルの区別しっかりと .
. サブシステム化がよくなかった .

-基本的にはデータの涜れを書き，その接着剤としてバブルを考える .
.データの整理 .
・ プロセスの名前の確認.
渡部さんのコメントの後で討論が始まり，中間報告の内容について . 以下のような疑問点があげられた :(1)第 O 階層のプロセスは昨日の 3 つでよいか?
(2) それを変えるとコ ン テクストダイアグラムはどう変化するか?
(3) 機能とデータの関係が不明瞭では?

(3) を受けて，渡部さんから ER モデル l の説明があった . rER モデル l についての検討は後ほど」ということであったが . 参加者の関心は強く ， いろいろな意見が出た実際に作ろうとしたとき .ER モデル 1 はすぐにできるものなのか?す ぐ にできるものならやってみたい」という声あった.それに対する渡辺さんの返答は次の通り :「 ふつうは ER モデル l から DFD を作る.それぞれのダイアグラムは . ER で・くとモデルがだいたい近いものになる.データベースが ER モデルに置けるかどうかが問題です.皆さん頭の中ではやっているので しょうが.それを 実 際にやっていくのは大変ですよ J
そうしたやりとりの結果 . リーダの大岡さんが rCASE ツールを使う上ではこういった作業が一番大切と思う

ので . 大変だけど，データを ER 図で正規化して行きましょう」と主張し，渡部さんも rERD のほうは大岡さんを中心に昨日のデータデ ィ クショナりで一応やりましょう.エンティテ ィ の関係づけをしっかりつけて ER
モデルを完成できれば一番よい」とい う ことで. DFD と ER モデルの 2 グループに別れて作業を始めた .

‑152‑

SeamallVo1. 6 , No.8-9-10・ 11

MoriokaWorkshopReport

5 . 1 コンテクストダイアグラムの検討

コンテクストダイアグラムについては.すべての参加者の意見として中間報告時の C !D FD C ONTEXT でだいたいよいのではということであったが，下の階層を検討して行く上で少し変化があった.

5.
20 階層ダイアグラムの検討
0 階層については，中間報告時の C !D FD 0 に関する討論として.以下 のような話合いが行われた:(1)在庫不足リストは名前がよ くない .
(2) 新しい O 階層を作る上でバブルは 2 個ではないか?

(3) 入庫と出庫を 管理するバブルがもう 1 個必要な 気がするが?
(4) 入庫のほうはこれ以上分けても仕方がないのではないか?
このような議論の末. 0 階層 の DFD は入庫の受付と出庫の受付を うけるプロセスが 2 個となった.できた
DFD について

1 個のバブルから出入りするデータフローが多いようだとい うことであったが.とりあえず ，

ツールによる DFD の作成となった.
そこで，まず渡部さんから「ここで，プロセスの名前を考えてゆくのが大 切です.上の階層の分け方が適切でないと下では困難になってきますよ」とコメントがあった.
また，参加者の議論は次の通り:(1)窓口の受付を行なうプロセスを作つてはどうか?そうすれば 1 個のプロセスの受けるデータがへる.
(2) 取引先からの .

いくつかのデータを窓口にもってくるのはおかしいので，取り除いたほうがよい.

(3) 商品管理のプロセスと窓口のプロセスでは，出庫命令とか不足報告があるはずだ.
(4) データの名前だけの参照か，深い属性のある参照か，を確認してみてはどうか?

(5) データストアの取引先と依頼者名簿は . 0 階層ではい らない.

1 階層で必要なのではないか?その結果，データストアの取引先と依頼者名簿は第 1 階層に移すことになった)
参加者からのツールに関する質問は次とおり ・(1)全体のプライマリの状況を見る方法はないのか?

(2) プリンタへの出力が少し弱いのではないか?
これに対する渡部さん吻回答は以下の通りであった:(
1)WINDOW をマルチに切って見るしかない.
(2) シェルコマンドでやるしかない.

この時点で，図 1 および図 2 のような DFD が一応完成した .
これらの DFD に対して次のような検討が行われた:(1)図 1 の"出庫受付"バ ブルは，窓 口業務と商品管理の 2 つに分けたらど うか?
(2) それだと図 2 は別にいらなくなるが.. .. ?

在庫ファイル

国 1 C
IDFD0 ー酒屋倉庫之入出庫を確認する‑153‑

SeamaUVol.6 , No.8-9-10・11

MoriokaWorkshopReport

出庫依華れ

依頼者名簿

在庫ファイル国 2 CIDFD1 一出庫の受付をする

検討の末 ， 図 1 を図 3 に変更することとなった.

出庫￡

6
.
簡

¥J
在庫ファイル国 2 CIDFD1 一出庫の受付をする

この時点で渡部さんから図 3 の"商品管理"バブルは.もっと階層をつけて分けた方がよい」というコメン

トがあった.それについて話しあっているうちに，議論が行き詰まり，ツールを離れて，図 3 について全員で検討した.次のような意見が出た:(1)出庫指示に，空コンテナ指示を知らせるニュアンスの空コンテナ搬出マークがあるので，空コンテナ通
知はいらないのではないか?
(2) たしかにそれはいえる .

(3) "入庫受付"バブルに商品管理"バブルへのインターフェースがないのは，問題の仕様に反するような気がする .

これでは入庫したことのチェ ッ クが抜けている .

(4) 在庫ファイルは出庫リストを含んでいるのでは?

(5) 在庫ファイルには"商品管理"で対応できるので入庫受付"からのアクセスはいらないのでは?
(6) そのアクセスを消すと入庫受付の仕事はほとんどなくなる.しかし，入庫受付を重視すると商品管理の仕事がへってしま う .

(7) 2 つのバブルを統合しては?
(
8) 1 組の入出庫をバブル 1 個で対応するというのはちょっとどうか? 2 つのバブルを統合すると，そのバブルの仕事が膨大になるし在庫商品があるか? J どいう客からの問い合わせに対して ， 何がいくつあるかがわからないとだめなのでは ? 客の依頼してきた商品がなかったとき，それをいかに早く用意して出すかを考えることが必要なのではないか?

(9) この段階では 2 つののバブルを統合しておき.下の階層で分けてはどうか?
こうした討論の結果.結局 2 つののバブルを統合することになった .

(10)0 階層において，プロセスの名前をどのレベルまで確定したものにするのか?たとえば，入力出力系の

‑154‑

o
.
8
‑
9
‑
1
0
‑
1
1
SeamailVo1. 6 , N

M
o
r
i
o
k
aWorkshopReport

関係を論理的に分けて見ては?

(11) この時点で名前を決め，論理的にしてみますか?
(1 2) この時点ではこのままにしておき ，

もっと下の段階まで行ってから考えればよいと思う.

さらに，商品管理バブルの下の階層について検討していった.これについては，泉田さんと藤原さんからそれぞれ案が出され，検討の結果，泉田家で行くことになった .

泉国家中の"出庫管理"バブルについて ， さらに下に階層をのばした.この階層については ， 藤原さんから出された案を採用することで意見の一致をみた.
話がまとまったところで，ツールを用いて，最終報告に見られるような DFD が作成された .

そして，中間報告のときと同様に，データディクショナリが作成された.これについては . 一度経験していたので，特に議論は

なかった.

5
.
2ER モデルの作成
ER モデル l に関しては，エンティティごとの関係を確定できないものなどを，それぞれ独立に書いて行くことで作成し直すことになった.

このグループからの作成終了時のコメントは以下の通り:
うまく正規化されないとエンティティどうしの関係が作れない

そこの所でひっかかって，結局のとこ

ろ中断という形になっている . DFD の方で階層が進むと ， データの量が増えて，それを考えるとまとまらなくなってしまうこともありそうで，短時間ではどうしょうもない.
6. モジュール構造園の作成

DF
D.ERD.DD が完成したので，ツールを用いてモジュール構造図を作ることとした.この作業は比較的簡単であった.これについての渡部さんのコメントは次の通り :レベルの複雑度は.

1 つのモジュールの呼ばれる回数への依存度が高い.あるモジュールについて複雑度が大きすぎたら，階層を下げてそこに制御のモジュールを置く.
この機能に関しては，参加者全員便利であると感じた .
ここで時間切れになり，最終報告の準備にかかった.

‑1
5
5‑

SeamallVol.6 , No.8-9-10・11

MoriokaWorkshopReport

4.StP グループの討論経過
報告者

中尾博司
(静岡大学)
o. 参加メンバ

問題解決者

満田豊 (B グループ)

シーイーシー

西垣郁夫 (A グループ)

東京電力

清水洋子 (A グループ)東芝

三上修 (B グループ)

岩手電子計算センタ一

山島利彦 (A グループ)

日本エムアイシー

浜恭士 (B グループ)
阪本普通 (B グループ)

SRA
SRA

柳瀬健一 (A グループ)

ケーシーエス

築山秀夫 (A グループ)

ケーシーエス

インストラクタ

桜井麻里

SRA

コンサルタント荻原剛

大阪大学

1.問題の選択

まず，実際に解決する問題の選択を行なった . 選択の基準に関して，(
1)SA/SD の手法で解けるものはどれか?
(2) 事務系の問題か?制御系の問題か?

(
3) 1 問だけか?

2 聞やるか?

という疑問があげられた . (1)に関しては，今回用意された問題はどれも SA/SD で解くことができるという助言が得られた.また. (2) に関しては.多数決の結果，事務系の方を希望する人数が多かった. (3) に関しては，「まず簡単な問題を全員で取り組み，うまくいったところで 2 問目をやってもよいのではないか? J という意見が支持された.

そこで，次に事務系の 2 つの問題(図書館管理および酒屋倉庫)を読みくらべ，どちらの問題を希望するか，自己紹介を兼ねて発言することになった

この時酒屋倉庫問題はこれまでにいろいろな手法で解かれているので ， それらとの比較ができる」という助言もあったが，結果として「図書館管理」の問題が選択された.
2. 問題解決の方針
次に ， この問題をどういうやり方で解いて行くかについて.議論が行なわれた.実際に SA/SD の手法を使ったことのある人はいなかったが J ともかくツールがあるのだから ， それを使いながらやってみよう J ということになった.さらに.今回は端末が 2 台あるので r 2 つにグループ分けをして作業を進め，後でそれぞれの報告しあ う 」というとになった.

3.A グループの作業
3.1 問題の解き方の議明

まず ， 桜井さんから. SA/SD の基本的な作業の進め方として，「システムの外に何があるか，どういう入力や出力があるかという点から，システムの概観図を作成して行く べきである」というアドバイスがなされ，それにしたがって作業を進めて行こうということにな っ た .
3.2 疑問点の決い出し

そこでまずグループ全 員 で問題文を詳細に読んでいったが，その時点で生じた疑問点は以下のようなものであ
る .

‑156‑

R

MoriokaW orkshopReport

SeamailVol.6 , No.8-9・10-11-問題に関するもの(1)この問題文にはあいまいなところがたくさんある.これをほんと うにユ ーザ 要求として解決して行ってもよいのか?

(2) 問題文の中で 3 番目の要求は，本当は図書館の利用者にも使える機能のはずで ある . これはこのま
ま解いてよいのか?これにちうては.結局このまま解決して行こうという合意が得られた)- 作業の進め方に関するもの(1)四角(外部エ ンティティ )と丸(システム)はどち らを先に書くのか?
.ツールの使い方に関するもの(1)日本語の入力方法は ?
(2) 辞書にない字がある場合はつ3.3 コンテキストダイアグラムの作成

疑問点を解決したところで.コンテキストダイアグラムの作成に取りかかった.この時点で問題になったのは，以下のようなことがらである(議論は実際にツールのいろいろな機能を利用しながらなされた):-エンティティの作成に関するもの(1)本の実体は何か ?

(2) 本は(データ ベ ースの)属性とキーとして整理できるのではないか?

(
3) "作者"とい うのは 外部エ ンティ ティになるのではないか?
(
4) "本箱"とい う エンティティを用意したが，実際には不要で ，システムと 利用者だけではないか?
.コンテキストダイアグラムの書き方に関するもの(1)コンテキストダイアグラムはどのレ ベルまで書けばよいのか?

(2) 外部エ ンティティをこのコンテ キストダイアグラムにどうマ ッピングするのか?

(3) コンテキストダイアグラムは.システムとそれに対するリクエスト ， 応答として考えればよいのではないか?

(4) 入出力は E-R 図で月 11 に書くのか?

(5) 入出力データは l 本にまとめるのか?それとも別々に書 くのか?

(6)( 入出力を)

1 本にまとめるのと別々に書くのとでは.単に見た目が違うだけではないのか?

(7) コンテキストダイアグラムで書く基準は何か?

(
8) "本を借りる"というのは，線で表現するのか?システムの概観図の中にあらわれるのかつ(9) トランザクショ ンに焦点をあてて 考えるのか?
-問題の解釈に関するもの(1)本の追加や削除は考えなくてよいのか?

(2) 実際に利用する場合は，ユーサ'も職員に操作してもらうのではないか?

この結果作成されたコンテキストダイアグラムについて，以下のような疑問が出された:-利用者 と職員を区別する必要性について(1)利用者と職員を同じものとして考えているが ，次のレベルで複 雑になるのではないか?
(2) 利用者と職員を区別しておくと，システムへの入力データの識別が容易になるのではないか?

(
3)r 利用者と職員を区別する」問題は，結局端末が 1 台だけなのか .2 台あって利用者と職員が別々に使えるのかという，システムの稼働する環境を決定する問題ではないか?
-出力について(1)出力するものはリストだけでよいのか?検索したものがあったかなか ったかの確認はしなくてよ
いのかつ

出力に関しては J 在庫リストは必ず何らかの応答を返すはずである J という意見が出された.また，次に行なう作業としてデータ定義とデータフローダイアグラムはどちらを先に作成すべきなのか? J という質問も出

‑1
5
7‑

SeamallVol.6 , No.8-9-10・11

MoriokaWorkshopReport

た.結局，データフローダイアグラムの作成を先に行なうことになった.
3.4 データフローダイアグラムの作成

データフローダイアグラムの作成に関して，以下のような疑問が出された:・プロセスの書き方に関するもの(1)プロセスの分け方の基準は?

(
2) 2 本以上のデータが揃ったら次のプロセスを起動する，という記述はできるのか?
(2) に関しては， No とい う答だった

また，桜井さんから「使わないデータは渡さないこと」というアドバイ

スを得た.

rReject 等の 矢印はデマルコの記法で書けるのか? J (荻原)
「書けない J (桜井)こうしてデータフローダイアグラム O を作成し次のレベルを記述するか?データ定義を先にやるか? J を相談していたが，メンバーの 1 人からデータフローダイアグラム O に対して独自の案が提案され.ひとまずそれと現在の案を皆で比較・検討することになった.そして 2 つの案をマ ージした結果 ，入力デ ータは 1 本とし，それを分解するプロセスを挿入することに決定した.その結果，コンテキストダイアグラムは修正され，また以下のような疑問も生じた.

.r データの分解」というプロセスに関するもの(1)データの分解とは ，プロセスなのか?コント ロールなのか?

(2) データの分解とは，データを変換しているのか ?変換して いないのか?
入力データに関するもの(1)もともと入力されるデータとして.必要なのはどれか 7.出力に関するもの(1)要求 1 , 2 はどんな出力を返すのか? (これに関しては j メンテナンス結果では? J という意見が出された)(2) 要求 3 ，4 ，5 を職員が行なった場合.結果としては何を返すのか?

(3) 出力のリスト情報の内容はどこまで記述すればよいのか?
-ファイル(データペース)に関するもの(1)本と人のデータベースは 1 つにするか?別々にするか?
(2) ファイルはメモリ上に実現するのか ?ファイルを作成するのか?
(3) 参照するだけのファイルというのも入れておくべきなのか?

(4) ファイルへの登録はどうするのか?
(5) そもそも，ファイルの意味は何か?
-ファイル(デ ータ ベース)の検索に関するもの(1)リスト要 求と検索とは意味が遣うのか?
(2) 職員と利用者の検索は，それぞれ行なえることの権利が遣うだけなのか?
(3) ファイルへの同時交信も考えるのか?アクセスは 1 本化するのか?
-デ ータフローダイアグラムの書き方に関するもの(1)プロセスとフ ァイルの聞のデ ータフローにはネーミングの必要性があるのか?
(2) 検索の時の矢印 の 向きはどちらか?

(
3)r 検索のキーを送るが， 実際にはファイルの内容を見るだけ J という場合の情報 を引き出す"という命令は点線で書くのか?
・プロセスに関するもの(1)出力がないプロセ スは存在するのか?

‑158‑

t

4

SeamaUVo1. 6 , No.8-9・10-11

M
o
r
i
o
k
aWorkshopReport(2) プロセスの整合性は持たせるべきなのか?
.その他の疑問(1) トランザクションと，それに必要な情報との関係は?

(
2) (SQL のような)設計言語でやり方が変ってくることはないか?
以上のよ う な話し合いをしながら，データフローダイアグラムを作成したところで .B グループとの打ち合わせの時間になった .

4.B グルーアの作業
4.1 問題の分析+コンテキストダイアグラムの作成
B グループでは，問題の分析を行ないながらコ ン テキストダイアグラムを作成した .
まず，中心に図書館を置き ， さらに利用者のエンティティを置くことに関しては全員の同意を得られた.しかし"職員"の扱いに関しては .A グループと同様に利用者との遠いは何か? J という議論になった.
その他この作業中に出た疑問点は以下の通りである:- 問題の内容に関するもの(1)このシステムを利用する人は，隊員だけなのか?利用者も直接システムを利用するのか?
(2) 問題には，図書館の中で利用されるはずの書類の存在が明記されていない .

コンテキストダイアグ

ラムには書く必要がないのか?

-コンテキストダイアグラムの書き方に関するもの(1)パプルには何を書くのか?トランサ' クションかっ(2)"職員"の外部エ ン ティティが 2 つ存在したりすることはないのかっ(3) どの程度まで詳細を書けばよいのか?
(4) データフローの数だけ線を書かなければならないのか?
.ツールの利用法に関するもの(
1) StP ではコ ン トロールが書けないのか?
4.2 データフローダイアグラムの作成
こうして作成されたコンテキストダイアグラムをもとに，次にデータフローダイアグラムを作成した .

この時

以下のような疑問点が出た:(
1) 5 種類の機能要求をここで分割して処理すべきなのか?
(2) 本に関するデータベースファイルが必要になるのではないか ?
(3)( 利用者かどうかの判定を行なうために)ユーザ名ファイルも必要ではないか?

(4) 出力はリストだけでよいのか ?
(5) 利用者履歴をとってお く 必要があるのではないか?
(1)に関しては，さらに下のバブルで処理することで同意が得られた.また. (3) については.ユーザ名ファイルという概念を導入することによって，さらに以下のような提案がなされた .
- 利用者の種類によって，できることに区別をつければよいのではないか?
- ユーザ名ファイルを用意し ， それに従ってユーザが職員か利用者かの判断をするバブルを先頭に入れてはどうか?
この提案を整理し，ユーザ名ファイルを導入する上で，以下のような疑問が生じた.
- ユーザ名 (ID) の登録に関するもの(1) ユーザ名 (ID) はどこで登録されるのか?それとも ID のない人はいないと仮定するのか?

(2) 登録系は別にあると仮定するのか?
-ユーザ名ファイルの内容に関するもの

‑1
5
9‑

SeamaﾟVol.6 , No.8-9-10・11

MoriokaWorkshopReport(1)ユーザ ID と名前の両方の項目が必要なのか?
.ユーザ名ファイルの利用目的に関するもの(1)ユーザ名ファイルは利用者と職員の区別に使うのか?それとも.そのユーザがこのシステムを使え
るか使えないかの区別に使うのか?
ファイルを導入すると決定した上で，以下のような疑問が出された:.SA/SD におけるファイルの級いに関するもの(1)ファイルの 参照系と書込系は 1 つにまとめるのか ?

(2) 同じファイルは 1 つにした方がよいのか?
-今回の問題に依存したもの(1)要求 3 はマスタファイルで.要求 4 ，5 は別のファイルで処理した方がよいのではないか?

(2) 1 つのデータベースで全部の処理ができるのではないか?
(3) 検索のキーはどれでも使えるようにした方がよいのではないか ?
(4) 要求 1 と 2 の処理は分けてやった方がよいのではないか?

(5) 要求 3 ，

4 ，

5 はデータベースのでき方に依存するのではないか?

こうしてデータフローダイアグラムを作成していったが.この時点で要求 3 ， 4 , 5 を処理するバブルが 1 つのものになっていた.要求 3 ， 4 ，

5 はよく似ているため.この時点では 1 つにまとめ，下のレベルで分割すればよい，と考えたからである.

さらに出力は 1 の結果 +2 の結果+ 3 ,5.
4 , 5 の結果となる」ということで全員の合意が得られたが，ここで荻原さんからトランザクションに対して， 3 種類の別の出力を作る場合，コンテキストダイアグラムの時

点、で 3 種類出力があるようにすべきである」というコメントを受けた .
そこでもう一度コンテキストダイアグラムに戻り，出力部分について詳細に書きなおした.このようなレベル

「う

方
な

の上下聞のパックトラックは頻繁に起こるものなのか，という疑問が出されたが，これに対する荻原さんの答は，またバブルを分ける細かさの基準は? J という質問も出されたが.これは「機能がある程度まとまっていれば 1 つにする J という答であった.

さ値はダ表「下から上へと，デ ータ構造から考 える方法もある」ということであった.

4.3 データ構造の作成

データフローダイアグラムが一応完成した時点で，データ構造を作成することになった.この時点で問題になったのは，次の点である:(1)貸出・返却はどうやって入力されるのか?たとえば，

1 つの要求が入力されてから本の名前が入力され6.
広るのか，それとも同時に入力されるのか?

しかし，データ構造の定義が完成しないうちに， A グループとの打ち合わせの時間になってしまった.
5. 中間報告へ向けての話し合い

ここで， A ， B 両 グル ー プが集まって，これまでのそれぞれの成果をお 互いに発表しあった.
さ

5.
1A グループの発表れた

コンテキストダイアグラム
・ プロセスは 1 つ .

-外部エンティティは職員と利用者の 2 つ.
-データの線の本数は，最初は各データごとに 1 本ずつにしていたが，線がたくさんになることを避けて， 1
まとまりにした .
データフローダイアグラム O-デ ータを 1 まとまりにしたので，まずそのデータをふりわけるプロセス(バブル)を挿入した.

‑160‑

MoriokaWorkshopReport

SeamaUVol.6 , N
o
.
8
‑
9
‑
1
0
‑
1
1

今後の作業

- データの設計を行なう .

5.
2B グループの発表
コンテキストダイアグラム
・ プ ロセスは 1 つ.

- 外部エンティティは最初利用者と職員の 2 つにわけていたが，後で 1 つにまとめた.
・入力は 1 本，出力は種類ごとに分けである.

-要求 1 は 1 つの入力であるが，さらに分ける必要がある ?
-要求 3 ，

4 ，

5 に対しては入力が 1 本であるが ， 分ける必要がある?

データフローダイアグラム O-利用者の判断用のプロセスおよびデータベースを用意した.
データベースの検索は.その内容でかわってくるはずだが.どういう形にするか?

(id ，分類，作者 ，

名前，

u
s
e
r
̲
i
d,... . )- 出力はそれぞれのプロセスか ら 行なわれる .
データ定義- 少し進めてある状態 .
5.3. グループ全体での討論

まず，今後の方針として「今のままで行くか， A.B を一本化するか? J という問題があった . これについては，「 データフローダイアグラム O ぐらいまではお互いに同意したものを作って，その後また担当を決めて分かれた方がやりやすいかもしれない J という意見もあり ， 結局それぞれのよいところを吸収して，1 つにすることになった

ただし， 2 つのループの明確な遣いとして一般利用者と職員は分けるべきか ? J という問題がここでも議論された一般利用者と除員はシステムを使う上では同じ J という意見もあったが ， 荻原さんに「職員だけに返す
値はどこかで覚えておく必要があり，面倒かもしれない」というコメントを受けた利用者と職員を分けた理由
はつ」という質問に対してはその方が素直だから」という意見があった.が，結局 rB グループのデータフロー

ダイアグラム O は， A グループのデータフローダイアグラム 1 に入るだろう」という意見が出た段階で，中開発
表の時間となった.

6.SA/SD に対するコメント(1)と質疑
中間報告会の後 .桜井さんからさらに SA/SD 方法論に関する次のよ うな コメ ン トがあ った :稽造化のポイント.1 枚の図でわかるよ う にすること.
-名前のつけ方はあまり抽象的なものにしない(内容を連想できるように).
.周 囲か らの矢印は少ない方がよい .

-無理してまとめようとはしないこと .
さらに ， これまでの作業を通して，以下のような Q&A が桜井さんと StP グループのメンバーの間で行なわれた .

質問 1: StP は今のところワープロと同じようだ.抜けをチェックする機能などはあるのか?
回答 1: 名前のないフローは実体をわかっていないことが多い，入出力フローがあるかどうかをチェックコ

マンドがある.まず自分でデータ辞書登録を行ない ， その後チェ ッ クを起動する.チェック内容としては・(i) 上の階層と入出カの数が同じか ?

(ii) 図自体のシンタックスのチェック(フローの中身の定義を含む)(iii) 図とデータ辞書の日付のチェ ック
質問 2: ER 図のチェ ックは?

‑161‑

S
e
a
m
a
l
lVol.6 , No.8-9-10・11

MoriokaWorkshopReport

回答 2 ・できる.ただしデータ辞書は作ること

質問 3: プロセスが見えないと書けない図もあるが . .. ?

回答 3: 入力と出力から，どういうプロセスが必要かを考える.
質問 4: 今回のシステムは DB の書き換えになるが...?
回答 4: DB はユーザに見せる必要がない.
質問 5 : データフローはどこまで詳しく書くのか?

回答 5 ・「何をしたいのか? J から，どこまで必要かがわかる . 注意しなければならないこととして . How を
なるべく書かないこと
質問 6 ・データフローからソースコードを書きたいが.. . ?
回答 6: やってはいけない 1

質問 7: DB 等が最初に決ま っている場合は?
回答 7: まず DB は考えず，要求定義をする.
(i) 現状調査:データフロー図作成.

(i i) 制約の排除，ゆがみをとる . 論証モデル作成.

(ii i)これから作るシステムが何かをデータフロー図へ.
(i v) 物理的なことを考えたモジュールを作る(物理モデル) .代替案を作って現状とのかねあいを考える.

質問 8: 実現されていないが必要なチェックは?

回答 8' '意味のチェックはできていない.バブルの中でとんでもないことをしていても，外があっていれば何もしない.また， 実現 可能性のチェ ックもできて いない.

質問 9 ・( StP の機能として)複数のプロセスをまとめて 1 つ 下のレベルへおとせるか?
回答 9: 無理.ただし，バッファを使ったカット&ぺーストはできる.
質問 10: マクロがあれば便利では?

回答 10: きまりきった動作をマクロ定義している.簡単な機能を提供し，それを組み合わせると便利になるかも?
質問 11: レベルの上のものから下へは結果を反映できるが，下から上へは?
回答 11: ツールの基本姿勢として，(i)上から下へ(ii) 勝手にな おさないというものがある.上下どちらが正しいかは，ツールは判断できない.
さらに.桜井さんから以下のようなコメントがあった:

今までは一気に物理モデルを書いていた.これではマシンが変わるとついて行けない . 確かに SA/SD では，分析の時聞が今までの 3~4 倍になっているが，手戻りを短かくしている分だけ，全体で見ると短縮化できているはずである.また，ツールのメリットは再利用や検索を支媛するところにある.
こうしてグループ討論 1 日目は終わった.

7.SA/SD 仁対するコメント (2)グループ討論 2 日目は.まず全体の方針として，前日の結果を 1 つにまとめ，それから分担して今後の作業を行なうという方針を決定した.しかしその作業に対し，荻原さんと桜井さんから，以下のような種々のコメントがあった・
バブル，データフロー，ファイルにつける名前には，よしあしの判断基準がある.それは見た時や直す時に内容が理解できるか? J ということである.

そもそもバブルは，何か処理をするのが基本である.だから処理する」という名前のバブルは.具体的に何をするのかが不明である . だからバブル名としては何を何する」という名前が望ましく処理する J
や「扱う」という名前は望ましくない.同様に受けとったデータをファイルへ書く J というのもデー
タ」と書いてはあるが，内容が不明なため，意味がない‑162‑

SeamallVo1. 6 , No.8-9-10・ 11

MoriokaWorkshopReport

そこで実際に作業を行なう上で，まずデ ー タフロ ー から具体的に考えて行くべきである.デ ー タの中身

(名前 ， 本の ID. .. .) が何か?ということについて，その塊をイメ ー ジすることが大切である . 同様に，貸出­返却が具体的にどういうものかわかるようにする必要がある.こうすることで，データフローダイアグラ
ムについて共通の概念が生まれ ， たとえば本を管理するにはどういう情報が必要かつ」などの議論を行なうことができる .
質問:名前がつけられなければ.羅列でもよいのか?

答:よい.
ファイルの名前に関しでも同じことがいえるデータベ ー ス J とか本棚群 J という名前も不適である

データベ ー スの項目には，著者名などが含まれていることがわかるような名前をつける必要がある.また，「本欄群」という名前をつけると，実際の本棚のイメ ー ジを思い出してしまい，実際に本をやりとりしているかのイメ ー ジを持たせてしまう .

これは誤解を生じさせる原因となる.だから ， 本の属性を記録しておくのか，それとも有無だけを記録しておくのか，あるいは両方記録しておくのかがはっきりするような名前づけが必要である .
そもそも，デ ー タフロ ー ダイアグラムを書く上で一番むずかしく重要なのは，名前づけの作業である.これを慎重に行なうことで，ユ ー ザ要求を反映させることができる.本来 ，
ユ ー ザ・分析者閣の相互理解のための手法であり，仕様書作りでもある .

データフローダイアグラムは .

したがって，ユーザが理解できるように作成することで，手戻りを減らすことができる.
8. 丙グループの作業の対応づけ

結局.名前づけも含めて作業をやりなおすことになった.コンテキストダイアグラムでは.システムの扱う範囲を(イメージとして)決めておくことが重要である，という桜井さんのコメントに対し，両グループのコンテキストダイアグラムは表現が遣うだけである，ということで合意が得られた .

また，デ ー タフロ ー ダイアグラム O に関しては .A グル ー プにおける「デ ー タのふり分け処理 J をはずした.

この結果，両グループ閣の遣いはデ ー タベ ー スの検索の部分だけということになった

この部分に対しては.要求 3 を「利用者の検索」と「蛾員の検索 」 に分け，全体として 4 パタ ー ンの検索を考えることで合意が得られた.

そしてそれぞれのデータ名のつけ直しをしたが，桜井さんから「本来，データ名をつけ，割りふってから処理を決めるべきであり，逆だとデータ名がつけづらい.また，そのようなやり方では，処理と処理を結ぶ
デ ー タ名になってしまい，これは本末転倒であるから，最初からやり直した方がよいのではないか? J という提案があった.また，最終的にシステムから得られる出力が決まっていなかったこともあって ， 再度コン
テキストダイアグラムの段階から作業をやり直すことになった .

9.SA /SD に対するコメント(めと質疑
作業のやり直しについては，荻原さんと桜井さんから「最終的にシステムからどういう出力を得たいか?
そしてその出力を得るためには，図書館データにどういう項目が必要かつ」を考えるとよいだろう，というコメントがあった.そこで全員でこれらの検討を始めた.
その結果，要求 3.4.5 から出力としてあきらかに必要なものが 4 種類あり ， また要求 1 .2 について
は，出力を出すための手段をして考えればよいだろう，ということになった .

ここで，メンバーの 1 人から「コンテキストダイアグラムとデ ー タフロ ー ダイアグラム O は図 1 のようになるのではないか? J という提案がなされた，

しかしこの図に対し，桜井さんから「これは従来の機能による分け方である.概観図には，リクエスト
データという言葉しかない.これを定義する必要がある.また，デ ー タフローダイアグラム O のプロセス
1 は入出力が同じだが，何をしているのかつ」というコメントがあった .

さらに，コンテキストダイアグラ

ムやデータフローダイアグラムの書き方，また SA/SD について，以下のようなコメントがあった:‑163‑

SeamaUVo1. 6 , N
o
.
8
‑
9
‑
1
0
‑
1
1

MorlokaWorkshopReportl2 ~ され た コ ン テ忌 ストダイアヲラ ム 書記

図モjj思 ンス テム~IJ 問者~ 案され た デー タフ ロー ダイアグ ラ ム O 案

5

登 録.

検察を受理 する

¥

ー

、キロ

:崎

一
一一 検

/

、

Illl''

国 1 修正ダイアグラムの提案(1) バブルとは機能分解ではあるが，データのやりとりに注目することが必要である .
(2) 一枚一枚の図の中で完結していることが大事である.
(3) コンテキストダイアグラムは，システムの入力として何をどこからもらい ， 出力として何をどこへ返すかを考えるためのものである.その後で，データや構造をしっかり書く.

(
4)r 本当に細かいところは後で決める」のと一般的な名前をつける」のとは別である.要求の段階で出ているものは，記述すべきである 』(5) コンテキストダイアグラムで外部エ ン ティティとの間に矢印を引く時点で，項目の名前まで原則としてはすべてあき ら かにしなければならない . ただし項目の集まりが 1 つの名前であれば，一緒にしてもよい .

(6) 概観図はシステムの境界を決めるものである . その中に出てくるものを.すべて洗い出す .
(7) 今回の問題では. ER 図は人に関して ， 本に関してまとめる.検索に関してまとめてはいけない.

(8) 論理モデルて'は.細かなエラーは考えなくてよいメインは何か? J を考える .
(9) 登録系と検索系はまったく無関係ではない.本の情報どうしの内容が重複していれば.同じにしてもよい .
(1 0) 同じ情報なら ， 媒体の区別はしない.

(1 1) コ ン テキストダイアグラムの作成は ， 要求分析をしていることになる .

(1
2)SA と SD の聞にはギャップがある. SA=What? SD=How?
(1 3) 図を作成するのは ， 討論するためである.
これらの指摘に対し，以下のような質問が出た:

質問 1: r 人や本」は要求から見つけるのか?
回答 1: その通り.あとはユーザとの論議で見つける.

質問 2: コ ン テキスト ダ イアグラムの段階で DB が出てくることもあるのでは?
回答 2: それはあり う る.その場合は DB を作るのが目的である.

‑164‑

世

一­

e

SeamaUVo1. 6 , No.8-9-10・ 11

MoriokaWorkshopReport

質問 3: この問題では，本の情報は検索の内容に依存するが，どうする ?

回答 3: とりあえず ， 登録のメインの処理は何かを考える . あとはバックトラ ッ クで作業を進める .
質問 4: 処理が成功したかどうかを返すため，データフローを引いた方がよいのか?
回答 4: ユーザによる.

質問 5: 今回の問題は.入力はデータ指向であるのに対して，出力は処理指向ではないか? (リストというのは莫然としている .

1 冊の本と本全体の情報とは別)

回答 5: ある程度仕方がない部分もある.

質問 6 : 分析は本来少人数でやるべきではないのか?

回答 6: 1 人か 2 人でやるのがよい.ユーザとのやりとりで.説明をする時にコ ン テキストダイアグラ
ムを使う.今回は分析者とユーザの立場を往復しているようなものである .
10. 作業のやり直し

結局，コンテキストダイアグラムの作成のやり直しを行なった

その際，時間がなくなってきたので，登録・削除に関する機能 ・ 情報は削除することになった.その結果作成されたコンテキストダイアグラムは，全員の合意を得ることができた .
次に，データ構造の定義を行なった . これは桜井さんの「データ構造の定義作業を分担してやるなら，本と人間に関して分けた方がよい J というコメントから .A グループが「最後に借りた人に関する情報 J. B グ
ループが「本に関するリスト」の定義をすることになった.ここでは ， 特に問題となるようなことはなかった

続いて両者の結果を比較した.その際，問題になったのは以下のような点である:(
1)r 現在借りている人」と「最後に借りた人」の関係はどうなるのか?
(2) r 本に関するリスト J の中に「返却の有無 J r 最後に借りた人」が入るが最後に借りた人」が入力と結びつかない.どうするか?

さらに，データベースの定義を行なった.ここでは本が貸し出し中かどうか」の判断をどう扱うか，などが議論の対象になった.しかし，終了時聞が近づいたため ， 詳細の定義を適当に済ませ. StP のチェ ック
機能を実際に利用したにとどまった.

以下，まとめに入ったが.その結果は巌終報告を参照されたい.

‑165‑

SeamallVo1. 6 , No.8-9-10・11

MoriokaWorkshopReport

5.Teamwork グループの討論経過
愛学

調U骨肉告書"清和大和凶問

O. 参加メンバ

問題解決者

知念徹

(三菱電気コントロールソフトウェア)

富永伸哉(ヒラタソ フトウェアテクノロジー〉

佐藤啓太(富士ゼロックス情報システム)

万根利光(シーイーシー)

渡辺瑞枝

(SRA)

森彰三

( 富士通ビーエスシ ー)

吉田 一 知(岩手電子計算センター)

林明賢

(SRA)

大篭高之

(日本システム)

インストラクタ

田中耕市(東陽テクニカ)

コンサルタント佐藤千明(長野県協同電算)

1.問題の選択

どの問題がよいか希望をとったところ，かなりの人が 3 番を選択した .これは メンバーの多くが 制御系の仕 事をしているためである.別の問題を選 んだ人か らも特に反対意見がでなかったため，制御系問題である 3 番 (ガス給湯システム)に決定した.
2. 問題の理解

続いてツ ール の説明が行なわれる予定だったが.ツ ールは あくまでも手段であり，先にど んな問題かを頭に入れておいた方がよいという意見が出たため.ここで問題を読むことになった . 次のような意見が出た:(1)問題ですでにかなり詳細に設計されている.

(2) まず存在するハードウェアの略図をかいてみればわかりやすい(視覚的アプローチが重要)(2) に関しては，この時点から CASE ツールを使っていかなければ意味がないという意見が出たため.次のツール説明の後にしようということになった.
3. ツールの謹明
田中さんから Teamwork の操作法の説明が行なわれた.そこでは.日本語処理やグラフィックス関係などの質問が出た.基本操作以外にも以下のような質問があった:(1)チェック機能は十分か?図の間違い.シンタックス，データの一貫性等)(2) メモ用のお絵書きツールは付随しているか?
(3) ツールを使って問題を解く時，どのくらいの人数が適当か?
(4) 多人数だとかえって意見の不一致などで効率が惑いのでは?
(5) どのような役割分担が適切かっ
4. コンテキスト-ダイアグラム (CD) の作成
入出力情報をあらいだし CD を作成してい った.この際 ，以下のよ うな意見や質問が出た.

(1)スイ ッ チ類を B C(パスコントローラ)としてまとめてよいか?
多数のランプ信号を 1 つの矢印でまとめては?

入力をまとめて考えておいて，あとで詳細化してはどうか?
→全てあらいだした方がよい.

「湯釜 J としてまとめてあるのはどうするのか?
→ DD で詳細に定義する .

‑166‑

SeamallVol.6 , N
o
.
8
‑
9
‑
1
0
‑
1
1

MoriokaWorkshopReport

CD は詳細にしたほうがよいか，まとめた方がよいか?

→場合によってやりやすい(見やすい)方にする.

(2) r ガス J や「水」は入力か?
→これらは物理的なもので「情報 J ではない
(3) 同じ名前のデータがあってもよいのか?
TOOL 上では大丈夫か?
→ Yes . まったくく同じ意味ならよい .

消火も含むので点火信号」より「燃焼信号 J の方がよい

名前の定義はあとでかさならないようにした方がよい『シグナル J と「信号」という名前を使っているが，統一すべきだ

作成が終了した時点でツールによるシンタックスのチェックを行ない OK となった.
5. データ・フロ ー ・ダイアグラム (DFD) の作成
DFD 作成にあたり，全体的な質問として次のようなものが出た.
(1)初期処理は?

→機能ではないのでバブルにはならない(2) 全体を制御するものは?
→コントロール仕様でかけばよい(状態遷移表など).
5.1 主要バプルの決定

まず，主要な徳能をもとにいくつかのバブルを作り，そのあと 1 つどこかのバブルを選んで，そこからデ ー タの涜れを追って書いていこうということになった.主要バブルとして次の 3 つをの洗いだした (A 案):
1.給湯(給湯せんに給湯する)

2. お湯はり(浴槽にお湯をはる)

3 . 追いだき(追いだきをする)
ところが，とこでデータの入出力を書き込もうとしたところ，どうもうまくいかない(たとえば「水量」というデータはすべてのバブルにはいってしまう).そこで，バブルの設定が悪いのかもしれないということになり.

次のような別の考え方にもとづく主要バブルにしてみては，という意見が出た (B 案)・
1.温度調節2 . 水量監視
3. 弁の切替え
ここで非常に長時間にわたる議論が行なわれた.以下に主要な意見を記す ・.A 案はシステムの外側から見た機能による分類である.それに対し， B 案はシステムの内側から見た(すなわちモジュ ー ル化などを意識した)機能分類である.
.A 案のバブルが B 案のバブルをコントロ ー ルするようにしてはどうか?
.A 案でやっても結局下の階層で B 案のバブルが出てくるのでは?

- 第 1 段階のバブルの認識が一番難しい.
.2 つの観点で作ってみてはどうか?

-モジュ ー ルとバブルの関係は?

-始めにバブルから考えたのは間違いだったのではないか?デ ー タの流れを中心に考えればよかった)
結局，意見がまとまらなかったので ， 全員がとりあえず DFD を書いてみてそれから考えるということになった .

5.2 作業方針の決定
各自の書いた DFD を全員で分析した結果，いずれも先ほどの A 案か B 案のどちらかに分類できることがわ

かった.ちょうど人数も半々に分かれたので，マシンも 2 台あることだし， 2 班に分かれてやってみようということになった.班の編成は次のようになった.

第 1 班(温度調節，水量監視などに分ける)

‑167‑

園田里里

SeamaHVol.6 , No.8-9-10・11

MoriokaWorkshopReport

刀根，吉田，株，富永パ田中)
第 2 班(給湯，お湯張りなどに分ける)
渡辺，大篭，森，佐藤，知念

5.
3DFD の作成
2 班に分かれてからは.それぞれの考えにもとづいて，作業は順調に進み出した.作業中に出た質問や意見を以下に記す:
第 1 班-システムが今どんな状怒になっているかが不明{お湯張り，給湯など) .

→コントロール ・ フローがしっかりしなければならない .
-火力と水量の調節は分けでは考えられない.
→温度調節という 1 つのバブルにする-データのチェックが手作業よりはるかに楽だ.
.どこまでバブルを細かく分けたらよいのか?
-バブルはすべて同時に動いていると考えるのか?
・点火はどのレベル(階層)におけばよいか?
第2班

・せっかくツールがあるのだから議論ばかりしていないでどんどんやってみよう .
作業は順調に進んでいるが果たして動くのか?
制御系はデータ ・ フローを書くのが難しい.

-バブルを中心に考えたので ， バブル同士が全然つながらない.
-作った後で，同じ機能のバブルがあるから上の階層にあげようということが，よく起こった .結局 ，この「共通部品を上にあげる J という手順を繰り返すうちに，第 1 班の考え方に近づいてきた.

-ツールがあるおかげて'パ ッ クトラックが簡単だ.
感想としては，第 2 班の方が作業が順調に進んでいたようだ.第 1 班はバブルの認識(どこまで細分化するか，どれをまとめるか)に苦労していた . そして 2 班の作業が進むうち. DFD が 1 班 のものに近くなっていった .
ここまでで.

2 班ともに一応 DFD ができあがった .

6. コントロール・フローの作成

最後に，リアルタイムデータフローの制御部分であるコントロールフロ ーを作成した .まず田中さんから制御のための各図表類 ( P AT, DT ， STD) の作り方の説明があった.ここで:・どんな順序で作るのか?
-どこから考えていくのか?

.DFD の階層と の関係は?
ー 階層ごとに作るのか?
といった基本的な質問が数多く出た .

これは. DFD に比ぺ制御関係は非常に複雑だからだろ う(シンタックスなど) .
作成途中では，以下のような質問や意見が出た:- システムの異常への対応はつ(エラー処理).DFD に 書いである信号. STD に書いである信号，それらが各レベルに展開したりしているのでとてもわ
かりにくい.
とにかく，このようにしてなんとか制御部分まで完成した.ここでツールを使って各種の図表を出力したり，エラーをチェックしたところで時間切れとなり，まとめにはいった .

‑168‑