Sun Proof Water

by N.Ikegami

Written in Japanese. English Page

更新履歴

Table of Contents

このサイトについて

プログラミング好きの麻酔を生業とするものが、開発したソフトウェア公開の場として開設しました。
開発時に気づいたことも忘備録として記載します。

フリーウェア

AtAGlance

薬物動態シミュレーター
インタラクティブにこだわって作成しました。パラメーター定義は式で与えて実行時評価します（DSLもどき）。 したがって、患者属性に依存したパラメーター定義が可能になるなどの柔軟性があります。

現在のところMac OS X 10.5が動作条件です。 動作確認：　MacBook Pro (Intel Core Duo 2GB) + Mac OS X 10.5.1

システムに害を与える心配はまずあり得ないですが、アプリケーション自身の不具合はあり得ます。 その際には教えていただければ幸いです。

バージョン履歴

開発時に気づいたこと

Cocoa

CoreData

NSManagedObjectContextのUndo - propertyの変更はいつなされるか？

CoreDataを使うとUndo/Redoの実装もしなくてよくてラッキー、と単純に思っていたが、Undo/Redoでpropertyが フレームワークによって変更される（た）ことを知ることができない壁に突き当たった。 propertyの値はフレームワークによって復帰されるのだがpropertyでないインスタンス変数は復帰されない。 再初期化が必要なのだがその適切な機会がないのだ。 NSManagedObject(MO)の初期化にはawakeFromInsertかawakeFromFetchを 使うように、とドキュメントにはあるのだが、削除後Undoで復帰したMOの再初期化にはどちらも使えない。

同じような問題はpropertyでも生じる。relation property先のオブジェクトをKey-Value-Observingしている場合、 property値だけが復帰してもだめで削除によって切れたObservationを復帰しないといけないのだが、MOには property値復帰が通知されないのだ。 調べてみると、以下の投稿でまさに同じ問題があつかわれていた。

http://www.cocoabuilder.com/archive/message/cocoa/2006/11/20/174747

上記で提示された解決法は、自身のrelation propertyをobserveしておくというもの。なるほど。

しかし上記でもだめな場合があった。faulting後releaseされていないMOを再利用することがあるようだ。 その場合faultingからの復帰はやはり知り得ないので上のリンクにあるようなdidTurnIntoFaultで removeObserver:forKeyPath:するのはやめたほうがいい。relation propertyの値が変化 しないので自身のrelation propertyをobserveしていても再observeするチャンスは来ないのだ。
selfへのobservationは放置したままMOがreleaseされても特にエラーにはならないのでremoveObserver: forKeyPath:しないで放置でいいと思う。もしremoveObserver:forKeyPath:するなら deallocかfinalizeだと思うがMOがいつreleaseされるのかは 全くわからないので放置が無難かと。

NSManagedObjectのあとしまつ - relation propertyは使えない

アップルのドキュメントではMOの後始末はwillTurnIntoFaultで行うべし、となっているのだが willTurnIntoFaultが呼ばれた時点でrelation propertyは既にnilになっている。従って relation依存のコードは書けない。

NSManagedObjectはいつ目覚めるか - 他MOに依存する初期化

awakeFromFetchでは他のMOに依存した初期化は不能。なぜならawakeFromFetchの 呼び出される順序は不定であるので、参照するMOの初期化が完了しているとは限らないから。これは発生したり しなかったりするエラーの原因となる。

アップルは、こうした初期化ではperformSelector:withObject:afterDelay:を使用することを 勧めているが、これでは開けただけでドキュメントがdirtyとなるので使えない方法だと思うのだが、どうなのだろう？

そのほか

TCIとOpenSource

TCIポンプ。ソフトウェアの常としてバグフィックスとかバージョンアップとかありそうなものだが聞かない。 ハードウェアのような保守点検と品質保証は必要ないのだろうか。ならベンチレーターはどうなの？IABPは？ と言われそうだが、機器の制御だけでなく薬剤の投与量をソフトウェアが決めるという点において 麻酔科医としてはこだわりたいところである。

しかし、ポンプの注入速度を毎回じっくりチェックしているはずもなく、これからも出来るわけがないので、 やはりソースコードがみれたらなぁと思う（たぶんアルゴリズムはSTANPUMPと似ているんじゃないかと思うのだが）。

STANPUMPは１０年以上Public Domain Softwareとして入手可能な実績あるTCIである。 アルゴリズムに関連する記事はIEEEで閲覧できるうえに、STANPUMP自身もOpenSourceになっている。 ５年ほど前にSTANPUMPの解析を行って、実は小さなバグをみつけた。シミュレーションモードで動作させた際に わずかだが誤差が生じる。Dr.Shaferに報告したところ、この手の報告は初めてとのことであった。

OpenSourceはプログラムの信頼性を向上させると思う。この分野に興味を抱いて関わってくれる開発者は きっと少なくて効果はなかなかあがらない。それでも、ゼロよりずっといいと思う。