データモデリング

追加ケース処理データは、ケース処理中に入力されたユーザー設定など、データオブジェクトの外部に存在することが多く、ケースのライフサイクルに影響を与えます。 システムでは、そのデータの保管場所が認識されている必要があります。 ベストプラクティスとして、ケースのようなワークオブジェクトに保管するのではなく、既存のデータオブジェクトにないデータを保管するケースタイプと同じ名前でデータクラスを作成するようにしてください。

たとえば、LibraryReservationケースタイプのユーザーは氏名、メールアドレス、電話番号、図書館カード番号などの利用者情報をPatronデータオブジェクトに保管します。 ケースの処理中に、予約プロセスの音声支援を有効にする選択肢が提示されます。 アプリケーション開発者は、このブーリアン選択による単一値のデータを、ケースタイプと同じ名前のデータオブジェクト、この場合はLibraryReservationに保管します。

ワークオブジェクトをコンテナのように牽引する貨物列車を想像してみてください。 コンテナはケース処理の補助的なデータを表し、データオブジェクトに属しません。 そのデータを移動して共有する場合、ワークオブジェクトの中に保存されている場合は効果的に行うことができません。 再利用と移植性を最大化するため、データオブジェクトに存在しないデータは、前の例のLibraryReservationのように、関連ケースタイプと同じ名前のデータクラスで保存するようにします。

次の画像で「+」アイコンをクリックすると、データオブジェクトの外部に存在するデータの保存について詳細を表示できます。

開発者は、データオブジェクトやプロパティを作成する前に、リードシステムアーキテクトとデータモデルを検証しておきます。 データを作成して操作する前にデータモデルを確立することで、将来の開発時間が節約され、アプリケーションのパフォーマンスに影響を与える可能性のあるエラーの量を最小限に抑えられます。 

UIビューによるデータの追加

ビューを作成する際にデータモデルの一部を作成することはできますが、開発者はデータがアプリケーションのさまざまなコンポーネント間でどのように相互作用し、再利用されるかという全体像を見逃してしまう可能性があります。 データモデルは再利用と継承を意識し、まずData Explorerで作成するのがベストプラクティスです。

Configure a view画面を使用すると、アプリケーションのアップデートライフサイクル全体で必要に応じて新しいフィールドを追加できます。 たとえば、アプリケーションのデータモデルにはFirst Name、Last Name、Addressなどの顧客情報を集約するCustomerという名前の再利用可能なデータオブジェクトが含まれています。 パッチリリースについては、仕様としてアプリケーションで顧客のアカウント番号を収集することが求められています。 Configure a view画面でこのフィールドの追加を選択できます。 

以下の画像の中央にある縦線をスライドすると、Configure a view画面からフィールドを追加した場合とData model画面で追加した場合の違いを表示できます。