部品化と再利用

部品化と再利用の手段

機械を設計するのに、ボルトやナットまで設計することは稀です。それは形状、材質、強度などが一定水準の品質であることが規格化されているからです。このように工業製品では、標準化した部品を用いることにより、生産の合理化、品質保証を実現しています。
　それと同様に、ソフトウェアでも、部品化をして再利用することが行われてきました。

サブルーチン

技術計算での「方程式の求根」や「連立方程式の解」、事務処理での「ファイルの操作」や「データのソート」など、多くのプログラムで共通して利用される処理があります。その処理プログラムをサブルーチンや副プログラムといいます。オブジェクト指向言語系ではクラスとして扱われます。サブルーチンを集めたものをライブラリといいます。
　これを利用すれば、プログラマはコーディングするメインプログラム（主プログラム）の中で、サブルーチンにある処理部分はそれを呼び出す命令を記述することができます。それにより、次のようなメリットがります。

• 「方程式の求根」など高度のロジックをサブルーチンにすることにより、その解法を知らなくても利用できます。科学計算分野では、サブルーチンは非常に普及しています（参照：「数値解析」）。
• サブルーチンの部分はコーディングが不要ですから、コーディング量が低減できます。
• サブルーチンは、既に多くの利用で信頼性が高いことが認められており、その部分のテストは不要です。そのため、品質の高いプログラムになります。
• サブルーチンが対象としているロジックに変更が必要になったとき、サブルーチンを使わずに個々のプログラムで記述しているならば、それに関係しているすべてのプログラムを改訂しなければなりません。それを欠落なしに探すのは大変な作業になります。そてに対してサブルーチンを利用しているならば、それだけを改訂すればよいことになります。すなわち。改訂に即応できるシステムになります。

サブルーチンは、言語ソフトウェアでの提供。アドオンソフト、市販ライブラリなどがありますが、自作することもあります。自作の場合、広く利用でき、利用勝手のよいサブルーチンにするには、モジュール分割の評価基準を参照するのが適切です。

標準パターン

事務処理では、ソート、照合、集計など、似たような処理が多くあります。サブルーチンとは逆に、メインルーチンが担当するフレームを汎用的に使えるプログラムとして標準化しておき、その中で個別処理をする部分だけをコーディングします。

事前に中計キー、小計キーでソートされているファイルを読んで、明細行、小計、中計、総計の表を出力する標準パターンを例にします。
　そのロジックを記述したメインプログラム（標準パターン）を用意しておき、ファイルの仕様、ソートキーや累積項目の変数、コントロールブレイクした（小計、中計が発生した）ときの処理プログラムを記述する場所に印をつけておきます。プログラムするときは、その場所だけをコーディングすればよいのです。

ここでは疑似言語を用いており、指定指示もあいまいですが、イメージはつかめるでしょう。

メインプログラム（標準パターン）
　　総計累計項目 = 0　　　　　
　　call ファイル読込
　　while (データがある間) {
　　　　前中計キー = 中計キー
　　　　中計累計項目 = 0
　　　　while (中計キー == 前中計キー) {
　　　　　　前小計キー = 小計キー
　　　　　　小計累計項目 = 0
　　　　　　while ((中計キー == 前中計キー) and (小計キー == 前小計キー)) {
　　　　　　　　call 明細行処理
　　　　　　　　小計累計項目 = 小計累計項目 + 明細累計項目
　　　　　　　　call ファイル読込
　　　　　　}
　　　　　　call 小計処理
　　　　　　中計累計項目 = 中計累計項目 + 小計累計項目
　　　　}
　　　　call 中計処理
　　　　総計累計項目 = 総計累計項目 + 中計累計項目
　　}　　
　　call 総計処理

サブルーチン（個別記述）
　　ファイル読込
　　　　中・小計キー、明細累計項目の定義
　　　　ファイルのデータがなくなったときのフラグ設定
　　明細行処理
　　　　明細行累計項目間の計算と出力
　　小計処理
　　　　小計累計項目間の計算と出力
　　中計処理
　　　　中計累計項目間の計算と出力
　　総計処理
　　　　総計累計項目間の計算と出力

このような標準パターンを検討するには、プログラムを全体かから細部に階層的に分割し、細部を実行する順序をします。そして、汎用化する部分と個別記述する部分を区分することになります。すなわち、構造化設計で設計することになり、標準パターンを利用して生成したプログラムは構造化プログラムになります。

関係者全員が、標準パターンを使えば、プログラムのどの部分で何をしているかが共通理解できます。これはウォークスルーの実施で大きな効果があります。また、多様な標準パターンが用意されていえば、システム全体を標準パターンの組合せとして構築することにつながります。

部品再利用を前提としたシステム開発

システム開発アプローチ

ＤＯＡ（データ中心アプローチ）

販売システム、会計システムなど業務を縦割りにして、担当者がどのデータをどのように処理するかをプログラムする方法をプロセス中心アプローチ（ＰＯＡ）といいます。そのようなアプローチでは、得意先や商品、売上データなどを、多くのシステムで個別に定義し、生成・運用することになります。それに対して、ＤＯＡでは業務横断的に必要となる項目やデータをデータベースにし、各業務はそれらを参照したり更新することだとするアプローチです。すなわち、データの部品化だといえます。

、

ＯＯＡ（オブジェクト指向アプローチ）

例えば、売上ファイルのデータの追加をする受注、出荷フラグを立てる納品など、データベースとそのデータを処理するプログラム（メソッド）を部品化部品化しました。

ＳＯＡ（サービス指向アーキテクチャ）

さらに部品の粒度を大きくして、受注とか在庫確認など、業務として意味のある単位（サービス）を部品化たものです。

非手続き型言語

修正個所を発見するには、プログラムのステップ数が短いほうが容易です。ＣＯＢＯＬのような手続き型言語に比べてＳＱＬのような非手続き言語を用いれば、ステップ数は非常に少なくなります。非手続き型言語は、標準パターンを言語化して汎用性を高めたものだと解釈することもできます（参照：「プログラミング言語の発展」）。

部品化と再利用の推進

部品化のメリット

• 開発において、白紙の状態から開発するよりも、部品を組み合わせて作るほうが労力がかからない。
• 個々の部品の品質が保証されているならば、それを組み合わせて作成した情報システムの品質が向上するし、品質確認する範囲を少なくすることができる。
• 標準化された部品を標準化さらた方法で組み合わせる方法を確立すれば、個人による差異が少なくなり、初心者でもある水準の品質の情報システムを作成できる。
• 部品を取り換えることにより保守・改訂ができる。

部品化のデメリット

反面、適切な管理をしないで部品化を進めると、かえって混乱が生じます。

• 多様な部品が整理されずに作られると、どのような部品があるのかわからない。
• 部品の存在を知っていても、その機能制約やインタフェースがあいまいなので使えない。
• 部品に欠陥があっても、それに気づかない。情報システムに欠陥があっても、部品が原因であることを突き止めるのはかえって困難である。
• このような理由により、部品を使う人と使わない人が混在して、情報システム全体の標準化ができない。

部品化推進の留意点

そのため、部品化を推進するには、多様な対処が必要になります。

• 共通に利用する正式な部品として作成し登録する制度。プログラマが勝手に作成したのでは、汎用性がなく、信頼性が低い部品が氾濫します。専門のグループが統一した思想や基準のもとで開発するとか、一般のプログラマなどからの提案や申請があったときは、専門グループがチェックや手直しを行って登録するなどの制度にします。
• 部品ライブラリなどの整備。部品利用の推進、利用の利便性向上のために、登録されている部品の検索、使い方、使用上の注意などが、プログラマの作業中に簡単にわかるような仕組みが必要です。
• 部品の標準化。利用者にわかりやすくするためには、部品の命名基準の統一、インタフェースの統一などを行うことが重要です。
• 部品の体系化。部品の粒度が大きいと生産性向上に効果がありますが、使い方が複雑になるとか、改訂が必要になるなどの欠点があります。また、同一システムの中でばらばらな粒度のものが混在していると、統一性のないシステムになります。ところが、大きい粒度のものが必要な場合もあるし、小さいほうが必要な場合もあります。そのため、体系化したライブラリが必要です。
• 市販部品の活用。ある目的だけのための機能のプログラムと比較して、汎用化した部品としたプログラムを作成するのは数倍の労力がかかります。情報システムでの「作るから買うへ」「所有から利用へ」の動向と同様に、市販の部品を利用することを考えるべきです。
• 長期的な推進体制。自作にせよ購入にせよ、部品化の効果を得るには再利用率を高めること、長期にわたって再利用することが必要です。部品化・再利用に関する成熟度を高めるマネジメントが求められます。