DFDコンテキストダイアグラムのターミネータ

データフローダイアグラムを教わり、まず最初にコンテキストダイアグラムを描こうとして、多くの初心者が困る事項として、「はたしてターミネータとはいかなるものか?」ということのようです。

具体的にその困惑の内容を書くと、例えば入出力用のターミネータについて

自分が作ろうとしているプログラムの外のものなのか?–プログラムの外ってどこから?

  1. 例えば文字端末入力(Windows ならコマンドプロンプトの入力)をターミネータとしたいとしたら、それは
    1. cmd.exe の標準入力に OS からデータが渡される、その際の OS 側部分がターミネータなのか?
    2. cmd.exe の標準入力から OS にデータが渡るその際の外側 (cmd.exe に含まれる部分) がターミネータなのか?
    3. OS (Windows) 環境からプログラムプロセスに入力データが渡されるその際の外側の部分なのか?
    4. プログラムが OS の入力ライブラリを利用していたとしたら、それは自分では作らないから、その部分なのか?
  2. 例えば出力はエラー出力と通常の出力が分かれているけれど
    1. Cのスタンダードライブラリーで標準出力、標準エラー出力は分かれているけれど、これって cmd.exe でリダイレクトなどで分けないと、普通に利用者側には同じ出力先に出ているようにみえるけれど、ターミネータは分けるの?分けないの? – cmd.exe が端末出力の出力先としては一つしかないように見えるけれど、cmd.exe が端末出力する際に出力データを受け取る口は、標準出力と標準エラー出力との二つの口を準備しているように見える・・・
    2. 文字端末入力同様にターミネータになる対象が cmd.exe の出力先から OS の出力ライブラリまで、いろいろ考えられる。

では、どれが正解なのか?

実際のところ、どれでも正解足りえます。

これは

我々はコレコレをターミネータとします

と、どれか一つにするんです!と決めれば、それが正解で、それ以外のものは不正解になる。自分の作るプログラム (システム) の内側は、ここまでですとすればよい。コンテキストダイアグラムの○の中に含まれるものは何であるかを決めるということです。

この「コレコレ」が、プログラムをビルドした際にリンクされたライブラリまではシステムの内側ですとすれば、上の入力に対する疑問には 1.C. のOS 環境からプログラムプロセスに入力データが渡されるその際の外側の部分がターミネータと解釈すればよくなる。

それでは、世間的にはどの立場をとっているのか?と気になってくるかもしれませんが、これもおそらく一つのプロジェクトの中でも、どの開発フェーズ(プロセス)にあるか、どの DFD を描いているのか、要求の DFD なのか、設計の DFD なのかなどの違いで異なっているのが現実ではないかと思えます。

関わっている人たちが、そこらへんを心得ているか、ちゃんと定義していれば、それで問題が無い。「要求仕様の DFD は、1.A. の解釈で描くけれど、設計仕様では 1.D. の解釈で描きますよ」と言った具合に分かっていれば、問題は起こらない。

ただし、もちろん要求仕様の DFD で 1.A. と 1.D. が混在してはいけない。そして決めないのもいけない。決めて周知したのに、勝手に変えるのもいけない。

とはいえ、要望から要求を起こすような初期のフェーズであまり堅苦しく決めてもフットワークが悪くなるので、ラフな要求がまとまってきたら、それ(どんなOS上でとか、プログラムの外部環境など)による制約も分かってくるはずなので、そこらへんの時点から「何を○の中とするか」を決めればよろしいでしょう。

2.A. については、要求仕様として通常の出力とエラー出力を分けないならターミネーターは一つですし、分けるなら二つになります。設計はこれに準じます。

カテゴリー: 構造化手法 パーマリンク

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください