JPH06187384A - 設計方法及び設計支援装置 - Google Patents

Abstract

(57)【要約】 【目的】 各々がシステムの一部を定義する第１組のオ
ブジェクトをユーザが発生することのできるシステム設
計ツールを提供する。 【構成】 オブジェクトは一つ以上の子オブジェクトの
各々が親オブジェクトの一部を定義する親子関係を有す
ることができる。第２組の実現可能なオブジェクトが発
生され、従属性に関連する第２組のオブジェクトの各々
が選定された１組のリンク間に発生される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はコンピュータシステムに
関し、特にシステムエンジニアのためのコンピュータシ
ステム自動化ツールに関する。

【０００２】

【従来の技術】システム工学は複雑なシステムの概念の
形成及び構築に関する。このようにして、それは任意主
要なプロジェクトの主要部分である。システム工学はプ
ロジェクトの初期段階を開始し、プロジェクトのライフ
サイクルを通して継続し、プロジェクトの首尾よい完成
に大きなインパクトを与える。

【０００３】システムエンジニアを支援するために、さ
まざまなコンピュータツールが設計されている。これら
のツールを理解するための一つの言葉は“システム”で
ある。ウェブスターの一般的定義ではシステムは“一つ
の全体を形成する規則的に相互作用するかもしくは独立
したアイテム群”と記述されている。“システム”には
“個人用モータ車”等の極めてハイレベルな概念から
“ドライブトレーン”等のローレベルなものまでが含ま
れる。

【０００４】“システム”という言葉は理解し難い意味
を有することもある負担の重い言葉であるが、これを考
慮するための重要な要素は異なるシステムレベルにおい
て適切な種々の支援ツールである。（例えば、ＣＡＳＥ
−コンピュータ支援ソフトウェア工学等の）現在のソフ
トウェア及び（例えば、ＣＡＥ−コンピュータ支援工学
等の）ハードウェア設計ツールは、広範なシステムレベ
ルではなく特定環境における使用効率の改善を目的とし
ている。

【０００５】

【発明が解決すべき課題】従って、異なるシステムレベ
ルにおいていくつかの異なるツールが必要となり、シス
テムレベル間で必要な情報の通信が複雑となる。さら
に、特定のツールによりユーザの操作要求が異ってきて
プログラムの使用効率が低下する。

【０００６】従って広範なシステムレベルにわたって工
学的支援を行うシステム工学的ツールに対するニーズが
生じた。

【０００７】

【課題を解決するための手段と作用】本発明により従来
のシステム設計ツールに付随する欠点や問題点を実質的
に解消するシステム設計方法及びそのための装置が提供
される。

【０００８】本発明において、各々がシステムの一部を
定義する第１組のオブジェクトが発生される。第１組の
オブジェクトに関連する第２組の実現可能なオブジェク
トも発生される。第１組のオブジェクトとの関係と第２
組のインプリメンテーションとを記述するリンクが確立
される。リンクの組間の相互依存性をリストアープした
マトリクスが発生される。

【０００９】本発明により従来技術に対して著しい利点
が得られる。相互従属性のマトリクスを調べることによ
り、セット内の他のリンクに対して一つのマトリクスを
修正する効果が示される。従って、オブジェクトの帰結
を容易に決定することができる。

【００１０】

【実施例】本発明の実施例及び長所は図１〜図１７を参
照して良く理解することができ、さまざまな図面の対応
する部分には同じ番号を付してある。

【００１１】図１はシステムエンジニアによってなされ
るプロジェクトの機能を示すブロック図である。プロジ
ェクト１０はその目的を広範に記述する概念定義部１２
から始まる。概念定義部１２からの出力に基いて、機能
設計１４が発生する。機能設計フェーズ１４からブロッ
ク１６内で詳細設計が展開される。ブロック１８におい
て、プロトタイプが展開される。プロトタイプが展開さ
れた後、ブロック２０においてユニットの製造が開始さ
れる。製造２０後、ブロック２２において保守及び現場
支援が継続される。プロジェクト１０のブロック図から
理解できるように、プロトタイプ製造乃至保守ブロック
１８〜２２から連続的にフィードバックが行われ、それ
は概念定義、機能設計及び詳細設計に組み入れられる。

【００１２】図２は代表的なシステム工学サイクルの詳
細ブロック図である。システム工学サイクルはブロック
２４において考慮中のシステムの操作ニーズの識別及び
評価で開始される。これらのニーズはブロック２６にお
いて顧客要求と結合され、ブロック２８において解釈及
び優先順位が割当てられる。この解釈は顧客により確認
され、その後ブロック３０においてシステムへの要求が
設計される。

【００１３】ブロック３０で定義されるシステムへの要
求を使用してシステム設計が展開される。システム設計
には設計トレードオフの文書化、評価性能、評価コス
ト、リスク、保守計画、検証、及び生産性が含まれる。
さらに、システム設計には提示されるアーキテクチュア
が含まれ、システムを論理グループへブレークダウンす
る。例えば、電子システムでは、アーキテクチュアはア
ナログ、デジタル及びソフトウェアグループへブレーク
ダウンすることができる。応用可能ならば、他の要素へ
のインターフェイスも定義しなければならない。システ
ム設計ブロック３２で発生する情報はシステム設計レビ
ューブロック３４で調べられる。これは受入れ可能な設
計仕様が生成されるまでシステム設計を精密化する相互
作用的工程である。

【００１４】受入れ可能な設計が生成されると、ブロッ
ク３６において設計要求仕様が生成される。設計要求仕
様は予備設計レビューブロック３８により調べられる。
仕様３６は受入れられるまで精密化される。

【００１５】予備設計レビュー３８の後で、ブロック４
０において詳細設計が展開され、ブロック４２において
詳細設計検証計画が展開される。詳細設計４０はクリテ
ィカル設計レビュー４４に受け入れられるまで精密化さ
れる。受け入れられた後、詳細設計４０は製造及び組立
４６へ取り出される。ブロック４８においてシステムの
性能、保守、信頼度及び環境要因がテストされる。シス
テムテスト４８からの情報はブロック４０において詳細
設計の精密化のために使用される。

【００１６】テストが完了すると、ブロック５０におい
てシステム統合及びテストが実施され、ブロック５２に
おいてシステムが展示され、ブロック５４において操作
分析が行われ、ブロック５６において操作ニーズ（ブロ
ック２４）が確認される。

【００１７】概念段から設計段へサイクルが進むと、さ
まざまな補助的要求が明白になってくる。これらの要求
は多くの場所に書き込まれるかもしくは１人以上の人間
の頭の中でなされる。これらの文書及び人間間で一貫し
た要求の組を維持するのは困難である。システムエンジ
ニアは情報を精密化し、要求をブレークダウンして解の
機能構造を定義し続ける。システムへの要求は階層を下
向きに流れ下り、システムがその要求に合致することを
保証する。同様に、インプリメンテーションの詳細は、
システムエンジニアが解の機能構造の定義をより精密化
できるように、階層を上流に向って流れる。

【００１８】要求 システムエンジニアのジョブの大部分は情報管理に関連
している。システムレベル要求は管理すべき最重要情報
の一つである。“要求”は一般化された用語であり、多
くの異種のシステムレベルの論点に莫然と適用されるこ
とがある。本発明は４種の基本的要求；構造的要求、コ
ンプライアンシィ要求、及びアロケータブル要求を支援
する。“構造的”要求は最終製品で実現されなければな
らない機能構造を記述する仕様書のステートメントであ
る。構造的要求の例として“データベースは２４個のモ
デムのバンクを介して情報を受け取る”が挙げられる。

【００１９】コンプライアンシィ要求は特定すべきシス
テムに関するグローバルコンプライアンシィステートメ
ントである。例えば、仕様書により“全てのソフトウェ
ア開発はパスカル言語で行うこと”もしくは“全てのハ
ードウェアは放射線耐性を有すること”が要求されるこ
とがある。

【００２０】“アロケータブル”要求は定量化可能な尺
度を特徴とする。量は一般には重量、サイズ、コスト、
圧力、温度、速度、電力、メモリ及び処理能力等の用語
で記述される。要求は一般に製品の寄与要素に制限を課
すものである。これらの各要求は“技術予算”の一部と
考えることができる。例えば、システム“２５ｗの電力
を配分し重量は０．９０７ｋｇ（２ポンド）以下”とす
れば、重量及び電力は全ての寄与要素間でワークブレー
クダウン構造で配分しなければならない。

【００２１】“補足”要求は特定のインプリメンテーシ
ョンの決定によりシステムへ課される。例えば、元の仕
様に温度制限が無くても、特定集積回路によりシステム
全体の動作温度が制限されることがある。従って、補足
要求は内部的に課せられる。例えば、特定の会社は特定
の競争相手が製造する部品は使用しない方針をとった
り、システム開発のドキュメンテーションに関して付加
要求をすることがある。補足要求はユニークに識別され
て別のインプリメンテーションを考慮する場合に、どの
要求を緩和もしくは排除し、どんな状況の下でこれが発
生するかを迅速に識別することができる。全ての構造的
要求はさらに構造的要求、コンプライアンシィの要求も
しくはアロケータブル要求として識別することができ
る。エンジニアのためのシステムレベル自動化ツール（ＳＬ
ＡＴＥ）

【００２２】図３はエンジニア用システムレベル自動化
ツールのハードウェア実施例の斜視図である。ユーザ５
８はモノクロもしくはカラーモニタ６２及びキーボード
６４とマウス６６等の入力装置を有するワークステーシ
ョン６０に対して情報を入出力する。ワークステーショ
ンはＸ−ウィンド等のグラフィックウィンドシステムを
作動できなければならない。ワークステーション６０は
ネットワークに接続されそのデータベースに記憶された
情報を複数のユーザと共有する。

【００２３】図４に開発のＳＬＡＴＥ支援を行う工学サ
イクルの抽象モデルを示す。このモデルのトップレベル
は機能要求定義（“ＦＲＤ”）６８である。ＦＲＤは操
作及び他の顧客ニーズが集められる問題ステートメント
である。これらのニーズは１組のシステムへの要求に精
密化される。各要求は前記４種のカテゴリへ分類するこ
とができる。ＦＲＤレベル６８の下にはインプリメンテ
ーション論理マッピング代替（Ｉｍｐｌｅｍｅｎｔａｔ
ｉｏｎ Ｌｏｇｉｃａｌｌｙ ＭａｐｐｅｄＡｌｔｅｒ
ｎａｔｉｖｅｓ：“ＩＬＭＡ”）群７０がある。各ＩＬ
ＭＡ７２はＦＲＤ６８のインプリメンテーションの１つ
である。ＩＬＭＡ７２は機能−インプリメンテーション
マッピング（Ｆｕｎｃｔｉｏｎ ｔｏ Ｉｍｐｌｅｍｅ
ｎｔａｔｉｏｎ Ｍａｐｐｉｎｇ：“ＦＩＭ”７４を介
してＦＲＤへ行く。システムには一つのＦＲＤレベル６
８しかなく、各代替インプリメンテーションに対して一
つずつの多くのＩＬＭＡ７２が存在する。各ＩＬＭＡ７
２は図４にソフトウェア、機構的及びハードウェアのカ
テゴリとして示す機能カテゴリ７４へ分割することがで
きる。コンプライアンシィチェックリストはコンプライ
アンシィ要求リストを含み、ＳＬＡＴＥの機能構造とは
別に維持される。

【００２４】ＳＬＡＢＳ 図５に示すように、ＳＬＡＴＥの基本目的はシステムを
“システム”レベル抽象ブロック（“ＳＬＡＢ”）７８
へ分解することである。ＳＬＡＢ７８は機能ブロック図
の基本要素と考えられる。各ＳＬＡＢ７８は“親”ＳＬ
ＡＢへの“上向き”階層リンク８０及び“子”ＳＬＡＢ
への“下向き”階層リンク８２をサポートする“キャブ
レータ”等のユニークな識別子を有している。異なる階
層レベルのＳＬＡＢ７８間のリンクを図６に詳細に示
す。さらに、各ピアＳＬＡＢはそれぞれＳＬＡＢに対し
て機能リンク８４，８６をサポートする。ピアＳＬＡＢ
は共通階層レベルのＳＬＡＢである。ピアＳＬＡＢ間の
相互関係も図６にグラフ表示される。さらに、各ＳＬＡ
Ｂ７８は技術配分予算（“ＴＡＢ”）８８、要求追跡可
能性リンク（“ＲＴＬ”）９０、実行可能機能記述
（“ＦＤ”）９２及びテキスト断片９４をサポートす
る。ＴＡＢ８８は階層レベルのさまざまなＳＬＡＢ間に
普及すべき定量化可能要求を維持するために使用され
る。例えば、重量は３．１８ｋｇ（７ポンド）以下とす
べきとのシステム要求があれば、一つの階層レベルに関
連する重量は３．１８ｋｇ（７ポンド）を越えてはなら
ない。

【００２５】ＳＬＡＴＥは２種のＲＴＬ９０−構造的Ｒ
ＴＬ及びアロケータブルＲＴＬ−をサポートする。構造
的ＲＴＬは構造的要求に関連するテキスト断片をＳＬＡ
Ｂへリンクする。例えば、送受信機に提示される“シス
テムはＡアルゴリズムを使用して符号化を行いＢアルゴ
リズムを使用して復号化を行う”という要求を有するこ
とができる。ＲＴＬは符号化／復号化要求を含むテキス
ト断片を要求を受け入れるＳＬＡＢへ結びつける。

【００２６】アロケータブルＲＴＬはアロケータブル要
求をＴＡＢ定義へ結びつける。アロケータブルＲＴＬに
ついては、第７図、第８図に関して後記する。

【００２７】テキスト断片９４はＳＬＡＢ７８に関連す
るテキスト情報の一つ以上のパラグラフである。テキス
ト断片はドキュメンテーション、提案、保守情報、マニ
ュアル等のさまざまな目的に使用できる。テキスト断片
９４はその目的を識別するための関連する記述フィール
ドを有している。

【００２８】実行可能機能記述９２は入力から出力を計
算してＳＬＡＢの機能動作をテストするために使用され
る。実行可能ＦＤについては図９に関連して詳記する。

【００２９】図６はＳＬＡＴＥのユーザインターフェイ
スの実施例を示す。一般に参照番号９６で示すインター
フェイスは各々がマウス６６もしくは他の入力装置を使
用して選定可能な複数のキー１００からなるメニューエ
リア９８を提供する。これら各キーの機能については後
記する。インターフェイス９６はさらに１０２，１０４
に示すように複数のウィンドへ細分割可能なビューエリ
ア１００を提供する。メッセージエリア１０６はシステ
ムからのメッセージをユーザへ示すために使用される。

【００３０】ウィンド１０２は概念の詳細なシステム構
成要素への階層的分解を示す。トップレベルＳＬＡＢ１
０６はＩＤとして自動販売機（Ｖｅｎｄｉｎｇ Ｍａｃ
ｈｉｎｅ）を有している。自動販売機の概念は６個の子
ＳＬＡＢ１０８〜１１８へ分割されている。硬貨処理
（Ｃｏｉｎ Ｈａｎｄｌｉｎｇ）ＳＬＡＢ１１４の子Ｓ
ＬＡＢをＳＬＡＢ１２０〜１３０として示す。両替機Ｓ
ＬＡＢ１２２は２つの子ＳＬＡＢ１３２，１３４を有し
ている。釣り銭供給（Ｃｈａｎｇｅ Ｓｕｐｐｌｙ）Ｓ
ＬＡＢ１３４は４つの子ＳＬＡＢ１３６〜１４２を有し
いる。ビユーイングエリア１０４は製品処理（Ｐｒｏｄ
ｕｃｔ Ｈａｎｄｌｉｎｇ）ＳＬＡＢ１１６の子ＳＬＡ
Ｂ１４４〜１５０間のピアごとの接続を示す。

【００３１】ＴＡＢＳ 実施例の重要な観点はＳＬＡＴＥのＴＡＢ割当機能であ
る。図７、図８は特定ＳＬＡＢのＴＡＢを構成するため
に使用されるポップアップメニューを示す。図７は自動
販売機ＳＬＡＢ１０６のＴＡＢ１５２を示し、図８は製
品在庫室（Ｐｒｏｄｕｃｔ Ｉｎｖｅｎｔｏｒｙ Ｃｈ
ｏｍｅｅｒ）ＳＬＡＢ１１０のＴＡＢ１５４を示す。

【００３２】ＴＡＢ８８は定量化可能（アロケータブ
ル）要求に対する制限、目標、実際値及び単位を記述す
るパラメータ情報を含んでいる。これらはＴＡＢに記憶
された６つの情報、すなわち、最大パラメータ限界、最
小パラメータ限界、目標パラメータ値、実（計算）パラ
メータ値、パラメータ信頼因子及びパラメータを表現す
る単位（Ｖ，Ａ等）である。多くの場合、例えば、要求
により越えられない値が設定されると最大もしくは最小
パラメータの一方だけが使用される。

【００３３】図６に示すように、ＳＬＡＴＥ設計はシス
テムブロックの階層分解を中心として構築される。各シ
ステムは構成要素レベルのインプリメンテーション詳細
に達するまで次第に詳細な構造を提供する。システム要
求は通常システムアーキテクチュア構造のより高いレベ
ルに設定された限界（例えば、システムは５．４４ｋｇ
（１２ポンド）よりも重くてはならない）を指示し、一
方、パラメータデータの実際の構成となる物理的観点
（例えば、マイクロプロセッサは０．１４ｋｇ（５オン
ス）である）は通常最低システム設計レベルに導入され
る。従って、ＳＬＡＴＥはＴＡＢ８８を介して下向きに
各パラメータ要求に対する限界及び目標を伝播し、同時
に子ＳＬＡＢの寄与を加算することによりＴＡＢを介し
て上向きに実際の実現された値を構成するように設計さ
れている。信頼性因子等のいくつかの制約はそれ自体ア
ルゴリズム計算を必要とし、簡単な加算により導き出す
ことは出来ない。

【００３４】複雑なシステムの主要な問題点は記述され
る配分可能（アロケータブル）要求は通常システム全体
の挙動及び／もしくは構成に課される統合限界であり、
システムエンジニアは初期割当から除外される大きさの
オーダーであることが多い低レベルでなされる設計判定
のインパクトをリンクする能力に欠けることである。設
計が多次元に制約される、すなわち一つの設計パラメー
タがもう一つの設計パラメータに逆作用することが認識
される場合には問題はさらに複雑になる。例えば、第１
の要求に合致する回路が高速応答性を必要とする場合、
高電力部品を使うことが考えられる。しかしながら、電
力消費が高くなると熱放散も多くなり、別の制約に影響
を及ぼして、冷却能力が大きくなり重量が増大する。さ
まざまなＳＬＡＢに関連するＴＡＢ８８は、複雑さを追
跡する能力だけでなく局部分脈内で充分な付加情報を提
供して設計者が利用可能なオプションを理解することを
支援する。前例では、冷却能力により重量が増加すると
述べた。しかしながら、ＳＬＡＢを通して重量を追跡す
る能力があれば、システムエンジニアは特定インプリメ
ンテーションに基づけば、不必要に重い重量（すなわ
ち、重量目標）がシステムのもう一つの部分に割当られ
ていると決定することができる。これにより、システム
エンジニアはシステム全体の重量制約を越えることなく
高電力部品を使用することができる。

【００３５】各ＴＡＢに記憶されるパラメータ値は、文
脈分析が有効となる前に、（公式フィールド１８８に関
する）変数や子ＳＬＡＢに関連する実際値が変化するた
びに再計算しなければならない。

【００３６】システムエンジニアはＳＬＡＴＥより各副
構成要素へ論理的にローカルパラメータ予算を配分する
ことができる。例えば、ユニットが２．２７ｋｇ（５ポ
ンド）の最大重量を有し（各々がＳＬＡＢ上に表わされ
る）３つのサブユニットで構成されている場合、設計者
は第１のサブユニットに対してＴＡＢ限界を０．４５ｋ
ｇ（１ポンド）として配分し第２のサブユニットに１ポ
ンド、第３のサブユニットに３ポンドを配分することが
できる。同様に設計者は、第３のサブユニットがソフト
ウェアモジュール等の無重量である場合、重量を第１の
サブユニットへ２ポンド、第２のサブユニットへ３ポン
ド、第３のサブユニットへ０ポンド配分することができ
る。また、設計者は後者の配分の決定に際し、いくつか
の局部限界及び／もしくは目標を保持することができ
る。限界及び目標は各ＳＬＡＢ及び“流れ下り（フロー
ダウン）”に対して挿入され、その結果、システム内の
各ＳＬＡＢに対して目標、限界及び実現値間でアルゴリ
ズムに関する比較を行うことができる。限界及び／もし
くは目標を越えるか接近する実際の状態ではシステムエ
ンジニアはフラグを立てて注意を促すことができる。あ
るＳＬＡＢに対して利用される割当の下で、予算の一部
が保存される（すなわち、利用できるが配分されない）
ように、ＳＬＡＢをより低い目標を越えるＳＬＡＢへ再
配分することができる。

【００３７】各ＴＡＢ８８は数量（予測対測定）に関連
ずけられる確実度を示す信頼性因子を含んでいる。従っ
て、ＴＡＢ再配分中に、精密測定されたＴＡＢの限界を
厳密にトリムすることができ、不確実な評価でＴＡＢ８
８に対して大きなエラーマージンを与えることができ、
しかもシステム全体の限界内にとどまることができる。
表１に最低信頼度１から最高信頼度１０までの信頼度カ
テゴリーを示す。

【００３８】

【表１】信頼性因子 １． 非初期化 ２． グローバルデフォールト ３． パーティションデフォールト ４． 低位階層から計算 ５． 特定モデル ６． 特定ユーザ ７． 特殊／他 ８． 特定顧客 ９． 標準により指定 １０． 物理的法則

【００３９】計算時、実際の最低信頼度は階層ＴＡＢへ
伝播されＳＬＡＢ７８内もしくはその下にフレキシビリ
ティがどの程度であるかが示される。

【００４０】図７、図８はＳＬＡＢ７８のＴＡＢ８８を
定義するポップアップメニュー１５２、１５４を示す。
各メニュー１５２、１５４はＴＡＢ名フィールド１５
６、ＳＬＡＢ名フィールド１５８、ＴＡＢユニットフィ
ールド１６０、目標値フィールド１６２、最小値フィー
ルド１６４、最大値フィールド１６６、ＴＡＢ ＲＴＬ
フィールド１６８（アロケータブル要求を指す）及び実
際値部１７０を含んでいる。実際値部１７０により設計
者は関連するＳＬＡＢに対する実際値を決定するために
使用される３つの方法の中の一つを選定することができ
る。設計者はフィールド１７２〜１７８を使用して子Ｓ
ＬＡＢに関連する対応するＴＡＢ値に数学演算を行って
実際値を決定することができる。実際値を得るための第
２の方法はフィールド１８０、１８２を使用して指定値
を使用することである。第３の方法はフィールド１８４
〜１８８を使用した等式により実際値を決定することで
ある。選定方法はポインタ１８９で示す。

【００４１】等式フィールド１８８を使用して実際値を
決定する等式が得られる。等式により決定される実際値
はフィールド１８４へ出力される。フィールド１８６は
計算値に関連する信頼値である。

【００４２】フィールド１８０の割付値は設計者が入力
することができる。信頼性フィールド１８２により割付
値に関連する信頼度が提供される。

【００４３】実際値は子ＳＬＡＢに関連するＴＡＢの計
算に基いて計算することができる。設計者はフィールド
１７４へ所望の演算を入力する。一般的に所望の数学演
算は加算であるが、他の演算も行なうことができる。例
えば、信頼度因子を決定するには、子ＳＬＡＢに関連す
る実際値に乗算を行う必要がある。フィールド１７６内
の信頼度因子は子ＳＬＡＢに関連する信頼度因子から計
算される。

【００４４】図７は“重量”ＴＡＢに対して設計者が完
了したメニューを示す。このＴＡＢは、階層のトップＴ
ＡＢである、自動販売機ＳＬＡＢ１０６に関連してい
る。従って、重量ＴＡＢに対する２，７２２ｋｇ（６，
０００ポンド）の目標がシステム全体の目標である。
２，２６８ｋｇ（５，０００ポンド）の最小重量及び
３，１７５ｋｇ（７，０００ポンド）の最大重量が指定
される。２，５１７ｋｇ（５，５５０ポンド）の実際値
が子ＳＬＡＢの和を使用して計算される。従って、各Ｓ
ＬＡＢ１０８〜１１８には合計２，５１７ｋｇ（５，５
５０ポンド）の重量ＴＡＢが関連している。

【００４５】図８は製品在庫室ＳＬＡＢ１１０に関連す
る“容量”ＴＡＢを示す。５５０缶、最小４００で最大
７００、の容量を提供することが目標である。この場
合、５４５缶の実際値はフィールド１８８へ入力される
等式により計算される。

【００４６】実行可能機能記述（ＦＤ） 図９は実行可能ＦＤの動作を示すブロック図である。図
５に関して説明したように、ＳＬＡＢ７８は入力を出力
へ変換する１つ以上の実行可能なＦＤ９２を有すること
ができる。実行可能ＦＤ１９０は２入力“ｉ”、“Ｘ”
及び２出力“Ｏ”、“Ｙ”を有している。Ｙは一群の出
力信号を表わしＸは一群の入力信号を表わし、Ｙ＝ｆ
（ｘ）は一般化された機能記述である。入力ｉはブロッ
クを初期化し、一時的パラメータ記憶、インプリメント
ブレークポイント能力等を提供するために使用される２
次入力である。２次出力Ｏは報告可能なデータ経路を提
供する。ＳＬＡＴＥを使用する設計者は実行可能ＦＤ、
ホストＳＬＡＢ／ＦＤ間の相互接続及びＦＤとその相互
接続間の機能／工程の一貫性を定義する責任がある。関
数ｆ（ｘ）はローカル変数及びパラメータを使用するこ
とができる。

【００４７】テキスト断片 図１１はＳＬＡＴＥから与えられるテキスト断片９４及
び自動文書発生機能を示す。前記したように、各ＳＬＡ
Ｂ７８に任意の数のテキスト断片９４を付随することが
できる。図１０は製品在庫室ＳＬＡＢ１１０に関連する
テキスト断片を示す。テキスト断片修正メニュー１９２
を図１０に示す。メニュー１９２はテキスト断片名に対
する名称フィールド１９４、テキスト断片に数値識別を
与える数値識別フィールド１９６、テキスト断片を記述
する記述フィールド１９８、テキスト断片に関連するキ
ーワードをリストするキーワードフィールド２００、テ
キスト断片が関連するＳＬＡＢを指定するアタッチメン
トフィールド２０２、テキスト断片を組み込む文書をリ
ストする参照文書フィールド２０４及び修正すべきテキ
スト断片の内容を表示する編集フィールド２０６を提供
する。

【００４８】図１１は一つ以上のテキスト断片からなる
文書のパラメータを指定するフォーマットブロックメニ
ューを示す。メニュー２０８には発生すべき文書名を入
力する名称フィールド２１０、文書のタイトルを与える
タイトルフィールド２１２、（マニュアル、ワークステ
ートメント、プロポザル等の）文書種別を指定する文書
種フィールド２１４、出版者名フィールド２１８、文書
に関連する特定契約を指定する契約名フィールド２２
０、文書が発生されるべき実体を指定するための顧客フ
ィールド２２２、修正識別子を指定する修正フィールド
２２４、修正日付を指定する日付フィールド２２６、文
書の信頼性分類を指定する分類フィールド２２８、ヘッ
ダー及びフーターフィールド２３０、文書が内容テーブ
ルを含むかどうかを示す文書支援フィールド２３２、イ
ンデクス、頭字部、参照文書部、付録リスト、図リスト
もしくはテーブルリストが含まれる。

【００４９】図１２は文書のテンプレートを構成するエ
ディタメニュー２３４を示す。名称フィールド２３６は
文書名を与える。文書タイトルフィールド２３８は、修
正フィールド２４０、データフィールド２４２、及び分
類フィールド２４４は図１１に関して記述したものと同
じ機能を有している。構造フィールド２４６によりユー
ザは文書及び参照テキスト断片の機構を記述するテンプ
レートを得ることができる。例えば、セクション３“製
品在庫室”の下で、テキスト断片“室”が参照される。
テキスト断片を図１０に示す。

【００５０】図１３に、文書テンプレートに基いてマー
ジされる出力を示す。ファイル名は名称フィールド２４
８に与えられテキストはテキストフィールド２５０に与
えられる。図示するように、さまざまなファイルが図１
２に示すテンプレートへマージされている。マージされ
た文書により“／ＢＥＧＩＮ”、“／ＤＯＣＴ”、及び
“／ＴＩＴＬＥ”等のいくつかのコントロールコマンド
が与えられる。しかしながら実施例では、マージされた
文書はいくつかの一般的なワードプロセッサのいずれか
のファイル仕様とコンパチブルとなるようにフォーマッ
トされることができる。

【００５１】ＴＲＡＭ 図４に関して述べたように、機能−処理マッピング（Ｆ
ＩＭ）７４により一つ以上のインプリメンテーション論
理的マッピング代替（ＩＬＡＭ）７０から分離された機
能要求定義（ＦＲＤ）６８として設計を構成することが
できる。実際上、ＦＲＤ及びＩＬＭＡ間だけでなく異な
るレベルのＩＬＭＡ間にもいくつかのＦＩＭが存在する
ことがある。解の合成においてどこかに“直観の飛躍”
があるかもしくは抽象概念（機能、アルゴリズムもしく
はニーズ）が（例えば、ポート、割込ハンドラーの指
定、帯域スケージューリング等により）システムリソー
ス上にマップされると、ＦＩＭが存在し、ＳＬＡＴＥ内
のマッピングを記録するオブジェクトはＴＲＡＭ（遷移
マッピング）となる。

【００５２】図１４はＴＲＡＭを示す。ＴＲＡＭ２５２
は設計構造内のＦＩＭ７４間で機能性、要求追跡性及び
技術配分予算を運ぶコンジットである。ＴＲＡＭ２５２
は、ここでＳＬＡＢ間の“フォスターペアレントーフォ
スターチャイルド（里親ー里子）”関係として記述され
る、特殊な親子関係を提供する。ＴＲＡＭ２５２は一つ
以上の里親ＳＬＡＢを一つ以上の里子ＳＬＡＢとリンク
する。各ＳＬＡＢは里親ＳＬＡＢから一つ以上のＲＴＬ
９０及びＴＡＢ８８とリンクすることができ、ＴＲＡＭ
インタリンクを記述する関連テキスト断片９４を有する
ことができる。

【００５３】図１５及び図１６はＴＲＡＭ２５２の共通
使用を示す。図１５において、コントロールハードウェ
アＳＬＡＢ２５４及びプロセスソフトウェアＳＬＡＢ２
５６がＴＲＡＭ２５８を介してＲＯＭ ＳＬＡＢ２６０
を有するマイクロプロセッサに接続されている。ＳＬＡ
ＴＥにより任意のＳＬＡＢが少くとも一つの親を有する
ことができるので、ＳＬＡＢ２５４、２５６〜ＳＬＡＢ
２６０のこの２：１マッピングを階層分解を使用して行
うことはできない。図１５の例では、ＳＬＡＢ２５４、
２５６は里親ＳＬＡＢであり、ＳＬＡＢ２６０は里子Ｓ
ＬＡＢである。

【００５４】図１６はＴＲＡＭの第２例を示し、通信チ
ャネルＳＬＡＢ２６２が待ち行列ソフトウェアＳＬＡＢ
２６４、待ち行列ハードウェア２６６、プロトコルＳＬ
ＡＢ２６８及びバスハードウェア２７０に接続されてい
る。通信チャネルＳＬＡＢ２６２はＲＴＬ２７２及び放
射ＴＡＢ２７４を含んでいる。ＲＴＬ２７２はＴＲＡＭ
２７６を介して里子ＴＡＢ２６４〜２７０へ転送され
る。放射ＴＡＢ２７４は待ち行列ハードウェアＳＬＡＢ
２６６及びバスハードウェアＳＬＡＢ２７０間に配分さ
れる。放射ＴＡＢ２７４は任意の所望の比率で配分する
ことができ、例えば、通信チャネルに関連する放射の１
／３を待ち行列ハードウェアＴＡＢ２６６に配分し放射
の２／３をバスハードウェアＳＬＡＢ２７０に配分する
ことができる。

【００５５】複雑なシステム設計を記録する際にインプ
リメンテーションの詳細の導出の後の思考過程を明確な
文書化を元の要求から得ようとするとシステムエンジニ
アにとって大きな問題が生じる。システム設計の記述の
大部分は通常トップダウン階層分解で表わすことができ
る。ＳＬＡＴＥは、標準ＳＬＡＢ親子関係により、この
ような階層の詳細分解パラダイムを使用して大部分のシ
ステム設計の記述を遂行する。標準階層構造が最終設計
に到る関係に伴う複雑性を説明するのに適切でない場合
に問題が生じる。一般に最も説明を要し且つ文書化を支
援する必要があるのはこのような精密な複雑性である
が、それに対して設計者は使用すべき特殊なドキュメン
テーションツールを歴史的に所持していない。ＳＬＡＴ
Ｅパラダイムでは、ＴＲＡＭ機構がこれらの複雑な関係
を処理する。

【００５６】少くとも３つのカテゴリーの複雑性によ
り、標準階層ＳＬＡＢ構造の補足としてＴＲＡＭ構造が
必要とされる。

【００５７】１．概念要求を実現可能な構成要素及びサ
ブシステム上へマッピングする。（これは、しばしば
“ＦＩＭをブリッジする”と言われる元のＳＬＡＴＥ
“クラシック”ＴＲＡＭである。）これには必要ステー
トメントから計画解へ見通しをシフトすることが伴う。
これらの概念要求の例を図１５、図１６に示す。

【００５８】２．異なる機能ニーズを満すように予め設
計されている既存の実現可能な構成要素及び／もしくは
サブシステムへ２次要求のマージャーをマッピングす
る。このマッピングの例について以下に説明する。

【００５９】３．潜在的に実現可能性のある“現在の”
見通しを最終設計インプリメンテーションに“より近
い”実現可能要素の異なる組上へ再マッピングする。Ｓ
ＬＡＴＥパラダイムでは実現可能要素の一つの階層構造
を考へるのが自然であるため、このカテゴリーは把握し
難い。実際上、処理可能なビット及びピースへ分割でき
るまで画像全体を“ニブル”することにより解が形成さ
れる。従って、“設計解を得る”ための仮工程におい
て、最終的に実現されるものに近いものでニーズを再定
義するのを助けるための多くの中間ステップをシステム
設計者は踏むことになる。このカテゴリーの共通発生に
は共有リソースの多重使用を集結させてニーズを共通設
計へ合体させることが伴う。個別の使用点は実施されな
いため、（たとえ、個別に実現されていて階層構造内の
一つおきのＳＬＡＢが最終設計であっても）実現可能要
素として識別されるＳＬＡＢを考へるのは正しくなく、
それは文脈で使用されるように、これらのＳＬＡＢは共
有リソースを実施することにより最終設計において満さ
れるニーズ要求を形成するためである。

【００６０】これまでＳＬＡＴＥについて記載したこと
の大部分は広範な詳細要求リストの存在を必要とした。
営利企業を表わす厳密でない“ミッションステートメン
ト”からでも同じプロセスが展開されることを示す例を
以下に示す。選定例は自動車の設計に関するものであ
る。

【００６１】メーカーの自動車設計時における原理及び
要求の部分リストは次のように記述される。 “＊製品を販売できるようにするための政府の要求に合
致させ、 ＊顧客ベースの機能要求及びニーズに合致させ、 ＊潜在顧客の｀関心´に訴える、 ことにより成長力のある製品を市販せんとするものであ
る。”

【００６２】このような要求リストは第２表に示す“機
能要求定義”構造へマッピングして、最終詳細へと階層
分解することができる。以下の各階層線エントリーはＳ
ＬＡＴＥ内のＳＬＡＢに対応する。

【００６３】

【表２】機能要求定義 １． 成長力のある製品を市場へ出す。 １．１ 製品を市販できるようにする政府の
要求に合致させる。 １．１．１ 安全基準に適合させる。 １．１．２ 環境汚染基準に適合させる。 ．．． １．２ 顧客ベースの機能ニーズに合せる。 １．２．１ 積荷容量 １．２．２ 運転速度 １．２．２．１ エンジン馬力 １．２．２．２ 車輌重量 １．２．３ １個の燃料槽の運転距離 ．．． １．３ 顧客の｀関心´の喚起 １．３．１ 居住性 １．３．２ 運転容易性 １．３．３ “目を引く”デザイン １．３．４ “運転コスト”の低減 １．３．４．１ “燃費”向上 ．．．

【００６４】任意所与の領域においてさらにブレークダ
ウンを行うことができる。（例えば、１．２．２の運転
速度に関して、重量、馬力、空気力学的設計等間の数学
関係をさらに詳細化することが考へられる。）しかしな
がら、トップダウン式詳細化により自動車の設計が行わ
れることはなく、それは機能要求定義階層が“実現可能
要素（インプルメンタブル）”に対処しないためであ
る。キャブレータ、タイヤ、ピストン、ワイパー、テー
ルライトは供給されない。明らかにＴＲＡＭマッピング
は自動車を組立てる部品と表２の機能要求定義との間に
存在しなければならない。

【００６５】インプリメンテーションも表３の同様な階
層構造で記述することができる。このような構造の一部
は次のような詳細とすることができる。

【００６６】

【表３】インプリメンテーション階層構造 １． 自動車 １．１ 構造本体／シャーシ １．２ 内部客室 １．３ エンジン １．３．１ エンジンブロック １．３．２ キャブレータ １．３．３ ラジエータ／冷却システム １．３．３．１ ファン １．３．３．２ ウォータポンプ １．３．３．３ ヒータ １．３．３．４ デフロスター １．３．３．５ ラジエータ １．４ パワートレーン １．５ 排気システム １．５．１ テールパイプ １．５．２ マフラー １．５．３ 触媒コンバータ １．６ 電気システム １．６．１ バッテリ １．６．２ 発電機 １．６．３ ライト １．７ 運転性能 １．７．１ パワーステアリング １．７．２ クルーズコントロール １．７．３ 空調機．．．

【００６７】従来の階層と同様に、選択は分類され“連
想”の一つの実施例を“正しい”と考へてはならない。
むしろ、設計者がシステムを考える時の見通しの文書化
された記録を考へるべきである。

【００６８】ＳＬＡＴＥ内でＴＲＡＭ機構を使用して機
能要求定義とインプリメンテーション階層間のマッピン
グを構築する。自動車の設計例では、ＳＬＡＴＥ設計時
のシナリオは次のようになる。

【００６９】ＴＲＡＭの構成 ユーザは表２及び３に示す２つのＳＬＡＢ階層を既に有
している。ユーザは次に“Ａｃｔｉｏｎ／Ｏｂｊｅｃ
ｔ”コマンド“Ａｄｄ／ＴＲＡＭ”を選定する。ポップ
アップウィンドが開いてユーザはこのＴＲＡＭの特定事
項を指定することができる。ＴＲＡＭにはユーザが参照
できる名称が与えられる。入力側接続（本例では、機能
要求定義階層からの里親ＳＬＡＢ）が指定される。本例
ではインプリメンテーション階層のＳＬＡＢである出力
側接続（里子）が指定される。この点において、新しい
ＴＲＡＭが確立され正規のＳＬＡＢと同様にデータベー
ス内で“生きる”。

【００７０】ＴＲＡＭが確立されると、ユーザは標準Ｓ
ＬＡＢの場合と極めて同様にそれを強化することができ
る。ユーザは“Ａｄｄ／Ｔｅｘｔ Ｆｒａｇｍｅｎｔ”
を行ってＴＲＡＭが実施するマッピングの後の思考過程
を説明することができる。ユーザはＴＲＡＭの里親へ結
びついているＴＡＢを全体的もしくは部分的にＴＲＡＭ
へ流れるように（里親ＳＬＡＢにおけるＴＡＢ伝播を制
御することにより）“再ルート化”させ、次にＴＲＡＭ
自体においてＴＲＡＭへ伝播されたＴＡＢ部分を適切に
ルーチングする。“要求追跡可能リンク（Ｒｅｑｕｉｒ
ｅｍｅｎｔ Ｔｒａｃｅｂｉｌｉｔｙ Ｌｉｎｋｓ）”
はＴＲＡＭへ結びつけるか（マウスがＴＲＡＭへの連結
要求をカチッと知らせる）もしくはＴＲＡＭへ伝播させ
ることができる（里親ＳＬＡＢ及びＴＲＡＭにおける標
準ＲＴＬ伝播ウィンドの使用）。

【００７１】自動車の例を使用すれば、ユーザは次のも
のを呼出すことができる。 ＡＤＤ−ＴＲＡＭ．．．ＴＲＡＭ名＝ＰＡＳＳＥＮＧＥ
Ｒ ＲＥＳＴＲＡＩＮＴＳＹＳＴＥＭ 里親ＳＬＡＢｓ＝ＳＡＦＥＴＹ ＳＴＡＮＤＡＲＤ Ｘ
ＸＸ（１．１．１．８．４） ＰＡＳＳＥＮＧＥＲ ＣＯＭＦＯＲＴ（１．３．１．
６） 里子ＳＬＡＢ＝ＡＩＲ ＢＡＧ（１．２．８．３．９） このＴＲＡＭにテキスト断片を置いて消費者調査により
エアバッグの方がハーネスよりも快適であると判断され
たことを説明することができる。別モデルの車では快適
性よりも経済条件が優先してショルダーハーネスが選択
されることもある。さらに経済性、安全性及び快適性を
このＴＲＡＭで一緒にして顧客に標準ショルダーハーネ
スを提供しエアバッグシステムをオプションとすること
もある。構造及び結果がどうであれ、ＴＲＡＭは設計イ
ンプリメンテーションへ導く過程を文書化し、設計過程
で考慮した要因に対する追跡可能性を提供する。

【００７２】乗客制約（Ｐａｓｓｅｎｇｅｒ Ｒｅｓｔ
ｒａｉｎｔ）ＴＲＡＭは一人の里子及び多数の里親を有
している。それは複数の里親（安全基準及び乗客の快適
性）をマップし、一人の里子（エアバッグ）へ遷移マッ
ピングを行うため“Ｎ対１”ＴＲＡＭと呼ばれる。ＳＬ
ＡＢは定義によりせいぜい一人の親しか持てないため、
“Ｎ対１”ＴＲＡＭは設計において最も明確なＴＲＡＭ
である。従って、多くの関心が集中して一つの実現され
た実体となる場合には、ＳＬＡＢは前に説明された概念
を単に詳細化したものではなく開発された多くのアイデ
アの合成（新しい見通し）となり、ＴＲＡＭを介してマ
ップして意図する関係を明確に叙述しなければならな
い。前記ＴＲＡＭはカテゴリー１ ＴＲＡＭの合理化に
適合する。

【００７３】幾分難しくなるのは、一人の里親の属性が
図１５に示すように無数の里子に結びついている“１対
Ｎ”ＴＲＡＭである。これは（図６に示す）正規の階層
親子関係と混同されることがあり、時には“１対Ｎ”Ｔ
ＲＡＭについて疑問を生じる。答は“見通しの変化”に
あり、例により説明することができる。次のように仮定
する。

【００７４】里親ＳＬＡＢ＝非燃性材の使用を要求する
安全基準（１．１．１．３．５） 里子ＳＬＡＢ＝椅子張材（１．２．８．３．５．９） ラジェータホース（１．３．３．６） 外装ビニールトリム（１．７．６．２） 等

【００７５】明らかに、ラジェータホースは“非毒性材
使用”に含まれない。その主機能は冷却システムへ流体
を送ることである（従って、その直接の先祖はＳＬＡＢ
１．３．３−ラジェータ／冷却システムへ通る）。本例
では、数量化は存在せず配分もされないため、数量的技
術予算は適切ではなく、非燃性材使用をコンプライアン
シィチェックリストへ調整する試みにより、“１対Ｎ”
ＴＲＡＭにより得られるこの設計構造の詳細が薄められ
る。これはＴＲＡＭのカテゴリ２の利用である。

【００７６】ドライニーズ及び結果たる実施構造が配分
されると、ＴＲＡＭは“Ｎ対Ｎ”マッピングとなる。例
えば、自動車の電子システムは精巧となり、自動車全体
を通じて状態情報及びコマンドを通信するニーズは非常
に複雑となって自動車全体に内部“データバス”を配線
するものも現れている。このような情報バスの設計に関
連する“Ｎ対Ｎ”ＴＲＡＭは次のように記述できる。

【００７７】ＴＲＡＭ名＝自動車情報バス 里親ＳＬＡＢｓ＝空燃ミックスの感知データ エンジンタイミング感知データ エミッション感知データ “ガスペダル位置”からの感知データ “ブレーキペダル位置”からの感知データ 速度計からの感知データ 近接ライトからの感知データ ヘッドライトビームの感知状態 コントロールマイクロプロセッサアルゴリズム 里子ＳＬＡＢｓ＝（ＲＯＭにソフトウェアを有する）電
気データバス ケープリングマイクロプロセッサ バスマルチプレクサハードウェア 種々のセンサ…… 種々のアクチュエータ…… 等

【００７８】このＴＲＡＭには指摘点が多い。第１の点
は、“いくつかの機能タスクを実施する部品の組立
体”、全ての“Ｎ対Ｎ”ＴＲＡＭのおそらく正しいステ
ートメント、を明確に構成することである。“部品の組
立体”とあるので、短縮されたサブシステムと考へら
れ、本質的に“すぐ入手可能な”部品となる。自動車自
体さえも高レベルシステムでは部品とみなされるため、
このような見通しの変化は驚くに当らない。従って、Ｔ
ＲＡＭは相対文脈内で対処される見通しを文書化し、そ
の内に含まれる情報はその文脈内で適切に理解されるも
のとみなさなければならない。見通しに対して価値判断
は割当てられない。

【００７９】（ハードウェアバスもしくはソフトウェア
サブルーチン等の）再使用可能／共有可能リソースの多
重使用を伴う多くのシステム設計において共通に発生す
るテーマがある。（トップダウン階層設計構造の下で最
も厳しい感覚で要求されるように）各事象を別々に実現
すると通常カウンターはコスト低減による効率向上とい
うほとんど普遍的な要求へ進む。これら多数の事象を集
結し（しばしば一つである）少数のリソース供給を実現
すれば見通しの変化が生じＴＲＡＭが必要となる。この
ようなＴＲＡＭはインプリメンテーションの一つの見解
からもう一つの見解へマップされるように見える。実際
には、最初の階層構造は実現可能要素と“機能ニーズ”
が混合されたものである。“機能リソースを必要とする
構造点”のＴＲＡＭを介した共有リソースとして実現さ
れる見通しへの再マッピングにより、中間階層構造は
“純粋に実現可能”ではない、すなわち少くとも実現さ
れる最終システム設計に関して実現可能ではないことが
確認される。

【００８０】ＭＯＲＴＡＲ 根本的配慮を文書化するだけでなく配分可能要求、構造
要求及びインプリメンテーション構造をコンピュータ的
にリンクするＴＲＡＭを介してＦＩＭがトラバースされ
ると、ＦＩＭに生じるマクロレベル協同効果の文書化に
注意を向けることができる。マクロ協同考察を説明する
ＳＬＡＴＥ機構はＭＯＲＴＡＲ（Ｍａｐｐｉｎｇ ｏｆ
Ｒａｇｉｎａｌ ＴＲＡＭｓ ａｎｄ Ｒｅｑｕｉｒ
ｅｍｅｎｔｓ）である。

【００８１】ＭＯＲＴＡＲは１組のＴＲＡＭに固有の協
同関係を結びつける構造を提供する。ＭＯＲＴＡＲは実
際上ＴＲＡＭ間に生じる協同関係を説明する支援テキス
ト記述及び量的マトリクス記述で構成される。この種の
関係は、" 協同工学 "の心臓部で核となる状態である、
ＦＩＭマッピングに実際上多くの制約があって結果たる
インプリメンテーション選択が２次的に微妙に多重拘束
されている場合の文書にとって特に重要である。

【００８２】この点における例により多くの点が明確に
なり、いくつかの概念をより完全に練り上げることがで
きる基準状況が提供される。 必要とされる機能： “アイテム”をソートし、分類し相関させるシステムの
設計 制約： システムの重量は１．９８ｋｇ（７０オンス）以下、電
流は５Ａ以下、且つ少くとも６０００“アイテム”／秒
の処理を行うこと。 要求リスト（上記より誘導） Ｒ１ − ソート Ｒ２ − 分類 Ｒ３ − 相関 Ｒ４ − ＜１．９８ｋｇ（７０オンス） Ｒ５ − ＜５Ａ Ｒ６ −６０００アイテム／秒 解を実現する際の可能な“システムの構成要素”

【００８３】

【表４】 電子チップ TYPE MIPS WEIGHT POWER COST Microprocessor XYZ 6.5 4.5 oz 400 ma $ 38.75 Microprocessor RST 8.2 6.2 oz 750 ma $ 46.20 Microprocessor JKL 3.5 3.4 oz 350 ma $ 14.50 256 K DRAM - - 2.5 oz 160 ma $ 1.38 1 Meg DRAM - - 4.9 oz 425 ma $ 12.42

【００８４】

【表５】

【００８５】ＳＬＡＴＥは各設計の非常に多くの解釈及
びアプローチを供給することができ、“正しい”アプロ
ーチは一つではない。ＴＲＡＭの定義及びマッピング方
法の定義はユーザの個別の設計方法を反映し、ユーザが
設計を調べるフレームワーク内で完全で且つ一貫性を有
しなければならない。本質的に、ＴＲＡＭは設計者が意
図する見通しをとらえる。別の見通しも同等に妥当であ
る。一つの可能な見通しにより例を続ける。

【００８６】分析：相関関数Ｓ６４は非常にメモリを消
耗するため、電力及び重量制限を越えてしまう。Ｓ６４
はＸＹＺとコンパチブルな唯一の相関であるため、ＸＹ
Ｚは実行できる代替策とはならない。スループット条件
によりマイクロプロセッサＪＫＬを利用する場合少くと
も２台を並列運転させる必要がある。

【００８７】 解１：（最低廉） Weight Power Cost Microprocessor - JKL, Qty 2 6.8 oz 0.7 a $ 29.00 DRAMs - 256 K, Qty 25 62.5 oz 4.0 a $ 34.50 Software - J93, C15, & S71 この解により毎秒６４８１＋アイテムが処理される。 解２：（より高価であるが、電力及び重量は小さい） Weight Power Cost Microprocessor - JKL, Qty 2 6.8 oz 0.7 a $ 29.00 DRAMs - 1 Meg., Qty 7 34.3 oz 2.975 a $ 86.94 Software - J93, C15, & S71 この解により毎秒６４８１＋アイテムが処理される。 解３：（高コストによる高速、高スループット） Weight Power Cost Microprocessor - RST 6.2 oz 0.75 a $ 46.20 DRAMs - 1 Meg., Qty 9 44.1 oz 3.825 a $111.78 Software - J14, C15, & S71 この解により毎秒６９２３＋アイテムが処理される。

【００８８】２５６Ｋ及び１Ｍｅｇ ＤＲＡＭを使用す
れば他にもいくつかの解が可能となる、すなわちスケー
ルを変更することによりコストが低減されるが重量及び
消費電力にも影響を及ぼす。例えば、 解３Ａ：（スループットが同じで、重量、電力及び費用が少い） Weight Power Cost Microprocessor - RST 6.2 oz 0.75 a $ 46.20 DRAMs - 1 Meg., Qty 8 39.2 oz 3.4 a $ 99.36 DRAMs - 256 K, Qty 1 2.5 oz 0.16 a $ 1.38 Software - J14, C15, & S71 この解により毎秒６９２３＋アイテムが処理される。

【００８９】この分析レベルでは解３Ａの方が解３より
も優れているように見えるが、実際には異なるサイズの
メモリを混合することが複雑で結果的な重量、電力及び
支援回路の費用により３Ａは除外される。重量、電力及
びコストの広範な改良の点からメモリサイズの混合を受
け入れるものとすれば、全ての１Ｍ ＤＲＡＭを２５６
Ｋ ＤＲＡＭへ置換したくなる。（１Ｍ及び２５６Ｋ
ＤＲＡＭは共にＣ１５／５８Ｋニーズをカバーするのに
充分過ぎるため）１対１チップ置換に対してうまく作用
するものは４対１チップ置換が必要な時にもブレークダ
ウンされる。各１Ｍ置換に対して適用可能なデルタは次
のようになる。 重量 − １４５ｇ（５．１オンス）増加 電力 − ０．２１５Ａ増加コスト− ６．９０ドル低
減

【００９０】コスト低減は望ましいが、重量及び／もし
くは電力制限によりこれ以上２５６Ｋ ＤＲＡＭをＲＳ
Ｔベース解へ置換することは直ちに防止される。 補足条件： ＲＳ１−マイクロプロセッサが全ソフトウェアをランさ
せるニーズ ＲＳ２−ＳＯＲＴ ＳＷに対するメモリ条件 ＲＳ３−ＣＬＡＳＳＩＦＬＣＡＴＩＯＮ ＳＷに対する
メモリ条件 ＲＳ４−ＣＯＲＲＥＬＡＴＩＯＮ ＳＷに対するメモリ
条件

【００９１】この例を実施するために、ＩＬＭＡ２（解
２）を付随する結果ＴＲＡＭの一つのバリエーションを
示す。 Ｔ１｛（Ｒ１）−＞（Ｊ９３）｝ ソート要求からのソ
ートＳＷ Ｔ２｛（Ｒ２）−＞（Ｃ１５）｝ 分類要求からの分類
ＳＷ Ｔ３｛（Ｒ３）−＞（Ｓ７１）｝ 相関要求からの相関
ＳＷ Ｔ４｛（ＲＳ１）−＞（ＪＫＬ）｝ソフトウェアラン要
求からのマイクロプロセッサ Ｔ５｛（ＲＳ２，ＲＳ３，ＲＳ４）−＞（ＤＲＡＭ
ｓ）｝総メモリニーズ

【００９２】このＴＲＡＭマッピングには未解決の問題
がいくつかある。第１に、システムエンジニアは並列Ｊ
ＫＬプロセッサの二重アーキテクチュアに対処するよう
にＳＬＡＴＥに命令しなければならない。おそらく受け
入れられる最も簡単な方法は“完全”マイクロプロセッ
サ機能を示した一つのＳＬＡＢ（おそらく“ＪＫＬ”）
を有することである。次に、このＳＬＡＢ（“ＪＫ
Ｌ”）は配分する必要のある任意の他の回路と共に、マ
イクロプロセッサの事象の２つのインスタンス（ＳＬＡ
Ｂ“ＪＫＬ１”、“ＪＫＬ２”）である子を有し、ツイ
ンプロセッサ間の処理タスクを平衡させる。Ｔ４は機能
マイクロプロセッサＳＬＡＢ（“ＪＫＬ”）を指示する
ことができる。

【００９３】他方の論理的疑問は配分可能要求（Ｒ４、
Ｒ５、Ｒ６）の結合方法である。第６ＴＲＡＭによりハ
ードウェアにハードウェア要求をマップするのは不合理
なことではない。例えば、（Ｔ６｛（Ｒ４，Ｒ５）−＞
（ＪＫＬ，ＤＲＡＭｓ）｝ＨＷ要求限界からの制約

【００９４】しかしながら、システムが６０００アイテ
ム／秒の処理を行う要求Ｒ６は考慮しなければならな
い。単にＴＡＢ定義表からマップするために、最高レベ
ルで人工“システム”ＳＬＡＢを導入することができ
る。しかしながら、この“スループット”ＴＡＢを低位
ＳＬＡＢへ配分するのは困難である。分析部で見られた
ように、この解に達するために平衡しなければならない
ＴＲＡＭ間に多くの微妙なリンクがあるため、この“分
散された配分可能”（Ｒ６）は“全体画像”がまだ存在
しないことを示す。これらのＴＲＡＭのドキュメンテー
ションはＭＯＲＴＡＲ内に提供され、この場合Ｒ６を受
取るのに適切なのはＭＯＲＴＡＲである。各ＭＯＲＴＡ
ＲはＩＬＭＡに所属してそのインプリメンテーション構
造内でユニークなＴＲＡＭセットを反映しなければなら
ない。

【００９５】ＭＯＲＴＡＲの核はＴＲＡＭ関係のマトリ
クスである。マトリクスはＭＯＲＴＡＲにより記述され
るセット内の全ＴＲＡＭで構成され、それに対してマッ
プされている。従って、１組“ｎ”個のＴＲＡＭに対し
て、ＭＯＲＴＡＲマトリクスは“ｎ”דｎ”であり、
“ｎ”平方要素を含む。マトリクスの適切な要素内でリ
レーショナルマッピングが行われる。このようなマトリ
クスは（冗長情報を含む）その対角線に沿ってミラー構
成とされるため、対角線及び残りの三角領域の一つを指
定するだけでよい。慣例により、下部三角領域はＭＯＲ
ＴＡＲマトリクスに対して充填される。ＭＯＲＴＡＲは
設計者に対して図１７に示すスプレッドシート状で表わ
される。

【００９６】ＭＯＲＴＡＲマトリクスは設計者が選定す
る１組のＴＲＡＭに適用可能な全相互従属制を簡潔に示
す。ソートＳＷ（Ｔ１）に対しては、Ｊ９３の選択がＪ
ＫＬマイクロプロセッサに結びついていることを示し、
２Ｍ（メガ）メモリが必要とされ、０．８１ＭＩＰＳの
処理を可能とするＪＫＬマイクロプロセッサ（Ｔ４）は
３．５ＭＩＰＳを有し、二対を使用して１．９２ｋｇ
（６７．８オンス）の重量及び７００ｍＡの消費電力と
なる。同様に、７個の１Ｍ ＤＲＡＭ（Ｔ５）が必要と
され、重量及び消費電力の寄与がリストされる。ここ
で、Ｒ６はこのＭＯＲＴＡＲに直結することができる。
このＭＯＲＴＡＲを支援するテキスト断片は相互依存性
を説明し、考慮する代替策の詳細及び選択されない理由
を記録する。

【００９７】変更を考える場合は常にＭＯＲＴＡＲマト
リクスが採用される。任意の関連ＴＲＡＭに対して行列
を走査することにより、全ての相互依存性を協同インパ
クトに対してチェックすることができる。例えば、誰か
が新しい高速相関ソフトウェアルーチンを提案すれば、
Ｔ３コラムにより考慮すべき適切な疑問が次のように示
される。 １．基本Ｒ６要求に対して実行するのにどれだけのＭＩ
ＰＳが必要か。 ２．ＪＫＬプロセッサでランするか。 ３．どれだけのメモリを要するか。 前のＴＲＡＭ（Ｔ１＆Ｔ２）はＴ３（ヌルエントリ）へ
直接依存することがないため、Ｔ３行を走査してもこれ
以上の質問は発生しない。

【００９８】これら全ての質問に答えることにより、新
しいソフトウェアを導入することによる全体インパクト
の正しい分析を行うことができる。新しいソフトウェア
が必要とするＭＩＰＳが少く、ＪＫＬでランし、遙かに
多くのメモリを必要としなければＳ７１と置換する非常
に面白い候補となる。

【００９９】ＴＲＡＭ間の全ての依存性を示す他に、Ｍ
ＯＲＴＡＲはさまざまなセルに対して行列及びマトリク
ス演算を実施することができる。例えば、ＴＲＡＭ Ｔ
１、Ｔ２、Ｔ３に従って必要なＭＩＰＳに対して計算を
行うセルは、セルＴ１−Ｔ１、Ｔ２−Ｔ２、Ｔ３−Ｔ３
の和を計算して実現することができる。総重量セルはＴ
６−Ｔ４、Ｔ６−Ｔ５セルに指定された重量を加えて得
ることができる。これらのセルは従来のスプレッドシー
ト技術を使用して加えることができる。

【０１００】ＭＯＲＴＡＲにより設計変更インパクトの
分析が容易になることを理解する観点から一層興味のあ
ることは、実質的にＭＩＰＳ及びメモリは少くなるがＪ
ＫＬでランできない新しいソフトウェアの可能性がある
ことである。このシナリオにより設計者は強制的にマイ
クロプロセッサ（Ｔ４）の変更を考慮することになり、
ＭＯＲＴＡＲマトリクスへ送り戻されてＴ４の変更時に
どのニーズを考慮すべきかを決定する。これにより、次
のような１組の質問が発生する。 １．Ｊ９３は別のプロセッサでランするのか。 ２．Ｃ１５は別のプロセッサでランするのか。 ３．別のプロセッサはどんなＭＩＰレートでランするの
か。 ４．別のプロセッサの重量及び消費電力はどれ程か。

【０１０１】このマイクロプロセッサの変更自体はメモ
リの考慮に影響を及ぼさない。しかしながら、これらの
質問により“ドミノ的に”さらにソフトウェアの変更を
考慮することになると（Ｊ９３及び／もしくはＣ１５の
一方もしくは両方が別のプロセッサでランすることがな
いため）、Ｔ１及び／もしくはＴ２の元で適切な行列エ
ントリーから次レベルの質問が発生する時にメモリの考
慮は分析プロセスへ再入する。

【０１０２】最後に、新しい４Ｍ ＤＲＡＭが利用可能
となってＳ６４の使用を妨げた（Ｒ４及びＲ５を越え
る）元のバリアを有効に取り除く場合の潜在インパクト
について考える。 Type MIPS Weight Power Cost 4 Meg DRAM -- 6.3 oz 485 ma & 28.00 解４： Weight Power Cost Microprocessor - XYZ 4.5 oz 0.4 a $ 38.75 DRAMs - 4 Meg, Qty 4 25.2 oz 1.94 a $112.00 Software - J42, C88, & S64 この解により毎秒１５６９５＋アイテムが処理される。 得られる解 解番号 コスト 重量 電力 アイテム／秒 １ $ 63.50 69.3 oz 4.7 a 6481 ２ $ 115.94 41.1 oz 3.675a 6481 ３ $ 156.98 50.3 oz 4.575a 6923 ３Ａ $ 146.94 47.9 oz 4.31 a 6923 ４ $ 150.75 29.7 oz 2.34 a 15695

【０１０３】前記全例をＭＯＲＴＡＲ内で文書化すれ
ば、マトリクスのエントリーにより他へのインパクトを
適切に分析しなければいかなる構成要素も任意に変更す
ることはできないマイクロプロセッサ、メモリ及びソフ
トウェアルーチン間の関係が確立される。マトリクスの
エントリーはどのパラメータ値が平衡されているかを示
し（例えば、本例ではチップが占有するボード領域は制
約とはならない）、関連するパラメータだけを分析すれ
ばよい。

【０１０４】上記関係マトリクスの他に、実際に実現さ
れた数値を有するシャドーマトリクスを実現して、全シ
ステムデータベースにわたる置換のインパクトを計算
し、オーバナイトバッチ分析に対する代替構成要素のラ
イブラリを有する分析プログラムをロードアップにより
適切な代替構成要素を探索することができる。この概念
はＭＯＲＴＡＲ関係を捕捉し構成して計算分析に適切で
ある場合のみ可能である。

【０１０５】

【効果】本発明により従来技術に較べてさまざまな利点
が得られる。ＳＬＡＴＥは広範な階層レベルを処理する
ため、プロジェクト全体に対して一貫性のあるツールセ
ットを提供することができる。コンプライアンシィ、構
造及び配分可能要求は多レベルで実現されシステムエン
ジニアは問題領域を識別し且つ配分問題の解決に使用で
きる過配分領域を識別することができる。ＳＬＡＴＥに
より要求は流下しインプリメンテーション詳細は流上し
て、システム設計者はシステム全体を広範に理解するこ
とができる。インプリメンテーションが変化すると、技
術的配分可能予算の実際値の勘定を自動的に再計算する
ことができる。

【０１０６】さらに、ＳＬＡＴＥ内に設けられたＴＲＡ
Ｍ構成によりインプリメンテーション複雑性のドキュメ
ンテーションが促進される。ＴＲＡＭ間の関係はＭＯＲ
ＴＡＲ内に文書化され、提示されるインプリメンテーシ
ョン変更の複雑性を識別する手段が提供される。

【０１０７】本発明及びその利点について詳細に説明し
てきたが、特許請求の範囲に定義された本発明の精神及
び範囲から逸脱することなく、さまざまな変更、置換、
修正が可能である。

【０１０８】以上の説明に関して更に以下の項を開示す
る。 （１）コンピュータを使用したシステム設計方法におい
て、該方法は次のステップすなわち、各々がシステムの
一部を定義する第１組のオブジェクトであってオブジェ
クトは親子関係を有し一つ以上の子オブジェクトの各々
が親オブジェクトの一部を定義する前記第１組のオブジ
ェクトを発生し、前記第１組のオブジェクトに関連した
第２組の実現可能なオブジェクトを発生し、前記第１組
及び第２組間のリンクを発生し、前記リンクは前記第１
組に関連する要求と前記第２組に関連するインプリメン
テーション間の関係を記述し、前記１組のリンク間の相
互従属性マトリクスを発生することからなるシステム設
計方法。

【０１０９】（２）第１項記載の方法において、さらに
一つ以上のシステム要求を前記マトリクスへ関連ずける
ステップからなるシステム設計方法。

【０１１０】（３）第１項記載の方法において、さらに
前記マトリクスへテキストファイルと関連ずけるステッ
プからなるシステム設計方法。

【０１１１】（４）第１項記載の方法において、前記マ
トリクス発生ステップは三角マトリクスを発生するステ
ップからなるシステム設計方法。

【０１１２】（５）第１項記載の方法において、前記マ
トリクス発生ステップはマトリクスをスプレッドシート
として表示するステップを含み、各相互従属性はスプレ
ッドシートの１セルを占有するシステム設計方法。

【０１１３】（６）第１項記載の方法において、さらに
前記セルに演算を実施するステップからなるシステム設
計方法。

【０１１４】（７）第１項記載の方法において、さらに
前記マトリクスを調べて前記１組のリンク内の一つのリ
ンクを修正する効果を決定するステップからなる、シス
テム設計方法。

【０１１５】（８）コンピュータを使用したシステム設
計方法において、該方法は次のステップすなわち、各々
がシステムの一部を定義する第１組のオブジェクトであ
ってオブジェクトは親子関係を有し一つ以上の子オブジ
ェクトの各々が親オブジェクトの一部を定義する前記第
１組のオブジェクトを発生し、前記第１組のオブジェク
トに関連する第２組の実現可能オブジェクトを発生し、
前記第１組及び第２組間のリンクを発生し、前記リンク
は前記第１組に関連する要求及び前記第２組に関連する
インプリメンテーション間の関係を記述し、前記セル内
の前記１組のリンク間の相互従属性マトリクスを示す複
数の行列からなるスプレッドシートを発生し、前記セル
に対して演算を実施し、前記マトリクスを調べて前記１
組のリンク内の一つのリンクを修正する効果を決定す
る、ことからなるシステム設計方法。

【０１１６】（９）第８項記載の方法において、さらに
一つ以上のシステム要求を前記マトリクスへ関連ずける
ステップからなる、システム設計方法。

【０１１７】（１０）第８項記載の方法において、さら
に前記マトリクスへテキストファイルを関連ずけるステ
ップからなる、システム設計方法。

【０１１８】（１１）システム設計支援装置において、
該装置は各々がシステムの一部を定義する第１組のオブ
ジェクトであってオブジェクトは親子関係を有し一つ以
上の子の各々が親オブジェクトの一部を定義する前記第
１組のオブジェクト発生回路と、前記第１組のオブジェ
クトに関連する第２組の実現可能なオブジェクトを発生
する回路と、前記第１組及び第２組間のリンクを発生し
前記リンクは前記第１組に関連する要求と前記第２組に
関連するインプリメンテーション間の関係を記述する回
路と、前記１組のリンク間の相互従属性マトリクスを発
生する回路、からなるシステム設計支援装置。

【０１１９】（１２）第１１項記載の装置において、さ
らに一つ以上のシステム要求を前記マトリクスへ関連ず
ける回路からなるシステム設計支援装置。

【０１２０】（１３）第１１項記載の装置において、さ
らに前記マトリクスへテキストファイルを関連ずける回
路からなるシステム設計支援装置。

【０１２１】（１４）第１１項記載の装置において、前
記マトリクス発生回路は三角マトリクス発生回路を具備
する、システム設計支援装置。

【０１２２】（１５）第１１項記載の装置において、前
記マトリクス発生回路はマトリクスをスプレッドシート
として表示する回路を含み、各相互従属性がスプレッド
シートの１セルを占有する、システム設計支援装置。

【０１２３】（１６）第１１項記載の装置において、さ
らに前記セルに対して演算を実施する回路を具備する、
システム設計支援装置。

【０１２４】（１７）第１１項記載の装置において、さ
らに前記マトリクスを調べて前記１組のリンク内の一つ
のリンクを修正する効果を決定する回路を具備する、シ
ステム設計支援装置。

【０１２５】（１８）各々がシステムの一部を定義する
第１組のオブジェクトをユーザが発生することのできる
システム設計ツールが提供される。オブジェクトは一つ
以上の子オブジェクトの各々が親オブジェクトの一部を
定義する親子関係を有することができる。第２組の実現
可能なオブジェクトが発生され、従属性に関連する第２
組のオブジェクトの各々が選定された１組のリンク間に
発生される。

【０１２６】関連特許出願 本発明は同時出願された米国特許出願（代理人の処理番
号第ＴＩ−１５４９１号）“システム設計支援方法及び
装置”、米国特許出願（代理人の処理番号第ＴＩ−１５
４７２号）“システム設計方法及び装置”、及び米国特
許出願（代理人の処理番号第ＴＩ−１５３３４号）“配
分可能要求の追跡方法及び装置”の関連特許である。

【図面の簡単な説明】

【図１】システム工学が実施するプロジェクト機能のブ
ロック図。

【図２】代表的システム工学サイクルの詳細ブロック
図。

【図３】本発明のハードウェア実施例の斜視図。

【図４】本発明を適用する工学サイクルの抽象モデル。

【図５】システムレベル抽象ブロック（ＳＬＡＴＥ）。

【図６】要求定義の階層分解を示すユーザインターフェ
イス。

【図７】技術的配分予算の定義用途を示す図。

【図８】技術的配分予算の定義用途を示す図。

【図９】実行可能ＳＬＡＢのブロック図。

【図１０】テキスト断片及び自動文書発生を説明するた
めの図。

【図１１】テキスト断片及び自動文書発生を説明するた
めの図。

【図１２】テキスト断片及び自動文書発生を説明するた
めの図。

【図１３】テキスト断片及び自動文書発生を説明するた
めの図。

【図１４】従来のマッピング（ＴＲＡＭ）のブロック
図。

【図１５】ＴＲＡＭの共通使用を示す図。

【図１６】ＴＲＡＭの共通使用を示す図。

【図１７】局部ＴＲＡＭ及び条件（ＭＯＲＴＡＲ）のマ
ッピング処理。

【符号の説明】

１０ プロジェクト １２ 概念定義部 １４ 機能設計 １６ 詳細設計 １８ プロトタイプ ２０ 製造 ２２ 保守及び現物支援 ２４ 操作ニーズ ２６ 顧客要求 ２８ 解釈、優先順 ３０ システム要求定義 ３２ システム設計開発 ３４ システム設計レビュー ３６ 仕様 ３８ 予備設計レビュー ４０ 詳細設計 ４２ 詳細設計検証計画 ４４ クリティカル設計レビュー ４６ 製造組立 ４８ サブシステムテスト ５０ システム統合及びテスト ５２ システム現場説明 ５４ 操作分析 ５６ 操作ニーズ検証 ５８ ユーザ ６０ ワークステーション ６２ モニター ６４ キーボード ６６ マウス ６８ 機能要求定義 ７０ ＩＬＭＡ ７２ ＩＬＭＡ ７４ ＦＩＭ ７６ コンプライアンシィチェックリスト ７８ ＳＬＡＢ ８０ 上向き階層リンク ８２ 下向き階層リンク ８４ 機能リンク ８６ 機能リンク ８８ 技術配分予算（ＴＡＢ） ９０ 要求追跡可能性リンク（ＲＴＬ） ９２ 実行可能機能記述（ＦＤ） ９４ テキスト断片 ９６ 参照番号 ９８ メニューエリア １００ ビューエリア １０２ ウィンド １０４ ウィンド １０６ メッセージエリア １０８ 子ＳＬＡＢ １１０ 子ＳＬＡＢ １１２ 子ＳＬＡＢ １１４ 子ＳＬＡＢ １１６ 子ＳＬＡＢ １１８ 子ＳＬＡＢ １２０ 子ＳＬＡＢ １２２ 子ＳＬＡＢ １２４ 子ＳＬＡＢ １２６ 子ＳＬＡＢ １２８ 子ＳＬＡＢ １３０ 子ＳＬＡＢ １３２ 子ＳＬＡＢ １３４ 子ＳＬＡＢ １３６ 子ＳＬＡＢ １３８ 子ＳＬＡＢ １４０ 子ＳＬＡＢ １４２ 子ＳＬＡＢ １４４ 子ＳＬＡＢ １４６ 子ＳＬＡＢ １４８ 子ＳＬＡＢ １５０ 子ＳＬＡＢ １５２ ＴＡＢ １５４ ＴＡＢ １５６ ＴＡＢ名フィールド １５８ ＳＬＡＢ名フィールド １６０ ＴＡＢユニットフィールド １６２ ゴール値フィールド １６４ 最小フィールド １６６ 最大フィールド １６８ ＴＡＢ ＲＴＬフィールド １７０ 実際値部 １７２ フィールド １７４ フィールド １７６ フィールド １７８ フィールド １８０ フィールド １８２ フィールド １８４ フィールド １８６ フィールド １８８ フィールド １８９ ポインタ １９２ 修正テキスト断片メニュー １９４ 名称フィールド １９６ 数値識別フィールド １９８ 記述フィールド ２００ キーワードフィールド ２０２ アタッチメントフィールド ２０４ ドキュメントフィールド ２０６ 編集フィールド ２０８ メニュー ２１０ 名称フィールド ２１２ タイトルフィールド ２１４ 文書タイプフィールド ２１６ シンボル名 ２１８ 出版社名フィールド ２２０ 契約名フィールド ２２２ 顧客フィールド ２２４ 修正フィールド ２２６ 日付フィールド ２２８ 分類フィールド ２３０ ヘッダー及びフーターフィールド ２３２ 文書支援フィールド ２３４ エディタメニュー ２３６ 名称フィールド ２３８ 文書タイトルフィールド ２４０ 修正フィールド ２４２ データフィールド ２４４ 分類フィールド ２４６ 構造フィールド ２４８ 名称フィールド ２５０ テキストフィールド ２５２ ＴＲＡＭ ２５４ コントロールＳＬＡＢ ２５６ ソフトウェアＳＬＡＢ ２５８ ＴＲＡＭ ２６０ ＲＯＭ ＳＬＡＢ ２６２ 通信チャネルＳＬＡＢ ２６４ キューソフトウェア ２６６ キューハードウェア ２６８ プロトコルＳＬＡＢ ２７０ バスハードウェア ２７２ ＲＴＬ ２７４ 放射ＴＡＢ ２７６ ＴＲＡＭ

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成５年１１月５日

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】図１

【補正方法】変更

【補正内容】

【図１】

【手続補正２】

【補正対象書類名】図面

【補正対象項目名】図２

【補正方法】変更

【補正内容】

【図２】

【手続補正３】

【補正対象書類名】図面

【補正対象項目名】図４

【補正方法】変更

【補正内容】

【図４】

【手続補正４】

【補正対象書類名】図面

【補正対象項目名】図５

【補正方法】変更

【補正内容】

【図５】

【手続補正５】

【補正対象書類名】図面

【補正対象項目名】図６

【補正方法】変更

【補正内容】

【図６】

【手続補正６】

【補正対象書類名】図面

【補正対象項目名】図１０

【補正方法】変更

【補正内容】

【図１０】

【手続補正７】

【補正対象書類名】図面

【補正対象項目名】図１１

【補正方法】変更

【補正内容】

【図１１】

【手続補正８】

【補正対象書類名】図面

【補正対象項目名】図１２

【補正方法】変更

【補正内容】

【図１２】

【手続補正９】

【補正対象書類名】図面

【補正対象項目名】図１３

【補正方法】変更

【補正内容】

【図１３】

【手続補正１０】

【補正対象書類名】図面

【補正対象項目名】図１４

【補正方法】変更

【補正内容】

【図１４】

【手続補正１１】

【補正対象書類名】図面

【補正対象項目名】図１５

【補正方法】変更

【補正内容】

【図１５】

【手続補正１２】

【補正対象書類名】図面

【補正対象項目名】図１６

【補正方法】変更

【補正内容】

【図１６】

Claims (2)

【特許請求の範囲】
1. 【請求項１】 コンピュータを使用したシステム設計方
   法において、該方法は次のステップすなわち、各々がシ
   ステムの一部を定義する第１組のオブジェクトであって
   オブジェクトは親子関係を有し一つ以上の子オブジェク
   トの各々が親オブジェクトの一部を定義する前記第１組
   のオブジェクトを発生し、前記第１組のオブジェクトに
   関連した第２組の実現可能なオブジェクトを発生し、前
   記第１組及び第２組間のリンクを発生し、前記リンクは
   前記第１組に関連する要求と前記第２組に関連するイン
   プルメンテーション間の関係を記述し、前記第１組のリ
   ンク間の相互従属性マトリクスを発生する、ことからな
   るシステム設計方法。
2. 【請求項２】 システム設計支援装置において、該装置
   は各々がシステムの一部を定義する第１組のオブジェク
   トであってオブジェクトは親子関係を有し一つ以上の子
   の各々が親オブジェクトの一部を定義する前記第１組の
   オブジェクト発生回路と、前記第１組のオブジェクトに
   関連する第２組の実現可能なオブジェクトを発生する回
   路と、前記第１組及び第２組間のリンクを発生し前記リ
   ンクは前記第１組に関連する要求と前記第２組に関連す
   るインプルメンテーション間の関係を記述する回路と、
   前記１組のリンク間の相互従属性マトリクスを発生する
   回路、からなるシステム設計支援装置。