知識ベースソフトウェアアシスタント

知識ベースソフトウェアアシスタント（KBSA）は、米国空軍が資金提供した研究プログラムでした。プログラムの目標は、人工知能の概念をコンピュータソフトウェアの設計と実装の問題に適用することでした。ソフトウェアは、超高水準言語（本質的には一階述語論理に相当）のモデルによって記述され、次に変換規則により仕様が効率的なコードに変換されます。空軍は、この方法を使用して、兵器システムやその他の指揮統制システムを制御するソフトウェアを生成できるようになることを期待していました。ソフトウェアが米国空軍の兵器システムにとってますます重要になるにつれて、ソフトウェア開発プロセスの品質と生産性を向上させることは、軍隊だけでなく、他の主要な米国産業の情報技術にも大きな利益をもたらす可能性があると認識されました。

歴史

1980年代初頭、アメリカ空軍は、航空機の故障診断といった専門的な問題の解決に人工知能技術を適用することで大きなメリットが得られることを認識しました。空軍は、人工知能と形式手法のコミュニティの研究者グループに、こうした技術をソフトウェア開発というより一般的な問題にどのように活用できるかに関する報告書の作成を委託しました。

この報告書は、ソフトウェア開発への新たなアプローチのビジョンを描いていました。従来のプロセスのように、ダイアグラムで仕様を定義し、それを手作業でコードに変換するのではなく、知識ベースソフトウェアアシスタント（KBSA）のビジョンは、非常に高水準な言語で仕様を定義し、その後、変換ルールを用いて、異機種プラットフォーム上で効率的なコードへと段階的に洗練させていくというものでした。

システムの設計と改良における各ステップは、統合リポジトリの一部として記録されます。ソフトウェア開発の成果物に加えて、プロセス、様々な定義、そして変換も、必要に応じて後で分析・再生できる形で記録されます。各ステップは、実装されたシステムの様々な非機能要件を考慮した変換となるという考えに基づいています。例えば、Adaなどの特定のプログラミング言語を使用する要件や、リアルタイムのミッションクリティカルなフォールトトレランスのためにコードを強化する要件などです。[ 1 ]

空軍は、ニューヨークのグリフィス空軍基地にあるローマ航空開発センター研究所を通じて、このビジョンのさらなる研究に資金を提供することにしました。初期の研究の大部分は、北カリフォルニアのケストレル研究所（スタンフォード大学と共同）と南カリフォルニアの情報科学研究所（ISI）（南カリフォルニア大学およびカリフォルニア大学ロサンゼルス校と共同）で実施されました。ケストレル研究所は、主に論理モデルから効率的なコードへの証明可能な正しい変換に焦点を当てていました。ISIは、主に論理形式論にマッピングでき、システムアナリストが直感的で使い慣れた形式である仕様を定義するプロセスのフロントエンドに焦点を当てていました。さらに、レイセオンは非公式な要件収集を調査するプロジェクトを実施し、ハネウェルとハーバード大学は基礎となるフレームワーク、統合、および活動の調整に取り組みました。

KBSAプログラムによって主に資金提供されたわけではないが、MITプログラマーズアプレンティスプロジェクトもKBSAと多くの点で同じ目標を持ち、同じ技術を使用していた。[ 2 ]

KBSA プログラムの後期段階 (1991 年開始) では、研究者らは中規模から大規模のソフトウェア開発問題に使用されるプロトタイプを開発した。また、この後期段階では、純粋な KBSA アプローチから、知識ベース技術を使用して既存および将来のコンピュータ支援ソフトウェアエンジニアリング(CASE) ツールを補完、拡張する方法という、より一般的な問題に重点が移った。この後期段階では、KBSA コミュニティとオブジェクト指向コミュニティおよびソフトウェアエンジニアリング コミュニティの間で重要な交流があった。たとえば、KBSA の概念と研究者は、国防高等研究計画局(DARPA) がスポンサーとなったメガプログラミングおよびユーザー中心のソフトウェアエンジニアリング プログラムで重要な役割を果たした。[ 3 ] この後期段階で、プログラムは知識ベース ソフトウェアエンジニアリング (KBSE) に名称を変更した。名称変更は研究目標が変化したことを反映したもので、完全に新しい包括的なツールでソフトウェアのライフサイクル全体を網羅するのではなく、知識ベース技術を既存のツールに徐々に取り入れていくこととなった。アンダーセン コンサルティング(最大手のシステム インテグレーターの 1 つであり、当時は独自の CASE ツールのベンダーだった) などの企業は、この後の段階でプログラムに大きな役割を果たしました。

重要な概念

変換ルール

KBSAが用いた変換規則は、従来のエキスパートシステムの規則とは異なっていました。変換規則は、現実世界の事実ではなく、仕様言語や実装言語と照合しました。規則の右辺と左辺の両方で、パターン、ワイルドカード、再帰を用いて変換を指定することができました。左辺の式は、既存の知識ベース内で検索するパターンを指定します。右辺の式は、左辺を変換する新しいパターンを指定できます。例えば、集合論的データ型をAda集合ライブラリを用いてコードに変換するといったことが可能です。[ 4 ]

変換ルールの当初の目的は、高レベルの論理仕様を、特定のハードウェアおよびソフトウェア プラットフォーム向けに適切に設計されたコードに洗練させることでした。これは、定理証明と自動プログラミングに関する初期の研究にヒントを得ました。しかし、情報科学研究所 (ISI) の研究者が進化変換の概念を開発しました。[ 5 ] 仕様をコードに変換するのではなく、進化変換は、仕様レベルでのさまざまな定型的な変更を自動化することを目的としていました。たとえば、より一般的に共有できる既存のクラスからさまざまな機能を抽出して新しいスーパークラスを開発することです。進化変換は、ソフトウェア パターン コミュニティの出現とほぼ同時に開発され、2 つのグループは概念と技術を共有しました。進化変換は、本質的には、オブジェクト指向ソフトウェア パターン コミュニティでリファクタリングとして知られているものです。 [ 6 ]

知識ベースのリポジトリ

KBSAの主要概念は、要件、仕様、変換、設計、コード、プロセスモデルなど、すべての成果物が知識ベースリポジトリ内のオブジェクトとして表現されるというものでした。KBSAの当初の報告書では、いわゆる「ワイドスペクトラム言語」について説明されています。要件は、ライフサイクル全体（要件、仕様、コード、そしてソフトウェアプロセス自体）をサポートできる知識表現フレームワークでした。知識ベースのコア表現は、特定の表現や実装をサポートするために様々なレイヤーを追加できるものの、同じフレームワークを利用することを意図していました。

これらの初期の知識ベースフレームワークは、主にISIとKestrelによって、LispおよびLispマシン環境をベースに開発されました。Kestrel環境は最終的にRefineという商用製品へと発展し、KestrelからスピンオフしたReasoning Systems Incorporatedによって開発・サポートされました。

Refine言語と環境は、ソフトウェアのリバースエンジニアリングにも適用可能であることが証明されました。リバースエンジニアリングとは、ビジネスに不可欠でありながら適切なドキュメントが欠如しているレガシーコードを、ツールを用いて分析し、より保守性の高い形式に変換することです。2000年問題への懸念が高まる中、リバースエンジニアリングは多くの米国大企業にとって大きなビジネス上の懸念事項となり、1990年代にはKBSAの研究の焦点となりました。[ 7 ] [ 8 ]

KBSAコミュニティとフレーム言語およびオブジェクト指向コミュニティの間では、活発な交流が行われました。初期のKBSA知識ベースは、オブジェクト指向ではなくオブジェクトベース言語で実装されていました。オブジェクトはクラスとサブクラスとして表現されていましたが、オブジェクトにメソッドを定義することはできませんでした。アンダーセン・コンサルティングのコンセプトデモなど、KBSAの後のバージョンでは、仕様言語が拡張され、メッセージパッシングもサポートされるようになりました。

インテリジェントアシスタント

KBSAは、問題解決とユーザーとの連携方法に関して、従来のエキスパートシステムとは異なるアプローチを採用しました。従来のエキスパートシステムのアプローチでは、ユーザーは一連の対話型の質問に答え、システムが解決策を提示します。KBSAのアプローチでは、ユーザーが主導権を握っていました。エキスパートシステムが専門家の必要性をある程度排除しようとしたのに対し、KBSAのインテリジェントアシスタントアプローチは、テクノロジーを用いてプロセスを再構築することを目指しました。これにより、ユーザーインターフェースレベルで数々の革新がもたらされました。

オブジェクト指向コミュニティとKBSAの連携の一例としては、KBSAのユーザーインターフェースに使用されたアーキテクチャが挙げられます。KBSAシステムは、モデル・ビュー・コントローラ（MVC）ユーザーインターフェースを採用していました。これはSmalltalk環境から取り入れられたアイデアでした。[ 9 ] MVCアーキテクチャは、特にKBSAのユーザーインターフェースに適していました。KBSA環境は、知識ベースの複数の異種ビューを特徴としていました。エンティティとリレーション、オブジェクトの相互作用、クラス階層、データフロー、その他多くの可能なビューの観点から、出現するモデルを検討することは有用かもしれません。MVCアーキテクチャはこれを容易にしました。MVCアーキテクチャでは、基礎となるモデルは常に、仕様と実装言語のメタモデル記述である知識ベースでした。アナリストが特定のダイアグラムを介して何らかの変更（クラス階層へのクラスの追加など）を加えると、その変更は基礎となるモデルレベルで行われ、モデルのさまざまなビューがすべて自動的に更新されました。[ 10 ]

変換を使用する利点の一つは、仕様と実装の多くの側面を一度に変更できることです。小規模なプロトタイプであれば、結果として得られる図は十分に単純で、基本的なレイアウトアルゴリズムとユーザーによる図のクリーンアップを組み合わせるだけで十分でした。しかし、変換によって数十、あるいは数百のノードとリンクを持つモデルが根本的に再描画される場合、様々なビューを常に更新することはそれ自体が大きな作業となります。アンダーセン・コンサルティングの研究者は、イリノイ大学のグラフ理論に関する研究を取り入れ、知識ベースに関連付けられた様々なビューを自動的に更新し、リンクの交差が最小限に抑えられ、ドメインおよびユーザー固有のレイアウト制約も考慮されたグラフを生成しました。

インテリジェントな支援を提供するために使用されたもう1つの概念は、自動テキスト生成でした。ISIでの初期の研究では、非公式な自然言語テキスト文書から正式な仕様を抽出する実現可能性が調査されました。彼らは、このアプローチは実行不可能であると判断しました。自然言語は本質的にあまりにも曖昧であるため、システムを定義するための適切な形式としては適していません。しかし、自然言語生成は、管理者や非技術者が読めるテキスト記述を生成する方法として実現可能と見なされました。これは特に空軍にとって魅力的でした。なぜなら、法律により、すべての契約業者はシステムをさまざまな観点から説明するさまざまなレポートを作成することを義務付けられていたからです。ISIの研究者、そして後にCogentextとAndersen Consultingの研究者は、独自の技術を使用して空軍との契約で要求される文書を生成することで、このアプローチの実現可能性を実証しました。[ 11 ]

参考文献

  1. ^ Green, Cordell; D. Luckham; R. Balzer; T. Cheatham; C. Rich (1983年8月). 「知識ベースソフトウェアアシスタントに関する報告書」(PDF) . Kestrel Institute ( FTP ). p. 78. 2014年1月4日閲覧。（ドキュメントを表示するには、ヘルプ:FTPを参照してください）
  2. ^ Rich, Charles; Richard C. Waters (1988年11月). 「プログラマーズ・アプレンティス・プロジェクト：研究概要」(PDF) . Computer . 21 (11): 10– 25. doi : 10.1109/2.86782 . hdl : 1721.1/6054 . S2CID 18925917. 2017年7月6日時点のオリジナル(PDF)からアーカイブ。 2013年12月26日閲覧。 
  3. ^ DeBellis, Michael; Christine Haapala (1995年2月). 「ユーザー中心のソフトウェアエンジニアリング」. IEEE Expert . 10 (1): 34– 41. doi : 10.1109/64.391959 .
  4. ^スミス、ダグ (1991). 「KIDS - 知識ベースソフトウェア開発システム」. マイケル・ローリー、ロバート・マッカートニー編. 『ソフトウェア設計の自動化』. AAAI/MIT Press. pp.  483– 514. CiteSeerX 10.1.1.54.6955 . ISBN  978-0262620802。
  5. ^ジョンソン、ルイス、MSフェザー（1991年）「進化変換を用いた仕様構築」『ソフトウェア設計の自動化』 AAAIプレス：65～ 92ページ。
  6. ^ファウラー、マーティン（1999年）『リファクタリング：既存コードの設計改善』アディソン・ウェスリー、ISBN 0201485672。
  7. ^ Boehm, Barry; Prasanta Bose (1998-08-15). 「KBSAライフサイクル評価：最終技術報告書」(PDF) .契約番号: F30602-96-C-0274 . I. USCソフトウェアエンジニアリングセンター. 2014年1月4日閲覧.このプログラムが最終目標に向かって進むにつれ、Refineベースのソフトウェアリエンジニアリングおよびテストツールなど、生産性を向上させるスピンオフが数多く生み出されました。
  8. ^ Welty, Chris. 「KBSE-93: 第8回知識ベースソフトウェアエンジニアリングカンファレンスの概要」ase-conferences.org。2012年3月17日時点のオリジナルからのアーカイブ。2014年1月4日閲覧。REFINE /COBOL Object Modeling Workbenchは、一連のリエンジニアリングツールを提供します。RefineはKBSAコンセプトデモの言語です。
  9. ^ Harris, Dave; A. Czuchry (1988). 「知識ベース要件アシスタント」. IEEE Expert . 3 (4).
  10. ^ジョンソン、ルイス、デビッド・R・ハリス、ケビン・M・ベナー、マーティン・S・フェザー（1992年10月）。「Aries：KBSAの要件／仕様ファセット」ローマ研究所最終技術報告書。RL-TR-92-248。
  11. ^マイケル・デベリス;カンス・ミリヤラ。スディン・バート。ウィリアム・C・サッソ。オーウェン・ランボー（1993年4月）。「KBSA コンセプト デモ: 最終技術レポート」。アメリカ空軍ローマ研究所技術報告書。 RL-TR-93-38 。2021 年10 月 25 日に取得。
「 https://en.wikipedia.org/w/index.php?title=Knowledge_Based_Software_Assistant&oldid=1296947124」より取得