JP2013235508A - オブジェクト指向プログラム生成装置、その方法、プログラム - 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モデル図間の整合性をチェックすることにより、ソフトウェアテスト時の不具合を未然に防ぐことができ、結果としてプログラムの作成作業が大幅に軽減され、オブジェクト指向プログラム開発のトータル作業工数を大幅に削減することができる。

また、本発明によれば、プログラムコードを自動で生成する際に、配置図を用いてソフトウェア機能をどのハードウェア上に実装するかを表現することにより、分散環境下で動作するプログラムコードも自動で生成されるため、プログラム作成作業が大幅に軽減され、オブジェクト指向プログラム開発のトータル作業工数を大幅に削減することができる。

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

以下、本発明の実施の形態について、詳細に説明する。
＜オブジェクト指向プログラム生成装置の構成概要＞
図１は、本発明におけるオブジェクト指向プログラム生成装置の一例を示す図である。

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

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

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

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

図２に示すように、配置図は、ノード、及び、通信経路を持つ。また、ノードは、ステレオタイプを用いて、デバイス(ステレオタイプに<<device>>と表記)と実行環境(ステレオタイプに<<executionEnvironment>>と表記)に区別される。本発明では、デバイスをハードウェア、実行環境をソフトウェア機能として表現する。

図２に示す例では、ハードウェア名が”HardwareA”であるハードウェアには、ソフトウェア機能として、クラス名が”ClassA”であるクラスのソフトウェア機能、及び、クラス名が”ClassB”であるクラスのソフトウェア機能が実装される。

さらに、ハードウェア名が”HardwareB”であるハードウェアには、ソフトウェア機能として、クラス名が”ClassC”であるクラスのソフトウェア機能が実装される。
また、ハードウェア名が”HardwareA”であるハードウェアとハードウェア名が”HardwareB”であるハードウェアは通信経路を持つ。
＜クラス図＞
図３は、本発明におけるクラス図の一例を示す図である。また、クラス図は、クラス図作成部４２を用いて作成される。

図３に示すように、各クラスは、クラス名、属性、及び、操作の区画から構成される。また、操作は、ステレオタイプなどを使用し、処理関数とイベントに分類される。
図３に示す例では、クラス名が”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”を持つ。
＜ステートマシン図＞
図４、図５、及び、図６は、本発明におけるステートマシン図の一例を示す図である。また、図４はクラス名が”ClassA”であるクラスのステートマシン図であり、図５はクラス名が”ClassB”であるクラスのステートマシン図であり、図６はクラス名が”ClassC”であるクラスのステートマシン図である。ステートマシン図は、ステートマシン図作成部４３を用いて作成される。

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

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

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

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

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

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

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

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

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

図７に示す例では、１つ目のシーケンスでは、クラス名が”ClassA”であるクラスが”StateA1”の状態でイベント”Ea1”を受け取ると、クラス名が”ClassB”であるクラスに対してイベント”Eb1”を送信し、クラス名が”ClassC”であるクラスに対してイベント”Ec1”を送信する。

２つ目のシーケンスでは、クラス名が”ClassA”であるクラスが”StateA2”の状態でイベント”Ea2”を受け取ると、クラス名が”ClassB”であるクラスに対してイベント”Eb2”を送信する。

３つ目のシーケンスでは、クラス名が”ClassB”であるクラスが”StateB1”の状態でイベント”Eb2”を受け取ると、クラス名が”ClassA”であるクラスに対してイベント”Ea3”を送信する。

４つ目のシーケンスでは、クラス名が”ClassC”であるクラスが処理関数”Mc1”を実行すると、クラス名が”ClassA”であるクラスに対してイベント”Ea2”を送信し、クラス名が”ClassB”であるクラスに対してイベント”Eb1”を送信する。
＜UMLモデル図判別＞
図８は、UMLモデル図判別部６０にて、UMLモデル図間の整合性に問題がないかどうかを判別する際の処理を示すフローチャート図である。

UMLモデル図判別処理では、配置図とクラス図の関係に問題がないかどうかをチェックする(S801)。配置図とクラス図の関係に問題がある場合、異常で終了する(S801：NO)。S801では、配置図に記載されている全てのクラスがクラス図に記載されているクラスであるかどうかをチェックする。

ここでS801の詳細について図２、図３、図９を例に説明する。
例えば、図２に記載されている全てのクラスは図３に記載されているクラスであるため、図２に示す配置図と図３に示すクラス図の関係には問題がないと判別し、処理を続行する(S801：YES)。

また、図９に記載されている配置図において、クラス名が”ClassX”であるクラスは図３に記載されていないため、図９に示す配置図と図３に示すクラス図の関係には問題があると判別し、異常で終了する(S801：NO)。

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

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

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

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

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

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

また、図１２に記載されているシーケンス図において、クラス名が”ClassX”であるクラスは図３に記載されていないため、図１２に示すシーケンス図と図３に示すクラス図の関係には問題があると判別し、異常で終了する(S803：NO)。

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

また、図１４に記載されているシーケンス図において、クラス名が”ClassA”であるクラスがクラス名が”ClassB”であるクラスに対して送信するイベント”Ex3”は図３に記載されているクラス名が”ClassB”であるクラスのイベントではないため、図１４に示すシーケンス図と図３に示すクラス図の関係には問題があると判別し、異常で終了する(S803：NO)。

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

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

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

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

以上により、UMLモデル図間の関係性をチェックし問題がないかどうかを判別する。
なお、ここでは、UMLモデル図間の関係性のチェックの順番を配置図とクラス図、ステートマシン図とクラス図、シーケンス図とクラス図、シーケンス図とステートマシン図のようにしているが、順番は任意であってもよい。
＜プログラムコード生成＞
図１７は、本発明における配置図、クラス図、ステートマシン図、及び、シーケンス図から作成されるプログラムコードの一実施例を示す図である。図１７に示すプログラムコードは、プログラムコード生成部７０を用いて自動で作成される。

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

同様に、クラス名が”ClassB”であるクラスのプログラムコードもプログラムコード生成手段を用いて自動で作成される。
図１８は、本発明における配置図、及び、クラス図から作成されるプログラムコードの一実施例を示す図である。図１８に示すプログラムコードは、プログラムコード生成手段を用いて自動で作成される。
図１８に示すプログラムコードは、ハードウェア名が”HardwareA”であるハードウェア上に実装されるクラス名が”ClassC”であるクラスのプログラムコードである。図１８において、２行目、及び、９行目〜１１行目は図２に示す配置図、及び、図３に示すクラス図から作成され、４行目〜７行目は図３に示すクラス図から作成される。

図１９は、本発明における配置図、及び、クラス図から作成されるプログラムコードの一実施例を示す図である。プログラムコードは、プログラムコード生成手段を用いて自動で作成される。

図１９に示すプログラムコードは、メイン処理のプログラムコードである。図１９において、４行目〜６行目、１０行目〜１２行目、及び、１４行目〜２５行目は図２に示す配置図、及び、図３に示すクラス図から作成される。

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

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

さらに、本発明を適用することにより、配置図を用いてソフトウェア機能をどのハードウェア上に実装するかを表現することにより、分散環境下で動作するプログラムコードも自動で生成されるため、プログラム作成作業が大幅に軽減され、トータル作業工数を大幅に削減することが可能となった。

また、本発明を適用することにより、分散環境で実現されるシステム開発において、配置図を変更するだけで、ソフトウェア機能をどのハードウェア上に実装するかを容易に変更することができるため、製品開発時の自由度を大幅に高めることが可能となった。

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

Claims (8)

1. オブジェクト指向プログラムを生成するオブジェクト指向プログラム生成装置であって、
   開発対象システムの複数種類の設計ドキュメントを作成する設計ドキュメント作成部と、
   前記設計ドキュメント作成部により作成された設計ドキュメントの情報を記憶する設計ドキュメント記憶部と、
   前記設計ドキュメント記憶部から複数種類の前記設計ドキュメントの情報を各々読み出し、これら設計ドキュメント間の整合性をチェックする設計ドキュメント判別部と、
   前記設計ドキュメント判別部で整合性に問題が無いと判別された場合、オブジェクト指向プログラムを生成するプログラムコード生成部と
   を備え、
   前記設計ドキュメントは、少なくとも配置図を含むUMLモデル図であることを特徴とするオブジェクト指向プログラム生成装置。
2. 請求項１記載のオブジェクト指向プログラム生成装置において、
   前記設計ドキュメントは、少なくともステートマシン図またはシーケンス図を含むUMLモデル図であることを特徴とするオブジェクト指向プログラム生成装置。
3. 請求項２記載のオブジェクト指向プログラム生成装置において、
   前記UMLモデル図は、クラス図を含み、
   前記設計ドキュメント判別部は、
   配置図に記載されている全てのクラスがクラス図に記載されているクラスであるか否かの整合性、
   ステートマシン図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、ステートマシン図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、
   シーケンス図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、シーケンス図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、
   または、シーケンス図に記載されている全ての状態がステートマシン図に記載されている状態であるか否かの整合性の少なくともいずれかの整合性のチェックをすることを特徴とするオブジェクト指向プログラム生成装置。
4. 請求項２または３記載のオブジェクト指向プログラム生成装置において、
   前記設計ドキュメント作成部で配置図を作成する際、デバイスとしてハードウェア名、実行環境としてソフトウェア機能を記載し、プログラムコード生成部でプログラムコードを自動生成する際、分散環境下で動作するプログラムコードを生成することを特徴とするオブジェクト指向プログラム生成装置。
5. オブジェクト指向プログラムを生成するオブジェクト指向プログラム生成方法であって、
   開発対象システムの複数種類の設計ドキュメントを作成する過程と、
   作成された設計ドキュメントの情報を記憶する設計ドキュメント記憶部と、
   前記設計ドキュメント記憶部から複数種類の前記設計ドキュメントの情報を各々読み出し、これら設計ドキュメント間の整合性をチェックする過程と、
   前記整合性をチェックする過程で整合性に問題が無いと判別された場合、オブジェクト指向プログラムを生成する過程と
   を具備し、
   前記設計ドキュメントは、少なくとも配置図を含むUMLモデル図であることを特徴とするオブジェクト指向プログラム生成方法。
6. 請求項５記載のオブジェクト指向プログラム生成方法において、
   前記UMLモデル図は、クラス図を含み、
   前記設計ドキュメント間の整合性をチェックする過程は、
   配置図に記載されている全てのクラスがクラス図に記載されているクラスであるか否かの整合性、
   ステートマシン図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、ステートマシン図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、
   シーケンス図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるか否かと、シーケンス図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるか否かの整合性、
   または、シーケンス図に記載されている全ての状態がステートマシン図に記載されている状態であるか否かの整合性の少なくともいずれかの整合性のチェックをすることを特徴とするオブジェクト指向プログラム生成方法。
7. 請求項５または６記載のオブジェクト指向プログラム生成方法において、
   前記設計ドキュメント作成部で配置図を作成する際、デバイスとしてハードウェア名、実行環境としてソフトウェア機能を記載し、プログラムコード生成部でプログラムコードを自動生成する際、分散環境下で動作するプログラムコードを生成することを特徴とするオブジェクト指向プログラム生成方法。
8. コンピュータを、
   請求項１ないし４の何れか１項に記載のオブジェクト指向プログラム生成装置が有する各手段（各部）として機能させるためのオブジェクト指向プログラム生成プログラム。
   
   
   

Images