関数の呼応関係のみで、
関数の呼応関係のみで、因果関係を表そうとしても、
- プログラムの関数はどれも同列レベルで、
- すべて結果に過ぎず、
- 事前知識も交絡因子も消えてしまう。
- COBOLで出来たシステムが時代を経るごとに、訳が分からなく成るのも、これの徹底のせいでは？
要するに、関数の呼応関係は、相関関係しか表現できない、とか？
UMLがダメな理由
UMLがはかばかしく無い、理由も、
- どの様な原因でそのクラス図か？ とかを書かず、
- 事前知識も交絡因子も消えてしまう。
要するに、UMLは、相関関係しか表現できない、とか？
プログラミング言語の限界
プログラミング言語は、変数を使うので、
- 視点が上がらない、
- アイスクリームを食べるとか、水難事故が起きるとかを表現すると、気温（または季節）を同時に、同システムでは表現できない。
- それがプログラミング言語の限界？
- （特定のプログラミング言語でプロモーション目的で勝手に言っているだけのやつでは無い本当の）高階関係を表現出来ないのでは？
- アイスクリームを食べるとか、水難事故が起きるとかより、気温（または季節）の方が、階位が高いのでは？
- 別に、気温（または季節）にフォーカスした、プログラムも有りでしょうけれど、そうすると、今度は、アイスクリームを食べるとか、水難事故が起きるとかが埋没してしまう。
で、
- 視点（WBSのレベル）の上下関係を切り口とした、レベル１からレベル１００や、１億でも、表現できる、それを表現するのが主目的で有る所の、
- プログラムの各手続き（関数も含めた、プログラムの部分）を結果とした際の、原因についての記述としての、因果ダイアログ
こそ、
- 最終的に設計書を捨てた、プログラムの呼応関係のみの”残骸”プログラム
や、
- 視点（WBSのレベル）を±２位しか拾えない、直接的に、事前知識も交絡因子も表現できない、UML
に対する、必須となるべき補完資料だと思います。
結論
これからも「プログラミング分野ならではの、数学的具体化」の不当な欠落でプログラミングが嫌いになる人は存在し続けることでしょう。
