グラフが開発を簡素化するケースとは?

# はじめに
この記事はNeelima Tadikonda氏の[Graphs simplify software development](https://blogs.oracle.com/database/post/graphs-simplify-software-development)の翻訳記事になります。この記事では下記のソフトウェア開発に役立つGraph技術の活用例を知ることができます。

- コンテキスト境界の自動認識
- クラスタ情報を活用したソフトウェアテストの簡易化
- アプリケーションのビジネスプロセス特定

-------------------------------------------------------

グラフは、ソフトウェアアプリを数週間単位ではなく、数時間単位で分析するなど、意外なところで活用されています。ソフトウェア開発は、常に進化し続ける複雑なプロセスです。どんなソフトウェアでも、市場に存在する期間が長ければ長いほど、そのメンテナンスはより複雑になります。Oracle Forms のような開発フレームワークは 40 年以上前から市場にあり、グローバル企業で長年にわたってミッションクリティカルなアプリケーションを構築するために使用されてきました。これらの企業は、今でも同じアプリケーション環境でコードを書いています。そこで、モノリシックなソフトウェアを分析し、複雑さを軽減する必要があるのです。オラクルのパートナーであるPITSS GMBHのStephan La Rocca氏は、グラフを使ってリンクしたソフトウェア・モジュールやクラスター化したモジュール、類似のパターンを見つけ出し、企業を支援する方法について講演しました。この記事は、彼のプレゼンテーションに触発され、Oracle Graphがレガシー・ソフトウェアの分析に役立ち、ソフトウェア開発を簡素化するソリューションを提供する方法について述べています

# モノリシック・アプリケーションの問題点とは？
-	階層の責任を区別しないため、個別のタスクとして維持することが困難である。データ管理、ビジネスロジック、ユーザーインターフェースが複雑に絡み合っていることが多い。
-	特定の機能を持つコンポーネントではなく、機能を1つのコードの塊にまとめている。そのため、セキュリティや通知機能、モバイルアプリ開発など、特定の機能のために新しい技術を取り入れることが面倒になる。モダンなソフトウェアフレームワークでは、これらの機能は独立したライブラリやフレームワークによって処理される
-	ビジネスの観点からは柔軟性に欠ける。これらのアプリケーションには、開発者が時間をかけて追加した機能が満載されており、新しいビジネスプロセスや改訂されたビジネスプロセスに適応させたりカスタマイズしたりすることは困難になる。これに対して、モダンなアプリケーション開発は、プロセスフローによってより推進されます。


# グラフ技術がモノリシックなアプリケーションを打開するために役立つこと
-  レガシーアプリケーションにおけるコンテキスト境界の識別
-  ソフトウェアのマニュアルテストのサポート
-  ビジネスプロセスの特定

# ユースケース1 グラフを利用したコンテキスト境界の自動認識
コンテキスト境界は、モノリシックなアプリケーションを、Webサービスのようなデプロイ可能な小さなアーティファクトに分解するためのプロセスです。これにより、さまざまなアプリケーション機能の開発とデプロイメントを互いに独立させることができます。
 例えば、以下の図では、「注文管理」コンテキストのソフトウェア開発とデプロイは、「支払い」コンテキストのそれとは完全に異なっています。しかし、これらの小さなデプロイ可能な成果物のユーザーインターフェース、ビジネスロジック、およびデータモデルは、別々ではない可能性があります。

レガシーアプリケーションのビジネスロジックは、ドメインの専門家に相談しないと詳細を理解することが難しい場合があります。しかし、異なるアプリケーションによって30～40年かけて収集された大量のシステムデータがあれば、ドメインやビジネスの知識がなくても依存関係を特定することが可能になります。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/706384/430d2594-8960-34ac-b706-c80d12da14c9.png)

以下は、異なるモジュールを持つレガシーアプリケーションのシステムフロー例です。モジュールはコンテキスト境界に基づいてクラスタ化されています。 各クラスタは、そのクラスタを管理する独自のコンテキスト境界を持っています。このシナリオでわかるように、'顧客' クラスタは他のクラスタデータを消費し、一方で他のクラスタによって消費される回数は少なくなっています。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/706384/5b153a04-9617-9fa1-0e1b-1fbe1b61e741.png)

## 伝統的手法で起こる問題点
伝統的に、複雑なアーキテクチャスキーマを構築する場合、業界やLoBの専門家が提供するドメイン知識が不可欠でした。これらの専門家は、特定のクラスタに機能を特定するためのクラスタ基準を提供します。既知のクラスタとともに、多数の未割り当てのオブジェクトが存在し、アーキテクチャスキーマの複雑さを増している可能性があります。

また、各クラスタは複数のモジュールを表し、複数の機能（認証、ボタン、ビジネスロジック、SQL文など）を持つアプリケーションの1画面や、複数の機能を持つアプリケーションの複数画面などが含まれる可能性があります。 画面ごとの機能数の合計が、画面の重み付け属性となります。つまり、重み付け属性が大きいほど、画面は複雑になります。したがって、クラスタとその境界のコンテキストは、次の2つの原則に従わなければなりません。

- 各クラスターは、その下の階層に同じウェイトを持つべきです。つまり、アプリケーションの様々なドメインに均等に機能が分散されている必要があります。
- コンテキスト境界を追加するための開発の必要性を回避するためこれらのクラスター間の相互作用は最小限であるべき。

# Oracle Graphは、どのようにコンテキスト境界で役立つのか
Oracle Graphには、アプリケーションの複雑性に応じてクラスタのアドバイスを行う60以上のアルゴリズムがあらかじめ組み込まれています。これにより、ドメインの知識がなくても境界のあるコンテキストを定義するのに役立ち、カスタムアルゴリズムと組み込みアルゴリズムの両方を実装することができます。Oracle Graphは、クラスターにコンテキスト境界を形成させる際に、理由、サブドメイン、境界の作成のために役立ちます。これは、コミュニティの検出に続いて、モジュールの重みを考慮し、クラスタの推奨を作成するアルゴリズムを使用することで可能となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/706384/9fb50e7f-add8-34c4-4527-336765e6a7a2.png)
モジュールの複雑さが増すにつれ、グラフのバブルのサイズも大きくなり、一方でノードとエッジは同じままになります。アルゴリズムはコンパイルされ、Oracle Property Graph Server に割り当てられ、それにより、新たな属性をコミュニティIDに付与して、プロパティの重みづけが行われます。

これらのアルゴリズムを実行すると、オブジェクトを可視化するために有効な新しいコミュニティIDが作成され、グラフアルゴリズムが関連するものとしてそれを選択し、クラスタリングします。これにより、ドメインの知識がなくても、これらのオブジェクトがどのように相互作用しているか、どのモジュールがこのクラスタに属しているかを確認することができます。上の図では、このようなグラフで選択されたクラスターが緑色でハイライトされているが、必要に応じて複数の粒度のクラスターを自分で作成することも可能です。

# ユースケース2 アプリケーションにおけるソフトウェアテストのサポート

リポジトリに全てのクラスタ情報があれば、テストの実行に役立つかもしれません。グラフ技術を利用することで下記のようなことが可能になります。

- ログイン画面から特定のPL/SQLユニットまでのユーザーの最短経路やクリックパスを簡単に記述する
- ユーザーテストの調整
- コードの網羅性を確保することが可能になり、経緯路上の条件を考慮

## Oracle Graphは、どのようにテストサポートの提供で役立つのか
大規模なアプリケーションのリリース変更では、多くの新機能が追加されることがよくあります。レガシーアプリケーションでは自動テストが困難なため、ユーザーを変更された機能へ誘導することが不可欠になります。バックエンドのOracle Graphアルゴリズムを使用すると、クリックパスを簡単に特定できます。このアルゴリズムは、モックアップ統合による視覚化を支援し、ユーザーにステップバイステップの指示を提供します。例えば、[次へ]ボタンを押すとスクリーンポップアップが出現して、[クレームを送信する]ボタンを押す等の動作です。

機能変更時には、Oracle GraphのFastest-Pathアルゴリズムを実装することで、ログイン画面から終了までの正確なクリックパスを把握することができます。

# ユースケース3 グラフを使用してアプリケーションのビジネスプロセスを特定する

レガシーアプリケーションでは、外部キーの関係がしばしばうまく定義されていないため、データモデルの分析が必要になります。データモデルを変更し、テーブル間に外部キーを割り当てることで、where句を持つユーザーインターフェース表の特定や、DML句を結合するテーブルを特定するのに役立ちます。したがって、ユーザーインターフェイスが2つのテーブルの間にマスター詳細関係宣言を作成する場所を特定できるようになります。 外部キーがなくても、テーブル間の関係を理解し、ビジネスプロセス情報を追跡するためにデータモデル内の重要なテーブルを特定することができます。

この情報は、アプリケーションを強化し、ユーザーの行動を追跡するのに役立ちます。Oracle Graphを使用すると、作成されたこれらの複雑な関係を視覚化して分析し、ビジネスプロセス、ユーザーとのインタラクション、およびこれらがアプリケーションを介してどのように実行されるかを特定することができます。

# Oracle Graphをアプリケーションに統合する利点
Oracle Graphは、ドメインの知識がなくてもモノリシック・アプリケーションを分析することができ、さまざまなコンテキストの依存関係を明確に分析することで、簡単にソリューションを検討することができます。また、グラフは、新規リリース時のユーザー・テストを改善し、変更されたフローにユーザーを直接誘導して簡単にテストできるようにし、ビジネス・プロセスを特定および可視化することも可能です。