非常に複雑なフォームのフィールド間の依存関係をモデル化する方法

複数の保険商品の申し込みフォームとして使用するWebアプリケーションを作成する必要があります（合計15）。このアプリケーションフォームはフォームウィザードに似ています。4〜10の製品に応じて、複数のページにまたがります。

フォームがレンダリングするすべてのさまざまな要素（入力、選択ボックス）の合計は約250ですが、最も複雑な製品でさえ170を超えることはありません。最も複雑でないものでも約80の要素が必要です。

製品ごとに1つずつ、15の異なるアプリケーションフォームを作成するのではなく、すべての製品で使用される単一のアプリケーションフォームを作成する必要があります。

想像できるように、要素には要素間に多くの依存関係があります。フィールドに値を入力すると、別のフィールドまたはフィールドのセットが（現在のページまたは次のページで）表示または非表示になります。入力した値に基づくその他の依存関係：

• 要素の値が必要かどうか
• 選択ボックスの可能な値が変更されます
• 検証制約が変更されます

ご想像のとおり、これのモデリングは非常に複雑です。問題は、これらすべての要素のモデリング（および文書化）、それらの間の依存関係、および検証制約にどのツールを推奨するかです。どのようにモデリングしますか？この場合、データモデルについてはまったく触れません。このモデルは、必要な作業の仕様の一部となり、プロジェクトの完了後の参考になります。モデルを変更しても、申請書は自動的に変更されません。

簡単にできることのいくつか：

• 特定の要素が依存する要素を確認する
• 特定の製品のフォームに含まれるすべての要素を確認する
• 特定の製品に必要な要素を確認する
• 各要素の検証ルールを定義する
• 各要素にさまざまな属性を定義する

制限：モデリングを行うのは製品マネージャーと製品所有者です。

同様の複雑なプロジェクトで、ビジネスレイヤーにインタープリターを実装し、すべてのフォーム要素に「isValid」と「isVisible」の式を使用しました

インタープリターには、かつてその目的のために設計されたUML-s Object Constraint Languageを使用しました。

残念ながら、「uml-ocl」を話す人はほとんどいないため、ルールを維持する人を見つけるのは困難です。

それをもう一度行う必要がある場合は、インタープリターにjs / vb-scriptのようなより一般的な言語を選択します

ツールの組み合わせは、複雑さの管理に役立つ場合があります。私は、人間がやり取りしやすい構造化された説明的なアプローチ（高度に形式化されたアプローチとは異なります）から始めるのが好きです。PMはスプレッドシートに慣れている必要があり、依存関係を表形式でレイアウトすると役立ちます。

1. たとえば、製品xフィールドの依存関係のテーブルです。
2. 2番目のテーブルは、フィールド間の相互作用をカプセル化する場合があります（フィールドxフィールド）。交差するセルには、最初に説明テキストが含まれる場合があります。

最初のパスとして、これはロジックの問題を明らかにしたり、ロジックを簡略化する機会を特定したりする場合があります。

また、PMはWebプログラミングを直接避けるかもしれませんが、最新の表現力豊かなクライアント側テクノロジを使用して、アプリケーションの「言語」を構築します。angular.jsなどのツールは、コンポーネントが何をするのかに焦点を当て、ノイズコードを最小限に抑えるのに役立ちます。適切なWebテクノロジーも、優れたテストサポートを提供する必要があります。

問題は、これらすべての要素のモデリング（および文書化）、それらの間の依存関係、および検証制約にどのツールを推奨するかです。どのようにモデリングしますか？

同様のプロジェクトがありました。非常に複雑なフォーム、およびそれらの多く。

• オリジナルの紙のフォーム
  • 私たちの目標は、ウェブページをそれらのように見えるようにすることでした
• エクセル
  • 画面フォーム要素データ仕様
  • データ要素名（コーディング時に非常に重要）タイプ、長さ、フォーマット、一般的な規則
• エンタープライズアーキテクト
  • UMLによる基本的なクラス設計。

エンタープライズアーキテクト（EA）

こちらがリンクです。

予選：前回使用してから数年になります。複雑なツール。大きな学習曲線。正確な結果を得るには、非常に優れたUML知識が必要です。すべての背後にメタデータがあります。したがって、EAの機能は幅が広く、奥行きがあり、謎めいており、奇抜な場合もあります。

EAはその成果物を非常にうまく統合します。しかし、私たちのチームのUMLおよびEAツールの集合的な知識は、エンドツーエンドのツールとして満足できるものにするのに不十分でした。私たちの目標はそれをそのように使用することではなかったことに注意してください。それでも、ツールの悪用（一部の側面）は、悪用するよりも適切です。

各開発者はそれを使用して、割り当てられたフォーム（またはそのセクション）のクラスを設計しました。ビジネスアナリストは、これを使用してユースケース図を作成しました。ペーパーフォーム、フォームデータ、およびプロセスは十分に確立されており、EAを採用する前に完了していたため、要件分析には使用しませんでした。

要件分析から実際のコードへの統合を約束するこの包括的なツールを活用することはできませんでした。開発者は、管理go-code-approvalに必要な基本的なクラスとシーケンス図を作成するのに十分なだけを学びました。そして、クラス図からコードシェルを生成したとしても、非常に困難であり（つまり、UMLの詳細な知識が不足して）、EAをコード開発と同期させるのに不便で面倒過ぎることは明らかでした。そのため、UML図のコーディングを開始するとすぐに、時代遅れになり無視されました。

クラスの相互作用とオブジェクトのインスタンス化を理解するには、優れたシーケンス図が非常に役立ちます。コーディング時の高レベルのマップ。

警告

有能で（適切に）完全なビジネスドメインの設計は、どのツールよりもFARよりも重要です。PTSは、優れたビジネスモデルを実行した非常にまれな時間を除いて、コードがどれほど普遍的であるかについて考えているだけです。ページとページを書くことができました。