ワークフローの詳細:
|
このワークフローの詳細の目的は、データベース内に保持する設計クラスを識別し、対応するデータベース構造を設計することです。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
このワークフローの詳細には、次のことが含まれます。
データベースと永続データの記憶領域と取り出しのメカニズムは、アプリケーションのコンポーネントとサブシステムの全体的な実装の一部として実装、テストされます。
このワークフローの詳細に関連する追加情報へのリンクを提供します。
推敲フェーズで開始し、作成フェーズと移行フェーズで繰り返します。
オプション (システムにデータベースが含まれる場合は必須)
永続クラスを担当する設計者は、永続性の一般的知識と永続性メカニズムの詳細な知識を持つ必要があります。この設計者の第 1 の責務は、永続クラスを識別し、この永続クラスが永続性メカニズムを適切に利用するようにすることです。データベース設計者は、設計モデル内の永続クラスを理解する必要があるので、オブジェクト指向の設計と実装の手法について、実践的な知識を持たなければなりません。データベース設計者はさらに、データベースの並行性と分散の問題について詳しい背景知識を持つ必要があります。
推敲フェーズでは、このワークフローは、永続性戦略に拡張性を持たせること、そしてデータベース設計と永続性メカニズムがシステムのスループット要求をサポートすることに重点を置きます。「作業: クラス設計」で識別された永続クラスが永続性メカニズムにマッピングされ、データを多用するユース ケースが分析されてメカニズムが拡張性を持つことが確認されます。永続性メカニズムとデータベース設計が評価、検証されます。
永続性は設計作業の不可欠な部分として扱われなければならず、設計者とデータベース設計者の綿密なコラボレーションが必須です。通常、データベース設計者は「浮動的な」リソースであり、永続性の問題に対処するコンサルティングのリソースとして複数のチームの間で共有されます。データベース設計者は通常は永続性メカニズムも担当します。永続性メカニズムを購入せずに構築する場合は、通常は永続性メカニズムを担当するチームが存在します。大規模なプロジェクトでは、通常は、データベース設計者の小さいチームが、両方の設計チームの間とデータベース設計者相互の間で作業を調整し、プロジェクト全体で一貫性を保って永続性が実装されるようにする必要があります。
Rational Unified Process
|