| UMLモデリングの本質 |
主にソフトウェア開発の世界で、要件定義から設計までの間に行うモデリングをUML(Unified Modeling Language)でやる方法について、実践例を示しながら解説した本。
設計書の形式が各社バラバラだと分かりにくいし、独自の形式なんていうと必要な項目が漏れたり逆に冗長で書くのが大変になったりするので、一昔前からUMLでやろうという流れがあった。しかし多くの人がUMLを形でしか理解していなかったため、とりあえずこの形式で書こうということでみんなそれっぽく書くことしかしてこなかったと思う。本書はちゃんとUMLの本質を伝えながら実践的にモデリングに利用するためのやり方を解説している。
まずモデリングの歴史から入っているのが面白かった。UMLという形になる前に、この世界の思想家たちが自分たちのやり方を発表しあっている。一時はメジャーなものだけで50種類ぐらいあったらしい。その流れは今も続いているけれど、とりあえずオブジェクト指向のモデリング記法として、スリーアミーゴスと呼ばれる三人組によるUMLが国際標準規格ISOとして規格化された。
UMLは現時点でバージョン2まであるけれど、本書では広く使われている1.4を使っている。UMLは十数種類の形式の図で構成されているけれど、私たちが広くなじみのあるのは大体1.4の時点ですでにあるものだ。
モデリングは顧客の業務に対して行うため、かなり業務寄り（ビジネス寄り）のモデリングを行う図もある。それがユースケース図と呼ばれるもので、アクター（登場人物）がどんなことをするのかを表記する。ビジネスプロセスを記述するのはUMLにとってはどちらかというと守備範囲外で、この分野はまだまだ混沌としており、他の複数の表記法が割拠しているらしい。UMLの中でもユースケース図はあまり重要視されてこなかったのだけど、近年それが見直されてきているらしい。
でも現場から言わせてもらうと、ユースケース図が表記する内容自体は非常に重要だけど、わざわざユースケース図を使用する意味がないため実際にはほとんど使われていない。こんなものはわざわざ図で書くまでもなく、一覧表で十分だからだ。というか一覧表のほうが見やすい上に書きやすい。アクターをあらわす人形の絵なんて馬鹿馬鹿しくて描いていられない。
システム構成を表記する配置図も使用する意味がないというか、もし使われていてもそれがUMLの配置図かどうか分かりにくいし、わざわざUMLの配置図の形式に従って書く必要性を認めないため、ほとんど使われていないと思う。どうせシステムまたはサブシステム一つにつき一枚しか書く必要がないし、それぞれのシステムに応じて自由に書いたほうが分かりやすい。
本書の多くはクラス図を使ってのモデリング方法にページを割いている。最初にどういうとっかかりで描きだせばいいのかということで、要件（客の要望）に出てきた名詞をまず抜きだすという一見拍子抜けながら有効な方法なんかを一から丁寧に説明していて良かった。そこからまず一度描いてみて、できたものを色々突っついて欠点を見つけて直していくサイクルを示していくのは素晴らしい。これぞ本当の意味で解説本だと思う。よく分からないうちに完成形を示して適当な説明でお茶を濁されるような凡百の本とは全然違う。とはいっても、自分が同じ筋道で試行錯誤するわけではないから、他人の思考プロセスをなぞるのは多少苦痛ではあるのだけど、どういう誤りを犯してそれをどう直していくのかを追っていくのは勉強になる。ただ、クラス図ならUMLじゃなくても別にいいじゃんという話にもなる。
サンプルとして、図書館で本を借りるシステム、お酒の問屋が在庫を管理するシステム、航空機のチケットを予約するシステムなんかを実際にモデリングしている。たとえば図書館で本を借りるシステムなら、利用者は五冊まで本を借りることができるだとか、利用者の中で教師だけは雑誌を借りられるだとかあって、それをどのようにモデリングするのかを試行錯誤している。
いったんモデリングしてクラス図を作ったら、試しにいくつかの業務を想定して実際にオブジェクトを作って動かしてみる、なんていうのも実際にやってみている。その過程でオブジェクト図を描くことになる。客にデータモデルを説明するときに、独自の図を描くよりはUMLのほうが胸を張れるんじゃないだろうか。なんて言ってみても、複雑なデータモデルを説明するときにはデータ操作方法を逐一図示しなければならないのでなかなかそうもいかないかも。
UMLには他にシーケンス図やアクティビティ図や状態遷移図なんかがあるけれど、これらについての説明にはほとんど紙面を割いていない。一応一通り説明してくれてはいるのだけど、これらの図はモデリングよりも先の設計に使うので重視していないのだろう。クラス設計次第でシーケンス図が複雑になったり簡単になったりする例が紹介されていて、内容自体は当たり前のことなのだけど分かりやすかった。
というわけでこの本はUMLよりもモデリング自体の方法を解説した内容になっている。その気になればUML以外の表記法に書き換えることも簡単だと思う。だから、UML自体を勉強したいならばこの本はあまり適当ではないと思う。でも、モデリングを通じて実際にどうやってUMLを使っていくのかということが示されるので、ただ形だけUMLを学ぶよりも実になると思う。
一応もっと批判するとしたら、時々狙いがブレて散漫な記述が見られるのが気になった。ひらたく言えば、こういうところでこんなことをわざわざ泥臭く追記しなくても、みたいな感じ。章立てもなんだかあまりきれいではないし。作者の経歴を見たらこの人はもともと文系の人らしい。ユーザ側の立場から情報システムに興味を持って、ついにはこの方面で最高の資格の一つである技術士を取り、大学の講師までやっているみたいだった。悪く言えば説明があまり体系立っていないのだけど、やたらときれいに説明することにこだわっている理系文章よりも分かりやすかった。
この分野、プロジェクトマネジメントなんかも含めて、形ばかり整っていっているわりにあまり成功していないのだけど、なんとかこれらのツールを使ってうまいことやる希望ぐらいにはなっていると思う。結局は使う人次第なのだけど、触れておいたらいくらかは良いと思う。
|
|
|
| 題名 | | * |
| | コメントを一言で要約して題をつけて入力してください。 | |
| 中身 | | * |
| | 必ず日本語を入れてください（SPAM対策）。 | |
| | コメントを書いてください。 | |
| 評価 |
| * |
| | この事物に明確な評価を与えてください。現在のところ 最高(+50) 傑作(+30) まあまあ(+10) いまいち(-10) 駄作(-30) 最低(-50) の六段階評価となっています。0 つまり平凡だという評価を下すことはできませんが、省略することもできます。 | |
