会社では開発方法論や、データモデリングといった上流工程のコンサルティングをやっている関係で、ＵＭＬなどを少し勉強し始めました。

とはいっても、あくまでツールなので、肝心なのは、オブジェクト指向の考え方。
ＭｏｔｉｆのＷｉｎｄｏｗプログラムをＴｏｏｌＫｉｔで作った経験があるので、オブジェクト指向の本質は理解しているつもり。

そういう、昔とった杵柄世代にとって、昨今のＵＭＬに代表されるオブジェクト指向設計というのは、とても手間がかかる、概念が勝ちすぎているように見えます。

多分、ほとんどのエンジニアは、よくわからんけれども、ＦｒａｍｅＷｏｒｋを使うと、実際に動くコードがどんどん出来てくるので、便利便利と思って、使っているんだろうなと思うと、恐ろしい気がします。

なんとなく絵を描いていると、仕様になってきて、動くプログラムが出来てしまうということは、”簡単なアプリケーション”であればできるけれど、実業務の複雑さでは、よーく考えないといけないんでしょうね。

モデリングには、静的なモデリングと動的なモデリングがあって、静的なモデリングは、クラス図が主な成果物で、こちらはわかりやすい。ところが、動的なモデリングは、シーケンス図がメインになるのですが、こちらは判りにくい上に、作るの大変。
ＯＯで開発している人はよくドキュメントを作っていると思う今日この頃。
（で、ドキュメントレスの開発が増加しているという悪いうわさも耳にする・・・）

最近では家の会社では、ＤＯＡを使って、昔ながらの設計をまずやって、それからＯＯに持ってくるという方法論を提唱しています。ロバストネス図を使うところが、ちょっと怪しい。（ＵＭＬ３．０ではロバストネス図は正式採用されていないし）
ただ、設計がカチッと固まってから、実装するというシナリオは、なかなか現実的だと思いますが、ＦｒａｍｅＷｏｒｋがどんどん進化して、そういった実装部分が不要になれば、本当に上流の設計だけで開発が進むようになるのかな。　過渡期ですね。

ああ、そういえば、ＳｏｆｔｗａｒｅＦａｃｔｏｒｙの話もありましたね。
究極の共通化・汎用化ですよね。

どうすれば、効率よく、単純化することが可能になるかということでしょうが、
単なる流行のような気もするし。
（流れ図が一番確実だって言うと、年がばれてしまいますね）