JP6421249B2 - デバッグを支援する方法及び計算機システム - Google Patents

デバッグを支援する方法及び計算機システム Download PDF

Info

Publication number
JP6421249B2
JP6421249B2 JP2017547206A JP2017547206A JP6421249B2 JP 6421249 B2 JP6421249 B2 JP 6421249B2 JP 2017547206 A JP2017547206 A JP 2017547206A JP 2017547206 A JP2017547206 A JP 2017547206A JP 6421249 B2 JP6421249 B2 JP 6421249B2
Authority
JP
Japan
Prior art keywords
input
package
parts
output
debug target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017547206A
Other languages
English (en)
Other versions
JPWO2017072828A1 (ja
Inventor
山田　浩之
浩之 山田
裕計 谷山
裕計 谷山
雅史 中岡
雅史 中岡
雅年 吉田
雅年 吉田
佑樹 清水
佑樹 清水
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of JPWO2017072828A1 publication Critical patent/JPWO2017072828A1/ja
Application granted granted Critical
Publication of JP6421249B2 publication Critical patent/JP6421249B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/28—Error detection; Error correction; Monitoring by checking the correct order of processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)
  • Software Systems (AREA)

Description

本発明は、概して、デバッグの支援に関する。
国内外におけるデータセンタやクラウド環境のような運用対象システムの活用の拡大に伴い、ユーザ固有の環境に応じたシステム運用化のニーズが高まっている。システム運用化のようなサービスとして、複数の部品で構成されており複数の部品の実行順序が定義された部品集合全体処理を作成することが考えられる。本明細書において、「部品」とは、１以上（典型には複数）の処理ステップの集合としての有意な処理のモジュールであって、他の部品からは独立している。このため、部品（処理ステップの集合）だけで有意な処理が完結し、他の部品とは依存関係がない。例えば、部品は、１つの業務に対応し、故に、部品集合全体処理は、複数の業務で構成されていることになる。このため、部品集合全体処理（例えばサービス）は、１つの業務としての処理（例えばサービス）より、規模が大きく且つ実行開始から実行終了までの時間は長い。
一般に、プログラム作成では、作成したプログラムが正常に動作するか否かを検証するため、デバッグが行われる。部品集合全体処理についても、一般的なプログラム作成と同様にデバッグをすることが望ましいと考えられる。
特許文献１には、プログラムが要求する入力値をプログラムの処理が流れる順序で予め記憶させておき、デバッグの際に任意の処理まで自動で入力値を入力するデバッグ支援技術が記載されている。
特開平6-139108号公報
しかし、特許文献１のデバッグ支援技術を部品集合全体処理のデバッグ支援に適用することはできない。以下の第１及び第２の課題が生じるからである。
第１の課題は、以下の通りである。或る特定の入力値を変更してプログラムの検証をしたい場合、全ての入力値を入力順序通りに記憶させておかなければならない。このため、手続きが煩雑となってしまう。特に、プログラムの規模が大きくなればなるほどこの傾向は顕著となるところ、部品集合全体処理の規模は１つの業務としての処理（サービス）よりも大きいため（例えば、データセンタやクラウド環境のような運用対象システムの規模は一般的には大きいため）、手続きの煩雑さは大きな問題となる。
第２の課題は、以下の通りである。部品集合全体処理では、各部品（部品の処理内容）は他の部品（他の部品の処理内容）に依存しないが、部品の入力値は、同じ部品又は他の部品の入力値に依存し得る。すなわち、１つの部品に対する入力値同士で依存関係を有していたり、他の部品の出力値を入力値として使用したりすることがあり得る。このため、部品集合全体処理について存在する全ての入力値について、どの入力値がどの入力値に依存するかを理解することは簡単ではない。エキスパートレベルの知識が無いユーザにとってはその理解は一層簡単ではない。このため、部品集合全体処理のデバッグを正確に行うことが難しいこともある。
計算機システムは、部品集合全体処理のテストにおいて、実行対象の少なくとも１つの部品について、入力パッケージと出力パッケージとのうちの少なくとも１つを記憶資源にエクスポートする。各入力パッケージは、その入力パッケージに対応した部品の入力プロパティを含み、各入力プロパティは、入力値を含む。各出力パッケージは、その出力パッケージに対応した部品の出力プロパティを含み、各出力プロパティは、出力値を含む。計算機システムは、デバッグ対象部品の順番Ｎ（Ｎは自然数）よりも前の順番の部品を実行すること無しにデバッグ対象部品を実行するために、以下の（Ｘ１）及び（Ｘ２）のうちの少なくとも１つを、デバッグ対象部品にインポートする。
（Ｘ１）デバッグ対象部品のエクスポートされた入力パッケージと、順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、デバッグ対象部品の入力値。
（Ｘ２）デバッグ対象部品のエクスポートされた入力パッケージと、順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、デバッグ対象部品についてユーザにより更新された入力値。
ユーザは、デバッグのためにデバッグ対象部品より順番が前の部品についてまで入力値を入力する必要が無く、デバッグ対象部品について必要な入力値（例えば、ユーザにより変更された入力値とその入力値に依存する可能性のある入力値）のみを入力すればよい。故に、デバッグの効率が高い。
また、部品は有意な処理のモジュールでありそれ自身で処理が完結するものである。そのような部品を単位として入力値が記憶される。このため、ユーザは、入力値の意義を理解し易い。更に、部品が他の部品に依存しないので、ユーザは、入力値を変更した場合、その変更が他の部品（例えば、入力値が変更された部品の出力値が入力値となる次の順番の部品）に与え得る影響を理解し易い。このため、エキスパートレベルの知識が無いユーザであっても、部品集合全体処理のデバッグを行い易い。
実施形態の概要を示す。 実施形態に係るシステム全体の構成を示す。 管理サーバの構成を示す。 管理クライアントの構成を示す。 ＳＴ入力プロパティとＳＴ出力プロパティの関係の一例を示す。 デバッグ対象のサービスの一例を示す。 入力パッケージの第１のエクスポート例を示す。 入力パッケージの第１のインポート例を示す。 入力パッケージの第２のエクスポート例を示す。 入力パッケージの第２のインポート例を示す。 デバッグ対象部品３のデバッグの概要を示す。 部品管理テーブルの構成を示す。 部品プロパティ管理テーブルの構成を示す（部品３）。 部品プロパティ管理テーブルの構成を示す（部品４）。 エクスポートインポートプロパティテーブルの構成を示す。 サービス保持プロパティテーブルの構成を示す。 サービスデバッグ画面を示す（インポート前）。 サービスデバッグ画面を示す（インポート後）。 サービスデバッグ画面を示す（デバッグ対象部品の実行後）。 サービスデバッグのフローチャートである。 第１のインポート処理のフローチャートである。 第２のインポート処理のフローチャートである。
以下、一実施形態を説明する。なお、以下に説明する実施形態は請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
また、以下の説明では、「ｋｋｋテーブル」の表現にて情報を説明することがあるが、情報は、テーブル以外のデータ構成で表現されていてもよい。データ構成に依存しないことを示すために「ｋｋｋテーブル」のうちの少なくとも１つを「ｋｋｋ情報」と呼ぶことができる。また、テーブルの構成は一例であり、２以上のテーブルが１つのテーブルにまとめられたり、１つのテーブルが複数のテーブルに分割されたりしてもよい。
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェイスデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。また、プロセッサは、処理の一部または全部を行うハードウエア回路を含んでもよい。プログラムは、プログラムソースから各コントローラにインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機または計算機が読み取り可能な記憶メディアであってもよい。
また、以下の実施形態では、運用対象システムを管理する第１の計算機システム（以下、運用管理システム）と、システム運用の自動化を支援する第２の計算機システム（以下、運用自動化システム）とがある。しかし、運用管理システムと運用自動化システムは１つの計算機システムであってもよい。また、運用管理システムは運用対象装置に含まれていてもよい。
また、以下の説明において、計算機システムは、一以上の計算機で構成されてよい。具体的には、例えば、計算機が情報を表示する場合（具体的には、計算機が自分の表示デバイスに情報を表示する、或いは、計算機が表示用情報を遠隔の表示用計算機に送信する場合）、計算機が計算機システムである。本実施形態では、運用自動化システム又はそのうちの管理サーバが、計算機システムの一例であり、運用自動化システムのうちの管理クライアントが、表示用計算機の一例である。
また、以下の説明において、要素の識別情報として、「ｕｋ（ユニークキー）」又は「キー名」という表現を用いるが、これらのうちの少なくとも１つに代えて又は加えて他種の識別情報（例えば番号）が使用されてもよい。
図１は、実施形態の概要を示す。
運用自動化システムは、システム運用の多数の部品を管理する。ここで、「システム運用」とは、計算機システムの運用のことである。「部品」とは、１以上（典型には複数）の処理ステップの集合としての有意な処理のモジュールであって、他の部品からは独立している。このため、部品（処理ステップの集合）だけで有意な処理が完結し、他の部品とは依存関係がない。つまり、部品は、１つの独立した処理（業務）である。部品は、後述のサービステンプレート（以下、ＳＴ）に関連付けられる１つの単位でよい。部品としては、プラグイン部品と、ＳＴ部品（部品として扱われるサービステンプレート）がある。詳細は後述する。
プラグイン部品は、例えば、スクリプトを実行する処理モジュールであり、実行ファイルでよい。プラグイン部品は、運用自動化システムに予め設けられるが、これに限らず、後から運用自動化システムに追加することもできる。プラグイン部品は、例えば、ストレージ装置の構成変更（例えば論理ボリュームの作成）を実行させる部品でよいが、これに限らず、部品同士を組み合わせるために使用する部品、汎用的に使用可能な部品などがあってもよい。例えば、プラグイン部品としては、繰り返し実行するためのソフトウェア部品、ファイル転送部品、ファイル実行部品などがあってもよい。
なお、運用自動化システムの外部より部品が追加（ダウンロード）される場合、運用自動化システムのユーザが部品を作成又は改善する場合、又はＳＴが部品とされる場合、といったことが考えられるが、これ以外で運用自動化システムにて部品が追加されてもよい。ちなみに部品の改善例として、（１）部品内部の不具合の修正、（２）内部処理効率の改善、（３）部品が運用対象とする装置が変更された（例えば、ある装置の管理をするコマンドの仕様が変わったので、そのコマンドを実行する部品も変える必要が出た）、（４）部品が運用対象とする装置が増えた（例えば、第１のベンダーの装置に加えて新たに第２ベンダーの装置も運用できるようになった）、（５）部品の入出力プロパティ数が増減した、（６）部品の入出力プロパティに与える値のフォーマットが変更された、（７）部品に関連付けられているデフォルト値が変更又は追加された、（８）部品として処理できることが増加又は処理効率の改善、のうちの少なくとも１つが考えられる。
運用自動化システムは、多数の部品を管理する。本実施形態では、多数の部品のうちの２以上の部品を基にＳＴが作成され、作成されたＳＴを基にサービスが作成され、作成されたサービスが実行（提供）される。また、本実施形態では、例えばサービスの実行前に（サービスの提供前に）、サービスのテストが行われ、そのテストにおいて、サービスのデバッグが行われる。以下、部品管理、ＳＴ作成、ＳＴ確定、サービス作成、サービス実行及びサービスデバッグの概要を説明する。
＜部品管理＞
運用自動化システムは、多数の部品を管理する。部品は、部品提供ユーザにより追加又は編集されてよい。運用自動化システムは、部品毎に、部品に関連付けられる１以上の部品プロパティを管理する。また、運用自動化システムは、部品毎に、部品のバージョンを管理する。図１では、部品ＢＢＢを例に取って、部品プロパティ及びバージョンを示しているが、別の部品にも、その別の部品の部品プロパティ及びバージョンが関連付けられている。
「部品プロパティ」とは、部品のプロパティである。部品プロパティとして、部品入力プロパティと部品出力プロパティの２種類がある。部品入力プロパティは、定義された項目（表示名）についての値（入力値）の入力に関するプロパティである。部品出力プロパティは、定義された項目（表示名）についての値（出力値）の出力に関するプロパティである。１つの部品に、１以上の部品入力プロパティと０以上の部品出力プロパティのうちの少なくとも１つが関連付けられる。すなわち、部品によっては、出力プロパティが０個の場合もあるが、入力プロパティは、各部品につき１個以上関連付けられている。入力値は、例えば、過去に作成されたサービスのプロパティとして入力された値のコピーであってもよいし、実行済みの他の部品について出力された値のコピーであってもよい。出力値は、部品実行後の構成情報等でよい。
バージョン００１の部品ＢＢＢと、バージョン００２の部品ＢＢＢがそれぞれ管理されている。すなわち、同一部品でも「バージョン」が異なれば、異なる部品のように扱われる。別の言い方をすれば、部品が更新（例えば改善）されても、更新後の部品が更新前の部品に上書きされることなく、更新前の部品とは別に更新後の部品が管理される。部品が更新された場合にいわゆるソフトウェアの更新のように更新前の部品が自動で更新後の部品に置き換わると、運用自動化においてトラブルの原因となり得る。特に、更新前の部品が既に作成されたサービスの要素の場合には、トラブルの原因となる可能性が高い。そこで、本実施形態では、運用自動化システムは、部品が更新された場合、更新後の部品の第１種の識別情報（例えば部品名）を更新前の部品の第１種の識別情報と同じとするが、更新後の部品のバージョン及び第２の識別情報（例えば部品ｕｋ（部品ユニークキー））のうちの少なくとも１つを、更新前の部品のバージョン及び第２の識別情報と違う値とする。これにより、運用自動化システムは、更新後の部品を更新前の部品と別部品のように管理できる。
「部品提供ユーザ」とは、部品の追加又は更新等を行う、運用自動化システムのユーザである。部品提供ユーザは、例えばＧＵＩ（Graphical User Interface）、ＣＬＩ（Common Language Infrastructure）、ＡＰＩ（Application Programming Interface）などを介して、部品を作成、追加、又は更新等行うことができる。部品提供ユーザにより追加又は更新される部品は、典型的にはプラグイン部品でよい。ＳＴには、プラグイン部品及びＳＴ部品のいずれも関連付けることができる。プラグイン部品は、最小単位でよく、ＳＴ部品は、１以上のプラグイン部品とそれらが関連付けられたＳＴとのパッケージでよい。プラグイン部品は、部品入力プロパティと、部品入力プロパティに入力された入力値に基づいて実行する処理内容とを含んでよい。ＳＴ部品も、部品入力プロパティと、部品入力プロパティに入力された入力値に基づいて実行する処理内容とを含んでよい。ＳＴ部品の部品入力プロパティは、後述するＳＴ入力プロパティでよい。
＜ＳＴ作成＞
運用自動化システムが、ＳＴ作成画面を表示する。ＳＴ作成画面に、情報の入力ＵＩが表示される。ＳＴ作成ユーザが、ユーザ操作により、ＳＴ作成画面に情報を入力する。例えば、運用自動化システムは、ＳＴ作成画面を介して、多数の部品のうちの２以上の部品の選択と、２以上の部品の実行順序の指定とを受け付ける。運用自動化システムが、選択された２以上の部品と指定された実行順序とに基づきサービスフローのＳＴを作成する。
「ＳＴ作成ユーザ」とは、ＳＴを作成する、運用自動化システムのユーザである。ＳＴ作成ユーザは、上述のように、ＳＴ作成画面を用いてＳＴを作成する。ＳＴ作成ユーザは、部品提供ユーザと同一であってもよいし異なっていてもよい。なお、前述のＳＴ部品は、典型的には、ＳＴ作成ユーザにより作成され検証済みとなったＳＴが部品化されたものでよい。しかし、ＳＴ部品は他のベンダーやユーザが作成したものであってもよい。
「ユーザ操作」とは、画面に対してユーザが入力デバイスを使用して行う操作である。ユーザ操作に使用される入力デバイスは、一般に、ポインティングデバイス（例えばマウス）とキーボードの組合せ、又は、タッチスクリーンである。画面を介した入力は、ユーザ操作により行われる。
「ＳＴ」とは、サービスのテンプレートである。本実施形態では、ＳＴが「ＳＴ」と略記されることもある。ＳＴは、インスタンス化されていない自動実行内容を指し示すオブジェクトという言い方をすることもできる。
「サービスフロー」とは、典型的には、選択された２以上の部品の並びである。部品の並びは、指定された実行順序に従う。選択された部品の数が１つだけの場合、サービスフローを構成する部品の数も１つである。
上述のように、運用自動化システムは、ＳＴ作成画面を介して選択された２以上の部品及び指定された実行順序を基にＳＴを作成する。具体的には、例えば、運用自動化システムは、選択された２以上の部品に関連付けられている複数の部品プロパティ（例えば部品プロパティ００１及び００２）にそれぞれ対応した複数のＳＴプロパティ（例えばＳＴプロパティ００Ａ及び００Ｂ）を作成し、作成した複数のＳＴプロパティをＳＴ（例えばＳＴ００１）に関連付ける。部品プロパティに対応したＳＴプロパティは、その部品プロパティを基に運用自動化システムにより自動作成される。ＳＴプロパティの作成中又は作成後にユーザ操作により入力された値がＳＴプロパティに含まれてもよいが、ユーザ操作による入力（つまり手動入力）無しにＳＴプロパティが作成されてよい。「ＳＴプロパティ」とは、ＳＴのプロパティである。ＳＴプロパティとして、ＳＴ入力プロパティとＳＴ出力プロパティの２種類がある。ＳＴ入力プロパティは、定義された項目（表示名）についての値の入力に関するプロパティであり、ＳＴ出力プロパティは、定義された項目（表示名）についての値の出力に関するプロパティである。１つのＳＴに、１以上のＳＴ入力プロパティと０以上のＳＴ出力プロパティのうちの少なくとも１つが関連付けられる。すなわち、ＳＴ出力プロパティが必ず１個あるとは限らない。
図１の例では、サービスフローは、部品ＢＢＢ「Provisioning volume」（ストレージ装置に論理ボリュームを作成する）と、部品ＤＤＤ「Create pair volume」（論理ボリューム（プライマリボリューム）とペアになる論理ボリューム（セカンダリボリューム）を作成する）の組合せであり、そのサービスフローのＳＴ（ＳＴ００１）が作成されたとする。
＜ＳＴ確定＞
運用自動化システムは、作成されたＳＴについて、ユーザ操作により確定を受けた場合、その作成されたＳＴのＳＴ種別を「Release」として管理する。ＳＴ種別「Release」は、ＳＴが確定しており、そのＳＴを基にサービスを作成することが可能であることを意味する。一方、確定していないＳＴは、ＳＴ種別「Debug」である。ＳＴ種別「Debug」は、ＳＴが編集中であることを意味する。なお、運用自動化システムは、サービス実行において、ＳＴ種別「Debug」のＳＴの選択を受け付けないようにしてもよい（例えば、ＳＴ種別「Debug」のＳＴを、選択可能に表示しない（ディスエーブル））。その一例としては、後述するサービス作成ユーザは、ＳＴ種別が「Release」であるＳＴだけサービスの作成を可能とし、ＳＴ作成ユーザは、テスト目的もあるため、ＳＴ種別が「Release」と「Debug」両方でサービス作成を可能としてもよい。なお、こうした処理を実現するため、運用自動化システムはユーザ認識を行っていることは言うまでも無い。また、ＳＴとサービスのいずれも同様にデバッグすることができるが、本実施形態の説明では、サービスのデバッグを例に取る。
＜サービス作成＞
運用自動化システムは、作成済のＳＴを管理する。運用自動化システムは、ＳＴ種別「Release」のＳＴのうちのいずれかのＳＴの選択をサービス作成ユーザから受け、選択されたＳＴを基にサービス作成画面を表示する。サービス作成ユーザが、ユーザ操作により、サービス作成画面に情報を入力する。運用自動化システムは、サービス作成画面を介して入力された情報を基にサービスを作成する。
「サービス作成ユーザ」とは、サービスを作成（実行）するユーザである。サービス作成ユーザとＳＴ作成ユーザは異なるユーザであってもよいし同一ユーザであってもよい。
「サービス」とは、インスタンス化されたＳＴである。具体的には、ＳＴは、サービスの実行に必要な値がブランクとなっており、その必要な値がＳＴに入力されたものが、サービスである。なお、前述のサービスの実行に必要な値については、デフォルト値がＳＴのプロパティの情報として設定できる場合もある。
なお、サービスは運用に関係するものであることを表すために「運用サービス」と記載する場合がある。なお、特定の状況においては「サービス」は、ユーザが指定した運用対象装置に対して行うべき運用処理を示しているとも言える。例えば、図５の例でＳＴ入力プロパティ１３０４Ｃを指定した場合はこの表現に該当する。また、部品自体に指定する運用対象装置情報（運用対象装置を示す情報）を埋め込んだり、部品の入力プロパティのデフォルト値として運用対象装置情報を与えたりしない場合は、「サービス」と「ＳＴ」間の別な見方として、「サービス」が示す処理内容では入力値の定めにより構成変更対象や情報取得先としての運用対象装置が明確になっている一方で、「ＳＴ」ではそのような運用対象装置が不明であるとも言える。
なお、運用自動化システムは、作成されたサービスに、サービスプロパティを関連付けらよい。「サービスプロパティ」とは、サービスの入力・出力プロパティ（入力及び出力のうちの少なくとも一方のプロパティ）である。サービスの入力・出力プロパティには、サービス作成においてＳＴに入力された値と、サービス実行において部品から出力された値とのうちの少なくとも１つが設定される。具体的には、例えば、サービスの実行では、サービス作成において入力プロパティに入力された値が、そのサービスのＳＴに関連付けられている部品に入力されて、処理が実行されてよい。また、部品から出力された値が、サービスの出力プロパティに設定されることで、サービスの実行結果画面において、その設定された値（例えば、部品が実行された後の構成情報等）が表示されてよい。
＜サービス実行＞
運用自動化システムが、作成したサービスの実行の命令を、運用管理システムに送信する。運用管理システムが、その命令に従い、サービスを実行する。
＜サービスデバッグ＞
例えばサービスの実行前に、サービスのテストが行われる。そのテストにおいて、運用自動化システムがサービスデバッガを実行することで、サービスのデバッグが行われる。具体的には、運用自動化システムは、実行対象の少なくとも１つの部品について、入力パッケージと出力パッケージとのうちの少なくとも１つをエクスポートする。入力パッケージは、対応する部品の全ての入力値を含み、入力パッケージの一例が、入力プロパティファイルである。出力パッケージは、対応する部品の全ての出力値を含み、出力パッケージの一例が、出力プロパティファイルである。
運用自動化システムは、デバッグ対象部品に、エクスポート済のファイルのうちの該当する入力値を、インポートする。ここで言う入力値は、例えば、（ａ）乃至（ｃ）のうちの１種類以上の入力値である。
（ａ）デバッグ対象部品の入力パッケージにおける入力値。
（ｂ）デバッグ対象部品の直前の部品の出力パッケージにおける出力値であってデバッグ対象部品の入力値となる値。
（ｃ）（ａ）及び（ｂ）のうちの少なくとも１つがユーザ（例えばサービス作成ユーザ）により変更された値。
デバッグ対象部品より前の順番の部品についてまで入力値を入力する必要が無いので、デバッグ効率が高く、且つ、部品（処理内容９が他の部品（処理内容）に依存しないので入力値の変更が与え得る影響を理解し易くデバッグが行い易い。
なお、本実施形態に係るサービスデバッグでは、手順（Ｑ）が採用されるが、手順（Ｑ）に代えて手順（Ｐ）が採用されてもよい。つまり、入力パッケージと出力パッケージとのうちの少なくとも１つが、実行対象の少なくとも１つの部品についてエクスポートされるが、「実行対象の少なくとも１つの部品」は、デバッグ対象部品として選択された部品のみであってもよいし、サービス実行において実行された各部品であってもよい。
（Ｐ）初回のサービス実行では、実行された部品毎に、入力パッケージと出力パッケージとのうちの少なくとも１つが手動で（又は自動で）エクスポートされる。その後、サービスを構成する複数の部品のうちデバッグ対象部品とされる部品がユーザにより選択される。選択された部品（デバッグ対象部品）に対して、その部品についてエクスポート済の入力値がインポートされる。
（Ｑ）初回のサービス実行の前に、サービスを構成する複数の部品のうちのデバッグ対象部品とされる部品がユーザにより選択される。選択された部品（デバッグ対象部品）についてのみ、入力パッケージと出力パッケージとのうちの少なくとも１つがエクスポートされる。その後、その部品に対して、エクスポート済の入力値がインポートされる。
以上が、部品管理、ＳＴ作成、サービス作成、サービス実行及びサービスデバッグの各々の概要である。
以下、実施形態を詳細に説明する。
図２は、実施形態に係るシステム全体の構成を示す。
運用対象システム３１０に、運用管理システム３０２が接続されており、運用管理システム３０２に運用自動化システム３０１が接続されている。運用自動化システム３０１は運用管理システム３０２と一体でもよい。
運用対象システム３１０は、１以上のホスト計算機（以下、ホスト）３０３と、１以上のストレージ装置３０４とを含む。ホスト３０３とストレージ装置３０４は通信ネットワーク３０６を介して接続されている。ホスト３０３は、ストレージ装置３０４に接続されたＩ／Ｆ（通信インターフェースデバイス）と、メモリのような記憶資源と、それらに接続されたプロセッサとを有する。ストレージ装置３０４は、１以上のＰＤＥＶ（物理記憶デバイス）と、１以上のＰＤＥＶに接続されたコントローラとを有する。コントローラは、ホスト３０３に論理ボリュームを提供する。ホスト３０３は、提供された論理ボリュームを指定したＩ／Ｏ（Input/Output）要求をストレージ装置３０４に送信する。ストレージ装置３０４のコントローラが、そのＩ／Ｏ要求に従い、論理ボリュームに対するデータＩ／Ｏを行う。Ｉ／Ｏ対象のデータが、論理ボリュームのＩ／Ｏ先領域に基になっている１以上のＰＤＥＶに対して入出力される。なお、ホスト３０３とストレージ装置３０４の各々は運用対象装置の一例である。
運用管理システム３０２は、運用対象システム３１０を管理する管理システムである。運用管理システム３０２は、運用自動化システム３０１からの命令に従いサービスを実行する。サービス実行では、例えば、ストレージ装置３０４に論理ボリュームを作成すること、及び、ストレージ装置３０４にセカンダリボリュームを作成することが行われる。
運用自動化システム３０１は、システム運用の自動化を支援する管理システムである。運用自動化システム３０１は、管理サーバ３１１と、管理サーバ３１１に接続された管理クライアント３１２とを有する。管理サーバ３１１が管理クライアント３１２に送信した表示用情報を基に、管理クライアント３１２により情報が表示される。
具体的には、例えば、管理サーバ３１１は、部品と関連ＳＴとの関係を特定し（Ｐ１１）、部品のバージョン毎の関連ＳＴリストを表示する（Ｐ１２）。部品のバージョンについて、「関連ＳＴ」とは、そのバージョンの部品が関連付いたＳＴである。
また、例えば、管理サーバ３１１は、ＳＴ作成画面を表示し（Ｐ２１）、ＳＴ作成ユーザからＳＴ作成画面を介してＳＴの作成（編集を含む）を受け付ける（Ｐ２２）。管理サーバ３１１は、確定したＳＴに基づきサービス作成画面を表示する（Ｐ２３）。管理サーバ３１１は、サービス作成ユーザからサービス作成画面を介して情報を受け、入力された情報を基にサービスを作成し保持する（Ｐ２４）。管理サーバ３１１は、サービスの編集のための画面又はサービスデバッグのための画面を表示し（Ｐ２５）、サービスの編集を受け付ける又はサービスデバッグ支援を実行することもできる。管理サーバ３１１は、作成（編集を含む）されたサービスの実行画面を表示する（Ｐ２６）。管理サーバ３１１は、サービス実行画面を介してサービスの実行をサービス作成ユーザから受け付け、受け付けたサービスの実行の命令を、運用管理システム３０２に送信する（Ｐ２７）。
図２に示した処理Ｐ１１、Ｐ１２及びＰ２１〜Ｐ２７の各処理群（１以上の処理）が、プログラム群（１以上のコンピュータプログラム）がプロセッサにより実行されることにより行われる。
図３は、管理サーバ３１１の構成を示す。
管理サーバ３１１は、通信ポート４１４（Ｉ／Ｆの一例）、メモリ４１２（記憶資源の一例）、及び、それらに接続されたプロセッサ（典型的にはＣＰＵのようなマイクロプロセッサ）４１１を有する。管理サーバ３１１は、通信ポート４１４を介して、少なくとも運用管理システム３０２及び管理クライアント３１２と通信する。
メモリ４１２は、半導体メモリに限らずハードディスクドライブでもよい。メモリ４１２は、管理情報４００、サービス編集プログラム４３１及びサービスデバッガ４３２を記憶する。管理情報４００は、後述の部品管理テーブル４２１、部品プロパティ管理テーブル４２２、エクスポートインポートプロパティテーブル１５００及びサービス保持プロパティテーブル１６００を含む。サービス編集プログラム４３１は、ＳＴ作成支援とサービス作成支援（例えば、ＳＴ作成画面やサービス作成画面の表示）等を行う。サービスデバッガ４３２は、サービスデバッグの支援を行う。サービス編集プログラム４３１及びサービスデバッガ４３２のうちの少なくとも１つが、２以上のプログラムモジュールに分割されていてもよい。また、サービス編集プログラム４３１とサービスデバッガ４３２を含んだ１つのプログラムが構成されていてもよい。
図４は、管理クライアント３１２の構成を示す。
管理クライアント３１２は、通信ポート５１４（Ｉ／Ｆの一例）、入出力デバイス５１３、メモリ５１２（記憶資源の一例）、及び、それらに接続されたプロセッサ（典型的にはＣＰＵのようなマイクロプロセッサ）５１１を有する。
メモリ５１２は、半導体メモリに限らずハードディスクドライブでもよい。メモリ５１２は、表示プログラム（例えばＷｅｂブラウザ）５３１を記憶する。また、メモリ５１２には、サービスの部品毎にエクスポートされたファイル（エクスポートファイル）５３３が記憶されてよい。
図５は、ＳＴ入力プロパティとＳＴ出力プロパティの関係の一例を示す。
ＳＴ１３０１に対応するサービスフローが、部品１３０２Ａ（「Provisioning Volume」）と、部品１３０２Ｂ（「Create pair volume」）とにより構成されている。そのサービスフローでは、部品１３０２Ａの次に部品１３０２Ｂが実行されるような実行順序となっている。
部品１３０２Ａには、４つの部品入力プロパティ１３０３Ａ〜１３０３Ｄが関連付けられている。４つの部品入力プロパティ１３０３Ａ〜１３０３Ｄのそれぞれの表示名は、「Number of Volume」、「Volume Capacity」、「Host Name」及び「Number of path」である。また、部品１３０２Ａには、２つの部品出力プロパティ１３０３Ｅ及び１３０３Ｆが関連付けられている。２つの部品出力プロパティ１３０３Ｅ及び１３０３Ｆのそれぞれの表示名は、「Volume uk」及び「Path info」である。
部品１３０２Ｂには、４つの部品入力プロパティ１３０３Ｇ〜１３０３Ｊが関連付けられている。４つの部品入力プロパティ１３０３Ｇ〜１３０３Ｊのそれぞれの表示名は、「Volume uk」、「Host Name」、「Path info」及び「Path世代数」である。また、部品１３０２Ｂには、１つの部品出力プロパティ１３０３Ｋが関連付けられている。その部品出力プロパティ１３０３Ｋの表示名は、「Path info」である。
これらの部品プロパティにおいて、表示名「Volume uk」の部品出力プロパティ１３０３Ｅと、同じ表示名「Volume uk」の部品入力プロパティ１３０３Ｇは、同一のキー名を有する。同様に、表示名「Path info」の部品出力プロパティ１３０３Ｆと、同じ表示名「Path info」の部品入力プロパティ１３０３Ｉも、同一のキー名を有する。これにより、部品出力プロパティ１３０３Ｅからの出力値が、部品入力プロパティ１３０３Ｇの入力値とされ、また、部品出力プロパティ１３０３Ｆからの出力値が、部品入力プロパティ１３０３Ｉの入力値とされる。このように、「Volume uk」及び「Path info」については、出力値がそのまま入力値と使用されるので、ＳＴ作成ユーザがわざわざ「Volume uk」及び「Path info」について値を入力する必要が無い。従って、誤入力を防止できる。
このような部品を有するサービスフローのＳＴ１３０１には、ＳＴ入力プロパティ１３０４Ａ〜１３０４Ｅと、ＳＴ出力プロパティ１３０４Ｆ及び１３０４Ｇが、サービスデバッガ４３２により関連付けられる。ＳＴ入力プロパティ１３０４Ａは、部品入力プロパティ１３０３Ａを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Number of Volume」である。ＳＴ入力プロパティ１３０４Ｂは、部品入力プロパティ１３０３Ｂを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Volume Capacity」である。ＳＴ入力プロパティ１３０４Ｃは、部品入力プロパティ１３０３Ｃ及びＨを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Host Name」である。ＳＴ入力プロパティ１３０４Ｄは、部品入力プロパティ１３０３Ｄを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Number of path」である。ＳＴ入力プロパティ１３０４Ｅは、部品入力プロパティ１３０３Ｊを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Path世代数」である。ＳＴ出力プロパティ１３０４Ｆは、部品出力プロパティ１３０３Ｅを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Volume uk」である。ＳＴ出力プロパティ１３０４Ｇは、部品出力プロパティ１３０３Ｋを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Path info」である。これらのＳＴ入力プロパティ及びＳＴ出力プロパティは、部品入力プロパティ及び部品出力プロパティを基にそれぞれサービス編集プログラム４３１により生成される。
以下、本実施形態で行われるサービスデバッグを説明する。
図６は、デバッグ対象のサービスの一例を示す。
サービス６５０が、例えば部品１〜４で構成されている。図６における矢印の流れが、値の流れである。従って、実行順序等の前提は下記である。
（＊）サービス６５０に対する入力（入力値の集合）６５１が部品１〜３に入力される。部品１〜３の各々には、入力６５１の少なくとも一部が入力される。
（＊）部品１、部品２、部品３及び部品４の順に実行される。具体的には、部品１に、入力６５１の少なくとも一部の入力値が入力され、部品１から、出力値が出力される。部品２に、部品１から出力された出力値の少なくとも一部の出力値と、入力６５１の少なくとも一部の値とが、入力値として入力される。部品２から、出力値が出力される。部品３に、部品１から出力された出力値の少なくとも一部の出力値と、部品２から出力された出力値の少なくとも一部の出力値と、入力６５１の少なくとも一部の値とが、入力値として入力される。部品３から、出力値が出力される。部品４に、部品３から出力された出力値の少なくとも一部の出力値が、入力値として入力される。部品４から、出力値が出力される。最終的に、サービス６５０の実行結果としての出力６５３が、部品３から出力された出力値の少なくとも一部の出力値と、部品４から出力された出力値の少なくとも一部の出力値とを含む。
以上の前提によれば、実行順番Ｎ（Ｎは自然数）の部品Ｘを基準とした場合、実行順番（Ｎ−１）の部品が、部品Ｘの直前の部品であり、実行順番（Ｎ＋１）の部品が、部品Ｘの直後の部品である。なお、複数の部品の実行順序の定義によっては、実行順番が同じ部品が２以上存在することもある。例えば、部品Ａの出力値が部品Ｂ及び部品Ｃに入力され、部品Ｂ及び部品Ｃの出力値が部品Ｄに入力されるサービスでは、部品Ａの順番は「１」であり、部品Ｂ及び部品Ｃの順番は「２」であり、部品Ｄの順番は「３」となる。
本実施形態では、サービス６５０の実行（テスト）において、サービスデバッガ４３２が、サービス６５０における実行対象の少なくとも１つの部品について、入力パッケージ（典型的には、部品の全ての入力値を含んだパッケージ）と出力パッケージ（典型的には、部品の全ての出力値を含んだパッケージ）とのうちの少なくとも１つをメモリ４１２のような記憶資源（外部ストレージ装置を含んでもよい）にエクスポートしてよい。サービスデバッガ４３２は、エクスポートしたパッケージを含んだファイルであるエクスポートファイルを、例えば表示の際に、管理クライアント３１２に送信してもよい。管理クライアント３１２のメモリ５１２には、サービスデバッガ４３２からのエクスポートファイル５３３が格納されてよい。
入力パッケージの一例が、入力プロパティファイルである。入力プロパティファイルは、対応する部品の入力プロパティを含んだファイルである。各入力プロパティは、プロパティ値（入力値の一例）を含む。
出力パッケージの一例が、出力プロパティファイルである。出力プロパティファイルは、対応する部品の出力プロパティを含んだファイルである。各出力プロパティは、プロパティ値（出力値の一例）を含む。
図７は、入力パッケージの第１のエクスポート例を示す。
入力パッケージの第１のエクスポート例によれば、デバッグ対象部品として選択された部品３についてのみ、実行直前の部品３に対する入力パッケージ（例えば部品３の全ての入力値を含んだパッケージ）として、入力プロパティファイル７５１が、サービスデバッガ４３２によりエクスポートされる。
図８は、入力パッケージの第１のインポート例を示す。
図７に示したエクスポート済の入力プロパティファイル７５１における入力値は、部品３にインポートされる。
この例によれば、部品３より順番が前のいずれの部品（部品１及び部品２の各々）を実行すること無しに、部品３の実行直前時の全ての入力値を部品３に入力することができる。
図９は、入力パッケージの第２のエクスポート例を示す。
部品３の実行のために入力された入力パッケージと、部品３の出力パッケージ（部品３の全ての出力値を含んだパッケージ）とを含んだ出力プロパティファイル９５１が、サービスデバッガ４３２によりエクスポートされる。つまり、部品３の入力パッケージが、部品３の出力パッケージと共にエクスポートされる。
この例によれば、部品３の入力パッケージがエクスポートされなくても、部品３について、同じ条件のデバッグが再度可能となる。このため、ユーザの作業ミスを防止することや、部品３の出力値として意図しない出力値があった場合に部品３を即時に再実行することが期待できる。
図１０は、入力パッケージの第２のインポート例を示す。
部品３のエクスポートされた出力プロパティファイル１０５３における少なくとも１つの出力値が、部品３の直後の部品である部品４の少なくとも１つの入力値として、部品４の入力プロパティファイル１０５１に含まれている。そのような入力プロパティファイル１０５１が、部品３の次の部品４にインポートされる。具体的には、例えば、部品３の出力プロパティ“OutX”における出力値が、部品４の入力プロパティ“Prop1”における入力値にマッピングされている。つまり、部品３の出力プロパティ“OutX”における出力値と部品４の入力プロパティ“Prop1”における入力値間に依存関係がある。
この例によれば、少なくとも１つの部品について入力値をエクスポートする必要がなく、故に、デバッグの効率化が期待できる。
図１１は、デバッグ対象部品３のデバッグの概要を示す。
デバッグ対象部品３より順番が前のいずれの部品（部品１及び部品２の各々）を実行すること無しに部品３のデバッグを実行することができる。部品３に入力された入力パッケージ（全ての入力値）を含んだファイルがエクスポート済みであり、そのエクスポートされたファイルから部品３の入力値をインポートできるからである。
一般的なデバッグ（従来のデバッグ）では、デバッグ毎に、処理の始めから実行する必要がある。この技術を、サービス６５０（部品集合全体処理）のデバッグに適用すると、サービス６５０の先頭部品１から１つ１つの部品を実行する必要がある。１つの部品は、例えば、多くの論理ボリュームの各々について「Provisioning volume」（ストレージ装置に論理ボリュームを作成する）や「Create pair volume」（論理ボリューム（プライマリボリューム）とペアになる論理ボリューム（セカンダリボリューム）を作成する）といった業務処理に対応する（例えば図１参照）。つまり、１つ１つの部品の完了までに多大な時間がかかる場合がある。これは、複数回デバッグを実行しようとすると大きな問題である。
そこで、図１１に例示したように、デバッグ対象部品３より前の部品１及び２のいずれの実行も不要なので、デバッグの効率が向上し、結果として、サービスデバッグ全体（サービスのテスト）に要する時間を短縮することができる。
また、「部品」は、有意な処理のモジュールでありそれ自身で処理が完結するものである。そのような部品を単位として入力値が記憶される。このため、ユーザは、入力値の意義を理解し易い。更に、部品が他の部品に依存しないので、ユーザは、入力値を変更した場合、その変更が他の部品（例えば、入力値が変更された部品の出力値が入力値となる次の順番の部品）に与え得る影響を理解し易い。このため、エキスパートレベルの知識が無いユーザであっても、部品集合全体処理のデバッグを行い易い。
デバッグの１つの具体例として、部品３から実行が開始される。具体的には、例えば、サービスデバッガ４３２は、デバッグ対象として部品３の選択を受けた場合、部品１及び部品２の実行無しに部品３の実行を開始する。
デバッグの別の具体例として、サービス６５０の先頭部品１から実行が開始されるが、デバッグ対象部品３より前の部品１及び２のいずれの実行もスキップされる。具体的には、例えば、サービスデバッガ４３２は、デバッグ対象部品３までの部品１及び２の各々について、実行をスキップするか否かの選択をユーザ受け、ユーザからの選択に応じて、部品１及び２の各々の実行をスキップするか否かを決定してよい。
上述のようなデバッグのために、図３に示した管理情報４００中の種々のテーブルがサービスデバッガ４３２により参照される。以下、管理情報４００中の各種テーブルの構成を説明する。
図１２は、部品管理テーブル４２１の構成を示す。
部品管理テーブル４２１は、部品に関する情報を有する。部品管理テーブル４２１は、部品毎にレコードを有する。各レコードが、部品名６０２、バージョン６０３、実行ファイルパス６０４、及び部品ｕｋ６０５を記憶する。部品名６０２は、部品の名称である。バージョン６０３は、部品のバージョンを表す。実行ファイルパス６０４は、部品の実行ファイルへのパス（パス名）を表す。部品ｕｋ６０５は、部品のユニークキー（番号）である。
なお、図１２から分かるように、バージョンが異なる同一部品は、部品名６０２が同じであり（例えば、「Provisioning Volume」）、バージョン６０３が異なる（例えば「01.00.00」、「01.10.00」）。つまり、バージョンが異なる同一部品は、別々の部品として管理される。しかし、複数の部品の部品名６０２が同一であれば、それら複数の部品のオリジナルは同一であることがわかる。
図１３及び図１４は、部品プロパティ管理テーブル４２２の構成を示す。具体的には、図１３は、部品３の部品プロパティ管理テーブルを示し、図１４は、部品４の部品プロパティ管理テーブルを示す。
部品プロパティ管理テーブル４２２は、部品毎に存在する。部品プロパティ管理テーブル４２２は、対応する部品の部品プロパティ毎にレコードを有する。各レコードが、部品ｕｋ７０１、キー名７０２、プロパティ名７０３、説明７０４、モード７０５、データ型７０６、入力条件７０７、プロパティ値７０８、更新可否７０９、マッピング対象７１０及び要否７１１を記憶する。
部品ｕｋ７０１は、対応する部品のｕｋである。キー名７０２は、部品プロパティを一意に特定するための名称であり、部品プロパティの識別情報の一例である。プロパティ名７０３は、部品プロパティの名称である。説明７０４は、部品プロパティの説明、例えば、部品プロパティが含むプロパティ値７０８（入力値又は出漁値）が属する項目（情報種類）の名称である。モード７０５は、部品プロパティが入力プロパティ（“In”）であるか出力プロパティ（“Out”）であるかを示す（言い換えれば、プロパティ値７０８が入力値か出力値かを示す）。データ型７０６は、プロパティ値７０８のデータ型を示す。入力条件７０７は、プロパティ値７０８の入力条件を示す。プロパティ値７０８は、入力値又は出力値である。更新可否７０９は、部品プロパティ（プロパティ値７０８）の更新可否を示す。マッピング対象７１０は、プロパティ値７０８（例えば出力値）が別の部品プロパティのプロパティ値７０８（例えば入力値）にマッピングされている場合（依存関係がある場合）のその依存関係名（マッピング名）を示す。要否７１１は、対応する部品にとってプロパティ値７０８が必須か否かを示す。
図１３における最終レコードと、図１４における先頭レコードによれば、部品３のキー名“OutX”のプロパティ値７０８（出力値）が、部品４のキー名“Prop1”のプロパティ値７０８（入力値）にマッピングされている（マッピング対象“Map1”）。これは、図１０を参照して説明したマッピング関係（依存関係）を示す。
図１５は、エクスポートインポートプロパティテーブル１５００の構成を示す。
エクスポートインポートプロパティテーブル１５００は、部品のエクスポートされた入力パッケージ及び出力パッケージのうちの少なくとも１つを含んだファイルである。エクスポートインポートプロパティテーブル１５００は、部品プロパティ毎に、レコードを有する。各レコードは、部品プロパティ管理テーブル４２２のレコードの一部を記憶する。具体的には、各レコードは、キー名１５０１、プロパティ名１５０２、説明１５０３及びプロパティ値１５０４を記憶する（更に部品ｕｋのような他種の情報を記憶しておよい）。これらの情報１５０１、１５０２、１５０３及び１５０４は、部品プロパティ管理テーブル４２２のレコードにおける情報７０２、７０３、７０４及び７０８とそれぞれ同じである。
図１６は、サービス保持プロパティテーブル１６００の構成を示す。
サービス保持プロパティテーブル１６００は、サービス毎に存在するテーブルである。サービス保持プロパティテーブル１６００は、サービスにおいて存在する関係であって、出力値と入力値間の依存関係（マッピング関係）に関する情報を保持する。サービス保持プロパティテーブル１６００は、サービスに存在する依存関係毎にレコードを有する。各レコードは、キー名１６０１、データ型１６０２及びプロパティ値１６０３を記憶する。
キー名１６０１は、依存関係名であり、例えばマッピング対象７１０として記憶される値と同じである。データ型１６０２は、その依存関係に属するプロパティ値１６０３のデータ型を示す。プロパティ値１６０３は、その依存関係に属するプロパティ値（入力値又は出力値）である。
なお、このテーブル１６００は、無くてもよいケースがある。図１３と図１４のテーブルから、“Map1”に対応するデータ型及びプロパティ値を特定することができるからである。但し、直前部品の出力値のエクスポートを利用する場合、このテーブル１６００は必要である。
サービスデバッグは、サービスデバッガ４３２によりサービスデバッグ画面が提供され、そのサービスデバッグ画面が表示プログラム５３２により表示される。
図１７は、サービスデバッグ画面を示す。
サービスデバッグ画面２８００は、サービス情報エリア２８０１と、サービス構成エリア２８０２とを含む。
サービス情報エリア２８０１に、デバッグボタン２８７１と、選択ＵＩ（ユーザインターフェース）２８１１と、部品情報ＵＩ２８１２と、プロパティ一覧ＵＩ２８１３とが表示される。
選択ＵＩ２８１１は、作成済の１以上のサービスからサービスを選択するためのＵＩである。
部品情報ＵＩ２８１２は、選択されたサービスのうち選択された部品（例えばデバッグ対象部品）に関する情報を表示するためのＵＩである。選択された部品に関する情報は、例えば、部品管理テーブル４２１（図１２参照）から取得された部品ｕｋ６０５及び部品名６０２と、その部品のステータスとを含む。
プロパティ一覧ＵＩ２８１３は、選択された部品の部品プロパティに関する情報の一覧を表示するためのＵＩである。一覧として表示される情報は、例えば、部品プロパティ毎に、対応する部品プロパティ管理テーブル４２２（図１３及び図１４参照）から取得されたモード７０５、プロパティ名７０３及びプロパティ値７０８である。また、プロパティ一覧ＵＩ２８１３は、インポートボタン２８５１とエクスポートボタン２８５３とを含む。
サービス構成エリア２８０２に、選択されたサービスの構成が表示される。具体的には、例えば、選択されたサービスが４つの部品で構成されている場合、サービスを構成する部品にそれぞれ対応した部品表示オブジェクト（例えばアイコン）２８６１Ａ〜２８６１Ｄが表示される。また、部品表示オブジェクト間に、対応する部品間の順番の先行を意味する矢印が表示される。また、部品表示オブジェクト２８６１Ａ〜２８６１Ｄに、それぞれ、部品のステータスを表すマーク２８６３Ａ〜２８６３Ｄが表示される。
サービスデバッガ４３２は、例えばサービス構成エリア２８０２を介して、ユーザから部品の選択を受けることができる。選択された部品に対応した部品表示オブジェクト２８６１Ｂは強調表示（例えば異なる色での表示）がされる。
また、サービスデバッガ４３２は、例えばサービス構成エリア２８０２を介して、ユーザからデバッグ対象部品（ブレイクポイント）の選択（指定）を受けることができる。例えば、部品表示オブジェクト２８６１Ｂに対応した２番目の部品がデバッグ対象部品として選択された場合、サービスデバッガ４３２は、部品表示オブジェクト２８６１Ｂに所定のマーク（例えば虫ピンマーク）２８６５を関連付ける。これは、部品表示オブジェクト２８６１Ｂに対応する部品がデバッグ対象部品であることを意味する。
図１７に示したサービスデバッグ画面２８００は、デバッグ対象部品についてインポートが行われる前の画面である。デバッグ対象部品についてエクスポート済の入力プロパティファイルにおいて、例えば、プロパティ名“Destination host”に対応したプロパティ値は、“LocalHost”ではなく“AnotherHost”であるとする。
図１７の画面２８００におけるインポートボタン２８５１が押された場合（インポート操作がされた場合）、サービスデバッガ４３２は、デバッグ対象部品についてエクスポート済の入力プロパティファイルにおける入力値をインポートする。この結果、インポート前における、各入力プロパティのプロパティ値（入力値）は、インポートされたファイルにおけるプロパティ値（入力値）に更新される。具体的には、例えば、図１８に示すように、プロパティ名“Destination host”に対応したプロパティ値は、“AnotherHost”に更新される。また、サービスデバッガ４３２は、インポートの結果を表すＵＩ２８９０を表示する。ＵＩ２８９０には、更新されたプロパティの数と、更新がスキップされたプロパティの数が表示される。
その後、デバッグボタン２８７１が押された場合（デバッグ対象部品の実行操作がされた場合）、サービスデバッガ４３２は、インポート後のプロパティ値（入力値）をデバッグ対象部品に入力することによりデバッグ対象部品を実行する。入力された入力値には、ユーザにより変更された入力値を含むケースもある。サービスデバッガ４３２は、デバッグ対象部品を実行する場合、そのデバッグ対象部品に実際に入力される入力値を含んだ入力プロパティファイルをエクスポートしてもよいし、その入力値の他に実行結果としての出力値を含んだ出力プロパティファイルをエクスポートしてもよい。なお、本実施形態では、手動で（例えばエクスポートボタン２８５３が押されたときに）、プロパティファイルがエクスポートされる。
サービスデバッガ４３２は、デバッグ対象部品の実行結果を表示する。具体的には、例えば、サービスデバッガ４３２は、図１９に示すように、部品情報ＵＩ２８１２に表示のステータスを、“Failed”（実行失敗）に更新し、且つ、プロパティ一覧２８１３における該当箇所に、出力値（プロパティ値）を表示する。
デバッグ対象部品の実行結果としてのステータスが“Failed”の場合、ユーザは、ステータスが“Successful”（実行成功）になるまで、入力値のインポート操作（及び、入力の変更（修正））と、デバッグ対象部品の実行操作とを含んだ一連の部品デバッグ操作を繰り返すことができる。
以下、本実施形態で行われる処理を説明する。
図２０は、サービスデバッグのフローチャートである。
サービスデバッガ４３２は、ユーザからのデバッグ開始指示に応答して、サービスデバッグ画面２８００を表示する（Ｐ３００１）。
サービスデバッガ４３２は、選択されたサービスについて、ブレイクポイントの選択を受け、選択されたブレイクポイントを設定する（Ｐ３００２）。これにより、１以上のデバッグ対象部品が定まる。
サービスデバッガ４３２は、選択されたデバッグ対象部品の入力値をエクスポートする（Ｐ３００３）。この結果の一例が、図１７におけるプロパティ一覧ＵＩ２８１３の表示内容である。また、この結果の一例としての出力が、エクスポートインポートプロパティテーブル１５００（図１５参照）である。
サービスデバッガ４３２は、デバッグ対象部品の実行操作に応答して、選択されたデバッグ対象部品を実行する（Ｐ３００４）。この実行前に、ユーザは、プロパティ一覧ＵＩ２８１３の表示内容におけるプロパティ値を変更してもよい。サービスデバッガ４３２は、デバッグ対象部品の実行の際に入力された入力値を含んだファイルと、デバッグ対象部品の実行結果として出力された出力値を含んだファイルとをエクスポートしてよい。そのエクスポートは、入力値と出力値の両方を含んだファイルのエクスポートでもよい。
デバッグ対象部品の実行結果としてのステータスが“Successful”の場合（Ｐ３００５：Ｙｅｓ）、他にデバッグ対象部品があれば（Ｐ３００７：Ｎｏ）、Ｐ３００３が行われ、他にデバッグ対象部品が無ければ（Ｐ３００７：Ｙｅｓ）、デバッグ作業は終了する。
デバッグ対象部品の実行結果としてのステータスが“Failed”の場合（Ｐ３００５：Ｎｏ）、図２１又は図２２に示すインポート処理が行われる（Ｐ３００６）。その後、再度、Ｐ３００４が行われる。なお、Ｐ３００６の結果の一例として、図１９に示したプロパティ一覧ＵＩ２８１３の表示内容が、再度のＰ３００４で表示されてよい。そして、再度のＰ３００４の結果の一例が、図１９の画面２８００の表示内容でよい。
図２１は、第１のインポート処理のフローチャートである。
サービスデバッガ４３２は、デバッグ対象部品のエクスポートされたファイル（具体的には、Ｐ３００３で出力されたエクスポートインポートプロパティテーブル１５００）から入力値（プロパティ値）を取得する（Ｐ３１０１）。取得された入力値毎に、以下の処理が行われる。
すなわち、サービスデバッガ４３２は、対応する入力値（例えば、Ｐ３００４の直前回（例えばＰ３００３）でエクスポートされた入力値）を、Ｐ３１０１で取得された入力値（例えば、Ｐ３００４でエクスポートされた入力値）に更新可能か否か（取得された入力値を採用可能か否か）を判断する（Ｐ３１０２）。具体的には、例えば、サービスデバッガ４３２は、取得された入力値が、対応する入力条件７０７を満たし、且つ、更新可否が“True”か否かを判断する。この判断の結果が肯定の場合（Ｐ３１０２：Ｙｅｓ）、サービスデバッガ４３２は、対応する入力値を、取得された入力値に更新する（Ｐ３１０３）。
更新不可と判断された入力値に対応する入力プロパティについては、その入力値の入力が必須でなければ（要否７１１が“Required”でなければ）、デバッグ対象部品に対する入力値無しに、デバッグ対象部品の実行が行われてよい。また、入力値がユーザにより変更される場合、変更後の入力値についても、Ｐ３１０２が行われてよい。
図２２は、第２のインポート処理のフローチャートである。
サービスデバッガ４３２は、デバッグ対象部品のエクスポートされたファイル（具体的には、Ｐ３００３で出力されたエクスポートインポートプロパティテーブル１５００）から入力値を取得することと、デバッグ対象部品の直前部品のエクスポートされたファイルから出力値を取得することとのうちの少なくとも１つを実行する（Ｐ３２０１）。取得されたプロパティ毎に、以下の処理が行われる。
すなわち、サービスデバッガ４３２は、Ｐ３２０１で取得されたプロパティ値が、直前部品のエクスポートファイルから出力された出力値の場合、その出力値を入力値として利用可能か否かを判断する（Ｐ３２０２）。具体的には、例えば、その出力値をプロパティ値１６０３として保持するサービス保持プロパティテーブル１６００（図１６）が無い場合、Ｐ３２０２の判断結果は否定となる。一方、その出力値をプロパティ値１６０３として保持するサービス保持プロパティテーブル１６００がある場合、Ｐ３２０２の判断結果が肯定となる。
Ｐ３２０２の判断結果が肯定の場合、サービスデバッガ４３２は、サービス保持プロパティテーブル１６００のキー名１６０１と同じマッピング対象７１０に対応する入力値（例えば、Ｐ３００４の直前回（例えばＰ３００３）でエクスポートされた入力値）を、Ｐ３２０１で取得されたプロパティ値に更新可能か否かを判断する（Ｐ３２０３）。この判断は、図２１に示したＰ３１０２と同じ判断でよい。Ｐ３２０３の判断の結果が肯定の場合（Ｐ３２０３：Ｙｅｓ）、サービスデバッガ４３２は、対応する入力値を、取得されたプロパティ値に更新する（Ｐ３２０４）。
図２１に示した第１のインポート処理と、図２２に示した第２のインポート処理のどちらが採用されるかは、予め決められていてもよいし、動的に選択されてもよい。後者のケースでは、例えば、サービスデバッガ４３２は、デバッグ対象部品のいずれの入力プロパティにもマッピング対象７１０として無効な値が設定されていれば、第１のインポート処理を選択してよい。一方、サービスデバッガ４３２は、デバッグ対象部品のいずれかの入力プロパティにマッピング対象７１０として有効な値が設定されていれば、第２のインポート処理を選択してよい。
以上、一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。
３０１：運用自動化システム ３１１：管理サーバ ３１２：管理クライアント

Claims (11)

  1. （Ａ）複数の部品で構成されており前記複数の部品の実行順序が定義された部品集合全体処理のテストにおいて、実行対象の少なくとも１つの部品について、入力パッケージと出力パッケージとのうちの少なくとも１つを記憶資源にエクスポートし、前記複数の部品の各々は、１以上の処理ステップの集合としての有意な処理のモジュールであって他の部品からは独立しており、各入力パッケージは、その入力パッケージに対応した部品の入力プロパティを含み、各入力プロパティは、入力値を含み、各出力パッケージは、その出力パッケージに対応した部品の出力プロパティを含み、各出力プロパティは、出力値を含み、
    （Ｂ）デバッグ対象部品の順番Ｎ（Ｎは自然数）よりも前の順番の部品を実行すること無しに前記デバッグ対象部品を実行するために、以下の（Ｘ１）及び（Ｘ２）、
    （Ｘ１）前記デバッグ対象部品のエクスポートされた入力パッケージと、順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、前記デバッグ対象部品の入力値、
    （Ｘ２）前記デバッグ対象部品のエクスポートされた入力パッケージと、前記順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、前記デバッグ対象部品についてユーザにより更新された入力値、
    のうちの少なくとも１つを、前記デバッグ対象部品にインポートし、
    （Ｂ）において、
    （ｂ１）前記デバッグ対象部品のエクスポートされた入力パッケージと、前記順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、前記デバッグ対象部品の入力値を表示し、
    （ｂ２）前記表示された入力値のうちユーザから選択された入力値があれば、その選択された入力値の変更後の入力値を受け、
    （ｂ３）（ｂ１）及び（ｂ２）後の入力値を前記デバッグ対象部品にインポートし、
    （ｂ４）前記デバッグ対象部品を実行し、
    少なくとも前記デバッグ対象部品の実行が成功になるまで、（ｂ１）乃至（ｂ４）を繰り返す、
    ことをコンピュータに実行させるコンピュータプログラム。
  2. （Ａ）において、前記複数の部品のうちの少なくとも１つの部品について、入力パッケージを出力パッケージと共にエクスポートする、
    請求項１記載のコンピュータプログラム。
  3. （Ａ）において、前記複数の部品のうちの少なくとも１つの部品について、その部品の順番の次の順番の部品の入力値としてマッピングされた出力値を含んだ出力パッケージをエクスポートする、
    請求項１記載のコンピュータプログラム
  4. （Ｂ）において、前記順番Ｎよりも前の順番の部品を実行すること無しに前記デバッグ対象部品を実行するとは、前記順番Ｎよりも前の順番の部品の各々の実行をスキップすることである、
    請求項１記載のコンピュータプログラム。
  5. 前記部品集合全体処理は、１以上の運用対象装置を含む運用対象システムの運用自動化のためのサービス又はそれのテンプレートである、
    請求項１記載のコンピュータプログラム。
  6. 複数の部品で構成されており前記複数の部品の実行順序が定義された部品集合全体処理のテストにおいて、実行対象の少なくとも１つの部品について、入力パッケージと出力パッケージとのうちの少なくとも１つを記憶資源にエクスポートし、前記複数の部品の各々は、１以上の処理ステップの集合としての有意な処理のモジュールであって他の部品からは独立しており、各入力パッケージは、その入力パッケージに対応した部品の入力プロパティを含み、各入力プロパティは、入力値を含み、各出力パッケージは、その出力パッケージに対応した部品の出力プロパティを含み、各出力プロパティは、出力値を含み、
    （Ｂ）デバッグ対象部品の順番Ｎ（Ｎは自然数）よりも前の順番の部品を実行すること無しに前記デバッグ対象部品を実行するために、以下の（Ｘ１）及び（Ｘ２）、
    （Ｘ１）前記デバッグ対象部品のエクスポートされた入力パッケージと、順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、前記デバッグ対象部品の入力値、
    （Ｘ２）前記デバッグ対象部品のエクスポートされた入力パッケージと、前記順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、前記デバッグ対象部品についてユーザにより更新された入力値、
    のうちの少なくとも１つを、前記デバッグ対象部品にインポートし、
    （Ｂ）において、
    （ｂ１）前記デバッグ対象部品のエクスポートされた入力パッケージと、前記順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、前記デバッグ対象部品の入力値を表示し、
    （ｂ２）前記表示された入力値のうちユーザから選択された入力値があれば、その選択された入力値の変更後の入力値を受け、
    （ｂ３）（ｂ１）及び（ｂ２）後の入力値を前記デバッグ対象部品にインポートし、
    （ｂ４）前記デバッグ対象部品を実行し、
    少なくとも前記デバッグ対象部品の実行が成功になるまで、（ｂ１）乃至（ｂ４）を繰り返す、
    デバッグ支援方法。
  7. （Ａ）において、前記複数の部品のうちの少なくとも１つの部品について、入力パッケージを出力パッケージと共にエクスポートする、
    請求項６記載のデバッグ支援方法。
  8. （Ａ）において、前記複数の部品のうちの少なくとも１つの部品について、その部品の順番の次の順番の部品の入力値としてマッピングされた出力値を含んだ出力パッケージをエクスポートする、
    請求項６記載のデバッグ支援方法
  9. （Ｂ）において、前記順番Ｎよりも前の順番の部品を実行すること無しに前記デバッグ対象部品を実行するとは、前記順番Ｎよりも前の順番の部品の各々の実行をスキップすることである、
    請求項６記載のデバッグ支援方法。
  10. 前記部品集合全体処理は、１以上の運用対象装置を含む運用対象システムのシステム運用化のためのサービス又はそれのテンプレートである、
    請求項６記載のデバッグ支援方法。
  11. 記憶資源と、
    プロセッサと
    を有し、
    前記プロセッサが、
    （Ａ）複数の部品で構成されており前記複数の部品の実行順序が定義された部品集合全体処理のテストにおいて、実行対象の少なくとも１つの部品について、入力パッケージと出力パッケージとのうちの少なくとも１つを前記記憶資源にエクスポートし、前記複数の部品の各々は、１以上の処理ステップの集合としての有意な処理のモジュールであって他の部品からは独立しており、各入力パッケージは、その入力パッケージに対応した部品の入力プロパティを含み、各入力プロパティは、入力値を含み、各出力パッケージは、その出力パッケージに対応した部品の出力プロパティを含み、各出力プロパティは、出力値を含み、
    （Ｂ）デバッグ対象部品の順番Ｎ（Ｎは自然数）よりも前の順番の部品を実行すること無しに前記デバッグ対象部品を実行するために、以下の（Ｘ１）及び（Ｘ２）、
    （Ｘ１）前記デバッグ対象部品のエクスポートされた入力パッケージと、順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、前記デバッグ対象部品の入力値、
    （Ｘ２）前記デバッグ対象部品のエクスポートされた入力パッケージと、前記順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、前記デバッグ対象部品についてユーザにより更新された入力値、
    のうちの少なくとも１つを、前記デバッグ対象部品にインポートし、
    （Ｂ）において、
    （ｂ１）前記デバッグ対象部品のエクスポートされた入力パッケージと、前記順番（Ｎ−１）の部品のエクスポートされた出力パッケージとのうちの少なくとも１つのうちの、前記デバッグ対象部品の入力値を表示し、
    （ｂ２）前記表示された入力値のうちユーザから選択された入力値があれば、その選択された入力値の変更後の入力値を受け、
    （ｂ３）（ｂ１）及び（ｂ２）後の入力値を前記デバッグ対象部品にインポートし、
    （ｂ４）前記デバッグ対象部品を実行し、
    少なくとも前記デバッグ対象部品の実行が成功になるまで、（ｂ１）乃至（ｂ４）を繰り返す、
    計算機システム。
JP2017547206A 2015-10-26 2015-10-26 デバッグを支援する方法及び計算機システム Active JP6421249B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/080089 WO2017072828A1 (ja) 2015-10-26 2015-10-26 デバッグを支援する方法及び計算機システム

Publications (2)

Publication Number Publication Date
JPWO2017072828A1 JPWO2017072828A1 (ja) 2018-03-08
JP6421249B2 true JP6421249B2 (ja) 2018-11-07

Family

ID=58631341

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017547206A Active JP6421249B2 (ja) 2015-10-26 2015-10-26 デバッグを支援する方法及び計算機システム

Country Status (3)

Country Link
US (1) US10235270B2 (ja)
JP (1) JP6421249B2 (ja)
WO (1) WO2017072828A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10496379B2 (en) * 2018-02-07 2019-12-03 Sap Se Facilitated production of code for software testing
JP7073813B2 (ja) * 2018-03-16 2022-05-24 富士通株式会社 制御プログラム、制御方法および情報処理装置
CN109002388B (zh) * 2018-07-17 2021-11-23 京信网络系统股份有限公司 一种调试方法及装置
US11275875B2 (en) 2018-12-27 2022-03-15 Hitachi Automotive Systems, Ltd. Co-simulation repeater with former trace data
CN110543429B (zh) * 2019-09-10 2023-05-16 深圳前海微众银行股份有限公司 测试用例调试方法、装置及存储介质
KR20220124210A (ko) * 2020-01-06 2022-09-13 램 리써치 코포레이션 기판 프로세싱 툴의 다양한 모듈들의 하드웨어 컴포넌트들의 자동 구성

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06139108A (ja) 1992-10-26 1994-05-20 Sharp Corp デバッグ処理方法
US7720670B2 (en) * 2005-05-16 2010-05-18 Texas Instruments Incorporated Saving resources by deducing the total prediction events
US8527958B2 (en) * 2005-05-16 2013-09-03 Texas Instruments Incorporated Profiling operating context and tracing program on a target processor
JP2007072712A (ja) 2005-09-06 2007-03-22 Nippon Telegr & Teleph Corp <Ntt> 利用情報を用いたサービス部品発見システム及び方法
JP2009301352A (ja) 2008-06-13 2009-12-24 Hitachi Ltd テスト装置およびテスト方法
DK2440049T3 (en) * 2009-06-10 2018-02-19 Horizon Orphan Llc GENOTYPE-SPECIFIC PROCEDURES FOR TREATING HUMAN INDIVIDUALS USING 4-METHYLPYRAZOLE
JP2012159952A (ja) 2011-01-31 2012-08-23 Fujitsu Ltd コンピュータプログラム、テスト支援方法及びテスト支援装置
US8522213B2 (en) * 2011-05-12 2013-08-27 International Business Machines Corporation Debugger and debugging methods using breakpoints conditioned on the static identity of data
US9009541B2 (en) * 2012-08-20 2015-04-14 Apple Inc. Efficient trace capture buffer management
US9047404B1 (en) * 2013-03-13 2015-06-02 Amazon Technologies, Inc. Bridge to connect an extended development capability device to a target device
US9780926B2 (en) * 2014-07-08 2017-10-03 Mediatek Inc. Burst OFDMA supporting MU-MIMO
US9779133B2 (en) * 2014-11-25 2017-10-03 Sap Se Contextual debugging of SQL queries in database-accessing applications
US20170075789A1 (en) * 2015-09-10 2017-03-16 Google Inc. Method and apparatus for generating, capturing, storing, and loading debug information for failed tests scripts
US9619366B1 (en) * 2015-11-12 2017-04-11 International Business Machines Corporation Object monitoring in code debugging

Also Published As

Publication number Publication date
US10235270B2 (en) 2019-03-19
US20180189165A1 (en) 2018-07-05
WO2017072828A1 (ja) 2017-05-04
JPWO2017072828A1 (ja) 2018-03-08

Similar Documents

Publication Publication Date Title
JP6421249B2 (ja) デバッグを支援する方法及び計算機システム
US10768978B2 (en) Management system and management method for creating service
US10606581B2 (en) Management system for creating service
CN104424338B (zh) web系统的自动生成装置和自动生成方法
JP6637599B2 (ja) 管理システム及び管理方法
JP5403448B2 (ja) 仮想マシン管理装置、仮想マシン管理方法、及びプログラム
JP2019525373A (ja) テストケースの生成方法
US9558046B2 (en) Computer system and program for prior verification of a workflow program
JPWO2019026248A1 (ja) プログラム開発支援装置、プログラム開発支援方法、及びプログラム開発支援プログラム
JP5403447B2 (ja) 仮想マシン管理装置、仮想マシン管理システム、仮想マシン管理方法、及びプログラム
JP5380895B2 (ja) 管理プログラム、管理方法及び管理装置
JP5403445B2 (ja) 仮想マシン管理装置、仮想マシン管理方法、及びプログラム
US9727362B2 (en) Execution control method, storage medium, and execution control apparatus
JP2019121119A (ja) 計算機システムおよび推奨パラメータ値抽出方法
JP2005050138A (ja) 環境設定システムおよび環境設定方法ならびにプログラム
JP2016170578A (ja) スイッチ装置およびゾーニング方法、並びにコンピュータ・プログラム
JP2013235604A (ja) 管理プログラム、管理方法及び管理装置
JP2004102952A (ja) プログラム開発資源の保存方法
JP2002229785A (ja) Ｇｕｉ設計支援装置および方法およびプログラム
TW201640241A (zh) 通信模擬裝置及通信模擬程式產品
JP2015141604A (ja) 通信システム、サーバ装置、サーバネットワーク、情報処理方法、ネットワーク構築方法、およびプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171019

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180807

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180914

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181002

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181015

R150 Certificate of patent or registration of utility model

Ref document number: 6421249

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150