3.6 デバッグ

プログラミングにはデバッグがつきものです。プログラムを作り始めてから完成するまでの間に、1つもバグが混入しないことはまずあり得ないことです。そこで必要なのが、デバッグ(バグ取り)です。

デバッグの基本は、状況の判断に必要な情報を得ることです。 フローの動作状況を判断するためには、以下の情報が必要です。

  • ストリームの内容
  • コンポーネントの実行順序
  • フロー変数、セッション変数の値
  • 例外の詳細情報

ASTERIA 3 Service Pack 3 (Build 3.3.2300)からデザイナにデバッグ機能(デバッガ)が実装され、これらの情報を簡単に参照できるようになりました。デバッガを使うと、指定したコンポーネントでフローを一時停止し、そこからステップ実行で1つずつ実行しながらその時の状態を確認することができます。

また、デバッガを使わずに、フローにデバッグログを出力する処理を追加して確認するなどの方法もあります。

デバッガやそれ以外の方法を使って必要な情報を得るためにはどうすればいいのか、サンプルのフローを題材に順を追って見ていきましょう。

3.6.1 ストリームの内容

まず、サンプルのプロジェクトファイル「432_Process_Parallel.xfp」に入っている「パラレル1」フローを開きます。

このフローでは、「品番, 品名, 価格」の3カラムを持つCSVファイルを読み込み、それを「品番, 品名」の2カラムのCSVファイルと、「品番, 価格」の2カラムのCSVファイルへ書き出すという処理をしています。

デバッグ時にはフローのコンパイルが完了していなければなりません。プロジェクトを右クリックして「登録/コンパイル」を選択し、メッセージウィンドウでエラーが無いことを確認します。

フローを選択してツールバーの「フローのデバッグ」ボタンを押し、デバッグの開始ダイアログを開きます。

フロー開始時から実行を確認するために「フロー開始時にブレークする」にチェックを入れて「実行」ボタンを押します。

デバッグを開始すると、フローのタイトルが「(デバッグ中)」となり、デバッグのツールバーとデバッグデータウィンドウが表示されます。上図では、Startコンポーネントで一時停止している状態です。

ツールバーの「ステップオーバー」ボタンを2回押してMapper1まで実行します。

Mapper1で一時停止した状態で、デバッグデータウィンドウのStreamタブをクリックすると前のコンポーネントの出力ストリーム、つまりFileGetコンポーネントで読み込んだinput_data/Parallel1.csvの内容が表示されます。

続けて、「ステップオーバー」ボタンを押してFileSystem_Put_1で一時停止すると、Mapper1で作成したCSVの内容を確認することができます。

ストリームの内容量が多い場合など、デバッグ中に確認するのではなく一時ファイルとして出力して内容を確認したいときは、パラレル処理を応用して確認したい部分にデバッグログとして一時ファイルを取るための処理を追加する方法があります。

サンプルのプロジェクトファイル「300_Lesson.xfp」のフロー名「WebSearch2」に処理を追加してみましょう。

以下にあげた順で、コンポーネントを追加してください。

Component Tab Description
(1) Mapper Control データのマッピング
(2) FileSystem(Put) Storage ファイルへ書き込む
(3) End Control 終了

コンポーネントに設定するプロパティは、以下の通りです。

(1) Mapper
OutputStreamFormat CSV
FieldCount 5
Encoding Windows-31J

(2) FileSystem(Put)
FilePath output_data/log.txt
AppendMode Append

Mapperでは、以下の通りにマッピングします。

(1) Mapper

NOW関数のプロパティは、デフォルトのままにしておいてください。

これでデバッグ用の枝の追加が完了しました。 フローを実行すると、以下のような内容の「log.txt」というファイルが作成されます。

今回の例では、記録時間と、RDB(Get)コンポーネントの出力ストリームの内容をCSVファイルとして出力できていることがわかります。

このように本流とは別の枝を追加する方法は、デバッグ以外にも応用することでより便利なシステムを構築することができますので、ぜひ覚えておいてください。

3.6.2 コンポーネントの実行順序

コンポーネントの実行順序を確認するために、先ほどデバッガでステップ実行してきた「432_Process_Parallel.xfp」に入っている「パラレル1」フローをみていきましょう。

先の手順でFileSystem_Put_1で一時停止していた状態から、続けて「ステップオーバー」ボタンを押すと一方の処理がEndコンポーネントに辿り着きました。

次に「ステップオーバー」ボタンを押すと、パラレル処理のもう一方(Mapper2)に移動します。

このようにコンポーネントを1つずつステップ実行することにより実行順序を確認することができます。

Startコンポーネントからのステップ実行ではなく、特定の場所まで実行してそこからステップ実行するには、一時停止したいコンポーネントの右クリックして「ブレークポイントのトグル」を選択してブレークポイントを設定します。

デバッグを開始した後、ツールバーの「フローの再開」ボタンを押すと次のブレークポイントを設定したコンポーネントまで実行されます。そこから「ステップオーバー」ボタンでステップ実行することができます。

さらに簡単に特定の場所まで実行するには、デバッグを開始した後、一時停止したいコンポーネントを右クリックして「コンポーネントまで実行」を選択します。すると、そのコンポーネントまでフローを実行して一時停止します。

複数の分岐、ループやサブフローを含む処理などのフローの流れを、デバッグ中に確認するのではなく一通りの結果として確認したい場合は、管理コンソールのログで確認する方法があります。

サンプルのプロジェクトファイル「300_Lesson.xfp」のフロー名「WebSearch2」で確認してみましょう。

デザイナの実行ダイアログで、実行モードを「デバッグ」にして、Argumentには「ノート」を入力して、フローを実行してください。

フローが実行されて、その経過がログに書き込まれました。

次に、管理コンソールにログインしてログを確認してみましょう。 ログインしたらログの検索画面が表示されます。 ここで「出力レベル」を「デバッグ」に変更してから、「表示」ボタンをクリックします。

デザイナによって実行されたフローのログは、「セッションが作成されました」から上の部分に並んでいます。

このログを下から追っていくことで、コンポーネントの実行順序を確認することができます。

3.6.3 変数類の値

変数についての詳細は、「4.2.3 変数・定数」を参照してください。

デバッガを使って変数を確認してみましょう。サンプルのプロジェクトファイル「431_Process_Branch.xfp」に入っている「ブランチ1」フローを開きます。

このフローでは、現在時刻から秒の値を取り出し、その値が偶数か奇数かを計算してフロー変数"flag"に代入し、代入された値が0かどうかをブランチで判断しています。そして、判断結果をテキストで出力します。

ツールバーの「フローのデバッグ」ボタンを押してデバッグの開始ダイアログを開き、「フロー開始時にブレークする」にチェックを入れて「実行」ボタンを押します。デバッグデータウィンドウのVariableタブをクリックしてフロー変数"flag"の中身を確認しておきます。

ツールバーの「ステップオーバー」ボタンを2回押してBranchStartコンポーネントまで実行し、デバッグデータウィンドウのフロー変数"flag"をみると、現在時刻から計算された値が設定されているのが確認できます。

さらに「ステップオーバー」ボタンを押して値に対して条件分岐が正しく行われたかをみることもできます。

デバッガを使わずに、先ほどのデバッグ用の枝を追加する方法を応用することで、フロー変数やSQLプロパティなどの変数類の値をログファイルに出力して参照することも可能です。

3.6.4 例外の詳細情報

フローで例外が起きたときには、例外フローが設定されていれば、例外フローが呼ばれます。

例外フローの詳しい動作については、「4.3.5 例外処理」を参照してください。

デバッガを使って例外の詳細情報を確認してみましょう。サンプルのプロジェクトファイル「435_Process_Exception.xfp」に入っている「例外処理1(例外処理あり)」フローを開きます。

このフローは、FileSystem(Get)コンポーネントのFilePathプロパティに何も設定が入っていないため、例外が発生します。

「通常処理1(例外処理あり)」フローで例外が発生したときに呼び出されるように設定されている「例外処理1」フローは、いくつかのシステム変数から例外処理中にだけ設定される詳細情報を取得し、実行日時とともにデバッグログとしてCSVファイルに出力しています。

フローでは、次にあげるシステム変数が追加されています。

システム変数についての詳細は、「4.2.3 変数・定数」を参照してください。

  • ExceptionComponentType
  • ExceptionComponent
  • ExceptionMessage
  • ExceptionDetail

デバッガを使うとデバッグ中にそれらの詳細情報を参照することができます。

ツールバーの「フローのデバッグ」ボタンを押してデバッグの開始ダイアログを開きます。ここでは例外発生時にブレークすることを確認するために「フロー開始時にブレークする」にチェックを入れずに実行してみましょう。

「実行」ボタンを押すと、FileSystem(Get)コンポーネントで例外が発生し、エラーメッセージで例外の詳細情報の一部が表示されます。

「OK」ボタンを押してフローに戻ります。ツールバーの「ステップイン」ボタンを押して例外フローをステップ実行します。デバッグデータウィンドウのVariableタブをクリックして追加したシステム変数をみると例外時の情報が設定されています。

「例外処理1」フローのように、フローで詳細な情報をファイルに出力しておくことは、運用での例外発生時に状態を確認することができてデバッグ時のみならず使えるので、覚えておくとよいでしょう。

仕様書の自動生成

ASTERIAを使えばプロトタイピングから始めてシステムの設計と開発を大幅にスピードアップできるのですが、システム開発の現場には「基本設計書や詳細仕様書などのドキュメントをきちんと残そう」という考え方が残っていることも現実です。

しかしそれでは、いかに開発が早くできてもドキュメントを書くのに時間を取られてしまってなかなか全体のスピードが上がりません。それに何より、コードと詳細仕様書を二重にメンテナンスするのはモチベーションの上がる作業ではないですから、心理的な負担は見かけの工数以上にあるのではないでしょうか。

分厚い詳細仕様書の存在意義については議論が分かれるところでしょう。コストパフォーマンスの観点から、基本設計は書いて欲しいが詳細仕様は書かなくてもいい、となる場合もあります。しかし多くの場合、ケースバイケースでそういう判断ができるユーザはほとんどおらず、結局は不安だからとりあえず通例どおり納品物件として書いて欲しい、となるケースが多いようです。

そこでASTERIAには、この無駄ともいえる工数を劇的に削減するために、作成したフローから仕様書を自動生成する機能があります。

この機能を使うことで、ドキュメンテーション作業の負担が軽減され、ASTERIAデザイナのない環境でのフローのレビューを可能にします。

これまで何度か説明してきているように、ASTERIAにおけるフローは設計図であり、同時にプログラムそのものでもあります。つまり設計と開発を分離していませんから、フローをそのまま注釈つきで出力すれば詳細仕様になるというのが基本的な考え方となっています。

(1) 仕様書のサンプル

仕様書出力の機能を使うには、該当プロジェクトを選択してから「ツール」→「仕様書出力」を選択します。これで、指定したディレクトリにプロジェクトに含まれる全フローのコンポーネント、マッパーなどの設定内容がHTMLファイルとして出力されます。同時にフローやマッパーの画像データがJPEGファイルで同じディレクトリに保存されます。

以下にこうして出力した仕様書の画面イメージを掲載します。

コンポーネントのDescriptionプロパティに適宜コメントを残すことで、仕様書の方にもコメントが反映されます。また、Descriptionプロパティに書き込んだコメント文のうち、1行目だけがフローのキャンバス上で表示され、2行目以降は仕様書出力したときの「説明」欄に表示されます。

(2) Wordへのインポート

なお、仕様書の出力はHTML形式で行われますが、このHTMLデータをWordで開くと縮尺を調整したり印刷したりPDF化したりといった取り回しが容易になります。