.NET開発の設計作業を説明。分析モデルをアプリケーションアーキテクチャで定義したコンポーネントにマッピングしながら詳細を設計を進める。多くの場合、画面・エンティティ・サービスの３つの要素を対象に設計を進める

1. http://biki.jp.net/enterprisenet
エンタープライズ.NET
詳細設計編
分析モデルをアーキテクチャにマッピングする

2. http://biki.jp.net/enterprisenet
詳細設計成果物一覧
2
開発成果物 概要
物理データベース 論理データベースから生成しインデックスなどの物理設計をアプリケーション
開発に合わせて実施していく
詳細設計開始に合わせて初版を提供する
※本書では説明しない
プログラム設計書
（シーケンス）
ユースケース・ロバスネス図を参考にアーキテクチャで既定されたコンポーネ
ントを利用したシーケンスを作成する。ビューモデル・サービス・エンティティ３
つのコンポーネントでシーケンスを作成する。
ユースケースからユーザ操作に対するアクションや入力チェック、画面遷移な
ど画面動作に関する処理を識別する
プログラム設計書
（画面）
モックアップから画面レイアウトおよび画面項目の仕様と動作（検証チェックや
選択データなど）を設計する
シーケンスで識別した画面動作の処理を設計する
プログラム設計書
（エンティティ）
分析クラス図やエンティティ説明書からエンティティの構造、エンティティに対
する操作、導出項目や構造制約（参照制約など）を設計する
プログラム設計書
（ビジネスロジック）
サービス定義書からシステムが提供する機能を設計する
業務機能毎に機能を集約。複雑な処理構造はシーケンスを記述してエンティ
ティのアクセスロジックを整理する

3. http://biki.jp.net/enterprisenet
プログラム設計書（シーケンス）
処理シナリオ ビューモデル
画面
エンティティ
入出力データ
サービス
ビジネスロジック
１．利用者は会員証を提示して貸出・予約
を開始する
TitleReserveWindow
２．利用者がタイトルを検索すると、システ
ムは検索内容を利用者に表示する
QueryAction TitleList EntityService
３．利用者がタイトルを選択して予約を指
示する。システムは予約確認書を利用者
に通知する
ReserveAction TitleReserve TitleReserveComman
d
例外シナリオ
３a．利用者が延滞中の場合 LoadAction MemberList EntityService
延滞中のアイテムを返却後にし
か貸出・予約をできない旨通知す
る
3
ユースケースシナリオより記述
横軸はコンポーネント種別
アーキテクチャ設計で決定
される
シナリオのユーザ操作に対する
処理をアクション処理として識別
ロバストネスで識別されたサービスと入出力
するデータ・エンティティを記述
 ユースケース・ロバストネス図を参考にアーキテクチャで既定されたコンポーネントを利用し
たシーケンスを作成する
 ビューモデル・サービス・エンティティ３つのコンポーネントでシーケンスを作成する
 ユースケースからユーザ操作に対するアクションや入力チェック、画面遷移など画面動作に関する処理
を識別する
<<サービス>>
タイトル検索
<<サービス>>
タイトル予約
<<サービス>>
会員取得
ここでは主要な処理メソッドの識別が目的であるためコンポーネント間レベルで利用されるメソッドのみ
を記述（内部処理は別設計書で記述）
ユースケースシナリオ
ロバストネス図

4. http://biki.jp.net/enterprisenet
プログラム設計書（画面）
 モックアップから画面レイアウトおよび画面項目の仕様と動作（検証チェックや
選択データなど）を設計する
 シーケンスで識別した画面動作（アクション）を設計する
4
画面モックアップ
シーケンス
QueryAction

5. http://biki.jp.net/enterprisenet
プログラム設計書（画面）
 画面動作（アクション）の設計
 画面動作は主にボタンのクリックで起動される
 上記以外にもロストフォーカスやファンクションキー押下などのタイミングで起動する処
理もある
 主な処理内容は以下の通りで、アクションの詳細化を行う際に分解基準とし
て利用する
 アクション処理（以下の処理を実行）
1. 単項目入力検証チェックの実行
2. 複合項目入力検証チェックの実行
3. コントロールからの入力データ取得
4. サービス（ビジネスルール）の呼び出し
5. コントロールへの出力データ設定
6. 画面表示状態の変更（活性不活性、フォーカス移動）
※ 上記下線項目は別途処理として仕様化・設計が行う単位になる。
単機能に分解されているため同じような実装になる
 ユースケースシナリオの「検索内容を表示する」の場合
 アクション処理⇒ 検索アクション（QueryAction）
 複合項目入力検証チェック⇒全検索条件が無指定の場合にエラー（IsEmptyQuery）
 入力データ取得⇒ 検索条件作成（CreateQuery）
 出力データ設定⇒ 結果表示⇒（ShowResult）
 画面表示状態⇒ 結果表示状態への変更（Mode←結果表示モード）
5

6. http://biki.jp.net/enterprisenet
プログラム設計書（エンティティ）
 分析クラス図やエンティティ説明書からエンティティの構造、エンティティ
に対する操作、導出項目や構造制約（参照制約など）を設計する
6
分析モデル
エンティティ説明書

7. http://biki.jp.net/enterprisenet
プログラム設計書（エンティティ）
 １つのエンティティから複数のエンティティ・プログラムが設計される
 エンティティはさまざまな処理で利用されるため共通部品として定義される
 ただ、特別な機能要求や性能向上要求によるカスタマイズをすることも可能
 エンティティの肥大化を防ぐ目的と複数チームによる並行開発を促進する目的
7
予約 会員
会員の貸出数・予約数が
判断できる会員エンティティ
他のエンティティを参照する場合に、参照するエンティティとのやり取
りを行う代理のエンティティ（他エンティティの役割を行うためエンティ
ティロールと呼ぶ）を作成して利用。データベースの集約機能を利用
しているため性能的に有利。

8. http://biki.jp.net/enterprisenet
プログラム設計書（エンティティ）
 エンティティの共通化
 エンティティの共通化では、共通的に利用されるエンティティとはどのよ
うなエンティティか、特定エンティティの機能のうち共通機能として扱う
べき機能は何かの２つの視点で考える
 共通的に利用されるエンティティは業務共通
 概念モデル（トップレベル）で識別されたエンティティはビジネス的に最
重要で広範囲に利用される可能性が高い⇒業務共通
 より詳細な分析モデルにも共通化すべきエンティティが多くある
8
概念モデル
共通ビジネスエンティティ
会員エンティティ
予約エンティティ
貸出エンティティ
タイトルエンティティ
アイテムエンティティ
タイトル在庫エンティティ
分析モデル

9. http://biki.jp.net/enterprisenet
プログラム設計書（エンティティ）
 エンティティの共通機能
 広範囲に利用されるエンティティはさまざまなエンティティと関連しさまざまな機
能を提供する必要がある
 エンティティの共通機能として提供すべき機能は、エンティティの典型的な利用
方法を規定できれば、その利用方法から共通機能を識別する
 上記が難しい場合、エンティティを内部テーブルだけで構成し、その中のデータ
だけで完結する機能を共通機能として提供する
 なお、エンティティの実装は複数個可能で、エンティティの共通機能も複数用意
することが可能である
 更新用・検索用にエンティティを分けて用意することは良く行われる
 例) タイトルエンティティ（分析）
⇒ タイトルエンティティ（実装）、 検索タイトルエンティティ（実装）
9
タイトルエンティティ
検索タイトルエンティティ

10. http://biki.jp.net/enterprisenet
プログラム設計書（ビジネスロジック）
 サービス定義書からシステムが提供する機能を設計する
10
サービス定義
エンティティ

11. http://biki.jp.net/enterprisenet
詳細設計のまとめ
 分析フェーズで作成された各種成果物からプログラム設
計書を作成する作業。
 プログラムの全体構成をシーケンスで整理し、画面・エン
ティティ・ビジネスロジック（サービス）を実装可能なレベ
ルに設計をする
11

12. http://biki.jp.net/enterprisenet
詳細設計における注意点
 全般
 詳細設計（設計モデル）の作成には適用するアーキテクチャ
を考慮する必要がある
 前述のプログラム設計書は特定のアーキテクチャを前提にしたもの
で、分析モデルから設計モデルへの対応がどのようになるか参考に
なる
 分析モデルで詳細設計（設計モデル）に関する制約はなるべ
くつけないことが望ましい
 分析モデルでは詳細な技術に依存すべきでない。しかし、これは実
装技術を全く考慮しなくても良いということではなく、逆に実現可能性
についてはある程度考慮する必要があるということである。1坪の土
地に高層ビルを建てるようなことにならないようにする
12

13. http://biki.jp.net/enterprisenet
詳細設計における注意点
 画面
 入力検証チェックはコントロール単位のチェック、複数項目の相関チェック、データ
ベースを利用するチェックなど複数の実装場所を考慮する必要がある
 ユーザ操作に対する動作をアクションといい設計時の重要な観点になる、多くはボタ
ンクリックなどで起動するがロストフォーカスなど暗黙的に起動されるものをあるので
もれなく識別できるようにする必要がある
 画面上の表示項目の導出項目は、ビューモデルまたはエンティティの導出項目とし
て定義される
 サービス
 サービスはステートレス（一時的な状態保持はしない）で設計する必要がある
 呼び出し回数やデータ量を考慮してサービスは設計する必要がある
 プロパティの取得のためにサービスを呼び出さない
 大量データは必要なデータだけ分割して取得する
 検索処理は汎用化可能であるため共有化を進める
 基本１サービス＝１トランザクションで設計を行う。トランザクションは自動化されてい
る前提で、例外を送出しないと正常終了でCommit、例外を送出すると異常終了で
Rollbackする
 業務エラーはエラーコードで表し例外を送出して通知する
13

14. http://biki.jp.net/enterprisenet
詳細設計における注意点
 エンティティ
 エンティティは物理データベースから自動生成されたクラスを
使うため設計時に物理データベースが必要になる
 エンティティはデータベースの構造をほぼそのままマッピング
する。（ORマッピング可能な範囲）
 テーブル以外にビューのマッピングも上手に利用する
 分析されたエンティティに対して、処理毎のカスタマイズを可
能にするため複数の実装が行われる点を考慮
 エンティティの永続化時の制約や採番機能もエンティティ側で
実装可能か検討する
14

15. http://biki.jp.net/enterprisenet
詳細設計における注意点
 バッチ処理に関しての補足
 「バッチ処理」の実装パターンは２つ想定している
 オンライン処理と同じトランザクション処理を行うサービスを1回または繰
り返し利用した処理形態
 オンラインと同じデータを同時にアクセスし整合性を保つ必要がある場合
 オンライン停止中に実行されるバッチ処理
 大量データを取り扱う“バッチ処理”固有の注意点
 エンティティを構築、管理するためのパフォーマンスとリソース消費を意
識する必要がある
 処理固有エンティティ、エンティティロール等の“バッチ処理”専用の設計を
行って、処理に最適化する必要がある
 パフォーマンスと設計のトレードオフで考慮
 パフォーマンスを維持するためにはバッチ対象データの分割、並行実行
等が想定される為、複数のエンティティを利用する場合は分割しやすい
考慮が必要
 Ex.同一の処理をエリア別に分割して、並行実行する
15

16. http://biki.jp.net/enterprisenet
エンティティの実装 他エンティティの参照
 エンティティに記述するロジックは他エンティティ（外部データ）にアクセスしな
いことが原則
 エンティティ同士の結合度は下げることで再利用性をあげる目的
 複数エンティティにまたがる処理はサービスに記述することが第1候補
 サービスがエンティティのナビゲートの責務を負う
 親子などの密結合の場合はリレーションを明示してアクセスしても良い
 特定の処理において他のエンティティを参照する処理をエンティティに記述し
たい場合は処理固有用のエンティティを作成する
 エンティティの肥大化を防ぐ目的と複数チームによる並行開発
 特定の処理によらず他のエンティティを参照する場合は参照するエンティティ
とのやり取りを行う代理のエンティティ（他エンティティの役割を行うためエン
ティティロールと呼ぶ）を作成して利用する
 エンティティ間の依存性の低下や最適化に利用する
 例） 従業員の年間売上を人事評価に使うシナリオで、年間売上を計算するために従業員に
関連する売上エンティティを全てメモリにロードして処理するとオーバーヘッドが多い。この
ような場合、売上In従業員エンティティロールを導入して集約された売上データのみをDBか
ら取得して利用する
16
従業員 売上 従業員 売上◆ 売上In従業員
全て売上データを取り扱うためオーバヘッドが大きい 集約した売上データを取り扱うためオーバヘッドが小さい