2012年12月09日

UMLの有用性が理解できない

仕事でUML書いてます。ま、仕事の話なんてつまらないことだらけなんだけど、その中でもつまらないのは管理業務ドキュメント。そのつまらないドキュメントの仕事で、今発注元からはた迷惑な流れが出てきています。UMLをしっかり使えと。
 
UMLは、国際的に規格が統一されたプログラムの図の描き方で、13種類くらいの図があるそうな

http://ja.wikipedia.org/wiki/%E7%B5%B1%E4%B8%80%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E

そんなにいっぱい覚えられるわけないんで、普段は基本設計書にユースケース図、情報受け渡しにシーケンス図を活用して、あとはフローチャート代わりにアクティビティ図を使うくらいかな。

このなかでUMLを活用してから統一的になったのはせいぜいシーケンス図くらい。ユースケース図なんて表現力がたりないから落書きで補ったりしてるし、アクティビティ図はこれ本当にフローチャートの再発明じゃん

Javaとかでクラス設計をしっかりするようになるとクラス図とか使うようになるの?でもうちのプロダクト、C++をベタ書きしてるようなやつで一切クラス設計とかされてないんだけど。

その割に発注元はやたらに熱心で、矢印の先が三角になってないけどこのメッセージは同期的だよねとか細かいこと突っ込む。いやそれ非同期だとか同期だとか本質と関わりないしっつーかその動作どう考えても非同期では実装できないって。それより君の所が提供したフレームワークだと重たいサーバ側の処理をうまく扱えない問題なんとかしてくれないかな。

これ、ソースから自動的にいろんな図を生成してくれる機能が有効活用できればきっと嬉しいんだろうなあ。図はastah、文章はdoxygenで生成しておいて人間が書く場所はRedmineのWikiの注釈だけにしときゃいいのよ。注釈ってのは例えばこの処理とこの処理の共通関数を作ろうとしたがコレコレの原因で依存関係が強すぎるため関数化は諦めるみたいな文章ね。この手の実装しなかったことはソースいくら見てもわからん上に、引き継ぎ者が同じ失敗をやらかすから。

でも現状そういう風になってないし、未だに仕様書はWORDで書かせやがるし表見づらいだろEXCELでデシジョンテーブル確認しろよ。あと差分見づらいだろWikiにしとけ。

うん、なんか話がずれた。とにかくUMLって変に不必要な部分をルール化しまくっていて全然言いたいことが書けないかんじ。設計やら注釈は本文に書いて、図はそれを補強するもののはずなんだけど、図で全部を表現しようとしてる。例えば、出荷用の伝票処理なら

基本の処理の流れ
  1. 出荷商品の分類取得
  2. 分類ごとに伝票が必要かどうか判定
  3. 伝票フォーマットの取得
  4. 伝票出力
で、これの下位分類として
 
電子伝票の流れ
  1. 商品マスターから分類の列を取得
  2. 分類ごとに伝票が必要かどうか判定 ※伝票プログラムから提供された関数
  3. 電子伝票テーブルのレイアウトを取得
  4. 電子伝票テーブルに1行追加 ※伝票プログラムから提供された関数
っていう処理と
紙伝票の流れ
  1. 商品マスターから分類の列を取得
    1. 分類を手修正するダイアログを表示
  2. 分類ごとに伝票が必要かどうか判定 ※伝票プログラムから提供された関数
  3. 差し込み印刷用のWORDファイルを取得
    1. WORDファイルは重い上にめったに更新されないからクライアントにキャッシュがあるか調べる
    2. キャッシュがない場合のみネットワークから取得
    3. キャッシュのメンテナンス処理
    4. つーかWORDがサーバ側で処理できればすっきりするのになんでこんな苦労しなきゃいけないんだよフレームワーク直せよ
  4. WORDファイルに伝票のデータを差し込み印刷出力 ※伝票プログラムから提供された関数
っていう処理があるじゃん?一見上記見るとTemplateMethodパターンで実装されているように見えるけど、別にそんなことなくて実際はネストされたif文がずらずら続いてるだけとかよくあるじゃん?図や設計書は、こういう実装とかけ離れたところで処理の概念だけ書いてレビューアやメンテナの頭をすっきりさせる仕事をするものなのに、UMLはかなり実装よりで、こういうのをif文ずらずらで実装してあったらこのとおりに書けないんだ。

それより基本処理の流れの1.2.3.4.が電子伝票や紙伝票の1.2.3.4.と対応してますよ、っていう概念を何図で書けばいいんだ?処理があるならワークフローが描ける、ワークフローが描けるならアクティビティ図で描けって話だと思うけど、アクティビティ図にTemplateMethodみたいな関係を示す記法はない。というわけで、適当な落書きで補強する。ほら、UML導入の目的だった図法の統一は取れない。なんだそりゃ!

こういうのに比べれば、実際の処理が同期とか非同期とか、実装が継承だか委譲だかは些細な問題なんでございますのにどうしろというんだ。ああ、でも自動生成さえすれば実装と仕様書の整合性が取れないとか言って文句を言う品質保証の人が黙るからそういう効果はあるか。自動生成ほしいなあ。astahフリー版にはないなあ。ていうかJava以外の言語では生成できないなあ。残念
posted by LoyalTouch at 10:39| Comment(0) | TrackBack(0) | プログラム全般 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:


この記事へのトラックバック