プログラミングの技術的制約とは何に起因するのか
私は昔からプログラミングについて、因果推論により「確率から因果に」変換すると言う理論が役に立つのでは無いかと思っていました。*1
確率とは要求であり、因果とはプログラミングです。
もちろんプログラミングと統計学は、恐ろしく相性が悪いので、（統計的因果推論の様に）因果推論の際に統計学の力を借りて大局的に調査をするのはしずらいと思いますが、非巡回有向グラフ(DAG)と言う因果推論の1つの道具は、非常に有効だと思います。
何十年も前から「ペトリネット（Wikipedia 日本語版）」と言う表記方法も有りました。これは離散分散システムの記述だと言う触れ込みですが、
そもそもDBを使ったWeb画面による入力システム自体が、複数の場所（ブラウザー）から合い互いに示し合わせたりせずに入力する訳ですから、これだけでも離散分散システムです。
端的に言って何に起因するのか？
- 計算に必要な値が揃わないと計算出来ない
- 計算に必要な値は常に手に入る訳ではない
- 後から使いたければ、手に入る内に別に記憶しておく必要があるが、記憶域は無限ではない
からだと思います。
それをややこしく表現するとペトリネットの様な、因果推論の様な世界になると言う訳です。
プログラミング開始時点では計算結果が50だろうと100だろうと50歩100歩であり、計算に必要な値を揃えるのこそが大変で、大変さの克服の結果、プログラムに人間が自然だと思う「意味」とのズレが生じるのです。
なぜUMLのパッケージだと、まともな名前に近づくと考えるのか？
javaのパッケージやjavascriptのパッケージャは、1カタマリの機能を読み込む単位です。それに対し、UMLのパッケージは、
- 何の制限もなく、（典型的にはクラスといった）モデル要素を集めるだけ
です。これはクラス数が少ない、お試しで作った様なシステムでは完全な役立たずに見えますが、クラス数が50を超える様な実用的なシステムでは必須の位置付けになります。
極論するなら、
訳ですし
訳です。
UMLのパッケージはクラス（など）に対して、
- 問題からの角度はそのままで、
- 遠ざかり、解像度が落ちる
視座にあると言う位置付けだと思います。プログラム内部の事情から離れて、人間が付けたい名前に寄せたいと思うなら、値を手にいれると言うレベルからは遠ざかるしかないのだと思います。
値を手に入れると言う機能を無視すれば良いのでは無いか？
否だと思います。万能な、値を即時に手に入れてくれる何かがあるとは思えません。
値を手に入れる手間もプログラミングの内です。
- それも含めた上で、
- それが見えないレベルまで視座を引いたもの
がUMLのパッケージだと思います。
結論
UMLのパッケージは後知恵となり、かなりクラス等が出来上がってからの話になると思います。「（せめて）名前をつけたい」と願う素人の出番は有りません。
ですので、これからも「まともな名前をつけさせてくれず、意味がわからない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
