エンタープライズ.Net 詳細設計編

http://biki.jp.net/enterprisenet

エンタープライズ.NET詳細設計編

分析モデルをアーキテクチャにマッピングする


詳細設計成果物一覧

2

開発成果物概要

物理データベース論理データベースから生成しインデックスなどの物理設計をアプリケーション開発に合わせて実施していく

詳細設計開始に合わせて初版を提供する

※本書では説明しない

プログラム設計書（シーケンス）

ユースケース・ロバスネス図を参考にアーキテクチャで既定されたコンポーネントを利用したシーケンスを作成する。ビューモデル・サービス・エンティティ３つのコンポーネントでシーケンスを作成する。

ユースケースからユーザ操作に対するアクションや入力チェック、画面遷移など画面動作に関する処理を識別する

プログラム設計書（画面）

モックアップから画面レイアウトおよび画面項目の仕様と動作（検証チェックや選択データなど）を設計する

シーケンスで識別した画面動作の処理を設計する

プログラム設計書（エンティティ）

分析クラス図やエンティティ説明書からエンティティの構造、エンティティに対する操作、導出項目や構造制約（参照制約など）を設計する

プログラム設計書（ビジネスロジック）

サービス定義書からシステムが提供する機能を設計する

業務機能毎に機能を集約。複雑な処理構造はシーケンスを記述してエンティティのアクセスロジックを整理する


プログラム設計書（シーケンス）

処理シナリオビューモデル画面

エンティティ入出力データ

サービスビジネスロジック

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

TitleReserveWindow

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

QueryAction TitleList EntityService

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

ReserveAction TitleReserve TitleReserveCommand

例外シナリオ

３a．利用者が延滞中の場合 LoadAction MemberList EntityService

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

3

ユースケースシナリオより記述

横軸はコンポーネント種別アーキテクチャ設計で決定される

シナリオのユーザ操作に対する処理をアクション処理として識別

ロバストネスで識別されたサービスと入出力するデータ・エンティティを記述

ユースケース・ロバストネス図を参考にアーキテクチャで既定されたコンポーネントを利用したシーケンスを作成するビューモデル・サービス・エンティティ３つのコンポーネントでシーケンスを作成する

ユースケースからユーザ操作に対するアクションや入力チェック、画面遷移など画面動作に関する処理を識別する

<<サービス>>

タイトル検索

<<サービス>>

タイトル予約

<<サービス>>

会員取得

ここでは主要な処理メソッドの識別が目的であるためコンポーネント間レベルで利用されるメソッドのみを記述（内部処理は別設計書で記述）

ユースケースシナリオロバストネス図


プログラム設計書（画面）

モックアップから画面レイアウトおよび画面項目の仕様と動作（検証チェックや選択データなど）を設計する

シーケンスで識別した画面動作（アクション）を設計する

4

画面モックアップ

シーケンス

QueryAction


プログラム設計書（画面）画面動作（アクション）の設計

画面動作は主にボタンのクリックで起動される上記以外にもロストフォーカスやファンクションキー押下などのタイミングで起動する処理もある

主な処理内容は以下の通りで、アクションの詳細化を行う際に分解基準として利用するアクション処理（以下の処理を実行）

1. 単項目入力検証チェックの実行2. 複合項目入力検証チェックの実行3. コントロールからの入力データ取得4. サービス（ビジネスルール）の呼び出し5. コントロールへの出力データ設定6. 画面表示状態の変更（活性不活性、フォーカス移動）※上記下線項目は別途処理として仕様化・設計が行う単位になる。単機能に分解されているため同じような実装になる

ユースケースシナリオの「検索内容を表示する」の場合アクション処理⇒検索アクション（QueryAction）

複合項目入力検証チェック⇒全検索条件が無指定の場合にエラー（IsEmptyQuery）入力データ取得⇒検索条件作成（CreateQuery）出力データ設定⇒結果表示⇒（ShowResult）画面表示状態⇒結果表示状態への変更（Mode←結果表示モード）

5



分析クラス図やエンティティ説明書からエンティティの構造、エンティティに対する操作、導出項目や構造制約（参照制約など）を設計する

6

分析モデル

エンティティ説明書



１つのエンティティから複数のエンティティ・プログラムが設計されるエンティティはさまざまな処理で利用されるため共通部品として定義される

ただ、特別な機能要求や性能向上要求によるカスタマイズをすることも可能エンティティの肥大化を防ぐ目的と複数チームによる並行開発を促進する目的

7

予約会員

会員の貸出数・予約数が判断できる会員エンティティ

他のエンティティを参照する場合に、参照するエンティティとのやり取りを行う代理のエンティティ（他エンティティの役割を行うためエンティティロールと呼ぶ）を作成して利用。データベースの集約機能を利用しているため性能的に有利。


プログラム設計書（エンティティ）エンティティの共通化

エンティティの共通化では、共通的に利用されるエンティティとはどのようなエンティティか、特定エンティティの機能のうち共通機能として扱うべき機能は何かの２つの視点で考える

共通的に利用されるエンティティは業務共通概念モデル（トップレベル）で識別されたエンティティはビジネス的に最重要で広範囲に利用される可能性が高い⇒業務共通より詳細な分析モデルにも共通化すべきエンティティが多くある

8

概念モデル

共通ビジネスエンティティ

会員エンティティ

予約エンティティ

貸出エンティティ

タイトルエンティティ

アイテムエンティティ

タイトル在庫エンティティ分析モデル


プログラム設計書（エンティティ）エンティティの共通機能

広範囲に利用されるエンティティはさまざまなエンティティと関連しさまざまな機能を提供する必要がある

エンティティの共通機能として提供すべき機能は、エンティティの典型的な利用方法を規定できれば、その利用方法から共通機能を識別する

上記が難しい場合、エンティティを内部テーブルだけで構成し、その中のデータだけで完結する機能を共通機能として提供する

なお、エンティティの実装は複数個可能で、エンティティの共通機能も複数用意することが可能である更新用・検索用にエンティティを分けて用意することは良く行われる

例) タイトルエンティティ（分析）⇒ タイトルエンティティ（実装）、検索タイトルエンティティ（実装）

9

タイトルエンティティ検索タイトルエンティティ


プログラム設計書（ビジネスロジック）

サービス定義書からシステムが提供する機能を設計する

10

サービス定義

エンティティ


詳細設計のまとめ

分析フェーズで作成された各種成果物からプログラム設計書を作成する作業。

プログラムの全体構成をシーケンスで整理し、画面・エンティティ・ビジネスロジック（サービス）を実装可能なレベルに設計をする

11


詳細設計における注意点

全般

詳細設計（設計モデル）の作成には適用するアーキテクチャを考慮する必要がある

前述のプログラム設計書は特定のアーキテクチャを前提にしたもので、分析モデルから設計モデルへの対応がどのようになるか参考になる

分析モデルで詳細設計（設計モデル）に関する制約はなるべくつけないことが望ましい

分析モデルでは詳細な技術に依存すべきでない。しかし、これは実装技術を全く考慮しなくても良いということではなく、逆に実現可能性についてはある程度考慮する必要があるということである。1坪の土地に高層ビルを建てるようなことにならないようにする

12


詳細設計における注意点画面

入力検証チェックはコントロール単位のチェック、複数項目の相関チェック、データベースを利用するチェックなど複数の実装場所を考慮する必要がある

ユーザ操作に対する動作をアクションといい設計時の重要な観点になる、多くはボタンクリックなどで起動するがロストフォーカスなど暗黙的に起動されるものをあるのでもれなく識別できるようにする必要がある

画面上の表示項目の導出項目は、ビューモデルまたはエンティティの導出項目として定義される

サービスサービスはステートレス（一時的な状態保持はしない）で設計する必要がある呼び出し回数やデータ量を考慮してサービスは設計する必要がある

プロパティの取得のためにサービスを呼び出さない

大量データは必要なデータだけ分割して取得する

検索処理は汎用化可能であるため共有化を進める

基本１サービス＝１トランザクションで設計を行う。トランザクションは自動化されている前提で、例外を送出しないと正常終了でCommit、例外を送出すると異常終了でRollbackする

業務エラーはエラーコードで表し例外を送出して通知する

13



エンティティ

エンティティは物理データベースから自動生成されたクラスを使うため設計時に物理データベースが必要になる

エンティティはデータベースの構造をほぼそのままマッピングする。（ORマッピング可能な範囲）

テーブル以外にビューのマッピングも上手に利用する

分析されたエンティティに対して、処理毎のカスタマイズを可能にするため複数の実装が行われる点を考慮

エンティティの永続化時の制約や採番機能もエンティティ側で実装可能か検討する

14



バッチ処理に関しての補足「バッチ処理」の実装パターンは２つ想定している

オンライン処理と同じトランザクション処理を行うサービスを1回または繰り返し利用した処理形態オンラインと同じデータを同時にアクセスし整合性を保つ必要がある場合

オンライン停止中に実行されるバッチ処理

大量データを取り扱う“バッチ処理”固有の注意点

エンティティを構築、管理するためのパフォーマンスとリソース消費を意識する必要がある

処理固有エンティティ、エンティティロール等の“バッチ処理”専用の設計を行って、処理に最適化する必要がある

パフォーマンスと設計のトレードオフで考慮

パフォーマンスを維持するためにはバッチ対象データの分割、並行実行等が想定される為、複数のエンティティを利用する場合は分割しやすい考慮が必要 Ex.同一の処理をエリア別に分割して、並行実行する

15


エンティティの実装他エンティティの参照

エンティティに記述するロジックは他エンティティ（外部データ）にアクセスしないことが原則エンティティ同士の結合度は下げることで再利用性をあげる目的複数エンティティにまたがる処理はサービスに記述することが第1候補

サービスがエンティティのナビゲートの責務を負う

親子などの密結合の場合はリレーションを明示してアクセスしても良い

特定の処理において他のエンティティを参照する処理をエンティティに記述したい場合は処理固有用のエンティティを作成するエンティティの肥大化を防ぐ目的と複数チームによる並行開発

特定の処理によらず他のエンティティを参照する場合は参照するエンティティとのやり取りを行う代理のエンティティ（他エンティティの役割を行うためエンティティロールと呼ぶ）を作成して利用するエンティティ間の依存性の低下や最適化に利用する

例）従業員の年間売上を人事評価に使うシナリオで、年間売上を計算するために従業員に関連する売上エンティティを全てメモリにロードして処理するとオーバーヘッドが多い。このような場合、売上In従業員エンティティロールを導入して集約された売上データのみをDBから取得して利用する

16

従業員売上従業員売上◆ 売上In従業員

全て売上データを取り扱うためオーバヘッドが大きい集約した売上データを取り扱うためオーバヘッドが小さい

Technology

エンタープライズ.Net 詳細設計編