雑ノート(仮)

適当なメモ。

「これだけでわかる!初歩のUMLモデリング」を読んだ

UMLについて本を探していたところ、匠道場主催の萩本さんが書かれている本があったので読みました。

読んだ動機

  • クラス同士の関係性を俯瞰できるようになりたい
    • ソースを読んで理解だと時間がかかりすぎる
  • 技術的なコミュニケーションをUMLを使うことによって改善したい
  • 設計を考えるときの思考ツールとしてUMLを使いたい
  • UMLで実装アイディアを説明している本を読めるようになりたい

あと現場で作っている設計書は、SQLやPGを一行単位で日本語で訳したものがほとんどであり、 設計ノウハウを学ぶことはできないという危機感がある。

またこのままでは私が目指す「いいモノづくり」にたどり着けないので、個人の努力で良い設計を目指したい。

UML

クラス図

クラス間のメンバとクラス間の関係性を記述する。 個人的にはUMLといえばクラス図、という印象がある

メンバの可視性

記号 アクセス修飾子 意味
+ public 効果
- private 効果なし
~ なし パッケージ内に効果
# protected サブクラスにのみ効果

関係性

関係性には以下の5種類がある

このリンクが網羅的・簡潔でわかりやすい http://blog.asial.co.jp/712

オブジェクト図

https://www.ogis-ri.co.jp/otc/swec/process/am-res/am/artifacts/objectDiagram.html 調べてみるとインスタンス図と呼ばれることがあるらしく、名称はこちらの方がしっくりくる。 多重度・メンバを全て排除した状態で展開し、クラス名の左にインスタンス名を加えて、インスタンス同士の関連を表現する。

クラス図に対して実際のインスタンス同士を図示するとこうなる、といった点を表現するのに便利。 クラス図を補足するような位置付け。あくまで主役はクラス図であるが、抽象的な思考が苦手であったり、具体例をイメージしたい場合は有効。

シーケンス図

クラスの完の処理の流れを書く インスタンスの生成から消滅までを扱う。

ちょっと使い方は違うけど、クラス設計ではなく、DB設計の時に利用した。 複雑なトランザクションが必要な業務要件をシーケンス図で表したことがある。 具体的には「私のテーブル設計だと、このように処理が進むのでうまくいく」ということを示すのに使った。

コラボレーション図

シーケンス図を抽象化したもの

ユースケース

ユーザーがシステムを何に利用するか?という点を整理した図。 これは読みやすいので、アクターを利用者、ユースケースを業務とかに置き換えれば ユーザーと同じ資料を共有できると思う。

ユースケースモデル

  • 棒人間で表現したアクター
  • 楕円で表現したユースケース を繋げる。

システムのどの機能にどのユーザーが関わるか? を記述する。

ユースケース記述

  • 概要
  • アクター(利用者)
  • メインフロー(処理の流れ)

の3つがワンセットになる。

アクティビティ図

業務フローを表現する 格アクターの行う処理をフローとしてつなぐ

フローチャートっぽいけど、処理の詳細は書かずに、概念レベルでまとめる。 どのアクターの処理がどの順番で行われるか?という点が大事。複雑な承認の流れを整理したい時に使えると思う。

感想

  • UMLはクラス図だけじゃない。
  • 活用の具体例が豊富
  • 上流で開発する人向け?
    • UMLの適用をシステムではなく、ビジネスにフォーカスしている。
    • コードはあまり出てこない
    • 下流工程でのノウハウは少なめ

この本はUMLの説明とそれを活用したプロジェクトの進め方が約5:5で構成されている。

UMLを最初に見たとき(学部の授業)の感想は「なにこれ使えるの?」だった。最初に覚えることが多すぎる割に実践する機会がないのですぐに忘れてしまった。資格試験でたまに見るけど、4択クイズになっているので適当に選んでほぼ正解するし、深い部分の理解は得られない。 そんな矢先、最近デザインパターンの本を読んでUMLに再開した。 クラス図を書け、という章末問題をといた際、汎化の矢印を逆向きに書いてしまったことから、改めて復習する必要があると感じて本書の購入に至った。

この本は実際のシステム開発UMLをどう適応していくか、という視点で書かれているのでかなり参考になった。

クラス図だけじゃない

UMLと言えばクラス図、というイメージがあるが、 ユースケース図などは、使ったことがない。必要でなくなったのではなく、それが表す必要がある概念を別の方法で表しているだけだ。

大体は箇条書きになった文章やよくわからない長文になっているように思う。 そこからユースケース図で表していることを読み取ったり、整理するのに非常に時間がかかる

ユースケース図はエクセルでも簡単に作れると思うので、現状のシステムや要件の分析から始めたい。 そして技術者同士のコミュニケーションに積極的に利用していきたい。 オレオレUMLになってしまうと思うが、なるべくスタンダードなものに近づけたい。

UMLは古くなったのか?

それぞれの図で表せなければいけないことを、長い時間を書けて個人が再発明してしまうだけだと思うので、UML自体を学んで活用することは無駄ではないと思う。

UMLを使ったプロセスの話

著者はユーザーとのコミュニケーションにもUMLを活用するよう進めているが、私は所詮下流担当なので厳しい。