【第2回】プログラムのモダナイゼーション

連載第2回目はアプリケーション・プログラムのモダナイゼーションについて考えます。アプリケーション・プログラムのモダナイゼーションというと、とかくプログラミング言語の選択をどうするかとか、最新のIT技術（例えばAIなど）をどう取り込むかといった話題になりがちですが、本稿では「モダナイゼーションとは、ITシステムをビジネス変化に迅速に対応できるように変革すること」という視点から、プログラムのモダナイゼーションに関するもっと根本的な問題について考えようと思います。

モノリシックなプログラムの問題点

昔から使われているIBM iのアプリケーション・プログラムは、必要なビジネスロジックや関連するI/O処理をすべて１つのプログラムの中に詰め込んだいわゆるモノリシック（一枚岩）なプログラムになっているはずです。なぜなら、IBM iで使用可能な古いプログラミング言語（OPM: Original Program Model）はモノリシックなプログラム構造を前提として設計されていたからです。 モノリシックなプログラムの問題は、ひと言で言えば「バグ修正や機能の変更／修正が難しく、時間とコストがかかる」点にあります。これは、本来は関連性の低いあるいは全く関係の無い多くの機能が、相互に干渉し合う可能性のある状態で1つのプログラム中に混在していることに起因しており、その抜本的解決にはプログラム構造の変革が必要です。 こうした問題を抱えるモノリシックなプログラムを変更や修正がしやすいものに変え、ビジネスの変化に素早く対応できるITシステムに転換することは企業の存続にとって重要な課題と言えます。 実はこの問題は古くから議論されてきており、既に1970年代半ばには複合設計という考え方がその問題解決策として提唱されています。複合設計における基本単位はモジュールと呼ばれる小さなプログラムです。モジュールは外部からは直接その内部にアクセスできない閉じたサブプログラムで、独立してコンパイル可能であり、プログラム内の他のどのモジュールからも呼び出すことができるという条件を満たしている必要があります。このような特性を持つモジュールを組み合わせてプログラムを作成するモジュラー設計により、プログラムの変更や機能追加が必要になった場合には、該当するモジュールだけを変更したり新たなモジュールを追加したりすることでこれに即応できるようになります。また、同じモジュールを他のプログラムで再利用することで、プログラム作成や保守の工数を削減することも期待できます。 図１．モジュラー設計の概念 図１の例で言えば、仕様変更によりモジュールFを修正する必要が出た場合には、モジュールFだけを修正することで対応が可能です。また、新しい機能が必要になった場合は新たにその機能を担うモジュールHを作成し、しかるべきモジュールからそれを呼び出すようにすることで変化に対応できます。 プログラムのモダナイゼーションを実現するには、プログラムをこのようなモジュラー構造に変える必要があり、そのためにはILE言語が必須です。これがプログラムのモダナイゼーションとILE言語がセットで語られる理由であり、ILE言語を使うだけでモダナイゼーションが実現できるわけではないことを理解しておく必要があります。 では、モダナイゼーションの根幹をなすモジュールの設計はどのように行えば良いのか、もう少し詳しく見てみましょう。まず、モジュールの設計で考慮するべきポイントとして、モジュール強度を高める、モジュール間の結合度を弱くする(疎結合化)、適切なモジュールサイズにするという3点が挙げられます。

モジュールの設計原則

1. モジュールの責務を決める

モジュール設計を考える際に重要なのは、モジュールの責務つまりそのモジュールがどのような機能を提供するかという1点に思考を集中することです。機能をどのように実装するのかとか、モジュールを使用する環境や条件といったいわゆるコンテクストもモジュール設計の初期段階では考慮しません。つまり、使用する言語、アルゴリズム、プラットフォームといったことはここでの関心事ではありません。 この段階で留意すべきことに単一責務の原則があります。これは、１つのモジュールが担う責務は1つにするという原則です。１つのモジュールに複数の責務を担わせると、その中の１つの責務に変更が生じた場合、そのモジュールの修正が必要になりますが、その際にその他の責務に影響を与えないよう慎重な作業が求められます。モジュールが担う責務が多ければ多いほど修正作業は難しいものになりますし、修正が必要になる可能性も高くなります。つまり、単一責務の原則を守らないと、変更に対して強度の低い脆弱なモジュールになってしまいます。換言すれば、単一責務の原則はモジュール強度の高い高凝集度のモジュールを設計するための原則であるとも言えます。

2. モジュール間の結合を疎結合に

あるモジュールを変更した影響が他のモジュールに波及し、そちらも修正をしなければならないような事態が発生するようでは、モジュール設計を行う意味がありません。つまり、そのようなモジュール設計は悪い設計ということになります。この問題はモジュール間のデータ共有のしかたに起因するもので、その良し悪しの判断基準として「結合度」と言う評価指標が与えられています。良いモジュール設計をするには、できるだけモジュール間の結合度を弱くして疎結合にする必要があります。そのためには、モジュールの呼び出しやモジュールからの戻り時に受け渡すべきデータをインターフェースで規定されたデータ項目、データ属性に則ったものに限定して、それ以外の方法で外部からモジュール内のデータにアクセスできないようにする、いわゆるカプセル化を行います。

3. 適切な大きさのモジュールにする

モジュールに関して考慮するべき点がもう１つあります。それは適切なモジュールサイズ（一般に「粒度」と言います）をどのように決定すれば良いかということです。モジュールは単一責務の原則に則って設計しているわけですから、見方を変えればこれは責務をどこまで細かい責務に分解するかという問題になります。 例えば、「受注処理をする」という責務を担うモジュールを考えてみましょう。このまま責務を1つのモジュールとして設計するとその粒度は1つのプログラムに相当する大きなものになり、モノリシックなプログラムと変わらない修正の難しいモジュールになってしまうことは容易に想像できると思います。そこでこの責務を、「受注データを受け取る」「受注データの妥当性を検査する」「在庫数を確認する」「受注データを作成する」「在庫を引き当てる」「受注確定を通知する」等々のより細かな責務に分解し、これらを組み合わせることで理解しやすく、作成も容易で、機能の追加や変更にも対応しやすいプログラムが作成できます。 問題は、この責務の分解をどこで止めるかですが、これに対する論理的な正解はありません。この件に関して、多くの研究者や実務家が様々な見解を述べていますが、容易に理解でき変更や修正の易しいモジュールの大きさは、あくまで目安ではありますが高水準言語で30～100ステップというのが大方の意見のようです。 責務の分解に関して留意しなければならないことがあります。それは、責務はビジネスプロセスの言葉で記述し、そこに技術的要素に左右される実装概念を持ち込まないということです。そうすることで、ビジネスオーナーにも理解しやすく、ビジネスプロセスの変化に対応しやすいモジュールができますし、過度に小さなモジュールができるのを防ぐこともできます。 ここまではモジュールの候補が見つかっていることを前提に、そこからどのような評価基準に基づいてモジュール設計を進めるかという話をしてきました。では、このモジュール候補はどのように見つけ出せば良いのでしょうか。目的とする処理を構成するモジュールを抽出する場合、モジュールの候補には漏れがないと同時に重複がないことが求められます。この要件を満たすモジュール候補を見つけるには、テンプレートとしてアプリケーション・アーキテクチャを参考にするのが役立ちます。

アプリケーション・アーキテクチャ

アプリケーション・アーキテクチャにはオブジェクトコードの再利用と修正・変更の影響を最小限に抑えるという2つの主要な目的があります。長年にわたり多種のアーキテクチャが提唱されてきましたが、ここではモジュール候補を抽出するための参照アーキテクチャとしてMVCモデルと3層アーキテクチャをご紹介します。

MVCモデル

MVCモデルは1970年代末にSmalltalk-80によるウィンドウプログラムの設計指針として生まれたアーキテクチャですが、GUIを持つアプリケーションの有効な設計手法であったことから、他言語でも広く使用されるアプリケーション・アーキテクチャとなり今日に至っています。 MVCモデルはその名の通り、プログラムの構造を大きくModel(M)、View(V)、Controller(C）の3つに分割して設計を行います。ここで、Modelはアプリケーションが扱うデータとその処理を行う役割（ビジネスロジック）を、ViewはModelで処理されたデータをUIに表示する役割を、ControllerはUIで発生したイベント（更新ボタンが押されたなど）と受け取ったデータを適切なModelに伝えて処理させる役割を担います。 図２.　MVCモデルの概念図 MVCモデルはGUIを持つプログラムを設計するためのアーキテクチャとして生まれたものですが、バッチプログラムのようにGUIを持たないプログラムでもControllerを入力、Viewを出力と捉えればMVCモデルを適用することもできます。 ここで1例として「受注処理プログラム」に必要な責務をMVCモデルに当てはめてモジュール候補の抽出を考えてみましょう。すると、Model、View、Controllerに該当するモジュール候補は、表１のようになります。 表１．「受注処理プログラム」のモジュール候補 3層アーキテクチャ 一般に階層アーキテクチャは、各階層の責務を明確にするとともに、下にある層のモジュールの変更をすぐ上の層で吸収することで変更の影響が更に上位の層に波及することを防ぐ目的で使用されるアーキテクチャです。古くは7階層モデルがOSや通信プログラムなどシステム系のプログラム設計で採用されてきた伝統的アーキテクチャです。 3層アーキテクチャはこの流れを汲むアーキテクチャで、対話型アプリケーション・プログラム開発で頻繁に使用されています。プレゼンテーション層、ビジネスロジック層、データベース層の3層で構成されることからこのように呼ばれています（ちなみに、各層の名称には様々なバリエーションがありますが、本質的な内容は一緒です）。 図３.　3層アーキテクチャの概念図 3層アーキテクチャを参考に、先ほどの「受注処理プログラム」に必要なモジュール候補の抽出を行うと各層にどのようなモジュール候補が見つかるかは演習問題として残しておきますので、各自で考えてみてください。

データ中心プログラミング

データ中心プログラミングは、いわゆるアーキテクチャとは違いますが、モジュールを抽出するための新たな考え方のヒントを与えてくれます。 伝統的なIBM iのプログラムはビジネスロジックが、データアクセスやユーザーインターフェースを制御する構造のプログラムロジック中心のプログラミングと言えます。これに対してデータ中心プログラミングは、DMBSの機能を最大限に活用することでビジネスロジックをアプリケーション・プログラムから分離し、DBMSに委ねるというアプローチです。この考え方はこれまでと違うモジュールの設計に繋がる可能性がありますが、この話題はデータベース機能と大きく関係するので、次回の「データベースのモダナイゼーション」で改めて詳しく説明します。

おわりに

今回の記事で、プログラムのモダナイゼーションにはOPM言語ではなくILE言語を使う必要があることと、単にOPM言語からILE言語に置き換えただけではあまり意味がなく、プログラムをモジュール構造に変える必要があることを理解していただけたと思います。 モジュールの組み合わせによってプログラムを作るモジュラー設計の考え方は、従来のモノリシックなプログラム作りと考え方が異なるため、習得にはある程度の学習時間と経験が必要です。しかし、これはモダナイゼーションの目標に到達するために必要なコストであり、投資に値する効果をもたらしてくれます。 本稿では、モダナイゼーションの本質に焦点を絞るために極力プログラミング言語に関する記述を避け、論理レベルでのモジュール設計論に話を限定しました。この記事を読んでILE RPGによるモジュラーコーディングについて具体的に勉強したいと思われた方は、以下の資料を参考にしてください。

「水平統合への第一歩：ILE環境を試してみよう」

iWorldの資料ダウンロードサイトにある「IBM i TECHセミナー2018秋」セミナー資料中のプレゼンテーション資料で、ILE RPGを簡潔かつ分かりやすく説明しています。

 「IBM iの”新“必須言語～FFRPG入門～」

iWorldの連載記事でFF RPGについてサンプルを使いながら丁寧な説明がされています。

A Pattern for Reusable RPG Code with ILE

英語の資料になりますが、MVCモデルに則り、既存の非ILE RPGプログラムをILE RPGでモジュラー構造に書き直す方法について解説されています。（但し、作成者であるKlement氏のモジュール抽出で使われている参照アーキテクチャはオーソドックスなMVCモデルではなく、彼流のアレンジが施されている点に注意してください。）