[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”4_5″ last=”no” spacing=”yes” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” border_size=”0px” border_color=”” border_style=”” padding=”” class=”” id=””][fusion_text]UMLを思い出すってばなんだよと思われるかもしれませんが、ちゃんとUMLを読んだのは、UMLが生まれるくらいのころでした。そうです、スリーアミーゴス(Boochさん、Rumbaughさん、Jacobsonさんの3人のこと)が、1995年あたりに一緒になって、UML0.9だかを出したあたりからUML1.0 が登場した時期にしかしっかりと読んでいません。
久しぶりに、UMLを書こうかなとおもいたったわけなんですが、ユースケース、クラス図、シーケンス図だけしか書く気が無かったりしています。
そんな感じで、調べてみると、UMLは、すでに2.xというバージョンになっていて、現時点でOMG(http://www.omg.org/spec/) を拝見する限り、2015/1においてはUML2.4.1というのが最新なんでしょうかね。UML2.5β2なんてものもありそうでした。
まぁ、細かいバージョンは、Professionalな皆さまにお任せして、ここでは、自分たちが必要なことについて、ざっくり調べます。
ちゃんとUML2.4を学びたい方は、左の本があたらしめでしたので、そちらでどうぞ。[/fusion_text][/fusion_builder_column][fusion_builder_column type=”1_5″ last=”yes” spacing=”yes” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” border_size=”0px” border_color=”” border_style=”” padding=”” class=”” id=””][fusion_text]
[/fusion_text][/fusion_builder_column][fusion_builder_column type=”1_5″ last=”no” spacing=”yes” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” border_size=”0px” border_color=”” border_style=”” padding=”” class=”” id=””][fusion_text]
[/fusion_text][/fusion_builder_column][fusion_builder_column type=”4_5″ last=”yes” spacing=”yes” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” border_size=”0px” border_color=”” border_style=”” padding=”” class=”” id=””][fusion_text]
ユースケース
まずは、wikiあたりをさくっと見てもらっちゃったほうが早かったりします。
ユースケース wikpedia
ちょっと難し目に書いてありますが、ユースケース(Use Case)とは、システムの使い方と言いましょうか、機能といいましょうか、作りたいものっていうところなんですね。UMLに含まれる他の記法、例えばクラス図とかと比べて、かなりざっくりとした内容を記載するものなので、オブジェクト指向設計でなくとも、ちょっとした打合せなんかでも使えるのがメリットです。
UML2.5β2のドキュメントに、P672あたりに、ユースケースの例が書かれています。
こんな感じの人と楕円がならんでいると思います。システムの利用者や管理者を「Actor」とよばれる図を使って表現して、「Use case」と線で結び、その機能が利用可能であるということを表現しているもの、と私は理解しています。上記のwikipediaにも書かれているように、どれくらい細かく書いたらいいか?という議題はあるのですが、それぞれのチームでちょうどいい粒度が一番だと思っているので、記法としてのユースケースだけを使えばいいのではないかと思うわけです。
ユースケースの正しい使い方かどうかはわかりませんが、便宜上「Actor」を「利用権限」、「Use case」を「機能」だと考えて、使えたら先で結ぶ、使えなければ線を引かないというのが、わかりやすいのかなと考えています。
このActorというのは、人間である必要はなくて、システム例えばデータベースとかでも大丈夫ですし、Use caseは、機能でなくても、アクションのようなもの例えば出社などでもOKです。私は、ユースケース図が細かくなりすぎちゃうのではないかと思うので、上記程度の機能名称がわかるレベルが、最初は重要なのではないかと思ったりしています。
そもそもユースケース図は、Jacobsonさんが開発したビジネスモデリングに近い図版ですので、なおのことビジネス全体がわかるざっくりとしたレベルでかければいいのではないかと思っています。
もう少し粒度が細かくなってくると、3つの依存関係を書く必要が出てきます。
- <<include>> 一方のUse Caseがもう一方をまるごと含む
- <<extend>> 拡張
- 汎化
複数のUse Caseが登場し、それらのUse Caseがどのような関係かを記述しなければならなくなってからで、いいんじゃないかしらとか思っています。
[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]