AWS Blu Age で移行したコードの保守性

このブログ記事では、コードの保守性を評価するための基準を概説し、AWS Blu Age がメインフレームアプリケーションを保守可能なオブジェクト指向の Java にどのように変換するか説明します。

AWS Blu Age を利用すると、お客様はメインフレームアプリケーションを Java Spring アプリケーションに変換できます。このトランスフォーメーションは、技術的な問題を解決するだけでなく、ビジネスのトランスフォーメーションも可能にします。新しく着任した開発者が、担当する Java アプリケーションに取り組むことができる状態になっていないと、モダナイゼーションの取り組みは行き詰まり、モダナイゼーション後の作業の大半がメンテナンスに集中したままになります。

COBOL から Java へのプログラム変換や同様のリファクタリングサービスを調査検討すると、JaBOL のような用語がよく出てきます。JaBOL という用語は COBOL の構造を模倣した Java コードを指し、多くの場合、移行元のコードのロジックが理解されないままの状態であることの表れです。AWS Blu Age は、モデルからモデルへの変換、再利用可能なクラス、非手続き型パターンによって JaBOL を回避するコードを生成し、よりクリーンでモダンで保守しやすい実装を実現しています。

可読性

コードは、明確な命名規則に従って、コードの目的やロジックの説明に関して意味のあるコメントを備えた、読みやすく理解しやすいものでなければなりません。プロジェクト全体で一貫したコーディングスタイルがあれば、開発者の認知負荷が軽減され、コードベースの操作が容易になります。

AWS Blu Age の Transformation Engine は、プロジェクト全体を通して一貫したコーディングスタイルに従い、読みやすくわかりやすいコードを生成します。

AWS Blu Age がモダナイズしたアプリケーションは Java Web アプリケーション (WAR) としてパッケージ化されており、どの Java EE サーバーにもデプロイできます。通常、サーバーは Spring Boot と Angular フレームワーク上に構築された AWS Blu Age ランタイムを組み込んだ Tomcat インスタンスです。

基本的な Java プロジェクトは、以下のように構成されます。

Entities プロジェクト — ビジネスモデルとコンテキスト要素が含まれています。プロジェクト名は通常「-entities」で終わります。これはレガシー COBOL プログラムの INPUT-OUTPUT SECTION (データセット) と DATA DIVISION のモダナイゼーションに相当します。一つのアプリケーションに複数の Entities プロジェクトを含むことができます。
Service プロジェクト — 従来のビジネスロジックのモダナイゼーション要素が含まれています。これは COBOL プログラムの PROCEDURE DIVISION に相当します。一つのアプリケーションに複数の Service プロジェクトを含むことができます。
Utility プロジェクト — 他のプロジェクトで使用される共通のツールやユーティリティが含まれています。
Web プロジェクト — UI があるアプリケーションの場合は、モダナイズされた UI 関連の要素が含まれます。これらの UI 要素は、CICS BMS マップ、IMS MFS コンポーネント、およびその他のメインフレーム UI ソースから取得されます。一つのアプリケーションに複数の Web プロジェクトを作成できます。

各構成要素のトランスフォーメーション前後の対応関係を捉えやすくするために、各 Java クラスは、対応する COBOL プログラムの名前を踏襲しています。リファクタリング中、AWS Blu Age の Transformation Engine は変数と関数にお客様固有の命名規則を適用します。各プロジェクトは Apache Maven をビルドの自動化とプロジェクト管理に活用し、一貫した構造と一元的な依存関係管理を実現しています。

モジュール性

個々のモジュール、クラス、および関数は、それぞれシステムの特定の側面を処理するよう、コードを構成する必要があります。このモジュール型のアプローチにより、システム全体に影響を与えずに個々のコンポーネントを更新でき、コンポーネントの再利用が可能になり、重複が減り、保守性が向上します。

AWS Blu Age は、COBOL のモノリシックな構造とは異なり、オブジェクト指向設計のベストプラクティスに従い、複数のレイヤーに編成されたコードを生成します。その構造は以下のようになります。

COBOL の DATA DIVISION は、複数のエンティティに変換されます (01/77 レベルの COBOL データ構造ごとに 1 つ)。コンテキストクラスが生成され、すべてのエンティティが COBOL の実行ユニットコンテキストの概念を再現する 1 つの Java オブジェクトにグループ化されます。プログラムの呼び出し時にコンテキストを復元する必要が生じた場合は、シリアライズ/逆シリアライズできます。
各プログラムには固有の Configuration クラスがあり、プログラムごとに動作をカスタマイズできます。たとえば、アプリケーション内で、あるプログラムは ASCII データを処理するよう設定し、別のプログラムは EBCDIC データを処理するよう設定することができます。
COBOL の PROCEDURE DIVISION は、Spring 等のモダンなアプリケーションで使用されている DI (Dependency Injection) フレームワークに則り、interface を実装する Service クラスに変換されます。COBOL のパラグラフは、標準的な Java のメソッドになります。
最後に、プログラムの名前を持つクラスが、上述の独立した各クラス間を繋ぎます。このクラスは run メソッドを公開しており、呼び出されると最新バージョンのプログラムが実行されます。

このアーキテクチャでは、同一のデータ構造が 1 つのクラスに統合されるので、コードの重複が減り、メンテナンスが容易になります。

複雑さ

コードの複雑さは、主に循環的複雑度とコードの重複によって測定されます。

循環的複雑度 — コード内の独立したパスの数を測定します。一般に、複雑度が低いということは、コードの理解、テスト、および保守に必要な労力が最小限であることを示します。複雑度が高いと、コードにバグが発生しやすくなり、変更が難しくなります。
コードの重複 — 繰り返されるコードは最小限に抑える必要があります。重複していると、変更を複数の場所に反映する必要があるため、メンテナンスの負担が増えます。重複したコードを関数やクラスにリファクタリングすると、保守性が向上します。

モダナイズされたコードは、レガシーシステムの複雑さをいくらか受け継いでいます。とはいえ、モダナイズされたコードの方が COBOL よりも読みやすく、クラスやオブジェクトおよびメソッド等の定義や参照先を辿り易くなっています。これは、メソッドのナビゲーション、インデント、構文がより明解になったことによるものです。たとえば、COBOL の END-IF やドットメカニズム (文の終端にピリオド「.」を書くこと) と比べると、if / else ステートメントには中括弧 { … } が使われます。

AWS Blu Age でリファクタリングしたコードは Java Spring の標準的なコーディングルールすべてに準拠しているため、どんな Java 開発者でもすぐにコードの中身に入って行き、詳しく調べることができます。

複数のレイヤーがあり、それぞれが特定のアーキテクチャレイヤーに焦点を当てている
標準の getter / setter を持つオブジェクト
interface と実装を分離する Spring のデザインパターン
Fluent API に支えられたフレームワーク
設定情報をプログラムから分離して設定ファイルに外出しすることで、必要なときに設定情報に素早くアクセスして変更することができる。たとえば、設定ファイルに外出しした SQL クエリや、YAML での設定など。

トランスフォーメーション中に、複雑な制御フローアルゴリズムを使用して、各プログラムの動作を把握します。AWS Blu Age ツールチェーンは、コード実行シミュレーションを使用して実行可能なパスを見つけ、モダンなコードで必要になるものだけを処理するようにしています。このプロセスのおかげで、COBOL の「GO TO」構文の動作を維持しつつ、COBOL パラグラフを Java メソッドに変換することで、移行元のプログラム構造を残しています。

進化可能性

コードは、最小限の労力で変更に対応できるように設計する必要があります。コンポーネント間は疎結合にする必要があります。つまり、システムのある部分の変更が他の部分に与える影響を最小限に抑える必要があります。

モダナイゼーション後に改修を実施することで、モダンな言語のすべての機能が利用できるようになり、モダンなアプリケーションですぐに有効化できるようになります。

使用されているエンティティ (COBOL データ構造に由来する) は JSON 互換であるため、Spring の機能とアノテーションを活用して、わずか数分で JSON ペイロードをもつモダンな HTTP エンドポイントとしてプログラムを公開できます。結果として、アプリケーションのソースコードを API ベースのソリューション、メッセージングシステム、その他の最新テクノロジーとシームレスに統合できます。

生成されるコードは一定の Java イディオムで構成され、どのコードも同じコーディングパターンに従います。以下は、簡単に実装できる一般的な変更の例です。

新しい特定の動作をアプリケーション全体に一律実装する必要がある場合: Spring が AspectJ で提供するアスペクト指向プログラミング (AOP) を使用して、アプリケーション全体に実装します。
データアクセスルーチンが、本番 (実データ) とテスト (スタブデータ) では異なる動作をする必要がある場合: 生成されたコードが Java の interface を使うので、テスト用の実装を作成し、プロファイル (本番/テスト) に基づいて異なる Bean を使うよう Spring を構成します。
無限ループプログラムを使って IBM MQ メッセージの取得と応答を行っている場合: メッセージ処理に Spring Integration を使用するようにコードをリファクタリングします。これによって、従来の順次処理に代わって、トラフィックに基づいてメッセージを並行して処理するスケーラブルなリスナーを実現します。
既存のバッチの実行時間を改善する必要がある場合: 既存のコードを Java Runnable に直接ラップし、Spring の TaskExecutor の概念と Java Future オブジェクトを使用した並列化を追加します。

AWS Blu Age で作成された Java コードは、モダンなコーディングのベストプラクティスに従った、標準的な Java コードです。これにより、他の標準的な Java プロジェクトと同様に、移行後のコードをさらに進化させて複雑さを軽減し、保守性を向上させることができます。

コードレビューと品質保証

SonarQube のような静的解析ツールは、エラー、セキュリティの脆弱性、コーディング標準からの逸脱を検出することにより、コードの品質と保守性を保証します。

AWS Blu Age は、コード品質を判定するための主な指標として、静的コード解析ツールである SonarQube を使用します。SonarQube はコードベースを実行せずにスキャンし、開発プロセスの早い段階でバグ、セキュリティの脆弱性、潜在的なパフォーマンス上の問題を特定します。バグ、テストカバレッジ、コードの複雑さなどの重要な指標にしきい値を設定することで、「品質ゲート」を通じて標準を適用します。

AWS Blu Age における SonarQube の主な機能:

コードの重複と保守性の問題に関する洞察を提供します
OWASP Top 10 などの標準を使用してセキュリティの脆弱性を検出します
不適切なプラクティスや設計を示す兆候となるようなコードを特定します
特定のプロジェクト要件に合わせてルールとしきい値をカスタマイズできます

AWS Blu Age でモダナイズされたコードは、お客様の SonarQube プロファイルを使用して解析しても確実に AAAA 評価を得られるようにし、業界標準を満たす高品質で保守しやすいコードになることを保証します。

ドキュメント化

保守に必要なドキュメントとして、次の 2 種類のものが考えられます。

インラインコメント — 複雑なロジック、アルゴリズム、または自明ではない決定を説明するコメントがコード内に必要不可欠です。コメントは、冗長だったり、自明なコードを説明したりするべきではありません。
外部ドキュメント — API リファレンス、アーキテクチャ図、使用ガイドなどの包括的なドキュメントは、新規開発者がシステムを理解し、効果的に貢献するのに役立ちます。

AWS Blu Age のトランスフォーメーションプロセスでは、元のプログラム内でロジックの説明に記述されているコメントをそのまま引き継ぎ、インラインコメントとしてコード内に残します。

JDK に含まれている Javadoc を使うと、他の開発者が追跡し理解できるような一貫したスタイルのドキュメントを作成できます。Web ベースの HTML ドキュメントを生成することで、開発者はコードベースのドキュメントを簡単に参照および検索できます。AWS Blu Age は、各機能を適切に文書化し、将来の開発やデバッグ作業で理解しやすくするため、コードの保守に役立ちます。

テスト容易性

単体テストで個々のコンポーネントを簡単にテストできるよう、コードを記述する必要があります。そのためには、多くの場合、疎結合で、明確なインターフェースを備えたコードを設計する必要があります。単体テスト、統合テスト、回帰テストを含む包括的なテスト自動化により、コードの変更によってバグが発生しないことが確認できると、メンテナンスが容易になります。

リファクタリングされたコードには、明確なインターフェースがあり、疎結合であるため、単体テストコードの生成が容易になります。JUnit、EvoSuite、JUnit-QuickCheck などのツールは、コードに基づいて単体テストケースを自動的に生成できます。また、JaCoCo などのツールを使用すると、テストの都度コードカバレッジを分析したり、追加のテストケースが必要な領域を特定したりできます。

AWS は、アプリケーションテストを大規模に記録、再生、比較するためのサービスである AWS Mainframe Modernization Application Testing を提供しています。これにより、アプリケーション機能のテスト再生、比較、検証のためのテストワークフローを高度に自動化して作成できます。

まとめ

AWS Blu Age はメインフレームアプリケーションの俊敏性を高め、メインフレームのモノリスからアジャイルなマクロサービスへ進化させることができます。すると、お客様はモダンな開発環境を採用できるようになり、生産性が向上し、ブロッカーを排除できます。開発とテストは、機能ごとに独立して柔軟に行えるようになります。その結果、市場投入までの時間が短縮され、変更にかかるコストが削減されます。レガシーテクノロジーに熟練した人材の退職に伴うリスクも軽減されます。AWS Blu Age によって移行したアプリケーションは、マイクロサービスの導入によってモダナイゼーションの次の段階に進むことができ、メインフレームアプリケーションに AI を活用し、AWS クラウドサービスと統合することができるようになります。

AWS Blu Age に関するその他の参考情報:

AWS Blu Age 認定: https://bluinsights.aws/certification/
ドキュメンテーション: https://bluinsights.aws/docs/transformation-center-create-a-project/
メインフレーム・モダナイゼーションのお客様事例とその他のソリューション

Amazon Web Services ブログ