システム開発技術

システム開発者の皆様へ、システム設計方法にはいくつかあるが、私が長年用いてる階層的手法があります。
その概念はシステム全体から最終的なプログラムモジュールへとトップダウンで階層的に分割して技法、この場合上位のレベルでは、分割の構成要素は、サブシステム、ジョブ等、ログラムモジュールとは直接対応しない概念的まとまりになる。
私は初めてプログラムを組んだ時から構造化プログラミングを行っています、なぜなら、頭の容量が小さいので、最初に理解できているところから作成ただし入出力は明確にしておく。この方法が構造化プログラミングの方法であることに気づいたの入社後５年後であった。

図ー１　階層的設計

構造化プログラミング（こうぞうかプログラミング、（英: structured programming）は、コンピュータプログラムの処理手順の明瞭化、平易化、判読性向上を目的にしたプログラミング手法である。一般的には順接、分岐、反復の三種の制御構造（control structures）によって処理の流れを記述することと認識されている。制御構造は制御構文、構造化文（structured statement）、制御フロー文（control flow statement）とも呼ばれる。また、プログラムを任意に分割した部分プログラム（サブルーチンとコードブロック）の階層的な組み合わせによるプログラムの構造化も指している。

このプログラミング手法の普及に貢献したのは、1968年の計算機科学者エドガー・ダイクストラによるACM機関紙への投書「Go To Statement Considered Harmful」と言われている。しかし同じくダイクストラが、1969年度NATOソフトウェア工学会議で発表した論文「Structured Programming」との混同を招いてこちら側の名称で知られるようになった。現在に到るまでの国内外の多くの書籍で、構造化プログラミングは制御構文に関する説明に結び付けられている。なお、1969年の論文内容はプログラム正当性検証のための設計技法を扱っており、トップダウン設計、段階的な抽象化、階層的なモジュール化、抽象データ構造と抽象ステートメントを連携させる共同詳細化といった考え方が提唱されていた。

制御構文[編集]

詳細は「ミルズの構造化プログラミング」を参照

制御構文（control structures）とは、goto文によるフロー分岐やループ表現を、if文の選択構文やwhile文の反復構文に置き換えるためのプログラム記法を意味している。ラベル先にジャンプするというgoto文の機能を、if文やwhile文は「特定のコード群だけを実行する」という概念に置き換えている。goto文を用いた制御フローは、(1)データの照合/比較の結果にしたがって次の実行コード群を選択するパターンと、(2)データの照合/比較の結果が任意条件を満たしているならば実行コード群を反復するパターンの、二通りに集約されることが経験則で知られていたので、これを専用の記号で形式化したのが制御構文であった。

コード群とは命令コード（instruction code）のまとまりであり、構造化定理では部分プログラム（subprogram）と定義されている。部分プログラムはステートメント（statement）コードブロック（code block）サブルーチン（subroutine）の総称である。ステートメントは命令コードの一行を意味する。コードブロックは一行以上のステートメントをまとめたものである。サブルーチンは一行以上のステートメントまたは一個以上のコードブロックを内包している。部分プログラムは直列状または入れ子状に配置される。その実行順序を決定するものが制御構文であり、以下の三つがある。

1. 順次（sequence）部分プログラムを順々に実行する。

2. 選択（selection）条件式が導出した状態に従い、次に実行する部分プログラムを選択して分岐する。

3. 反復（repetition）条件式が導出した特定の状態の間、部分プログラムを繰り返し実行する。

図－２　制御構文

制御構造の導入は1960年公開の「ALGOL60」まで遡れるが、当時広く使われていたFORTRANやCOBOLでの正式導入は1977年以降だったので、多くの開発現場では馴染みのないものであった。1966年にコラド・ベームらが「順次・選択・反復」のフロー万能性を数学的に証明したが、それはあくまで論理的研究だった。それを参考にしたとされるダイクストラの1968年の投書「goto文は有害」はいわゆるgoto文論争を引き起こしたが、同時に制御構造への関心を大きく高めた。1970年代、goto文が多用される開発現場での制御構造の普及を重視していたIBM社のハーラン・ミルズは、1969年にダイクストラが発表していた論文題名から知名度を得ていた「構造化プログラミング」を自社の技術セミナーマーケティングに活用するために、上述のベームらの数学的証明を「構造化定理」という独自のタイトルで復刻させて、彼らが勧めるフローチャート制御構造の裏付け理論にした。こうして構造化プログラミングは、IBM社が提唱する構造化定理を論拠にした制御構造を用いるプログラミング手法として世間に定着することになった。
上記のような内容でＧＯＴＯ文は嫌われ、Gotolessプログラミングという言葉も生まれた。

制御構造を導入したプログラミング言語を指しての「構造化言語」というワードが浮上したのは1970年代からであり、これは当時のgoto文中心だったFORTRANやCOBOLやBASICを意識してそれと線引きするための用語として存在していた。

構造化設計[編集]

詳細は「段階的詳細化法」を参照

上述の制御構文をコーディング視点の下流工程テクニックとすると、構造化設計（structured design）はプログラムデザイン視点の上流工程テクニックであり、こちらも構造化プログラミングと呼ばれるものである。構造化設計では、サブルーチン（subroutine）をまとめたサブルーチン複合体と、データ要素をまとめたデータ構造（data structure）が主要な役割を果たしている。段階的詳細化に則ったサブルーチン複合体の階層的な組み合わせと、それに必要なデータ構造を連携させてプログラム全体を構築するというテクニックが構造化設計である。サブルーチン複合体はプログラムモジュール（program module）とも読み替えられ、モジュール凝集度と結合度もここから生まれている。

この構造化設計と、ダイクストラの構造化プログラミングの違いは、前者がサブルーチン複合体とデータ構造の連携を中心にしたテクニックであるのに対して、後者は専属サブルーチンを通して扱われる抽象データ構造を中心にしたテクニックであるという点である。後者では、段階的に抽象化した各モジュールの階層的な連結と、抽象データ構造と抽象ステートメントを連携させる共同詳細化といった考え方が提示されており、この詳細については後節で述べられる。ダイクストラが提唱した抽象（abstraction）指向の構造化は、その思想の前衛性から1970年代を通して理解を得られることはなく、発案者本来の構造化プログラミングは上流工程視点からも普及することはなかった。

内容が複雑になったが、簡単に私の考える構造化設計は、最初に理解できているところから作成、ただし入出力は明確にしておく。この方法が構造化設計の基本と考えています。（図ー１　参照）
この構造化設計の考え方は業務フロ－作成においても利用できます

図ー３　業務分析1

図ー３を階層的に分解すると
　

図ー4　業務階層化

詳細は

をご覧ください。