UML-その3

 前回はUMLのクラス図の関係を取り上げました。今回はこのUMLのシーケンス図
 を取り上げようと思います。

 クラス図ではオブジェクト(実体)を設計するために、まずマスターファイルやトラ
 ンザクションファイルのデータ項目を属性として定義しました。属性の次に定義する
 のは、“このオブジェクに何が出来るか”の機能を定義することでオブジェクトが
 設計できます。オブジェクト設計で述べましたように、属性というデータ項目があっ
 て、このオブジェクトで出来る機能が定義されて始めて、オブジェクト単独で機能で
 きるサブシステム的な構造が出来上がります。
 この機能はこのクラスで独自に定義するのではなくて、外部や別のクラスからの指令
 によって定義される独自機能でした。
 この機能設計を効果的に進める手法として、UMLではシーケンス図を活用していま
 す。
 シーケンス図は横軸にクラスを並べて置きます。縦軸には“アクター”と言われる
 受注業務機能の外に置き、クラスに影響を与えるオブジェクトを配することから始め
 ます。
 たとえば、顧客は“注文”という指令を出すアクターです。
 同様に商品の出荷処理をする商品管理課も出荷要求が受注業務のあるオブジェクト
 から指令が出される受注業務の外のオブジェクトですので“アクター”といいます。
 それでは、受注処理のシーケンス図を作って見ましょう。

 ◆ステップ1:注文登録
  受注業務ですから、アクターの顧客から注文伝票が発行されます。まず、この注文
  伝票を登録する必要がありますので、行先は注文登録の属性を有している注文クラ
  スです。アクターである顧客から“注文登録”という指令が注文クラスに出ている
  ことになります。
  すなわち、注文クラスは“注文登録”という処理機能が必要であり、その機能を
  このクラスで持つことになります。

 ◆ステップ2:顧客取引条件照合
  注文登録しますと、顧客によって取引条件が通常変わりますので、その情報の入手
  が必要になります。たとえば、顧客の仕切値であったり、在庫割り当て優先順位な
  どです。注文クラスにはこのような情報はありませんので、その情報を持つ顧客
  クラスにその情報の取得の指令を出します。
  したがって、顧客クラスは“顧客取引条件取得”の機能を持ち、その情報を注文
  クラスへ返す設計をすれば良いことが分ります。

 ◆ステップ3:在庫引当
  また、注文書登録後、注文品の引当をしなければなりません。注文クラスの中で
  その機能は持てません。注文品の数量を引き当てることの出来るクラスは在庫クラ
  スです。注文クラスから在庫クラスに対して“在庫引当”の指令を出すことになり
  ます。在庫クラスは在庫の引当をし、引当/不足情報を注文クラスに返す処理にな
  ります。在庫クラスでは“在庫引当”の処理機能を持つ必要があります。
  以下、同様にして受注業務システムを設計して行きます。
 
 シーケンス図に基づいたクラスの機能設計の概念がお分かりになったと思います。
 従来のデータ中心設計と違って、データと機能を一括するオブジェクトを対象として
 いるところにオブジェクト設計のシンプルさがあり、UMLはそれをより設計し易い
 表記としました。
 第65回はここで終了します。UMLの設計を3回に亘って取り上げました。
次回取り上げますテーマはプロジェクトマネジメントのデファクトであるPMBOKの代表的手法から取り上げてみようと思います。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする