揺り戻しで、古めの本が読みたくなるパターン。
ということで、UMLのパターンについての書籍に手を取ってみました。
UMLの書き方というと、今はそれに詳しい方の横に行き、「これはこんな風なこと?」という風に直接共有を受けるということが弊社ではよくあります。
ただ、例えばUMTPなどのUMLの問題を解くと、結構癖が強かったりして読み解きにくかったりします。
この書籍ではそういった癖を少し抑えてくれるようなパターンを提示して具体的に説明してくれています。また、パターン、モデル、デザインとは何かということも説明してくれています。
パターンのサンプルの例として、マジカルナンバー7±2をわかりやすい図を作成するときのパターンとして出してくるのはわかりやすかったです。そして、モデルを書いたとき、指摘として挙がること、もうすでに自分自身がモデルを書くときに考慮していることも書かれていたりします。(特に初期モデルでは、スタイルのパターン…。ものによっては、ツールで解決されているものもあります。)
パターンのカテゴリ
- スタイルのパターン:UML図のグラフィック品質に影響する11個のパターン
- 実体のパターン:モデルを正しく創造的なもの(有効で意味のあるもの)にするための11個のパターン
- ドメインのパターン:実際のソフトウェアにつながる本格的なモデリングを行うための8個のパターン
- 製品のパターン:システムの論理的/物理的な現実をモデル化するための10個のパターン
- コンポーネントのパターン:ソフトウェアのデプロイに関する8個のパターン
スタイル、実体はいずれも、モデルのイディオムに該当するものだそうです。
良く弊社で話が上がるように、まず表記があっているか、意味が通るモデルかといったことをチェックするパターンが多い印象です。
ドメインはエンドユーザーにとって意味があり、より妥当かという意味があるモデルにするためのパターンが多かったです。
文書内では、パターンのレベルとして下記のような位置づけで紹介されています。
基本は、低いレベルのパターンから実践していくと良さそうですが…一番難しくて大事なのはドメインという…。
パターンのレベル
UMLでモデルでこれってどんな風に書くんだっけ?
とちょっと考えたことのある方は手に取ってみて下さい。
「なぜシステムモデルを作るのか」、「モデルの用途はなにか」といったことに本書は答えてくれています。それは、「共同で設計プロセスを実施するときにそれらを理解するためのツール」だそうです。言語なのでそうだよねと個人的には納得しています。
皆さんはいかがでしょうか?