JP2005515518A

JP2005515518A - レガシーソフトウエアアプリケーションを現代的オブジェクト指向型システムへ変換する方法及びシステム

Info

Publication number: JP2005515518A
Application number: JP2002589976A
Authority: JP
Inventors: デイビッドトンドロー，; ジョンマホーニー，
Original assignee: コンピュータアソシエイツシンク，インコーポレイテッド
Priority date: 2001-05-11
Filing date: 2002-05-10
Publication date: 2005-05-26
Also published as: ATE476702T1; CA2446162A1; EP1388054A1; ZA200308593B; US20030226132A1; IL158696A0; BR0209497A; WO2002093367A1; EP1388054B1; US7467375B2; AU2008201056A1; CN1509433A; KR20040004619A; DE60237200D1

Abstract

手順言語コードを有する手順プログラムをオブジェクト指向型プログラムへ変換するシステム及び方法であって、手順言語コードをスキャンし且つスキャンした手順言語コードに基づいてマップを作成し、スキャンした手順言語コードを中間コードとして格納し、該マップを使用して該手順言語コードの少なくとも１つのセグメントを処理し、該処理したセグメントを使用して第一データ構造を作成し、該第一データ構造に基づいて該中間コードを修正し、且つ該修正した中間コードに基づいてオブジェクトクラスを有するオブジェクト指向型プログラムを発生する、ことを包含している。

Description

本発明はコンピュータプログラムの変換に関するものである。より詳細には、本発明はレガシーソフトウエアアプリケーションを現代的オブジェクト指向型システムへ変換する方法及びシステムに関するものである。

ソフトウエアアプリケーションを１つのプログラミング言語から別のプログラミング言語へ変換する多くの技術及び方法が存在している。然しながら、１つのソフトウエアアプリケーションが書かれている言語はその組立の１つの側面に過ぎない。ソフトウエアアプリケーションは多くの部分を有する複雑なシステムである。

「コード」はプログラミング言語で書かれており且つ種々の条件下においてそのソフトウエアアプリケーションが何を行うかの命令を包含するソフトウエアアプリケーションの部分である。コンピュータの初期においては、ソフトウエアアプリケーションはアッセンブリ言語を使用して書かれていた。アセッブリ言語プログラムはアッセンブラーと呼ばれるアプリケーションによってマシン言語へ変換され、それがコンピュータの中央処理装置によって実行される。アッセンブリ言語操作は非常に低いレベルであり且つアプリケーションを書くことを困難なものとさせる場合がある。コンピュータ技術が進展するに従い、別の「より高いレベル」の言語が開発され、それはプログラマーが複雑なタスクを実行するソフトウエアをより容易に作成することを可能としたものである。コンパイラーと呼ばれる特別のソフトウエアアプリケーションが開発され、それはより高いレベルの言語をマシン言語へ還元させ、それによりコンピュータにより実行することが可能となるものである。ハイレベル言語は、必要に応じて、繰返し使用することを可能とするルーチン又は手順と呼ばれるコードのブロックへプログラマーがコードを編成することを可能とした。

ソフトウエアアプリケーションは、又、情報を管理することが可能であることが必要である。ソフトウエア開発ツールは、従って、データ構造を宣言する能力を提供する。データ構造は、コードによってデータを処理することが可能であるように、組織化し且つ識別可能な態様でメモリ内にデータを格納するための１つの態様を提供する。コードはデータ構造に関して動作を行う命令を包含しており且つルーチンと呼ばれるセグメントにグループ化される。初期のソフトウエア開発ツールにおいては、データ構造及びルーチンは別々に定義されていた。任意のルーチンがデータに関して捜査するために、データはパラメータとしてルーチンへパスされねばならなかった。ルーチンをコールし且つパラメータをパスするソフトウエアを書くアプローチは、通常、「手順プログラミング」と呼称される。より現代的なアプローチは「オブジェクト指向型」即ちＯＯモデルである。ＯＯモデルは手順モデルとは著しく異なるものである。

ＯＯモデルにおいて、データ構造及びコードルーチンは「クラス」と呼ばれる単一の独立したデータ構造内にグループ化させることが可能である。クラスはオブジェクトの特定の種類に属するデータ構造及びメッソドと呼ばれるルーチンのテンプレート定義である。クラスはメンバーオブジェクトの共通のプロパティ即ち特性を定義する。ＯＯプログラムはモジュール型で再使用可能なコード構造のために容易に作成し且つ修正することが可能である。

ＯＯプログラミングは、又、継承等の多くのその他の有益的な特性を可能とする。継承はその親クラス（即ち「スーパークラス」）として別のオブジェクトを特定することによりユーザが新たなオブジェクトを最初に作成することを可能とする。新たに作成されたオブジェクトはその親の能力の全てを直ちに獲得する。然しながら、ユーザは任意の条件下においてその新たなクラスの挙動をカスタム化することが可能である。

「ユーザインターフェース」は個人がソフトウエアアプリケーションと相互作用即ち対話することを可能とするアプリケーションの一部である。多くの場合において、ユーザインターフェースは「フォーム」を使用して作成される。フォームはディスプレイ上でユーザに対して提供される「フィールド」及び「トリム」の様相を特定する。フィールドは、ユーザがデータをエンターすることが可能な個別的な区域である。トリムはラベル等の固定情報であり、それは異なるフィールドに何をエンターさせるか又はそのアプリケーションにおける何等かのその他の目的を提供することをユーザに命令する。しばしば、これらのフォームはコードを使用して実現されるものではない。そうではなく、プログラマーが対話的にフォームを構築することを可能とするソフトウエア開発環境の一部である「フォームエディター」が存在している。フォームの定義はリポジトリー及び開発環境内に格納され且つアプリケーションが実行される場合にそのフォームの表示を与える。

１９７０年代及び１９８０年代のソフトウエア開発ツールは「キャラクタを基礎とした」ユーザインターフェースを使用していた。典型的に、このユーザインターフェースは２４本のラインとライン当たり８０個のキャラクタのフォームを表示することに制限されていた。これらのツールは、しばしば、アクティブなフォームと関連するコマンドを表示するためにターミナル上に２５番目のラインを使用していた。より現代的なツールは、グラフィカルユーザインターフェース（ＧＵＩ）を使用するフォームの実現を可能とさせる。ＧＵＩはより多数の及びより多様なユーザ制御でより複雑なフォームを実現することを可能とする。

一体的に、コード及びフォームはタスクを実施するために実行することが可能なアプリケーションを作成する。ユーザインターフェースを管理するプログラムの部分は「プレゼンテーション論理」と呼ばれる。これはユーザの入力をトラップし且つプログラムの動作をスタートさせ、ユーザに対して付加的な情報を促すか又はその他の態様でディスプレイを変化させるコードステートメントを包含している。このコードの残部は「ビジネス論理」と呼ばれる。ビジネス論理は、ワークフロー、データベースアクセス、トランズアクション及びユーザのコマンドの結果であるその他の動作を包含している。ビジネス論理及びプレゼンテーション論理に絡み合っていることが極めて一般的である。

データベース論理システム（ＤＢＭＳ）は、データベースからの情報を格納し、修正し且つ抽出することが可能なプログラムの集まりである。データベースからの情報に対する要求はクエリーの形態で行われ、それはスタイル化した質問である。クエリーを構成する１組の規則はクエリー言語として知られている。異なるＤＢＭＳは異なるクエリー言語をサポートするが、ＳＱＬ（構造型クエリー言語）と呼ばれる半標準化したクエリー言語が存在している。

データベース内に格納されている情報は多用なフォーマットで提供することが可能である。殆どのＤＢＭＳはレポートの形態でデータを出力することを可能とするレポートライタープログラムを包含している。このレポートライタープログラムは、レポート発生器とも呼称され、１つ又はそれ以上のファイルから情報を抽出し且つその情報を特定されたフォーマットで提供するデータベース管理システムの一部である。レポートライターはある条件に合致し且つ選択したフィールドを行及び列で表示するレコードの選択を可能とする。データは円グラフ、棒グラフ及びその他の線図にフォーマットさせることが可能である。レポートフォーマットが作成されると、そのフォーマット仕様はファイル内に保存し且つ将来のプレゼンテーションのために再使用することが可能である。

リレーショナルデータベース管理システム（ＲＤＢＭＳ）は、関連したテーブルの形態でデータを格納するデータベース管理システム（ＤＢＭＳ）の１つのタイプである。リレーショナルデータベースは、どのようにデータが関連しているか又はどのようにしてデータベースから抽出されるかに関しての２，３の仮定を必要とする場合がある。その結果、同一のデータベースは多数の異なる態様で見ることが可能である。リレーショナルデータベース管理システムにおいては、情報は、行及び列に配列されているデータを参照する例えばスプレッドシート等のテーブルの形態で格納される。リレーショナルシステムの１つの所望の特徴は、単一のデータベースを幾つかのテーブルにわたって拡布させることが可能であるという点である。

ソフトウエアアプリケーションは何等かの種類の「アーキテクチャ」を使用して実現される。アーキテクチャはアプリケーションの基本的なインフラストラクチャを記述する。アーキテクチャの１つの側面は関連するコンピュータの数に関するものである。単段ソフトウエアアプリケーションは、全てのアプリケーション及び／又はシステムが単一のコンピュータ上でランするものである。これはそのソフトウエアが他のソフトウエアアプリケーションに対して行うことを必要とする任意の外部的コールを包含している。例えば、ソフトウエアアプリケーションはデータを検索又はアップデートするためにデータベース管理システムを「コール」することが可能である。単段モデルにおいては、ソフトウエアアプリケーション及びデータベース管理システムの両方が単一のコンピュータ上でラン即ち稼動する。ユーザインターフェースは、フォームを表示し、ユーザが情報をエンターすることを可能とし、且つその入力を「ホスト」コンピュータへリターンすることが可能であるに過ぎない装置である「非プログラム式端末」上に表示させることが可能である。

クライエント／サーバーアプリケーション、即ち２段ソフトウエアアプリケーションは、ソフトウエアアプリケーションが１つのコンピュータ（クライエント）上でランし且つネットワーク接続を介して別のコンピュータ（サーバー）上でランするその他のソフトウエアアプリケーションに対して外部的コールを行うものである。

更により最近のアーキテクチャ革新はＮ段アプリケーションである。Ｎ段モデルにおいては、ソフトウエアアプリケーションの一部のみがクライエントワークステーション上でランされるに過ぎない。これは、通常、インテリジェントユーザインターフェース（即ちシンクライエント（ｔｈｉｎｃｌｉｅｎｔ））である。特定のタスクを実施することが必要である場合、クライエントは要求されたビジネス論理を包含する「アプリケーションサーバー」を探し出し且つその作業は、実際に、アプリケーションサーバーをランするコンピュータ上で実施される。アプリケーションサーバーは、このクライエントにより要求された処理を完成するために、データベースサーバー等の別のコンピュータへコンタクトすることが必要な場合がある。この一連のイベントが究極的に無制限の数のコンピュータを関与させる場合があり、そのモデルはＮ段モデルと呼ばれる。

今日多くの組織が直面する１つの問題は、キャラクタインターフェースを使用し、性質上手順的であり且つ単段モデルで実現されるソフトウエアアプリケーションを開発するために多大の費用及び時間を投資しているということである。これらのアプリケーションは「レガシー」アプリケーションと通常呼ばれる。これらのアプリケーションをサポートし且つ向上させることは主要なチャレンジである。何故ならば、開発者は最早それらが作成された技術を教えられるものでないからである。更に、インターネット及び電子通商の現在の世界は、グラフィカルユーザインターフェースを使用し、性質上オブジェクト指向型であり且つＮ段モデルを使用して実現されるシステムを必要とする。組織がその既存のレガシーアプリケーションをグラフィカルユーザインターフェースを使用する現代的なオブジェクト指向型Ｎ段アプリケーションへ変換することを可能とする技術は未だに作成されていない。その結果、その組織は現代的なツールを使用してそのアプリケーションを完全に再設計し且つ書き直すための時間がかかり且つ高価な処理を行わねばならない。

本発明に基づく方法及びシステムはこれら及びその他の問題を解決するものである。例えば、本発明に基づく方法及びシステムは、レガシーソフトウエアアプリケーションをＧＵＩに基づいたソフトウエアアプリケーションへ「変換」することが可能である。本発明によって意図されている変換は、システムの個々の側面の変換及び向上を包含している。単一処理において、レガシーソフトウエアアプリケーションのキャラクタを基礎としたユーザインターフェースはＧＵＩへ変換させることが可能であり、コード及びデータ構造は適宜形成されるオブジェクトクラスとして統合させ、再形態化し且つ再生され、且つレガシーソフトウエアアプリケーションをクライエント／サーバー又はＮ段システムのいずれかとして動作させることを可能とするための向上及び付加を行うことが可能である。

本発明は手順言語コードを有する手順プログラムをオブジェクト指向型プログラムへ変換する方法に関するものであり、手順言語コードをスキャンし且つスキャンした手順言語コードに基づいてマップを作成し、スキャンした手順言語コードを中間コードとして格納し、該マップを使用して該手順言語コードの少なくとも１つのセグメントを処理し、処理したセグメントを使用して第一データ構造を作成し、該第一データ構造に基づいて該中間コードを修正し、且つ該修正した中間コードに基づいてオブジェクトクラスを有するオブジェクト指向型プログラムを発生する、ことを包含している。本方法は、又、該手順言語コードの所定のセグメントが検知された場合に該手順言語コードの１つのセグメントを処理するステップを中止し、且つ該所定のセグメントに基づいてその他の中間コードを修正することを包含することが可能である。本方法は、又は、該手順言語に基づいて第二データ構造を作成することを包含することが可能であり、且つ該第二データ構造は該手順プログラミング言語の１つのステートメントのプロパティを識別するノードを有する階層的ツリーとすることが可能である。該第一データ構造を作成するステップは、該処理したセグメントに基づいて該第二データ構造内のノードを探し出し、該第二データ構造のノードをルートノードへトラバースし、且つ該トラバースしたノードの内容を該第一データ構造内に包含させることを包含することが可能である。

本発明は、又、手順言語コードを有する手順プログラムをオブジェクト指向型プログラムへ変換するコンピュータによって実行可能なコードを包含する格納媒体に関するものであって、手順言語コードをスキャンし且つスキャンした手順言語コードに基づいてマップを作成するコード、スキャンした手順言語を中間コードとして格納するコード、該マップを使用して該手順言語コードの少なくとも１つのセグメントを処理するコード、該処理したセグメントを使用して第一データ構造を作成するコード、該第一データ構造に基づいて該中間コードを修正するコード、該修正した中間コードに基づいてオブジェクトクラスを有するオブジェクト指向型プログラムを発生するコード、を有している。本格納媒体は、又、該手順言語コードの所定のセグメントが検知された場合に該手順言語のセグメントの処理を中止するコード、及び該所定のセグメントに基づいてその他の中間コードを修正するコードを包含することが可能である。本格納媒体は、又、該手順言語に基づいて第二データ構造を作成するコードを包含することが可能であり、且つ該第二データ構造は該手順プログラミング言語の１つのステートメントのプロパティを識別するノードを有する階層的ツリーとすることが可能である。該第一データ構造を作成するコードは、該処理したセグメントに基づいて該第二データ構造内の１つのノードを探し出すコード、該第二データ構造のノードをルートノードへトラバースするコード、及び該トラバースしたノードの内容を該第一データ構造内に包含させるコードを包含することが可能である。

本発明は、又、伝送媒体において実施化され且つ手順言語コードを有する手順プログラムをオブジェクト指向型プログラムへ変換させるコンピュータによって実行可能な命令を包含するコンピュータデータ信号に関するものであって、手順言語コードをスキャンし且つスキャンした手順言語コードに基づいてマップを作成するデータ信号部分、スキャンした手順言語コードを中間コードとして格納するデータ信号部分、該マップを使用して該手順言語コードの少なくとも１つのセグメントを処理するデータ信号部分、該処理したセグメントを使用して第一データ構造を作成するデータ信号部分、該第一データ構造に基づいて該中間コードを修正するデータ信号部分、及び該修正した中間コードに基づいてオブジェクトクラスを有するオブジェクト指向型プログラムを発生するデータ信号部分を包含している。本コンピュータデータ信号は、又、該手順言語コードの所定のセグメントが検知された場合に該手順言語コードの１つのセグメントの処理を中止するデータ信号部分、及び該所定のセグメントに基づいてその他の中間コードを修正するデータ信号部分を包含することが可能である。本コンピュータデータ信号は、又、該手順言語に基づいて第二データ構造を作成するデータ信号部分を包含することが可能であり、且つ該第二データ構造は、該手順プログラミング言語の１つのステートメントのプロパティを識別するノードを有する階層的ツリーとすることが可能である。第一データ構造を作成する該データ信号部分は、該処理したセグメントに基づいて該第二データ構造内のノードを探し出すデータ信号部分、ルートノードへ該第二データ構造のノードをトラバースするデータ信号部分、該トラバースしたノードの内容を該第一データ構造内に包含させるデータ信号部分を包含することが可能である。

本発明は、又、手順言語コードを有する手順プログラムをオブジェクト指向型プログラムへ変換する方法に関するものであって、手順言語コードをスキャンし且つスキャンした手順言語コードに基づいてマップを作成し、該マップ及び該スキャンした手順言語コードをリポジトリー内にメタデータとして格納し、各コンポーネントの変換した表現に対し新たな組のターゲットメタデータコンテナを作成し、該処理したセグメントを使用して第一アブストラクトシンタックスツリーを作成するために手順メタデータ表現を使用して該手順言語コードの少なくとも１つのセグメントを処理し、該第一アブストラクトシンタックスツリーに基づいて該ターゲットメタデータコンテナをポピュレートし、且つ該第一アブストラクトシンタックスツリーに基づいてオブジェクトクラスを有するオリジナルの手順プログラムのオブジェクト指向型メタデータ表現を発生させる、ことを包含している。本方法は、更に、該手順言語コードの所定のセグメントが検知された場合に該手順言語コードの１つのセグメントの処理するステップを中止し、且つ該所定のセグメントに基づいて別のアブストラクトシンタックスツリーを修正することを包含することが可能である。本方法は、更に、該手順言語に基づいて第二アブストラクトシンタックスツリーを作成することを包含することが可能であり、その場合に、該第二アブストラクトシンタックスツリーは、該手順プログラミング言語の１つのステートメントのプロパティを識別するノードを有するアブストラクトシンタックスツリーとすることが可能である。該第一アブストラクトシンタックスツリーを作成するステップは、該処理したセグメントに基づいて該第二アブストラクトシンタックスツリーにおけるノードを探し出し、ルートノードへ該第二アブストラクトシンタックスツリーのノードをトラバースし、且つ該トラバースしたノードの内容を該第一アブストラクトシンタックスツリー内に包含させる、ことを包含することが可能である。

図面に例示した本発明の好適実施例を説明する場合に、説明の便宜上特定の用語を使用する。然しながら、本発明はそのように選択された特定の用語に制限されることを意図したものではなく、各特定の用語は同様の態様で動作する全ての技術的な均等物を包含するものであることを理解すべきである。

図１は本発明の方法及びシステムを実現することが可能なコンピュータシステムの１例を示している。本発明のこのシステム及び方法は、例えば、メインフレーム、パソコン（ＰＣ）、ハンドヘルドコンピュータ、サーバー等のコンピュータシステム上で稼動するソフトウエアアプリケーションの形態で実現することが可能である。このソフトウエアアプリケーションは、例えば、フロッピィディスク、コンパクトディスク、ハードディスク等のコンピュータシステムにより局所的にアクセス可能な記録媒体上に格納することが可能であり、又はコンピュータシステムから遠隔地にあり且つ例えばローカルエリアネットワーク又はインターネット等のネットワークに対してのハードワイヤード又はワイヤレス接続を介してアクセスすることが可能である。

本コンピュータシステムは、通常、システム１００として呼称され、且つ中央処理装置（ＣＰＵ）１０２、例えばランダムアクセスメモリ（ＲＡＭ）等のメモリ１０４、プリンタインターフェース１０６、ディスプレイユニット１０８、ローカルエリアネットワーク（ＬＡＮ）データ伝送制御器１１０、ＬＡＮインターフェース１１２、ネットワーク制御器１１４、内部バス１１６、例えばキーボード、マウス等の１つ又はそれ以上の入力装置１１８を包含することが可能である。図示した如く、システム１００は、例えば、ハードディスク１２０等のデータ記録装置へリンク１２２を介して接続することが可能である。

本発明のシステム及び方法は、レガシーアプリケーションをグラフィカルユーザインターフェースを使用する現代的なオブジェクト指向型Ｎ段アプリケーションへ変換するための変換を実施する。このことは、レガシーアプリケーションプログラムコードを解析し、レガシーコードに基づいてクラス及びそれらのメッソドを作成すると共にレガシーコードに基づいてグラフィカルユーザインターフェースを作成する処理を包含することが可能である。ある条件下において、レガシーコードの幾つかのセグメントの変換は所望でない場合があり、その場合には、該処理はオリジナルのコードを転送する場合があり又は新たなコードを置換させる場合がある。

図２は本発明の１実施例に基づくプロセスチャートの１例を示している。１実施例においては、該変換は、マイニング（ｍｉｎｉｎｇ）プロセス１４０で開始し、該プロセスは、ディスカバリー１４２、アナリシス１４４、コンフィギュレーション１４６、ＧＵＩスタイルウィザード１４８、拡張ウィザード１５０、アプリケーションアナリシスレポート１５２、プリパレーション（準備）１５４、及びレガシーソフトウエアアプリケーションから必要とされる全ての資源を回収し且つそれらを変換のために準備させることが必要なその他のステップを包含することが可能である。メタフォーマットで格納されると、メタコンポーネントは変換プロセス１５６変換１−変換４１５８−１６４によって処理することが可能であり、その場合に、メタコンポーネントを処理し、再編成し且つ向上させることが可能である。この変換プロセス期間中に、レガシーメタコンポーネントはオブジェクトメタコンポーネントへ変換される。最後に、再生プロセス１６６期間中に、拡張ステップ１６８において、マイニングプロセス１４０からの結果に基づいてライブラリが構築され、且つ再生ステップ１７０において、オブジェクトメタコンポーネントは特定のオブジェクト指向型言語において実際のオブジェクトクラスとして実現される。

本発明の変換システムを上述した如く複数個のプロセスへ分離することは、本発明の幾つかの付加的な特徴を提供する。第一の特徴は、「任意の箇所から／任意の箇所へ」変換の作成である。何故ならば、メタコンポーネントの組立は変換システムによって定義することが可能だからである。例えば、特定のレガシーソフトウエアアプリケーションを変換させるために、レガシーコンポーネントをメタコンポーネントとしてリポジトリー内に格納することが可能なマイニングプロセス１４０を与えることが可能である。レガシー言語ソフトウエアアプリケーションを特定のオブジェクト言語へ変換させるために、変換プロセス１５６及びオブジェクトメタコンポーネントから所望のオブジェクト言語でオブジェクトクラスを作成することが可能な再生プロセス１６６も与えることが可能である。２番目の特徴は、変換の結果を変更することが所望される場合に、変換システムプロセスへ付加的な新たなステップを付加させることが可能であるということである。

例えば、特定の変換方法をカスタム化させるために、プロセスに対して「カスタム化」ステップを付加することが可能である。これらのカスタム化ステップは、変換システムにおけるその他のステップのうちの１つを実施する前又は後に、該コンポーネントのいずれか又は全てに対して変化を実施することが可能である。このようなカスタム化ステップは、コンポーネントに対して付加するか、それから削除するか、又はそれを変更するために使用することが可能である。例えば、１つ又はそれ以上のフォームから特定のフィールドを除去すること、対応するＧＵＩに対して異なるフィールド又はその他の資源（例えばアイコン）を付加し且つ次いで関連するオブジェクトコードに対して変更を行うことが所望される場合がある。このインフラストラクチャのために可能であるその他の多数の特徴が存在している。

本発明に基づく方法の別の側面は、レガシーソフトウエアアプリケーション内の任意のステップ又はプロセス及び任意のコンポーネントから再開始可能なものとさせることが可能であるということである。例えば、処理の任意の部分期間中に電源障害が発生すると、変換システム及び方法は、電源障害が発生した時に処理中であったステップ及びコンポーネントから再開始させることが可能である。この特徴を達成するために、選択したリポジトリーが永続的な格納施設（例えば、データベースリポジトリー）であることが望ましい場合がある。

マイニング、変換及び再生プロセスの例示的な実施例について以下に詳細に説明する。

マイングプロセス
マイニングプロセス１４０は変換に必要な資源を発見し、それらをリポジトリー内に格納し且つそれら及び変換に必要とされる任意のその他のメタコンポーネントを用意する。好適には、マイニングプロセス１４０は完全な変換を阻止するようなレガシーソフトウエアアプリケーションにおいて見つかった任意の欠陥を報告する能力を有している。これらの欠陥は、最も一般的には、ソースコード又はフォーム定義等の欠落コンポーネントである。マイニングプロセス１４０は、又、既知の変換が存在しないが又は変換システムが未だに処理すべくプログラムされていないいずれかである場合にレガシー開発環境の能力に遭遇する場合に使用することが可能な入力をオペレータに提供することが可能である。このことは、そのプロセスの残部を稼動する前に、変換システムにおける任意の欠陥を補正するか又は変換システムを向上させるためにオペレータに対して機会を与える。

以下のステップはマイニングプロセス１４０により実施することが可能なステップの例である。説明する各ステップは、特定の変換方法に対して使用可能である場合も使用可能でない場合もある。更に、各変換方法は、その処理により発生される出力を変更する１組のコンフィギュレーション値を与えることが可能である。例えば、特定のコンフィギュレーション値は特定のパターンに基づいて結果的に得られるコンポーネントの名称変更を行うことが可能である。各コンフィギュレーション値はオペレータにより変更することが可能なデフォルト設定を有することが可能である。

ディスカバリー
ディスカバーステップ１４２はレガシーソフトウエア開発環境に質問を発し且つ特定のアプリケーション内に包含されるコンポーネントのカタログを展開させる。ディスカバリーステップは、スキャンしたコンピュータ上に存在するオペレーティングシステムに従って、物理的メモリブロック及び仮想メモリページ等の適宜の論理メモリをスキャンすることが可能である。スキャンしたコンポーネントは、これらに制限されるものではないが、ソースコード、ホームページ、アプリケーション構造、任意の関連したデータベースのスキーマ、フォーム、フレーム、手順、レコード定義、グローバル変数、定数、ホストルーチン等を包含することが可能である。これらのコンポーネントは、好適にはリポジトリー内にメタコンポーネントとして格納される。更に、ソースコードコンポーネントの場合、ソースコードは「トークン化」又は基本的なプログラミング記号のストリームに分解することが可能である。これらのコンポーネントのコピーは「リポジトリー」内にメタコンポーネントとして格納され、そこで、それらは繰返し検索され、修正され且つ保存されることが可能である。このリポジトリーは、メモリキャッシュ、ファイルシステム、データベース又は任意のその他の適宜の情報格納設備とすることが可能である。

アナリシス
アナリシスステップ１４４において、メタコンポーネントの情報の全てを解析し且つ各コンポーネントに対して１つのマップが作成される。該マップは、各ルーチン及び１つのルーチン内のセクションがトークンシステム内においてどこで開始し且つ停止するかに関する情報を包含することが可能である。更に、各コンポーネントに関するメトリックを使用してアプリケーションアナリシスレポート１５２を作成することが可能である。

妥当性検査
妥当性検査フェーズ期間中、レガシーアプリケーションにおける全てのコンポーネントの相互参照が発生される。この相互参照は１つのコンポーネントにより参照される全てのコンポーネント（モジュール、データ源、フォーム等）のリストを与える。次いで、リポジトリーをチェックして、レガシー環境のコンポーネントの全てがリポジトリー内に格納されていることを確保する。いずれかのコンポーネントが欠落していることが判明すると、その欠陥に対処することを可能とすべくオペレータに通知がなされる。このプロセスは参照されないコンポーネントについて継続して行うことが可能であるが、それらを参照するコンポーネントは完全に変換されることはない。

コンフィギュレーション
コンフィギュレーションステップ１４６期間中に、アナリシスステップ１４４からの情報を使用して初期的なコンフィギュレーション即ち形態を確立する。このコンフィギュレーションは、レガシーアプリケーション自身を記述するメタコンポーネント内に格納される。このメタコンポーネントは変換プロセス１５６を制御する。これらのパラメータの幾つかは妥当性検査フェーズ期間中に修正することが可能である。

ＧＵＩスタイルウィザード
ＧＵＩスタイルウィザード１４８は、オペレータに、そのデフォルト仕様を変更することにより結果的に得られるグラフィカルユーザインターフェースをカスタム化させる能力を与える。このウィザードはカスタムメニューバーを作成し、ツールバー及びボタンバー定義が全てのグラフィカルフォームに対して適用されて結果的に得られるアプリケーションにおいて一貫性のある様相及び感じを与える。

拡張ウィザード
拡張ウィザード１５０は、オペレータに、そのアプリケーションに対する新たな基礎クラスライブラリー、ビジネスオブジェクトライブライー及びフロントエンドライブラリーを作成することを変換プロセス１５６に指示する機会を与える。これらの新たなオブジェクトライブラリーはレガシーソフトウエアアプリケーションにおいて見つかったスキーマ仕様に基づいて構築され且つ新たなアプリケーションにおいて新たな特徴及び関数を開発するのに必要な時間を著しく減少させることが可能である。このステップがランされない場合には、変換がこれらのライブラリを作成することはない。

アプリケーションアナリシスレポート
好適には、アプリケーションアナリシスレポート１５２は全体的なレガシーインフラストラクチャに関する包括的なレポートであり、且つ全ての資源及び各コンポーネントに関する詳細な情報及びメトリックの相互参照を包含している。それは、又、上述したような問題区域のリストを与えることが可能である。該メトリックは、レガシーアプリケーションにおけるコンポーネントの種類及び総数、ソースコードの全ライン数、各モジュールを構成するルーチンの数及び定義、アプリケーションにより提供される全てのコマンドのコンパイルを包含している。

プリパレーション
プリパレーション（準備）ステップ１５４期間中、変換に使用される全ての付加的なターゲットＯＯメタコンポーネントはリポジトリー内に作成される。そのメタコンポーネントが変換プロセスの前のラン即ち稼動からリポジトリー内に存在する場合には、それらは破壊され且つ新たなメタコンポーネントが作成される。

変換プロセス
変換プロセス１５６は、現在リポジトリー内に格納されているレガシーメタコンポーネントがそれにより処理されてオブジェクトメタコンポーネントを作成するメカニズムを提供する。変換プロセス１５６は変換を実施し、その場合に、全レガシーアプリケーションを多段並列処理で変換することが可能である。変換プロセス１５６において、任意の特定のソースステートメント（コードのインスタンス）、又はフォーム部分、又はレガシーソフトウエアアプリケーションのコンポーネントの任意のその他の部分は１つ又はそれ以上のコンポーネント（又は手順）を何らかの態様で修正させるルールを潜在的にトリガすることが可能である。例えば、「フレーム」の変換期間中（フレームは、ユーザインターフェースを必要とし且つ関連するフォームを有する手順である）、変換プロセス１５６は１つのパラメータを発見する場合がある。そのパラメータはそのフレームを置換すべく作成中のオブジェクトクラスの属性となる。そのフレームの処理が中止され、オブジェクトクラスがリポジトリーから検索され、該属性がオブジェクトクラスへ付加され、該オブジェクトクラスはリポジトリーへリターンされ且つ該ソースの処理が再開される。同様に、フレームのホームページの処理において、１つのフィールドが該フォーム上において遭遇すると、属性が同様の態様で同一のオブジェクトクラスへ付加される。条件に依存して１つのコンポーネント（又は手順）から別のコンポーネントへコードの全ブロックを移動させる場合がある多くのその他のより複雑なトランズアクションが該プロセス内に存在している。

上述した並列処理を容易とさせるために、レガシーソフトウエアアプリケーションと新たなアプリケーションの両方から及び中間アプリケーション（又は「メタアプリケーション」）からのコンポーネントの中間表現を管理する能力を有する一時的な格納設備が設けられるべきである。このメタアプリケーションは、任意の特定のソフトウエア開発環境の特定の実現例に対して結び付けられるものではなく、それはこれらの環境のうちのいずれかにおいて見出される構造を包含するものであるから便利である。「メタコンポーネント」を操作することにより、レガシーソフトウエアアプリケーションを新たなアプリケーションへ変換するプロセスは３つの別個のプロセス、マイニング、変換、再生に分割することが可能である。

変換プロセス１５６の１つの実施例について以下に４つの変換として説明する。

変換１
変換１エンジン１５８はレガシーソースコードを分解し且つそれを容易に処理することが可能な構造型フォーマットへ編成する責任を有している。コンポーネントに対するソースコードはガイドとしてアナリシスステップ期間中に作成されたマップを使用して分解される。各パラメータ及び変数定義及び各ソースステートメントが分解され、編成され且つ内部フォーマットに翻訳される。このことは多数の態様で達成することが可能である。１つの態様は、１つのコンポーネントに対するレガシーソースコードをプロパティツリーデータ構造ヘ分解することである。プロパティツリーは階層的構造であり、それはツリー内の任意のノードにおいて無制限の数の識別子又はプロパティの格納を提供する。この分解は幾つかのステップを使用して達成される。

第一ステップは、階層的プロパティツリーの形態におけるレガシープログラミング言語の文法表現を開発することである。変換の前に、図３にその１例を示してあるレガシープログラミング言語文法を作成し、それはレガシープログラミング言語の特性を表わす。レガシー言語がサポートする各異なるタイプのステートメントがレガシー言語において識別される（例えば、ＦＯＲ−ＥＮＤＦＯＲ、ＣＡＬＬ、ＰＲＯＭＰＴ等）。これらのステートメントは共通タイプのステートメントをグループ化することにより階層にグループ化される。例えば、ＦＯＲ−ＥＮＤＦＯＲ、及びＷＨＩＬＥ−ＥＮＤＷＨＩＬＥは「ループ制御」と考えられる。単一ルートノード２００がそのプロパティツリーに対して作成される。ルートノード２００において、プロパティが全てのステートメントに対して共通なツリーにおいて作成される。例えば、「行番号」は全てのステートメントに対して共通なプロパティである。ルートノードの下側において、分類ノード２０２が上のステートメントに対して開発された階層を表わすツリーにおいて作成される。各分類ノード２０２において、これらのステートメントに対して共通のプロパティが実現される。例えば、「ループカウンタ」は全てのループ制御の共通の属性となる場合がある。最後に、各特定のステートメントを表わす適宜の分類ノード２０２においてステートメントノード２０４が作成される。そのステートメントに対してユニークなそのノードに対してプロパティが作成される。この方法において、そのステートメントに対してユニークなデフォルト値、ステートメントタイプで少なくとも１つの共通のプロパティが各ステートメントノード２０４において定義されるべきである。

変換１１５８期間中、アブストラクトシンタックスツリーとして知られる別のタイプのツリーが各コンポーネントに対して展開される。アブストラクトシンタックスツリーは、完全に分解されたソースコードを包含すべく設計された階層的プロパティツリーの特別バージョンである。アブストラクトシンタックスツリーの１つの例を図４に示してある。ルートノード２５０が作成され且つプロパティがそのコンポーネントを全体として識別するルートノード２５０において定義される。ルーチンノード２５２がそのコンポーネント内に存在するコードの各ブロックに対して作成される。異なるタイプのコードブロックを保持する分類ノード（不図示）を、このことが再生プロセス１６６（本文書において後に説明する）に対して有益性を提供するものである場合に、作成することが可能である。各ルーチンノード２５２はそのルーチンを識別する定義されたパラメータを有している。セクションノード２５４，２５６，２５８はルーチンノード２５２の下側に作成され且つルーチンの異なるセクションを識別する。以下の３つのセクションタイプは典型的なものであり、即ちパラメータノード２５４、局所変数ノード２５６、ステートメントノード２５８である。

変換１１５８は、又、マイニングプロセス１４０のアナリシスステップ１４４期間中に作成されたマップを使用する。該マップは、各ルーチン及びルーチン内のセクションがトークンストリーム内のどこで開始し且つ停止するかに関する情報を包含している。コードのパラメータセクションに対する第一トークンにおいて開始し、変換１１５８は、それが完全な宣言ステートメントを見つけ出すまでトークンを処理する。次いで、それは宣言ノード２６０をパラメータセクションノード２５４へ付加する。そのノードにおいて、それはパラメータを定義し、該プロパティはパラメータとして宣言されている変数を完全に定義する。このことは局所的変数及びステートメントセクションに対して繰返される。変換１１５８がステートメントタイプを識別すると、それはそのステートメントを表わす図３に示したレガシー言語文法ツリー内のノードを探し出す。それは、ルートノードを含みルートノードまで任意の分類ノードのプロパティであるか又はステートメントを定義するプロパティの全てをコピーするツリーを上方へトラバースする。次いで、これらのプロパティはコンポーネントプロパティツリーのステートメントノードにおいて定義される。次いで、変換１１５８は該ステートメントを構文解析し且つ各プロパティのデフォルト値をそのステートメント内において見つけられた正確な値で置換させる。

更に、変換１１５８はステートメント間の関係を維持する。例えば、ＦＯＲステートメントの後で且つ対応するＥＮＤＦＯＲ前に見つけられたステートメントはＦＯＲステートメントノードの子ノードとして作成される。このネスティング（入れ子）は必要な深さだけ継続することが可能である。このような態様におけるノードのネスティングは、後に変換期間中に全体的なコードブロックを移動させることを容易なものとさせる。このプロセスが完了すると、レガシーソースコードの完全な編成されたバージョンが作成され且つそれについて動作することが可能である。ＸＭＬドキュメントとして表現されたアブストラクトシンタックスツリーの可視化サンプルを図６に示してある。

変換２
変換２エンジン１６０は、レガシーフォームを、再生期間中にグラフィカルインターフェースを作成するために使用することが可能なオブジェクトメタコンポーネントへ変換させる役務を司る。このことは、レガシーソースコードを変換１１５８で処理した態様と同様の態様で達成することが可能である。このプロセスは、２つの参照プロパティツリー、即ちグラフィカルインターフェースフォームテンプレートツリー、及びＯＯクラス階層ツリーを使用する。

グラフィカルインターフェースフォームテンプレートツリーは空のグラフィカルインターフェースフォームの表現を包含している。このフォームに対するルートノードはそのフォームの基本的特性の記述を包含している。プロパティツリーは３個のルートノードを有している。第一ルートノードは「ウインドウ」を記述するプロパティを包含している。ウインドウはグラフィカルユーザインターフェース上で情報を表示するための区域である。第二ルートノードはメニューバーに対するプレースフォルダを包含している。メニューバーは、ユーザが一連のコマンドから選択することを可能とするウインドウの上部に通常配置される特別の区域である。第三ルートノードはウインドウ自身の内容を記述する子ノードを包含している。より効率的なプロセスを作成するために、ウインドウ内容に対するデフォルトコンフィギュレーションはプロパティツリー内に供給されるべきである。ＯＯクラス階層ツリーはターゲットオブジェクト指向型ソフトウエア開発環境のクラス階層を記述する。このプロパティツリーはレガシー言語文法ツリーと実質的に同様に作成される。全てのＯＯモデルソフトウエア開発環境は「システム」又は構築クラス階層を有している。このクラス階層は開発環境を構成する基礎クラスオブジェクトを定義する。ＯＯクラス階層ツリーは、その階層における各クラスの各属性を記述するプロパティツリーを実現することにより作成される。

図５を参照すると、変換２１６０はレガシーフォームを表わすリポジトリーからメタコンポーネントを検索する（ステップＳ３５０）。新たなプロパティツリーが作成され、それはレガシーフォームに対するグラフィカルインターフェースフォーム置換を表わす（ステップＳ３５２）。このことは、最初に、グラフィカルインターフェースフォームテンプレートをコピーすることにより達成される。変換２１６０はネタコンポーネントをスキャンし（ステップＳ３５４）、且つ、スキャンしたコードが名前付きデータエントリフィールドでない場合には（Ｎｏ、ステップＳ３５６）、レガシーキャラクタフォームに関する各項目に対して（フィールド、トリム等）、変換２１６０は、グラフィカルフォーム上にどの置換オブジェクトを配置させるかを決定する（ステップＳ３５８）。この決定がなされると、本プロセスはＯＯクラス階層ツリー内のオブジェクトクラスをルックアップすることが可能であり且つルートノードに至るまでずっと該ツリーをトラバースし且つ途中でプロパティを回収することによりそのプロパティの全てを回収する（ステップＳ３６０）。次いで、フィールドノードがアブストラクトシンタックスツリーのフォームセクション内に作成され且つコピーしたプロパティが、そのノードにおいて定義されデフォルト値はレガシーフォームから読取られたものにより置換される（ステップＳ３６２）。レガシーフォームに関する全ての項目が処理されると、残存するものはグラフィカルインターフェースの完全なる記述である。

２つのその他のプロセスをグラフィカルインターフェースの作成期間中に実現させることが可能である。第一に、名前付きデータエントリフィールドがレガシーフォーム上で遭遇した場合に（Ｙｅｓ、ステップＳＳ３５６）、そのフォームの処理が中止され（ステップＳ３６４）、一方そのフォームと関連するソースコードを置換するオブジェクトクラスに対するメタコンポーネントが検索され且つ属性がそのフィールドの定義とマッチするオブジェクトへ付加される（ステップＳ３６６）。このことが行われる理由は、多くのレガシーソフトウエア開発環境において、フォーム上のフィールドはフォームのソースコードにおける暗示的に宣言された変数であるからである。ＯＯモデルにおいて、それらはそのオブジェクトの宣言された属性となる。第二に、レガシーフォームを処理した後に、該プロセスはそのフォームのソースコードに対して変換１１５８において作成されたアブストラクトシンタックスツリーをスキャンする。特に、該プロセスはレガシーソース内において見出されたユーザコマンドを探し出す。いずれかが見つけられると、幾つかのＧＵＩ制御（ボタン、ツールバーアイコン、又はメニューバーコマンド）のうちのいずれか１つをＧＵＩスタイルウィザードからの入力に基づいてグラフィカルユーザインターフェースプロパティツリー上に作成することが可能である。次いで、１つ又はそれ以上の「イベント」が該フォームに対する新たなコード論理を表わすアブストラクトシンタックスツリーへ付加される。これらの付加された「イベント」は新たなＧＵＩフォーム制御をレガシーアプリケーションにおけるメニューコマンドと関連する論理の変換した表現であるオブジェクトクラスにおいて発生されたメッソドと関連させる。

変換３
変換３１６２において、各レガシーソースコードコンポーネントに対するアブストラクトシンタックスツリーがリポジトリーから検索される。対応するオブジェクトメタコンポーネントも検索される。アブストラクトシンタックスツリーにおける全てのルーチンノードに対して、「メッソド」ノードがオブジェクトメタコンポーネント内に作成される。メッソドはオブジェクトに関し動作することが可能なオブジェクト内のソースコードである。変換３１６２は、最初に、該ルーチンの任意のパラメータを取り且つそれらを該メッソドのパラメータとして宣言する。

同じことが局所的変数について行われる。次いで、該ステートメントが処理される。各レガシーステートメントタイプに対して、変換３１６２はどのようにしてステートメントを変換し且つどこにそれを配置させるかを決定する。多くの場合において、該エンジンは全体的なルーチン又は１つのルーチンのサブセットを完全に異なるオブジェクトへ完全に移動させることを決定することが可能である。このことは、レガシーソフトウエア開発言語の特徴が新たなソフトウエア開発環境へ容易に翻訳されない場合に発生する。

変換３１６２の別の部分は、レガシーソフトウエアアプリケーションの手順コンテキストをオブジェクトコンテキストへ変換することである。このことは２つの側面を有している。第一に、手順環境において、１つのコンポーネントがそれを「コール」することにより別のコンポーネントを喚起させる。ＯＯモデルにおいて、手順をコールする代わりに、オブジェクトのインスタンス（即ちコピー）が作成され且つそのメッソドのうちの１つが喚起される。変換３１６２が何等かの種類のレガシーコールステートメントに遭遇すると、それは処理を中止し、コールされたオブジェクトを定義するオブジェクトメタコンポーネントを検索し、且つそのコールに対するパラメータの妥当性検査を行う。幾つかのインスタンスにおいて、該オブジェクトは調節を必要とする場合がある。従って、コールを行うコンポーネントにおいて、コールステートメントは幾つかの異なるステートメントと置換される。第一ステートメントはオブジェクトリクエストブローカー（ＯＲＢ）に対するものである。ＯＲＢは特別なオブジェクトであり、そのジョブは要求に基づいてその他のオブジェクトの作成を管理することである。付加された次のステートメントはオブジェクトの処理を「喚起」又は即ち開始させる全ての変換されたコンポーネントに対して共通の特別のメッソドに対するコールである。

手順からオブジェクトコンテキストへの変換の２番目の側面は手順ソフトウエア開発ツールとＯＯソフトウエア開発ツールとの間の文脈的差異である。ステートメントの処理期間中に、各トークンがチェックされて、そのクラスの属性に変換されたものに対する参照であるか否かを判別する。そうである場合には、適宜の変化がソースに対して行われ、従って適宜の変数が参照される。

変換４
変換４１６４はこの例示的実施例における変換である。それは残存することがあるが変換３１６２において実施される処理の全てに対して並列的に取扱われない場合のある多様な小さな問題のクリンナップを包含する。

再生プロセス
再生プロセス１６６はマイニングプロセス１４０の逆である。再生プロセス１６６期間中、変換プロセス１５６期間中に作成されたオブジェクトメタコンポーネントを使用して新たなソフトウエア開発環境内に配置される実際のオブジェクトクラスを作成する。更に、その新たなグラフィカルインターフェースフォーム及び任意のその他の必要なコンポーネントが作成され且つ新たなソフトウエア開発環境に配置される。

拡張
拡張ステップ１６８は、マイニングプロセス１４０を期間中にランされる拡張ウィザードにより特定されるように、新たな基礎クラスライブラリー、ビジネスオブジェクトライブラリー、フロントエンドコンポーネントライブラリーを構築する。

再生
再生ステップ１７０において、実際のオブジェクトクラス及びＧＵＩフォームがその中に包含される仕様に従ってオブジェクトメタコンポーネントから発生される。

多数の付加的な修正及び本開示の変形例が上述した説明に鑑み可能なものである。従って、特許請求の範囲内において、本発明を本明細書に特に記載したもの以外に実施することが可能であることを理解すべきである。

本発明の方法及びシステムを実現することが可能なコンピュータシステムの１例を示した概略図。本発明の１実施例に基づくプロセスチャートの１例を示した概略図。本発明の１実施例に基づくレガシー言語ステートメント文法ツリーの例示的フォーマットを示した概略図。本発明の１実施例に基づくアブストラクトシンタックスツリーの例示的フォーマットを示した概略図。本発明の１実施例に基づくプロセスのフローチャートを示した概略図。ＸＭＬドキュメントとして表現したアブストラクトシンタックスツリーのサンプル表現の一部を示した概略図。ＸＭＬドキュメントとして表現したアブストラクトシンタックスツリーのサンプル表現の一部を示した概略図。

Claims

手順言語コードを有する手順プログラムをオブジェクト指向型プログラムへ変換する方法において、
手順言語コードをスキャンし且つスキャンした手順言語コードに基づいてマップを作成し、
スキャンした手順言語コードを中間コードとして格納し、
前記マップを使用して前記手順言語コードの少なくとも１つのセグメントを処理し、
前記処理したセグメントを使用して第一データ構造を作成し、
前記第一データ構造に基づいて前記中間コードを修正し、
前記修正した中間コードに基づいてオブジェクトクラスを有するオブジェクト指向型プログラムを発生する、
ことを包含する方法。
請求項１において、更に、
前記手順言語コードの所定のセグメントが検知された場合に前記手順言語コードの１つのセグメントを処理するステップを中止し、
前記所定のセグメントに基づいてその他の中間コードを修正する、
ことを包含している方法。
請求項１において、更に、前記手順言語に基づいて第二データ構造を作成することを包含しており、前記第二データ構造が前記手順プログラミング言語の１つのステートメントのプロパティを識別するノードを具備する階層的ツリーである方法。
請求項３において、前記第一データ構造を作成するステップが、処理したセグメントに基づいて前記第二データ構造内の１つのノードを探し出し、前記第二データ構造のノードをルートノードへトラバースし、前記第一データ構造内のトラバースしたノードの内容を包含すること、を包含している方法。
手順言語コードを有する手順プログラムをオブジェクト指向型プログラムへ変換するコンピュータによって実行可能なコードを包含している格納媒体において、
手順言語コードをスキャンし且つスキャンした手順言語コードに基づいてマップを作成するコード、
スキャンした手順言語コードを中間コードとして格納するコード、
前記マップを使用して前記手順言語コードの少なくとも１つのセグメントを処理するコード、
前記処理したセグメントを使用して第一データ構造を作成するコード、
前記第一データ構造に基づいて前記中間コードを修正するコード、
前記修正した中間コードに基づいてオブジェクトクラスを有するオブジェクト指向型プログラムを発生するコード、
を包含している格納媒体。
請求項５において、更に、
前記手順言語コードの所定のセグメントが検知された場合に前記手順言語コードの１つのセグメントを処理することを中止するコード、
前記所定のセグメントに基づいてその他の中間コードを修正するコード、
を有している格納媒体。
請求項５において、更に、前記手順言語に基づいて第二データ構造を作成するコードを有しており、前記第二データ構造が前記手順プログラミング言語の１つのステートメントのプロパティを識別する１つのノードを有している階層的ツリーである格納媒体。
請求項７において、前記第一データ構造を作成するコードが、
前記処理したセグメントに基づいて前記第二データ構造内の１つのノードを見つけ出すためのコード、
前記第二データ構造のノードをルートノードへトラバースするためのコード、
前記第一データ構造内のトラバースしたノードの内容を包含するためのコード、
を包含している格納媒体。
伝送媒体において実施化され且つ手順言語コードを有する手順プログラムをオブジェクト指向型プログラムへ変換するコンピュータによって実行可能な命令を包含するコンピュータデータ信号において、
手順言語コードをスキャンし且つスキャンした手順言語コードに基づいてマップを作成するデータ信号部分、
スキャンした手順言語コードを中間コードとして格納するデータ信号部分、
前記マップを使用して前記手順言語コードの少なくとも１つのセグメントを処理するデータ信号部分、
前記処理したセグメントを使用して第一データ構造を作成するデータ信号部分、
前記第一データ構造に基づいて前記中間コードを修正するデータ信号部分、
前記修正した中間コードに基づいてオブジェクトクラスを有するオブジェクト指向型プログラムを発生するデータ信号部分、
を有しているコンピュータデータ信号。
請求項９において、更に、
前記手順言語コードの所定のセグメントが検知された場合に前記手順言語コードの１つのセグメントの処理を中止するデータ信号部分、
前記所定のセグメントに基づいてその他の中間コードを修正するデータ信号部分、
を有しているコンピュータデータ信号。
請求項９において、更に、前記手順言語に基づいて第二データ構造を作成するデータ信号を有しており、前記第二データ構造は前記手順プログラミング言語の１つのステートメントのプロパティを識別する１つのノードを有する階層的ツリーであるコンピュータデータ信号。
請求項１１において、前記第一データ構造を作成するデータ信号部分が前記処理したセグメントに基づいて第二データ構造内の１つのノードを探し出すデータ信号部分と、前記第二データ構造のノードをルートノードへトラバースするデータ信号部分と、前記第一データ構造内に前記トラバースしたノードの内容を包含させるデータ信号部分とを包含しているコンピュータデータ信号。
手順言語コードを有する手順プログラムをオブジェクト指向型プログラムへ変換する方法において、
手順言語コードをスキャンし且つスキャンした手順言語コードに基づいてマップを作成し、
前記マップ及びスキャンした手順言語コードをメタデータとしてリポジトリー内に格納し、
各コンポーネントの変換した表現に対し新たな組のターゲットメタデータコンテナを作成し、
手順メタデータ表現を使用して手順言語コードの少なくとも１つのセグメントを処理して前記処理したセグメントを使用して第一アブストラクトシンタックスツリーを作成し、
前記第一アブストラクトシンタックスツリーに基づいて前記ターゲットメタデータコンテナをポピュレートし、
前記第一アブストラクトシンタックスツリーに基づいてオブジェクトクラスを有するオリジナルの手順プログラムのオブジェクト指向型メタデータ表面を発生する、
ことを包含している方法。
請求項１３において、更に、
前記手順言語コードの所定のセグメントが検知された場合に前記手順言語コードの１つのセグメントを処理するステップを中止し、
前記所定のセグメントに基づいて別のアブストラクトシンタックスツリーを修正する、
ことを包含している方法。
請求項１３において、更に、前記手順言語に基づいて第二アブストラクトシンタックスツリーを作成することを包含しており、前記第二アブストラクトシンタックスツリーは手順プログラミング言語の１つのステートメントのプロパティを識別する１つのノードを有するアブストラクトシンタックスツリーとすることが可能である方法。
請求項１５において、前記第一アブストラクトシンタックスツリーを作成するステップが、前記処理したセグメントに基づいて第二アブストラクトシンタックスツリー内の１つのノードを探し出し、前記第二アブストラクトシンタックスツリーのノードをルートノードへトラバースし、且つ前記トラバースしたノードの内容を前記第一アブストラクトシンタックスツリー内に包含させることを包含している方法。