JPWO2005038647A1 - ユーザーインタフェースソフトウェア設計システム - Google Patents

Abstract

差分開発によるユーザーインタフェースソフトウェア設計開発の効率化を図るために、ルール処理手段が、未整理設計データ格納手段に格納された、個々のソフトウェア設計者により設計され蓄積されてきた未整理設計データ、および、ルール格納手段に格納された整理ルール群を読み出し、読み出した未整理設計データに整理ルール群の各整理ルールを逐次適用し、これを解析することにより、その未整理設計データに対して分割、統合等の変換を施すことにより、再利用性の良い整理済み設計データとする。

Description

この発明は、携帯電話、携帯情報端末、カーナビゲーション装置等のソフトウェアプロダクトを装備した機器において使用されるユーザーインタフェースソフトウェアの設計開発の効率化を図るためのユーザーインタフェースソフトウェア設計システムに関するものである。

携帯電話、携帯情報端末、カーナビゲーション装置等のソフトウェアプロダクト装備機器分野においては、近年、技術の進歩や前記の各機器に対するニーズのめまぐるしい変化により製品サイクルの短縮化が著しい。この状況に対処するために、新機種開発、特にソフトウェアプロダクト設計開発の効率化が要請されており、機器に装備されたソフトウェアプロダクトの重要な部分であるユーザーインタフェースソフトウェアの開発を効率化することによりソフトウェアプロダクトの開発を促進することも急務となっている。ユーザーインタフェースソフトウェア設計システムは、このような背景から、ユーザーインタフェースソフトウェアの設計開発の効率化を目的として生まれたものである。

一般に、ソフトウェア開発では、設計開発の効率化のために、過去の設計データ等の資産をできる限り再利用し、新しい機能など、従来とは異なる部分のみを新たに設計する差分開発が重要である。一方、ユーザーインタフェースソフトウェアの設計に使用する設計データは、その時々のソフトウェア設計者の裁量で作成された部分が多く、そのため、再利用には不便なものが多かった。例えば、実質的に同一の一連の画面を、複数の設計データで、定義したり、画面の一部を占める、アイコンなどのユーザーインタフェースの動きと、画面全体の切り替えとを同じ階層の画面遷移として捉えたため、画面遷移が平面的で、数が多くなり、設計データ全体の見通しが悪くなるケース等があった。このように、個々の設計者の設計思想が、統一されずに、ユーザーインタフェースソフトウェアの設計データに反映され、その結果、それらの設計データは再利用の観点が十分に検討されたものとはなっていなかったため、再利用性の良くないものが多かった。このような状況から、ソフトウェア設計者は、新しくユーザーインタフェースソフトウェアの設計開発の際、状態集合編集手段やイベント処理編集手段、属性編集手段、状態表示編集手段など、ユーザーインタフェース設計手段である各種編集手段を通じて、その都度、過去に蓄積された設計データを編集することにより必要な設計データを作成し、ユーザーインタフェースソフトウェア設計システムに入力していた（例えば、特許文献１参照。）。このような状況は、設計データの作成が極めて創造性の高い仕事で、属人性の高いものであるということにも起因している。

このように、差分開発を行う場合でも、設計データに関する限り、その作成には非常に手間のかかることが多かった。そのため、過去に蓄積された設計データ資産の再利用による効率化という差分開発の趣旨が活かされていなかった。

一方、過去の設計データが新規のユーザーインタフェースソフトウェアの開発にとって再利用性のよい形で得られない場合の対応策に、所謂リバースエンジニアリングという手法がある。これは、過去のソフトウェアのソースコードを入力・解析して、設計データを得るという手法で、そのための装置としてリバースエンジニアリング支援システムと呼ばれるものがある（例えば、特許文献２参照）。既存のリバースエンジニアリング支援システムは、ソースコードを入力としてソフトウェアの構造を解析しているが、ユーザーインタフェースソフトウェアのソースコードは、ユーザーとの相互作用によって対応を決定するイベント駆動型（即ち、イベント毎に適用する処理を決めておき、これに従って動作させる方式のこと）で記述されていることが多いので、ソースコードからそのソフトウェアの設計情報を解釈し、再利用しやすいように整理された形で設計データを得ることは困難であった。

特開２００２−２４４８４８号公報（請求項１、第３−４頁、図１） 特開平０９−１０１８８４号公報（請求項１）

このように、従来から蓄積されている設計データは、個々の設計者によって、統一された設計思想に基づかずに作成されているため、再利用性が低く、ソフトウェアの差分開発の効率化のためには、この蓄積された設計データの再利用性を改善する手段が望まれていた。

本発明のユーザーインタフェースソフトウェア設計システムは、ソフトウェアプロダクトへのイベントと、このイベントに対応する前記ソフトウェアプロダクトの画面変化情報とからなる、ユーザーインタフェースソフトウェア用設計データを、未整理設計データとして格納する未整理設計データ格納手段と、前記未整理設計データを再利用しやすい形に変換するルールを記述する整理ルールの集合体である整理ルール群を格納するルール格納手段と、前記未整理設計データ格納手段に格納された未整理設計データ及び前記ルール格納手段に格納された整理ルール群を読み出し、この読み出した未整理設計データに対して、前記読み出した整理ルール群に含まれる各整理ルールを逐次適用し、解析することにより、前記未整理設計データを整理済み設計データに変換するルール処理手段と、このルール処理手段の指示により、前記整理済み設計データを格納する整理済み設計データ格納手段とを有するものである。

上記本発明に係るユーザーインタフェースソフトウェア設計システムは、設計開発時に互いに統一された設計思想に基づかないで作成され、再利用に不便な形のままで蓄積されている未整理設計データを、再利用性のよい、整理済み設計データに変換するため、設計者の意図やユーザーインタフェースの構造の理解が容易となり、ユーザーインタフェースソフトウェア、及び、それを含むソフトウェアプロダクトの差分開発の効率化を図ることができる。

［図１］本発明の実施の形態１に係るユーザーインタフェースソフトウェア設計システム構成図
［図２］本発明の実施の形態１に係る未整理設計データから整理済み設計データへの変換手順
［図３］（ａ）本発明の実施の形態１に係る整理ルールの例１ （ｂ）本発明の実施の形態１に係る未整理設計データの例１ （ｃ）本発明の実施の形態１に係る整理済み設計データの例１
［図４］（ａ）本発明の実施の形態１に係る整理ルールの例２ （ｂ）本発明の実施の形態１に係る未整理設計データの例２ （ｃ）本発明の実施の形態１に係る整理済み設計データの例２
［図５］本発明の実施の形態２に係るユーザーインタフェースソフトウェア設計システム構成図
［図６］本発明の実施の形態２に係るＳＴＥＰ３の詳細手順
［図７］（ａ）本発明の実施の形態２に係る整理ルールの例１ （ｂ）本発明の実施の形態２に係る未整理設計データの例１ （ｃ）本発明の実施の形態２に係る整理済み設計データの例１
［図８］（ａ）本発明の実施の形態２に係る整理ルールの例２ （ｂ）本発明の実施の形態２に係る未整理設計データの例２ （ｃ）本発明の実施の形態２に係る整理済み設計データの例２
［図９］本発明の実施の形態３に係るユーザーインタフェースソフトウェア設計システム構成図
［図１０］本発明の実施の形態３に係るＳＴＥＰ２以降の詳細手順
［図１１］（ａ）本発明の実施の形態３に係るメニューテンプレートの例 （ｂ）本発明の実施の形態３に係る未整理設計データの例１ （ｃ）本発明の実施の形態３に係る整理済み設計データの例１
［図１２］本発明の実施の形態３に係る他の例によるＳＴＥＰ２以降の詳細手順
［図１３］（ａ）本発明の実施の形態３に係る整理ルールの例 （ｂ）本発明の実施の形態３に係る未整理設計データの例２ （ｃ）本発明の実施の形態３に係る整理済み設計データの例２
［図１４］本発明の実施の形態５に係るユーザーインタフェースソフトウェア設計システム構成図

符号の説明

１ 設計データ格納手段、２ モデル解析手段、３ 入力情報生成手段、４ ソフトウェアプロダクト、５ モデル生成手段、６ 設計データ編集手段、７ ルール編集手段、１１０ 未整理設計データ、１２０ 整理済み設計データ、２１ ルール格納手段、２２ ルール処理手段、２１１、２１２、２１３、２１４、２１６ 整理ルール、２１５ メニューテンプレート

実施の形態１．
本願発明で対象とする、ユーザーインタフェースソフトウェアの設計開発に必要な設計データは、ソフトウェアプロダクトへの一連のイベント（様々な操作入力や状態設定等）と、そのイベント毎に切り替わる表示画面とで構成される画面系列と呼ばれる画面変化情報として定義される。この設計データは、一般ソフトウェアの設計データに比べて単純化されたデータであるという特徴を有している。本願発明は、この点に着目して、設計データを、客観的に容易に理解できる形に変換することにより、その設計データの再利用性を改善するというものである。

図１は、本発明の、実施の形態１の構成を示している。図において、未整理設計データ格納手段１１は、過去に、個々のソフトウェア設計者が、その都度作成したことにより互いに設計思想が統一されておらず、再利用しやすい形に整理されていない、未整理設計データを記憶蓄積しておく格納手段、整理済み設計データ格納手段１２は、この未整理設計データを後述する所定のルールに基づき、再利用しやすい形態に変換した、整理済み設計データを記憶蓄積しておく格納手段である。図１では、未整理設計データ格納手段１１と整理済み設計データ格納手段１２とを包含する形で設計データ格納手段１を示したが、これは、未整理設計データ格納手段１１と整理済み設計データ格納手段１２とを一体化して、その中に未整理設計データ格納手段１１と、整理済み設計データ格納手段１２とを設定してもよいことを示すものである。モデル解析手段２は、ルール格納手段２１とルール処理手段２２とを含む。ルール格納手段２１は、未整理設計データを、再利用しやすい形態である整理済み設計データに変換するための整理ルール群を格納する機能を有し、ルール処理手段２２は、上記整理ルール群をルール格納手段２１から読み出し、この整理ルール群に含まれる各整理ルールを逐次適用して、前記未整理設計データ格納手段１１から読み出した未整理設計データを解析し、階層化、統合化、分岐化、分割化等の処理を行うことにより、整理済み設計データに変換するとともに、これを整理済み設計データ格納手段１２に格納するよう指示する機能を有する。

図２は、本実施の形態１についての未整理設計データを整理済み設計データに変換する際の手順を説明する図である。以下、この図に従ってその手順を説明する。ルール処理手段２２は、ルール格納手段２１に格納されている整理ルール群を読み込み（ＳＴＥＰ１）、更に、未整理設計データ格納手段１１に格納されている未整理設計データを読み込む（ＳＴＥＰ２）。

次に、ルール処理手段２２は、整理ルール群に含まれている各整理ルールを逐次、前記読み込んだ未整理設計データに適用する。各整理ルールは、適用の「条件」と、整理ルールによる処理の内容を記載した「適用処理」とを含む。未整理設計データに、この「条件」に合致する部分があれば、「適用処理」に従って、未整理設計データに対して、例えば、階層化、統合化、分割化等の変換を施す（ＳＴＥＰ３）。ＳＴＥＰ３の処理は、全未整理設計データを対象として行われる。この処理が完了したら、ルール処理手段２２は、全ての整理ルールについてＳＴＥＰ３の処理が終了したかどうかを判断し、終了したと判断した場合（ＳＴＥＰ４／ＹＥＳ）は、上記変換後の設計データを、整理済み設計データ格納手段１２に格納するよう指示を出す（ＳＴＥＰ５）。整理済み設計データ格納手段１２はこの変換後の設計データをルール処理手段２２の指示により、整理済み設計データとして格納する（ＳＴＥＰ６）。ルール処理手段２２が、ＳＴＥＰ３の処理を終了していない整理ルールがあると判断した場合は、ルール処理手段２２は、次の整理ルールに対してＳＴＥＰ３の処理を実行する。

図３は、未整理設計データの具体例と、これに対して、ある特定の整理ルールを適用した例を示す。図３（ａ）は、前記整理ルール群に含まれる整理ルールの一例を整理ルール２１１として示している。整理ルール２１１には、そのルールの「名称」と、ルール適用の「条件」と、その条件に対する数値基準である「条件値」と、その条件が満たされた場合の未整理設計データに対する処理内容である「適用処理」が記載されている。ここで示す整理ルール２１１は、整理ルールを表形式で示した場合の例である。図３（ｂ）は未整理設計データ１１０の一例を画面系列１１１と１１２とで示している。この画面系列のうちの一部分を取り出したものを部分画面系列と呼ぶ。画面系列１１１、１１２に示す符号１１１１、１１２１はそれぞれ、画面系列１１１、１１２の部分画面系列の例を示す。図３（ｃ）は、整理済み設計データを画面系列１２１〜１２３で示したものである。整理済み設計データ１２０には通常はその他の整理済み設計データが含まれるが、画面系列１２１〜１２３は、その一部を示したものである。

次に、図２のＳＴＥＰ３の変換処理手順を、図３の例を使って説明する。まず、ルール処理手段２２は、ＳＴＥＰ１において、ルール格納手段２１から読み込んだ図３（ａ）の整理ルール２１１の「条件」に適合する未整理設計データの有無を、ＳＴＥＰ２において未整理設計データ格納手段１１から読み出した未整理設計データについて検索する。「条件」適合性の検索に際しては「条件値」を考慮する。未整理設計データである、図３（ｂ）の画面系列１１１と１１２を見ると、画面Ｅにイベントｅｆが発生して画面遷移が生じ、画面Ｆになる部分（部分画面系列１１１１と１１２１）が共通している。しかし、この共通部分が、それぞれの画面系列で独立に記述されているために、この２つの設計データは煩雑な表記となっている。ルール処理手段２２は、これらの未整理設計データに整理ルール２１１の「適用処理」に記載の”対象部分画面系列を１状態として切り出し階層化”するという処理を施して整理統合する。その結果、ルール処理手段２２は、画面ＥＦを新たに定義することで、整理済み設計データを図３（ｃ）の画面系列１２１〜１２３に示すように階層化された設計データに変換する。すなわち、この整理ルール２１１による処理は、未整理設計データの画面系列の中に、ｎ個の要素（部分画面系列を構成する画面の数のことで、この例ではｎ＝２）からなる同一の部分画面系列を有する未整理設計データがｍ回（この例ではｍ＝２）以上出現するときに、この共通の部分画面系列を画面ＥＦとして切り出し、階層化したもので、出現頻度の高い部分画面系列を一つの画面として代表化させたものである。図３は未整理設計データである画面系列２個について、その間で同一の部分画面系列がある場合の例を示したが、未整理設計データである画面系列数がもっと多い場合や、一つの未整理設計データの画面系列内に同一の部分画面系列が複数回出現する場合についても同様の処理が可能である。

このように統合化することで、ソフトウェア設計者は、例えば部分画面系列１１１１や１１２１について機能の拡張・縮小・変更等の各種処理を施す場合に、個々の部分画面系列１１１１や１１２１ごとに処理を施す必要がなくなり、整理済み設計データ１２３に示す、画面ＥＦの定義部分にのみ必要な処理を施せばすむことになり、処理が大幅に簡略化できる。条件値ｎ、ｍは、予め決められた値であるが、ソフトウェアの設計に大きく影響する点に留意して決定される。

図４は、他の整理ルールの適用例を説明する図である。図４（ａ）は、前記整理ルール群に含まれる整理ルールの他の例を整理ルール２１２として示している。この整理ルール２１２は、「名称」、「条件」および「適用処理」の欄に記載されているように、未整理設計データに対応した複数の画面系列において、各画面系列の最初からｎ個の要素からなる部分画面系列が同一の場合、この複数の画面系列を、分岐を使って統合するものである。図４（ｂ）は、未整理設計データ１１０に含まれる画面系列１１４中の最初の部分画面系列１１４１と、画面系列１１５中の最初の部分画面系列１１５１とが同一である場合を示している。この場合には、未整理設計データは、ルール処理手段２２により、整理ルール２１２に基づいて整理済み設計データ１２００に変換される。この変換された整理済み設計データ１２００は、図４（ｃ）に示すように、共通の部分画面系列１２４１（互いに同一の部分画面系列である１１４１及び１１５１と同じ。）と、そこから分岐する部分画面系列１２４２と１２４３とで表わされたものとなる。図４は未整理設計データである画面系列２個について、その間で同一の部分画面系列がある場合の例である。この種の処理には、未整理設計データである画面系列数がもっと多い場合も含めてよい。

このように統合化することで、ソフトウェア設計者は、例えば部分画面系列１１４１や１１５１について機能の拡張・縮小・変更等の処理を施す場合に、個々の部分画面系列１１４１や１１５１ごとに処理を施す必要がなくなり、整理済み設計データの部分画面系列１２４１にのみ必要な処理を施せばすむことになる。また、この例では、整理済み設計データにより分岐構造が明示される形になるため、ソフトウェア設計者は、分岐数の増減処理による機能の拡張・縮小・変更を容易に実施できるため、未整理設計データで同様な処理を施す場合に比べると処理を大幅に簡略化することが可能となり、開発の効率化を図ことができる。また、処理の簡略化により、完成したソフトウェアの信頼性も向上する。整理ルール２１２の条件値ｎは、予め決められた値であるが、ソフトウェアの設計に大きく影響する点に留意して決定される。

以上の２例に示すように、整理ルール群を格納するルール格納手段２１と、この整理ルール群の各整理ルールを、設計データ格納手段１に格納されている既存の未整理設計データに適用するルール処理手段２２とを用いることにより、既存の未整理設計データは、階層化、統合化、分岐化、分割化等の処理が施され、設計データの構造の理解が容易な形に整理された、整理済み設計データに変換される。未整理設計データをそのまま再利用する場合、ソフトウェア設計者は、ソフトウェアの機能の拡張、縮小、変更、構造変更等を実施するにあたって、そのソフトウェア構造が見えない中で、再利用したい設計データごとに、その再利用のために必要な処理を検討しなければならないことから、設計には大変な困難を伴う。しかし、上記のような整理がなされることで、ソフトウェア設計者は、他のソフトウェア設計者の設計意図を容易に理解することができ、ソフトウェア機能の拡張、縮小、変更、構造変更等に際して、蓄積された設計データの再利用が容易になる。

尚、以上の説明では、２種類の整理ルールを例示して説明したが、本実施の形態に係る発明は、これらの整理ルールに限定されるものではなく、その他の整理ルールについても同様の効果を奏することができる。また、上記整理ルールは、表形式で記述したものであったが、表形式にこだわるものではなく、「条件（条件値含む）」とその条件を満たす場合の「適用処理」が記述されていればよい。例えば、整理ルールがＩＦ−ＴＨＥＮルールやその他の形式で表現されていても上記と同様な効果を奏することができる。なお、未整理設計データ格納手段１１と整理済み設計データ格納手段１２と設計データ格納手段１との関係はすでに説明したとおり、自由な構成が可能であり、そのいずれにおいても上記と同様な効果を奏することができる。
また、以上の説明で、ルール処理手段２２は、未整理設計データに対して全整理ルールを１回しか適用していないが、これを複数回適用してもよい。複数回の適用の際は、その前の回の整理済み設計データを未整理設計データとして扱うことになる。このように整理ルールを繰り返す適用することで、設計データの整理が促進され、より再利用性の高い設計データに変換される。

実施の形態２
実施の形態２の発明は、整理ルールの「条件」を満たすために必要な十分な数の未整理設計データが蓄積されていない場合でも、未整理設計データを新たに生成補充することにより、この整理ルールの「条件」を満たす状況を作り出し、整理を進めるというものである。図５は、実施の形態２の発明の構成を示している。この構成は、実施の形態１の構成に、入力情報生成手段３と、モデル生成手段５とを付加したものである。入力情報生成手段３は、ルール処理手段２２からの指示により、イベントを生成し、差分開発の基礎とするソフトウェアプロダクト４に、このイベントを入力する。モデル生成手段５は、入力されたイベントによりソフトウェアプロダクト４に生じた表示画面の変化情報と、この入力されたイベントとを入力し、これらを合わせて画面系列とし、この画面系列をモデル設計データとする。そして、このモデル設計データを、未整理設計データの一部として未整理設計データ格納手段１１に格納する指示をする。他の構成要素は実施の形態１の場合と同じである。即ち、実施の形態１の図１に示す構成に、入力情報生成手段３と、モデル生成手段５とを付加することにより、差分開発の基礎とするソフトウェアプロダクト４を介して未整理設計データを新たに生成補充する手段が提供される。この補充により、整理ルールの「条件」を満たすだけの未整理設計データがそろえば、その整理ルールに基づく未整理設計データの整理が促進される。

本実施の形態により未整理設計データを整理済み設計データに変換する手順は、図２と図６とで示される。図２についての説明は、実施の形態１での説明と同じであるが、図２のＳＴＥＰ３については、図６の手順に従うものとする。図７は、本実施の形態を説明するための整理ルール、未整理設計データおよび整理済み設計データの具体例を示す。図７（ａ）は実施の形態１で示した整理ルールとは異なる他の例を、図７（ｂ）はこの整理ルールに対応した未整理設計データの例を、図７（ｄ）は、この整理ルールで整理した、整理済み設計データの例を示す。この例に示す処理は、図７（ａ）、（ｂ）に示すとおり、イベントｘを、任意の画面に入力するとその画面のひとつ前の画面に戻るという「戻るイベント」である。図７（ａ）に示す整理ルール２１３の「戻るイベント同定１」には、未整理設計データの一部を「戻るイベント」であると同定し、整理するための「条件」と、その条件が満たされた場合の「適用処理」の内容が記載されている。

この「条件」を満足する場合は、整理ルール２１３の「適用処理」に記載の内容に従って（この例では「戻るイベント」を使って）、未整理設計データが、整理済み設計データに変換される。このことは実施の形態１で説明したとおりである。しかし、この条件を満たさないために整理対象から除外され、未整理設計データの整理が進まないというケースもある。このようなケースをできるだけ低減するために、整理ルール「戻るイベント同定１」の後にもう一つの整理ルール「戻るイベント同定２」が置かれる。この「戻るイベント同定２」の「条件」を満たす場合は、「戻るイベント同定２」の「適用処理」に従い、設計データが補充され、補充された設計データは未整理設計データに含められる。そして、この補充された未整理設計データは、改めて「戻るイベント同定１」で再評価される。

以上の処理を図２と図６に従って説明する。図２のＳＴＥＰ１，２の処理内容は、実施の形態１の場合と同じなので、説明を省略する。すでに説明したとおり、図６は、図２のＳＴＥＰ３に該当する部分の手順を詳細に示したものである。まず、ルール処理手段２２は、図７（ａ）の整理ルール２１３に含まれる最初の整理ルール（ここでは説明の簡略化のために、ｉ＝１としておく）「戻るイベント同定１」の「条件」を未整理設計データ１１０に適用し（図６のＳＴＥＰ３１）、この「条件」を満たすかどうかの判定を行う（ＳＴＥＰ３２）。図７（ｂ）に示す未整理設計データ１１０では、該当するデータ数が２個しかなく、”３回”を要求するこの「条件」を満たさない。従って、ルール処理手段２２は、処理手順を、図２のＳＴＥＰ４に戻す。次に、ルール処理手段２２は、ｉ＝２に対応する「戻るイベント同定２」を未整理設計データ１１０に適用し（ＳＴＥＰ３１）、この整理ルールの条件を満たすかどうかの判定を行う（ＳＴＥＰ３２）。満たさなければ、再度ＳＴＥＰ４に移行し、本実施の形態に係る処理は完了し、他の整理ルールについての処理に移行する（図２のＳＴＥＰ４）。上記「戻るイベント同定２」の条件を満たす場合は、ルール処理手段２２は、処理手順を設計データを補充する過程（ＳＴＥＰ３３からＳＴＥＰ３９）に進める。

補充は、以下に説明する通り、差分開発の基礎とするソフトウェアプロダクト４にイベントを入力することにより実行される。ルール処理手段２２は、まず、補充するデータ数ｋを設定する（ＳＴＥＰ３３）。このｋの値は、「戻るイベント同定２」の「適用処理」に記載された値であるが、あらかじめ任意に決めておく性格のものである。次に、ルール処理手段２２は、データの補充が必要と判断された整理ルール、即ちこの例では「戻るイベント同定１」の「適用処理」の内容を解析することにより、１連の画面系列を設計データとして補充する際にどのような画面から始めるか、また、どのようなイベントを必要とするかについて決定する（ＳＴＥＰ３４）。最初にイベントを入力する初期画面は、どのような設計データを補充するかにより、任意の画面から始めてよいこともあるし、特定の画面から始めなければならない場合もあるからである。イベントについても同様で、特定のイベントを指定する場合もあるし、特定の画面に対して任意のイベントでよい場合もある。
「戻るイベント同定１」の場合、ルール処理手段２２は、イベントをイベントｘに固定し、初期画面を任意に設定する。なお、補充すべき設計データを取得するために、差分開発の基礎となる既知のソフトウェアプロダクト４が使用されるので、上記初期画面を設定するために必要な入力イベントは既知であり、ルール処理手段２２はこれを認識・設定することができる。

ルール処理手段２２は、このようにして設定されたイベントの発生を入力情報生成手段３に指示する（ＳＴＥＰ３４およびＳＴＥＰ３５）。入力情報生成手段３は、まず、初期画面設定用に指示されたイベントをソフトウェアプロダクト４に入力し（ＳＴＥＰ３４）、表示画面を、設定した初期画面に移行させ、その後に、さらに一画面系列の取得に必要な指示されたイベントｐ（この例では「戻るイベント」であるイベントｘ）を逐次ソフトウェアプロダクト４に入力（ＳＴＥＰ３５）する。ソフトウェアプロダクト４ではイベントｐの処理を実行することにより、表示画面が表示画面ｐに変化する（ＳＴＥＰ３６）。モデル生成手段５は、初期画面移行後に、ソフトウェアプロダクト４に入力した一連のイベント（戻るイベントの例では、イベントｘは１個だけ。）と、その結果生じたソフトウェアプロダクト４の画面変化情報とを入力する（ＳＴＥＰ３７）。ルール処理手段２２は、１画面系列の補充に必要な一連のイベントの処理が終了したかどうか（ＳＴＥＰ３８）を判定し、まだの場合は１画面系列の補充に必要な一連のイベント処理が終了するまで、ＳＴＥＰ３５からＳＴＥＰ３７の処理を繰り返させる。ルール処理手段２２は、１画面系列が得られたとの判定がなされた場合には、次に、整理ルール「戻るイベント同定２」の適用処理に規定されている補充を要するｋ個の画面系列の作成が終了したかどうかを判定する（ＳＴＥＰ３９）。終了していれば、モデル生成手段５は、入力された、一連のイベントと、対応する画面変化情報から、画面系列としての設計データをｋ個作成する（ＳＴＥＰ４０）。これをモデル設計データと呼ぶが、モデル生成手段５は、このモデル設計データを未整理設計データに補充し、未整理設計データ格納手段１１にも格納する（ＳＴＥＰ４１）。ルール処理手段２２は、この補充後の未整理設計データを整理ルール２１３の「戻るイベント同定１」の「条件」に従って再評価して整理する（ＳＴＥＰ４２）。上述の通りｋ通りの一連のイベントとそれに対応するｋ通りの表示画面データ、即ちｋ個の画面系列が生成され未整理設計データに補充されるが、「戻るイベント同定１」の「条件」を満たすだけの設計データが補充されているかどうかは不明であり、再度、「戻るイベント同定１」の「条件」を満たさないこともある。その場合、この「戻るイベント同定１」と「戻るイベント同定２」とを、何回繰り返すかは、それぞれの適用処理の中で明示することができる。図７（ｃ）は、このような補充過程を経た後、補充されたモデル設計データの例を示す。図７（ｂ）と（ｃ）の設計データをあわせて未整理設計データとして、これを整理ルール２１３「戻るイベント同定１」で再評価した結果、「イベントｘ」は「戻るイベント」であるとして、図７（ｄ）に示すような整理済み設計データに変換される。

図８は、本実施の形態を説明するための他の整理ルール、未整理設計データおよび整理済み設計データの具体例を示す。図８（ａ）は図７（ａ）で示した整理ルールとは異なる他の整理ルールの例を、図８（ｂ）はこの整理ルールに対応した未整理設計データの例を、図８（ｃ）は、図７の（ｃ）の場合と同様に、補充されたモデル生成設計データの例を、図８（ｄ）は、この整理ルールで整理した、整理済み設計データの例を示す。
図８（ａ）に示す整理ルール２１４は、整理ルール「中間画面統合１」と、この後に置かれる整理ルール「中間画面統合２」とで構成されている。「中間画面統合１」は、複数の画面系列において中間の画面が同一で、且つ当該画面までの部分画面系列（若しくは履歴）にかかわらず、当該画面でのイベントのみに依存して遷移先が決まる場合、そのような画面系列数がｎ以上あれば、それを統合するという内容である。また、「中間画面統合２」は上記画面系列数がｎに満たなくてもｍ以上であれば、この「中間画面統合２」の「適用処理」に従がって処理する、即ち、設計データの補充を行い「中間画面統合１」に戻り再評価するという内容である。この例の未整理設計データから整理済み設計データへの変換処理は、以下のように実行される。なお、図２、図６で説明した処理の手順はこの例においても同じなので、以下では図２、図６の各ＳＴＥＰとの照合は省略する。

この例の未整理設計データは、図８（ｂ）に示すように２つの未整理設計データである画面系列１１８、１１９を有している。両画面系列とも画面Ｘを有し、その直後の画面は、この画面Ｘに到る部分画面系列（即ち履歴）に依らず、この画面Ｘに対するイベントのみによって決定されている。即ち、イベント発生後の画面は、そのイベントがイベントｘｂであれば画面Ｂに、イベントｘｄであれば画面Ｄに遷移する。ルール処理手段２２は、この未整理設計データに対して、整理ルール「中間画面統合１」を適用して、整理を試みる。この「中間画面統合１」の例では「条件値」はｎ＝４に設定されており、「中間画面統合１」の「条件」は、未整理設計データ１１８，１１９の２例だけでは満たされない。従って、ルール処理手段２２は、未整理設計データ１１８と１１９とを統合して整理することは出来ないと判断し、次に、整理ルール「中間画面統合２」による評価に移行する。「中間画面統合２」の「条件値」は、この例ではｍ＝２なので、未整理設計データが１１８，１１９の２例だけでも、この「条件」は満たされる。そこで、ルール処理手段２２は、不足する設計データを未整理設計データの一部として補充するための処理に移行する。補充手順は、図７の説明で述べたとおりで、モデル生成手段５で生成されたモデル設計データが、図８（ｃ）の画面系列５１２、５１３である。モデル生成手段５は、これらを未整理設計データ１１０に加え、ルール処理手段２２は、この補充後の未整理設計データについて、整理ルール「中間画面統合１」による再評価を行う。このケースでは「条件」に対応する画面系列の数が当初の２から４に増加し、「条件」が満たされることになるので、ルール処理手段２２は、補充後の未整理設計データに対して「中間画面統合１」の「適用処理」の欄に記載された処理を実行し、その結果、未整理設計データ１１８、１１９は図８（ｃ）に示す２つのモデル生成設計データ５１２、５１３の補充を受け、図８（ｄ）に示す通り、一つの整理済み設計データ１２８に変換される。

以上の２例に示すように、ルール処理手段２２は、設計データ格納手段１に格納されている未整理設計データだけでは、データ数の点で条件を満足できず、十分な整理ができない場合に、不足する未整理設計データの生成指示を入力情報生成手段３に対して行う。この指示を受けた入力情報生成手段３は、イベントを生成し、ソフトウェアプロダクト４に対して、このイベントを入力する。モデル生成手段５は、ソフトウェアプロダクト４に入力されたイベントと、この入力によりソフトウェアプロダクト４において生じた画面変化とからモデル設計データを生成し、これを未整理設計データの一部として補充するとともに、未整理設計データ格納手段１１に格納する。ルール処理手段２２は、この補充後の未整理設計データに対して、実施の形態１で説明した処理と同様の処理を行い、整理済み設計データに変換する。このような整理がなされることで、設計データの不足により整理ができなかった設計データも整理が可能となり、より再利用しやすい形の設計データを得ることができる。この様に、本実施の形態に依れば、より広範なケースに対して実施の形態１の効果と同様の効果が期待できる。

本実施の形態に依れば、以上の効果に加え、ユーザーインタフェースソフトウェア設計システムを初めて利用する場合においても、一定の効果が期待できる。すなわち、未整理設計データ格納手段１１に未整理設計データ１が蓄積されていなかった場合でも、差分開発の基礎となるソフトウェアプロダクト４を介して上述した過程によりモデル設計データを容易に生成することができ、これを過去の蓄積された未整理設計データとみなして整理済み設計データへの変換を行うことができる。従がって、ユーザーインタフェースソフトウェア設計システムの使用初期の段階から、設計開発の効率化が可能となる。なお、本実施の形態は、ここで例示した整理ルールに限定されるものではなく、他の整理ルールについても、同様に適用できるものであり、上述同様の効果を奏する。

尚、以上の説明では、２種類の整理ルールを例示して説明したが、本実施の形態に係る発明は、これらの整理ルールに限定されるものではなく、その他の整理ルールについても同様の効果を奏することができる。また、上記整理ルールは、表形式で記述したものであったが、表形式にこだわるものではなく、「条件（条件値含む）」とその条件を満たす場合の「適用処理」が記述されていればよい。例えば、整理ルールがＩＦ−ＴＨＥＮルールやその他の形式で表現されていても上記と同様な効果を奏することができる。なお、未整理設計データ格納手段１１と整理済み設計データ格納手段１２と設計データ格納手段１との関係はすでに説明したとおり、自由な構成が可能であり、そのいずれにおいても上記と同様な効果を奏することができる。
また、実施の形態１での説明と同様に、ルール処理手段２２は、未整理設計データに対して全整理ルールを複数回適用してもよい。複数回の適用の際は、その前の回の整理済み設計データを未整理設計データとして扱うことになる。このように整理ルールを繰り返し適用することで、設計データの整理が促進され、より再利用性の高い設計データに変換される。

実施の形態３
図９は、本発明の実施の形態３の構成を示している。この構成は、実施の形態１の構成に設計データ編集手段６を加えたものである。設計データ編集手段６は、未整理設計データ格納手段１１に格納されている未整理設計データを編集する手段である。ソフトウェア設計者は、この設計データ編集手段６を使い、特定の未整理設計データ１１０に対して、これまで説明してきた整理ルールとは別枠で予め設定されているルールテンプレートという整理ルールを優先適用することを指定できる。このルールテンプレートは、ルール格納手段２１に、これまで説明してきた整理ルールとは別に格納されている。複数のルールテンプレートもありうるので、上記設計データ編集手段６での指定には、対象とする未整理設計データの指定と共に、優先適用するルールテンプレートの名称（又は番号、符号等の識別子。以下、名称と略称する。）の指定も含めることができる。例えば、未整理設計データの個々の設計データ毎に、優先適用記載欄が設けられ、ソフトウェア設計者は、予め、その欄に優先適用するルールテンプレートの名称等を入力する。

ルールテンプレートの優先適用は、例えば、未整理設計データの画面系列内で、特定の部分画面系列が特定の形状でその前後とつながりがあることが予めわかっている場合等に必要となる。そのような未整理設計データに対しては、ルール格納手段２１に格納されている整理ルールを機械的に適用させるのではなく、前記特定の形状を有する部分画像系列に応じた「ルールテンプレート」を適用するほうが設計意図を良く表すことができる場合があるからである。

図１０は本実施の形態に係る処理を示すもので、この処理は、図２のＳＴＥＰ２とＳＴＥＰ３の間に挿入される。また、図１１は、本実施の形態の説明に使用する具体例を示す。図１１（ａ）はルールテンプレートの具体例であるメニューテンプレート２１５を示す。その内容は、図１１（ａ）の表に記載された通りである。図１１（ｂ）は未整理設計データ１１００、図１１（ｃ）はメニューテンプレート２１５に従って未整理設計データ１１０を整理した後の整理済み設計データを示す。ここで、ソフトウェア設計者は、図１１（ｂ）の未整理設計データ１１００に含まれる画面Ａが、メニュー画面である可能性を認識しているものとする。従って、ソフトウェア設計者は、設計データ編集手段６を使い、あらかじめ、この未整理設計データ１１００の優先適用記載欄に優先適用するルールテンプレートの名称として、メニューテンプレート２１５の名称を記載しているものとする。以下、図１０、図１１に従って、ルール処理手段２２による未整理設計データの処理手順を説明する。処理は、図２のＳＴＥＰ１から開始されるが、ＳＴＥＰ２までは実施の形態１の場合と同じなので、ここでは説明を省略する。ＳＴＥＰ２の後、ルール処理手段２２は、未整理設計データに優先適用のルールテンプレートの指定があるかどうかを判定する（ＳＴＥＰ２１）。指定がなければ、図２のＳＴＥＰ３に戻り、指定があれば、その未整理設計データに対して指定されたルールテンプレート（本例ではメニューテンプレート２１５）での処理を実施する（ＳＴＥＰ２１）。図１１の例では、未整理設計データ１１００には指定があるので、ＳＴＥＰ２２での処理の対象となる。

以下、ＳＴＥＰ２２の処理内容を詳細に説明する。図１１（ａ）に示すメニューテンプレート２１５には、”分岐先の階層化”という「適用処理」とその適用のための「条件」が、記載されている。ルール処理手段２２は、メニューテンプレート２１５に示されている「条件」に従って、画面系列１１００を解析し、ある画面Ａに分岐がｎ以上ある場合に、その画面Ａはメニュー画面と判断する。この例では、画面Ａは部分画面系列１１０１から１１０３に分岐しているので、ｎ＝３となり、図１１（ａ）の「条件値」を満たす。そこで、画面Ａはメニュー画面であると見なされ、未整理設計データ１１００に対して、図１１（ａ）の「適用処理」に従って、”分岐先の階層化”処理が実行される。その結果、未整理設計データ１１００は、図１１（ｃ）に示す４個の階層化された整理済み設計データ１２００から１２０３に変換される。

次に、本実施の形態のバリエーションについて説明する。ここでは、ソフトウェア設計者は、設計データ編集手段６を使い、特定の未整理設計データに対して、予め、整理ルール”非適用”の指定を行う。指定された設計データ、即ち画面系列は、整理ルール適用対象から除外される。この指定による処理は、すでにある程度整理されている設計データを再度整理する場合などに必要とされることが多い。
図２のＳＴＥＰ３に移行する前に、図１２に示すとおり、非適用指定の有無を判断するＳＴＥＰ２３が挿入されており、未整理設計データに対して、指定がなければ実施の形態１と同様の処理を、指定があれば、図２のＳＴＥＰ４に移行し、整理ルールの適用を行わないこととする。この非適用指定欄は独立して設けることもできるが、図１０、図１１で説明した整理ルール優先適用の指定欄と共用することもできる。

なお、整理済み設計データに対して、再度別な観点からの整理を行いたい場合にも、この機能を使うことができる。具体的には、既に一定の整理が進み、これ以上の整理を望まない設計データに対して、ソフトウェア設計者は、設計データ編集手段６を使って、整理適用除外（非適用）を指定する。そうすると、ルール処理手段２２は、この非適用指定された設計データも含む、一定の整理が進んだ設計データ全てを、未整理設計データとして未整理設計データ格納手段へ格納指示をするとともに、この未整理設計データに対して、再度整理ルールを適用して整理を行う。

具体例を図１３に示す。図１３（ａ）の整理ルール２１６は、通常の未整理設計データに対して適用すべき整理ルールの例、図１３（ｂ）は未整理設計データ、図１３（ｃ）は整理済み設計データを示す。ここで、未整理設計データ１１０４は、非適用を指定されているものとする。ルール処理手段２２は、未整理設計データ１１０４に対しては整理ルール２１６の適用を除外し、整理ルール２１６による解析、処理を一切行わない。しかし、非適用指定のない、他の未整理設計データ、たとえば画面系列１１０５に対しては解析・変換を実行し、１３（ｃ）に示す画面系列１２０５のように変換する。即ち、画面系列１１０５は、既にある程度整理が進んだ設計データである既存の画面系列１１０４と同じ部分画面系列を含んでいるので、当該部分画面系列については、この既存の画面系列を呼び出す形で置き換え処理される。このように置き換え処理を施すためには、置き換えのベースとなる画面系列が変換されて変質してしまわないように保存しておく必要がある。そのため、予め、この画面系列である設計データに”非適用”指定がなされる。

このように設計データ編集手段６の導入により、ソフトウェア設計者は、整理ルールの機械的な適用による解析、変換のみでなく、個々の設計データの状況に対応して設計者の意図を反映した形での設計データの整理を行うことができるので、より再利用しやすい設計データの構築が可能となる。なお、以上の例では、ルールテンプレートの優先適用を指定する手段、及び、整理ルールの適用除外を指定する手段として、設計データ編集手段６が利用されているが、実質的に設計データに上記の指定ができる手段であれば「編集手段」でなくてもよく、本実施の形態同様の効果を奏することができる。また、この実施の形態では設計データ編集手段６を実施の形態１の図１に示すシステムに付加した例を示したが、実施の形態２の図５に示すシステムに付加した場合でもこの実施の形態で説明した効果と同様の効果を奏することができる。

尚、本実施の形態に係る発明は、例示した整理ルールに限定されるものではなく、その他の整理ルールについても同様の効果を奏することができる。また、上記整理ルールは、表形式で記述したものであったが、表形式にこだわるものではなく、「条件（条件値含む）」とその条件を満たす場合の「適用処理」が記述されていればよい。例えば、整理ルールがＩＦ−ＴＨＥＮルールやその他の形式で表現されていても上記と同様な効果を奏することができる。なお、未整理設計データ格納手段１１と整理済み設計データ格納手段１２と設計データ格納手段１との関係はすでに説明したとおり、自由な構成が可能であり、そのいずれにおいても上記と同様な効果を奏することができる。
また、実施の形態１での説明と同様に、ルール処理手段２２は、未整理設計データに対して全整理ルールを複数回適用してもよい。複数回の適用の際は、その前の回の整理済み設計データを未整理設計データとして扱うことになる。このように整理ルールを繰り返し適用することで、設計データの整理が促進され、より再利用性の高い設計データに変換される。

実施の形態４
実施の形態４は、これまで説明してきた各実施の形態のいずれかにルール編集手段７を加えたものである。ルール編集手段７によれば、ソフトウェア設計者は、ルール格納手段２１に格納された整理ルールやテンプレートの追加、削除、変更等を行うことが可能となるとともに、ルールの適用順序も変更することができる。この様な手段を設けることにより、整理ルール群の充実化や、ルール適用処理の適正化が可能となり、そのことにより、ソフトウェア設計者は、より効果的に設計データの整理を行うことができる。これにより、設計意図の理解が容易な形に整理された、より再利用しやすい設計データの構築が可能となる。なお、図１４は、本発明の実施の形態４の構成を、実施の形態１から３までの全ての要素を含めた場合について示したものである。

この発明は、携帯電話、携帯情報端末、カーナビゲーション装置等のソフトウェアプロダクト装備機器分野におけるソフトウェアの一部であるユーザインタフェースソフトウェアの設計開発に利用される。

Claims (8)

1. ソフトウェアプロダクトへのイベントと、このイベントに対応する前記ソフトウェアプロダクトの画面変化情報とからなる、ユーザーインタフェースソフトウェア用設計データを、未整理設計データとして格納する未整理設計データ格納手段と、前記未整理設計データを再利用しやすい形に変換するルールを記述する整理ルールの集合体である整理ルール群を格納するルール格納手段と、前記未整理設計データ格納手段に格納された未整理設計データ及び前記ルール格納手段に格納された整理ルール群を読み出し、この読み出した未整理設計データに対して、前記読み出した整理ルール群に含まれる各整理ルールを逐次適用し、解析することにより、前記未整理設計データを整理済み設計データに変換するルール処理手段と、このルール処理手段の指示により、前記整理済み設計データを格納する整理済み設計データ格納手段とを有するユーザーインタフェースソフトウェア設計システム。
2. ルール処理手段の指示により、整理済み設計データを未整理設計データに置き換え、この未整理設計データに対して、整理ルール群に含まれる整理ルールを再度逐次適用し、解析することにより、整理済み設計データに変換することを特徴とする請求項１に記載のユーザーインタフェースソフトウェア設計システム。
3. 差分開発の基礎とするソフトウェアプロダクトへのイベントを生成し、当該ソフトウェアプロダクトに入力する入力情報生成手段と、前記ソフトウェアプロダクトへ入力した前記イベント、及び、この入力したイベントに対する前記ソフトウェアプロダクトの画面変化情報を入力し、このイベントと画面変化情報とからなるデータをユーザーインタフェースソフトウェアの追加設計データとして生成するモデル生成手段とを有し、このモデル生成手段で生成された追加設計データを未整理設計データに加えることにより生成される新たな未整理設計データを、ルール処理手段により、整理済み設計データに変換することを特徴とする請求項１又は２に記載のユーザーインタフェースソフトウェア設計システム。
4. ルール処理手段が、整理ルールに基づき、未整理設計データの解析を行ない、その結果から、設計データの追加が必要と判断した場合に、必要な追加設計データの生成を入力情報生成手段に対して指示することにより、この入力情報生成手段が、ソフトウェアプロダクトへのイベントを生成し、当該ソフトウェアプロダクトに入力することを特徴とする請求項３に記載のユーザーインタフェースソフトウェア設計システム。
5. 未整理設計データの中の、特定の設計データは、予め指定された整理ルールの優先適用、および整理ルールの非適用のいずれかを指定するための指定欄を有し、この指定欄への指示を可能とする設計データ編集手段を有することを特徴とする請求項１乃至４のいずれかに記載のユーザーインタフェースソフトウェア設計システム。
6. 入力情報に基づき整理ルールを編集するルール編集手段を有することを特徴とする請求項１乃至５のいずれかに記載のユーザーインタフェース設計システム。
7. 未整理設計データ格納手段と、整理済み設計データ格納手段とを、設計データ格納手段として共用し、前記未整理設計データと前記整理済み設計データとを、それぞれ前記設計データ格納手段の異なる領域に格納することを特徴とする請求項１乃至６のいずれかに記載のユーザーインタフェースソフトウェア設計システム。
8. 未整理設計データ格納手段と、整理済み設計データ格納手段とを、設計データ格納手段として共用し、この設計データ格納手段に格納されている前記未整理設計データを、整理済み設計データで書き換えることにより、この整理済み設計データを前記設計データ格納手段に格納することを特徴する請求項１乃至６のいずれかに記載のユーザーインタフェースソフトウェア設計システム。

Images