●抽象化ブレークダウン式構造化プログラミング（COBOLベース）
業務処理のプログラムを作成する場合の１手法をCOBOLベースで紹介しよう。
手法名が長いのでBDFA（Breaking down from abstraction）手法と呼ぶことにする。
コーディングの概念は下図の要領だ。気まぐれな気力がどこまで続くか分からないけどやってみよう。
ブレークダウンしていくと、自然と細部コーディングがされていく手法である。
●理解しやすくするために、「簡易例題1 人事マスターの作成」
ここに新しい合同会社、「三国志」を設立した３人の男がいる。劉備社長、関羽総務部長、張飛営業部長だ。あなたは孔明、IT部長である。社長から人事マスターを作るよう指示があったので、早速プログラミングにとりかかった。
簡単なプログラム仕様は下図のとおり。４人ぐらいのデータなら手作業でできるが、将来の急速な会社発展（社員１万人超）を考えて、バッチ（一括）処理を行う。
●BDFA手順１ 上位抽象化パターンの適用
まず機械的に上位抽象化パターンを適用する。次に、前処理、主処理、後処理のプログラム構造を解析するのだが、その時に、着目するのが、
・制御フラグ：プログラム全体のフローを制御するフラグ
・処理フラグ：業務処理の判別をするフラグ
●BDFA手順2 制御フラグの抽出設定とデシジョン・テーブル解析
プログラムはどの言語であれ、フローの骨格は３つの処理でできている。順次処理、繰返し処理（COBOLならPERFORM文、Pythonならwhile文）、分岐処理（COBOLならIF、EVALUATE文、Pythonならif文）である。
ここでは分岐処理に着目する。
プログラムの終了は、トランザクション・ファイル（ＴＲ－Ｆ）のＥＮＤなので、制御フラグをＴＲ－ＥＮＤとする。
前処理でＴＲ－ＥＮＤに“ＯＦＦ”をセットする。そしてＴＲ入力処理（中位抽象化）を１回行う。
次の主処理では、ＴＲ－ＥＮＤ＝“ＯＦＦ”であれば、トランザクション・レコード（ＴＲ－Ｒ）を人事マスタ（ＪＭ-Ｒ）に移送し、ＪＭ－Ｒを書き込む。そして次のＴＲ-Ｒを読み込む。ブレークダウン対象（中位抽象化）としてＪＭ出力処理、ＴＲ入力処理を設定する。ＴＲ－ＥＮＤ＝“ＯＦＦ”の間は、主処理を繰り返す。
ＴＲ－ＥＮＤ＝“ＯＮ”になれば、後処理に移る。
以上の解析をデシジョン・テーブル（ＤＴ）を使って整理する。
ここで、具体的にコーディングできるものはコード化する。
例えば、前処理なら
OPEN INPUT TR-F OUTPUT JM-F（入出力ファイルのオープン）
MOVE “OFF” TO TR-END（制御フラグの初期セット）
PERFORM TR-IN (次のブレークダウン対象)
例えば、主処理なら
PERFORM JM-OUT (次のブレークダウン対象)
PERFORM TR-IN (次のブレークダウン対象)
主処理が終了したら、後処理となる。
CLOSE TR-F JM-F
ここでＤＴの点検を行うと、前処理でＴＲ－ＥＮＤに“ＯＦＦ”をセットしているので、制御フラグの判定表の「３」、すなわち制御フラグが“ＯＦＦ”でもなく、“ＯＮ”でもない判定条件は余計であることが分かる。従って「フラグセットエラー表示処理」は不要として、コーディングの際に削除する。
●BDFA手順3 処理フラグの抽出設定とデシジョン・テーブル解析
次は業務処理フローを判別するために、処理フラグの抽出設定とＤＴ解析を行うのだが、今回の簡易例題１では、制御フラグであるＴＲ－ＥＮＤが処理フラグにもなっている（”ＯＦＦ”なら主処理）ので、ＤＴ解析は不要である。
残るは、抽象化のままの、ＪＭ出力処理とＴＲ入力処理のブレークダウンである。
ブレークダウンの結果をみると、抽象化する部分がなくなりコード化されたので、コーディング終了となる。
プログラム完了である。
●処理フラグとＤＴ解析について。追加説明。
業務処理の構造化と抽象化を行う処理フラグについて、上記の例題では説明できなかったので補足しよう。
合同会社「三国志」はますます発展し、本社を蜀CITYに移した。社員も当然大幅に増えた。趙雲開発部長はその目覚ましい活躍により開発本部長に昇格した。また新しく外部から社長室付きの黄忠顧問を招来した。重大な命令違反があった馬謖ＩＴ部長が懲戒免職で社を去った。他にも多くの社員の人事異動があった。そこで孔明CIO（最高情報責任者）は、新しく昇格した姜維ＩＴ部長に人事異動プログラムの開発を命じた。驚いたことに馬謖ＩＴ部長は今のいままで人事異動プログラムを開発していなかったのだ！そのことも懲戒免職の理由の１つだった。
人事異動プログラムの概要
これまでの人事トランザクション・レコードの先頭に、U（更新）、I（挿入）、D（削除）の異動コード項目を加える。
異動ＴＲを読み込み、ＴＲの社員IDでマッチングした人事マスタに異動処理を行う。
異動ＴＲ（順ファイル）がエンドになるとプログラム終了。
プログラム仕様は下図の通り。
●再度、BDFA手順3 処理フラグの抽出設定とデシジョン・テーブル解析。
ＴＲがエンドになったらプログラム終了であるから、プログラム全体のフローを制御するフラグはTR-ENDとなる。これについての制御とＤＴについては、上記で説明しているので割愛する。
さて業務処理の構造区分と制御を左右する処理フラグは、下図のＤＴ解析から、ＴＲの異動ＣＤ（Ｕ、Ｉ、Ｄ）と社員ＩＤである。ＤＴからフローチャートに展開すると下図の主処理となる。
もちろんこのままフローチャートからコーディングできるが、ＤＴを点検して、改善することができる。
●BDFA手順3-1 デシジョン・テーブルの改善解析。
改善後ＤＴは下図のとおり。見ての通りＤＴからコーディングも可能で、抽象化にも役に立つツールだ。ＤＴ条件の中の「社員ＩＤがマッチ」等の記述は、直接コーディングにつながらずブレークダウンが必要だが、処理構造の区分・分岐を分かりやすくするために敢えてそうした。いずれにしてもこのＤＴはコーディングと等価であり、各言語への自動コード生成が可能だ。
フローチャートもいいツールだが、ＤＴの良さは情報圧縮された一覧性と判定・分岐の可読性に優れている点である。
以上、BDFA（Breaking down from abstraction）手法と勝手に命名した構造化プログラミング開発手法を紹介しましたが、現役プログラマー諸氏に少しでもお役に立てれば幸いです。
まだ書きかけで未整理のゲーム記事がたくさん残っているので、これにて。
業務処理のプログラムを作成する場合の１手法をCOBOLベースで紹介しよう。
手法名が長いのでBDFA（Breaking down from abstraction）手法と呼ぶことにする。
コーディングの概念は下図の要領だ。気まぐれな気力がどこまで続くか分からないけどやってみよう。
ブレークダウンしていくと、自然と細部コーディングがされていく手法である。
●理解しやすくするために、「簡易例題1 人事マスターの作成」
ここに新しい合同会社、「三国志」を設立した３人の男がいる。劉備社長、関羽総務部長、張飛営業部長だ。あなたは孔明、IT部長である。社長から人事マスターを作るよう指示があったので、早速プログラミングにとりかかった。
簡単なプログラム仕様は下図のとおり。４人ぐらいのデータなら手作業でできるが、将来の急速な会社発展（社員１万人超）を考えて、バッチ（一括）処理を行う。
●BDFA手順１ 上位抽象化パターンの適用
まず機械的に上位抽象化パターンを適用する。次に、前処理、主処理、後処理のプログラム構造を解析するのだが、その時に、着目するのが、
・制御フラグ：プログラム全体のフローを制御するフラグ
・処理フラグ：業務処理の判別をするフラグ
●BDFA手順2 制御フラグの抽出設定とデシジョン・テーブル解析
プログラムはどの言語であれ、フローの骨格は３つの処理でできている。順次処理、繰返し処理（COBOLならPERFORM文、Pythonならwhile文）、分岐処理（COBOLならIF、EVALUATE文、Pythonならif文）である。
ここでは分岐処理に着目する。
プログラムの終了は、トランザクション・ファイル（ＴＲ－Ｆ）のＥＮＤなので、制御フラグをＴＲ－ＥＮＤとする。
前処理でＴＲ－ＥＮＤに“ＯＦＦ”をセットする。そしてＴＲ入力処理（中位抽象化）を１回行う。
次の主処理では、ＴＲ－ＥＮＤ＝“ＯＦＦ”であれば、トランザクション・レコード（ＴＲ－Ｒ）を人事マスタ（ＪＭ-Ｒ）に移送し、ＪＭ－Ｒを書き込む。そして次のＴＲ-Ｒを読み込む。ブレークダウン対象（中位抽象化）としてＪＭ出力処理、ＴＲ入力処理を設定する。ＴＲ－ＥＮＤ＝“ＯＦＦ”の間は、主処理を繰り返す。
ＴＲ－ＥＮＤ＝“ＯＮ”になれば、後処理に移る。
以上の解析をデシジョン・テーブル（ＤＴ）を使って整理する。
ここで、具体的にコーディングできるものはコード化する。
例えば、前処理なら
OPEN INPUT TR-F OUTPUT JM-F（入出力ファイルのオープン）
MOVE “OFF” TO TR-END（制御フラグの初期セット）
PERFORM TR-IN (次のブレークダウン対象)
例えば、主処理なら
PERFORM JM-OUT (次のブレークダウン対象)
PERFORM TR-IN (次のブレークダウン対象)
主処理が終了したら、後処理となる。
CLOSE TR-F JM-F
ここでＤＴの点検を行うと、前処理でＴＲ－ＥＮＤに“ＯＦＦ”をセットしているので、制御フラグの判定表の「３」、すなわち制御フラグが“ＯＦＦ”でもなく、“ＯＮ”でもない判定条件は余計であることが分かる。従って「フラグセットエラー表示処理」は不要として、コーディングの際に削除する。
●BDFA手順3 処理フラグの抽出設定とデシジョン・テーブル解析
次は業務処理フローを判別するために、処理フラグの抽出設定とＤＴ解析を行うのだが、今回の簡易例題１では、制御フラグであるＴＲ－ＥＮＤが処理フラグにもなっている（”ＯＦＦ”なら主処理）ので、ＤＴ解析は不要である。
残るは、抽象化のままの、ＪＭ出力処理とＴＲ入力処理のブレークダウンである。
ブレークダウンの結果をみると、抽象化する部分がなくなりコード化されたので、コーディング終了となる。
プログラム完了である。
●処理フラグとＤＴ解析について。追加説明。
業務処理の構造化と抽象化を行う処理フラグについて、上記の例題では説明できなかったので補足しよう。
合同会社「三国志」はますます発展し、本社を蜀CITYに移した。社員も当然大幅に増えた。趙雲開発部長はその目覚ましい活躍により開発本部長に昇格した。また新しく外部から社長室付きの黄忠顧問を招来した。重大な命令違反があった馬謖ＩＴ部長が懲戒免職で社を去った。他にも多くの社員の人事異動があった。そこで孔明CIO（最高情報責任者）は、新しく昇格した姜維ＩＴ部長に人事異動プログラムの開発を命じた。驚いたことに馬謖ＩＴ部長は今のいままで人事異動プログラムを開発していなかったのだ！そのことも懲戒免職の理由の１つだった。
人事異動プログラムの概要
これまでの人事トランザクション・レコードの先頭に、U（更新）、I（挿入）、D（削除）の異動コード項目を加える。
異動ＴＲを読み込み、ＴＲの社員IDでマッチングした人事マスタに異動処理を行う。
異動ＴＲ（順ファイル）がエンドになるとプログラム終了。
プログラム仕様は下図の通り。
●再度、BDFA手順3 処理フラグの抽出設定とデシジョン・テーブル解析。
ＴＲがエンドになったらプログラム終了であるから、プログラム全体のフローを制御するフラグはTR-ENDとなる。これについての制御とＤＴについては、上記で説明しているので割愛する。
さて業務処理の構造区分と制御を左右する処理フラグは、下図のＤＴ解析から、ＴＲの異動ＣＤ（Ｕ、Ｉ、Ｄ）と社員ＩＤである。ＤＴからフローチャートに展開すると下図の主処理となる。
もちろんこのままフローチャートからコーディングできるが、ＤＴを点検して、改善することができる。
●BDFA手順3-1 デシジョン・テーブルの改善解析。
改善後ＤＴは下図のとおり。見ての通りＤＴからコーディングも可能で、抽象化にも役に立つツールだ。ＤＴ条件の中の「社員ＩＤがマッチ」等の記述は、直接コーディングにつながらずブレークダウンが必要だが、処理構造の区分・分岐を分かりやすくするために敢えてそうした。いずれにしてもこのＤＴはコーディングと等価であり、各言語への自動コード生成が可能だ。
フローチャートもいいツールだが、ＤＴの良さは情報圧縮された一覧性と判定・分岐の可読性に優れている点である。
以上、BDFA（Breaking down from abstraction）手法と勝手に命名した構造化プログラミング開発手法を紹介しましたが、現役プログラマー諸氏に少しでもお役に立てれば幸いです。
まだ書きかけで未整理のゲーム記事がたくさん残っているので、これにて。