UMLとクラウドのススメ - babydaemons’ blog

デスマっててずっとスライドのバグフィックスが出来なかったのですが、ようやく凡ミス修正とかアジェンダ＆まとめとか出来ましたので、SP1版リリースです。

その前に以前会社で書いたコラム「今さら聞けないUML入門」で復習を

UMLって何なのさ？

Unified Modeling Language（統一化されたモデリングのための言語）です。
言語なんですがお絵描きするのが特徴で、構文・文法は覚えなくても大丈夫です。
但し、お絵描きには約束事があります。これが難しい。だからウサギレベルのもやもやした落書きからスタートするんですよ。

Unified(統一化された)ってどういう意味？

モデリング（モデル化）というアプローチはUML以前にもありました。
みんなバラバラの描き方をしてたのを統一したのでUnifiedです。統一化した恩恵で開発者同士のコミュニケーションが円滑になったり、
同じ絵を見てお客さんとお話しすることで要件定義がスムースに進むことが期待されます。

UMLには13年1ヶ月の歴史がある！

UML 1.0 仕様ドラフト版が1997年1月に公開され、その後2004年10月に2.0へのメジャーバージョンアップがありました。
2007年8月現在のバージョンは 2.1.1です。と言う訳で、それ以前にUMLのお勉強をして暫く離れていた人は涙目なんです。

UMLって難しそうだし、オブジェクト指向を使わない人には関係ない？

確かにクラスを作らない人には不要なものに感じられるかも知れません。
しかし、オブジェクト指向プログラミング(OOP)するか否かは実装の手段であってどのようなシステムでも要件定義は必要です。
設計者の頭の中で順不同に浮かんできたり顧客に仕様盛り込みをお願いされたりする要件を、
視覚的に整理して漏れを防ぐのにマインドマップが有効です。

じゃ、要件定義にマインドマップを使えばあとはOK？

マインドマップで列挙した機能でも、顧客の中で人事部の人と営業部の人では使う機能の範囲は違います。
共通して使う機能もあれば、人事部の人・営業部の人しか使わない機能もあるでしょう。
このような場合はユースケース図を描くとすっきりします。
共通して使う機能があれば、人事部と営業部の両方の要件を盛り込む必要があるので設計が大変になります。
予算の都合で全部盛りこめない場合もありえます。
ユースケース図を描く事でこういう危ないブロックを視覚化することができます。

マインドマップ＆ユースケース図で設計はOK？

OOPしなくても、ソフトウェアシステムには切っても切り離せないものがあります。それは、「シーケンス」と「状態」です。

シーケンスって何なんだ？

シーケンスとは、ソフトウェアのシステムの機能が実行される流れです。
機能の単位は関数・メソッドの場合もあれば、スレッド・プロセスの場合や、
他サーバのDBやクレジットカード会社のホストなど別の計算機である場合もあります。
UMLでシーケンスを描くにはシーケンス図を使います(そのまんまだ)。
例としてAmazonで本を注文することを考え、ログインのシーケンスを妄想してシーケンス図を描いてみました

状態って何なんだ？

ソフトウェアのシステムでは、ネットワーク的に離れた通信相手やデータベース検索や銀行ATMの入金取引での紙幣計数など、
他の要素に作業を依頼して完了を待つ時間帯が存在します。この時間帯の種類を状態と言います。
ある状態から別の状態へ変化することを状態遷移と言います。
状態遷移のきっかけ(トリガー)は、別の要素からの作業依頼受信＆作業結果送信や、
他の要素への作業依頼送信＆作業結果受信であることが一般的でイベントと呼びます。
UMLでは状態遷移を表すのにステートマシーン図(状態遷移図)を描きます。
同じくAmazonで本を注文することを考え、ステートマシーン図(状態遷移図)を描いてみました。