パート2：Altova UModelを用いたレガシーアプリケーションの分析

「レガシーアプリケーションの分析」シリーズの第1部では、当社のATMシミュレーションアプリを紹介し、JavaのソースコードをUModelプロジェクトにインポートし、クラス図を修正して、アプリケーションのクラスとその関係性の概要を把握しました。今回の記事では、当社のATMアプリの現在の機能を記述するためにユースケース図を作成し、将来の機能拡張を計画するために、あるユースケース図に情報を追加します。第1部でご覧いただいたように、ユーザーが当社のATMシミュレーションを実行すると、口座番号とPINコードを入力してログインし、その後、アプリケーションとのすべての利用可能なインタラクションをまとめたトランザクションメニューが表示されます

トランザクションメニューを参考にすることで、ATMシミュレーションにおけるユーザーの操作をまとめたユースケース図を作成できます

UMLの表記に慣れている方であれば、まず最初に気づくことの一つは、当社の図に描かれている「アクター」が、一般的なUMLで使われる棒人間とは異なっている点でしょう。UModelでは、ソフトウェアモデラーが、ユースケース図における「アクター」を表現するために、任意のWindowsの.bmp画像ファイルを指定することができます。今回は、UModelに付属しているライブラリから画像を選択し、その画像を「アクター」として割り当てるために、プロパティ設定ウィンドウを使用しました。

ユースケース図は、アプリケーションの処理フローやオブジェクト指向のクラスを定義する場所ではありません。あくまで、ユーザー（UML用語では「アクター」）がシステムとどのようにやり取りするかを記述するためのものです。各インタラクションの詳細をより明確に示すために、追加のユースケース図を作成することができます。各インタラクションを別の図で詳細に記述することで、図面がシンプルで分かりやすくなり、さまざまな選択肢を試すための十分なスペースが確保できます。

口座番号と暗証番号の認証は、ユースケース図の楕円ではなく、メモとして追加しました。これは、ATMを利用する人が、その認証処理を実行する主体ではないためです。実際のATMの利用経験から推測できます（まだコードを見ていないので）、引き出し金額が口座残高よりも大きい場合、引き出しはキャンセルされるでしょう。しかし、引き出し金額と口座残高の比較はユーザーが行う作業ではないため、その処理もユースケース図の楕円には含めていません。

「現金引き出し」ユースケース内の矢印は、ハイパーリンクを示しています。UModelでは、図内のあらゆる要素に1つ以上のハイパーリンクを付加できます。ハイパーリンクは、URL、外部ファイル、または別の図を参照することができます。さらに、ハイパーリンクの設定画面では、ハイパーリンクに表示する補助テキストを定義することも可能です。

もし複数のハイパーリンクを定義した場合、ヘルプテキストはポップアップ形式の選択メニューとして表示されます。例えば、既存のATMシミュレーションを修正し、毎回引き出しに対して手数料を課すというタスクが与えられたとします。引き出し金額が100ドル未満の場合、手数料は2ドルです。100ドル以上の場合、手数料は4ドルです。ATMには1ドル札が用意されていないため、手数料は現金引き出しから直接差し引くのではなく、口座から引き落とす必要があります。手数料は、現金が払い出される前に表示され、ユーザーは取引をキャンセルすることができます。この新しい要件を、ATM引き出しのユースケース図に追加することができます。

承認手数料に関するユースケースの楕円の配色を変更しました。これは、現在計画段階であり、まだ実装されていない機能であることを示すためです。一部の開発者は、承認手数料の楕円に付記されている注釈は冗長であると主張するかもしれません。なぜなら、"include"という表記自体が、承認手数料が「現金引き出し」の必須要素であることを示しているからです。しかし、多くの人が "include" と "extend" の違いについて混乱しているため、明確にすることが最善です。また、UModelのレイヤー機能を利用して、新しい機能に関連するすべての要素を別のレイヤーに配置することも可能です。

現在、レイヤーヘルパーウィンドウを使用することで、図面表示において、計画中の機能を表示したり、非表示にしたりすることができます。

実際のATMでの利用状況を分析した結果、既存のATMシミュレーションには一部の取引が欠落していることがわかりました。取引メニューには、口座間の資金移動を行うオプションが用意されていません。これまで作成した図面から、既存のアプリケーションの設計では、資金移動機能を実装することが困難であることがわかります。ユーザーのログインは口座番号に基づいており、既存のアプリケーションは、同一の銀行顧客が普通預金口座と貯蓄預金口座の両方を持っているという概念を理解していないようです。もし、マネージャーから資金移動機能の要望があった場合、当社の中核システムアーキテクトと協議する必要があります。ユーザーIDと複数の口座を紐付ける機能は、ATMシミュレーションアプリだけでなく、銀行のデータベースにも実装する必要があります。

Jolt賞を受賞した AltovaのMissionKit for Enterprise Architectsは、エンタープライズソフトウェアのアーキテクト向けに開発された、8つのXML、データベース、およびUMLツールを集めた製品です。この製品は、高度なXML、Webサービス、データ統合機能に加えて、UMLモデリングやデータベース管理ツールが必要となるユーザーに対応しています。

こちらをクリックして、フル機能の30日間試用版をダウンロードしてください。次回は、コードを詳しく見ていく前に、既存のATMシミュレーションを全く異なる視点から解説します。