JP5948926B2 - オブジェクト指向プログラム生成装置、プログラム - Google Patents

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

また、本発明によれば、プログラムコードを自動で生成する際に、クラス図を用いて機
能のタスク割り当てを表現することにより、マルチタスクまたはマルチスレッド環境下で動作するプログラムコードも自動で生成されるため、プログラム作成作業が大幅に軽減され、オブジェクト指向プログラム開発のトータル作業工数を大幅に削減することができる。

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

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

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

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

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

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

図２、及び、図３に示すように、各クラスは、クラス名、属性、及び、操作の区画から構成される。また、操作は、ステレオタイプなどを使用し、処理関数とイベントに分類される。

図２に示す例では、クラス名が”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”を持つ。

また、クラス図名は、スレッド名を表現している。図２より、スレッド名が”Thread1”であるスレッドには、クラス名が”ClassA”であるクラス、及び、クラス名が”ClassB”であるクラスが割り当てられている。図３より、スレッド名が”Thread2”であるスレッドには、クラス名が”ClassC”であるクラスが割り当てられている。

スレッド名は、クラス図名として表現する代わりに、クラス図に付帯するノート欄などにスレッド名を記載しておいても良い。
＜ステートマシン図＞
図４、図５、及び、図６は、本発明におけるステートマシン図の一例を示す図である。
また、図４はクラス名が”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モデル図判別処理では、ステートマシン図とクラス図の関係に問題がないかどうかをチェックする(S701)。ステートマシン図とクラス図の関係に問題がある場合、異常で終了する。S701では、ステートマシン図に記載されている全てのイベントがクラス図に記載されているクラスのイベントであるかどうかをチェックする。また、S701では、ステートマシン図に記載されている全ての処理関数がクラス図に記載されているクラスの処理関数であるかどうかをチェックする。

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

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

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

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

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

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

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

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

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

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

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

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

以上により、UMLモデル図間の関係性をチェックし問題がないかどうかを判別する。
なお、ここでは、UMLモデル図間の関係性のチェックの順番をステートマシン図とクラス図、シーケンス図とクラス図、シーケンス図とステートマシン図のようにしているが、順番は任意であってもよい。
＜プログラムコード生成＞。

図１６は、本発明におけるクラス図、ステートマシン図、及び、シーケンス図から作成されるプログラムコードの一実施例を示す図である。図１６に示すプログラムコードは、プログラムコード生成部７０を用いて自動で作成される。

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

同様に、クラス名が”ClassB”であるクラス、及び、クラス名が”ClassC”であるクラ
スのプログラムコードもプログラムコード生成部７０を用いて自動で作成される。図１６
の例では、クラス”ClassA”にスレッド”Thread1”が割り当てられている。

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

図１７に示すプログラムコードは、スレッド、及び、オブジェクトの生成のプログラムコードである。図１７において、４行目、７行目〜８行目、１３行目、１６行目〜１７行
目、２０行目、及び、２３行目〜３０行目は図２に示すクラス図から作成され、５行目、
９行目、１４行目、１８行目、２１行目、及び、３１行目〜３４行目は図３に示すクラス
図から作成される。

図１７の例では、メインプログラムにスレッド”Thread1”と”Thread2”が定義され、スレッドに起動がかけられると該当するオブジェクトが呼び出され処理を実行する。これにより、クラスの機能を最小の単位として、一つのスレッドと対応させることで、他のスレッドとの排他制御やレベル付け（優先付け）を容易にしている。

ここでは、”ClassA”と”ClassB”は、同じスレッド”Thread1”であるため、”ClassA”と”ClassB”のプログラムをマルチ処理（並行処理）することはできない。一方、”ClassA”と”ClassC”のプログラムはそれぞれ別なスレッドに割り付けられているため、マルチ処理が可能となる。

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

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

さらに、本発明を適用することにより、クラス図を用いて機能のタスクまたはスレッド割り当てを表現することで、マルチタスクまたはマルチスレッド環境下で動作するプログラムコードも自動で生成されるため、プログラム作成作業が大幅に軽減され、オブジェクト指向プログラム開発のトータル作業工数を大幅に削減することが可能となった。

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

Claims (3)

1. オブジェクト指向プログラムを生成するオブジェクト指向プログラム生成装置であっ
   て、
   開発対象システムの複数種類の設計ドキュメントを作成する設計ドキュメント作成部
   と、
   前記設計ドキュメント作成部により作成された設計ドキュメントの情報を記憶する設計
   ドキュメント記憶部と、
   前記設計ドキュメント記憶部から複数種類の前記設計ドキュメントの情報を各々読み出
   し、これら設計ドキュメント間の整合性をチェックする設計ドキュメント判別部と、
   前記設計ドキュメント判別部で整合性に問題が無いと判別された場合、オブジェクト指
   向プログラムを生成するプログラムコード生成部と
   を備え、
   前記設計ドキュメントは、少なくともクラス図とステートマシン図またはクラス図とシーケンス図を含むUMLモデル図であり、
   前記設計ドキュメント作成部は、クラス図を作成する際、クラス単位の機能に対応させてタスク名またはスレッド名を記載し、
   プログラムコード生成部は、メインプログラムコードを自動生成する際、同じタスク名またはスレッド名が対応するそれぞれ異なるクラスのプログラムを並列処理できないようにし、異なるタスク名またはスレッド名が対応するそれぞれ異なるクラスのプログラムを並列処理できるようにするマルチタスクまたはマルチスレッド環境下で動作するプログラムコードを生成することを特徴とするオブジェクト指向プログラム生成装置。
   
2. 請求項１に記載のオブジェクト指向プログラム生成装置において、
   前記プログラムコード生成部は、メインプログラムコードを自動生成する際、メインプログラムにタスク名またはスレッド名を定義し、タスクまたはスレッドに起動がかけられると該当するオブジェクトが順次呼び出され処理が実行されるマルチタスクまたはマルチスレッド環境下で動作するプログラムコードを生成することを特徴とするオブジェクト指向プログラム生成装置。
   
   
3. コンピュータを、
   請求項１または２に記載のオブジェクト指向プログラム生成装置が有する
   各手段（各部）として機能させるためのオブジェクト指向プログラム生成プログラム。