dotkuwaの日記: 業務フローを作った 3
先日業務フローを作りました。
・自分のやっている業務で、
・いくつかユースケースを決め(登録、更新、抹消とか)
・どの部署が発端となり、どういう書類を用意し、
・どの部署に渡し、承認を貰い、
・事務方でどの一覧を参照・更新し、
・結果をどういう風に返すか
とかです。
業務フローと言えば上流工程の業務分析でやる
事で、自分はやった事が無かったのですが、
一言で言って、
・細かい
・仕様になぞらえるか、プログラミングになぞらえるか
と言えば、是も非も無く後者と言える
・現在の規約から当然に導き出される必要書類、必要操作
をひたすら展開しまくるだけ。
・手抜きをしようとして、フローの線におれおれ上位概念
などを付けてすると、途端に意味が分からなくなる。
・その代わり、手抜きなしにひたすらフローを書き続けると
規約の矛盾が自動的に浮かび上がる。
(なにも考えなくても!)
です。
① ③
自然言語 自然言語
(仕様) (業務)
⇔ ⇔
②
プログラム言語
という
簡略化したV字モデルで言うなら、
・①の仕様バグを②をする事で自動的に検知出来る
と言うのと同じ事だと思います。
#この様な仕様バグの検知は普通、リーダーが握り潰します。
#前回、2例ほど、その知識をユビキタスと出来た例を述べました
#が、そうで無い、千、万、十万の例は握り潰されました。
#かといって、リーダーがその知見をプロジェクト外で出版したら、
#それこそ、不正競争防止法違反です。
この性質は、
・実際に動く程度の細かさ、因果の一方向さを持つ
プログラム言語、フロー
ならなんで有っても具有し(何々型言語に特有という事は無い)
・上位概念・下位概念を考えようとすると途端に、その
良い性質(自動的に仕様バグが検知出来る)が失われる
ものだと思います。
category theoryなど上位概念と連関させようとした
途端に、良さが失われるという事が実感として分かる事は、
第二言語を学ぶ上での良さだと思います。
自然言語との関係性 (スコア:1)
プログラム言語の良さは単純なフローのみで、それ以上の概念を加えない事で
のみ実現するのが事実だとしても、それでは正しさ(仕様との合致性)を言う事が
出来ません。両者の関係性を考えないといけません。
プログラム言語と自然言語は、
・二つの本性を、混合することも分かれることもなく、唯一のシステムの中に有する
関係では無いか?
そして、
・プログラム言語と自然言語が、対応付いた時以外はバグだが、
その方が普通である。バグで無い稀有な状態も、どちらかの言語を少しでも
揺り動かすと容易にバグになる。
という観測から導き出される事実から考えると、
「分かれる」方の動きが強い「混合することも分かれることもなく」状況では
無いか?(分離ドレッシングの様?)
・自然言語だけで自動的にプログラムが出来る。
・プログラムで作るテストを書きさえすれば自然言語と対応付く。
・自然言語の(上位)概念をプログラム言語に直接持ち込むことが出来る。
・合成が出来る。
といった、「混合する」方の動きが強い関係性の記述は
困難では無いか?(短期的中期的には誤謬では無いか?)
それに比べ、
・動いているプログラムを(住所や姓を付けて)単に分け隔てるだけ。
「分かれる」方に掉さす方向
の「オブジェクト」は中位概念の創出に役立ち、根本的に合致しているのでは
無いか?
自動テストは (スコア:1)
自動テストは多くの場合、書くだけで自然言語とプログラム言語の
対応付けを壊すから、
書ければ良いのは皆、合意していても書けないのかも知れない。
「テストを初めに」に馴染めない一番の理由 (スコア:1)
要するに、
・簡略化されたV字モデルでいう、①では「正しさが決まらない」。
・要求として一種勝手に書かれた自然言語の記述は、かなりの箇所で
プログラミング言語と本質的に対応付かない。
・②の最後の方であっても、まだ漏れが検出され得る。
②を二行程に分ければよい話でもない。
・プログラミングが一応完成した時、取りあえず対応付けに足る、
叩かれた、自然言語の有るべき記述が完成する。
・初めにテスト書くことは、「正しさが決まっている」と自らの
責任で宣言するに等しい行為になってしまい、一介のプログラマ
が負いうる責任を次元的にかけ離れている。
・最後になって見なければ解らない正しさを、解ると「言うだけ」なら
ともかく、先回りして、かなりの労力をかけてテストプログラム
を書くのをいい顔する、周りの人間はいない。
からです。