【第３回】手続き型言語をオブジェクト指向言語に自動変換する？

1. 手続き型言語とは？

その名の通り、実行する命令や手続きを順番にプログラムに記述していく言語を指し、COBOL、PL/I、Fortran、C言語 などが該当します。
例えば、次の処理を行うプログラムは、そのまま上から順番に記述します。

1. 共通ファイルのデータを読み込む
2. 業務ファイルのデータ読み込み、共通データを基に業務データを編集する
3. 編集後の業務データを結果ファイルに出力する

構造化プログラミングが適用されていれば No.１～ No.３は別々のプログラムで処理され、データを引数として No.１から No.２を呼び出し、同じように No.２から No.３を呼び出します。各プログラムの中では、変数を定義して対象ファイルをオープンするなど、複数の手続きが処理順に記述されています。

COBOL の例）

このような処理順に記述されているプログラムを組み立て、システム全体を構築していきます。

2. 手続き型言語のメリット

手続き型言語を使用したプログラムには、以下のようなメリットがあります。

1. 仕様の理解が容易
   順番に処理が記述されているため、ソースコードを上から読んでいけば仕様書がなくとも処理内容が理解しやすい。
2. 学習難易度が低い
   業務処理を一定のルールに従って順番に記述していく、かつ別プログラムの呼び出しも明確に記述するため、複雑さが低く習得が容易である。特に COBOL は自然言語に近い構文により可読性が高く難易度が低い。
3. 開発時の分業化が容易
   処理の前後関係が明確で開発の分業が容易にできる。また、エラー発生時には処理別に検証ができ、問題の切り分けが比較的容易である。

シンプルがゆえに誰にとっても理解や習得が容易で、システム設計時も複雑さは高くありません。

3. オブジェクト指向言語とは？

オブジェクトとはモノや事柄を指し、このオブジェクトを単位としてプロパティやメソッドをクラス定義するもので、Java、PHP、C++ などが該当します。特徴的なのは、継承やポリモーフィズムなどの概念があることで、基底クラスを継承した派生クラスから、基底クラスのプロパティやメソッドを使用することができ、同じ名前のメソッドであっても引数や戻り値、データ型などの違いにより複数の実装ができます。手続き型言語と同じ例では、まず No.３の結果を得るためには何が必要かを考えます。

1. 共通ファイルのデータを読み込む
2. 業務ファイルのデータ読み込み、共通データを基に業務データを編集する
3. 編集後の業務データを結果ファイルに出力する

No.１を基底クラスとして、インスタンス生成時に共通データを取得し、派生クラスが参照できる変数に格納します。共通データは No.２のみが参照できるように No.１の派生クラスとして定義し、編集後の業務データを引き渡すメソッドを用意しておきます。No.３では No.２のインスタンスを生成し、そのメソッドを呼ぶなど、目的に合わせたプログラミングが可能です。

既にお気づきかもしれませんが、オブジェクト指向言語は結果となるオブジェクトを考慮しながら、関連するオブジェクトを効率よく生成するクラス設計が非常に重要になります。

4. オブジェクト指向言語のメリット

オブジェクト指向言語を使用したプログラムには、以下のようなメリットがあります。

1. 機能の独立性が高い
   システム全体を把握していなくとも、小さな単位でクローズした処理を記述できる。
2. 改修による影響範囲が少ない
   きちんとクラス設計されていれば、１つのクラスメソッドを修正するだけなど、仕様変更にともなう修正範囲を最小限に抑えることができる。
3. 再利用性が高い
   新しい処理が追加になった場合は、基底クラスから派生させたクラスを追加する、ポリモーフィズムを利用したメソッドを追加するなど、既にあるコードを有効に利用できる。

クラスの関連をすべて把握することは複雑で困難ですが、必要なときに必要なインスタンスを生成して処理できるなど、柔軟性に長けています。

5. それぞれの概念

手続き型言語とオブジェクト指向言語の概念は相反するものではなく、手続き型言語でもポインタや構造体を駆使し、処理単位を最小化すればオブジェクト指向言語の概念に近づけることはできます。また、オブジェクト指向言語でも１つのクラスメソッドにすべての処理を記述すれば、手続き型言語に近いコードを作成することはできます。

しかし、これでは各概念のメリットを享受することはできません。手続き型言語では処理が分散し、内容が理解しづらくなる程度ですが、オブジェクト指向言語では前述のすべてのメリットを得ることができなくなります。

手続き型言語は細部を組み立てて結果につなげる概念、オブジェクト指向言語は結果を求めるためにシステム全体を大きな括りで考える概念です。そのため、各概念の特長を活かしたシステム設計がメリットを最大限に活かせるのです。

6. ツールによる自動変換の落とし穴

手続き型言語からオブジェクト指向言語へ変換する際、一般的な自動変換ツールはマッピングテーブルを駆使してもプログラム単位にソースコードが変換されるため、システム全体を考慮した変換は行われないと考えて良いでしょう。それゆえ、処理内容が推測しにくい同じ名称のメソッドが複数のクラスに出現してしまう、本来分割するべき処理が手続き型言語と同じように１つのメソッドに順番に記述されてしまうことになります。

正当なクラス設計が行われた結果、インスタンスの生成タイミングや変数のスコープなど、オブジェクト指向言語のメリットがあるわけで、自動変換したプログラムは言語が変わっただけで概念は変わらぬままです。

また、プログラミング言語を変更することでデータ型や内部の演算方法が変わり、実行時非互換が発生する可能性や、メモリ領域管理の違いによりパフォーマンスが低下する恐れがあります。一部の機能ではなく、システム全体を変換する場合には、これが大きな差となって表面化する可能性があります。

手続き型言語の COBOL と オブジェクト指向言語の Java を例に採って代表的な例を挙げてみます。

1. １０進演算
   COBOL は事務処理用の言語として誕生した経緯から変数の桁数は厳密に定義し領域を確保することに対して、Javaでは固定値を与えない限り、値によって動的に桁数が変化します。
   COBOL の例）
   01 num1 PIC 9(2)V9(5) VALUE 10.1.
   01 num2 PIC 9(2)V9(5) VALUE 2.2.
   01 ans1 PIC 9(2)V9(5).
   COMPUTE ans1 = num1 * 2 / num2.
   ans1 の値は 09.18181 となり、小数点以下の桁数が定義通り確保されます。
   Java で１０進演算を実現するには BigDecimal クラスを使用して次のように記述します。
   Java の例）
   BigDecimal num1 = new BigDecimal(”10.10000”);
   BigDecimal num2 = new BigDecimal(”02.20000”);
   BigDecimal ans1 = (num1.multiply(new BigDecimal(“2.00000”)).divide(num2);
   確保する桁数は値で示すため、コーディングミスが発生しやすくなる懸念や、数学の数式とは異なる記述により若干読みづらくなります。
   また、Java は必要なときに必要なクラスを動的に生成できることがメリットですが、上記の例では１０進演算を呼び出すたびに BigDecimal クラスの生成と解放を繰り返します。一方、COBOL では静的に割り当てられたメモリを繰り返し使用します。
   １件のデータでは顕著にならない差でも、夜間バッチなどの大量データ処理を行う場合はパフォーマンスが劣化する恐れがあります。
2. 再定義
   COBOL では１つのメモリに割り当てられた変数を異なる変数に再定義することができます。
   COBOL の例）date1 を date2 に再定義する。
   01 date1 PIC X(08).
   01 date2 REDEFINES date1.
   　03 year PIC 9(04).
   　03 month PIC 9(02).
   　03 day PIC 9(02).
   この例では date1 と date2 は同じメモリ領域の値を指します。
   Java ではこのように値を共有する記述はできないため、自動変換で補いきれないものは独自の対策が必要になります。
3. データの転記
   COBOL では変数の集団項目を転記する場合は文字型として扱われるという決まりがあります。
   COBOL の例）
   01 grp1.
   　03 num1 PIC 9(06).
   　03 str1 PIC X(05).
   01 grp2 PIC X(11).
   01 num2 PIC 9(06).
   　① MOVE grp1 TO grp2.
   　集団項目である grp1 を grp2 へ転記する場合は文字列として転記ができます。
   　② MOVE num1 TO num2.
   　基本項目ある num1 は数値項目ですので、当然 num2 へ数値として転記されます。

   これを Java で表現するには複数の命令が必要になり、１回の命令では同じように転記はできません。
   このような変換前の言語特有の仕様を、変換ツールではどのように扱うのか注意が必要になります。

4. メモリ領域の確保と解放
   メモリの使い方は前項で少し触れましたが、例えば COBOL でファイルのレコードを繰り返し読む処理があったとします。
   COBOL の例）INDATA のデータを１件ずつ読み込む。
   READ INDATA AT END
   SET LOOP1 TO TRUE
   NOT AT END
   MOVE INREC TO PREC
   END-READ.
   COBOL はファイルや変数のメモリ領域を静的に確保し、同じ領域を繰り返し利用します。
   このソースコードを Java へ自動変換した結果、レコードの構造体を１つのクラスとして、読むたびにこのクラスを生成していたらどうでしょうか。当然、動的にメモリ領域を確保、開放するためにオーバーヘッドが発生し、以前よりも処理時間が長いという事態に陥ります。

ソースコードのメンテナンスについても、Java 技術者には馴染みのないコードが出力され、保守性も劣化する恐れがあります。たとえ変換後のクラス図があったとしても、そこから正しいクラス設計を行うには長い時間を要することになります。

ただし、手続き型言語のプログラムでもオブジェクト指向言語を意識した作りになっていれば、それほど困難さはないかもしれません。このためには手続き型言語の全プログラムを精査し、オブジェクト指向言語の変換に適しているか判断する、または事前にオブジェクト指向言語の概念に則した記述に変更するなどの対応が必要になります。

ご参考までに、プログラミング言語別のメリットについては連載コラムの「プログラミング言語の特性を活かした DX」で説明していますので、ぜひご一読ください。

7. おわりに

手続き型言語をオブジェクト指向言語へ安価で自動変換してくれる便利なツールが世の中にはたくさんありますが、変換後に「こんなはずではなかった」「ソースのメンテナンスが困難で頓挫した」という声もお聞きします。移行コストを無駄にしないためにも、それぞれの概念を理解し、どのようなリスクが発生するのかを事前に調査して計画することが大切です。

また、連載コラムの「プログラミング言語の特性を活かした DX」に記載していますが、各プログラミング言語には特長があり、オブジェクト指向言語へ変換したからといってすべてが良くなるとは限りません。
プレゼンテーション層では正当に設計されたオブジェクト指向言語を使用してユーザーの満足度を高めるが、計算精度を保持したいビジネスロジックは現状の手続き型言語を使用するなど、プログラミング言語を適材適所で利用することが、結果として低リスクで DX を成功に導くことになります。

マイクロフォーカスでは、COBOL、PL/I 言語、IBM メインフレームの JCL、CICS、IMS をオープン環境でも使用できる製品や、COBOL のビジネスロジックをそのまま使用した Web サービス、EJB 連携、マイクロサービスにも利用できるコンテナ型仮想化が実現できる製品をご提供しています。
新しいテクノロジとも連携が可能なマイクロフォーカスのモダナイゼーション支援製品が、DXの一助になれば幸いです。

COBOL, PL/I のモダナイゼーションに関するご相談は下記 URL からお気軽にお問合せください。
【 ご相談受付 】
https://www.amc.rocketsoftware.co.jp/mfproducts/amc_inquiry/
【 営業部へのお問い合わせ 】
https://www.amc.rocketsoftware.co.jp/about/contact/