抽象クラスのクラス要素はクラス内部でオブジェクトとして展開する

一応ZTシステム構成図の作図規則は決定しているはずなのだが,実際に描画してみると難点が見えてくる.一番大きな欠陥は配置がフラットになってBobjectのような重要なクラスの内部構造が見えなくなってしまうという点だ.これを改善するために次のような方式変更を考えた.

  1. 基本クラス要素をオブジェクトの子オブジェクトとして表示する
    【オブジェクト】→【基本クラスオブジェクト】
  2. 基本クラス要素はクラスと基本クラスオブジェクトの結婚によって産出される子オブジェクトとして表示する
    【基本クラス】+【基本クラスオブジェクト】→【基本クラス要素】
  3. 上記クラス要素の子オブジェクト展開は抽象クラスに限定する

この方式の利点はクラスの記述がその中で完結しているという点にある.つまり,クラスのブロックを作ってしまえばあとはそれを参照するだけになる.しかし,【基本クラスオブジェクト】というオブジェクトは実装上は存在しないものだから,そのようなものを導入することの当否には議論の余地がある.また,基本クラス要素は基本クラスと基本クラスオブジェクトの結婚の産物なので基本クラスオブジェクトが複数存在する場合には図面が不要に煩雑なものになる可能性もある.

これを避けるためにはこのようにクラス内でオブジェクトを展開する対象クラスを抽象クラスに限定するということが考えられる.現システムには(抽象クラスとして実装されている訳ではないので観念的には)抽象クラスとみなされるものは3種存在している.①NODULE,②DATALIST,③Bobjectだ.これらを整理するだけでもかなり見易くなるのではないだろうか?すでにBobjectについてはこの方向で修正を入れているので最後までやってみることにする.

▲人名カード記入中カードを移動する場合はデフォルトで登録した方がよい.キャンセルは右クリックメニュー→再読み込みでできる.

▲ファイルを保存しようとしてMARGLINK::getOnumで(!margbase.otto)により停止した.このあと,例外が発生した.

image

続行不能のため落とすしかない.再起動後バックアップを開いてエラーが出る.このファイルは開けない.

NAMEBOXとMARGBOX定義を入れ直さなくてはならない.context.hで marghgap = framevgap としてみた.⇒全然効いていない!⇒2箇所修正する必要があった.

▲カード入力中フィールドを移動するたびにIMEの文字種が(全角に)変わるのはうれしくない.

▲子ども欄に記入中ページフルになると強制登録して本人タブに移るが,次ページに移れるようにしたい.

▲SUW(Show Under Wear)が出てしまった.(ERR9)として保存したが再現できるだろうか?undoで戻ってもSUWになる.主選択ノードはghostnodeで,基準ノードはcoupling.全体図から部分図に遷移するタイミングで起きた.このファイルは開いただけでSUWになる.

原本の構成図4はエラーの起きる2分前に保存されている.これが開ければよいのだが…開けた.構成図5として保存しておこう.このファイルから部分図に移動するだけで障害が発生する.このバグを取り除かないと作業にならないのではないか?TRIBELIST::MakePairListCleanでMPLCループカウントオーバーが起きている.

SUWを止めて画面は表示できた.このファイルを(ERR10)として保存してみる.どうも部分図自体が不良という感じだ.不可視ノードの座標補正というダンプが出ている.TRIBELIST::DetectCollision 衝突を検出.反例サンプルは136点というかなり大きなものだが,問題点を切り出すために28点までカットした.

image

かなり関係が錯綜しているので一種の「複雑骨折」のような状況に堕ちているのではないかと思われる.もっと削減可能かもしれないが,このくらいでトレースしてみることにしよう.

▲一覧表の並び替えをしただけで系図画面の再描画が発生する.これはまずいと思う.一覧表の順位がトポロジーに影響するということはあり得るが,それも問題だ.父母数はMDBとtreeviewが4,PDBとanodが3であとはcouplingを除いてすべて1だ.結婚を持たないノードが5つある.これを外してみよう.これで23点になった.婚姻を持たないノードが新たに4点発生した.これは子どもを削除されたために単身になったためだろう.19点になったがまだ障害は発生する.結婚を持たないノードはゼロになった.tribelist, pagesetup,  topology, namesort, treeviewが結婚を2づつ持っている他はすべて1だ.いや,おかしい.婚姻数には画面外の関係も含まれているようだ.ともかく16点まで削減できた.10点まで削減して再現する.

image

coupling→treeviewの切れ切れになった垂線辺りが悪いのではないかという気がするのだが…おそらくこれは障害を再現するミニマムなサンプルだろう.coupling直下のfamilytreeは削減できるかもしれない.⇒できた.9点になった.もうこれ以上は無理なのではないか?もう1点削除できた.8点だ.いや,まだいける!6点→5点になった.

image

これ以上削減するのは無理なようだ.これで見ると問題はtribelistとpagesetupの間にある垂線にあるように思われる.本来ならここには不可視の結婚枠が通っていなくてはならないのだが,線分の引き方を見ると座標がずれているように思われる.いや,結婚枠は存在している.

image

結婚枠は8個描画されている.goodsonのいる結婚枠が5つ,なしの結婚枠が3つだ.goodsonは,tribelist,topology,pagesetup,treeview(5),treeview(0).赤で塗りつぶされているのが可視の結婚枠,小さな黄色いボックスは不可視結婚枠だ.

▲カードをクリックしただけで系統並び替えが発生している.⇒この動作で結婚枠オブジェクトのリサイクルが起きている.⇒これではトレース不能なので暫定的に系統並び替えを抑制しておく.

原因は分かった.今日の修正が影響している.marghgapをふかした分の衝突が起きている.連結垂線を通している結婚枠幅と通常の結婚枠幅に差異が出ている.marghgap = 0とすればエラーは発生しない.

image

これは衝突検定の方に問題があるのかもしれない…実際よりふかして交叉を見ているのではないだろうか?いや,違うのではないか?最終出力では衝突は起きていない.どこで調整しているのだろう?

インテリセンスのファイル格納場所の変更

BuildCompleteTreeで衝突は一旦解決し,CheckMargBoxChangedで再発する.「不可視枠を移動」を実行している.これが元凶だ.実行関数はMoveInvisibleBox.⇒応急措置として不可視枠の移動では結果を無視するということにしてみよう.⇒いや,それは動作には関係ない.どこかで何かが競合しているのではないかと思う.

コメントを残す

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

CAPTCHA