UML 2.0
UML 2.0 の研修を受けてきた。なかなか良かった。
事前に読んでいた本と内容はそれほど変わらないが、
講師の方が現役バリバリの SE の方だった。
しかも現場で実際に UML を使用しているとの事。
ノリが良いと言うのか、ファンキーな発言を連発していた。
「中国の SE が『UML 読めます』なんて言っても信じちゃダメすよ。
彼らの『読めます』は『見た事あります』って意味だから。」
「ホントはドキュメントなんて要らんのですよ。
だってソースコードがそこにあって動いてるんだから。」
「現場で書いてる UML なんてクラス図とシーケンス図しか無いすよ。
たまにユースケース図お客に見せるくらい。ぶっちゃけ。」
国際問題に発展するをいをいな発言は置いておくとして、
軽快なテンポで炸裂するトークは変に的を得ている気がした。
中でも以下の発言は秀逸だった。
「大工さんが仕事をする時に見るものは設計図。設計書とは言わない。
文章で表現されているものはほとんど無いから。何故文章が排除されるか？
それは日本語という言語が表現の曖昧さを許容している言語だから。
UML の真髄は設計内容から文章を取り除き、ほぼ全てを図式化する事にある。」
。。。なるほど！
追伸：
講師は上記の発言の後、
「曖昧な表現だからこそ価値がある部分もある。設計書には向かないが。」
と続けた。好感を持った。
posted by kazufuruk at 10:42:00 午後
4 Comments:
いい講師だね。
我輩も日本語は仕様を記述する言語としては不適切だと思うけど、
何もかも Z 言語で記述してしまう某Ｘer○x の御方には閉口したよ♪
やっぱクラス図とシーケンス図が基本だね〜
>日本語という言語が表現の曖昧さを許容している言語だから。
お客との打ち合わせや資料には、都合の悪いときわざと曖昧さを含ませてごまかすこともよくあったりして。。。
確かに
１．分かり易く
２．出来るだけシンプルに
がベストでしょう。
しかし、PGの設計書に限らず
最も大切な上記の１を怠ってしまっている
単なる「手抜き」なドキュメントしか書かない(or書けない)勘違いな輩が存在するのも現実。
「どう書くか」って前の次元として、「どうすりゃみんな楽にやれるか」を念頭に考えればと。。。
木も、森も、全てを分かりやすく簡潔に表現するというのは永遠の課題ですね。
自分としては UML だけで設計書を完結させるのはちと無理かなと考えています。
ユースケース図、クラス図、シーケンス図あたりを効果的に使い、
文章で補足という逃げ道を用意しておくというのが妥当ではないかと。
sempreff> 何もかも Z 言語で記述してしまう某Ｘer?x の御方には閉口したよ?
そいつは豪快ですね。Z を駆使する自分に酔ってる感バリバリですね。
たのむからフツーに書いてって言ってしまいそうです。
tam> 都合の悪いときわざと曖昧さを含ませてごまかすこともよくあったりして。。。
図式化すると曖昧さが無くなってしまうのが良いのか悪いのかですね。
複雑な処理を図にすると破綻するし。
いや、図に出来ない時点で設計間違っていると言えなくもないか。
on my beat> 「どう書くか」って前の次元として、「どうすりゃみんな楽にやれるか」を念頭に考えればと。。。
なるほど。確かにドキュメントで全て表現できるわけがないんで、
そこに詰め込もうとすると見るのも嫌な設計書になりますね。
それは開発チームの雰囲気作りとか、システムに対する理解度や意識の統一とか、
ドキュメントだけに囚われないトータルなケアも必要という事ですかね。
コメントを投稿
<< Home