業務の粒度やアクターの役割を明確化し、システムの振る舞いをUMLで表現する（第12回）

要求仕様に対するソフトウェア工学からのアプローチを解説する第2回である今回は、実際にUML図を作成する。自分だったらどう記述するか、考えながら読み進めてほしい。

前回、要求仕様書作成におけるUMLの意義について述べた。今回は、システム化の具体例を設定し、実際にUML図を作成していく。題材として、広告誌を発行するA社における新・広告編集システムを取り上げる。これは、原稿の入稿から編集、印刷に至るまでの業務プロセスを効率化することを目的にしたシステムである。

UML図の作成に先立ち、システム化の背景を説明しておこう。A社はこれまで、図1の業務フローに示すようにFAXを利用して原稿をやりとりしており、そのプロセスを管理するための「注文管理システム」を利用してきた。従来のこうしたやり方には、毎月の通信費がかさむという問題があった。さらに、A社では近くWeb広告に参入する計画だが、その際にも紙の原稿をベースにした編集作業は足かせになることが容易に予想できた。

図1　広告編集の業務フロー

そこで、A社はFAXに加えてデジタル原稿をWeb経由で送受信し、入稿から印刷までの工程を管理できる仕組みを整えることにした。通信費削減のほか、紙に印字された情報をパソコンに入力する手間をなくすことも、新システムの狙いである。

以上の経緯を踏まえたうえで、A社の新システムを「ユースケース図」「クラス図」「シーケンス図」という、UMLの代表的な3モデルで表現していく。

ユースケース図を作成する

ユースケースは、ある目的を達成するためにアクターが実行する個別の操作を示す。ユースケース図には、システムのアクターやそのアクターが業務フローの中でどのような操作を行うのかを記述する。

実は、あるワークショップでこの題材を使ってユースケース図を作成する演習を実施したところ、3つのグループが作成したユースケース図はすべて異なっていた。なぜだろうか。グループ間の議論の焦点になったポイントを以下に示す。

（1）ユースケースをどう分割するか。例えば、編集（社員による最初の原稿作成）と校正（顧客と原稿を確認しながら、確認修正する作業）を、同じユースケースとするか別のユースケースとするか。

（2）A社は業務規模が小さいため、1人の社員が営業や編集、印刷業務を兼務することが多い。この場合、アクターを「社員」という1つのアクターとするか、あるいは「営業担当」「編集者」「印刷担当」といった役割で分けて表現するか。

（3）一定期間は新システムと既存の注文管理システムを並行して稼働させ、新システムに登録された受注内容を既存の注文管理システムに送信する必要がある。既存システムはユースケースのどこに、どのように書くべきか。

（1）はユースケースの粒度の問題、（2）はアクターの表現の問題、（3）は既存システムとの関係をどう表現するかの問題と言える。いずれも、ユースケース図を作成する際に混乱しやすい事柄なので、前もって明確に定義しておきたい。3つのポイントについて、ここでは次のように定義する。

• 業務フロー図にならい、編集作業と校正作業はそれぞれ別のユースケースとする。
• 社員が増えた場合を見越して、アクターはそれぞれの役割別に設ける。
• 既存の注文管理システムをアクターとして設け、「原稿を入稿する」というユースケースと関連づける。

以上の要件を得て作成したのが、図2のユースケース図である。

図2　広告編集システムのユースケース図

ただし、ユースケース図だけではシステム構築に必要な情報を網羅できない。そこで、ユースケースごとに「ユースケースシナリオ」を作成する。このユースケースシナリオには、アクターが実施すべき業務フローに従ってシステム仕様を文章で記述する。顧客がWeb経由で入稿する際のユースケースシナリオの例を、図3に示す。

クラス図を作成する

次に、ユースケース図とユースケースシナリオを基に、クラス図を作成する。クラス図は、システムの静的な状態での構造を示す目的で用いられる。クラス図を作成するには、システムが満たすべき要件を明らかにする必要がある。ここでは以下に示す要件を検討し、クラス図を作成する。

【要件1】

「Web顧客」「FAX顧客」という2つのクラスを設け、顧客クラスの下で統一的に扱う。

【要件2】

顧客が原稿を入稿する際に、受注クラスを作成する。

【要件3】

1つの受注につき複数の原稿を持ち、版を管理する。

【要件4】

原稿を作成した人を記録するために、原稿クラスに「入稿者」「編集者」「校正者」という関連を設ける。入稿者は顧客であり、編集者は「編集者」という役割を持つ社員である。校正者は、「編集者」という役割を持つ社員あるいは顧客のいずれかとする。

【要件5】

1人の社員が複数の役割を兼ねられるようにするため、社員と役割のクラスを分ける。

図4に、上に挙げた5つの要件に従って作成したクラス図を示す。図中の太線で囲んだ長方形は、クラスを表す。長方形はそれぞれ3つに区切る。上段にはクラス名、中段には属性、下段には操作を記述する。属性と操作は、省略してもよい。

図4　広告編集システムのクラス図

長方形同士を結ぶ実線は、クラス間の関連を示している。その両端にある数字は、クラス間の多重度を表す。多重度とは、2つのクラスが何対何の関係かを表す数字である。

例えば、原稿クラスから見て受注クラスは必ず1つである。その一方で、受注クラスから見て原稿クラスは必ずしも1つではないし、ゼロでもない。こうしたことから、原稿クラスから受注クラスへの多重度は1、受注クラスから原稿クラスの多重度は複数であることが分かる。そこで、原稿クラスから受注クラスに向かう線の先には「1」、受注クラスから原稿クラスに向かう線の先には複数を表わす「1..*」を記載する。このほか、多重度の範囲を示すには「0..2（0から2まで）」「3..5（3から5まで）」などと記載する。

シーケンス図を作成する

シーケンス図は、システムの動的な振る舞い、つまりユースケースシナリオに書かれている業務フローをシステムがどのように実現するのかを記述するために用いる。

例えば、「原稿を入稿する」というユースケースのシーケンス図を作成する場合は、図5のように「入力内容のチェック」「入稿された原稿のシステムへの保存」「既存システムへの情報の送信」といった一連の業務フローを時系列で記載する。図中の矢印は、クラス間ではどういったメッセージがやり取りされるかを示している。

図5　広告編集システムのシーケンス図（画像をクリックで拡大）

ユースケース図、クラス図、シーケンス図の目的や作成イメージを述べた。次回は、要求仕様を記述するための「Z言語」を取り上げる。1970年代に生まれたZ言語とは何かについて、UMLとの比較を交えて概観したうえで、その可用性を検討する。さらに、要求仕様に求められる論理性についても説明する予定である。