キミの設計に「トレーサビリティ」はあるか：保守性・拡張性に優れたシステムを作る（11）（2/2 ページ）

» 2008年02月07日 12時00分 公開
[野村佳弘，＠IT]
前のページへ 1|2 　　　　　　

2　分析モデルを設計するまでの各工程の詳細

　ビジネス要求の分析から機能の設計までの流れを図にすると、図3のようになります。

ALT 図3 分析モデルの設計（ユースケースに基づくクラス）　クリックすると拡大

2.1　ビジネス要求の分析

　ビジネスモデルが不明確で曖昧（あいまい）な場合は、どのようなビジネスモデルなら目的を達成できるかを検討し、それを実現するためのビジネスモデリングを行います。As-isモデル（現状）を分析し、目的を達成するためのTo-beモデル（未来）を検討します。すでにビジネスモデルの概要がある場合は、ビジネスプロセスを明確化し、プロセスを業務フローで詳細に定義することで、ビジネス要求を定義します。ビジネス要求の分析には、データフローダイヤグラムを利用した構造化設計手法や、UMLを利用したRUPをベースにしたビジネスモデリングの手法があります。これらの手法をカスタマイズし、プロジェクトに合った手法を適用することがよいでしょう。

2.2　システム要求の分析

　業務フローからユースケースを見つけ出します。システム化すべきサービスを洗い出し、ユースケースとします。ユースケースやアクターを基にユースケース図を作成し、システム化すべきユースケースを決めてシステム化の範囲を明確にします。また、外部システムやアクターとのインターフェイスが存在することを明らかにします。そして、ユースケースを基にユースケース定義書を作成します。ユースケース定義書は、概要レベルのものと詳細レベルのものの2種類が必要です。最初は概要レベルのユースケース定義書を作成し、システムの全体像を可視化します。

◆入力する成果物

・業務分析の分析結果

（業務フロー、ビジネスルール、業務要件など）

◆作成する成果物

第1段階

  • ユースケース図
  • ユースケース定義書（概要レベル）

第2段階

  • ユースケース定義書（詳細レベル）
  • テストケース
  • 事務規定集などのユーザーが利用する手順書

　システム要求の分析は、第1段階と第2段階に大きく分かれます。

　第1段階は、システム化の全体像を明確にすることを目的とします。ユースケース図でシステム化の範囲を決定し、ユースケース定義書（概要レベル）でシステム要求の概要を明らかにします。これにより、開発規模の初期の見積もりを行うことができます。

　第2段階では、より詳細にサービスの内容を検討しユースケース定義書（詳細レベル）を作成します。ユースケース定義書（詳細レベル）は、概要だけではなく、基本フローや代替フロー、エラー処理などを詳細に処理の手続きを記述します。これによりテストシナリオを考えることができ、テストケースを作成することが可能となります。また、ユーザーがシステムをどのように利用するか調べて事務規定を作成することができます。

2.3　機能の設計（その1：ユースケースに基づくクラスの分析）

　ユースケース分析で作成されたユースケース定義書を基に分析モデルを作成していきます。最初にユースケースに基づくクラスの分析を行います。この場合のクラスは、業務的なクラスを意味し、粒度は比較的大きなものとなります。

　分析の手順を順番に考えていきましょう。

2.3.1　ユースケースに基づくクラスの分析と設計

　ユースケースには、サービスを実現するために<>クラスと、<>クラス、<>クラスがあります。

　<>クラスは、アクター（システムの利用者や外部システムを指す）とのインターフェイスを担当する機能であり、<>クラスは、ユースケースのプロセスを実現するための機能です。<>クラスは、情報を扱う機能であり、そこには永続化データやビジネスロジックが存在します。

　ユースケースに基づくクラス分析では、ユースケースについての<>クラス、<>クラス、<>クラスの構造を分析し、定義します。

　ユースケースには、<>クラスがアクターごとに1個、<>クラスがユースケースに1個ずつ必ず存在します。<>クラスは、サービスに必要な情報の数だけ存在します。

　これらをクラスとして扱い、ユースケースに基づくクラス図としてクラス間の関係を分析し、設計していきます。

　<>クラスは主に、プレゼンテーション層に対応し、画面遷移の構成要素となります。<>クラスは主に、セッション層に対応し、サービスを実現するためのコントロールロジックを定義します。<>クラスはドメイン層に対応し、データやビジネスロジックを定義します。

2.3.2　ユースケースに基づくクラスの機能の設計

　クラス図を基にシーケンスを分析し、クラスの責務を設計します。サービスを起動するイベントごとにクラス間のシーケンスを定義し、シーケンス図を作成することで、クラスの機能を定義します。

2.3.3　ユースケースに基づくクラスの統合

　ユースケースごとにユースケースに基づくクラスが作成されるので、重複したクラスが存在する場合は、まとめて統合します。特に<>クラスは、ほかのユースケースで使われていることがあります。重複したクラスは統合します。この<>クラスは、事前にユースケース定義書や概念モデルなどから抽出しておき、ユースケースに基づくクラスの設計時に参照するという方法もあります。大規模開発の場合は、事前に<>クラスを抽出しておくと、不要なクラスを作らなくて済みます（図4）。

ALT 図4 ユースケースに基づくクラスの作成の例

　今回は、機能の設計工程における「ユースケースに基づくクラスの分析」までを検討してきました（あらためて図1を参照してください）。次回はこの続きとして、分析モデル作成の後半であるコンポーネント化（設計）から、メソッドの設計（“設計モデル”の設計や、アーキテクチャの統合）までの作業の詳細な手順を解説します。

参考文献
▼UMLに基づくオブジェクト指向分析設計実践（IBM Rational）
▼構造化分析とシステム仕様（トム・デマルコ）
▼戦略マップによるビジネスモデリング（内田功志、羽生田栄一）

筆者プロフィール

野村 佳弘（のむら よしひろ）


「保守性・拡張性に優れたシステムを作る」バックナンバー
前のページへ 1|2 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ

あなたにおすすめの記事PR