オブジェクトの広場は株式会社オージス総研グループのエンジニアによる技術発表サイトです

COSMIC法

ビジネスアプリ開発者のための機能規模測定手法COSMIC法入門(第4回)

COSMIC法のデータ移動モデルのUMLでの表現
オージス総研 技術部 ソフトウェア工学センター
藤井 拓
2010年11月4日

今回の記事では、COSMIC 法のデータ移動モデルを UML で表現する方法について説明します。COSMIC法のデータ移動モデルをUMLで表現することにより、モデルの定義者以外の人にもデータ移動モデルの意味を伝えたり、モデルの妥当性を確認してもらいやすくなります。また、これまでの連載で説明してきたCOSMIC法の全体像を理解するためにも役立つと思います。

トップレベルのパッケージ構成

COSMIC 法のデータ移動モデルを表現する UML モデルの直下には、以下の3つのパッケージを作成します。

  • ピアシステム
  • 利用者機能要件
  • 注目オブジェクト
図 1 トップレベルのパッケージ
図 1 トップレベルのパッケージ

これらの用語の意味については、本連載の第 2 回で説明していますので、その記事をご参照下さるようにお願いします。

以降の記事では、これら 3 つのトップレベルパッケージ毎に下位のモデル要素を説明します。

ピアシステム

「ピアシステム」パッケージの下には、以下のモデル要素を作成します。

  • 「ピアシステム」クラス
  • クラス図「汎化階層」
図 2 ピアシステム
図 2 ピアシステム

ピアシステムに対するエクジット (eXit) のデータ移動を表現するために、「ピアシステム」クラスには図2 に示すように「eXit()」という操作が定義されています。機能規模を測定する対象のソフトウェアにデータをエクジット (eXit) する相手となる具体的なピアシステムがある場合には、その具体的なピアシステムを表現するクラスを「ピアシステム」クラスの派生クラスとして定義します。この派生クラスは、クラス図「汎化階層」において定義します。

例えば、データ移動モデルに「メールサーバー」というピアシステムを加えたい場合を考えてみましょう。この場合は、以下のようにモデルを定義すればよいでしょう。

  • 「メールサーバー」クラスを「ピアシステム」パッケージに追加する
  • ピアシステム「パッケージ」のクラス図「汎化階層」で「メールサーバー」クラスから「ピアシステム」クラスへの汎化関係を定義する(図 3 )
図 3 具体的なピアシステムの追加
図 3 具体的なピアシステムの追加

注目オブジェクト

「注目オブジェクト」パッケージには、機能規模を測定する対象のソフトウェアが読み書きする永続ストレージの注目オブジェクトを定義します。「注目オブジェクト」パッケージの下に作成するモデル要素は以下のとおりです。

  • 「注目オブジェクト」クラス
  • 「データベース」パッケージ
  • 「入力ファイル」パッケージ
  • 「出力ファイル」パッケージ

注目オブジェクトに対するリード (Read)、ライト (Write)のデータ移動を表現するために、「注目オブジェクト」クラスは「Read()」と「Write()」という操作を持ちます。また、「データベース」パッケージ、「入力ファイル」パッケージ、「出力ファイル」パッケージは永続ストレージの種類毎に注目オブジェクトを分けて定義するためのパッケージです。

「データベース」パッケージの下には、以下のモデル要素が存在します。

  • クラス図「データモデル」
  • クラス図「汎化階層」

クラス図「データモデル」は具体的な注目オブジェクト間の関連を定義するためのものです。別の言い方をすれば、論理的なデータモデルをこの図に定義します。それに対して、クラス図「汎化階層」は「注目オブジェクト」パッケージの直下にある「注目オブジェクト」クラスと具体的な注目オブジェクトとの汎化関係を定義するためのものです。

具体例としてデータベースに「従業員」クラスと「所属」クラスという具体的な注目オブジェクトが存在し、「従業員」クラスと「所属」クラスの間に「所属する」という関連が存在するとしましょう。その場合、クラス図「データモデル」で「従業員」クラスと「所属」クラスを定義し、「従業員」クラスと「所属」クラスの間に「所属する」という関連を引きます。さらに、クラス図「汎化階層」上で「注目オブジェクト」クラスと「従業員」クラス、「注目オブジェクト」クラスと「所属」クラスとの間に汎化関係を引きます。

図 4 注目オブジェクトの追加
図 4 注目オブジェクトの追加

「入力ファイル」パッケージも「出力ファイル」パッケージも「データベース」パッケージと同様にクラス図「データモデル」、クラス図「汎化階層」を持ち、それらのクラス図入出力ファイルに読み書きする注目オブジェクト(正確にはデータグループ)を定義します。

ここでメールクライアントソフトウェアを題材に「注目オブジェクト」の例を考えてみましょう。メールクライアントがメールを送信する際に、送信したメールを1件ずつファイルに保存するとします。このような場合には、「出力ファイル」パッケージに「注目オブジェクト」の派生クラスとして「メールデータ」クラスを定義します。(図 4 )

利用者機能要件

「利用者機能要件」パッケージには、利用者機能要件、機能プロセスと機能プロセス毎のデータ移動モデルを定義します。「利用者機能要件」パッケージの直下には、必要に応じて以下のモデル要素を追加します。

  • 「オンライン処理」パッケージ
  • 「バッチ処理」パッケージ
  • 「帳票」クラス
  • 「機能プロセス」クラス
  • 「画面」クラス
  • 「クロック」クラス

「オンライン処理」パッケージと「パッチ処理」パッケージは、「利用者機能要件」を処理の種類により分けて定義するためのものです。「帳票」クラス、「画面」クラス、「クロック」クラスは、エントリー (E) やエクジット (X) などのデータ移動の起点や終点となるクラスです。「機能プロセス」クラスは、具体的な機能プロセスを派生して定義するための基底クラスです。

COSMIC 法のエントリー(E)、エクジット(X)等のデータ移動は、具体的な「機能プロセス」クラスと「画面」クラス、具体的な「ピアシステム」クラス、具体的な「注目オブジェクト」クラスとの間のメッセージのやり取りとしてシーケンス図により表現されます。

具体的な「機能プロセス」クラスの定義からデータ移動を表現するシーケンス図までの定義を「メールを送信する」という利用者機能要件を例に考えてみましょう。

まず、「オンライン処理」パッケージや「バッチ処理」パッケージの直下には、個別の利用者機能要件に対応するパッケージを定義します。

利用者機能要件の具体例として「メールを送信する」というものを考えてみましょう。この利用者機能要件は、画面で以下の 3 つの内容を入力して「送信」ボタンを押下するとメールが送信されるというものです。

  • 送信先のメールアドレス
  • 件名
  • 本文

利用者機能用件「メールを送信する」はオンライン処理です。そのため、「利用者機能要件」パッケージの下の「オンライン処理」パッケージの下に「メールを送信する」パッケージを作成します。(図 5 )

図 5 「メールを送信する」パッケージ追加後
図 5 「メールを送信する」パッケージ追加後

次に、「メールを送信する」という利用者機能要件に含まれる機能プロセスを考えます。機能プロセスとは、なんらかのトリガー(エントリーイベント)をきっかけにして動作する一連のデータ移動です。

この場合、「送信」ボタンの押下によりメールがメールサーバーに送信されるというデータ移動が発生します。この「送信」ボタンの押下をトリガーとして発生する一連のデータ移動を機能プロセスと捉えることができます。この機能プロセスを「メール送信」機能プロセスと呼びます。このような個別の機能プロセスは、利用者機能要件パッケージの下に「汎化階層」というクラス図を作り、図 5 に示されている「機能プロセス」クラスの派生クラスとして定義します。(図 6 )

図 6 「メール送信機能プロセス」クラスの追加
図 6 「メール送信機能プロセス」クラスの追加

「送信先のメールアドレス」、「件名」、「本文」は、メール送信機能プロセスがメールサーバーにエクジット (X) するデータグループになります。このデータグループも「メールデータ」と呼びます。

次に「メール送信」機能プロセスで発生するデータ移動を表現するためのシーケンス図を作成します。作成するシーケンス図は、やや紛らわしい名前かもしれませんが「メール送信機能プロセス」とします。(図 7 )

図 7 シーケンス図「メール送信機能プロセス」の追加
図 7 シーケンス図「メール送信機能プロセス」の追加

メール送信機能プロセスで発生するのは、以下の 3 種類のデータ移動です。

  • 画面の「送信」ボタンの押下により画面から入力されたメールデータを受け取る
  • メールデータをメールサーバーに送信する
  • 送信したメールデータをファイルに保存する

これらのデータ移動は、「画面」クラス、「メール送信機能プロセス」クラス、「メールサーバー」クラス、「メールデータ」クラスの間の以下のようなメッセージの送信として表現することができます。

  • 「画面」クラスから「メール送信機能プロセス」クラスへのエントリー (E)
  • 「メール送信機能プロセス」クラスから「メールサーバー」クラスへのエクジット (X)
  • 「メール送信機能プロセス」クラスから「メールデータ」クラスへのライト (W)

これらのメッセージ送信をシーケンス図「メール送信機能プロセス」上で定義すると図 8 のようになります。

図 8 データ移動定義後のシーケンス図「メール送信機能プロセス」
図 8 データ移動定義後のシーケンス図「メール送信機能プロセス」

メールサーバーにメールを送信する際に、送信先が抜けているとエラーメッセージが画面上で表示されるならば、それは「メール送信機能プロセス」クラスから「画面」クラスへのエクジットとして追加します。

また、UML のノート表記を使って図 9 のようにエントリーやエクジットで移動するデータを明示的に示すこともできます。

図 9 UMLのノートを使い移動するデータグループを示した例
図 9 UMLのノートを使い移動するデータグループを示した例

終わりに

今回の記事では、COSMIC 法のデータ移動モデルを UML で表現する方法を説明しました。その際に、「ピアシステム」などのパッケージや「ピアシステム」などの基底クラスを逐次モデルに追加していくように説明しました。実際には、これらのモデル要素を定義したモデルを一旦作成し、保存すればそのファイルを機能規模測定用のモデルテンプレートとして使うことができます。そのようなモデルテンプレートを使うことで、次回の機能規模測定から「ピアシステム」などのパッケージや「ピアシステム」などの基底クラスを定義する必要はなくなります。

第 3 回の記事で紹介したデータ移動を表に記入していく方法と比べると、UML での表現はより手間がかかり、メリットが分からないという人もいらっしゃるかもしれません。UML での表現には以下のような長所があります。

  • データ移動を定義した人以外の他人がそのデータ移動モデルの意味を理解し、妥当性をチェックできる
  • データ移動を定義した人が以前定義したデータ移動モデルの意味を思い出す
  • ソフトウェアの拡張や変更を行う際に、元のソフトウェアからの変更箇所を記録するのに役立つ

次回の記事では、これらの長所がどのように役立つかを説明するとともにこれまでの記事に対するいくつか補足を行い、当社での COSMIC 法の適用結果を紹介します。

参考文献

参考文献[2]について:
本記事を掲載した時には日本語訳のドキュメントがリンク先で公開されていましたが、2016年2月現在はリンク先に存在しないようです。日本語訳としては、代わりにJIS規格「JISX0143 ソフトウェア-COSMIC機能規模測定手法」をご覧ください。JIS規格は、日本工業標準調査会JISCの公式サイトhttp://www.jisc.go.jp/のJIS検索ページにてJIS番号「X0143」で検索すると閲覧できます。(2016年2月追記)