異常系の洗い出し！！

こんばんは。
キテレツです。

FAXアプリケーションの詳細設計を執筆中。
正常系はアレコレと考えられるんですが、問題は異常になった時です。
処理の途中で強制終了されちゃったとか、DBにアクセス出来ないとかディスクにアクセス出来ないとか。

リカバリ方法とか色々考えるんですが、そもそも。。。。

というところが、まだ明確になっていません。
仕様上、完全復活は無理です。
なぜなら、完全復活させるだけの材料が手元に無いから。（プログラムが動いている環境に）

ならば、プログラムが動作している環境で、可能な限りのリカバリを行う必要があります。
それで事足りない場合は・・・根本的な環境づくりから再設計しなければなりません。。

あぁ、、、、まぁ、そんな事は無いと思いますが、重要なポイントを後回しにしてしまっていますね。･･･(･∀･i)ﾀﾗｰ･･･
異常系のリカバリ要求については、もっと早めに詰めておくべきでした。。。orz

ってことで落ち着きました。
環境の残っているファイルとデータベースの整合性をとるところまでをリカバリ作業とします。

FAXの受信を取りこぼしたり、解析をミスると、売上に影響が出る部分です。
注文書とか証書とか契約書とか・・・・大切なファイルが送られてきます。
取りこぼすとか多重に検出するとかは絶対にあってはなりません。

基幹システムにFAX受信したことを正確に伝えて記録を残さなければなりません。
ソフトウェアの動作精度をどうやって向上させるのか。。。監視するヤツが必要だ。

仕様で考えます。
プロセス監視とは違います。
プロセスとしては動作しているけれど、内部的に止まっているとか、暴走している事も考えられるので、プロセスが生きている事に加えて、プログラムが吐き出すログを監視して、正しく動いているかどうかを検証することとします。

マイコンで言えば、WDT的な仕組みが必要かなと思います。
定期的に処理を実施する作りにするので。

監視プログラム側もアレコレと考えなければなりません。
監視プログラム自信が止まってしまうことも考えられますが・・・・同一マシン上にあるので、監視プログラムが死んだ場合は、FAXアプリ側も死んでいると判断することとします。

これ、、どこまで考えるべきなのか悩みどころですが、監視プログラムをさらに監視するプログラムが必要になるとか考え始めるとトドメがつかなくなりそうです。

これをできるだけ洗い出さなければなりません。
今のうちからリストとして書いておきます。

DB接続できないとか、ファイルアクセス失敗とか、ディスクそのものが死んだ場合とか。
その場合のソフトウェアの動きも合わせて残しておいて、、、対応するコードを埋めていかなければ。

です。
異常終了を想定した作りにして、コーディング。

部分的な機能を満たすテストコードを書いて、異常終了時のリカバリを想定して。
詳細設計の仕組みが出来上がったら、テストで書いた部分的なプログラムを合体させて機能を実現。

プログラム書きながらアレコレと気がつく所もありそうなので、できるだけ早く詳細設計をすませなければ。

あぁ、詳細設計ではなく、機能設計も含んでいるなぁ。
機能作るために詳細設計作ったりとか、このへんいつもクチャクチャになりながら雰囲気でやっちゃってます。

本当は、きちんと体型だって順番に仕事しなきゃいけないんですが、、ついつい作業が混ざっちゃいますね。

機能がはっきりしていて、それを実現するための関数について詳細設計ができていたら、機械的にコーディングするだけで完了です。

んが、いつもスッキリとはならず、ごっちゃになっちゃうんですよね。
これ、キテレツの自分への課題です。

金高真悟の奇天烈大百科！！