JP2012048329A - オブジェクト指向プログラム生成装置、その方法、プログラム - Google Patents

Abstract

【課題】設計ドキュメントからオブジェクト指向のプログラムコードを自動で生成するオブジェクト指向プログラム生成装置、その方法、プログラムを提供する。
【解決手段】エディタなどの入力装置によって開発対象システムのUMLモデル図を作成する各UMLモデル図作成部４１〜４４と、各UMLモデル図の情報５１〜５４を記憶するUMLモデル図記憶部９１と、前記UMLモデル図記憶部９１から前記UMLモデル図の情報を読み出し、UMLモデル図間の整合性をチェックするUMLモデル図判別部６０と、整合性に問題が無ければオブジェクト指向プログラムを自動で生成するプログラムコード生成部７０とを備える。
【選択図】図１

Description

本発明は、設計ドキュメントからオブジェクト指向のプログラムコードを自動で生成するオブジェクト指向プログラム生成装置、その方法、プログラムに関する。

オブジェクト指向をベースとするシステム開発において、分析・設計段階ではシステムの構造をソースコードよりも抽象化した形でモデリングする必要がある。モデリングとは、対象をある目的または観点から眺め、整理し表現することであり、このモデリングした結果作成されたものをモデルと呼ぶ。

モデリングの表記方法を統一化することにより、分析の明確化や適切な設計、情報の共有化・再利用を行うことがきる。
統一モデリング言語としてUML(Unified Modeling Language)が知られている。UMLは、業務及びソフトウェアを記述するための図式記法として、オブジェクト指向の標準化団体である米国のOMG（オブジェクト・マネジメント・グループ）で制定された規格である。既に、デファクトスタンダードとして世界で受け入れられており、国際規格（ISO/IEC 19501）としても制定されている。

また、UMLはグラフィカルな記述で抽象化したシステムのモデルを生成する汎用モデリング言語であり、その実施において、複数種類の図が用いられている。UMLで用いられる図(以降、UMLモデル図と表記する)は、開発対象システムの分析や設計を行う際に作成される。また、UMLモデル図は、システムの静的な構造をモデルで表現する構造図とシステムの振る舞いをモデルで表現する振る舞い図に大別される。

構造図としては、クラス図、オブジェクト図などがある。振る舞い図としては、ステートマシン図(ステートチャート図や状態遷移図とも表現される)、シーケンス図、などがある。

ところで、従来のオブジェクト指向プログラム開発においては、市販のUMLモデリングツールを用いて、UMLモデル図を作成し、作成したUMLモデル図からプログラムコードを自動で生成することで、ソフトウェアの生産性向上が図られてきた。

しかしながら、市販のUMLモデリングツールを用いて、自動生成できるUMLモデル図は構造図のみであり、振る舞い図からプログラムコードを自動生成することまではできていない。そのため、プログラム開発者は市販のUMLモデリングツールを用いて作成した振る舞い図を元に、手入力で振る舞い図に対応したプログラムコードを生成する必要があった。

また、特許文献１では、構造図だけではなく、振る舞い図であるステートマシン図(ステートチャート図)とアクティビティ図からプログラムコードを自動で生成するオブジェクト指向プログラムの自動生成装置を提供している。

特開２００２−１１６９１１号公報

しかしながら、特許文献１のオブジェクト指向プログラムの自動生成装置では、構造図と振る舞い図からプログラムコードを自動生成するものの、UMLモデル図間の整合性については何らチェックを行っていない。

従って、上述した自動生成装置を用いたシステム開発において、UMLモデル図から自動生成させたプログラムは、設計上の不具合を内在させたものとなる。また、プログラムの設計上の不具合はテスト工程にならないと発見できず、完了した設計工程に再び作業を戻して、UMLモデル図の不整合を修正することになり、開発作業の効率を低下させるという問題がある。

上記の課題を解決するために、本発明では、UMLモデル図(クラス図、オブジェクト図、ステートマシン図、シーケンス図)間の整合性をチェックし、整合性に問題が無い場合にのみプログラムコードを自動で生成する装置、方法、プログラムを提供することを目的とする。

上記課題を解決するために、本発明に係るオブジェクト指向プログラム生成装置は、開発対象システムの複数種類の設計ドキュメントを作成する設計ドキュメント作成部と、前記設計ドキュメント作成部により作成された設計ドキュメントの情報を記憶する設計ドキュメント記憶部と、前記設計ドキュメント記憶部から複数種類の前記設計ドキュメントの情報を各々読み出し、これら設計ドキュメント間の整合性をチェックする設計ドキュメント判別部と、前記設計ドキュメント判別部で整合性に問題が無いと判別されたときオブジェクト指向プログラムを生成するプログラムコード生成部とを備えることを特徴とする。

また、本発明に係るオブジェクト指向プログラム生成装置は、前記設計ドキュメントが、少なくともステートマシン図またはシーケンス図を含むUMLモデル図であることを特徴とする。

また、本発明に係るオブジェクト指向プログラム生成装置は、前記UMLモデル図が、クラス図、オブジェクト図を含み、前記設計ドキュメント判別部が、オブジェクト図に記載されている全てのオブジェクトがクラス図に記載されているクラスのインスタンスであるか否かの整合性、ステートマシン図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、ステートマシン図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、シーケンス図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、シーケンス図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、シーケンス図に記載されている全てのオブジェクトがオブジェクト図に記載されているオブジェクトであるか否かの整合性、または、シーケンス図に記載されている全ての状態がステートマシン図に記載されている状態であるか否かの整合性の少なくともいずれかの整合性のチェックをすることを特徴とする。

尚、ここでは、クラス図作成部、オブジェクト図作成部、ステートマシン図作成部、及び、シーケンス図作成部は別々の手段としているが、クラス図、オブジェクト図、ステートマシン図、及び、シーケンス図の全てを同一の環境で作成できる手段であってもよい。

また、ここでは、装置として表現されているが、方法、プログラムにより実現されるとしてもよい。

本発明によれば、オブジェクト指向プログラム開発において、開発者は設計ドキュメントであるUMLモデル図からプログラムが自動で生成されるので、プログラム作成作業が大幅に軽減され、また、本発明により、プログラムコードを自動で生成する前に、UMLモデル図間の整合性をチェックすることにより、ソフトウェアテスト時の不具合を未然に防ぐことができ、結果としてプログラムの作成作業が大幅に軽減され、オブジェクト指向プログラム開発のトータル作業工数を大幅に削減することができる。

本発明におけるオブジェクト指向プログラム生成装置の一例を示す図である。 クラス図の一例を示す図である。 オブジェクト図の一例を示す図である。 ステートマシン図(クラス名が”ClassA”であるクラス)の一例を示す図である。 ステートマシン図(クラス名が”ClassB”であるクラス)の一例を示す図である。 ステートマシン図(クラス名が”ClassC”であるクラス)の一例を示す図である。 シーケンス図の一例を示す図である。 UMLモデル図判別部にて、ＵＭＬモデル図の整合性に問題がないかどうかを判別する際の処理を示すフローチャート図である。 異常なオブジェクト図の一例を示す図である。 異常なオブジェクト図の一例を示す図である。 異常なステートマシン図(クラス名が”ClassA”であるクラス)の一例を示す図である。 異常なステートマシン図(クラス名が”ClassA”であるクラス)の一例を示す図である。 異常なシーケンス図の一例（異常パターン１）を示す図である。 異常なシーケンス図の一例（異常パターン２）を示す図である。 異常なシーケンス図の一例（異常パターン３）を示す図である。 異常なシーケンス図の一例（異常パターン４）を示す図である。 異常なシーケンス図の一例（異常パターン５）を示す図である。 本発明におけるオブジェクト指向プログラム生成装置によってクラス図とステートマシン図から作成されるプログラムコードの一例を示す図である。 本発明におけるオブジェクト指向プログラム生成装置によってオブジェクト図、ステートマシン図、及び、シーケンス図から作成されるプログラムコードの一例を示す図である。

以下、本発明の実施の形態について、詳細に説明する。
図１は、本発明におけるオブジェクト指向プログラム生成装置の一例を示す図である。
図１に示すように、オブジェクト指向プログラム生成装置は、エディタなどの入力装置によって開発対象システムのクラス構造を表現するクラス図を作成するクラス図作成部４１、エディタなどの入力装置によって開発対象システムのオブジェクト構造を表現するオブジェクト図を作成するオブジェクト図作成部４２、エディタなどの入力装置によって開発対象システムの各クラスにおける状態の変化を表現するステートマシン図を作成するステートマシン図作成部４３、エディタなどの入力装置によって開発対象システムのオブジェクト間のメッセージの流れを表現するシーケンス図を作成するシーケンス図作成部４４、上記で作成したUMLモデル図の情報(クラス図５１、オブジェクト図５２、ステートマシン図５３、シーケンス図５４)を記憶するUMLモデル図記憶部９１、UMLモデル図記憶部９１から、UMLモデル図の情報を読み出しUMLモデル図間の整合性をチェックし問題がないかどうかを判別するUMLモデル図判別部６０、及び、UMLモデル図間の整合性に問題がない場合に上記により作成されたUMLモデル図からプログラムコードを自動で生成するプログラムコード生成部７０、生成されたプログラムコード８０を記憶するプログラムコード記憶部９２とで構成されている。

また、図示はしていないが、オブジェクト指向プログラム生成装置の機能を実現するためにオブジェクト指向プログラム生成装置本体１０は、一般的なコンピュータのハードウェア資源として、例えば、ＣＰＵ、記憶装置、入出力装置、各種インターフェースなど、を周知の構成として備えており、また当然ながら、上記のごとき機能を実現させるためのプログラムを上記記憶装置内に格納している。UMLモデル図記憶部９１、プログラム記憶部９２は上述の記憶装置により実現され、また、上述の各種作成部（４１〜４４）、UMLモデル図判別部６０、プログラムコード生成部７０内の各構成は、上述のＣＰＵ、記憶装置、各種インターフェース等のハードウェア資源と後述する処理フローを実行する各種プログラムにより実現される。

さらに、オブジェクト指向プログラム生成装置は、キーボード、マウス、タッチパネル等のインターフェースを用いて実現される入力部２０と、液晶または有機EL等からなる表示パネルや音声出力用のスピーカー等を有し、各種情報を出力する出力部３０を備える。

また、入力部２０及び出力部３０は、オブジェクト指向プログラム生成装置本体１０のクライアント端末（図示せず）にその機能があってもよい。このときは、ネットワークを介してオブジェクト指向プログラム生成装置本体１０とクライアント端末が通信可能に接続されている。なお、ネットワークは、有線、無線を問わず既存の公衆網、ＬＡＮ、ＷＡＮなどを用いることができる。

図２は、本発明におけるクラス図の一例を示す図である。クラス図は、クラス図作成部４１を用いて作成される。
図２に示すように、各クラスは、クラス名、属性、及び、操作の区画から構成される。また、操作は、ステレオタイプなどを使用し、処理関数とイベントに分類される。

図２に示す例では、クラス名が”ClassA”であるクラスは、属性として、int型である変数”a”、及び、char型である変数”b”を持つ。また、処理関数として、返り値の型が”void”である処理関数”Ma1”、及び、”Ma2”を持つ。また、イベントとして、返り値の型が”void”であるイベント”Ea1”、”Ea2”、及び、”Ea3”を持つ。

さらに、クラス名が”ClassB”であるクラスは、属性を持っていない。また、処理関数として、返り値の型が”void”である処理関数”Mb1”を持つ。また、イベントとして、返り値の型が”void”であるイベント”Eb1”、及び、”Eb2”を持つ。

さらに、クラス名が”ClassC”であるクラスは、属性を持っていない。また、処理関数として、返り値の型が”void”である処理関数”Mc1”、”Mc3”、及び、”Mc4”を持つ。また、イベントとして、返り値の型が”void”であるイベント”Ec1”、”Ec2”、”Ec3”、及び、”Ec4”を持つ。

図３は、本発明におけるオブジェクト図の一例を示す図である。オブジェクト図は、オブジェクト図作成部４２を用いて作成される。
図３に示すように、各オブジェクトは、オブジェクト名、及び、クラス名によって表現される。

図３に示す例では、オブジェクト名が”objectA1”であるオブジェクトとオブジェクト名が”objectA2”であるオブジェクトは、クラス名が”ClassA”であるクラスのインスタンスであることを示している。

さらに、オブジェクト名が”objectB1”であるオブジェクトは、クラス名が”ClassB”であるクラスのインスタンスであることを示している。
さらに、オブジェクト名が”objectC1”であるオブジェクトは、クラス名が”ClassC”であるクラスのインスタンスであることを示している。

図４、図５、及び、図６は、本発明におけるステートマシン図の一例を示す図である。また、図４はクラス名が”ClassA”であるクラスのステートマシン図であり、図５はクラス名が”ClassB”であるクラスのステートマシン図であり、図６はクラス名が”ClassC”であるクラスのステートマシン図である。ステートマシン図は、ステートマシン図作成部４３を用いて作成される。

図４、図５、及び、図６に示すように、各ステートマシン図は、開始(図中に●で表示)、状態、及び、遷移を持つ。
図４に示す例では、状態として、”StateA1”、”StateA2”、及び、”StateA3”を持ち、初期状態(開始からの遷移で表現される)は”StateA1”である。また、遷移として、3つの遷移を持つ。

1つ目の遷移では、”StateA1”の状態でイベント”Ea1”を受け取ると、処理関数”Ma1”を実行し、”StateA2”へ状態を遷移する。
2つ目の遷移では、”StateA2”の状態でイベント”Ea2”を受け取ると、処理関数”Ma2”を実行し、”StateA3”へ状態を遷移する。

3つ目の遷移では、”StateA3”の状態でイベント”Ea3”を受け取ると、何も処理を実行することなく、”StateA1”へ状態を遷移する。
図５に示す例では、状態として、”StateB1”、及び、”StateB2”を持ち、初期状態は”StateB1”である。また、遷移として、2つの遷移を持つ。

1つ目の遷移では、”StateB1”の状態でイベント”Eb1”を受け取ると、処理関数”Mb1”を実行し、”StateB2”へ状態を遷移する。
2つ目の遷移では、”StateB2”の状態でイベント”Eb2”を受け取ると、処理関数”Mb1”を実行し、”StateB1”へ状態を遷移する。

図６に示す例では、状態として、”StateC1”、”StateC2”、”StateC3”、及び、”StateC4”を持ち、初期状態は”StateC1”である。また、遷移として、6つの遷移を持つ。
1つ目の遷移では、”StateC1”の状態でイベント”Ec1”を受け取ると、処理関数”Mc1”を実行し、”StateC2”へ状態を遷移する。

2つ目の遷移では、”StateC1”の状態でイベント”Ec3”を受け取ると、処理関数”Mc3”を実行し、”StateC4”へ状態を遷移する。
3つ目の遷移では、”StateC2”の状態でイベント”Ec2”を受け取ると、何も処理を実行することなく、”StateC3”へ状態を遷移する。

4つ目の遷移では、”StateC3”の状態でイベント”Ec3”を受け取ると、何も処理を実行することなく、”StateC4”へ状態を遷移する。
5つ目の遷移では、”StateC4”の状態でイベント”Ec1”を受け取ると、処理関数”Mc1”を実行し、”StateC2”へ状態を遷移する。

6つ目の遷移では、”StateC4”の状態でイベント”Ec4”を受け取ると、処理関数”Mc4”を実行し、状態は遷移しない。
図７は、本発明におけるシーケンス図の一例を示す図である。シーケンス図は、シーケンス図作成部４４を用いて作成される。

図７に示すように、シーケンス図は、メッセージ終了点(図中に●で表示)、ライフライン、及び、メッセージを持つ。また、各シーケンスは、メッセージ終了点からあるライフライン(以降、ライフライン1と表記する)に対してメッセージを送信し、そのメッセージを送信されたライフライン1からあるライフライン(以降、ライフライン2と表記する)に対してメッセージを送信するように表記される。

図７に示す例では、1つ目のシーケンスでは、オブジェクト名が”objectA1”であるオブジェクトが”StateA1”の状態でイベント”Ea1”を受け取ると、オブジェクト名が”objectB1”であるオブジェクトに対してイベント”Eb1”を送信し、オブジェクト名が”objectC1”であるオブジェクトに対してイベント”Ec1”を送信する。

2つ目のシーケンスでは、オブジェクト名が”objectA2”であるオブジェクトが”StateA1”の状態でイベント”Ea1”を受け取ると、オブジェクト名が”objectB1”であるオブジェクトに対してイベント”Eb1”を送信する。

3つ目のシーケンスでは、オブジェクト名が”objectA2”であるオブジェクトが”StateA2”の状態でイベント”Ea2”を受け取ると、オブジェクト名が”objectB1”であるオブジェクトに対してイベント”Eb2”を送信し、オブジェクト名が”objectC1”であるオブジェクトに対してイベント”Ec2”を送信する。

4つ目のシーケンスでは、オブジェクト名が”objectB1”であるオブジェクトが”StateB1”の状態でイベント”Eb2”を受け取ると、オブジェクト名が”objectA1”であるオブジェクトに対してイベント”Ea3”を送信し、オブジェクト名が”objectA2”であるオブジェクトに対してイベント”Ea3”を送信する。

5つ目のシーケンスでは、オブジェクト名が”objectC1”であるオブジェクトが処理関数”Mc1”を実行すると、オブジェクト名が”objectA1”であるオブジェクトに対してイベント”Ea2”を送信し、オブジェクト名が”objectA2”であるオブジェクトに対してイベント”Ea2”を送信し、オブジェクト名が”objectB1”であるオブジェクトに対してイベント”Eb1”を送信する。

図８は、UMLモデル図判別部６０にて、UMLモデル図間の整合性に問題がないかどうかを判別する際の処理を示すフローチャート図である。
UMLモデル図判別処理では、オブジェクト図とクラス図の関係に問題がないかどうかをチェックする(S801)。オブジェクト図とクラス図の関係に問題がある場合、異常で終了する。S801では、オブジェクト図に記載されている全てのオブジェクトがクラス図に記載されているクラスのインスタンスであるかどうかをチェックする。

ここでS801の詳細について図２、図３、図９、図１０を例に説明する。
例えば、図３に記載されている全てのオブジェクトは図２に記載されているクラスのインスタンスであるため、図３に示すオブジェクト図と図２に示すクラス図の関係には問題がないと判別し、処理を続行する。

また、図９に記載されているオブジェクト名が”objectX1”であるオブジェクトは、クラス名が”ClassX”であるクラスのインスタンスであり、クラス名が”ClassX”であるクラスは図２に記載されていないため、図９に示すオブジェクト図と図２に示すクラス図の関係には問題があると判別し、異常で終了する。

また、図１０に記載されているオブジェクト名が”objectX2”であるオブジェクトは、クラスのインスタンスではないため、図１０に示すオブジェクト図と図２に示すクラス図の関係には問題があると判別し、異常で終了する。

図８に戻って、続いて、ステートマシン図とクラス図の関係に問題がないかどうかをチェックする(S802)。ステートマシン図とクラス図の関係に問題がある場合、異常で終了する。S802では、ステートマシン図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるかどうかをチェックする。また、S802では、ステートマシン図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるかどうかをチェックする。

ここでS802の詳細について図２、図４、図５、図６、図１１、図１２を例に説明する。
例えば、図４、図５、及び、図６に記載されている全てのイベントは図２に記載されているクラスのイベントであり、図４、図５、及び、図６に記載されている全ての処理関数は図２に記載されているクラスの処理関数であるため、図４、図５、及び、図６に示すステートマシン図と図２に示すクラス図の関係には問題がないと判別し、処理を続行する。

また、図１１に記載されているステートマシン図は、クラス名が”ClassA”であるクラスのステートマシン図であるが、図１１において、状態”StateA1”から状態”StateA2”への遷移で使用されているイベント”Ex1”は図２に記載されているクラス名が”ClassA”であるクラスのイベントではないため、図１１に示すステートマシン図と図２に示すクラス図の関係には問題があると判別し、異常で終了する。

また、図１２に記載されているステートマシン図は、クラス名が”ClassA”であるクラスのステートマシン図であるが、図１２において、状態”StateA2”から状態”StateA3”への遷移で使用されている処理関数”Mx1”は図２に記載されているクラス名が”ClassA”であるクラスの処理関数ではないため、図１２に示すステートマシン図と図２に示すクラス図の関係には問題があると判別し、異常で終了する。

図８に戻って、続いて、シーケンス図とクラス図の関係に問題がないかどうかをチェックする(S803)。シーケンス図とクラス図の関係に問題がある場合、異常で終了する。S803では、シーケンス図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるかどうかをチェックする。また、S803では、シーケンス図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるかどうかをチェックする。

ここでS803の詳細について図２、図７、図１３、図１４、図１５を例に説明する。
例えば、図７に記載されている全てのイベントは図２に記載されているクラスのイベントであり、図７に記載されている全ての処理関数は図２に記載されているクラスの処理関数であるため、図７に示すシーケンス図と図２に示すクラス図の関係には問題がないと判別し、処理を続行する。

また、図１３に記載されているシーケンス図において、オブジェクト名が”objectA1”であるオブジェクトが”StateA1”の状態で受け取るイベント”Ex2”は図２に記載されているクラス名が”ClassA”であるクラスのイベントではないため、図１３に示すシーケンス図と図２に示すクラス図の関係には問題があると判別し、異常で終了する。

また、図１４に記載されているシーケンス図において、オブジェクト名が”objectA1”であるオブジェクトがオブジェクト名が”objectB1”であるオブジェクトに対して送信するイベント”Ex3”は図２に記載されているクラス名が”ClassB”であるクラスのイベントではないため、図１４に示すシーケンス図と図２に示すクラス図の関係には問題があると判別し、異常で終了する。

また、図１５に記載されているシーケンス図において、オブジェクト名が”objectC1”であるオブジェクトが処理を実行する処理関数”Mx2”は図２に記載されているクラス名が”ClassC”であるクラスの処理関数ではないため、図１５に示すシーケンス図と図２に示すクラス図の関係には問題があると判別し、異常で終了する。

図８に戻って、続いて、シーケンス図とオブジェクト図の関係に問題がないかどうかをチェックする(S804)。シーケンス図とオブジェクト図の関係に問題がある場合、異常で終了する。S804では、シーケンス図に記載されている全てのオブジェクトがオブジェクト図に記載されているオブジェクトであるかどうかをチェックする。

ここでS804の詳細について図３、図７、図１６を例に説明する。
例えば、図７に記載されている全てのオブジェクトは、図３に記載されているオブジェクトであるため、図７に示すシーケンス図と図３に示すオブジェクト図の関係には問題がないと判別し、処理を続行する。

また、図１６に記載されているシーケンス図において、オブジェクト名が”objectX3”であるオブジェクトは図３に記載されていないため、図１６に示すシーケンス図と図３に示すオブジェクト図の関係には問題があると判別し、異常で終了する。

図８に戻って、続いて、シーケンス図とステートマシン図の関係に問題がないかどうかをチェックする(S805)。シーケンス図とステートマシン図の関係に問題がある場合、異常で終了する。S805では、シーケンス図に記載されている全ての状態がステートマシン図に記載されている状態であるかどうかをチェックする。

ここでS805の詳細について図４、図５、図６、図７、図１７を例に説明する。
例えば、図７に記載されている全ての状態は図４、図５、及び、図６に記載されている状態であるため、図７に示すシーケンス図と図４、図５、及び、図６に示すステートマシン図の関係には問題がないと判別し、正常で終了する。

また、図１７に記載されているシーケンス図において、オブジェクト名が”objectA1”であるオブジェクトがイベント”Ea1”を受け取る状態”StateX1”は図４に記載されているクラス名が”ClassA”であるクラスの状態ではないため、図１７に示すシーケンス図と図４に示すステートマシン図の関係には問題があると判別し、異常で終了する。

以上により、UMLモデル図間の整合性をチェックし問題がないかどうかを判別する。なお、ここでは、UMLモデル図間の整合性のチェックの順番をオブジェクト図とクラス図、ステートマシン図とクラス図、シーケンス図とクラス図、シーケンス図とオブジェクト図、シーケンス図とステートマシン図のようにしているが、順番は任意であってもよい。また、作成しないUMLモデル図の種類がある場合は、その含まれるUMLモデル図間の整合性のチェックを飛ばして次のチェックを行ってもよい。

図１８は、本発明におけるクラス図とステートマシン図から作成されるプログラムコードの一例を示す図である。図１８に示すプログラムコードは、プログラムコード生成部７０を用いて自動で作成される。また、生成されたプログラムコード８０は、プログラム記憶部９２に記憶される。

図１８に示すプログラムコードは、クラス名が”ClassA”であるクラスのプログラムコードである。図１８において、４行目〜６行目、１４行目、及び、３１行目〜４１行目は図４に示すステートマシン図から作成され、２行目、９行目〜１１行目、１７行目〜１８行目、４５行目〜４７行目、及び、４９行目〜５１行目は図２に示すクラス図から作成される。

同様に、クラス名が”ClassB”であるクラス、及び、クラス名が”ClassC”であるクラスのプログラムコードもプログラムコード生成部７０を用いて自動で作成される。
図１９は、本発明におけるオブジェクト図、ステートマシン図、及び、シーケンス図から作成されるプログラムコードの一例を示す図である。プログラムコードは、プログラムコード生成部７０を用いて自動で作成される。また、生成されたプログラムコード８０は、プログラム記憶部９２に記憶される。

図１９は、処理の流れを表わしたプログラムコードである。図１９において、６行目〜９行目は図３に示すオブジェクト図から作成され、１９行目〜２６行目は図４に示すステートマシン図から作成され、３５行目〜６１行目は図７に示すシーケンス図から作成される。

なお、ここでは、プログラムコードをJava(登録商標)言語を用いて表記しているが、その他の言語(C言語、C++言語など)を用いて表記してもよい。
以上のように、本発明を適用することにより、オブジェクト指向プログラム開発において、クラス図、オブジェクト図、ステートマシン図、及び、シーケンス図を作成し、オブジェクト指向プログラム生成装置を使用することで、プログラムコードが自動で生成されるため、プログラム作成作業が大幅に軽減され、トータル作業工数を大幅に削減することが可能となった。

また、本発明を適用することにより、UMLモデル図間の整合性をチェックすることにより、ソフトウェアテスト時の不具合を未然に防ぐことができ、テスト作業を軽減することが可能となった。

さらに、特許文献１のオブジェクト指向プログラムの自動生成装置では、振る舞い図として、各クラスにおける状態の変化を表現するステートマシン図(ステートチャート図)とステートマシン図の一種であるアクティビティ図のみを対象としていたが、本実施例では、オブジェクト間のメッセージの流れを時間軸に沿って表現するシーケンス図についても対象としており、複数種類のUMLモデル図を使ったオブジェクト指向のシステム開発において、トータル作業工数を大幅に削減することが可能となった。

１０ オブジェクト指向プログラム生成装置本体
２０ 入力部
３０ 出力部
４１ クラス図作成部
４２ オブジェクト図作成部
４３ ステートマシン作成部
４４ シーケンス図作成部
５１ クラス図データ
５２ オブジェクト図データ
５３ ステートマシン図データ
５４ シーケンス図データ
６０ UMLモデル図判別部
７０ プログラムコード生成部
８０ プログラムコード
９１ UMLモデル図記憶部
９２ プログラム記憶部

Claims (7)

1. オブジェクト指向プログラムを生成するオブジェクト指向プログラム生成装置であって、
   開発対象システムの複数種類の設計ドキュメントを作成する設計ドキュメント作成部と、
   前記設計ドキュメント作成部により作成された設計ドキュメントの情報を記憶する設計ドキュメント記憶部と、
   前記設計ドキュメント記憶部から複数種類の前記設計ドキュメントの情報を各々読み出し、これら設計ドキュメント間の整合性をチェックする設計ドキュメント判別部と、
   前記設計ドキュメント判別部で整合性に問題が無いと判別されたときオブジェクト指向プログラムを生成するプログラムコード生成部と
   を備えることを特徴とするオブジェクト指向プログラム生成装置。
2. 請求項１記載のオブジェクト指向プログラム生成装置において、
   前記設計ドキュメントは、少なくともステートマシン図またはシーケンス図を含むUMLモデル図であることを特徴とするオブジェクト指向プログラム生成装置。
3. 請求項２記載のオブジェクト指向プログラム生成装置において、
   前記UMLモデル図は、クラス図、オブジェクト図を含み、
   前記設計ドキュメント判別部は、
   オブジェクト図に記載されている全てのオブジェクトがクラス図に記載されているクラスのインスタンスであるか否かの整合性、
   ステートマシン図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、ステートマシン図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、
   シーケンス図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、シーケンス図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、
   シーケンス図に記載されている全てのオブジェクトがオブジェクト図に記載されているオブジェクトであるか否かの整合性、
   または、シーケンス図に記載されている全ての状態がステートマシン図に記載されている状態であるか否かの整合性の少なくともいずれかの整合性のチェックをすることを特徴とするオブジェクト指向プログラム生成装置。
4. オブジェクト指向プログラムを自動的に生成するオブジェクト指向プログラムの生成方法であって、
   入力された開発対象システムにおける複数の設計ドキュメント間の整合性をチェックするステップと、
   チェックした結果、問題が無ければオブジェクト指向プログラムを自動生成するステップと
   を備えることを特徴とするオブジェクト指向プログラム生成方法。
5. 請求項４記載のオブジェクト指向プログラム生成方法において、
   前記複数の設計ドキュメント間の整合性をチェックするステップは、
   オブジェクト図に記載されている全てのオブジェクトがクラス図に記載されているクラスのインスタンスであるか否かの整合性、
   ステートマシン図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、ステートマシン図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、
   シーケンス図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、シーケンス図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、
   シーケンス図に記載されている全てのオブジェクトがオブジェクト図に記載されているオブジェクトであるか否かの整合性、
   または、シーケンス図に記載されている全ての状態がステートマシン図に記載されている状態であるか否かの整合性の少なくともいずれかの整合性のチェックをすることを特徴とするオブジェクト指向プログラム生成方法。
6. オブジェクト指向プログラムを自動的に生成するオブジェクト指向プログラム生成装置に、
   入力された開発対象システムの複数の設計ドキュメント間の整合性をチェックするステップと、
   チェックした結果、問題が無ければオブジェクト指向プログラムを自動生成するステップ、
   を実行させることを特徴とするオブジェクト指向プログラム生成プログラム。
7. 請求項６記載のオブジェクト指向プログラム生成プログラムにおいて、
   前記複数の設計ドキュメント間の整合性をチェックするステップは、
   オブジェクト図に記載されている全てのオブジェクトがクラス図に記載されているクラスのインスタンスであるか否かの整合性、
   ステートマシン図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、ステートマシン図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、
   シーケンス図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、シーケンス図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、
   シーケンス図に記載されている全てのオブジェクトがオブジェクト図に記載されているオブジェクトであるか否かの整合性、
   または、シーケンス図に記載されている全ての状態がステートマシン図に記載されている状態であるか否かの整合性の少なくともいずれかの整合性のチェックを実行させることを特徴とするオブジェクト指向プログラム生成プログラム。