はじめに

　Tutorial Advent Calendar 2020の5日目、Tutorial Advent Calendar 2020の主宰というか言い出しっぺであるSREの平田が早くも2度めの投稿をさせて頂きます。よろしくおねがいします。

Tutorial Advent Calendar 2020

　本投稿では、実際の簡単な要求と仕様をもとに、UMLを利用してモデリングを行い、抽象的な要求を噛み砕いて仕様とし、更に抽象化や最適化を施しつつモデルに落とし込む一連の流れから要求や要件や仕様の不備の洗い出す方法をお見せします。これはRobotic Crowdの改修タスクをこなす際に、実際に平田が取っている情報整理フローの一端ですので、何かの参考にして頂ければ幸いです。

UMLとは？

　UML(Unified Modeling Language)は、主にオブジェクト指向におけるモデリングを設計または分析する上で用いられるモデリング言語です。モデリングを表現する言語で、一般的にはダイアグラム形式のUMLダイアグラムを指します。

　UMLダイアグラムにはいくつかの種類や形式、またそれぞれに方言的な仕様もあります。例えば、クラスオブジェクトを表現するクラス図やコンポーネントを表現するコンポーネント図、それらの振る舞いを表現するアクティビティ図やシーケンス図といったものがあります。今回、本投稿ではクラス図を利用します。

クラス図とは？

　クラスの名前とプロパティ、そしてクラスの関連性を中心とした、クラスモデリングをするためのモデリング言語です。例えば、以下の図のようなイメージになります。

「Class1」「Class2」がクラス名、「field」が属性、「type」が属性の型です。詳しい書き方はWikipedia等を参考にしてみてください。

モデリング実践

要求

　レンタルビデオの在庫管理システムを作ります。具体的には、レンタルビデオの作品一覧・商品一覧・店舗ごと商品一覧のデータが確認できるようにしてほしいです。店舗ごとの商品一覧には、その商品の作品タイトルも確認できるようにしたいです。

仕様に必要な概念と属性の検討

　まずは、要求をストーリーとして噛み砕いていきます。その際に必要になる概念をクラスとして描いていきましょう。

　レンタルビデオの在庫管理システムなので、まずはレンタルビデオの在庫を具体的にイメージする必要があります。一般的には「ランボー　怒りのアフガン」や「となりのトトロ」といった作品が最初に思い浮かぶと思いますが、これは要求内でも「作品ごとに確認できるようにしてほしい」とあるので、必要なクラスとなります。ちなみに、「涼宮ハルヒの憂鬱　第1巻」「志村けんのバカ殿様　春の巻」といった続き物の作品は、1巻ごとに1つの作品とします(「涼宮ハルヒの憂鬱シリーズ」という作品は作らないというイメージです)。
　固有属性としては、「作品名」が最低でも必要になりそうです。

　レンタルビデオなので、DVDやVHS(懐かしい！！！)の商品1本ずつがそれぞれタイトルごとに0本〜数本は存在する形にすると良いでしょう。そして今回はレンタルの概念が要求に入っていないため、ひとまず「貸し出し」や「破損による削除」といった概念は考慮しないようにします。このように導入する概念や関連性を要求に応じて最適化することは、仕様策定やモデリングの鉄則です。
　固有属性としては、「商品ID」が最低でも必要になりそうです。

　要求では店舗ごとの商品一覧も含まれているので、店舗も必要なクラスとなります。
　固有属性としては、「店舗名」が最低でも必要になりそうです。

　これらを総合すると、以下のようなクラス図が完成します。

この時点で要求から最低限求められている概念(クラス)と属性は網羅しましたが、ご覧の通りで実用には足らない状況です。要求の定義が甘く、要件定義も無いためです。もし実際にもっと概念や属性が必要なのであれば、要求定義と要件定義を更に深く詰めてから再度概念と属性を検討しましょう。

仕様に必要な関連性の検討

　続いて、関連性を考えていきます。クラス図における関連性は多重度とリンクの2つで構成されます。多重度は2つのクラスの数量関係を、リンクは2つのクラスの繋がりを表現します。例えば、以下のような感じです。

この図では、1個の固有のClass1から見て0個〜n個の固有のClass2が存在し、1個の固有のClass2から見て常に1個の固有のClass1が存在することを表しています。

　今回のモデリングでは、まず1つの作品に対して0個〜n個の商品が存在するべきで、1つの商品は必ず1つの作品のみにひも付きます。即ち、「涼宮ハルヒの憂鬱　第1巻」は3本あるかもしれないし、「涼宮ハルヒの憂鬱　第2巻」は2本しか無いかもしれない、という表現が可能になります。一方、「商品ID150025492」という商品は「ランボー　怒りのアフガン」であり、同時に「バカ殿様　春の巻」であることはありえません。

　1つの店舗においては0個〜n個の商品が存在するべきで、今回に関しては特に指定がないので、とりあえずわかりやすいように1個の商品の所属先は必ず1店舗とします(ここが1店舗以上でも要求は満たすことは可能なので、要求・要件の定義の詰め甘いことがこの点からもわかりますね)。「商品ID150025492」は「本店」の商品で、「商品ID200030297」は「川越的場店」の商品と表現できます。一方、「川越月吉町店」には「商品ID150010000」や「商品ID150010001」が所属する、という表現もできます。

　上記の関連性を用いて、いよいよクラス図を完成させてみましょう。

仕様を表現したモデルの完成

　このクラス図であれば、「作品一覧」「商品一覧」「作品タイトルを含んだ店舗ごとの商品タイトル一覧」がいずれも表現可能です。

　今回のクラス図はメソッドや複雑なエンティティを含まないので、このままER図に置き換えることも可能です。もしこれをER図に書き換えたら、更にイメージしやすくなるのではないでしょうか。

この図だと表現できないもの

　要求の最低限の概念と属性のみに絞って作成した図ですので、要求を一歩でもはみ出ると、これだけでは表現できないものが色々あります。例えば、最初に省いた「涼宮ハルヒの憂鬱シリーズ」といった続き物の一覧を取得したい、となると、その作品名のリストが必要になってしまいます。従って、この図だけでは満足に表現できない範囲となってきます。

　そういった過不足を見つけるための情報整理ツールとして、UMLを使ったモデリングは非常に有用です。

注意点

　あくまでUML(クラス図)は、情報整理ツールの1つです。例えば、概念の実体よりもエンティティや概念を操作するメソッドにフォーカスする必要がある場合、表現方法を変えるべきです。1種類の図だけに固執すると正確な情報整理ができない場合も多く見られるので、できるだけ柔軟で広い視野を持つようにしましょう。

結び

　UMLは情報整理をして仕様を考察する際に便利なモデリング言語の1つです。表現方法は様々ですが、抽象的な情報を具体化しつつ最適な形で再度抽象化する、そんな手順の必要になるプロダクトの仕様設計段階では非常に有用なツールです。

　皆さんも困った時にサクッと書いてみることをおすすめします。思考が整理されて、仕様設計の抜け漏れやそもそもの要求要件の甘い部分がはっきりするかもしれません。