ゼルコバの木システム構成図の仕様変更

相当数のバグが検出されているが,一番悪質なのは部分図の登録/削除画面での操作だ.かなり惨めな状態になっている.一覧表には選択されたカードだけを表示するというオプションは存在しないが,部分図を使えばそれができる.カードを(属性に従って)個別にカラー表示したり,隠蔽したりすることも部分図の拡張機能として考えられる.(個別に隠蔽することは現在も可能だ)部分図はもっともっと活用されなくてはならないので,部分図のロジックはもっと鍛える必要がある.

システム構成図の下半分はほぼ仕上がったとみてよい.きれいな(と言えるかどうかは別として)倒立した木になっている.上半分の部分図を正立した木として表示することができれば,一応システム構成図としては完成したことになる.どういう図柄になるのか?楽しみだ.

▲GENEBOXの父にbaselistを登録しようとしてMakePairListClean中PAIRBOX::getLocationで停止した.その後の操作でも同様エラーが生じる.GENEBOXとbaselistの間には下記のような関係がある.

image

つまり,母であるGENELISTはGENEBOXの異母兄弟となっている.多分上のエラーはこのような状況を反映したものではないかと推定されるが,図面からこの関係を読み取ることは難しい.このエラーは描画のたびに発生すると考えられるので一時的に停止しておくことにする.⇒今日はバックアップを取らずに始めてしまった.仕方ない.いまからでも取っておこう.サンプルは構成図7とした.

▲構成図7を開き,上図の部分図を再現しようとしてSIMPLEGRAPH:TightenHasseDiagramで「孤立ノードが存在する」エラーが発生した.このサンプルは障害サンプルフォルダにコピーしておく.

▲部分図から親族図に戻ったとき,選択されたカードが画面内に入っていない.⇒全体図→部分図→親族図のように遷移したものと思われる.全体図では選択カードは見えている.

おかしい.BASETABLE<CARDLINK, MAXPDB>はクラス(女性)だが,父がCARDTABLEになっている.CARDTABLEは女性のはずだ.⇒確かにそうなっている.いくらレインボーカラーと言ってもこれは流石にまずいのではないか?しかし,同性婚→養子縁組なら起こり得る事象だ.本来ゼルコバの木では異性婚しか認めていなかったが,現在は緩和して同性関係を許容するようになってはいるが,父母の性別はチェックしていなかったのだろうか?anodも父BASETABLEを持っている.

▲カード履歴の動作がおかしい.一度も訪問していないcouplingが中間に入ってしまう.選択状態は全体図・親族図・部分図共通であったはずだが…⇒図面種別を切り替えたとき強制的に基準ノードが選択されているのではないか?⇒図面種別の切り替えでは再描画のため系統並び替えが必ず実行される.カード履歴では系統並び替えの基準ノードを履歴として記録している.(系統並び替え履歴はカード移動履歴に含まれる)

▲UNDOで戻ったときにも「孤立ノードが存在する」が発生した.ここからREDOでも同じエラーになるので状況が再現できているということだけは言える.つまり,UNDO/REDOは概ね動作している.

▲UNDO/REDOでは図面種別の切り替えまでは再現されるが,人名カードの表示は変わらない.⇒仕様的にはやむを得ないとは思われるが…UNDO/REDOはDLLに送ったコマンドが保存されているだけで,カードの切り替えなどには関知しない…これは仕様である.

▲女性カードが父となっているのは子どもカード生成ないしリンク時の動作が誤っていた可能性が高い.クラスノードを親とするほとんどのノードにこの誤りが起きている.

▲部分図でtoplistの父がDATALISTだったのを母に移動して登録したら,新しい女性カードのDATALISTが生成された.これはまずいのではないか?⇒多分DATALISTはtoplistの子どもだったのだろう.このようなケースでは自動的に新規カードを生成する.これが意図しない動作だった場合にはカード合併で修正すればよい.このようなことが起こるのは実際にはレアケースだと思う.

◎現行では系図画面では右クリックしてもメニューは出ない.これは系図画面を出しているのがアプリではなく,バックグラウンドで動作するDLLであるためだが,DLLの持っている情報だけでも出せるものはあるのではないだろうか?系図画面で右クリックメニューが出ればかなり使い易くなると思う.ただし,カード削除一つ取っても単独では実行できない.VBでカード削除パネルを出すなどの動作が必要になる.DLLからVBにコマンドを発出する機構があれば,それも可能となるのだが…

toplistの母氏名にDATALISTを記入するとグリーンになるのは,実在するDATALISTカードを押さえているためと考えられるのに,実動作では新規カードが生成されるというのはどこかに誤りがあるためと考えられる.おそらく,このカードDATALISTが部分図画面上にないことが誤動作の原因になっているのではなかと考えられる.⇒実際,全体図に移ってから登録を実行すると正しいDATALISTにリンクされている.

一応システム構成図の上半分の要素包含図ができた.couplingをルートとする完全な木になっている.

image

もう一方の下半分クラス継承図も再掲してみよう.こちらはNODULEをルートとする倒立した木だ.

image

この2つを合体させたらどうなるか?こんな感じになった.

image

あまりわかり易い図とは言えないかもしれないが,システム全体の構成を一応網羅的に表現しているものと言って差し支えない.ある意味で「何だこんなものか」と思われる向きもおられるだろう.出口検査で出しているダンプを見ると

★出口検査 重婚同類循環=3 系列数=1 非連結=0 多重カード=1 避けられない多重=1 SYM=0 TYW=0 ZTYW=0 ROUND=3 表示数=4 基準ノード=CARDLINK:#338 @33baselist[0]

となっているが,多重カード1というのは明らかに間違っている.少なくともMDBとPDBは多重カードだ.tribelistも多重だし,NLISTも多重だ.当然避けられない多重1とは思われない.重婚同類循環が3もあれば多重が多発するのは避けられないだろう.図面が間違っているのか?計数が間違っているのか?図面もカウントも間違っている可能性もある.サンプルはゼルコバの木モジュール構成図8.ZELとして保存した.

この図面にはミスが相当含まれていると思われるが,欠落もかなり残っているのではないかという気がする.メモリ管理をやっているブロックがそっくり欠けている.タイトル設定に関するクラスも抜けていた.システム機能のうちnoduleで直接サポートしている部分は完全に隠蔽されている.それでも全体を把握するのには多少は役に立つだろう.さて,そろそろ本線に戻らなくてはならない.どこからこんな脇道に紛れ込んだのだろう?描画セグメントを管理するDrawingObjectの本体をどこに配置するのが適切か?という疑問から始まったような気もするが…

▲treeviewの出現は2つあるが,2番目の出現は配偶者であるはずなのに頭に垂線が入っているのはおかしい.これではTREEVIEWの子どものように見える.treeviewの親はcouplingとtribelistだからそこから入ってくるのならわかるが…treeviewの親はtreeviewの最初の仮ノードで受けているから,ここでは親からの連結線は入らないというのが正しい.

image

この図面の煩雑さから得られる教訓は「結婚枠には任意のカードを登録できるようにするべきだった」という反省だ.この点に関しては設計時かなり悩んだが,問題になったのは「先祖ノードを結婚枠に入れるべきか否か」という点だった.と言うのは「婚姻関係とは本人と配偶者と子どもからなる関係であり,これら当事者のうちの少なくとも2つの関係が成立する場合を結婚とする」と定義していたためだ.しかし,だとすれば少なくとも配偶者が存在すれば結婚は成立する.結婚が成立しているのならそれを表象する結婚枠は表示されるべきなのではないか?

image

これはおそらく結婚枠というオブジェクトを実装する中で結婚枠=子ども枠という考え方が固まっていったためではないかと思われる.実際子ども枠の中に存在するのは本来子ども(兄弟)のみであり,配偶者はある種の転入者と考えられていた.人は父と母を持たなければこの世に生存するを得ない.つまり,人に取って父と母は唯一無二の絶対的な存在である.親が無二であることから子ども枠(結婚枠)は親の結婚枠からリンクされることによって(グラフ理論的にも)結婚木を構成する.

当初設計の時点で方針転換していれば,「先祖ノードだけの結婚枠」というのが実装されていた可能性もあるが,そのときは「先祖ノードはかなり特殊な存在であり,結婚枠を持たないのは不自然ではない」という見方をしていたため実装を見送った.しかし,これを拡張して,「結婚枠の中には誰が入ってもよい」としたらどういうことになっていただろう?多分構図の自由度は格段に増したものと思われる.

結婚枠≒FAMILYと考えてよいが,「結婚枠の中には誰が入ってもよい」と再定義したときの「結婚枠」はむしろ「家庭」というより「世帯」ないし「家」という考え方に近いものになる.実際わたしが子どものころ家は相当貧しかったが,孤児(長兄の同級生)を一人預かっていたことがある.むしろこれはよりリアルな生態を表現できる可能性がある.親子関係がなくても結婚枠の中に入れられるようにすると,一般のダイアグラムを描くのにはかなり好都合だ.現行の構成規則を維持しながら,ここまで拡張することは不可能ではないように思われるのだが…

▲この図には確かにかなりの欠陥があるような気がする.下図ではnoduleが選択されているが,多重出現している.これは回避可能な多重であり,本来解決されるべきものだ.なぜこの状態で残ってしまったのか理由はよく分からないが精査する必要がある.

image

▲tajugraph2の子ども氏名欄をクリックしただけで,以下のようなパネルが出る.まったく意味不明だ.他のテキストボックスをクリックした後は収まった.登録されていない名前なら黙って新規カードを作ればよいし,空白氏名のカードを生成することは禁止されている(カード画面の本人タブで氏名を空欄にしてもよい).

image

不用カードを1枚削除した他は何もしていなかったと思う.ダブルクリックで新規カードを生成するという動作はあったかもしれないが…

▲一覧表で所属欄が見えなくなってしまった.また,列幅ゼロの列は可視に切り替えても見えない.⇒原因は分かった.横スクロールすれば見えるようになる.

image

▲NAMEBOX::IsPossibleBTWLeftHandでASSERT_NEVER (rightwife->IsLeftHandBox())により停止した.treeviewの父母ページで母氏名をCOUPLINGとして登録しようとしたところ.UNDOで戻して(ERR4)で保存.kakeizuでも起こる.

▲TRIBEBOX::SetMinorTribeで(primary->getrelation() == REL_SPOUSE)により停止した.starttribeから子どものTRIBEBOXを削除して配偶者に付け替えようとしたところ.UNDOで戻して(ERR5)で保存した.topUndo,UndoCurptrなどでも起こる.

ここまでのところをZTシステム構成図1として保存.longtable RecordListとBASETABLE<CARDLINK, MAXPDB> が孤立ノードになっている.前者はlongtableの配偶者,後者はBASETABLEの子どもとしておこう.いや,その逆だ.BASETABLE<CARDLINK, MAXPDB>がダブってしまった.後からできた方は削除しておこう.

▲一覧表で行クリックするたびに画面を更新しているようだ.

▲couplingの結婚ページで配偶者COUPLINGのページが2あるなかで最初のページが空のままになっている.(ERR6)で保存しておく.⇒読み直しても空白ページは残っている.⇒これはエラーではない.COUPLINGという同一名の配偶者を2人持っていただけだ.

これまではオブジェクトOのクラスCをオブジェクトの子どもとして配置し,その箱の中にクラスメンバーMを格納するというやり方をしてきた.この方式ではクラス名CはクラスメンバーMの入った箱のラベルという感じになる.クラス木の方はこれでうまく作れるが,構成要素木を作ろうとするとかなり無理な形になってくる.クラス間に多段の派生関係がある場合下位オブジェクトMは一つ上のクラスCupperの子どもになっているので,オブジェクトOはCupperと婚姻関係を結ぶことになるが,CupperはオブジェクトOの子孫でもあるので矛盾が生じる.描画は可能だが,クラスCupperの位置にオブジェクトOの仮ノードが配置され不可避的な多重カードが発生してしまう.

以前に試みたことのあるクラスオブジェクトOとクラスCを婚姻させるという方式を復活させてみたところ,うまくゆくことが分かった.なぜこれがうまくゆくのかという理由は下記のような解釈として与えられる.

「システム構成図は構成要素の包含関係図であると同時にクラス関係継承図でもあることを意図して作図される.構成要素は実体(男性)だが,クラス(女性)は抽象でその中のメンバーもまた抽象である.これを調和させるためにクラスとオブジェクトの婚姻という関係を導入する.クラスという抽象はオブジェクトという実体と婚姻することによりメンバーオブジェクトという実体を産出するという構成だ.」

システム構成図の構成規則は二転三転しているが,多分この方式の方が自然な木を構成し易いのではないかと思う.実際,大分形が変わってきた.これまでよりずっといい感じだ.

image

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA