アンジェロ先生のアルバムを聴きながら年を越してたー。いやー、これはなかなかできない体験だな (普通はしたくないか)。
寒さに暖房が追い付いてません。
今まで台所まで一緒にしてたのをやめて、設定温度をあげたらようやく効くようになった
珍しく技術的なコメントがきたのでそれに答えてみるよ。コメント先は去年の 12/30 の日記。
シーケンス図は OOP 固有でもないのでは。コードと等価な UML が無意味なのは同意。それならコードから生成すればいい。 UML は設計図というよりラフスケッチだと思う。
あれはそもそも「コードとドキュメントが人的、時間的どっちであっても分離してるとダメだよね」というところから始まった話なんで、実は UML の細かい要素は本題ではない。いや、引き金になったのは UML だけど。「UML は設計図というよりラフスケッチ」については俺も同じ事を考えているので、多分過去ログを UML で検索すれば出てくるというか出てきた。こっちでも UML は本題の添え物もいいところだけど。
あとシーケンス図に限らず UML の要素技術は別に UML 固有である必要性のないケースがあるのだけど (ユースケース図やコラボレーション図もそうだな)、 UML はラフスケッチとの立場に立つと実際には UML 固有に類するものは全て必要ではなくなる。多分。そもそも UML に限らず図説ってのは大抵は細かい事を考えずともなんとなく概観がわかってりゃいいので、例えばクラス図を描いたときに (俺はクラス図なんて suck だと思ってるから自発的には使わないけど)、クラス間を矢印なしの実線でつなぐと
という意味になるらしいのだけど、でもこれってそんなに本質的に重要な事か? こんな重箱の隅をつつくような事を指摘する暇があったら、その時間使ってコードの一行でも書けよとかクライアントと話し合って今やってること・作ってるもののレビューしろよとか思う。
こんなものを標準化してなにかいいことがあると思ってる連中は、そもそもの問題意識の持ちかたが間違っていると思う。俺が思うに、記法や用語の食い違いはそこまで大きな問題ではない (統一できてた方がいい場合もあるけど、それは輪をかけて UML の活躍できない場面だ。別の業種の間の文化的なギャップとか、クライアント固有の文化に起因する違いとかでしょ、そういうのって)。本当の問題は、それらが指し示す先の概念で起こっていると思う。作っているものの最終系に対するイメージが食い違っているとか、今問題にしていることが双方で食い違っているとか、それが表面的には「相手の使っている言葉がわからん」とか「この図の使われかたがわからん」という形で出てくるんじゃないのかなあ。
どーでもいいが、昨日は年越しそばの代わりに油そばとかいうものを食ったんだった。うん、一生に一度食えばいいや。
Blogger のインターフェースが読者からも嬉しい方向に改善されてた。
ていうかこれはこの手のサービスなら必須じゃないのかというツッコミはやめとこう。改善されたんだし、ね。