きり丸の技術日記

技術検証したり、資格等をここに残していきます。

トップ > 技術 > UMLは覚えておくべき(概念編)

UMLは覚えておくべき(概念編)

技術 設計

UMLは優秀だと思っていますが、何を覚えておくべきで、何は勉強しなくていいのか、という点を自分の言葉で言い換えなおしておくべきか纏めたことはありませんでした。
なので、今回の記事ではUMLの大事さ、覚えておくべきダイアグラムを纏めたいと思います。

なお、この記事を書いた後に、このダイアグラムがすごい！って点を書こうとすると文章量がとんでもないことになりそうだったので、別途記載することにします。

ターゲットについて

ターゲット

  • UMLが不要だと思っている人
  • UMLの概要を勉強したい人

非ターゲット

  • UMLを知り尽くしている人
  • UMLの有効性自体は知っていて、ダイアグラムの詳細を知りたい人

筆者のレベル

  • 積極的にはUMLは使ってこなかった
  • DDDも本は読んだ程度
  • 社会人7年目
  • 独習UML 第4版を読んだ
  • 豆蔵さんのUML研修は1年以内に受けた経験あり。
    ただし、最終日は業務都合で行けなかったので、そこは受けられていない。

UMLとは

様々なモデリングの表記法を統一したもので、Unified Modeling Languageの頭文字をとってUMLと名づけられている。
一度統一された表記法なので、今後も大きく変わることはないと思います。

だからこそ、勉強しても損はないという認識です。

UMLの有効なターゲット

開発者間でのコミュニケーションに役立てるもので、顧客が開発者ではない場合は難しいと思います。
別途、パワポやExcelで説明資料は作らないと、会話が立ち行かないと思います。

逆に、相手がUMLでも会話できるのであれば、開発速度は大きく上がるでしょう。
その経験はないですが…。

開発者がUMLを覚えておくべきと認識している理由

最速で開発者間での共通認識が取れるから。

UMLを使わずに口頭で会話することもあるが、その場では綺麗に内容が決まったように思えても、翌日以降はすぐに内容がかみ合わなくなることもしばしば。
なので、お互いの共通認識として、エビデンスを残しておくことが必要で、その時にUMLを使うことで認識を誤ることなく開発することができる。

A4の紙に記載されたUMLのモデルを文字で会話しようとすると、1000文字以上になることもある。

弊社はそうでもないですが、オフショア等を活用するグローバル社会において、常に第一言語でコミュニケーションが取れるということはないと思うので、少しでも共通的に使えるものは使っておいた方が良いと思います。

DDDとの関係

UMLとは関係ないかもしれないが、DDDと相性はいいと考えています。
私の考えるDDDの本髄は、ユビキタス言語で相手との共通認識を持ちつつ、既存のモデルでは立ち行かなくなった時に、新しいモデルを作成していくことで変更しやすいプログラムにしていくことだと考えています。

変更前と変更後のモデルがどの程度乖離があるのか、変更したことによってどこに影響があるのか等はUML無しで会話することは難しいと考えています。

UMLのデメリット

正直、すべてのUMLを記載したら工数が非常に高くなります。

当然、メンテナンスの工数も高いです。
ただ、資料のメンテナンスの工数が低くはないというだけで、ここがちゃんと設計されているのであれば、全体の工数は大きく抑えられます。
後工程に行くにしたがって、工数が跳ね上がりますからね。

あと、システムを何年運用するか、何年関わるかという点が大事になってくると思います。
1年程度しか関わらないのであれば、正直UMLの作成コストはメリット・デメリット含めてトントンくらいかな、と。

何度も何度も変更を加えるようになって、初めてUMLのメリットが出てくるかとは思ってます。

前の会社では私は開発専門で、運用は別の会社が行ってたりしてました。
正直、今後使わないものを真面目にメンテナンスする気は起きなかったので、かなり乖離ができた状態で納品とかもしてましたね…。

UMLを作るツール

ツールを使ってUMLを記載したことはないです。

plantUMLはUMLの描画ができるだけで、ツールではないですからね…。
基本的には有料版のツールしかないと思っているので、次のプロジェクトでは使ってみたいですね。
あるのであれば、同時編集できるタイプのツールがあると嬉しいと思ってます。

ツールはよく知らないですが、研修では以下の例が挙げられてました。

  • astah*
    • チェンジビジョン社。
      iPad版もあるが、クラス図しか書けない。
  • EnterpriseArchitect
    • SparxSystems社。
      チームでの開発を想定している。
  • Rational Rhapsody
    • IBM社。
      組み込み系で良く使われており、NASAの火星探索機とかもこれが使われてるとか。
  • Papyrus
    • Eclipseで無料で使える。

筆者が考える必要な図(ダイアグラム)

UMLで表現できる図はたくさんありますが、正直不要だと認識している図もあります。

必要と考えている図

静的構造

  1. クラス図
    ここのモデルが誤っていると、プログラムの修正が難しくなってしまいます。
    開発者や事業運営者がお互いに同じモデルを共有することの重要さはここで表現することではないと思うので割愛します。
    詳細は別途記事にする予定です。
    詳細記事

動的構造

  1. ステートマシン図
    オブジェクトの状態を表すための図です。
    同じオブジェクトでも、状態によって違う振る舞いをするので、どんな状態になるのか、どんな状態に変化しうるのかを表現するのは非常に大事です。
    詳細は別途記事にする予定です。
    詳細記事

機能的構造

  1. ユースケース記述
    これを書いていないと、相手に開発してもらったものを受け入れてもらうことが難しい。
    時間はかかりますが、個人的には書いていて楽しいです。
    詳細は別途記事にする予定です。
    詳細記事

  2. シーケンス図
    正直、ツール使わないなら書きたくないですね…。
    plantUMLで書くときはコストが高すぎて、まともにメンテナンスはできないです。
    ただ、これがないとシステムの流れを共有できないので、書いた方がいいです。

不要と考えている図

静的構造

  1. ユースケース図
    ユースケース記述は必要だが、ユースケース図は不要だと思ってます。
    どういうアクターが、どういう操作をするか、という点は必須になると思いますが、図で表現する限界があると思っています。
    細かく動作制御したいのであれば、表形式で整理しないと漏れると考えています。

  2. オブジェクト図
    クラス図を作成する前段階で作成するという認識の図。
    分析をするためにはあってもいいと思いますが、後に残すほどの図かといわれると…？

  3. コンポジット構造図
    クラス図で表現したいことは十分表現できると思います。
    表現力は高くなっていますが、ここまで表現するのであれば、実装したほうが早いと思います。

  4. コンポーネント図
    論理的なコンポジット構成図だそうです。
    コンポジット構成図が不要だと考えているので、こちらも不要だと考えてます。

  5. 配置図
    どこにどうデプロイするのか、っていう環境の記載をするのですが、本の内容は時代の関係でオンプレの内容しかないので、ちょっと微妙。
    クラウドのサービスをどう使うか、ってのが現代的に言うと配置図だとは思うのですが、ちゃんとそこまで書いてくれる内容が見つからなかったので、保留。

  6. パッケージ図
    モデルがどのパッケージにグループされているかを表現する図。
    Javaエンジニアだからか、実装見れば十分わかります。

機能的構造

  1. アクティビティ図
    処理の実行手順を表す図。
    見やすいのですが、シーケンス図で表現した方が良いと思います。
    シーケンス図とアクティビティ図の両方とも作成するコストは高いので、どちらかというとこちらは不要かと思います。

動的構造

  1. コミュニケーション図 オブジェクト間のやり取りを表す相互作用図の一種だそうです。
    シーケンス図が時系列的な観点で作成するのに対し、コミュニケーション図はオブジェクトの要素がどのように関連しているかを表す図。
    シーケンス図があれば、わざわざこちらは作る必要はないかと。

  2. 相互作用概要図 シーケンス図やコミュニケーション図がどういう順番で処理されるかを表現する図。
    個人的にシーケンス図だけで十分だと思っているので、不要。

  3. タイミング図
    組み込み系なら必要だそうですが、ガード条件で十分表現できるのではないかと考えてます。

終わりに

UML自体は古い形式なので、今更勉強するのは不要かと思うかもしれません。
ただし、自分が挙げた「クラス図」「ステートマシン図」「ユースケース記述」「シーケンス図」は有用だと思うので、他の分析手法でもまだまだ使われるんじゃないかと思ってます。

クラス図、ステートマシン図、ユースケース記述は別途記事にしますので、詳しく知りたい方はそちらを参考にしてください。