エンタープライズ.Net 分析編

http://biki.jp.net/enterprisenet

エンタープライズ.NET分析フェーズ

オブジェクト指向分析設計による業務アプリ分析


内容

目的オブジェクト指向分析・設計で利用されている手法を概観する

内容ユースケースの分析

概念モデルの作成

分析モデルの作成

ロバストネス分析

システムサービスの機能定義

注意オブジェクト指向分析・設計（OOAD）には様々な手法があり、唯一の確立された手法があるわけではない。本書で利用されている手法は業務アプリを対象にしたもので、OOADやDOA（データ指向アプローチ）でよく利用される手法を組み合わして作成された独自の方法である。


分析・設計手順要件獲得

分析ユースケースの分析





設計論理データベースの定義

サービスの定義

コンポーネントの定義

実装物理データベースの作成

プログラムの作成画面

ビジネスロジック

データアクセス

テスト

配置

本書の説明範囲


ユースケースの分析


ユースケースの分析

アクタの識別

ユースケースの識別

ユースケースシナリオの記述


アクタの識別

アクタとは

対象システムと直接関係する人やシステム

ただし、人やシステムそのものではなく「役割」を表している

アクタが利用する機能を表現したものがユースケース


ユースケースの識別

ユースケースとは

アクタがシステムに対して働きかけることで開始される一連の処理

アクタが利用する機能

ユースケースの命名

アクターにとっての目的（価値）がわかる名前にする

「目的語（何を）＋動詞（どうする）」という名前にする

予約を入力する

商品を検索する

月間の販売実績の集計を確認する

識別したユースケースは一覧にまとめる


ユースケースシナリオの記述

利用者（アクタ）がシステムを使用する手順を物語風にまとめたもの実装を意識しない操作マニュアル

モックアップ画面と合わせてシステム機能を明確化するために利用

主な記述内容トリガシナリオが開始するきっかけ

基本シナリオシナリオが成功する典型的な流れ

代替シナリオ基本シナリオの傍系

例外シナリオシナリオが失敗するケース

事前・事後条件シナリオを開始するための条件シナリオ終了時の成立条件


ユースケースシナリオの記述会員がタイトルを予約する（UC-R001）

事前条件

利用者は会員である

基本シナリオ

１．利用者は会員証を提示して貸出・予約を開始する

２．利用者はタイトルを検索すると、システムは検索内容を利用者に表示する

３．利用者はタイトルを選択して予約を指示する。システムは予約確認書を利用者に通知する

予約を指示できるのは現在貸出可能な在庫がない場合のみである（BR-R001)

雑誌は予約できない（BR-R002)

予約数は一般会員の場合は１個、ゴールドは３個まで可能で、既に超過している場合は予約はできない（BR-R003)

利用者は予約通知方法としてメールおよび電話を選択しなければならない

例外シナリオ

1a．利用者が延滞中の場合

延滞中のアイテムを返却後にしか貸出・予約をできない旨通知する（BR-R004）


ユースケースシナリオの記述会員がアイテムを貸出する（UC-R002）

事前条件利用者は会員である

基本シナリオ１．利用者は会員証を提示して貸出・予約を開始する

２．利用者はタイトルを検索すると、システムは検索内容を利用者に表示する

３．利用者はタイトルを選択して貸出を指示する。貸出を指示できるのは現在貸出可能な在庫がある場合のみである（BR-R005）

最新号の雑誌は貸出できない（BR-R006）

貸出数は一般会員の場合は３個、ゴールドは５個まで可能で、既に超過している場合は貸出はできない（BR-R007)

４．複数のアイテムを貸出する場合は２・３を繰り返す

５．システムは貸出確認書を利用者に発行する

例外シナリオ 1a．利用者が延滞中の場合

延滞中のアイテムを返却後にしか貸出・予約をできない旨通知する(BR-R004)





概念エンティティの識別

概念モデル（クラス図）の作成


概念モデルの作成概念モデル（クラス図）とは

業務で実際に利用されているビジネス資源（もの）や出来事（こと）のトップレベルの概念エンティティを整理した図のこと

ビジネス上管理された資源や出来事はそれを指し示す識別子が付与される。このビジネス上利用されているトップレベルの識別子のことをビジネス識別子と呼ぶ

ビジネス識別子業務で実際に利用されているビジネス資源（もの）や出来事（こと）を識別するコードや番号のこと社員番号、商品コード、受注NO

ビジネス上極めて重要な概念とビジネス識別子は関係つけられている。したがって、業務系アプリの概念エンティティを見つける方法として、ビジネス識別子を利用することは合理的と言える

複数のビジネス識別子の組み合わせが１つの概念を表すこともある商品型式コード＋色コード＋サイズコード→ 洋服商品コード



ビジネス識別子から概念エンティティを識別 ○○番号、○○コード、○○名などの用語を探し出しビジネス識別子とする

ビジネス識別子から番号や情報などの冗長な用語を削除して概念エンティティとする（重複や明らかに不適切なものは除外）

識別したビジネス識別子貸出確認番号会員番号アイテム番号

それぞれ対応する概念エンティティ貸出会員アイテム

貸出確認書(#0105007)

会員＃111：山田太郎アイテム＃123-1：書籍XYZ＃456-2：ABCビデオ返却期限

2005/2/1



概念エンティティを調査し概念モデルクラス図に整理する

ボトムアップ分析

トップダウン分析



既存画面・帳票からの分析

既存の帳票や画面などから識別子を手がかりにオブジェクトモデルを作成する

貸出確認書(#0105007)

会員＃111：山田太郎アイテム＃123-1：書籍XYZ＃456-2：ABCビデオ返却期限

2005/2/1

0105007：貸出 111：会員

123-1：アイテム 456-2：アイテム



複数のオブジェクト図を作成しバリエーションを確認

概念モデルクラスごとに台帳に整理するとわかり易い

0105008：貸出

789-1：アイテム

貸出No アイテムNo 会員No 貸出日返却期限返却日予約No

0105004 567-1 333 1/5 1/12 1/6 R0103

0105008 789-1 333 1/5 1/12

貸出台帳

0105004：貸出


333：会員

R0103：予約333：会員



作成したオブジェクト図をもとにクラス図を作成

慣れてくれば台帳からクラス図を直接作成して良い

貸出

アイテム

会員予約

0105007：貸出 111：会員

123-1：アイテム 456-2：アイテム

0105004：貸出


333：会員

R0103：予約

10..*

*

0..1 0..*

0..*

0105008：貸出


333：会員



ものーこと分析による概念エンティティの整理

概念エンティティをリソース（もの）とイベント（こと）に分けて整理していく手法

リソースとイベントの区別を行うもっとも簡単な方法は概念名に「する」がつくがどうかで判断する方法で、イベントは「する」がつき、リソースは「する」がつかないというものです。商品は「商品する」とは言わないので、リソース、受注は「受注する」というのでイベントのようなやり方です。

<<イベント>>

貸出

<<リソース>>

アイテム

<<リソース>>

会員<<イベント>>

予約10..*

*

0..1 0..*

0..*



リソースの分析構造的な関係を識別

親子関係があるリソースがあれば関連を作成する（親子関係）

自リソースを説明しているリソースまたは、自リソースが説明しているリソースがないか、あれば関連を作成する（説明－もの関係）例)書籍タイトル－貸出図書

イベントの分析利用するリソースを識別

参照しているリソースがあれば関連を作成する

依存するイベントを識別参照しているか参照されているイベントがあれば関連を作成する

構造的な関係を識別親子関係のイベントがあれば関連を作成する



ユースケースごとに概念モデル（クラス図）を作成概念エンティティの識別・モデルの作成はユースケースごとに行う

会員がタイトルを予約する

予約確認書(#R9902)

会員＃111 ：山田太郎タイトル＃123：書籍XYZ

R9902：予約 111：会員

123：タイトル

<<イベント>>

予約

<<リソース>>

タイトル

<<リソース>>

会員0..*

0..*

1

*



概念モデル（クラス図）の統合

複数のユースケースから作成されたクラス図を統合する

必ずしも全体で1つの図にまとめる必要はない。サブシステムや業務

エリアごとにまとめてもよい。わかり易い（今後役に立つ）モデルを心がける

<<イベント>>

貸出

<<リソース>>

アイテム

<<リソース>>

会員

<<イベント>>

予約

<<リソース>>

タイトル

0..*0..*

0..*

0..*

1

*

*

0..*

0..1

*

1



クラスの基本的な配置方法

イベントを発生順序で並べる（業務フローがわかる）

リソースを上下両端に配置

頻繁に利用されるリソースの関連は省略してもよい（読みやすさを優先）

<<イベント>>

貸出

<<リソース>>

アイテム

<<リソース>>

会員

<<イベント>>

予約

<<リソース>>

タイトル

0..*0..*

0..*

0..*

1

*

*

0..*

0..1

*

1

発生順





概念エンティティの分析

台帳を分析して分析クラスを識別する

バリエーションの識別

状態の識別

内部クラスの識別

分析モデル（クラス図）の作成



分析モデル（クラス図）とは

分析モデルはビジネスの構造やビジネスルール・ポリシーなどを整理したモデル

目的

ビジネス用語やルールが定義できるレベル

ビジネスルールの共通化や安定化が促進される



分析作業のベースになる台帳を作成

利用者にインタビューする際に共通のモデルとして利用可能

他の項目から計算される項目や導出項目も記述

１概念エンティティごとに１つの台帳を作成することが基本

わかり易さを優先して、親子などの概念エンティティは１つの台帳にまとめたり、逆に、１つの概念エンティティをユースケースごとに別の台帳にしてもよい


0105004 567-1 333 1/5 1/12 1/6 R0103

0105007 123-1 111 1/5 1/12 R9902

0105007 456-2 111 1/5 1/8

貸出台帳

予約No タイトルNo 会員No 予約日貸出キャンセル日

R0103 567 777 1/3 1/6

R9902 123 111 1/3 済み

予約台帳


アイテムNo タイトル名

123-1 書籍XYZ

123-2 書籍XYZ

234-1 書籍DEF

997-10 DEF雑誌（10号）

456-1 ABCビデオ

アイテム台帳

タイトルNo

タイトル名種別貸出期間ゴールド / 一般

号雑誌のみ

ISBN

書籍のみ

貸出数/アイテム数/予約数

(貸出可能在庫数)

123 書籍XYZ 書籍 7日/3日 123-321 1/ 3/ 0 2

234 書籍DEF 書籍 7日/3日 234-432 1/ 3/ 1 1

997 DEF雑誌雑誌タイトル 7日/7日 0/ 0/ 0

997-10 DEF雑誌雑誌 7日/7日 10号 2/ 3/ 0 1

997-11 DEF雑誌雑誌 7日/7日 11号(最新) 0/ 3/ 0 0

456 ABCビデオビデオ 3日/3日 2/ 5/ 1 2

タイトル台帳

(項目)は導出項目

雑誌以外のアイテムは単品管理していてアイテムNoが個体Noになっている雑誌は発行された号の通番が付与されたタイトルNoを持ち、同じ号が複数個ある場合は同じアイテムNoが付与されている貸出可能在庫数＝アイテム在庫数－予約数（0以下の場合は0）

タイトル種別ごとに貸出期間の算出方法が決められている。現状は会員区分に応じた期間の計算がされているが将来的にポイント制の導入が検討されている


会員No 氏名住所連絡先会員区分 (予約数) (貸出数) (延滞中)

777 鈴木花子 999-01

大阪府．．

han@... ゴールド１ 5 ○

111 山田太郎 999-02

大阪府．．

090-9999-

XXXX

一般 0 2

会員台帳


（参考）

親子構造やより複雑な構造をもつ概念も工夫して表現

利用者（ユーザ）がわかり易いことが重要

http://f.hatena.ne.jp/dotnetmemo/20070707232320





バリエーションの識別

エンティティの属性や処理のバリエーションの違いを表現する

生成時に設定される属性の違いから判断


号、ISBNの有無から構

造的なバリエーションを識別

タイトル台帳

タイトルNo


号雑誌のみ

ISBN

書籍のみ

123 書籍XYZ 書籍 7日/3日 123-321

234 書籍DEF 書籍 7日/3日 234-432

997 DEF雑誌雑誌タイトル 7日/7日

997-10 DEF雑誌雑誌 7日/7日 10号

997-11 DEF雑誌雑誌 7日/7日 11号(最新)

456 ABCビデオビデオ 3日/3日



状態の識別

エンティティの内部イベントによって変化する状態を表現する

生成時以外のタイミングで設定される属性があれば検討

貸出・キャンセル日の有無により予約の状態の違い・貸出が済みであれば貸出済状態・キャンセル日が設定されていればキャンセル状態・それ以外は予約中状態

予約No タイトルNo 会員No 予約日貸出キャンセル日

R0103 567 777 1/3 1/6

R9902 123 111 1/3 済み

予約台帳



内部クラスの識別

エンティティ内部を構造化

関数従属性やライフサイクルの違いで判断される（正規化）

××変更業務などがヒント

主な識別クラス

内部エンティティ

ストア型

ビジネスルール型

汎用クラス


概念エンティティの分析内部エンティティ

ビジネス識別子をもっていないエンティティビジネス的な要求があればエンティティ化が可能なもの親子関係など構造的な関係（ライフサイクルが同じ）仮想的なエンティティ（ライフサイクルが異なる）

特定のエンティティに混入しているものを識別する。本質的にもとのエンティティの属性でないもの


0105004 567-1 333 1/5 1/12 1/6 R0103

0105007 123-1 111 1/5 1/12 R9902

0105007 456-2 111 1/5 1/8

貸出台帳

貸出に貸出Noの繰り返し項目がある→ 親子関係



内部エンティティ（続き）

タイトルの種別はタイトルのカテゴリを表している

もの－説明の関係がなりたつので仮想的なリソースのタイトル種別として識別

タイトルNo


号雑誌のみ

ISBN

書籍のみ



123 書籍XYZ 書籍 7日/3日 123-321 1/ 3/ 0 2

234 書籍DEF 書籍 7日/3日 234-432 1/ 3/ 1 1

997 DEF雑誌雑誌タイトル 7日/7日 0/ 0/ 0

997-10 DEF雑誌雑誌 7日/7日 10号 2/ 3/ 0 1

997-11 DEF雑誌雑誌 7日/7日 11号(最新) 0/ 3/ 0 0

456 ABCビデオビデオ 3日/3日 2/ 5/ 1 2

タイトル台帳



内部エンティティ（続き）

会員台帳


777 鈴木花子 999-01

大阪府．．


111 山田太郎 999-02

大阪府．．

090-9999-

XXXX

一般 0 2

会員の区分としての会員区分を識別

サブクラスとして識別する方法もあるが、構造の違いがないため必要なしと判断



ストア型

エンティティのインスタンスの数量を管理するもの

貸出数／アイテム数／予約数／貸出可能在庫数は雑誌の在庫量を管理している

タイトルの他の属性とは更新タイミングが異なる属性である

タイトルNo


号雑誌のみ

ISBN

書籍のみ



123 書籍XYZ 書籍 7日/3日 123-321 1/ 3/ 0 2

234 書籍DEF 書籍 7日/3日 234-432 1/ 3/ 1 1

997 DEF雑誌雑誌タイトル 7日/7日 0/ 0/ 0 0

997-10 DEF雑誌雑誌 7日/7日 10号 2/ 3/ 0 1

997-11 DEF雑誌雑誌 7日/7日 11号(最新) 0/ 3/ 0 0

456 ABCビデオビデオ 3日/3日 2/ 5/ 1 2

タイトル台帳



ビジネスルール型ビジネス的に重要なルールを表現。計算ロジックや計算に利用するパラメータの存在によって識別決定表、組み合わせルールマスタ、価格計算

貸出の期間は返却日を計算するためのパラメータビジネスルール変更によって改訂される

タイトルNo


号雑誌のみ

ISBN

書籍のみ



123 書籍XYZ 書籍 7日/3日 123-321 1/ 3/ 0 2

234 書籍DEF 書籍 7日/3日 234-432 1/ 3/ 1 1

997 DEF雑誌雑誌タイトル 7日/7日 0/ 0/ 0 0

997-10 DEF雑誌雑誌 7日/7日 10号 2/ 3/ 0 1

456 ABCビデオビデオ 3日/3日 2/ 5/ 1 2

タイトル台帳



汎用クラス

個別の業務ロジックに依存しない汎用的なデータ

住所型、国際通貨型、範囲型など


777 鈴木花子 999-01

大阪府．．


111 山田太郎 999-02

大阪府．．

090-9999-

XXXX

一般 0 2

会員台帳

住所や連絡先は、固有の業務に依存しない一般的なデータとして扱える


分析モデル（クラス図）の作成

概念モデルと同様にクラス図に整理する

概念モデルのエンティティ単位にクラス図を分けて管理しても良い





ロバストネス図の作成

ユースケースの配置

バウンダリ（画面）の配置

サービスの識別

ビジネスルールの識別

エンティティの配置

サービスの集約

分析モデルへの反映



ロバストネス分析とはユースケースシナリオをベースに画面･帳票（バウンダリ）・処理（コントロール）・データ（エンティティ）に分けてコンポーネントを識別・分析する手法

ユースケースごとに分析し、構成コンポーネントを識別・整理する

前作業でエンティティとバウンダリの多くは識別済なので、それ以外のコントロールにあたるサービスとビジネスルールの識別が重要な目的

ロバストネス分析の結果はロバストネス図にまとめられる



ロバストネス図

<<サービス>>タイトル予約

タイトル貸出予約画面

<<ルール>>貸出可能在庫あり時予約不可

<<ルール>>延滞中貸出予約不可

<<ルール>>予約数超過予約不可

<< UseCase>>会員がタイトルを

予約する

雑誌は予約できない(BR-R002)

予約を指示できるのは現在貸出可能な在庫がない場合のみである(BR-R001)

予約数は一般会員の場合は１個、ゴールドは３個まで可能で、既に超過している場合は予約はできない(BR-R003)


<<サービス>>タイトル検索

<<エンティティ>>タイトル

<<エンティティ>>予約

<<ルール>>雑誌予約不可

エンティティはトップレベルのみ配置

<<サービス>>予約可能会員？

シナリオ実行の前提になっている事前条件は各サービスの事前条件としても有効なことが多い



ロバストネス図

<<サービス>>アイテム貸出


<<ルール>>貸出可能在庫なし時貸出不可

<<ルール>>貸出数超過貸出不可

<< UseCase>>会員がアイテムを

貸出する


貸出を指示できるのは現在貸出可能な在庫がある場合のみである（BR-R005）




<<エンティティ>>貸出

<<ルール>>最新号雑誌貸出不可



<<サービス>>貸出可能会員？

<<ルール>>貸出期間取得

貸出期間はタイトル（現状は種別）によって決定される（BR-T001）




サービスの集約複数のサービスを集約可能か検討し、可能であれば１つのサービスに集約する

集約可能なサービス名前が同じまたは類似したサービス、目的が同じサービスが対象

入出力データの汎用化による集約汎用検索条件の導入

商品取得By品目、商品取得By特売品 → 商品取得By検索条件

入出力データの粒度の拡大による集約

単項目（プロパティレベル）の設定・取得をクラス（エンティティレベル）の設定・取得のサービスとして扱う図書在庫数取得、図書予約数取得 → 図書在庫情報取得


ロバストネス分析サービスの集約の例

以下のサービスの集約を検討予約可能会員？

貸出可能会員？

会員クラスのプロパティとして表現可能なので、粒度を拡大して会員取得サービスに集約合わせて、会員クラスのプロパティに予約可能？・貸出可能？プロパティを追加

エンティティ取得などの単純なサービスはロバストネス図から省略可能


予約する



予約する

<<サービス>>会員取得 <<エンティティ>>

会員


貸出する

<<サービス>>貸出可能会員？


貸出する


ロバストネス分析分析モデルへの反映

ロバストネス分析で新しく識別されたビジネスルールは分析モデルに反映する検証ルール

以後のサービス定義の記述で利用検証条件の判断は導出ルールとして整理する

導出ルール分析クラスのプロパティやメソッドに反映



予約数超過から会員の予約数を識別してプロパティに追加

<<ルール>>貸出期間取得

貸出期間はタイトル（現状は種別）によって決定される（BR-T001）

貸出期間の決定責務をタイトルに割り当て貸出期間取得メソッドを追加


（参考）シナリオ分析

簡易的なロバストネス分析

UMLのダイアグラムの代わり表を使って整理する方法もある


（参考）典型的なサービスエンティティサービス

データの検索マスタ（ビジネスリソース）のデータ更新（追加・変更・削除）例)

部署一覧取得、在庫サマリ取得、日報取得

従業員追加、商品登録

タスクサービストランザクション（ビジネスイベント）の記録（登録・修正・取消）業務処理の実行（複数作業の実行も含む）さまざまな計算結果の取得例)

受注登録、受注取消、出荷

引当実行、月末シメ実行（今月請求作成＋請求確認依頼）

出荷可能在庫数取得（商品ID）

ユーティリティサービス（インフラサービス）ビジネスの非機能な要件をサポートする処理例)

会員登録メール送信、監査ログ出力、売上帳票バッチ起動、承認ワークフロー開始

典型的なサービスを意識して、ロバストネス分析を行うとサービスの粒度がそろい共通化されやすくなる


（参考）ビジネスルールの分類

制約ルール刺激／反応型(WHEN-THEN)

例)在庫量が安全余裕在庫を下回った場合、商品発注処理が起動されます

タイマーまたはイベント（刺激）発生源になるサービス実行後に条件評価を行い該当サービスを起動します。ユースケースを制御するサービスで実装されます

操作制約(ONLY IF) 例)書籍を貸し出すのは、この書籍が貸し出し期間中に予約がない場合だけです

サービスの事前条件として実装されます

構造制約(不変条件) 例) 1ユーザあたり貸し出し可能な書籍の数は10冊

エンティティの永続化のタイミングでチェックするか、サービスの事前条件でチェックします


（参考）ビジネスルールの分類

派生ルール推論（IF-THEN）

例)過去3ヶ月の購入金額が10万円以上の顧客は重要顧客

該当クラス内もしくは直接参照可能なクラスの情報から推論できる場合は該当プロパティで実装。それ以外は別サービスとして切り出します。

評価（計算・アルゴリズム）例)税金は「製品単価ｘ税率の結果を切り捨て」で求めます

推論と同様の実装

分析モデル（クラス図）改訂版


ロバストネス図改訂版



<<ルール>>貸出可能在庫あり時予約不可




予約する

雑誌は予約できない(BR-R002)

予約を指示できるのは現在貸出可能な在庫がない場合のみである(BR-R001)






<<ルール>>雑誌予約不可

エンティティはトップレベルのみ配置

会員取得サービスは省略


ロバストネス図改訂版

<<サービス>>アイテム貸出


<<ルール>>貸出可能在庫なし時貸出不可

<<ルール>>貸出数超過貸出不可


貸出する


貸出を指示できるのは現在貸出可能な在庫がある場合のみである（BR-R005）


<<サービス>>タイトル検索 <<エンティティ>>

タイトル

<<ルール>>最新号雑誌貸出不可



貸出期間の計算はタイトルのメソッドで表現することで省略

<<エンティティ>>貸出






システムサービスとは

システムが提供するサービス

システムが提供する機能

画面などの入出力インタフェースに依存しない抽象化された機能

ビジネスロジック層が提供する機能に対応するイメージ

ロバストネス分析の結果を元に定義

ロバストネス図はシステムサービスを定義するための中間的な成果物という位置づけ

単純化してサービスと呼ぶことも多い


サービスの機能定義

サービスの機能定義を記述する

主な記述内容

概要サービスの機能や責務を説明

インタフェース引数・戻り値の指針や説明厳密な型定義は設計時に行うため範囲外

事前条件サービスを実行する前に成立している条件検証ルールが該当する

事後条件サービスを実行した後に成立している条件更新系で利用するエンティティや関連の作成・変更・削除を説明

関連ルールサービスで利用するビジネスルール

実装制約時間的な制約やアルゴリズムの指定など実装時の制約事項を記述

サービスの機能定義

サービス説明

タイトル予約会員がタイトルを予約する■事前条件・延滞中貸出予約不可（BR-R004）

・貸出可能在庫あり時予約不可(BR-R001)・雑誌予約不可(BR-R002)・予約数超過予約不可(BR-R003)

■事後条件・会員・タイトルに関連付けられた予約が作成される・タイトル在庫の予約数が１つふえる

タイトル貸出会員がアイテムを貸出する■事前条件・延滞中貸出予約不可（BR-R004)・貸出可能在庫なし時貸出不可(BR-R005)・最新号雑誌貸出不可(BR-R006)・貸出数超過貸出不可(BR-R007)

■事後条件作成：貸出変更：予約（貸出済）変更：タイトル在庫貸出数＝貸出数＋１変更：タイトル在庫予約数＝予約数－１（予約有りの場合）

タイトル検索さまざまな条件でタイトルを検索する

会員取得会員を取得する検索系は結果クラスの定義に導出項目の説明が記述されるためシンプル

事前条件にはロバストネス分析で識別した検証ルールを利用

具体的な内容はユースケースや後述エンティティ説明書（用語集）に記載


エンティティの説明



概念モデルや分析モデルで識別されたエンティティの説明エンティティ単位に、ユースケースシナリオやサービス定義などに利用されてるエンティティに関連するビジネスルールを記述エンティティ単位のビジネスルールはエンティティを利用する処理で再利用可能であるため幅広く利用されることが期待できる

ビジネスの流れやルールを表現するための用語を説明するため用語集的な役割も兼任する※特定のエンティティに関連しない用語やビジネスルールについても記載可能

例)ユースケースシナリオで利用している「延滞中」という用語をエンティティ説明書で説明予約ユースケースシナリオ（抜粋）

延滞中のアイテムを返却後にしか貸出・予約をできない

タイトルエンティティ説明書（抜粋）延滞中：返却期限までに返却していない貸し出したタイトル



主な記述内容概要エンティティの概要。機能や責務を説明

区分エンティティ区分（リソース・イベントなど）

識別子エンティティの識別子（複数存在する場合は全て記述）

ビジネスルールエンティティに適用されるビジネスルールを記述（仕様書を記述する担当者が記述可能なレベルでできるだけ仕様化する。あいまいさを避ける）

関連エンティティ構造的・動的に依存するエンティティを記述

操作エンティティに対する操作（エンティティの属性や状態を変更する操作のみ対象ロバストネス分析時に識別することが可能（後述））

属性エンティティが保持するデータ項目を記述論理的（抽象的）なレベルで記述


エンティティ説明書

エンティティ説明

会員（リソース）

■概要タイトルの貸し出しや予約を行うユーザのこと。会員番号をもつ会員の情報を管理を行う■識別子・会員No■ビジネスルール・会員No： 10000番から順番に採番する・未返却アイテム有り時の退会禁止：未返却のタイトルがある会員は退会できない・延滞会員（延滞中）：貸し出したタイトルを返却期限までに返却していない会員■関連エンティティ・貸出：会員の貸し出し状況を判断する・予約：会員の予約状況を判断する■操作（更新系のみ）・入会：新しい会員を作成する・会員編集：会員の情報を変更する・退会：会員を削除する■属性・会員番号・会員名・住所・電話・メールアドレス：予約時の連絡に利用される・会員タイプ：一般会員・ゴールド会員



エンティティ説明

予約（イベント）

■概要現在貸し出し中のタイトルが返却された時点で貸し出しできるようにすること■識別子・予約No■ビジネスルール・予約の単位：タイトルごとに予約が行われ予約番号が発行される・予約No：日付ごとに「R＋日付＋3桁の連番」のルールで採番する・同じタイトルの予約の禁止：会員は同じタイトルの予約は同時にできない・予約の優先順位：予約の優先順位は予約した日時が以前のものほど高くなる・延滞者予約禁止：延滞している会員は予約ができない。・予約可能数：会員タイプごとに予約可能数が規定、予約可能数を超えて予約はできない・自動キャンセル：貸出可能から一定期間後貸出しなかった場合自動的にキャンセルされる・予約の状態：予約中／キャンセル済／貸し出し済■関連エンティティ・会員タイプ：予約するためのいくつかの条件は予約する会員の会員タイプで決定される■操作（更新系のみ）・予約：新しい予約を作成する・予約貸出：予約中の予約を貸し出し済にする・予約キャンセル：予約中の予約をキャンセル済にする■属性・予約番号・予約日時・タイトル・会員・キャンセル日時・キャンセル理由・ステータス



エンティティ操作の識別

ロバストネス分析時のエンティティの操作を具体化することでエンティティ操作を識別できる




予約する




予約

予約（New）


分析編まとめ


分析モデル成果物

作成される成果物分析クラス

システムサービス

（ロバストネス図）他の成果物を作成・洗練するための中間的な分析資料

その他の構成要素画面・帳票・他システム

ロバストネス図のバウンダリクラス

ビジネスルールロバストネス図のルールクラス

改訂される成果物ユースケースシナリオ

画面モックアップ


FAQ

分析モデルのクラス図に他クラスの情報を利用する導出項目が定義されているのですが、実装や性能についてどのように考えればよいか？

分析モデルでは実装については考慮しません。ビジネス上で利用されているモデル構造をできるだけそのまま反映させます。実装や性能の指針はアプリケーションのアーキテクチャで定義され、それに基づき分析モデルから実装可能な設計モデル・コードに変換していきます。


参考資料


論理データベースの例

分析モデル（クラス図）から論理データベースへの作成例です

データベース化の指針によって作成される論理データベースは異なります

サブクラス・状態・集約をデータベースでどのように表現するかで変わってきます

２つの異なる指針で作成されたサンプル

パターン１（18テーブル）

分析１クラスを1テーブルで表現

パターン２（10テーブル）

サブクラス・状態・集約関係は全て１つのテーブルに集約

論理データベース(パターン1)

全体パッケージ


タイトル・アイテムパッケージ

会員パッケージ


予約・貸出パッケージ

論理データベース（パターン２）


UML基本ダイアグラム


UML基本ダイアグラム

UMLとはUnified Modeling Language（統一モデリング言

語）の略でオブジェクト指向モデリングの標準的な仕様記述言語です

現在13種類のダイアグラムが規定されていますが、よく

利用されるダイアグラムはクラス図、シーケンス図、状態図です

※詳細はインターネットや一般書籍を活用お願いしますが、よく利用する３つのダイアグラムについては簡単な説明を行います


クラス図

クラス図はシステムの静的な構造を表現するために利用

システム上のものやデータをクラス（四角で表現）として表現します

オプションでクラス名の下にプロパティ（データ）やメソッド（処理）を記述します

クラス間にはさまざまな論理的な関係を定義することができます

関連：静的にナビゲーション可能な構造

継承：IS-Aの関係

集約：HAS-Aの関係

関連の一種（）

依存：参照の依存関係

一時的な利用（）

クラス名

プロパティ

メソッド

継承関係

関連

補足（ノート）

クラスの分類名（ステレオタイプ）


シーケンス図シーケンス図はオブジェクト（プログラム）のやりとりを時系列に沿って表現するために利用横軸にやりとりを行うオブジェクトを記述縦軸が時間軸（上から下）になる

シーケンスの左側に処理シナリオを日本語で記述することもある

：ブラウザ：ビジネスコントローラ：データベース：Webフォーム

更新処理

データ更新実行

データ更新

入力データ検証

SQL更新文実行

事前条件チェック

処理結果

処理結果表示

結果ページ表示

トランザクション処理

更新データ作成ビジネスエンティティ（型付DataSet）

：ビジネスファサード

データ更新

処理結果

オブジェクト

メソッドの呼び出し

処理中を表す（活性区間）

リターン


状態図

状態図はオブジェクトの状態変化を表現するために利用

オブジェクトの特定の状態を（角が丸い）四角で表現、上部に状態名、下部に該当状態で行われる動作を記述します

矢印で状態の遷移を表します

矢印に記述される内容は「イベント名[ガード条件]/実行処理」で記述されます。ガード条件や実行処理など不要なものは省略可能。

自分自身への遷移も記述可能です

状態

状態遷移

開始状態

終了状態

Technology

エンタープライズ.Net 分析編