モデリングについてざっくり書いてみた

14日目はゆうたが担当します。

目次

はじめに

この記事でなんとなくわかること

モデリングとは？

ユースケース図

ロバストネス図

シーケンス図

まとめ

参考文献

おわりに

はじめに

モデリングって聞くと心理学とか３Dグラフィック上で動くものとか、色々イメージすると思いますが、ここではシステム開発におけるモデリングについて書いていきます。実装部分を協力会社に頼んだけど、要求と全然違うものが出来てしまった！ということを防ぐために要求定義、設計段階で作りたいシステムの特徴を図に起こして理解しやすくするものです。モデリングしておけば、双方の理解の齟齬が減らせてお互いハッピーになれます。ざっくりとしか書きませんが、興味があれば読んでください！

この記事でなんとなくわかること

モデリングってこんなもの

ユースケース図、ロバストネス図、シーケンス図の特徴(立ち位置とか、こういう時に使うとか)

作成方法は書かないです。世の中にはGoogleという素晴らしい検索サイトがあるので。

今までモデリングやってなかったけど、やってみるかという取っ掛かりになれば。。。

モデリングとは？

業務の流れやシステムの構造や振る舞いなどの目に見えないモノを可視化するために、「モデル」が広く利用されます。モデルとは一般に対象の特徴を捉えて抽象化したものと定義されています。このモデルを作っていく一連の作業をモデリングと呼びます。システム開発現場で主に使われるモデリングは主に7つあります。

・業務フロー図(アクティビティ図)　　//UML

・ユースケース図 //UML

・デシジョンテーブル

・ER図

・ロバストネス図

・シーケンス図 　 //UML

・クラス図 　//UML

7つのうち4つはUMLのモデル図であるように、モデリング記法でUMLはよく利用されます。

一方、ソフトウェア開発方法論の一つであるICONIXプロセスでは、要件定義の成果物であるユースケース図からロバストネス図の活用を通して、設計の成果物であるシーケンス図を作成する手順が定義されているのをご存じでしょうか？

そこで今回は、この3つについてどんな特徴なのか簡単に調べてみた。イメージはこんな感じ。

https://gyazo.com/0d3ba10be2c3fd55bb2840585dc4e5c8

ユースケース図

システムの利用者や関連する外部システムと開発するシステムとの関係を、ユースケースと呼ばれる単位で表現するモデル。

他のモデルと比べて、抽象度が高いから専門知識がなくても理解しやすいのが特徴。要求定義フェーズで大活躍。ユーザーへのヒアリングを通して明らかにしたシステムの仕様を整理する時に使う。

メリット

顧客の要求を明確化できる

システム開発では顧客自身が要求を明確に出来ていなケースがほとんど。ユースケース図を活用することで要求を可視化できたり、隠れた要求を引き出すことが出来る。認識の齟齬を減らすためにも役立つ。また、途中からプロジェクトに参加した人のキャッチアップにも大いに役立つ。

システムの範囲(できること、できないこと)を明確化できる

顧客自身が優先度付け出来ていないことが多い。要求定義を進める過程で要求がどんどん膨れ上がることも多々ある。これが欲しい、あれも欲しい、などなど。仮に途中からプロジェクトに参加した人がいたら、なぜ初めにちゃんと整理してなかったの、と疑問に思ってしまうだろう。ということで、ユースケース図を使ってシステムのできること、できないことをプロジェクト内で共通認識にすることができるので、ぜひ使おう。

デメリット

システムの中身までは分からない。また、納期重視や既存システムの更新、小規模システムの導入とかでは作成する工数を鑑みて作らないこともあり。しかし、後々認識の齟齬があって修正する工数に比べれば、たかが知れていると思うが、、、

＊ユースケース図の例

https://gyazo.com/3b62cebe12b19c047520f48ace8298f1

引用：若手ITエンジニア最強の指南書　日経BPムック

おまけ

ユースケース図を簡単に作成できるツールを載せときます。

・astah：UMLの定番ツール。有料。無料版でastah* communityがあったがなくなったとか。

・draw.io：ブラウザ上で動作する無料のUMLツール

draw.ioで実際に作ってみた。

https://gyazo.com/ca456da49a15fef2481749b7ebabdbb5

図形サイズの調整とかも楽で使いやすそう！保存形式もPNG, JPEG, PDF, HTML etc...とサポートしている。興味ある人はぜひ。

参考サイト

ロバストネス図

業務フロー図やユースケース図などの要件定義フェーズの成果物をもとにシステム仕様を実現する方法を検討する。しかし、上述したようにユースケース図はモデリング抽象度が高いため、モデルから直接実装レベルのモデル(シーケンス図)を作成することは出来ない。そこでシステムの基本的な大枠を示してギャップを埋めてあげようってのがロバストネス図。

このロバストネス図はUMLに正式に定義されていないからかシステム開発現場ではあまり使われないらしい。けどこれ自体はきわめて強力なツールなので、ものにしておきたいツール。

メリット

ユースケースの妥当性を検証できる

ユースケースのクラス図や相互作用図を記述していく過程で、ユースケースのイベントフローの問題が見つかることも少なくない。その仕様から派生して問題が見つかることも。このように、ユースケース図からロバストネス図を書いてみて、穴があったらまたユースケースに付け加えて、ロバストネス図に落とし込んで…と行ったり来たりし足りすることで、より設計の精度を高められる。

実装すべき点を明確化できる

ユースケース図ほど抽象的ではなく、またシーケンス図ほどコンピュータの内部の振る舞いをより詳細に記述しているわけではないので、ちょうどよい抽象度で記述できる。ざっくりどんな実装をすれば、要件を満たすかを把握できる。

ホワイトボードに描きやすい

書かないといったけど、基本的な描き方をいうと、「バウンダリ」「エンティティ」「コントロール」という3種類の構成要素を利用して、システムの基本的な構造をモデル化する。下図のようにアイコンが描きやすい。使ったことがないからわからないが、要素ごとにアイコンがはっきり異なるし、簡単な図だから描きやすい？

https://gyazo.com/bf74b0dc6eeea1904f1bb8e29ed9c7dc

＊ロバストネス図の例

https://gyazo.com/d86c802d3ffc4df72e214d2dfed83b8c

引用：若手ITエンジニア最強の指南書　日経BPムック

シーケンス図

メリット

開発者間の意識共有に活用できる

要件定義書や設計書など正式な成果物として作成したり、ソースコードの実装を意識した処理の流れが書いてあるからレビューに利用することができる。顧客に提出しておけば、後でいざこざがあったときに回避する手段にもなりうる。

保守フェーズや追加要求時に簡単に仕様確認できる

大規模開発になると数万数十万行以上になることも稀じゃない。コーディングした人以外が簡単に仕様を把握できる。ソフトウェア開発の新人がぶち当たる壁として、参加するプロジェクトのソースコードを読んでシステムを理解するってのがあると思うけど、そういう時にもシーケンス図があると役立つ！シーケンス図ありますか、って一言聞くか、ドキュメント探すかであったときは活用したい。

故障の原因や故障発生までの流れを説明できる

処理の流れを時系列で追えるから開発中どこで故障したかが分かりやすい。大規模システム開発に向いている。

デメリット

シーケンス図は、実装に近いモデルのため、モデルの要素も多く作図に時間がかかるのが欠点。

しかし、それを解決すべくPlantUMLやWebSequenceDiagramsなるものも登場してきている。モデリングの効率化も重要だから、興味があれば調べてみると良いと思う！

参考サイト：

＊シーケンス図の例

https://gyazo.com/4debf014196cfddac2849f2fba511836

引用：若手ITエンジニア最強の指南書　日経BPムック

まとめ

モデリングはシステムの特徴を図で示して整理することで、コードを読まなくても分かるようにしたもの。誰に見せるか、何を表したいか目的によって使うモデリング記法は変わってくる。

ユースケース図：ユーザー視点で利用例を取ってシステムで何が出来るか・何ができないかを可視化したもの

ロバストネス図：システム詳細まではいかないけど、システムをこういう感じで処理すればいいよねって目途を立てるもの

シーケンス図：システムをどうやって動かすかについて時間軸で追って可視化したもの

参考文献

若手ITエンジニア最強の指南書　日経BPムック

おわりに

途中からですます調やめました。読みにくかったらすみません。