Altova UModelを使ったレガシーアプリケーションの分析：パート1
いずれにしても、ほとんどのプロのエンジニアは、いずれ、自分が開発に関わっていない既存のアプリケーションのデバッグや機能追加の作業を任されることになるでしょう。 そのような状況下では、不正確または不十分なドキュメント、そして開発チームへのアクセス不足が、大きな障害となる可能性があります。 幸いなことに、Altova UModelは、既存のソフトウェアをリバースエンジニアリングすることで、分析を加速し、レガシーアプリケーションの理解を深めるための視覚的なモデルを作成することができます。 これは、Altova社のUModelを実際に活用する一連の投稿記事の最初です ソフトウェアモデリングのためのUMLツール そして、Javaで記述されたATM（自動現金預け払い機）のシミュレーションを分析し、その開発に取り組みます。 このアプリケーションは、人気のあるJavaのチュートリアルで紹介されている、いくつかのATM（現金自動預け払い機）のサンプルコードを基に作成されています。 このATMの操作はシンプルで、多くの人が慣れ親しんでいるため、ここでは具体的なコード例よりも、Java、C#、Visual Basicといったご自身のプロジェクトに適用できる技術に焦点を当てて説明します。 以下に、コマンドウィンドウ上で動作しているレガシーアプリケーションの画面を示します
開発元が都合よくサンプルアカウントの情報を提供してくれたため、ログインできました。その後、アプリケーションは一般的なATMの操作メニューが表示されます
アプリケーションが格納されているフォルダを調べると、Javaのソースファイルやコンパイル済みの.classファイルが見つかりますが、プロジェクトファイルは見当たりません。
それは問題ありません。UModelプロジェクトメニューを使用すると、プロジェクト全体、ソースコードが格納されているディレクトリ、あるいはコンパイルされたアプリケーションのバイナリファイルなどをインポートできます。非常に大規模なプロジェクトの場合、ソースコードは複数のフォルダに分かれていることが多いため、プロジェクトファイルがある場合でも、フォルダを一つずつ確認することをお勧めします。
始める前に、まず、ソースコードで定義されているクラス間の関連性を自動的に描画するように、UModelのオプションを設定しておく必要があります
フォルダをインポートする際に、ソースコードに含まれるJavaDocのコメントも、UModelプロジェクトのドキュメントとして含めるようにしましょう
今回、初めてこの既存システムを調査するにあたり、全体像を把握することが重要ですので、すべてのオプション機能は一旦利用しないようにします
UModelは、プロジェクトをわずか数秒でインポートし、エラーメッセージは表示されません。ダイアグラムツリーには、以下の2つのダイアグラムが含まれています
「モデルツリー」タブをクリックし、ソースフォルダを展開すると、UModelがインポートしたすべてのJavaクラスを表すアイコンが表示されます
次に、Diagram Treeに戻り、ソースコードUMLクラス図の内容を開きます。すべての線のスタイルを直交に設定し、いくつかの線やクラスの位置を調整して重なりを避けた後、図を見ると、アプリケーションのクラスとその関係が明確に示されていることがわかります
トランザクションクラスの名前はイタリック体で表示されており、これは抽象クラス（またはスーパークラス）であることを示しています。BalanceInquiry、Withdrawal、Depositといったサブクラスは、このクラスの機能を継承しています。トランザクションクラスを選択すると、UModelの階層構造ヘルパーウィンドウで継承関係が示され、また、クラス定義の直前にソースコードに記述されているJavaDocコメントが、ドキュメントウィンドウに表示されます
もし、レガシーアプリケーションをテキストエディタだけで分析する場合、上記の階層構造を理解するためには、すべてのソースコードファイルを一つずつ確認する必要があります。なぜなら、Transactionクラスは、内部的にそのサブクラスを識別していないからです。サブクラスを見つけても、その関連クラス（兄弟クラス）を特定することはできません。また、あるクラスがTransactionクラスのサブクラスではないと断定するには、すべてのクラスを調べてみなければなりません。
各クラスを選択して、ドキュメントウィンドウでそのドキュメントを確認することも可能です。あるいは、より見やすい図にしたい場合は、図から関連付けのラベルを削除することもできます
現在、バンクデータベース内のアカウント数の「ゼロ個から多数個」という多重性を表すアスタリスクが、以前よりもはっきりと認識できるようになりました。
弊社の開発チームの別のメンバーが、過去のプロジェクトを表現していると主張する一部のクラス図を発見し、それを共有してくれました。しかし、すぐにわかったのは、その図がUModelが生成した図とは全く異なっているということです
弊社の古いアプリケーションに関するドキュメントが、実際のコードと一致していないという事態が発生しています。これは残念ながらよくあることです。古い図と、今回作成した図の間には、いくつかの違いがあります
· The associations between ATM and the physical components are shown as composition associations
· The association between ATM and the BankDatabase is described by a text annotation
· The association between ATM and Transaction also has a text annotation, and it does not even exist in the UModel diagram
· Multiplicity is defined at each end of each association, but none were created by UModel
それでは、それぞれの点について検討していきましょう
· The representation of composition in the Java language is identical to ordinary association, so UModel could not deduce the composition characteristic. Of course the ATM “is composed of” a keypad, screen, cash dispenser, and deposit slot, so we can update the diagram to show composition.
· We can add a text annotation to any UModel association arrow. Simply click the arrow and start typing.
· If UModel did not create an association arrow between the ATM class and the Transaction, one must not be defined in the source code. We will postpone further investigation of this anomaly for now. · Multiplicity as shown in the legacy diagram would also require specific definition in the source code. We’ll leave this for investigation later too. Maybe that old diagram was left in the back of the file cabinet for a reason!
まず、注釈を追加し、次にUModelのプロパティウィンドウで、各ATM関連の集約特性を更新します。さらに、UModelのレイアウトツールバーを使用して、すべてのクラスを表す長方形を同じサイズに調整しましょう。これで、クラス図は次のようになります
完成したクラス図は、あくまで分析の出発点に過ぎません。次回の記事では、アプリケーションのコードをより詳細に分析し、さらに多くの情報を自動的に生成します UML図, そして、既存のコードに対する理解が深まるにつれて、独自の新しい図を作成していきます。
もし、すぐにJava、C#、またはVisual Basicで記述された既存のアプリケーションを解析し、再構築したい場合は、こちらをクリックして、機能フルバージョンで30日間無料で試用できる<2>Altova UModel</2>をダウンロードしてください