連載
【改訂版】初歩のUML

第12回
UMLモデリングの開発過程 開発編

萩本順三　株式会社豆蔵
2003/12/20

　第11回「UMLモデリングの開発過程（ビジネスモデリング編）」は、自動車専門部品販売店（RacingObjective社）を例にUMLビジネスモデリングについて説明を行いました。今回は、前回に引き続き、ビジネスモデリングからシステム開発への流れをUMLモデルを中心に説明を進めます。

UPによる反復開発

　開発編では、統一プロセス（UP）を使って説明を進めていきます。今回と次回（最終回）の説明には、UPベースの開発プロセスマップ（図1）をガイド役として登場させます。ここでこの図の見方について説明しましょう。現在説明している個所は黄色で範囲を示します。

図1 UPベースの開発プロセスマップ

　図1は、要求分析ディシプリン中の「（1）システム範囲を決める」という観点での作業を説明する際のガイドとなります。さて、この図で注意していただきたいことがあります。それは、「（1）システム範囲を決める」という作業が、「（3）要求の概念構造のモデル化」や「（4）アーキテクチャのプロト検証」といったほかの作業と並行して進められているということです。このように反復開発の本質は、実は並行的に進めていくものなのです。しかし、説明を並行して進めるすべはありませんので、（1）〜（6）の順に進めていきます。この図を見ながら頭の中で常にどの部分が並行で進んでいるかというイメージをしっかり持ちながら読み進めてください。

　ここで反復プロセスについてもう少し突っ込んだ話をしましょう。反復プロセスは、ウォーターフォール型開発の繰り返し版と思われがちです。なぜなら反復プロセスの説明図の中では分析、設計、実装、テストを繰り返しているかのように描かれているからです。しかし、実際にはそうではありません。反復開発のイメージは、責務の異なる複数チームによる並行開発といったニュアンスの方が適切です。図2は、一般的な反復開発でとられるメンバーのロール（役割）別チーム構成でUPを分割し、説明したものです。

図2 チーム構成別UP作業分割

　この図で示すように、それぞれのチームが並行的に協調しあいながら作業を進めていきます。図1と図2をまとめたものを表1に示します。なお、今回解説するのは（1）〜（3）までです。

ディシプリン名 UP（統一プロセス）	ディシプリン名 （本連載での名前）	チーム名	作業内容 （作業観点）
要求と分析	・システム分析 ・要求分析	システム分析チーム	（1） システム範囲を決める （2） システム要求を定め、管理する （3） 要求の概念構造のモデル化
設計 （前半）	システム設計の初期段階	アーキテクトチーム	（4） アーキテクチャのプロト検証 （5） コア・アーキテクチャの確立
設計 （後半）	システム設計の後半	設計・実装チーム	（6）　システムの詳細設計・実装・テスト
表1 チームによるディシプリンの実施

　この表のように、それぞれのディシプリンは、そのディシプリンを行う責務を持つチームにより作業内容が実施されます。実際の開発では、各ディシプリンにおける作業内容はこれだけではありませんので、「作業を行う観点」ととらえていただいた方が適切かもしれません。

　では、この表で注意していただきたい個所だけを説明しましょう。まず、「（3）要求の概念構造のモデル化」作業には、システム分析チームだけではなくアーキテクトチームからも参加することで、システム分析モデルを、要求分析者とアーキテクトの共通の知識としなければなりません。

　次は、設計（システム設計）について説明します。設計（システム設計）の前半は、アーキテクトチームによって進められます。アーキテクトチームはIT技術に優れた少人数の精鋭メンバーでなければなりません。比較的大きなシステム開発でも、アーキテクト1人と補佐1〜2人程度で構成することを検討してみてください。

　設計（システム設計）の後半、比較的大きなシステムにおいては、サブシステムに分割され複数のチームで開発を進めることになります。よって、分割されたサブシステムに対して、システム設計者、実装者、テスターがアサインされるようになるでしょう。この段階では、アーキテクトは、それぞれのサブシステムのインターフェイス部分とアーキテクチャを厳密にコントロールする役割となり、システム分析者は、システムのテストについてコントロールする役割となります。
　
　このような考え方は、小規模開発でも利用できます。その場合、要求分析、システム分析、システム設計は、開発者が問題領域を見る際の「観点」と考えて各作業を実施することになります。つまりは、システム開発において対象問題を、要求の洗い出しの視点、要求構造の分析的な視点、設計的な視点、という3つの視点で具現化していくのです。

　ではここから、それぞれの開発作業について、どのようにUMLのモデルが作成されるのか説明していきます。その前に読者にここで一言お断りがあります。この説明は、モデリングに関する部分に重点を置いた説明です。開発作業全体を説明しているわけではありません。その点、ご注意を。

　それでは、表1の作業内容にそって解説を行っていきます。

（1） システム範囲を決める

　これは、要求分析という観点で、要求分析チームが中心となって行う作業です（図3）。

図3 システム範囲を定める

　システム範囲を決めるということは、戦略分析の成果物に基づき、どのようなシステムをいつまでに開発し、業務モデルにどのように適合させることでビジネス全体の最適化をどう図るかを決めることです。また、ビジネスが急速な勢いで発展している中、リリース時期は非常に重要なものとなりますので、システムに要求される課題に対して優先順位を付け、最優先すべき要求をいつまでに作成すべきか、投資効果に配慮しどこまで作るべきか判断を下さなければなりません。
　
　つまり、前回説明した子どものオモチャ・オネダリモデルの「分析とは、現状を理解し、戦略を立て、財布（能力）と相談する」というところの「財布と相談する」という観点がここでは重要となります。

では、前回の図を使って説明しましょう。図4を見てください。この作業で考えるべき点は、アクティビティとシステムの間でやりとりされるインターフェイス（赤色のだ円）部分となります。業務分析フェイズで明らかになったシステム導入戦略について開発期間・開発コストを加味して現実的な解を探るわけです。

図4 コンピュータシステムによるビジネス最適化

　RacingObjective社の例では、社長と話し合った結果、できるだけシンプルにビジネスとして重要なものからシステム化の範囲にしていきたいという意向がありました。

　まずは、システムに対する要求をシンプルに示す文書を書きます。ここでは、この文章のことを「ビジネスIT化シナリオ」と呼びます。この文章の目的は、システムにとって最も重要な課題・要求をコンセプトベースで記述することです。これにはダラダラとすべての要求を書く必要はありません。開発者全員で、何が最もシステムにとって重要で死守すべきことなのかを、いつでも再確認するためのものです。例えば、システム開発過程では、システムに対する要求がどんどん累積されるうちに、結局何をやりたかったのかという点が不明確になることがあります。このようなときに、かっちりとシステムのコンセプトを押さえている「ビジネスIT化シナリオ」は役に立つことになるでしょう。また、ユースケースモデルは、この文書をベースに作成されることになります。

販売管理システム ビジネスIT化シナリオ RacingObjective社 ◎ビジネスシナリオ 　今回のシステム開発の大きな狙いは、顧客からの受注工程において商品予約をスピーディに行うよう改善することである。顧客から部品を予約された場合に、自社在庫を確認、在庫がなければ即本社に問い合わせを行い、他支社が保有する在庫を確認できるようにIT化を図る。そうすることで、顧客からの「商品がいつ届くかよく分からない」という苦情や、「営業担当が在庫商品を確認する業務処理がまちまちで業務過誤を犯しやすい」といった問題を早急に解決したい。さらに、顧客からの入金を経理が確認した段階でシステムにその情報を入力し、商品発送が可能状態になったことをシステムにより在庫部品センターの担当者に通知できるようにする。 　 ◎今後の方向性 　今後のビジネス拡大を狙って、各支社に存在する在庫部品センターはITシステムによる情報統合を急ぐ必要がある。このシステム開発は、このような在庫部品センターの情報統合の第1ステップとして実現する狙いがあるため、作成されるITシステムは今後在庫管理面で大幅な拡張を予定している。また、来年には、顧客からのWeb予約を導入する予定である。さらに、今後は、経理システムの日時売り上げオンライン化なども考えたい。 　 ◎要求されるレスポンス ・自社在庫の確認予約は10秒以内 ・他支社が保有する在庫問い合わせ処理は30秒以内 ◎ビジネス課題 　このシステムを導入するに当たって、各支社の在庫部品センターは、自社からの部品予約だけではなくほかの支社からの予約受け付けを行うようになる。本社としては、支社間の連携による部品在庫の振り替えについて、どのような方法で行うのか平成15年11月末までに具体化しなければならない。

図5 ビジネスIT化シナリオ

（注）本内容においては、開発プロセスやマネジメントにフォーカスした内容ではないため、開発範囲をあまり明確にせずに説明を進めています。一応、ユースケースにて開発範囲は示していますが、その後の設計で紹介するモデルは、要求範囲の一部分であったりします。また、実際の開発では、方向付けフェイズの段階で、ユーザーとディスカッションすることによって、性能要求・拡張要求・再利用性の要求など（これらを非機能要求といいます）を明確にしていきます。そして、その非機能要求を満たすモデルを作ることが設計の目標となるのですが、ここでは割愛しています。あくまでモデルを中心にしながらの説明に終始していることを理解していただき、開発・勉強の参考にしてください。

（2） システムの要求を定め・管理する

　この作業も、要求分析という観点で、要求分析チームが中心となって行う作業です（図6）。システムの利用者（ユーザー）が要求分析チームの一員として入っていることが重要となります。

図6 システムの要求を定め・管理する

　ここでようやくユースケースモデルの登場です。ユースケースモデルとは、ユースケース図と、ユースケース記述をセットにしたものをいいます。ユースケース図は、システム開発におけるユーザーから見たシステムの「使い方の例（ユースケース）」を示したものです。ユースケース図の詳しい説明は、下記を参考にしてください。

◎ 【改訂版】初歩のUML 第8回　顧客の要求をユースケースに反映させる

　ユースケース記述は、先に挙げた「ビジネスIT化シナリオ」をもう少し詳細化したものとなります。図7にユースケース図、図8にユースケース記述の例を示します。商品マスタなどの商品マスタメンテナンス機能は別途ユースケースにまとめていきます。図7は、まだ初期段階のユースケースモデルと考えてください。

図7 RacingObjective社 販売管理システム（ユースケース図）

ユースケース名	UC0002：商品を予約する
概要	お客様から注文部品を受け付ける
アクター	営業担当
事前条件	すでに登録済のユーザであること
メインフロー	1.アクターは予約したい商品リストを入力する 2.システムは自社内在庫を確認して、在庫がある商品に在庫ありマークを入れる 3.アクターは、すべての予約商品に在庫マークがつけられていれば、6へ 4.アクターは他支店在庫を問い合わせする 5.システムは、他社の在庫を確認し、在庫が他社にある場合は、在庫ありマークを付与し、その在庫の問い合わせ支社・担当者名を表示する 6.アクターは、表示された商品予約の在庫状況と顧客からの依頼を受けつけ、予約したい商品について、再度選択できる 7.アクターは、予約を中止したい場合は、このフローをぬける 8.アクターは、顧客Noを入力し予約を実行する
事後条件	アクターが予約を実行した場合のみ、商品が予約されていること。
特記事項	システムが商品予約する期間は、商品予約画面で変更ができるようにすること。デフォルトで3週間とする。アクターが本ユースケース実行時に、予約途中の商品は仮予約となる。仮予約の解除は、このユースケースが終了した場合と、適切なタイムオーバーになった時（警告表示）とする。
図8 「商品を予約する」ユースケース記述の例

（3） 要求の概念構造のモデル化

　この作業は、システム分析という観点で、要求分析チームとアーキテクトチームの間で行われる作業です（図9）。

図9 要求の概念構造のモデル化

　要求の概念構造のモデル化とは、名前のとおり要求に潜んでいる本質的な概念構造を明らかにすることで、ユーザー、要求分析者、アーキテクトといったさまざまな利害関係者のシステムに対する共通な分析モデルを作り上げることです。実装のためのモデル化が目的ではありません。よってこのモデルを評価する場合は、いかに要求に潜む概念構造をシンプルに表現しているかということに尽きます。
　
　図10がシステム分析で作られるクラス図（分析モデル）です。分析モデルとは、システム分析の段階で要求の概念構造のモデル化を目的として作成されるクラス図を中心としたダイアグラムのことです。分析モデルには、クラス図のほかに、コラボレーション図（またはシーケンス図）、オブジェクト図、ステートチャート図などが使用されることがあります。クラス図以外の図は、必要であれば作成するという程度に考えておいてください。

図10 分析モデル（クラス図）　クリックすると拡大

　今回の開発事例におけるクラス図の特徴としては、ビジネス分析時に作成したクラス図をすべて反映したものとなりますが、通常は、ビジネス分析時に作成したクラス図の中でシステム化対象となる部分にフォーカスしたクラス図になることを覚えておいてください。

　分析モデルでは、要求の概念構造を明確にするために、クラスの属性要求に必要となるデータをクラスの操作に入れています。このとき、操作についてあまり詳細な内容を入れるとモデルがやたらと複雑になったり、本質的に強調したい概念が分かりづらくなったりしますので注意してください。

　次に、注文された商品が顧客に配達されるまでにどのようなライフサイクルがあるのかを考察しましょう。図11に注文商品のライフサイクルをステートチャート図により示しています。ステートチャート図はUMLのダイアグラムの1つで、このようにシステムまたはオブジェクトの状態をとらえる際に使います。

図11 注文商品のライフサイクル（ステートチャート図）

　ステートチャート図は初めて登場しましたので、ここで図11を使って簡単に説明します。まずステートチャート図（状態図）は、「（1）状態」とその遷移をとらえるための図です。状態が次の状態へ遷移するためには何らかのきっかけが必要となりますが、そのことを「（2）イベント」と呼びます。イベントが発生する際に、何らかの「（3）アクション」が必要な場合、「イベント名／アクション名」と書きます。アクションは業務処理であったりシステムに要求される機能であったりします。イベントには「もしXXだったらイベントを実行する」といった条件が付けられます。これは、ガード条件と呼ばれ「［ガード条件］イベント名／アクション名」というようにイベント名の前に“［ガード条件］”を書き、そこに書かれた文章が真（True）であればアクションを実行するという表現もできます。状態の中には「（4）入状（Entry）」、「Do」、「退状（Exit）」といったアクションが書けます。ステートチャート図は、「（5）開始状態」で始まり「（6）終了状態」で終わります。

　では、図中の予約状態から発送済み状態に遷移する個所で具体的な説明をしましょう。ここでは、予約状態から発送済み状態へ遷移するためには、入金確認（顧客からの入金を確認）イベントが来なければならないことが分かります。また、入金確認イベントが来たときに、商品発送という業務アクションを実施しなければなりません。発送済み状態から抜け出る可能性として、顧客が商品を返品するというケースもありますので、返品イベントも定義しています。

コラム：ステートチャート図とアクティビティ図の違い

ステートチャート図とアクティビティ図の違いがよく分からなくなる人がいます。一時的な状態（イベント名が書かれていないイベントの遷移）がステートチャート図では描けるからです。ステートチャート図では、このような遷移をラムダ遷移というのですが、ラムダ遷移が多用されるステートチャート図の状態は、アクションのみの定義となってしまいます。このような図は、アクティビティとさほど違いがないようにみえます。しかしながら、やはりステートチャート図の関心事は、対象領域における状態の把握と、状態と状態の遷移にあります。アクションは、発見された状態の中の入状（Entry）、最中（Do）、出状（Exit）にて、どのようなアクションを行うのかということを記述するものですから、アクションについては補足的な扱いとなります。一方、アクティビティ図は、アクション（つまりはアクティビティ）とアクションの流れに着目するものですから、両者には大きな違いがあるのです。

　しかし、なぜステートチャート図をここで利用したのでしょうか。その理由は、今回の要求の中で見落とされがちになるのが注文された商品内容の管理状態であるからです。商品を販売し発送した後においても、注文された商品は履歴として残さなければなりません。うっかりこのことを忘れてしまっては、間違った注文オブジェクトの管理方法を設計してしまうでしょう。そこで、要求分析の中で、注文商品のライフサイクルを明らかにしておき、設計のリファレンスとして使用していくのです。

　次は、図10をユースケースに対応させてみましょう。

　図10は、ユースケースを動かすという観点から考えると、適切なものではありません。そこで、アクターからイベントを受け取る役割オブジェクト（Boundary）、制御を受け持つオブジェクト（Control）、データ管理を行うオブジェクト（Entity）というようにユースケースを実行する際に、ソフトウェア実現のための役割ごとに類別化する方法があります。この方法はロバストネス分析という手法として知られています。図10をこのような役割の観点で分けていくと、アクターからイベントを受け取る役割オブジェクト（Boundary）、つまりはユーザーインターフェイスを実現するオブジェクトが欠落しているように思えます。そこで、図12にロバストネス風クラス図を示します。この図は、ユースケースのサービスを満たすためにBoundaryを設け、さらに、EntityとControlにクラスを類別化したものです。また、自社在庫がない場合、本社に問い合わせするための仕組みをモデル上で表すために「本社商品在庫管理」というクラスを置いています。なお、Boundaryクラスは、クラス名から想像できる操作については省略しています。これは、Entityクラスの属性Set、Getを行う操作を省略としているものと同じ感覚で考えてください。

図12 ソフトウェア実現のための役割にクラスを類別化する（クラス図）

　今回はここまでです。次回は、いよいよ最終回です。

IT Architect 連載記事一覧