この時期に

作成中のプログラムの大幅な仕様変更を決行（するかも）。
今までスレッドの起動に関して、スケジューラを自分で用意してそれにやらせていたが、スレッドをリサイクルするわけでもないし、キャパシティの節約に役立つわけでもないし、ということでこの部分は別にJavaに全部任せてしまっても良いような気がしてきた。よって、スケジューラを削除してしまい、同期の部分だけを今までの仕組みでいこうかと思う。他の人に影響出るかもしれんが、そんなことは知ったこっちゃ無い（まあ、現実にはほとんど影響ないと思うが）。
論文書かずに何やってんだか、俺。


色々、考えた結果、結局、スケジューラは残すことにした。スケジューラを用意しておくことの利点を考えてみると、

• 実行コンテキストごとにスケジューリングを分けることが出来る（Test&nbsConfigurationに役立ちそうだ）。
• スレッドの起動を他のオブジェクトに任せることで、仕事の分担が出来る。
• スケジューラを立てない限り、シミュレーションが行われないので、モードの切り替えが楽。

という点があることに気付いた（他にもあると思うが、今思いつくのはこんなもん）。いくつかの点については他の方法でも実現できると思うが、やはりモードの切り替えが楽という利点には魅かれる。というわけで、このまま現状維持していくことにする。
気が変わるの早すぎ、俺。


そういえば、前にActivityEdgeはStructuredActivityNodeをまたげないみたいこと言ってた記憶があるが、あれは色々議論した結果、ウソっぽいということが判明。どうも、UML2.0スペックは思っていた以上にユルユルに定義してあるようだ。で、その通りに実装するか、もしくは問題が起きないように実装するかは、ツールの設計者に任すみたい感じにしてあるらしい。なんか、この手のスペックって、こういう手法が多いよね…。