既存システムの設計文書群からの機能モデル抽出の試み

既存システムの設計文書群からの機能モデル抽出の試み

An Approach to Extract Functional Model in System Design Documents

砂川 英一 長野 伸一

Eiichi Sunagawa, Shinichi Nagano

（株）東芝 研究開発センター

Corporate Research & Development Center, Toshiba Corp.

Abstract: In system development, it is an important issue how to reuse modules of existing systems.

However, in a situation where systems similar to each other but customized differently are required continually, reuse of the modules becomes more difficult because relations among their functions are complicated. To this problem, we aim to establish a technology for extracting a model of functional structure in design documents of the existing system and utilizing it for development of other new systems. In this paper, we introduce our trial approach to extract the model and also discuss how to use a domain ontology in that process.

1. はじめに

ハードウェア／ソフトウェアの種別を問わず、世 界各地で多くのシステムが開発され、あらゆる分野 で利用されている。結果、近年のシステム開発では、 その全てをゼロから構築することは稀であり、大抵 は既存システムの再利用が含まれる。ここで言う既 存システムには、第三者によって提供されるライブ ラリや、開発者が自ら過去に開発したシステムモジ ュールが含まれる。 第三者によるものの例として、オープンソースソ フトウェアが挙げられる。その多くは一定範囲に絞 られた機能を対象としており、汎用性が高く、より 大きなシステムに組み込まれて使われる。一方、自 身が持つ既存システムをベースとして新たなシステ ムを開発する形態の１つに派生開発がある。また、 派生開発を見越し、共通性の高い部分は再利用する ことを前提とした構成にすることで関連する類似シ ステム全体の開発効率を高める、ソフトウェアプロ ダクトライン開発（SPL 開発）と呼ばれる開発手法 も存在する。 東芝グループにおいても、発送電や水処理といっ たインフラ分野や、POS システムやエレベータとい った設備分野で多様なシステムが開発されており、 納品されるシステムの多くは既存のシステム資産を 再利用しながら構築されている。 再利用の範囲が大きく、新規開発の範囲が小さい ほど、システム開発のコスト低減が見込めるため、 既存のシステム資産を上手く再利用する手立てを整 えることは、システムベンダーにとって重要な課題 である。 しかし、共通モジュールを明確にしないまま、逐 次的に派生開発が続けられる状況や、ある段階で共 通モジュールが定義されたが、その後の環境変化に よって区分が変わってしまう状況は、通常のシステ ム開発で十分に起こり得る。そこから改めて再利用 性の高いシステム構造へとシフトさせていくために は、既に開発されたシステムモジュールが存在する ことを前提に、それらの再利用性を評価したり、そ のための知識を取集したりする必要がある。 新たなシステムをゼロから構築していく場合と異 なり、既存システムモジュールの再利用性評価は、 再利用のための要求だけでなく、既存のモジュール がそれを満たしているか、また、他の影響や制約を 受けていないかなども考慮しなければならないため、 より困難な作業となる。また、そのために必要な知 識が各開発の設計文書に散在しており、作業者が自 ら集めて繋ぎ合わせなければならない場合も考えら れる。 こうした課題の解決を目的として、本研究は相互 に関係がある一連のシステムおよびそのモジュール が持つ機能構造を表現するモデル（機能モデル）を 仕様書などの設計文書から構築し、これを新たな開 発で活用するための技術の確立を目指す。 人工知能学会研究会資料 SIG-SWO-044-01

活用のイメージを図１に示す。機能モデルは、シ ステム全体の機能構造に対応する部分と、個々の開 発内容に関係する機能構造に対応する部分とに分か れる。前者に対して後者は部分集合であるが、前者 はより抽象的であり、システムが適用業務の中で果 たす役割や、それによって満たされる要求など、シ ステムの外部を体系化したものである。一方、後者 は、より具体的で実装に近く、機能の呼び出し順序 や実行プロセス間の関係などシステムの内部を体系 化したものである。そして、機能モデルと設計仕様 書等の文書、さらにソースコードやオブジェクトコ ードなどのモジュールを相互に関連付け、辿れるよ うにする。これにより、開発者グループはシステム に対する理解を共有したり、進行中の開発案件の位 置付けを把握したり、新規モジュールを追加する際 の影響範囲を確認したり、必要な開発資産にアクセ スしたりするための知識基盤として機能モデルを活 用することで、システム全体の開発効率の向上が期 待できる。 このゴールイメージに向け、まず本報告ではシス テムの機能仕様書に注目し、この記載から機能の種 類および機能間の関係を自動的に抽出し、機能モデ ルとして構造化することを試みる。機能仕様書は一 般的な開発で広く用いられている文書であるため、 これを用いて機能モデルの抽出が可能であれば、比 較的広い範囲で効果が得られると予想できる。 以下、まず 2 章で関連する従来技術について述べ、 3 章では本研究における機能モデルを説明する。4 章では、仕様書文書からの機能モデルの抽出を試み た実験について述べ、5 章でこれに対する考察を行 う。6 章で本報告をまとめる。

2. 従来技術

システム機能の構造を扱う代表的な技術に、フィ ーチャモデルや機能分解木がある。 フィーチャモデル(Feature Model)は、フィーチャダ イアグラム(Feature Diagram)やフィーチャ木(Feature Tree)とも呼ばれ、SPL 開発において製品特性や、そ のバリエーションを体系的に表現・整理するモデリ ング手法である[1] [2] [3]。 SPL 開発は、「同種同系列のソフトウェア製品を効 率的に生産するために、共用・再利用のためのソフ トウェア資産を整備し、これに基づいて個別プロダ クトを作り出すスタイルの開発アプローチ」[4]と説 明される。SPL 開発は、共有・再利用を想定したコ ア資産の開発と、コア資産を利用した個別システム の開発から成る。その際、システムの類似点や違い を明らかにするものとして、システムを様々な特徴 （＝フィーチャ）に分解し、「必須(mandatory)」「選 択(optional)」「代替(alternative)」といった観点を導入 しながら、フィーチャ間の関係を階層状に表現した ものがフィーチャモデルである。 一方、機能分解木は、「注目する機能（目的機能） がどのように他機能（部分機能）の集合（達成方式） によって実現されるか」という達成関係の視点で、 人工物の機能を階層状に展開したものである[5]。 機能(what)と達成方式(how)を明確に分離すること により、純粋な“機能”に焦点を絞って対象を議論 することが可能である。また、機能表現で用いられ る語彙や概念はオントロジーによって管理され、そ の種類の違いが明らかになっている。その他、機能 達成における構成上の役割を表現することができ、 ただ「上位目的の達成に寄与する」という以上に、 「そもそも無いと達成され得ない」、「機能達成の効 率を維持する」など、機能間の関係の種類を詳しく 表現することも可能である。機能分解木は、主に概 念設計や理解・発想支援の目的で使われることが想 定されている。 フィーチャモデルと機能分解木は、ともにシステ ムの性質を階層的に捉えており、AND や OR に相当 する視点で要素間の関係を整理できる点も似通って いる。ただし、フィーチャモデルにおけるフィーチ ャは極めて広い概念であるのに対し、機能分解木は 人工物が稼働している最中の機能にフォーカスを当 てている。また、どちらのモデルもシステム開発の 前工程において、作業者がモデルを構築・共有して システムに対する理解を深めることで、その後の作 業における効果を期待できる。 図 1 機能モデル活用の基盤 システム全体の 機能モデル 個々の開発に対応する 機能モデル 機能仕様書_など システムモジュール 企画書、要求 定義書など

構築支援に関する技術としては、ユースケースか らのフィーチャモデル生成[6]、用いる語彙のヒント を与えて機能分解木の構築を支援する取り組み[7] などが報告されている。 本研究も、対象システムが持つ機能や、その間の 関係（特に、ある機能の実行で必要となる他の機能 が何か）に注目し、このモデル化に取り組んでいる。 しかし、本研究は、まず既存システムが持つ機能の 理解を深めることにのみ目標を絞り、この知識を新 たな開発のために活用することは将来的な課題とし ている。また、モデルの用い方として、ある程度構 築されたものが外部から与えられ、これを閲覧して 理解の土台とすることを前提としている、といった 違いがある。 また、3.1 節で述べるが、本研究におけるシステム 機能は、機能について記述してある仕様書内の部分 テキストに相当する。したがって、仕様書で明示的 に表現されなかったり、独立して表現を切り出せな い機能は対象とならない。さらに、機能間の関係の 種類についても、現時点では厳密な区別を目的とし ておらず、知識処理技術の非専門家であっても扱え るよう、比較的制約の緩い関係としている。

3. 文書からの機能モデル抽出

3.1. 機能モデル

システムの機能仕様書をもとに、システムが持つ 各機能がいつ何のために用いられるかに注目し、こ の構造をグラフネットワーク状に表現した機能モデ ルを抽出することが、本研究の目標の一つである。 このとき、グラフネットワークのノードは、システ ムの機能について述べている対象文書内の部分テキ スト（機能表現）とし、リンク（エッジ）は、機能 表現間の関係とする。 機能表現とは、システムの機能について述べてい る対象文書内の部分テキストであり、具体的には、 機能の名前や、何らかの処理の説明を含んだもので ある。ただし、厳密には機能と呼べないものであっ ても、その実行順序や目的に対する理解を深めるう えで有効な記述は、広く機能表現として扱う。一方、 実行主体が何であるかなど、上記の理解に直接寄与 しない記述しか含まれない部分は、機能表現として 扱わない。 機能表現の関係を表すものとして、本研究は以下 に述べる 3 種類のリンクを用いる。 ・同一関係：異なる機能表現が同じ機能を指して いる ・包含関係：ある機能の実行に他の機能の実行が 含まれる ・前後関係：ある機能の実行と他の機能の実行と の間に順序がある 包含関係の対象は広く、機能分解木ほど“達成” の視点に忠実でない。システム実装上の理由でサブ プロセス化されている場合や、is-a 関係に相当する ような種類展開も、ここでは区別せず扱う。 また、前後関係における順序は、細かなタイミン グを考慮しない。機能の実行プロセスには、厳密に は開始、実行中、終了などの段階があり、「どの段階 に対して前／後なのか」という情報は仕様の詳細理 解のためには重要であるが、機能間関係の大まかな 把握には影響しないものとして、区別せず扱う。

3.2. 機能モデルの例

ここで例として、POS システムモジュールの仕様 書から得られる機能モデルを説明する。

POS システムとは、販売時点管理(Point of Sales) システムのことであり、小売店舗が商品販売取引を 行うための基幹システムである。取引で必要となる 主機能には、販売商品の登録、請求額の計算、取引 内容の記録などがある。しかし、これを円滑に行う ためには、様々な周辺デバイスを制御したり、外部 システムと通信したりする必要がある。例えば、自 動釣銭機が備わっている場合、システムは請求額と 預かり額から釣銭額を計算するだけでなく、釣銭機 が持つ紙幣・貨幣の数量を正確に把握した上で、ち ょうど釣銭額と一致しかつ可能な通貨の組合せを選 び、適正に払い出す必要がある。 また、顧客がクレジットカードや電子マネーによ る支払を求めた場合は、決済処理が完了するまでカ ードが取り去られなかったことを確認したり、各電 子マネーブランドが定めるプロトコルに従って外部 システムと通信したり、決済の条件変更に従って取 引をチェック（例えば、請求額以上の金額を受け取 れず、お釣りは発生しない、など）したりする必要 がある。 その他、販売に直接寄与しないが、音を鳴らす、 機能をロック・アンロックするといった機能も必要 であり、全て組み合わせると複雑な構成のシステム となっている。 POS システムの仕様について一般に利用可能な文 書として、OPOS 技術協議会の発行する仕様書（以 下、OPOS 仕様書）がある。OPOS 協議会は、「オー プンで多様な POS 端末の実現と POS アプリケー

ション開発の生産性向上を目指した1_{」組織である。} OPOS 仕様書は、「Web サービス連携、運用管理機 能、各種デバイスとのアクセス、サーバーとの連携 など POS システムにおける完全なオープン化を実 現する仕様1_{」として、Web 上に公開されている。} OPOS 仕様書には、POS システムのモジュール単 位で、その概要、プロパティ、メソッド、イベント の仕様が記載されている。システム共通部分を除く と、ドロワー、ラインディスプレイ、ハードトータ ル、キーロック、磁気ストライプリーダなど、36 の モジュールが構成要素として挙げられている。 このうち、例えば POS プリンタに関する記載の 一括処理中、印刷操作は最初に有効性が確認さ れます。これが正当ならば、これら印刷操作は 一括処理バッファに追加されますが、まだ印刷 はされません。 という部分からは、[一括処理][印刷操作][有効性が 確認]などが機能表現として得られ、[一括処理]の中 で[印刷操作]が行われ、[印刷操作]の中で[有効性が 確認]が行われるという包含関係や、[印刷操作]の後 で[バッファに追加]が行われ、その後で[印刷]が行わ れる(可能性がある)という前後関係を読み取れる。 これを機能モデルとして構造化したものを、図 2 に 示す。

3.3. オントロジー

本節では、本研究で必要とするオントロジーや、 その利用方法について述べる。本研究は、対象とす るシステムの機能構造を表現することを目的として いるため、システム開発者が認識する機能の種別を 中心に、それを特徴づける概念の定義が必要である。 機能を特徴付ける大きな要素に、その機能が達成 する目的事象がある。これには、システム自身の振 1 https://www.microsoft.com/ja-jp/business/industry/ retailjapan.aspx#OPOS る舞いだけでなく、運用を含めた、より広い視点が 求められる。例えば POS システムの場合、それ自身 が行うのは販売情報の管理であるが、これによる販 売業務の作業効率向上、取引内容の適正化、販売戦 略に向けた情報収集などが上位の目的であり、小売 事業の運営をより良くすることが最終的な目的に含 められる。これらの概念はシステムの要求定義書や 商品企画書、ベンダーの事業戦略に関する文書など から得ることが可能である。 一方、より実装に近いレベルでは、個々の機能を 特徴付ける周辺概念として、機能の実行主体、入出 力、それらの状態を表現する属性などが考えられる。 例えば POS システムの場合、バーコードスキャナに よって、バーコードイメージ（入力）が商品コード （出力）に変換され、バックヤードサーバによって 商品コード（入力）が商品価格（出力）に変換され、 これを端末内の合計機が合わせて請求額（出力）を 算出する、という流れを表現する概念が必要である。 こうした概念は、システムの仕様書など開発時に用 いられる文書から得ることができる。 本報告はシステムの機能仕様書を対象としており、 扱う概念も実装に近い後者の範囲に位置付けられる。 機能モデルの抽出過程においては、対象となるテ キストを評価する際、用いられている表現だけでな く、背後の意味としてどのような概念が結びついて いるかを含めた評価となるよう、テキストの特徴量 を拡張するために用いる。

3.4. 機能モデル抽出のアルゴリズム

本節では、文書から機能モデルを抽出するための アルゴリズムについて概説する。モデル抽出は、以 下の手順で行う。 １． 文書からテキストを抽出する。抽出したテキス トは、章タイトルや体言止めの箇条書きなどを 除き、原則的として句点で終わる“文”を１単 位とする。 ２． １で得られた文を係り受け解析し、修飾構造を 得る。 ３． ２で得られた修飾構造のノードのうち、機能の 特定に寄与しない表現しか含まれていないノ ードを集約する。 ４． ３で得られた修飾構造の構成ノードそれぞれ を評価して特徴量を求め、機能表現であるか否 かを推定する。 ５． 機能表現と推定されたノードの組み合わせに ついて、その組合せの特徴量を求め、組合せ間 図 2 機能モデルの例 一括処理 印刷操作 有効性が 確認 バッファ に追加 印刷 ↓包含 ↓包含 → 前後 → 前後

に同一関係／包含関係／前後関係が成り立つ かを推定する。 ６． ５のうち同一関係が成り立つと推定されたも のは１つのノードとして集約する。集約された ノードと関連する包含関係／前後関係は、いず れか１つの集約前ノードと成り立っていたも のは、そのまま成立するものとする（つまり、 OR で束ねる）。 ３の処理におけるノード集約のイメージを図２に 示す。例えば、「購入」と「購入が可能である」、「登 録」と「登録を処理する」といった表現の違いは、 システム仕様を説明する上では重要であっても、機 能の存在や種類を特定する目的においては重要な違 いでない。そこで本研究は、一部のメタ機能を除き、 機能の特定に寄与しない表現は他の表現に集約させ て扱う。機能特定に寄与しない表現としては、「可能」 「処理」「する」「できる」「実行」「業務」「機能」な どを含め、33 の表現を選んだ。 図２ 修飾構造の集約イメージ 買物客の購入が可能な商品の登録を自動的に処理する機能の実行をシステムが開始します。 買物客の 購入が 可能な 商品の 登録を 処理する 機能の 実行を 開始します。 買物客の 購入が可能な 登録を処理する機能の 実行を開始します。 商品の システムが 自動的に システムが 自動的に 係り受け解析 ノードの集約 図３ 修飾構造のノードの特徴量化 買物客の 購入が可能な 登録を処理する機能の 実行を開始します。 商品の システムが 自動的に 評価対象 自身に由来 する領域 係り受け先に 由来する領域 係り受け元に 由来する領域 １つ前の文に 由来する領域 １つ後の文に 由来する領域 0,0,…,1,0,…1,0,1,…………,1,0, ………,1,0,1,0,……1,0,……… 評価対象 のノード 係り受け先 係り受け元 開始後は… １つ後の文 …します。 １つ前の文、 上位の文 (章タイトルなど) 商品 (表現) 販売品 (概念) 売買 (概念) 登録 (表現) _(表現)購入 _(表現)買物 _(概念)売買 評価対象のノードの特徴量

４の処理で用いるノード特徴量は、評価対象とな るノード自身、係り受け構造から得られる周辺ノー ド、前後の文などを対象に、そこから得られる形態 素の原型表現、品詞種類、および、形態素の表現か ら得られるオントロジー概念等を意味する、多次元 ベクトルで表現する。このとき、特徴量を得る情報 源の違いによって、ベクトル内の次元領域は区分け する。また、オントロジーの概念は、表現が一致す るものだけでなく、オントロジーで定義された関係 を辿って得られる上位概念なども含む。 評価対象とその特徴量の概要を図３に示す。例え ば、「商品の」という評価対象ノード自身に由来する 特徴量の領域では、“商品”という表現、この表現と 結びついた“販売品”という概念、ここから辿って 得られる“売買”という概念などが、このノードの 特徴に含まれる。 ５の処理においては、2 つのノードの組合せに対 する特徴量が必要である。これについては、組合せ 対象となるノードの特徴量や、それらを AND 処理 や XOR 処理して得られる新たな特徴量などを連結 して作成する。詳細は割愛する。

4. 実験

4.1. 実験概要

3.2 節で述べた OPOS 仕様書を対象として、この文 書内のテキストから機能モデルを自動抽出する実験 を行い、自動抽出の可能性の確認、および、オント ロジーで定義した概念を用いて特徴量を拡張するこ との効果を確認した。 本報告では、元テキストから機能表現となる部分 を抽出する処理を中心に述べる。

4.2. 対象データ

OPOS 仕様書から 18 のシステムモジュールを選び、 これに関する概要説明の文を人手で抽出した。得ら れたテキスト数を、表１(a)列に示す。

4.3. 実験手順

実験は、以下の手順で行った。 １． 対象のテキストを形態素解析器にかけ、得られ た形態素を用いて対象ドメインのオントロジ ーを作る。また、単一の形態素が直接指す概念 だけでなく、その合成語に相当する概念、テキ ストには表れない上位概念やコンテキストと なる概念も補い、必要に応じて関係を結ぶ。 ２． 対象のテキストを元に、マニュアルで機能モデ ルを構築する。 ３． 3.4 節で述べた内容に沿って、対象テキストか ら機能表現の候補となる表現部分と、その特徴 量を得る。また、その組合せの特徴量を得る。 ４． ２で構築したモデルを正解（教師データ）とし て、３で得た機能表現部分や組合せ間の関係を クラス分け（1:機能表現である／関係が成り立 つ、0:機能表現でない／関係が成り立たない） する。 ５． ３で得た特徴量および４で得た正解クラスを 用い、クロスバリデーションによって、機能モ デル抽出のための機械学習モデルの学習およ びテストを行い、結果の再現率・適合率を得る。 なお、3.3 節で述べた通り、３の手順における特徴 量には、オントロジーが提供する概念との関係が含 まれる。このとき、人が「機能」としてオントロジ ーで定義した概念を用いると正解を与えることに等 しくなり、自動抽出の評価を適切に行えなくなる。 そこで、形態素の表現から得られた概念が、「イベン ト」（「機能」を含む上位概念としている）に分類さ れるものであったら、その場合は対象から外すこと とした。ただし、is-a 関係以外の関係を辿って得ら れた概念に含まれる場合は、背景知識を補うものと して、そのまま用いることとした。 この概要を図４に示す。例えば「売買」という表 現がテキストに含まれている場合、これと同じラベ ルを持つ「売買」概念をオントロジーから得られる が、これはイベントに分類されるため、この概念は 含むものとみなさない。また、「商品」「登録」を合 成した「商品登録」という表現についても、そこか ら「商品登録」概念が得られるが、同様に扱う。し かし、「商品」という表現からは、これをラベルに含 む「販売品」概念が得られ、この「販売品」概念の 周辺概念として、そのコンテキストである「売買」 概念が得られる。これは、イベントの概念であるが、 表現から直接得たものでないため、特徴量に含める。 クロスバリデーションについては、2 通りの分割 を行った。1 つは得られたデータを全て混ぜたうえ で 18 分割する方法、もう 1 つはテキストが得られる 元となったモジュール間でデータを 18 分割する方 法である。 機能モデル抽出のための機械学習モデルには、オ ートエンコーダ付きの多層パーセプトロンを用いた。 エンコーダは 3 層で中間層は 128 チャネル、出力層 は 512 チャネルとした。また、判定そのもののニュ

ーラルネットワークは 4 層で、中間層 256 チャネル、 出力層は 2 チャネルとした。活性化関数には正規化 線形関数を用いた。 オントロジーの構築には、「法造」[8]を用いた。 また、データ処理全体のアルゴリズムは、Python で 実装した。教師データとなる機能モデルの構築では、 Django2を用いた Python ベースの Web ブラウザアプ リケーションを試作して用い、機械学習部分には Chainer3を用いた。また、形態素解析および係り受け 解析には JUMAN と KNP[9]を用いた。

4.4. 実験結果

4.4.1. オントロジー 本報告で述べる実験では、他の活動で領域専門家 と共に構築した POS システムのオントロジーを用い た。その概念階層の一部を、図５に示す。概念数は 587、ラベル（語彙）数 749、is-a 関係を含む関係数 は 675 である。 4.4.2. 機能モデルの構築（教師データ） 図６、７に、OPOS 仕様書のテキストと、それに 基づいて構築した機能モデルの例を示す。図は、機 能モデル構築のために試作した Web アプリケーショ ンのスクリーンショットである。図の左側はテキス トの表示領域であり、色塗りされている部分が、機 能表現として選択された範囲である。そして、図７ 2 https://www.djangoproject.com 3 https://chainer.org 図４ 形態素に対するオントロジーの概念の紐付け … … … … … 売買取引を… … … … … … …商品登録の前に…… 機能 商品登録 売買 ・販売品 ・ 商品 製品 played-by is-a is-a is-a part-of オントロジー 形態素 テキスト … … … … 商品 登録 前 is-a is-a is-a の 商取引 OK！ NG！ イベント 他の概念 売買 NG！ 図５ POS システムオントロジーの概念階層

…

…

…

の右側は、機能表現を構造化した機能モデルの表示 領域である。赤色の線は包含関係であり、青色の線 は前後関係を意味している。また、同一関係で結ば れた表現は、同じノード内に列挙して表している。 図６は、OPOS 仕様書の POS プリンタモジュール のテキストをもとに構築した機能モデルの全体像で ある。また、図７は、この一部を拡大したものであ る。例えば、「一括処理中、印刷操作は最初に有効性 が確認されます。」というテキストから、“一括処理”、 “印刷操作”などが機能表現として選ばれているこ とや、“一括処理”中に“印刷操作”が行われること が包含関係として示されている。また、「…印刷操作 を行った後、…メソッドが呼び出されます」という 表現が、“印刷操作”と“メソッドが呼び出されます” の間の前後関係になっていることが示されている。 このように、各モジュールのテキストごとに、教 師データとなる機能モデルを構築した。結果として 得られた機能表現、これを機能単位にまとめたノー ド数、包含関係数、前後関係数を、それぞれ表１の (b)～(d)に示す。 4.4.3. 機能表現の自動抽出 図８、９に、機能表現抽出処理をクロスバリデー ションで評価した平均適合率および平均再現率を示 す。いずれの試行においても、平均適合率および平 均再現率ともに約 0.8 となった。

5. 考察

機能モデルの作成においては、比較的広い意味を カバーするものとして包含関係および前後関係とい う２種類の関係を用意したが、実際に仕様書テキス トを構造化しようとすると、関係はあるがどちらか 特定できない場合が散見された。 例えば、図７で例として示したような、「（機能 A） 中、（機能 B）」や「（機能 A）した後、（機能 B）」と いった表現パターンは、ブレが少なくモデルに反映 できる例だと言える。同様の表現パターンとして、 「（機能 A）のため（機能 B）」「（機能 A）によって （機能 B）」「（機能 A）した○○を、(機能 B)」「（機 図７ POS プリンタの仕様テキストに基づく機能モデル（一部） 図６ POS プリンタの記載から得られる 機能モデルの全体像 表１ 仕様書テキストから得られた 機能モデルの規模 モジュール _{テキスト数}(a) (b)機能_表現数 (c)機能_ノード数 (d)包含_関係数 (d)前後_関係数 ドロワー 23 21 16 5 3 ラインディスプレイ 111 57 41 64 4 ハードトータル 88 133 82 59 22 キーロック 29 14 11 0 6 磁気ストライプリーダ 137 116 91 74 18 POSプリンタ 494 104 80 30 13 スキャナ 28 37 28 12 7 POSキーボード 33 37 26 13 10 コインディスペンサ 25 26 19 8 2 秤 53 50 35 11 5 自動釣銭機 169 90 56 32 9 トーンインジケータ 118 73 53 21 10 ピンパッド 68 45 28 9 2 ポイントカード機 182 146 89 9 2 電子ジャーナル 61 59 63 18 5 紙幣入金機 40 39 33 12 4 硬貨入金機 44 47 33 7 1 電子バリューライタ 67 39 30 8 2 （合計） 1770 1133 814 392 125

能 A）するまで（機能 B）」なども挙げられる。 一方、例えば「（機能 A）して、（機能 B）」という 表現は、「機能 A の後で機能 B」とも、「機能 A する ことによって機能 B」とも取れる。これを一意に特 定するためには、仕様書テキストから直接得られる 以上のドメイン知識が必要であった。 構築される機能モデルのブレを抑制するためには、 特定できない関係は無いものとみなすようにし、関 係の意味を厳密化してモデル自体から得られる情報 を落とすか、あるいは関係の意味を「何らかの影響 がある」という程度に更に曖昧化するといった対応 が考えられる。 機能モデルの平均的な抽出性能は、全体として適 合率・再現率ともに約 0.8 となった。目標性能は適 用先によって定まるが、機能表現抽出の可能性を確 認するという目的においては、現時点では十分な値 が得られたと判断する。今後は、具体的な利用シー ンや、その適用先において細かく注目すべき機能構 造を定めて、技術開発の指標を定める。 オントロジーによる特徴量の拡張を行った場合と 行わなかった場合については、モジュール間でデー タを分割した場合に 1 つだけ明らかに適合率・再現 率ともに低い場合があったことと、ややモジュール 間でデータ分割したほうが分散が高くなる傾向があ った以外に、顕著な違いを確認できなかった。モジ ュール間でのデータ分割については、結果とサンプ ル数との相関も確認したが、オントロジーを用いな かった場合に弱い負の相関が得られた以外に、目立 った傾向は確認できなかった。この結果については、 途中で用いられたモデルのパラメータを確認のうえ、 オントロジーを参照することで得られた特徴量との 関係を精査する必要があると考える。

6. おわりに

本報告では、まず派生開発が多発する状況におい て、その対象システム系列の機能構造を表現するモ デルを用い、新たな開発のために活用することで、 開発資産の再利用性を高めるという研究目的につい て述べた。また、これを実現する基盤技術の１つと して、システム仕様書のテキストから機能モデルを 自動的に抽出する技術の紹介と、これを OPOS 仕様 書に適用した実験結果の一部を紹介した。 引き続き、システム開発業務に対する本研究の成 果の適用イメージを具体化するとともに、オントロ ジーと機能モデル抽出の処理に関する調査を深める。

7. 参考文献

[１] 野田夏子, 岸知二:プロダクトライン開発における可 変性のモデル化手法, コンピュータ ソフトウェア, Vol. 31, No. 4, pp. 66-76, (2014) [２] 「フィーチャー」の概念を取り入れたモデルベース 開発, 独立行政法人情報処理推進機構, 先進的な設 計・検証技術の適用事例報告書 2015 年度版 15-A-6, (2015)

[３] Sven Apel, Christian Kästner: An Overview of Feature-Oriented Software Development, Journal of Object Technology, Vol. 8, No. 5, pp. 49-84, (2009) [４] 情報システム用語辞典, アイティメディア株式会社. ITmedia エンタープライズ. [５] 來村徳信, 溝口理一郎: オントロジー工学に基づく 機能的知識体系化の枠組み, 人工知能学会論文誌, Vol. 17, No. 1, pp. 61-72, (2002) [６] 田原圭祐, 野田夏子: ユースケースからのフィーチ 図８ 機能表現抽出の適合率 図９ 機能表現抽出の再現率 0 0.2 0.4 0.6 0.8 1 なし あり オントロジー参照

平均適合率

0.79 0.80 0.80 0.79 全データ混合 モジュール間 0 0.2 0.4 0.6 0.8 1 なし あり

平均再現率

オントロジー参照 0.80 0.76 0.78 0.77 全データ混合 モジュール間

ャモデル導出の提案, 情報処理学会研究報告 ソフト ウェア工学 (SE), Vol. 2014, No. 3, pp. 1-8, (2014) [７] 高藤淳, 來村徳信, 溝口理一郎: オントロジー工学と XML 技術に基づく技術知識統合管理プラットフォ ームの構築, 人工知能学会論文誌, Vol. 23, No. 6, pp. 424-436, (2008) [８] 古崎晃司, 來村徳信, 池田満, 溝口理一郎: 「ロー ル」 および「関係」に関する基礎的考察に基づくオント ロジー記述環境の開発, 人工知能学会論文誌, Vol. 17, No. 3, pp. 196-208, (2002) [９] 河原大輔, 黒橋禎夫: 自動構築した大規模格フレー ムに基づく構文・格解析の統合的確率モデル, 自然言 語処理, Vol.14, No.4, pp.67-81, (2007)