ラピッドプロトタイピング
一般的に、この用語は、比較的短時間で既製のボタンを備えたグラフィカルインターフェイスを取得できるようにする開発環境のメソッドまたは機能の名前として登場しました。
私の実践では、これにより、多くのコードが記述される前に、ユーザビリティテストと修正のみが許可されました。
私たちの実践（エンタープライズオートメーション）では、小さな領域を「自動化」する必要がある状況がしばしば発生します。 「コーナーのバッグ」と呼ばれるもの。 システム内の何かとどこかを説明する機能を実装する必要があります。 会計処理は、この何かの受け取りと支出の操作がどこかにあることを意味します。
実際、単純な状況の場合、プロトタイプ化されたソリューションには十分な機能があり、より複雑な場合には、インターフェイスおよびビジネスロジックの開発プロセスを分散できます。 さらに、複雑なビジネスプロセスであっても、ユーザーは開発の非常に早い段階でデータの入力を開始できます。
プロトタイピングの仕組みを理解するには、最初にサブジェクト領域のデータ構造を記述する概念を理解する必要があります。
詳細に進むことなく（詳細はドキュメントの抜粋にあります ）、すべての構造は次のクラスに属します。
- ディレクトリ
「静的」情報を含む。 たとえば、商品、オフィス、倉庫。 - テーブルの分離
異なるディレクトリ間の多対多の関係に関する情報を含む - ドキュメントと表のパーツ
ドキュメントは、サブジェクト領域のイベントに対応しています。 たとえば、販売または購入。 各ドキュメントは、「ヘッダー」、つまりフィールドと表の部分のセットで構成されています。 表セクションには、さまざまな属性がリストされています。 たとえば、販売した商品の量、金額、商品量などです。 - まとめ
このオブジェクトは理解するのが最も難しいので、いつも類推して説明します。 OLAPに精通しているのはキューブです。 測定値、変数があります。 1つの次元は一時的なものです。 1Cに精通している開発者にとっては、これはレジスターであり（はるかに複雑な構造ですが）、最後の例えはアカウントです。 それでもはっきりしない場合は、 ドキュメントを読んでみてください。 または、次に何が起こるかを見てください。
次に、サブジェクト領域の構造は、ディレクトリの種類、ドキュメントの種類、デカップリングテーブルの種類、およびスクリプトを介して相互作用する合計のセットとして記述されます-C＃の特別なクラス。
ディレクトリまたはドキュメントのタイプは、対応するオブジェクトの内部構造を定義します。 各タイプのディレクトリまたはドキュメントは、1つのデータ単位を保存するためのC＃のクラスに対応しています。
これで、プラットフォームにどのようなラピッドプロトタイピングがあるかを説明できます。
ラピッドプロトタイピング -メタデータの記述に基づいて、アクセス制御、実行時の外観の編集、その他の機能に基づいて、フル機能のデータ編集フォームを自動的に生成する機能。
ディレクトリとドキュメントの場合、レコードのリストのフォームとレコードの編集が利用できます。 結果については、レポート作成フォーム。 分離テーブルは、対応するディレクトリエントリのフォームを編集することで利用できます。
すでに混乱している場合でも-大したことはありません。 練習に移りましょう、すべてが明らかになります！
モニターがブラインドになるまで段階的に
「コーナーでのバッグの会計」の標準的な例を実装しましょう。
顧客（倉庫管理者）は、倉庫で包装袋の記録を保持したいと考えています。 バッグは他の製品とは別に保管され、それらを処理する機能は単に「ロード」で倉庫に捨てられることが知られています。 バッグにはいくつかのサイズがあります。 いつ（どこの倉庫で）いくつ、どのバッグが横になっているのかを知る必要があります。 バッグを発行または受け入れたときの人。
問題の声明から、サイズのあるバッグのディレクトリ、倉庫のディレクトリ、「バッグの残り物」の要約、および「バッグ」の表部分を持つドキュメント処理バッグが必要であることは明らかです。 バッグの種類はほとんどない（最大10個）と想定しているため、フラットリストを作成するだけで十分です。
行こう 新しいタイプのディレクトリを作成します（写真を散らかさないように、アニメーションgifを作成しました）。
倉庫のディレクトリは作成しませんが、基本的なソリューションの内容を活用します。
「バッグの残り」の結果を作成します（小さな余談-システムの主な言語は英語です。このタスクでは重要ではないため、ロシア語への翻訳は省略します）
すべての読み取り専用フィールドは、プラットフォームによって自動的に生成されます。
そのため、これまではキーボードからBags / Capacity、BagsStock / Bags of Remains、BagID / Bag、Store / Warehouseのみを入力しました。 それ以外はすべてシステムによって生成されます。
バッグの領収書と費用に関する情報を保存する必要があります。 さらに、各教区にはいくつかのサイズのバッグがあります。 バッグの表部分を作成します。
最も単純な表部分。 バッグと数量へのリンクの2つのフィールドのみがあります。
次に、この表部分を使用してドキュメントを説明します（1つのタイプの表部分は、複数のドキュメントで使用することも、1回で複数回使用することもできます）
ヘッダー内の作成されたドキュメントには、商品が出庫または入庫される倉庫（または倉庫）のみが含まれます。 ドキュメントには、このドキュメントが結果に与える影響を決定する2つの状態（用語ではサブタイプ）があります。
出来上がり：マウスで3分間クリックすると、これらのバッグを受け取って消費するための新しいバッグとドキュメントを作成できます！
ここで、自分で見てください：
ユーザーに権限を付与し、ユーザーが独自の列をカスタマイズできます。 フォームには、すべての列の設定、グループ化、フィルターがすべて含まれています。 同様にドキュメントで：
権利の分配は別々のサブタイプで行われ、すべての設定も機能します。
ところで。 対応するオブジェクトのプロパティからだけでなく、それに関連付けられているものからも列をフィルタリングまたは選択できます。
ドキュメントの例では、「作成者」列にはユーザーディレクトリで指定されたユーザー名が含まれています。 同様に、倉庫があるオフィスの名前などを表示できます。
ただし、結果を作成するまで。 ここでは、キーボードを取り上げて、プログラマが管理者とどのように異なるかを示す必要があります。
このプログラムを書く必要があります：
foreach(var r in document.Bags) { transactions.Add(new BagsStockTransaction { BagID = r.BagID, StoreID = document.StoreID, Quantity = r.Quantity, Amount = 0 }); }
そして、反対の符号のフローについても同様です：
行を調べて、それぞれについて、残りの合計袋に基づいて投稿を生成します。
これで、バッグの到着と支出の後、既製のレポートデザインフォームを使用して、必要に応じてその中のデータをひねることができます。
合計
すべての操作を完了するのに5分32秒かかりました。
その結果、絶対に使用可能なインターフェースができました。
残念ながら、すべてのドキュメントを1つの記事にまとめることはできません。そのため、プロパティのローカライズなどの詳細を省略し、権利管理のフォームを表示しませんでした。 主なことは、データを入力できるようになったことです。 より複雑なロジックが必要な場合は、簡単に完成させることができます。最も重要なことは、画面フォーム、Webサービス、統合テスト、その他のビジネスロジックの開発に同時に取り組むことができることです。 そして、各開発者には、作業を検証するツールがあります。
ちなみに、現時点では10行のコードしか書かれておらず、ミスを犯すのは非常に困難です-それだけです。 プログラミングはもう必要ありません。何もする必要はありません。マーフィーの法則の結果、エラーはありません！
これがもう1つの理由です。それに基づいて、 Ultimaソリューションをサポートするコストは競合他社よりも低いと主張します。 分析に専門家の1時間あたりの費用を含めても。