モデリングと技術者同士のコミュニケーション
実はアンチUMLだったのですが、最近その必要性を感じます。
なぜアンチUMLなのかと言うと仕様と実装の間にワンクッション置くと言うのに違和感を感じたからなんです。
今まで頭で考えるときも、コミュニケーションをとるときも「なんちゃってクラス図」とか「なんちゃってアクティビティ図」でなんとかなってました。
お客さんに納品するならちゃんとしないといけないけど、技術者同士でコミュニケーションするのが目的なら、通じるなら「なんちゃって」でもいいかなと思ってました。
ただ、最近実装方針をいろいろ話し合う事が多くなってきたので、いよいよちゃんと書けるようになった方がいいのかなぁと。
モデリングと言えばER図なんかはよく見たけど、UMLって流行ってるのんでしょうか?
コミュニケーションである以上、UMLを使える人口が多くないとメリットが少ないし。
技術者同士のコミュニケーションと言えば、デザインパターンは勉強しといた方がいいと思う。
Facade, Composite Factory Strategy Proxy Singletonぐらい覚えといたら今のところ十分に感じます。
たまにFlyweightみたいに「それってパターンだったの？」ってやつもあるけど、そこまで覚える必要はないでしょう。
他の言語、特に関数型言語とかではモデリングやパターンってあるんかな？
Comment
カテゴリ一覧
最近のエントリー
最近のコメント
2008-06-07 Sat 17:12
>実はアンチUMLだったのですが、
あら、そうだったのですね。
私もtmaさんが言われている通り技術者同士のコミュニケーションが取りやすいいい方法、且つ簡単にお客さんに動作説明をしたいときに便利なものが無いかなぁと言う程度でUMLを覚えてきました。
↑だからクラス名やメソッド名をきっちり書いたクラス図やシーケンス図を書くのは苦手です・・・・。日本語でこんなことするんだよ～みたいな（爆
なので、設計図を書くためにUMLを使わないといけないとかそういう考えはまったく無かったりします。なんちゃってでも通じればいいのではないでしょうか（笑
>Fathered, Composite Factory Strategy Proxy Singletonぐらい覚えといたら今のところ十分に感じます。
デザインパターンも基本的に同じ考えで覚えたのですが、お客さんは当然ですが、技術者である人にすら通じないことが多いので、実際にはそれらの意味合い（本質）と使いどころが重要なのではないかと考えています。
偉人達が考えた手法を適度に組合すことで必死に考えなくてもよくなる部分が多いので結果的に工数削減につながるからです。
（Fathered・・・Facade?）
後は多少アンチパターンみたいなのも覚えておくと便利かと思います。
ちなみに、関数型言語でもデザインパターンはありますよ。
結局デザインパターンは、先に述べたようによく使われる手法を"デザインパターン"としてパターン化したもので、設計手法として認識しています。もしかすると言語側から入ると使いどころを見逃すかも！？
2008-06-08 Sun 09:03
>偉人達が考えた手法を適度に組合すことで必死に考えなくてもよくなる部分が多い
これこそがデザインパターンの本質なんだと思ってたんですが、最近はパターンで会話するとなかなか理解が深まると感じる場面が多く感じます。そうなると技術者ですら通じないってのはこうなると寂しいんですけど。
>使いどころが重要なのではないかと考えています
覚えたての頃はついつい嬉しくなって無駄にパターンを使おうとしてたのを思い出しました。
それはさておき、本質はきっちりおさえる様にしたいですね。そこからアイデアが生まれてくる事もあるし。
Fathered>Facadeでした。