UMLモデリングのエッセンス 第3版: 標準オブジェクトモデリング言語入門
- 翔泳社 (2005年6月1日発売)
- Amazon.co.jp ・本 (174ページ)
- / ISBN・EAN: 9784798107950
作品紹介・あらすじ
UMLについて簡潔に解説したマーチン・ファウラー氏のベストセラー。第3版では、UML2.0に対応し新たなダイアグラムを多数追加。過去5年間の経験を踏まえ、全編にわたってリファインを施した最新版。オブジェクト指向ソフトウェア開発者必携の書。
感想・レビュー・書評
-
リファレンスとして良し。
詳細をみるコメント0件をすべて表示 -
UMLモデリングといっておきながらゴリゴリとモデルを書いてそれに従ってコーディングするというやりかたでなく、チームでの共有のために必要な分だけ書くというスケッチとしてのUMLというやりかたを推奨している。そのためエッセンスというタイトル中の単語が効いてくる。
全体の構成としては、開発プロセスにおいてのUMLの使い方および効果の説明があり、その後UML中の各種ダイアグラムの説明となっている。いざ読んでみると、UMLの全てのダイアグラムを等しく推奨しているのではなく一部のダイアグラムのみを使えば十分というスタンスで主張している。考えてみればがっつりモデルを書いてしまうとその修正も必要になるのでコードだけの修正ですまなくなり二重メンテになり作業としてDRYの減速に反する。よってこの著者の主張にはかなりの説得力がある。
上記の一部のダイアグラムというのはクラス図、パッケージ図、状態遷移図である(シーケンス図、アクティビティ図も含むが前3つに比べて優先度は低い)。 クラス図とパッケージ図は構造図でありソフトの設計に直結することから非常に重要である。状態遷移図も振る舞いと構造を両方表現できる点で有用である。
その他のダイアグラムは執筆当時そこまで使用されていなかったのか、どのように使われて効果があるのか詳細は書かれていなかったものの、上記の特に有用なダイアグラムさえ身につけておけば問題はないだろうと思われる。
いずれにせよ、どのダイアグラムもルールに厳密にすべてを書ききろうとすることを戒めている。冒頭のようにモデルを書くことでそれがコードに直結するような、いわばプログラミング言語としてのUMLが有用であると確信できる場面においてのみで、しいて例をあげるとするとMBDのようなときくらいだろう。それ以外ではスケッチとしてのUMLにとどめておくことが勧められている。
全体の感想としては、スケッチとしてのUMLを実践することを勧めている。しかしそれはルールには最低限のっとった上で余計なことを書かない、全てを書ききろうとしないという意味合いである。ツールとしては、設計を共有可能なものとしてくれる便利で単純なものだが、その場面に適切な情報のみを取捨選択して出力するというのは難しい。そのようなモデルを出力すること、入力として受け取り理解を共有することは、プログラマにそれなりの実力を求めるということだと思われる。そしてそれが伝えたいエッセンスの1つとも思う。 -
UML(Unified Modeling Language)の勘どころを解説した本。類書に比べて薄いのが嬉しい。UMLは多くのグラフを含む規約で、プログラミング言語のように使いこなすのはたいへん。しかしスケッチのために用いるならイメージを的確に伝えるのに便利である。この本は後者の用途に目的を絞り、UMLの基本的な構成の、文字通り「エッセンス」を解説してゆく。
-
大学時代の教科書。
結局、自分の中でしっくり来るUMLの本は見つけられていない。まだ理解不足な分野。 -
読了。さらっと読めた。 "エッセンス"ということで、実例を詳解するというよりは、必要十分なことを簡潔に説明するというスタイル。机の横に常備してリファレンスマニュアル的に使うのかな。 で、この本さらっと読み進めることが出来たんだけど、UMLって独学じゃ難しいんじゃないかなという印象。特に中盤以降、記法が複雑になってくると、"正しく使いこなせる自信がない"。自分はこうだと思っても、実はそういうことじゃないというのが沢山ありそう。師匠についたりチームで確認し合えればいいのだけど。
-
UMLの各図の概要と表記法および使うシーンをまとめた本。
わかりやすく要点をまとめており、UMLの入門書として実用的と感じた。 -
UMLモデルのみでソフトウェアが作れる時代がくるとは思わない。これまでの成功・失敗から学んだこと、これからの方向性を、設計、計画にラフで適切に抽象化してこめて記録する。素早く共有、実践し、軌道修正しながら開発をすすめる。
そのために注意する部分、あえて切り捨てる部分があるのではないか。
1章だけでもUMLの活用方法、つきあい方に関する深い洞察が得られるだろう。
P6
さて、その上で私の立場をはっきりさせておく必要があります。ほとんど必ずと
いってよいほど、私はUMLをスケッチとして使用します。UMLによるスケッチは、
フォワードエンジニアリングとリバースエンジニアリングのどちらにも使え、
概念的観念とソフトウェア的観点のどちらにとっても便利だと思います。
私は細部までフォワードエンジニアリングされた設計図面を支持しません。これを
うまく扱うのは非常に難しく、開発作業の遅れにつながると思っています。
サブシステムのインターフェイスレベルの設計図面を作成することは合理的ですが、
それでも開発者がこれらのインターフェイス間のやり取りを実装するのに合わせて、
インターフェイスが変更されることを予想しておく必要があります。
ブログラミング言語としてのUMLというのは良い考えだと思いますが、うまく
使われるかどうかは疑問です。ほとんどのブログラミング業務において、テキスト
形態よりもグラフィック形態のほうが生産性が高いとは確信を持って言えません。
たとえそうであっても、その言語が幅広く受け入れられるのは非常に困難です。
P67
全体と部分を表すが、実装上の意味はない。Jim Rumbough 曰く、集約はモデリングの気休め薬。 -
社会人一年目にUMLを勉強しようと思って手をとった本。当時はよく分からない部分の方が多かった。再度読み直したい。
-
一先ずこれを読めば、大まかにでもUMLについて理解が出来るようには思う。
利用頻度の比較的高いものについては詳細に、逆に低いものについては簡潔に記載されており、又、相変わらずなジョークを交えた展開は読みやすく、使いやすいものと言える。強いて言えば少し高いか。 -
【図書館報「みずもと」第27号(2008)による紹介】
現在ソフトウェアの設計をするときに描く説明用の図としてはUMLが主流です。UMLとはどのような図か極めてコンパクトにまとまっています。UMLのエッセンスを手短に知りたいひとにこの本はお勧めです。
大鎌広先生
図書館の所蔵状況はこちらから確認できます!
http://mcatalog.lib.muroran-it.ac.jp/webopac/TW00314969