スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

UMLについて

読もうと思って溜め込んでいたPDF版の本がたくさんある。以前、あちこちからダウンロードしてきたもので、紙で買うと、結構な額になるものばかりだ。

とはいえ、かなりのボリュームなので、そう簡単には読めない。英語の速読ができるようにならなければ。今のままでは、日本語に比べて格段に遅い。

ハードディスクを整理していると、UMLの本がたくさんあった。積読にしていてもしょうがないので、斜め読みというか、一行読みでぱらぱらと読んでいった。

こういう本はUMLの意味をきちんと書いている。営業の宣伝のためか、妙な誤解が世の中に広がっている。その反動でか、UMLなんて何の役に立つのかというSEも結構いる。これまた誤解を基にしていたりする。

面接に行ったときも、いくつものところでUML書いたことがあるかと聞かれる。UMLが魔法の杖で、問題をきれいに解決し、仕様をきれいにまとめてドキュメント化してくれるすばらしい方法だと錯覚して、そういう技術者がほしいと思っているようだ。

UMLは単なるモデリングの表記法であって、それ以上でもそれ以下でもない。人は概念を整理するときに図を使う。図は構造をわかりやすくするし、概念の骨子を表すことができる。UMLで用意されている図は、そういう図の一部に過ぎない。システム開発でよく使われる図を選んで表記法を統一しただけだ。だからことさらUMLというすごい表記法があるわけではない。UMLでなくても、モデルをきれいに書けるならそれで十分だと私は思う。

クラス図はよく使われるが、しばしば業務アプリでは不要だと思う。フレームワークの部分については、その構造を理解するためにあった方がいいと思う。しかし、不思議なのはstrutsにしろ、tomcatにしろ、そのドキュメントにUMLがほとんど使われていないことだ。これだけUMLが騒がれているのにもかかわらずなぜだろうかと思う。
フレームワークに沿って個々の業務を実現していくところは、例として一つ図に描くだけで、それ以外は同じ形式なので要らない。Actionクラス、サービスクラス、DAOクラスがあり、検索・参照・編集・削除等の機能に沿って同じようなパターンでクラスが作られるだけ。なので一例だけで十分だ。

クラス図は多くのIDEで自動生成するので、ドキュメントのページ数を稼ぐのにはよく使ったが。

シーケンス図については、よく例でクラス単位で書いているが、デザインパターン事態の説明やフレームワークの根幹の部分以外には要らない。そもそもクラス単位で書くと粒が小さすぎてまともにやろうとしたら膨大な量になってしまう。IDEで自動生成できればいいが、私はシーケンス図を自動生成してくれるものを聞いたことがない。
シーケンス図はもっと大きなノード単位で描くことはよくあるので、そのぐらいの粒度で書くのはいいと思う。

ユースケースは、唯一図が中心ではないものだが、これはUML批判派がよく誤解しているところでもある。前に「あんな人の絵書いて何になるんだ」などと言っていた奴がいるが、あの人の絵がユースケースではない。あれはユースケースを抽象化した図であって、ユースケース自体は文書で書く。あの図も、細かく書かなければ、システムの概要を簡単に示すのには役に立つ。そのシステムのユーザと、システムの担当領域を示すことができる。といっても、大したことはないが。

文書で書くユースケースの方だが、これまたどれだけのプロジェクトで使われているのかよくわからない。仕様書としては外部仕様に属するが、仕様のかなりの部分を表現できるが、すべては表現できない。ユーザがシステムを使用するケースをシナリオにして、その事前条件、手順、事後条件等を記述していくのでかなり正確に記述できそうだが、仕様書としてはあまり取り上げたくない。
シナリオ形式にすると、別の目的がある場合には別のシナリオを用意することになり、そうなると内容が重複したりする場合が出てくる。
これはそのままテスト手順書にもできそうだが、例外条件をいろいろと書くと、一つのユースケースの中にたくさんのテストケースが混在することになり、あまりよろしくない。多くの条件が細々と書かれるようになると、わかりづらくなる。かといって代表的なシナリオだけを書いたのでは仕様としては落ち度がある。

実際の外部仕様書で多いのは、やはり画面単位の記述だ。画面に表示する項目、操作をしたときにどうなるかを事細かに記述する。もちろんそのときにはユースケースで記述するような事前条件や例外などについては、きちんと記述する必要があるが。私はユースケースよりもこの方がわかりやすいと思う。

UMLはGUIやWebを前提にしているわけではないので、画面定義や画面遷移図というものは出てこない。よくオブジェクト指向の本で、UIやテーブル定義は変更されやすいので、UMLではまずドメインの部分を決めて、UIやDB実装の部分は後回しにするなどと書かれている。それが当てはまるアプリケーションもあるが、UIから仕様を定義していくのは少なくはない。

UIがメインになるWebアプリケーションの場合、画面定義と画面遷移があれば仕様のかなりの部分を定義できる。図を多用するUMLでここだけ図を排除して文書に徹しているのはなかなか面白い。

関連記事
スポンサーサイト

コメント

非公開コメント

画面処理のないPureJavaでのマルチスレッドプログラム組んだときは、クラス図とシーケンス図のおかげで現場をトンズラするときすごい助かった。UMLもとに引継ぎ一時間で終わらせて逃げた(爆)。UML必須で、UMLがないと、設計も現状把握も引継ぎも全然無理(全体像がわけわからない)って感じだった。

Web系だと画面っていう見えるものがあるから、UMLの必要性ってそんなに感じないよね。フレームワーク使って、コーディングのパターンもほぼ決まりきってたら、おおよそ必要ない気がする(お客用にあとでUML書いてたりして、書いてる当人も感じる意義は政治的な建前だけだったりして)。

しかし考えてみたら、フレームワークそのもののUMLは意義があるし、あったほうがいいよね。でも確かにあんまり見かけた覚えがないな。なんでだろう?つくった側が自分とわかるやつだけわかればいいと思ってるのかな。

作った人間の頭の中にUMLがあるので、彼らにとっては不要。

オープンソースでは、RUPのような手法では開発していないのではと思われる。
プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。