【０００１】
【発明の属する技術分野】
本発明は、システムＬＳＩの開発支援システムに関し、特に、地理的、時間的に異なる開発部隊により水平分業化された開発フレームワークを実現可能とするシステムＬＳＩ開発支援システムに関する。
【０００２】
【従来の技術】
システムＬＳＩは、機能の高度化及び複雑化に伴い、設計品質と開発期間の短縮がより重要になっている。 システムＬＳＩの開発プロセスとして、従来からＶ字型開発プロセスモデルが提案されている。 このＶ字型開発プロセスモデルでは、最初に顧客の要求を検討しその要求する仕様を抽出して要求仕様書を作成し、その要求仕様書に基づいてシステム全体の詳細仕様を開発し、実装レベルの具体的な設計を行い、そして、設計結果を実際のデバイスにハードウエア及びソフトウエアの形で実装する。 その後、そのハードウエア及びソフトウエアとして実装されたシステムＬＳＩについて、モジュール統合テスト、システム統合テストを行い、最後にシステム受入テストを行う。
【０００３】
上記のＶ字型開発プロセスモデルは提唱こそされているが、実際の開発プロセスにおいては、開発の最上流で要求仕様書を作成する段階で、原始的な紙レベルでの仕様のやりとりや検討が顧客と開発メーカとの間で行われており、この段階で双方の誤解や認識不足によりメーカが作成する要求仕様書と顧客が要求する仕様との間に不整合がしばしば発生する。 このような不整合が存在すると、その後のシステム詳細仕様や設計に多大な影響を及ぼし、開発期間の長期化と開発コストの増大をもたらす。
【０００４】
このような誤解や認識不足による不整合を削減するために、規格化されたモデリング言語であるＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）によって開発の上流段階でのモデリングを記述することが提案され、各業界においてその具体化が検討されている。
【０００５】
【発明が解決しようとする課題】
上記のように、より効率的で仕様のもれを防止する手法が提案されているが、大規模なシステムＬＳＩを開発するためには、例えば１００名以上の開発人員が開発プロセスに従事する必要がある。 そのような人員が１箇所に集結してシステムＬＳＩを開発する環境を実現することは難しくなってきている。 従って、地理的及び時間的に離れた複数の開発部隊が、開発プロセスの異なる階層を分担して開発する必要性があり、上流工程と下流工程とで頻繁にコミュニケーションをとりながら開発することは困難になっている。
【０００６】
また、大規模で多人数による開発プロセスでは、システムＬＳＩの部分的な変更が他の部分に複雑に影響しあい、開発プロセスの特に下流での安易な変更は極めて困難になりつつある。 そのため、下流工程で不具合が発覚したことによる上流工程への手戻りの発生は、開発時間の長期化とコスト増を招くことになる。
【０００７】
そこで、本発明の目的は、開発プロセスにおいて、上流側と下流側とで水平分業を可能にし、できるだけ下流工程から上流工程への手戻りの発生を防止することができるシステムＬＳＩの開発支援システムを提供することにある。
【０００８】
【課題を解決するための手段】
上記の目的を達成するために、本発明の一つの側面は、システムＬＳＩ開発支援システムにおいて、顧客が要求する仕様に基づいてシステムＬＳＩの要求仕様データを所定のモデリング言語で記述して生成するモデリング開発層コンピュータと、モデリング開発層コンピュータで生成された要求仕様データから詳細要求仕様データを生成するケース（ＣＡＳＥ、Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｓｙｓｔｅｍ Ｅｎｇｉｎｅｅｒｉｎｇ）開発層コンピュータと、前記詳細要求仕様データから変換され所定のプログラムコードで記述された実装レベルのプログラムを生成する実装設計層コンピュータとを有する。 更に、モデリング開発層コンピュータとケース開発層コンピュータと実装設計層コンピュータとが、ネットワークを介して接続され、当該ネットワーク上に設けられ前記モデリング言語で記述された要求仕様データを格納し、前記各コンピュータからアクセス可能な設計共通データベースを有する。
【０００９】
上記の発明の側面によれば、モデリング開発層とケース開発層と実装設計層に分けて水平分業化を可能にし、各階層での設計と検証とを他の階層層と分離して行うと共に、その検証に利用した検証パターンを、後に実際にデバイスに実装されたシステム検証にも利用することが可能になり、設計共通データベースに格納された要求仕様データを、全ての階層のコンピュータからアクセス可能にして、各階層から共通の要求仕様データを参照することが可能になる。 また、各階層のコンピュータをネットワークで接続することにより、各階層の開発者は、仮想的なサイバー開発空間での開発作業が可能になり、地理的及び時間的に異なる複数の地域の開発部隊によるシステムＬＳＩの開発支援を行うことができる。
【００１０】
更に、上記の発明の好ましい実施例では、要求仕様データを格納しモデリング開発層コンピュータとケース開発層コンピュータとからアクセス可能な第１の設計共有データベースと、詳細仕様データを格納しケース開発層コンピュータと実装設計層コンピュータとからアクセス可能な第２の設計共有データベースとを有する。
【００１１】
上記の実施例によれば、隣接する階層コンピュータが、両階層間で引き渡される設計データを格納する設計共有データベースに高速にアクセス可能になり、上流の開発層から次の下流の開発層及び設計層に設計データを引き渡す段階でのそれぞれの検証工程を適切に行うことができ、開発の下流工程からの手戻りを限りなく減らすことが可能になる。
【００１２】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態例を説明する。 しかしながら、本発明の保護範囲は、以下の実施の形態例に限定されるものではなく、特許請求の範囲に記載された発明とその均等物にまで及ぶものである。
［システムＬＳＩ開発支援システムの概略］
図１は、本実施の形態におけるシステムＬＳＩ開発支援システムの概略図である。 この開発プロセスのフレームワークは、開発の上流から下流までを水平分業化し、開発段階では上流から下流に検証段階では下流から上流へ進むＶ字開発プロセスフレームワーク５０と、各階層のコンピュータを特定ネットワーク１０で接続して設計共通データベース６２へのアクセスを実現し、更にグループウエアにより各階層のコンピュータ間での意志決定支援や協調開発環境支援などを行う協調開発フレームワーク５２とを有する。
【００１３】
このＶ字開発プロセスフレームワーク５０では、上流のモデリング開発層２０からＣＡＳＥ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｓｙｓｔｅｍ Ｅｎｇｉｎｅｅｒｉｎｇ）開発層３０、実装設計層４０を経由してシステムＬＳＩを開発し、開発されたソフトウエアをデバイスに実装し、その後、各実装設計層４０とＣＡＳＥ開発層３０とモデリング開発層２０での検証工程３０Ａ，２０Ａを行う。 これらの開発層及び設計層は、地理的または時間的にことなる地域の開発部隊によりそれぞれ担当される。 また、協調開発フレームワーク５２では、特定ネットワーク１０に接続された設計共通データベース６２に、モデリング開発層２０で開発されたシステムＬＳＩに要求される仕様が、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）で記述された要求仕様データとして格納され、全ての開発層または設計層のコンピュータからアクセス可能になっている。
【００１４】
更に、協調開発フレームワーク５２には、モデリング開発層２０とＣＡＳＥ開発層３０のコンピュータで共有される第１の設計共有データベース６３と、ＣＡＳＥ開発層３０と設計層４０のコンピュータで共有される第２の設計共有データベース６５とが含まれる。
［開発プロセスの概略］
図２は、システムＬＳＩの開発プロセスの具体例を示す図である。 この開発プロセスは、図１におけるＶ字開発プロセスフレームワーク５０の具体例である。 そして、図１６は、その開発プロセスのフローチャート図であり、図２及び図１６を参照して開発プロセスの概略を説明する。
【００１５】
最上流のモデリング工程Ｓ２０は、図１のモデリング開発層２０で行われる顧客の要求仕様を定義する工程である。 この工程では、顧客からの要求を分析し、その要求に応じることができるシステムＬＳＩの仕様をＵＭＬにより記述することで、システム全体のモデリングを行う（Ｓ２１）。 ＵＭＬで記述される要求仕様データには、ユースケース図、シーケンス図、クラス図、状態遷移図などが含まれる。
【００１６】
図３、図４は、ＵＭＬによるユースケース図の一例を示す図である。 この例は、車の後部ライトの制御に関する要求仕様に関する。 ユースケース図とは、ＵＭＬダイヤグラムの振る舞い図の一つであり、システムの外部機能やユーザ要求を定義する。 図３のユースケース図には、後部ライトの制御についてのモデル要素の入れ物を示す４つのパッケージ１０１〜１０４が示されている。 そこで、ブレーキライト制御のパッケージ１０１についての要求仕様を定義する図を以下に例示する。
【００１７】
図４には、ドライバ１０５からの何らかの作用に応じてブレーキライト点灯１０６とブレーキライト消灯１０７の振る舞い（ユースケース）が発生することが、ユースケース図として示される。
【００１８】
図５，６は、ＵＭＬによるシーケンス図の一例を示す図である。 シーケンス図は、図４のユースケースを実現する時のそれに参加するオブジェクト間のメッセージの送受信を表現する。 図５のブレーキライト点灯のシーケンス図では、ドライバ１０５からのブレーキペダル押し下げＭ１がテールライトコントローラ１０８に送信されると、それがブレーキライト点灯指示Ｍ２をブレーキライト制御部１０９に送信し、そのブレーキライト制御部１０９がブレーキライト点灯要求Ｍ３をブレーキライト１１０に送信する。 このように、図４のユースケース１０６を実現するためのオブジェクト間のメッセージの送受信シーケンスが図５のシーケンス図に示される。
【００１９】
図６のブレーキライト消灯のシーケンス図も、図５と同様であり、各オブジェクト間で図示したメッセージＭ１１〜Ｍ１３が送受信される。
【００２０】
図７，図８，図９は、ＵＭＬによるクラス図の一例を示す図である。 クラス図は、モデルの組立部品の集合であるクラスの関係を定義するものであり、クラスの構造とクラス間の関係を表現した仕様書である。 図７では、モデル要素の入れ物であるパッケージとして、ドメイン１１２とデバイス１１４との関係が定義されている。 つまり、パッケージ間の関係を示すものである。
【００２１】
図８には、上記のドメイン１１２のクラス図が示されている。 ここには、ドメインパッケージのクラス構造と関係が示される。 図８に示されたクラス１１６〜１２２は、それぞれ共通の構造と挙動を持つオブジェクトの定義であり、それぞれ図示されるクラス名と状態を有する。 また、図９には、上記のデバイス１１４のクラス図が示されている。 ここでは、デバイスパッケージのクラス構造と関係が示され、各クラス１２２〜１２６は、図示されるクラス名と状態を有する。 ここでは、テールライト１１２が、ブレーキライト１２３、フラッシャー１２４、バックライト１２５、リバースライト１２６としてライト状態になることが定義されている。
【００２２】
図１０、図１１は、ＵＭＬによる状態遷移図（ステートチャート図）の一例を示す図である。 図１０には、ブレーキライトの状態遷移図が示され、黒丸のスタートからそれぞれ遷移される３つの状態１２７，１２８，１２９が示されている。 これらの消灯中、点灯中、ＰＷＭ（Ｐｕｌｓｅ Ｗｉｄｔｈ Ｍｏｄｕｌａｔｉｏｎ（パルス幅変調））点灯中の状態は、図示される要求に応答して、図示される方向に遷移する。 図１１には、ブレーキライト制御の状態遷移図が示され、スタートからそれぞれ遷移する４つの状態１３０〜１３３の関係が示されている。
【００２３】
上記以外にも、ＵＭＬで記述されるダイヤグラムがある。 例えば、構造図として、クラス図以外にもオブジェクト図やパッケージ図があり、振る舞い図として、ユースケース図、シーケンス図や状態遷移図以外に、コラボレーション図、アクティビティ図があり、実装図としてコンポーネント図や配置図がある。
【００２４】
このようなＵＭＬによる様々なダイヤグラムを利用して、顧客が要求するシステムの要求仕様が、モデリング工程Ｓ２０で、モデリング開発層２０内のコンピュータに支援されて生成される。 そして、そのようにして生成された要求仕様データは、全ての階層のコンピュータからアクセス可能な設計共通データベース６２に格納される（Ｓ２３）。
【００２５】
図２のモデリング工程Ｓ２０内に示されるとおり、モデリング工程Ｓ２０では、上記の要求仕様データを生成するモデリング（Ｓ２１）に加えて、ＵＭＬレベルでのシステム検証が行われ、要求仕様データが適切であるか否かの検証が行われる（Ｓ２２）。 具体的には、シーケンス図をもとにして、ランタイムイベントを発生させ、それらランタイムイベントに対応するランタイムシーケンス図を生成し、元のシーケンス図と比較することで要求仕様データが適切であるかの検証を行う。
【００２６】
この検証工程で生成される検証パターンは、モデリング工程での検証に利用されると共に、実装後のモデリング開発層レベルでの検証（Ｓ２０Ａ）にも利用される。 検証パターンは、外界とのやりとりを含めた全てのイベントの組合せをカバーするパターンである。 そして、図１に示したとおり、モデリング開発層２０にて要求仕様データの開発と共に生成される検証パターンは、デバイスへの実装後に行われる自動化検証工程２０Ａでも利用され、これにより検証工程２０Ａを効率的に行うことができる。
【００２７】
モデリング工程Ｓ２０にて、要求仕様データが開発され、その検証も行われると、ＵＭＬによる要求仕様データが、ＣＡＳＥ工程Ｓ３０に手渡される。 具体的には、モデリング開発層２０とＣＡＳＥ開発層３０間で共有する設計共有データベース６３に、クラス図や状態遷移図などの要求仕様データが格納される（Ｓ２４）。
【００２８】
ＣＡＳＥ工程では、モデリング開発層２０から提供された要求仕様データにしたがって、システムの詳細仕様データを生成する（Ｓ３１）。 即ち、所定のコンバータにより、ＵＭＬで記述されたクラス図及び状態遷移図を変換してシステム言語で記述される状態遷移表が作成される。 この変換手段は、例えばモデルコンパイラが一般的である。 そして、その状態遷移表によって処理のもれや抜けを明確に浮き出させて、詳細仕様の精度を向上させる。 変換された状態遷移表に修正や詳細データの追加が行われて、詳細仕様データが生成される。 そして、ＣＡＳＥ工程Ｓ３０においても、詳細仕様データの開発と共に、その検証が行われる（Ｓ３２）。 また、その検証で利用した検証パターンは、実装後の検証工程３０Ａでもそのまま利用される。
【００２９】
図１２、図１３は、ＣＡＳＥ工程での状態遷移表の一例を示す図である。 図１２は、図１０のブレーキライトの状態遷移図を変換して得たブレーキライトの状態遷移表であり、横方向の３つの状態と、状態間の遷移のトリガとなる縦方向の３つのイベントとの関係が表に示される。 例えば、点灯中の状態でブレーキライト消灯要求のイベントが発生すると、ブレーキライトが消灯するイベントが発生し、消灯中の状態に遷移することが表に示される。 図中、斜線の部分は、状態遷移図から変換されなかった遷移であり、この状態遷移図を検証することで、処理のもれ又は抜けの有無をチェックすることができる。 更に、状態遷移図を利用することにより、あらゆるパターンをカバーする検証用パターンを生成することもできる。
【００３０】
図１３は、図１１のブレーキライト制御の状態遷移図から変換した状態遷移表を示す。 この状態遷移表も、図１２と同様に、４つの状態と４つのイベントとの状態遷移の関係が示される。
【００３１】
ＣＡＳＥ工程Ｓ３０で状態遷移表において処理のもれや抜けが発生していることが判明するとＣＡＳＥ工程にてその修正が行われ、更に、ＣＡＳＥ工程で詳細仕様に必要な詳細データが追加される（Ｓ３１）。 また、ＣＡＳＥ工程で修正できない重大な誤りがあると、モデリング工程Ｓ２０でその要求仕様データの修正が行われる。 この修正は、上流工程での修正作業であるので、比較的容易に修正を行うことができる。 そして、修正された要求仕様データは、再び設計共有データベース６３に格納されて、ＣＡＳＥ工程Ｓ３０での検証の対象になる。 このように、モデリング工程とＣＡＳＥ工程との間で、共有するデータベースを介して検証と必要な修正が適切に行われる。
【００３２】
さて、ＣＡＳＥ工程Ｓ３０では、システムに組み込まれる詳細仕様データが生成されると共に、その動作検証が行われる（Ｓ３２）。 この時の検証パターンは、後の実デバイスへの検証工程（Ｓ３０Ａ）でも利用される。 そして、ＣＡＳＥ工程で開発された詳細要求仕様データの例えば状態遷移図及び状態遷移表は、変換ツールによってＣ言語やＣ＋＋言語で記述されるソースコードに変換される。 そして、変換されたソースコードは、ケース開発層３０のコンピュータと実装設計層４０のコンピュータとで共有される設計共有データベース６５に格納されて、設計工程Ｓ４０に設計入力データとして引き渡される（Ｓ３３）。
【００３３】
実装設計工程Ｓ４０では、引き渡されたＣ言語やＣ＋＋言語のソースコードがＣコンパイラやＣ＋＋コンパイラによって実装レベルのソースコードが生成される（Ｓ４１）。 更に、実装設計工程Ｓ４０では、そのソースコードのプログラムについて、デバイスレベルでの種々の検証が行われる（Ｓ４１）。 また、実装設計層４０で何らかのバグが判明した場合は、再度ＣＡＳＥ工程Ｓ３０でその修正が行われる場合がある。 つまり、ＣＡＳＥ工程と実装設計工程との間でも、検証と修正とが繰り返される。
【００３４】
実装設計工程Ｓ４０で検証されたソースコードのソフトウエアがアセンブラにより機械コードに変換され、デバイスに実装される（Ｓ４２）。 そして、再度、実装設計工程レベルでの実デバイスの検証（Ｓ４３）、ＣＡＳＥ工程レベルでの実デバイスや実システムの検証（Ｓ３０Ａ）、最後にモデリング工程レベルでの実システムの検証（Ｓ２０Ａ）が行われる。 各検証工程では、図１に示した通り、開発時の検証パターンがそのまま実デバイスや実システムの検証パターンとしても利用される。
【００３５】
図１に戻り、モデリング開発層２０ではＵＭＬによる要求仕様データが開発され、検証され、設計共通データベース６２に格納される。 また、ＵＭＬによる要求仕様データは、モデリング開発層２０とＣＡＳＥ開発層３０とで共有される設計共有データベース６３にも格納され、モデリング開発層２０からＣＡＳＥ開発層３０への設計入力データとして引き渡される。 更に、ＣＡＳＥ開発層３０で開発された詳細要求仕様データは、同様にその開発層内で検証され、ソースコードに変換されて、第２の設計共有データベース６５に格納され、設計層４０への設計入力データとして引き渡される。
【００３６】
各層のコンピュータは、特定ネットワーク１０を介して相互に接続され、そのネットワーク上に配置される設計共通データベース６２にアクセスして、モデリング開発された要求仕様データを参照することができる。 この要求仕様データは、各開発層のコンピュータに共通の言語であるＵＭＬで記述されている。 これにより、地理的に時間的に異なる各開発層のコンピュータから、共通のモデリング開発資産を参照することができ、各開発層での設計ミスを未然に防ぐことができる。
【００３７】
図１４は、本実施の形態におけるシステム構成図の一例を示す図である。 簡単のために、図１４には、モデリング開発層２０のシステムと特定ネットワーク１０と、設計共通データベース６２及び設計共有データベース６３の関係だけが示される。 モデリング開発層２０には、ＵＭＬで記述される要求仕様データの生成を支援するモデリング設計装置（コンピュータ）２１と、その生成された要求仕様データの検証を行うモデリング検証装置（コンピュータ）２２とが、ＬＡＮ２４を介して接続される。 前述したとおり、モデリング開発層２０は、例えば同じ開発地域に配置され、その開発層内のコンピュータがＬＡＮ２４で接続される。
【００３８】
ＣＡＳＥ開発層３０及び実装設計層４０においても、モデリング開発層２０と同様に、開発装置と検証装置とが各階層３０、４０内のＬＡＮを介して接続されている。
【００３９】
別の実施例としては、隣接する階層間のＬＡＮを介して各階層の開発装置と検証装置とが接続されていても良い。
【００４０】
更に、図１４の例では、特定ネットワーク１０上に、モデリング開発層で生成されたＵＭＬの要求仕様データを格納した設計共通データベース６２おとその管理サーバ６０とが配置されている。 この管理サーバ６０を介して、全階層の装置から要求仕様データへのアクセスが可能である。 従って、管理サーバ６０は、全階層からのアクセスを管理し、要求仕様データの版数を管理し、また、厳重なセキュリティ管理を行う。
【００４１】
図１４の例では、各階層間で共有する設計データが格納される設計共有データベース６３、６５は、第２の管理サーバ６１を介して、特定ネットワーク１０上に配置される。 ここの格納される共有データベースは、隣接する階層のコンピュータからのアクセスのみ受け付けて、検証、修正に伴って頻繁に改版される。 従って、設計共通データベース６２に比較して、より高速にアクセスできる環境にする必要がある。
【００４２】
このように、全ての階層のコンピュータからアクセス可能な設計共通データベース６２と、隣接する階層のコンピュータからアクセス可能な設計共有データベース６３，６５とが、別々のデータベースとして異なる管理サーバにより管理されている。 従って、より頻繁なアクセスが要求される設計共有データベース６３，６５へのアクセス環境をより高速な形態にすることができると共に、広くアクセスが要求される設計共通データベース６２のセキュリティ環境をより厳重なものにすることができる。
【００４３】
図１５は、本実施の形態におけるシステム構成図の別の例を示す図である。 この例では、図１４の例と同様に、各階層に設計装置２１，３１，４１と、検証装置２２，３２，４２とを設け、それぞれ階層内のＬＡＮ２４，３４，４４を介して接続する。 そして、それらの装置は、特定ネットワーク１０により接続され、設計共通データベース６２にアクセス可能である。 そして、隣接階層間で共有される設計共有データベース６３，６５は、共有する階層間にローカルに配置され、隣接階層内のコンピュータから高速にアクセス可能に管理される。
【００４４】
グローバルなネットワーク上に配置される管理サーバ６０とその設計共通データベース６２とは、全階層のコンピュータに対して、クライアント・サーバ型で実現される。 従って、全階層のコンピュータがクライアントとして、管理サーバ６０にアクセスし、認証を伴って、設計共通データベース６２内のデータを取得する。
【００４５】
また、ローカルなネットワーク上に配置される管理サーバ６１，６４と、その設計共有データベース６３，６５とは、ピア・ツー・ピア型で実現される。 即ち、モデリング開発層２０内の複数のクライアントコンピュータ群（第１のピア）とＣＡＳＥ開発層３０内の複数のクライアントコンピュータ群（第２のピア）がローカルネットワークで接続され、それらのクライアントコンピュータの一つが管理サーバ６１として機能する。 従って、この管理サーバ６１は、管理サーバ６０よりも構成が簡単であり、隣接階層からの高速アクセスを可能にする。
【００４６】
図１５の水平分業開発支援システムによる開発工程について、以下に簡単に説明する。 最初にモデリング開発層２０内のモデリング設計装置２１を利用して、顧客の要求仕様データがＵＭＬで記述されて生成される。 そして、モデリング検証装置２２により、所定の検証パターンに対して正常に動作するか否かが検証される。 この検証パターンは、後の実システムへの検証パターンとして保管される。
【００４７】
モデリング開発層内で設計と検証が終了すると、そのクラス図や状態遷移図などが設計入力データとして設計共有データベース６３に格納される。 そこで、ＣＡＳＥ開発層３０内の設計装置３１により状態遷移表に変換され、その状態遷移表に従って処理の誤りがないか否かがチェックされ、もれや抜けの修正と詳細データの追加が行われて、システムのより詳細要求仕様データが生成され、検証装置３２で検証される。 また、状態遷移表で重大な誤りが検出されると、モデリング開発層２０にフィードバックされ、そこで修正、検証が再度行われる。
【００４８】
ＣＡＳＥ開発層３０での設計と検証が終了すると、そこで生成された状態遷移図などがＣやＣ＋＋のソースコードに変換され、入力設計データとして、設計共有データベース６５に格納される。 そして、実装設計層４０の実装設計装置４１にて、上記のソースコードに実装レベルの関数の追加などが行われ、生成されたソースコードに対して、実装検証装置４２にて検証が行われる。 検証をパスすると、そのソースコードが機械コードにコンパイルされデバイスに実装される。
【００４９】
実デバイスに対して、実装設計層４０のレベルでの検証パターンを利用してその実際の動作を検証する。 それが終わると、更に、ＣＡＳＥ開発層３０にて、実デバイスまたは実システムに対して、開発時に生成した検証パターンを利用して動作検証が行われる。 その後、更に、モデリング開発層２０にて、実デバイスまたは実システムに対して開発時に生成した検証パターンを利用して動作検証を行う。
【００５０】
このように、各階層が、地理的に時間的に異なる開発部隊に分業化されていても、各階層のコンピュータからグローバルアクセスにより設計共通データベース６２内のモデルデータを参照することができ、また、隣接階層のコンピュータからローカルなアクセスにより設計共有データベース６３，６５内の設計入力データに高速にアクセスして共有することができる。
【００５１】
以上、実施の形態例をまとめると以下の付記の通りである。
【００５２】
（付記１）システムＬＳＩ開発支援システムにおいて、
顧客が要求する仕様に基づいてシステムＬＳＩの要求仕様データを所定のモデリング言語で記述して生成するモデリング開発層コンピュータと、
前記モデリング開発層コンピュータで生成された前記要求仕様データから詳細要求仕様データを生成するケース開発層コンピュータと、
前記詳細要求仕様データから変換され所定のプログラムコードで記述された実装レベルのプログラムを生成する実装設計層コンピュータとを有し、
前記モデリング開発層コンピュータと前記ケース開発層コンピュータと前記実装設計層コンピュータとが、ネットワークを介して接続され、
更に、当該ネットワーク上に設けられ前記モデリング言語で記述された要求仕様データを格納し、全階層内のコンピュータからアクセス可能な設計共通データベースを有することを特徴とするシステムＬＳＩ開発支援システム。
【００５３】
（付記２）付記１において、
前記各階層のコンピュータは、対応する階層の開発データを生成する設計装置と、当該生成された開発データの検証を行う検証装置とを有することを特徴とするシステムＬＳＩ開発支援システム。
【００５４】
（付記３）付記１において、
前記要求仕様データを格納し、前記モデリング開発層コンピュータとケース開発層コンピュータとからアクセス可能な第１の設計共有データベースと、前記詳細要求仕様コードから変換された所定のソースコードのプログラムを格納し、前記ケース開発層コンピュータと実装設計層コンピュータとからアクセス可能な第２の設計共有データベースとを有することを特徴とするシステムＬＳＩ開発支援システム。
【００５５】
（付記４）付記３において、
前記第１の設計共有データベースは、前記モデリング開発層コンピュータとケース開発層コンピュータとを接続するローカルネットワーク上に配置され、
前記第２の設計共有データベースは、前記ケース開発層コンピュータと実装設計層コンピュータとを接続するローカルネットワーク上に配置されることを特徴とするシステムＬＳＩ開発支援システム。
【００５６】
（付記５）付記１において、
前記設計共通データベースが、前記各階層のコンピュータをクライアントとするグローバルサーバにより管理されていることを特徴とするシステムＬＳＩ開発支援システム。
【００５７】
（付記６）付記３において、
前記設計共有データベースが、隣接する階層のコンピュータ群とピア・ツー・ピア型で実現されるローカルサーバにより管理されることを特徴とするシステムＬＳＩ開発支援システム。
【００５８】
【発明の効果】
以上、本発明によれば、地理的、時間的に異なる開発部隊がシステムＬＳＩの開発プロセスの異なる階層を効率的に分業するための開発支援システムを提供することができる。
【図面の簡単な説明】
【図１】本実施の形態におけるシステムＬＳＩ開発支援システムの概略図である。
【図２】システムＬＳＩの開発プロセスの具体例を示す図である。
【図３】ＵＭＬによるユースケース図の一例を示す図である。
【図４】ＵＭＬによるユースケース図の一例を示す図である。
【図５】ＵＭＬによるシーケンス図の一例を示す図である。
【図６】ＵＭＬによるシーケンス図の一例を示す図である。
【図７】ＵＭＬによるクラス図の一例を示す図である。
【図８】ＵＭＬによるクラス図の一例を示す図である。
【図９】ＵＭＬによるクラス図の一例を示す図である。
【図１０】ＵＭＬによる状態遷移図（ステートチャート図）の一例を示す図である。
【図１１】ＵＭＬによる状態遷移図（ステートチャート図）の一例を示す図である。
【図１２】ＣＡＳＥ工程で得られる状態遷移表の一例を示す図である。
【図１３】ＣＡＳＥ工程で得られる状態遷移表の一例を示す図である。
【図１４】本実施の形態におけるシステム構成図の一例を示す図である。
【図１５】本実施の形態におけるシステム構成図の別の例を示す図である。
【図１６】システムＬＳＩの開発プロセスのフローチャート図である。
【符号の説明】
１０ 特定ネットワーク２０ モデリング開発層３０ ケース開発層、ＣＡＳＥ開発層４０ 実装設計層６２ 設計共通データベース６３，６５ 設計共有データベース