JP2007179171A - 秘密保持が要求されるモデル用のソフトウエア開発装置 - Google Patents

Abstract

【課題】Ｗｅｂサービスセキュリティの設定をアプリケーション開発者またはセキュリティ開発者が単独で行うのではなく、両者が協力して行えるようにする。
【解決手段】アプリケーションソフトウエアのクラス図において、要求されるサービスの秘密保持要件を付加した秘密要件付加情報を表示する表示装置１０と、秘密要件付加情報を入力する入力手段２０と、クラス図からマークアップ言語による構成モデルに変換する変換機能と、マークアップ言語による構成モデルからシリアライズする事によりマークアップ言語による構成ファイルを作成する構成ファイル作成手段、とを備える。ここで、秘密要件付加情報はセキュリティ要件とクライアントの身元をサーバに申告する証明書であるセキュリティトークンのトークンクラスである。
【選択図】図１

Description

本発明は、秘密保持が要求されるモデル用のソフトウエア開発装置に関する。さらに詳しくはＷｅｂサービスアプリケーションにおける秘密保持が要求されるモデル用のソフトウエア開発装置、ソフトウエア開発プログラム、およびソフトウエア開発方法に関する。

インターネットの普及にともない、Ｗｅｂを使用して電子商取引等を行うシステムが増大している。これらのシステムでは個人情報、パスワード、お金に関する情報など秘密を確保しなければならない情報がある。

Ｗｅｂを使用して電子商取引等を行うサービスには、ＷｅｂＳｐｈｅｒｅ Ａｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ（ＷＡＳ）でＷＳ−Ｓｅｃｕｒｉｔｙ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｓｅｃｕｒｉｔｙ）が利用可能である。ＷＳ−Ｓｅｃｕｒｉｔｙでは、ＷｅｂサービスでやりとりされるＳＯＡＰメッセージを保護するために、メッセージに署名を付加したり、メッセージを暗号化したり、認証のための情報を付け加えたりする方法を定義している。ＷＳ−Ｓｅｃｕｒｉｔｙについては、非特許文献１に紹介されている。

また、これらのシステム開発に際してはＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）が使用されることが多い。ＵＭＬに関しては非特許文献２に紹介されている。

加藤 健二、外4名、"Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｓｅｃｕｒｉｔｙ." ２００２年５月２３日 Microsoft home page 平成１７年１０月２８日検索、インターネット＜ＵＲＬ：http://www.microsoft.com/japan/msdn/webservices/spec/ws-security.asp＞ 株式会社テクノロジックアート著「ＵＭＬモデリングＬ１」株式会社翔泳社発行４６ページから６３ページ、２２４ページから２２８ページ

Ｗｅｂサービスアプリケーションシステムに必要な秘密保持要件を決定するには、そのアプリケーションの詳細を知っている必要があり、アプリケーション開発者により行われるのが適切である。

一方、決定された秘密保持要件を満たすＷｅｂサービスセキュリティを設定するには、Ｗｅｂサービスセキュリティの専門的な知識が必要であり、セキュリティ開発者が行うのが適切である。

また、その設定方法として例えば、ＷＳ−Ｓｅｃｕｒｉｔｙ ｃｏｎｆｉｇｕｒａｔｉｏｎ用のエディタがＲａｔｉｏｎａｌ Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｖｅｌｏｐｅｒ ６．０で提供されているが、ｒｕｎｔｉｍｅの動作を知っている人であっても設定項目が多いため正確に設定するのは労力が大きい。

従って、本発明は上記課題を解決するために、Ｗｅｂサービスセキュリティの設定はアプリケーション開発者またはセキュリティ開発者が単独で行うのではなく、両者が協力して行うことが必要である。すなわち、アプリケーションの詳細を知っているアプリケーション開発者がアプリケーションに必要な秘密保持要件を定義し、それに従ってセキュリティ開発者が要件を満たすマークアップ言語による構成モデルを作成するソフトウエア開発装置、ソフトウエア開発用コンピュータプログラム、およびソフトウエア開発方法を提供することを目的とする。

本発明の形態は、ソフトウエア開発装置、ソフトウエア開発用コンピュータプログラム、およびソフトウエア開発方法のいずれでも実現することができる。以下代表としてソフトウエア開発装置について説明する。

本発明のソフトウエア開発装置の形態では、Ｗｅｂサービスアプリケーションにおいて秘密保持が要求されるオブジェクトモデルのアプリケーションソフトウエアを開発するソフトウエア開発装置において、前記アプリケーションソフトウエアのクラス図において、要求されるサービスの秘密保持要件を付加した秘密要件付加情報を表示する表示装置と、秘密要件付加情報を入力する入力手段と、クラス図からマークアップ言語による構成モデルに変換する変換手段と、マークアップ言語による構成モデルからシリアライズする事によりマークアップ言語による構成ファイルを作成する構成ファイル作成手段、とを備えるソフトウエア開発装置を提供する。

ここで、秘密要件付加情報がセキュリティ要件とクライアントの身元をサーバに申告する証明書であるセキュリティトークンのトークンクラスである。また、セキュリティ要件は完全性保障、秘密保持、認証のいずれか１つ以上とすることが望ましい。

さらに、クラス図からマークアップ言語構成モデルに変換する変換機能を備え、前記変換機能は、前記セキュリティ要件ごとのマークアップ言語による構成モデルに変換することができる。

また、前記マークアップ言語構成モデルからシリアライズする事によりマークアップ言語による構成ファイルを作成することができる。

〔用語の定義〕
秘密要件付加情報（Ｓｅｃｕｒｉｔｙ ａｎｎｏｔａｔｉｏｎ）とは、Ｗｅｂサービスアプリケーションのアプリケーションにおいて要求されるサービスの秘密保持の情報で、クラス図のオブジェクトに付加するものをいう。

セキュリティ要件（Ｓｅｃｕｒｉｔｙ ｒｅｑｕｉｒｅｍｅｎｔ）とは、Ｗｅｂサービスアプリケーションにおいて必要な秘密保持の要件である。完全性保障（Ｉｎｔｅｇｒｉｔｙ）とは、改ざんされてないことを保障することである。秘密保持（Ｃｏｎｆｉｄｅｎｔｉａｌｔｙ）とは、秘密を保持するための対応であり、例えば暗号化されているかいなか等である。認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）とは、正当性を保証することである。

セキュリティトークン（Ｓｅｃｕｒｉｔｙ Ｔｏｋｅｎ）とは、クライアント（サービスにアクセスする顧客など）が持っている、セキュリティを確保するための情報である。また、申告（Ｃｌａｉｍ）とは、クライアントが行う声明であり（例えば、名前、ＩＤ、鍵、グループ、特権、権限など）、セキュリティトークンは、申告のコレクションを表している。

トークンクラス（Ｔｏｋｅｎ Ｃｌａｓｓ）とは、上記のセキュリティトークンを処理するためのオブジェクト言語（例えば、Ｊａｖａ（登録商標））のクラスをさしている。

マークアップ言語（Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、コンピュータなどで作成した文書やデータの中に、一定の情報を埋め込む言語である。代表例としてＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とかＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）がある。

構成モデル（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍｏｄｅｌ）とは、オブジェクトモデル（例えばＵＭＬモデル）からマークアップ言語に変換（Ｔｒａｎｓｆｏｒｍ）するのに、直接変換するには形式のモデルが違いすぎるので、これらの間を取り持つ中間モデルである。例えば、オブジェクトモデルのクラス図に書かれている秘密要件付加情報を抜き出して、マークアップ言語に変換しやすいように必要な情報をツリー状にメモリに保持することができる。ここでツリー状にデータを保持しているのが構成モデルである。
また、ＵＭＬについては、Ｃｒａｉｇ Ｌａｒｍａｎ 「Ａｐｐｌｙｉｎｇ ＵＭＬ ａｎｄ Ｐａｔｔｅｒｎｓ：Ａｎ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｏｂｊｅｃｔ−Ｏｒｉｅｎｔｅｄ Ａｎａｌｙｓｉｓ ａｎｄ Ｄｅｓｉｇｎ ａｎｄ Ｉｎｔｅｒａｃｔｉｖｅ Ｄｅｖｅｌｏｐｍｅｎｔ（３ｒｄ Ｅｄｉｔｉｏｎ）」Ｐｒｅｎｔｉｃｅ Ｈａｌｌ ＰＴＲ（２００４／１０／２０）を参照することもできる。

本発明によって、開発するＷｅｂサービスアプリケーションのクラス図にて、Ｗｅｂサービスアプリケーションにて使用されるオブジェクトの秘密要件付加情報を付加することで、アプリケーション開発者とセキュリティ開発者が共通して必要な秘密保持要件を認識する事が出来る。また、セキュリティトークンのトークンクラスを指定することで、秘密保持要件について共通の理解が得られる。

以下、本発明を実施するための最良の形態について図を参照しながら説明する。なお、これはあくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。

［第１の実施例］
図１は本発明に係るソフトウエア開発装置の構成図である。図２は、秘密要件付加情報を付加して表示した一例である。図３は、従来のソフトウエア開発の一例である。図４と図５は、ソフトウエア開発装置の動作を示すフローチャート図である。

本発明に係るソフトウエア開発装置は、図１の構成図にしめすように、表示装置１０とキーボードやマウス等及び通信部を介して入力することができる入力手段２０がバス線９０に接続されている。ＣＰＵ４０は、ソフトウエア開発プログラムを実行しオブジェクトモデルの表示、オブジェクトモデルのクラス図からマークアップ言語による構成モデルへの変換等を行う。ＲＡＭ３０はオブジェクトモデルに指定されているセキュリティ要件の種類、マークアップ言語による構成モデル、オブジェクトモデル等の表示用の画像データを一旦格納するものであり、通信部５０は外部のシステムと通信するものであり、ローカルエリアネットワークまたはＡＤＳＬによる通信可能な送受信部で構成される。

本ソフトウエア開発装置内のメモリには、大きく分けて３つのファイルが格納される。第１のファイル６０には、オブジェクトモデル６２（例えばＵＭＬモデル）が記憶されている。第２のファイル７０には、オブジェクトモデルに指定されている秘密要件付加情報の種類７２、マークアップ言語による構成モデル７４が記憶されている。第３のファイル８０には、プラットフォーム固有変数データファイル８２、サービス固有変数データファイル８４、マークアップ言語による構成ファイル８６、マークアップ言語ファイル８８が記憶されている。第２のファイル７０と第３のファイル８０とは別々に変更可能である。

上記のように、図２は、秘密要件付加情報を付加して表示した一例であり、図３は、従来のソフトウエア開発の一例である。従来は、アプリケーション開発者が開発しようとするアプリケーションソフトのクラス図に、図３の上段に示すようにセキュリティ要件を規定していた。これは、アプリケーションソフトの開発者が、そのアプリケーションの詳細を正しく理解している必要があり、また同時に、例えば、ＷＳ−ＳｅｃｕｒｉｔｙやＷＡＳ・ＷＳ−Ｓｅｃｕｒｉｔｙ ｒｕｎｔｉｍｅに関する専門知識が必要になる。ところが、実際にはアプリケーション開発者の専門知識が十分ではないので、図３の中段のようなセキュリティ設定を行うのは困難であり、セキュリティ開発者がセキュリティ設定を行っていた。その後、構成ファイルへの変換を行っていた。ところが、図３のような上段でのセキュリティ要件を規定では、セキュリティ設定を行うのに十分な情報がないため行き違いがあり問題となっていた。

この点を解決して、アプリケーション開発者とセキュリティ開発者が協力して行うことが必要である。図２に示す表示装置１０による表示のように、要求されるサービスの秘密保持要件をアプリケーションソフトウエアのクラス図に秘密要件付加情報として付加した。

図２の例はＵＭＬにて表現しており、サービスというクラスにＵＭＬのステレオタイプで安全性保証、認証と指定することにより、サービスというクラスのセキュリティ要件が安全性保証、認証であることが、アプリケーションソフトの開発者とセキュリティ開発者が共通で理解することができる。また、クライアントの身元をサーバに申告する証明書であるセキュリティトークンのトークンクラスであるａｕｔｈｅｎｔｏｋｅｎとｉｎｔｅｇｔｏｋｅｎが指定されている。そして、これらのトークンが同一であることがＵＭＬの制約条件により表示されている。

ここで、トークンクラスを設定したのは、異なるセキュリティ要件でもトークンは共用される可能性がある。例えば、Ｘ５０９Ｃｅｒｔｉｆｉｃａｔｅ Ｔｏｋｅｎでは安全性保証と認証で共通に使われる。同じセキュリティ要件をＵＭＬのステレオタイプで付けられたモデルでも、トークンの共用の有無により変換されるマークアップ言語による構成モデルが異なるからである。したがって、トークンクラスがないとオブジェクトモデル上（ＵＭＬモデル上）では区別が付かない。また、トークンが共有されているときのマークアップ言語による構成モデルへの変換が正しくできないからである。したがってトークンクラスを導入して秘密要件付加情報を正確に区別する必要があるからである。

図４と５のフローチャートにしたがって、本ソフトウエア開発装置の動作を説明する。上記の図２のような秘密要件付加情報を事前にアプリケーション開発者が入力手段２０により入力する。入力された情報はメモリのファイル６０とファイル７０に記憶される。

セキュリティ開発者が、秘密要件付加情報の付加されたサービスクラスを選択し、メニューからモデル変換を選択すると変換動作が開始する。まず、選択されたサービスに対応したサービス固有変数データファイルがＣＰＵ４０により選択される（Ｓ１０２）。

次に開発モデルの各オブジェクトの秘密要件付加情報を確認する（Ｓ１０４）。秘密要件付加情報はセキュリティ開発者が選択したものが対象となるので確認される。確認した結果、そのオブジェクトに例えばＵＭＬのステレオタイプで安全性保証が指定されているかＣＰＵ４０により調査される（Ｓ１１２）。調査したところ安全性保証が指定されている場合はＣＰＵ４０により安全性保証モデルとトークンモデルを作成し、第２のファイル７０のマークアップ言語による構成モデル７４にファイルされる（Ｓ１１３）。一方調査して安全性保証が指定されない場合は次のＳ１１４に進む。

次に、そのオブジェクトに例えばＵＭＬのステレオタイプで秘密保持が指定されているかＣＰＵ４０により調査される（Ｓ１１４）。調査したところ秘密保持が指定されている場合はＣＰＵ４０により秘密保持モデルとトークンモデルを作成し、第２のファイル７０のマークアップ言語による構成モデル７４にファイルされる（Ｓ１１５）。一方調査して秘密保持が指定されない場合は次のＳ１１６に進む。

その後、そのオブジェクトに例えばＵＭＬのステレオタイプで認証が指定されているかＣＰＵ４０により調査される（Ｓ１１６）。調査したところ認証が指定されている場合はＣＰＵ４０により認証モデルとトークンモデルを作成し、第２のファイル７０のマークアップ言語による構成モデル７４にファイルされる（Ｓ１１７）。一方調査して秘密保持が指定されない場合は次のＳ１２０に進む。

このように分けて処理するのは、トークンが複数のセキュリティ要件で共有された場合ＤＤ（Ｄｅｐｌｏｙｍｅｎｔ Ｄｅｓｃｒｉｐｔｅｒ）モデルとＢｉｎｄｉｎｇモデルの変換が複雑になるからである。この関係を図６の構成モデルの比較に示す。図６に示すようにトークンの記述が両モデルにまたがっているので複雑であるが、変換することによりトークンモデルのみを処理すればよく変換しやすくなるからである。

Ｓ１２０では、秘密要件付加情報に制約があるか否かＣＰＵ４０により調査される（Ｓ１２０）。例えば、図２で説明した例ではＵＭＬでのノートにより安全保障のトークンと認証のトークンが共用されるという制約がある。制約がない場合は、Ｓ１３０に進む。調査したところ制約がある場合はＣＰＵ４０により安全性保障と秘密保持のトークンモデルが共用されているか否か判定され（Ｓ１２２）、共用の場合は安全性保障と秘密保持のトークンモデルを１つとする（Ｓ１２３）。

共用でない場合は、ＣＰＵ４０により安全性保障と認証のトークンモデルが共用されているか否か判定され（Ｓ１２４）、共用の場合は安全性保障と認証のトークンモデルを１つとする（Ｓ１２５）。

Ｓ１３０ではすべての構成モデルをまとめ、次にプラットフォーム固有変数（ＳＩＭ）データファイルがＣＰＵ４０により選択される（Ｓ１３２）。選択されるとファイル８０に記憶されているプラットフォーム固有変数データファイル８２がＣＰＵ４０により読み出されて構成モデルにプラットフォーム固有変数データの値をセットする（Ｓ１３４）。そして、構成モデルをＸＭＬ形式に変換する（Ｓ１３６）。

図７に、プラットフォーム固有変数データの値をセット後の各構成モデルの内容を示す。各モデルは秘密要件付加情報とプラットフォーム固有変数（ＳＩＭ）の情報を持つ。図７では、秘密要件付加情報は斜体の文字で点線で囲まれおり、点線で囲まれていない情報がプラットフォーム固有変数（ＳＩＭ）の情報である。

ＸＭＬに変換された構成モデルにはサービス固有変数が必要かＣＰＵ４０により判定される（Ｓ１４０）。判定して必要な場合は、サービス固有変数データファイル８４を参照して必要な値を取り出す（Ｓ１４２）。必要でない場合はＳ１６０に処理が移る。

必要な値が取り出された後は、複数の秘密要件付加情報間で重複して使われているサービス固有変数はあるかＣＰＵ４０により調査される（Ｓ１４４）。調査した結果、重複して使用されている場合は、重複したサービス固有変数を１つにする（Ｓ１４６）。次にサービス固有変数を参照して取り出した値をセットする（Ｓ１５０）。次にマークアップ言語であるＸＭＬファイルを出力する（Ｓ１６０）。すなわち、ＸＭＬ形式に変換された構成モデルをシリアライズすることによりＸＭＬファイルが作成される。ここで、シリアライズとはソフトウェア内部で扱っているデータを丸ごと、ファイルに保存したりネットワークで送受信することができるように変換することをいう。シリアライズすることにより通信部５０を介して外部に取り出すことができる。

以上のように、アプリケーション開発者とセキュリティ開発者に秘密要件付加情報について共通の理解が得られ、両者が協力して行うソフトウエア開発装置、ソフトウエア開発プログラム、およびソフトウエア開発方法を提供することができる。

［第２の実施例］
第２の実施例は、第１の実施例に変換ダイアログのポップアップを取り入れた点が異なる。秘密保持が要求されるシステムによっては、標準的な仕様とは別のサービス特有な情報（例えば、キーの場所、ストアーパス（Ｓｔｏｒｅｐａｓｓ）、キーの名前等）を織り込まなければならない場合がある。このような場合に第２の実施例は有効である。

図８に、本発明の第２の実施例のブロックダイアグラムの概要を示す。最初に図２に示すような秘密要件付加情報を入力手段２０により入力する（Ｓ２１０）。入力後変換ダイアログがポップアップする（Ｓ２２０）。変換ダイアログはＳ２３０に示すような画面が表示装置１０に表示される。

ここで、サービス特有なデータを規定する。例えば、署名、暗号化が処理される順、トークンレファレンスタイプ（Ｔｏｋｅｎ Ｒｅｒｅｒｅｎｃｅ Ｔｙｐｅ）のＳＴＲＲＥＦ、ＫＥＹＩＤ等、サービスキー情報（例えば、キーの場所、ストアーパス（Ｓｔｏｒｅｐａｓｓ）、キーの名前等）、顧客キー情報（例えば、キーの場所、ストアーパス（Ｓｔｏｒｅｐａｓｓ）、キーの名前等）等である。特に署名、暗号化が処理される順は重要である。順序が異なると受け取った側で情報を解読できないからである。

これらのサービス特有なデータは入力手段２０により入力され、サービス固有データとしてファイル７０に記憶される（Ｓ２４０）。記憶後変換が実行される（Ｓ２５０）。変換に際しては記憶されているサービス固有データを引用して変換される。以降は第１の実施例と同様である。

以上、本発明を実施形態、および実施例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に、多様な変更または改良を加えることが可能である。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本発明において一つの実施形態として説明したソフトウエア開発装置は、コンピュータ上のシステム、方法またはコンピュータにその機能を実行させるプログラムによって実現可能である。また、上記メモリの例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ可読の媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、リードオンリー・メモリ（ＲＯＭ）、リジッド磁気ディスクおよび光ディスクが含まれる。現時点における光ディスクの例には、コンパクト・ディスク−リードオンリー・メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）およびＤＶＤが含まれる。

本発明に係るソフトウエア開発装置の構成図である。 本発明の秘密要件付加情報を付加して表示した一例である。 従来のソフトウエア開発の一例である。 本発明のソフトウエア開発装置の動作を示すフローチャート図である。 本発明のソフトウエア開発装置の動作を示すフローチャート図である。 構成モデルの比較を示す図である。 プラットフォーム固有変数データの値をセット後の各構成モデルの内容を示す図である。 本発明の第２の実施例のブロックダイアグラムの概要を示す図である。

符号の説明

１０ 表示装置
２０ 入力手段
４０ ＣＰＵ
５０ 通信部
６０ 第１のファイル
７０ 第２のファイル
８０ 第３のファイル

Claims (18)

1. Ｗｅｂサービスアプリケーションにおいて秘密保持が要求されるオブジェクトモデルのアプリケーションソフトウエアを開発するソフトウエア開発装置において、
   前記アプリケーションソフトウエアのクラス図において、要求されるサービスの秘密保持要件を付加した秘密要件付加情報を表示する表示装置と、
   前記秘密要件付加情報を入力する入力手段と、
   前記クラス図からマークアップ言語による構成モデルに変換する変換手段と、
   前記マークアップ言語による構成モデルからシリアライズする事によりマークアップ言語による構成ファイルを作成する構成ファイル作成手段と、
   を備えるソフトウエア開発装置。
2. 請求項１に記載のソフトウエア開発装置であって、
   前記秘密要件付加情報がセキュリティ要件とクライアントの身元をサーバに申告する証明書であるセキュリティトークンのトークンクラスであるソフトウエア開発装置。
3. 請求項２に記載のソフトウエア開発装置であって、
   前記セキュリティ要件が完全性保障、秘密保持、認証のいずれか１つ以上であるソフトウエア開発装置。
4. 請求項２から３のいずれかに記載のソフトウエア開発装置であって、
   前記変換手段は、前記セキュリティ要件ごとのマークアップ言語による構成モデルに変換するソフトウエア開発装置。
5. 請求項１から３のいずれかに記載のソフトウエア開発装置であって、
   前記クラス図をＵＭＬにより記載し、ＵＭＬの拡張機能を使用して前記セキュリティ要件を記載したことを特徴とするソフトウエア開発装置。
6. 請求項１から５のいずれかに記載のソフトウエア開発装置であって、
   前記マークアップ言語による構成モデルがＸＭＬによる構成モデルであることを特徴とするソフトウエア開発装置。
7. コンピュータをＷｅｂサービスアプリケーションにおいて秘密保持が要求されるオブジェクトモデルのアプリケーションソフトウエアを開発するソフトウエア開発装置として機能させるコンピュータプログラムであって、
   前記アプリケーションソフトウエアのクラス図において、要求されるサービスの秘密保持要件を付加した秘密要件付加情報を表示する表示機能と、
   前記秘密要件付加情報を入力する入力機能と、
   前記クラス図からマークアップ言語による構成モデルに変換する変換機能と、
   前記マークアップ言語による構成モデルからシリアライズする事によりマークアップ言語による構成ファイルを作成する構成ファイル作成機能と、
   してコンピュータを機能させるコンピュータプログラム。
8. 請求項７に記載のコンピュータプログラムであって、
   前記秘密要件付加情報がセキュリティ要件とクライアントの身元をサーバに申告する証明書であるセキュリティトークンのトークンクラスであるコンピュータプログラム。
9. 請求項８に記載のコンピュータプログラムであって、
   前記セキュリティ要件が完全性保障、秘密保持、認証のいずれか１つ以上であるコンピュータプログラム。
10. 請求項７から９のいずれかに記載のコンピュータプログラムであって、
    前記変換機能は、前記セキュリティ要件ごとのマークアップ言語による構成モデルに変換するコンピュータプログラム。
11. 請求項７から１０のいずれかに記載のコンピュータプログラムであって、
    前記クラス図をＵＭＬにより記載し、ＵＭＬの拡張機能を使用して前記セキュリティ要件を記載したコンピュータプログラム。
12. 請求項７から１１のいずれかに記載のコンピュータプログラムであって、
    前記マークアップ言語による構成モデルがＸＭＬのよる構成モデルであるコンピュータプログラム。
13. Ｗｅｂサービスアプリケーションにおいて秘密保持が要求されるオブジェクトモデルのアプリケーションソフトウエアを開発するソフトウエア開発方法において、
    前記アプリケーションソフトウエアのクラス図において、要求されるサービスの秘密保持要件を付加した秘密要件付加情報を表示する表示ステップと、
    前記秘密要件付加情報を入力する入力ステップと、
    前記クラス図からマークアップ言語構成モデルに変換する変換ステップと、
    前記マークアップ言語構成モデルからシリアライズする事によりマークアップ言語による構成ファイルを作成するステップと、
    を備えるソフトウエア開発方法。
14. 請求項１３に記載のソフトウエア開発方法であって、
    前記秘密要件付加情報がセキュリティ要件とクライアントの身元をサーバに申告する証明書であるセキュリティトークンのトークンクラスであるソフトウエア開発方法。
15. 請求項１４に記載のソフトウエア開発方法であって、
    前記セキュリティ要件が完全性保障、秘密保持、認証のいずれか１つ以上であるソフトウエア開発方法。
16. 請求項１３から１４に記載のソフトウエア開発方法であって、
    前記変換ステップは前記セキュリティ要件ごとのマークアップ言語による構成モデルに変換するステップであるソフトウエア開発方法。
17. 請求項１３から１６のいずれかに記載のソフトウエア開発方法であって、
    前記クラス図をＵＭＬにより記載し、ＵＭＬの拡張機能を使用して前記セキュリティ要件を記載したことを特徴とするソフトウエア開発方法。
18. 請求項１３から１７のいずれかに記載のソフトウエア開発方法であって、
    前記マークアップ言語による構成モデルがＸＭＬのよる構成モデルであることを特徴とするソフトウエア開発方法。
    

Images