(57)【要約】【課題】ソフトウェア開発者が作成したソフトウェアの品質に関する情報を、ソフトウェアの設計情報を秘匿したままで一元管理できるソフトウェア管理システムを提供する。【解決手段】プログラムの仕様をモデル記述言語で記述したアプリケーションモデルを取得するアプリケーションモデル取得手段と、前記プログラムを動作させるためのプラットフォームの仕様をモデル記述言語で記述したプラットフォームモデルを記憶するプラットフォームモデル記憶手段と、前記プラットフォームモデルと前記アプリケーションモデルとを用いて、前記アプリケーションモデルと前記プラットフォームモデルとの互換性を検証するモデル検証手段と、前記モデル検証手段による検証結果を前記ソフトウェア管理装置に出力する検証結果出力手段と、を有するソフトウェア検証装置と、前記検証結果を取得し記憶する検証結果記憶手段を有するソフトウェア管理装置と、からなることを特徴とする。【選択図】図１
2013125441.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの検証を行うソフトウェア検証装置と、
前記ソフトウェア検証装置が行った検証の結果を取得し、記憶する検証結果記憶手段を有するソフトウェア管理装置と、
からなるソフトウェア管理システムであって、
前記ソフトウェア検証装置は、
プログラムの仕様をモデル記述言語で記述したアプリケーションモデルを取得するアプリケーションモデル取得手段と、
前記プログラムを動作させるための基本ソフトもしくはハードウェアであるプラットフォームの仕様をモデル記述言語で記述したプラットフォームモデルを記憶するプラットフォームモデル記憶手段と、
前記プラットフォームモデルと前記アプリケーションモデルとを用いて、前記アプリケーションモデルと前記プラットフォームモデルとの互換性を検証するモデル検証手段と、
前記モデル検証手段による検証結果を前記ソフトウェア管理装置に出力する検証結果出力手段と、
を有する
ことを特徴とする、ソフトウェア管理システム。
【請求項２】
前記モデル検証手段は、前記プログラムがプラットフォームに対して行っているインタフェース呼び出しが、検証対象のプラットフォームモデルが有するインタフェース定義に対して適合するかを検証する
ことを特徴とする、請求項１に記載のソフトウェア管理システム。
【請求項３】
前記ソフトウェア管理装置は、検証対象のプラットフォームに対応するプラットフォームモデルを記憶する第二のプラットフォームモデル記憶手段をさらに有し、
前記ソフトウェア検証装置は、前記第二のプラットフォームモデル記憶手段からプラットフォームモデルを取得して、前記プラットフォームモデル記憶手段に格納する
ことを特徴とする、請求項１または２に記載のソフトウェア管理システム。
【請求項４】
複数の前記ソフトウェア検証装置と、単一の前記ソフトウェア管理装置と、
からなる、請求項１ないし３のいずれかに記載のソフトウェア管理システム。
【請求項５】
プログラムの仕様をモデル記述言語で記述したアプリケーションモデルを取得するアプリケーションモデル取得手段と、
前記プログラムを動作させるための基本ソフトもしくはハードウェアであるプラットフォームの仕様をモデル記述言語で記述したプラットフォームモデルを記憶するプラットフォームモデル記憶手段と、
前記プラットフォームモデルと前記アプリケーションモデルとを用いて、前記アプリケーションモデルと前記プラットフォームモデルとの互換性を検証するモデル検証手段と、
前記モデル検証手段による検証結果を外部に出力する検証結果出力手段と、
を有するソフトウェア検証装置。
【請求項６】
ソフトウェアの検証を行うソフトウェア検証装置と、
前記ソフトウェア検証装置が行った検証の結果を取得し、記憶するソフトウェア管理装置と、
が行うソフトウェア管理方法であって、
ソフトウェア検証装置が、プログラムの仕様をモデル記述言語で記述したアプリケーションモデルと、前記プログラムを動作させるための基本ソフトもしくはハードウェアであるプラットフォームの仕様をモデル記述言語で記述したプラットフォームモデルと、を用
いて、前記アプリケーションモデルと前記プラットフォームモデルとの互換性を検証し、検証を行った結果を前記ソフトウェア管理装置に出力するステップ
を含む
ことを特徴とする、ソフトウェア管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア管理システム、ソフトウェア検証装置、およびソフトウェア管理方法に関する。
【背景技術】
【０００２】
近年、携帯端末向けのオープンプラットフォーム環境によるソフトウェア開発が盛んに行われている。例えば、Ａｎｄｒｏｉｄ（登録商標）プラットフォームでは、オペレーティングシステム、ミドルウェア、ソフトウェア開発ツールなどが統合された環境が提供され、ソフトウェア開発者は、当該環境を用いることによってアプリケーションの開発を効率的に行うことができる。
【０００３】
開発されたアプリケーションは、アプリケーション配布業者を通じて利用者に配布することができる。例えば、前述のＡｎｄｒｏｉｄ（登録商標）プラットフォームにおいては、アンドロイドマーケットと呼ばれるオンラインストアを通じて、一般の利用者にアプリケーションを配布することができる。
【０００４】
一方で、このようにして作成されたソフトウェアの品質を一括して管理したいという要求がある。ソフトウェアの品質とは、開発者が意図していない不具合を含まないことや、ＯＳ（オペレーティングシステム）との互換性、セキュリティ性、処理速度などの複数の項目で表すことができる。
【０００５】
アプリケーションの品質を管理する方法としては、例えば利用者に実際にアプリケーションを使用させ、問題を発見した場合に不具合報告を送信してもらうことで品質情報を収集する方法がある。特許文献１に記載された情報収集システムによると、携帯電話用ソフトウェアの不具合や不備に関する情報を利用者から収集し、管理することができる。
【０００６】
また、アプリケーション配布業者が開発者からアプリケーションの設計情報を受け取り、テストを行ったうえで、結果を品質情報として管理するという方法が考えられる。特許文献２に記載された品質管理システムはこの形態に適用することができ、開発者側から管理装置側へソースコードをはじめとするアプリケーションの設計情報を送信することにより、管理装置側で品質情報を一元管理することが可能である。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−１２７４５０号公報
【特許文献２】特開２０１０−３３４４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１に記載の発明は、利用者が実際に使用したアプリケーションの不具合情報を収集するための発明であるため、公開前のアプリケーションに対する品質の判定には用いることができないという問題がある。また、管理される情報はエンドユーザが不具合であると判断したもののみであり、特定のルールに沿って検証されたものではないため、収集される情報に偏りが生じるおそれがある。
【０００９】
特許文献２に記載の発明では上記の問題を解決することができるが、当該発明は会社な
ど組織の内部で作成されるソフトウェアを想定した発明である。したがって、これをオープンプラットフォームなど、管理者と別の拠点で開発を行うシステムに適用した場合、開発者から管理者へソフトウェアの設計情報を送信しなければならないため、知的財産の保護が難しくなるという別の問題がある。
【００１０】
このように、既存の技術では、オープンプラットフォームを利用し、開発者によって開発されたアプリケーションを配布業者が管理し配布する形態において、作成されたアプリケーションの品質情報を、ソフトウェアの設計情報を秘匿したままで管理することが難しいという問題があった。
【００１１】
本発明は上記の問題点を考慮してなされたものであり、ソフトウェア開発者が作成したソフトウェアの品質に関する情報を、ソフトウェアの設計情報を秘匿したままで一元管理できるソフトウェア管理システムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明に係るソフトウェア管理システム、ソフトウェア検証装置、およびソフトウェア管理方法では、上記課題を以下の手段により解決する。
【００１３】
本発明に係るソフトウェア管理システムは、ソフトウェアの検証を行うソフトウェア検証装置と、前記ソフトウェア検証装置が行った検証の結果を取得し、記憶する検証結果記憶手段を有するソフトウェア管理装置と、からなるソフトウェア管理システムである。
また、前記ソフトウェア検証装置は、プログラムの仕様をモデル記述言語で記述したアプリケーションモデルを取得するアプリケーションモデル取得手段と、前記プログラムを動作させるための基本ソフトもしくはハードウェアであるプラットフォームの仕様をモデル記述言語で記述したプラットフォームモデルを記憶するプラットフォームモデル記憶手段と、前記プラットフォームモデルと前記アプリケーションモデルとを用いて、前記アプリケーションモデルと前記プラットフォームモデルとの互換性を検証するモデル検証手段と、前記モデル検証手段による検証結果を外部に出力する検証結果出力手段と、を有することを特徴とする。
【００１４】
モデルとは、仕様記述言語の一種であるモデル記述言語によってソフトウェアの仕様を表現したものである。アプリケーションモデルとは、作成対象のアプリケーションプログラムの仕様をモデル記述言語で表現したものであり、プラットフォームモデルとは、プログラムを動作させるための、ミドルウェアを含む基本ソフト（ＯＳ）、もしくはハードウェアの仕様をモデル記述言語で表現したものである。本発明は、これらのモデルを検証しながら開発プロセスを進めるという開発手法に適用することができる。
【００１５】
本発明に係るソフトウェア検証装置は、アプリケーションのモデルと、当該アプリケーションが動作するプラットフォームのモデルを用いて、モデル間の情報の交換に互換性があるかをチェックし、その結果を外部に出力する。このように構成することにより、開発者によって検証されたアプリケーションの詳細な検証結果、すなわち品質情報を出力することができる。また、出力されるデータには、ソフトウェアの設計に関する情報は含まれないため、アプリケーション開発に係る機密を保持することができる。
【００１６】
また、本発明に係るソフトウェア管理システムが有するソフトウェア管理装置は、前記検証結果を取得し記憶する検証結果取得手段を含む。
【００１７】
ソフトウェア検証装置によって出力された検証結果をソフトウェア管理装置が取得し、記録することで、ソフトウェア開発者によって作成されたソフトウェアの品質を一元的に管理することができる。
【００１８】
また、前記モデル検証手段は、前記プログラムがプラットフォームに対して行っているインタフェース呼び出しが、検証対象のプラットフォームが有するインタフェース定義に対して適合するかを検証してもよい。
【００１９】
モデル間の情報交換に互換性があることの確認は、基本ソフトやハードウェアが有しているＡＰＩ等のインタフェースに対する呼び出しが、アプリケーション側から正しく行われているかをモデル検証手段が検証することによって行う。検証は、アプリケーションモデルから呼び出しているインタフェースがプラットフォームモデルに存在しているか、または、アプリケーションモデルで定義されているインタフェースの型がプラットフォームモデルと整合しているかを確認すること等によって行う。このように構成することにより、ある特定のプラットフォーム上でプログラムが正常に動作することを確認することができる。
【００２０】
また、前記ソフトウェア管理装置は、検証対象のプラットフォームに対応するプラットフォームモデルを記憶する第二のプラットフォームモデル記憶手段をさらに有し、前記ソフトウェア検証装置は、前記第二のプラットフォームモデル記憶手段からプラットフォームモデルを取得して、前記プラットフォームモデル記憶手段に格納してもよい。
【００２１】
このように構成することにより、ソフトウェア検証装置は、任意のプラットフォームモデルを検証の対象としてソフトウェア管理装置から取得し、検証を行うことができる。
【００２２】
また、本発明に係るソフトウェア管理システムは、複数の前記ソフトウェア検証装置と、単一の前記ソフトウェア管理装置と、からなってもよい。
【００２３】
このように構成することにより、複数のソフトウェア検証装置が生成した検証結果を一元的に管理することができる。複数の開発者が複数の拠点で開発を行う形態に適用することができるため、オープンプラットフォームを採用した製品に好適である。
【発明の効果】
【００２４】
本発明によれば、ソフトウェア開発者が作成したソフトウェアの品質に関する情報を、ソフトウェアの設計情報を秘匿したままで一元管理できるソフトウェア管理システムを提供することができる。
【図面の簡単な説明】
【００２５】
【図１】第一の実施形態におけるシステム構成を表す図である。
【図２】開発環境におけるコンポーネント構成を説明する図である。
【図３】アプリケーションとプラットフォーム、ハードウェアの関係を説明する図である。
【図４】ソフトウェア作成装置を利用したソフトウェア開発手順を表すフローチャート図である。
【図５】ソフトウェア作成装置から伝送される検証結果の例を表した図である。
【発明を実施するための形態】
【００２６】
（第一の実施形態）
<システム構成>
本発明の第一の実施形態に係るソフトウェア検証装置は、検証機能と共に開発機能を有するソフトウェア作成装置として実装される。第一の実施形態に係るソフトウェア作成装置、およびソフトウェア管理装置について、図を用いて詳細な説明を行う。図１は、本実施形態におけるソフトウェア作成装置およびソフトウェア管理装置のシステム構成を表し
た図である。
【００２７】
ソフトウェア作成装置１００は、アプリケーションの開発に用いられるコンピュータであり、中央演算処理装置（ＣＰＵ）および主記憶装置（ＲＡＭ）、補助記憶装置（記憶媒体）等にて構成される。ソフトウェア作成装置１００は、モデル作成部１０１、プラットフォームモデル記憶部１０２ａ、アプリケーションモデル記憶部１０２ｂ、モデルチェック部１０３、検証結果出力部１０４、プログラム生成部１０５を含んでおり、補助記憶装置に記憶されたプログラムコードをＣＰＵが読み出して実行することにより、前記各部の機能が実現される。
【００２８】
また、ソフトウェア管理装置２００は、アプリケーション配布業者（以降、アプリケーションプロバイダと称する）が有しており、アプリケーションの管理に用いられるコンピュータである。ソフトウェア管理装置２００は、検証結果入力部２０１、検証結果記憶部２０２、品質情報検索部２０３、アプリケーションプログラム記憶部２０４、プラットフォームモデル管理部２０５から構成される。
【００２９】
まず、ソフトウェア作成装置１００について説明を行う。モデル作成部１０１は、開発対象となるアプリケーションをモデルで表したアプリケーションモデルを作成するための手段である。アプリケーションモデルとは、アプリケーションを、ＡＡＤＬ（The SAE Architecture Analysis and Design Language）などのモデル記述言語によって表したもの
である。なお、本実施形態においては、アプリケーションモデルをソフトウェア検証装置上で作成するので、モデル作成部１０１が、本発明におけるアプリケーションモデル取得手段となる。
【００３０】
プラットフォームモデル記憶部１０２ａは、開発対象のアプリケーションが動作するプラットフォームのモデルを格納する手段であり、本発明におけるプラットフォームモデル記憶手段である。プラットフォームモデルとは、アプリケーションが動作するＯＳ、ミドルウェア、ないしは仮想化されたハードウェアを、アプリケーションモデルと同様にモデル記述言語によって表したものである。
【００３１】
アプリケーションモデル記憶部１０２ｂは、モデル作成部１０１で作成されたアプリケーションモデルを記憶する手段である。
【００３２】
モデルチェック部１０３は、プラットフォームモデル記憶部１０２ａに記憶されたプラットフォームモデルと、アプリケーションモデル記憶部１０２ｂに記憶されたアプリケーションモデルとを用いてアプリケーションの検証を行う手段であり、本発明におけるモデル検証手段である。検証の具体的な内容については後述する。
【００３３】
検証結果出力部１０４は、アプリケーションの検証結果を出力する手段である。検証結果は、たとえばＴＣＰ／ＩＰを利用してネットワーク経由でソフトウェア管理装置２００へ送信してもよいし、ファイルとして出力してもよい。ファイルとして出力した場合、検証結果は外部媒体を介してソフトウェア管理装置２００へ取り込まれる。検証結果を出力できる形式であれば、出力先の媒体はどのようなものであってもよい。出力される情報の具体的な内容については後述する。
【００３４】
プログラム生成部１０５は、作成したアプリケーションモデル１０２ｂをソースコード、もしくは実行形式のプログラムに変換する手段である。モデル記述言語で記述されたアプリケーションモデルを、コンパイラやモデルコンパイラ等によってソースコードないしは実行形式のプログラムに変換する。
【００３５】
次に、ソフトウェア管理装置２００について説明を行う。検証結果入力部２０１は、検証結果出力部１０４が出力した検証結果を取得する手段である。検証結果出力部１０４と同様に、入力元の媒体はどのようなものであってもよい。ネットワーク経由で検証結果が送信される場合、検証結果入力部２０１はたとえばＴＣＰ／ＩＰによってデータを受信し、検証結果がファイルである場合、光学ドライブなどを用いて記憶媒体より読み込みを行う。
【００３６】
検証結果記憶部２０２は、取得した検証結果を保存する手段である。ソフトウェア管理装置２００は、複数の開発者が作成した複数アプリケーションの検証結果を記録することができる。検証結果入力部２０１と検証結果記憶部２０２が、本発明における検証結果記憶手段に該当する。
【００３７】
品質情報検索部２０３は、検証結果記憶部２０２に記録された検証結果より、指定した問い合わせ要求に該当する情報を検索する手段である。指定した条件に合致するアプリケーションを検索することもでき、指定したアプリケーションの検証結果を要求することもできる。
【００３８】
アプリケーションプログラム記憶部２０４は、開発者より送付された、完成したアプリケーション本体を記憶する手段である。アプリケーションプログラム記憶部２０４に記憶されたアプリケーションが、最終的に利用者に配布される。
【００３９】
プラットフォームモデル管理部２０５は、ソフトウェア作成装置１００に対して配布する複数のプラットフォームモデルを記憶する手段である。プラットフォームモデルの配布および使用方法については後述する。
【００４０】
<アプリケーション検証の概要>
次に、アプリケーションプロバイダによって配布される開発ソフトウェアと、ソフトウェア作成装置との関係を示し、アプリケーションモデルおよびプラットフォームモデルを用いてアプリケーションを検証する方法を説明する。図２は、ソフトウェア作成装置上で動作する開発ソフトウェア、および作成されるアプリケーションを表した図である。
【００４１】
開発環境４００は、開発ソフトウェアのパッケージであり、複数のコンポーネントによって成り立つ。開発者は、開発環境４００をアプリケーションプロバイダより取得し、ソフトウェア作成装置に格納する。開発環境は、ネットワーク経由で送信されてもよいし、記憶媒体によって移動されてもよい。
【００４２】
開発基盤４０８は、例えばオープンソースで提供されているＥｃｌｉｐｓｅのような統合開発環境である。開発基盤４０８上で動作するエディタ４０５は、通常のアプリケーションモデル作成にて使用されるコンポーネントであり、既存の技術によるものである。エディタ４０５はモデル作成部１０１にて実行される。作成されたアプリケーションモデル３０１は、前述したようにアプリケーションモデル記憶部１０２ｂに格納される。
【００４３】
作成されたアプリケーションモデルは、モデルコンパイラ４０６によって、ソースコードに変換することができる。ソースコードは、コンパイラ４０７によって実行形式のプログラムに変換することができる。また、変換されたプログラムは、エミュレータ４０２によって仮想環境で実行することが可能である。モデルコンパイラ４０６、コンパイラ４０７、エミュレータ４０２、およびライブラリ４０４は、プログラム生成部１０５に格納され実行される。
【００４４】
プラットフォームモデル４０３は、プラットフォームモデル記憶部１０２ａに格納され
る。従来技術では、プラットフォームモデルは開発者に配布されるものではないが、本実施形態では、プラットフォームモデル管理部２０５から取得され、開発環境４００と一緒に開発者に配布される。
【００４５】
ここで、アプリケーションとプラットフォームとの関係について説明する。図３は、アプリケーション、プラットフォーム、ハードウェアの関係を示した図である。実施形態の説明におけるプラットフォームとは、ハードウェアの差異を吸収するためのオペレーティングシステム（ＯＳ）、ミドルウェア、または仮想化されたハードウェアを指す。アプリケーションは、プラットフォームに対してＡＰＩ（Application Program Interface）を
経由して入出力を行うことで各種の機能を実現する。従って、ＡＰＩが定義されているアプリケーションモデルとプラットフォームモデルを組み合わせることによって、アプリケーションがプラットフォーム上でどのように動作するのかを検証することができる。
【００４６】
図２に戻り、説明を続ける。本実施形態に係るソフトウェア作成装置では、アプリケーションモデルとプラットフォームモデルとを、モデルチェッカ４０１によりモデルレベルで対比させることによって検証を行う。モデルチェッカ４０１は、モデルチェック部１０３に格納され、実行される。
【００４７】
検証の方法を説明する前に、検証ルールについて説明する。検証ルールとは、試験項目仕様書に該当するものであり、アプリケーションのどのような項目について検証を行い、どのような情報を保存するかが定義されている情報である。この検証ルールに従ってモデルチェッカは検証動作を行う。例えば、ＯＳの互換性チェックが要求されていた場合、モデルチェッカは、複数バージョンのプラットフォームモデルを用い、アプリケーションモデルで定義されているインタフェース呼び出しが全てプラットフォームモデル側と整合しているかを確認する。また、アプリケーションに固有なインタフェースの検証が要求されていた場合、必須とされるインタフェースがアプリケーションモデルに備わっているかを確認する。
【００４８】
モデル記述言語にＡＡＤＬを用いた場合、検証の対象はソフトウェアの構造に限られるが、ソフトウェアの振る舞いを記述できる言語を使用し、ソフトウェアの振る舞いについての検証を行ってもよい。この場合、定められた通りにイベントが発生するかを検証ルールとして定義する。このように、検証ルールは自由に定義することができる。検証ルールは、開発者が作成してもよいが、複数の開発者のアプリケーションを一元管理するという発明の性質上、アプリケーションプロバイダが提供することが望ましい。検証ルールは、開発環境４００に含まれる形で、たとえばモデルチェッカ４０１に含まれて配布される。
【００４９】
<アプリケーション検証の方法>
アプリケーションモデル、プラットフォームモデル、検証ルールを用いた検証の方法を、ＡＡＤＬを用いた場合を例に具体的に説明する。ＡＡＤＬの開発環境であるＯＳＡＴＥ（Open-Source AADL Tool Environment）では、整合性解析、リソース解析、フロー解析
の三つを用いてＡＡＤＬモデルの検証を行うことができる。
【００５０】
整合性解析は、アプリケーションモデルとプラットフォームモデル間のインタフェースの整合性が取れているかを確認し、設計仕様のエラーを検出する検証方法である。例えば、音楽ファイルを読み込んで再生するアプリケーションにおいては、ファイルの読み込みが完了する前に再生ボタンを押すとエラーが発生してしまう。そのため、読み込みが完了したことを通知するＡＰＩを呼び出す実装が必須となる。検証ルールには「アプリケーションモデルに当該ＡＰＩが実装されているか」といった定義を行ってもよいし、「呼び出しの型（引数）がプラットフォームモデルと整合しているか」といった定義を行ってもよい。また、「プラットフォームモデルに、アプリケーションモデルから行われる呼び出し
に対応するインタフェースが全て定義されており、型が一致しているか」といったルールを用いてもよい。整合性解析によって、プラットフォームとアプリケーションとの互換性エラーを検出することができる。
【００５１】
リソース解析では、アプリケーションが稼働した状態でのプロセッサの利用率（占有時間）を知ることができる。アプリケーションモデルには、オブジェクトごとに演算時間とデッドラインが定義されている。ＡＡＤＬスレッドをプロセッサに配置することにより、複数のアプリケーションが稼働した場合の負荷の見積もりを行うことができる。検証ルールには、例えば「ＣＰＵに制限値以上の負荷をかけていないか」といった定義を行うことができる。
【００５２】
フロー解析では、ＡＡＤＬのフローを使って定義したデータやイベントの経路において、伝送遅延時間の要求値を満足するか検証することができる。モデル間の通信に要する時間と演算時間を合計して、遅延時間に問題がないかをチェックする。検証ルールには、例えば「要求性能値を満たしていないフローが無いか」といった定義を行うことができる。
【００５３】
検証結果は、モデルチェッカ４０１によって集計され、検証結果出力部１０４に出力される。検証結果は、例えばＯＳのバージョンごとに集計し、「ＯＳバージョン２．２における動作＝問題なし」といった形式で出力してもよいし、検証ルールに定義されたチェック項目ごとに「ＯＳバージョン２．２におけるフローＸに対する遅延時間＝問題なし」といった形式で出力してもよい。また、測定結果の数値を入れてもよいし、動作に問題があるＡＰＩの名称のみをリスト化してもよい。
【００５４】
ネットワークを経由して検証結果の出力を行う場合、検証結果出力部１０４は、例えば検証結果をネットワーク経由で送信するプラグインを開発基盤４０８に追加することによって実現することができる。
【００５５】
<アプリケーションの開発フロー>
次に、具体的なアプリケーション開発の手順を説明する。図４は、ソフトウェア作成装置１００を用いて開発者がアプリケーション開発を行う手順を示したフローチャート図である。アプリケーション開発において、開発者はまずアプリケーションモデルを作成する（Ｓ１１）。アプリケーションモデルは、前述のＯＳＡＴＥといった開発ソフトウェアをＥｃｌｉｐｓｅ上に構築すること等により作成することができる。
【００５６】
次に、作成したモデルを、モデルチェッカによって検証し（Ｓ１２）、検証結果を出力する（Ｓ１３）。検証結果は、前述の通りネットワーク経由でソフトウェア管理装置２００へ送信してもよいし、単体で出力してもよい。アプリケーションプロバイダに提出できる形態であれば、どのようなものであってもよい。
【００５７】
検証結果を出力した後、開発者は、アプリケーションモデルからプログラムのソースコードを生成する（Ｓ１４）。そして、ソースコードから実行形式のプログラムを生成し、アプリケーションプロバイダに送付する（Ｓ１５）。なお、アプリケーションモデルから自動でコードを生成せず、開発者が自らコーディングを行っても良い。また、検証の実施と同時にソースコードないしはプログラムを生成してもよい。検証と成果物の生成を同時に行うことで、検証結果と生成された成果物の内容が一致していることが保証できるようになる。
【００５８】
送られたアプリケーション本体は、アプリケーションプログラム記憶部２０４に格納される。アプリケーション本体についても、検証結果と同様に、ネットワーク経由で送信されてもよいし、記憶媒体によって移動されてもよい。
【００５９】
<品質管理方法>
次に、アプリケーションプロバイダ側にて、品質管理を行う方法の説明を行う。
図５は、ソフトウェア作成装置へ送信される検証結果を表形式で表した例である。本例では、アプリケーションプロバイダ側にて把握したい情報を評価項目に分類し、対応する評価値を、開発者ＩＤおよびアプリケーションＩＤごとに保持する形式をとっている。検証結果は検証結果記憶部２０２へ保存される。
【００６０】
図５（ａ）は、ＡＰＩの名称を評価項目とし、アプリケーションモデルに当該ＡＰＩが備わっているかを評価値とした例である。このようにすることで、実装しているべきＡＰＩがアプリケーションに備わっているか否かを知ることができる。
【００６１】
また、図５（ｂ）は、ＯＳごとの互換性を評価項目とし、プラットフォームモデルとの互換性の有無を評価値とした例である。複数のプラットフォームモデルを使用して、アプリケーションに実装されている全てのＡＰＩについてチェックを行い、問題が無かったバージョンのみを「YES（動作可）」とすることができる。
【００６２】
この他にも、遅延時間の計測結果や、特定の機能が実装されているかといった評価項目を設けてもよい。このように、評価項目は、モデルチェッカによって取得できる情報であればどのような情報であってもよい。これにより、アプリケーションプロバイダは、未公開のアプリケーションのうち、定められた条件を満たすアプリケーションを抽出し、公開を決定することができる。また、ユーザの求めに応じて、公開中のアプリケーションのうち一定の条件を満たすものを抽出してもよい。品質情報検索部２０３は、検証結果記憶部２０２に記録されたデータに対して検索を行い、結果を取得することができる。取得された結果に対応するアプリケーションをアプリケーションプログラム記憶部２０４から取得することで、条件を満たすアプリケーションを利用者に提供することができる。
【００６３】
なお、プログラム生成部１０５、品質情報検索部２０３、アプリケーションプログラム記憶部２０４については、検証結果に基づいてアプリケーションをユーザに提供するための付随的な役割を果たすものであり、本発明の必須構成ではない。また、プラットフォームモデル管理部２０５も、プラットフォームモデルをソフトウェア作成装置に提供することができれば、ソフトウェア管理装置内に保持される必要はない。
【００６４】
また、本実施形態では評価値を文字列によって記録する例を挙げたが、他の形式であっても構わない。例えば、不具合発生時のメモリダンプ情報であってもよいし、開発者による試験時の操作ログであってもよい。また、文字列だけでなく、バイナリ形式のオブジェクトが格納されていてもよい。
【００６５】
本実施形態によれば、オープンプラットフォームを用いて複数の開発者がアプリケーションを作成する開発形態において、ソフトウェア管理装置が、複数のアプリケーションの品質情報を一括して管理することができる。また、開発者はアプリケーションの検証結果のみをアプリケーションプロバイダに送信すればよいため、設計情報を外部に提供する必要がなく、秘匿性が確保できるという利点がある。
【００６６】
（変形例）
なお、各実施形態の説明は本発明を説明する上での例示にすぎず、本発明は、発明の趣旨を逸脱しない範囲で適宜変更して実施することができる。例えば、第一の実施形態では、ソフトウェア作成装置を例示し、本発明に係るソフトウェア検証装置の一例としたが、アプリケーションモデルを作成できる手段があれば、アプリケーションモデルの作成と検証は別個に行ってもよい。この場合、モデル作成部１０１が、アプリケーションモデル取
得手段に置き換えられる。また、図１では検証結果とアプリケーション本体が別個にソフトウェア管理装置へ送付される形態を記載したが、同時に送られてもよい。
【００６７】
また、アプリケーションモデルは、モデル記述言語による設計を行わず、テキスト形式や表計算ソフトにて仕様を記述した後、記述した仕様を変換ツールによってモデル記述言語に変換してもよい。
【００６８】
また、第一の実施形態では、ネットワークを経由して検証結果を送信するが、ネットワーク経由で送信する場合、暗号化技術を用いて検証結果の改変を防いでもよい。例えば、検証結果出力部１０４が、検証結果にメッセージ認証コードを付加してもよいし、公開鍵暗号方式を用いた電子署名を付加してもよい。これによって、ソフトウェア管理装置は、受信した検証結果が改変されていないことを確認することができる。また、検証結果には、検証に使用したモデルの名称を含ませてもよい。これによって、ソフトウェア管理装置は、特定のモデルを用いて検証が実施されたことを確認することができる。
【００６９】
また、第一の実施形態では、モデル記述言語として、静的なアーキテクチャを記述する言語であるＡＡＤＬを例に挙げたが、ソフトウェアの振る舞いを記述することができるＰｒｏｍｅｌａ（Process or Protocol Meta Language）などの検証用モデリング言語を用
いてもよい。Ｐｒｏｍｅｌａによる記述は、ＳＰＩＮモデルチェッカによって検証することができ、これをモデルチェック部１０３にて実行してもよい。第一の実施形態では、ＡＡＤＬによって三種類の検証を行う例を挙げたが、他のモデル記述言語を用いる場合、それぞれの言語に適した検証方法を使用することができる。また、検証結果の内容についても、例示したものに限られない。
【００７０】
また、開発環境を開発者に直接配布せず、Ｗｅｂサービスとしてネットワーク経由で利用できるようにしてもよい。この方法を用いた場合、プラットフォームのバージョンアップ等によってプラットフォームモデルに変更が生じても、モデルを配布し直さなくてもよいという利点がある。ただし、通信文の暗号化等によるデータの保護が必要となる。
【符号の説明】
【００７１】
１００  ソフトウェア作成装置
１０１  モデル作成部
１０２ａ  プラットフォームモデル記憶部
１０２ｂ  アプリケーションモデル記憶部
１０３  モデルチェック部
１０４  検証結果出力部
１０５  プログラム生成部
２００  ソフトウェア管理装置
２０１  検証結果入力部
２０２  検証結果記憶部
２０３  品質情報検索部
２０４  アプリケーションプログラム記憶部
２０５  プラットフォームモデル管理部
【図１】
2013125441.tif 000003
【図２】
2013125441.tif 000004
【図３】
2013125441.tif 000005
【図４】
2013125441.tif 000006
【図５】
2013125441.tif 000007