3

オブジェクトの依存関係や要件を含むオブジェクト情報を含む文字列の解析に取り組んでいます。

これは製品構成用であり、オブジェクトは製品のビルドを構成するコンポーネントです。リストを調べて、車やコンピューターなど、他のコンポーネントを取得するために特定のコンポーネントを選択する必要のあるコンポーネントを備えたものを構築する場合のように考えてください。これは、アプリケーションで作成しようとしているロジックです。

私のアプリケーションは、Excelファイルからロードされたオブジェクトのリストを含むtreeViewコンポーネントをユーザーに提示します。ノードが表すオブジェクト間の依存関係に基づいて、treeViewのノードを適切に有効または無効にするオブジェクトのインタラクティブリストを作成しようとしています。オブジェクトのリストは、ビルドの構成を表します。したがって、オブジェクトは最終製品を構成するコンポーネントであり、特定のビルドに対してどのコンポーネントまたはオブジェクトを選択できるかについて制限があります。

これは、ロジックを記述しようとしている依存関係を含む行のサンプル形式です。

objectID_y1234_y1233_n2345
  • objectIDはこのオブジェクト(コンポーネント)のIDであり、4桁の数字であり、オブジェクトのIDに次のように1文字が含まれる非常にまれなケースがあります:12a4

  • y1234は、このオブジェクトをアクティブにするには、ID1234のオブジェクトを選択する必要があることを意味します。

  • y1233は、このオブジェクトをアクティブにするには、ID1233のオブジェクトを選択する必要があることを意味します。

    y1234とy1233はID番号の最初の2桁が同じであるため、これによりor条件が作成されます。

    したがって、このオブジェクトでは、両方を選択するのではなく、オブジェクト1234または1233を選択する必要があります。

  • n2345は、オブジェクト2345が選択されている場合、このオブジェクトがアクティブでないことを意味します。

リストされている最初の依存関係は常に「y」または「n」で始まるため、objectID_1234_n2345_y1235を持つことはできませんが、objectID_y1234_1235_n2345を持つことはできます。

また、条件が「または」条件である場合、y1234_n1233を使用できない場合は、両方にyがあるか、両方にnがあるかのいずれかです。

多くの可能なフォーマットのいくつか:

  1. objectID_y1234_2345
    これは、このオブジェクトをアクティブにするには、オブジェクト1234とオブジェクト2345を選択する必要があることを示しています。

  2. objectID_n1234_2345_y3456
    これは、このオブジェクトをアクティブにするには、objectIDで1234と2345を選択せず​​、3456を選択する必要があることを示しています。

  3. objectID_n1234_n1233
    y1234_y1233とは異なり、nが使用されている場合、条件は常に「and」であるため、このオブジェクトをアクティブにするために1234および1233を選択できないことを意味します。

不明な点がある場合は、お気軽に詳しい情報や説明をお求めください。依存関係が混乱しやすいので、これをできるだけ明確に説明しようとしています。ステートメントの長さに制限がないため、ステートメントの可能なすべての組み合わせをリストしませんでしたが、オブジェクトIDを持つより長いまたは複数の「or」および「and」条件で構成されています。

何が起こっているかの全体像:

objectIDのツリービューがあります。1つのオブジェクトを選択するときは、競合するオブジェクトを非アクティブ化して、または現在選択可能なオブジェクトをアクティブ化する必要があります。

依存関係の目的:

依存関係は2つの質問に答える必要があります...

1:このオブジェクトをアクティブにするには、どのオブジェクトを選択できませんか?

2:このオブジェクトをアクティブにするには、どのオブジェクトを選択する必要がありますか?

私の質問/問題:

このデータは非常に壊れやすく、オブジェクトが相互に依存して両方のオブジェクトを非アクティブ化し、どちらも選択できない場合があります。

例:

ID1234_y2345

ID2345_y1234

これにより、要件(依存関係)が満たされていないため、開始時に両方が非アクティブ化されるため、1234も2345もアクティブになりません。

依存関係を表す構文や形式を変更できるアイデアがあれば、それを実行できます。複雑さや問題を引き起こすことなく、要件に適合する別の方法を見つけられませんでした。

最終的に、私はこれにアプローチし、機能するソリューションを考え出すことができる方法を探しています。私はしばらくの間ソリューションを実装しようとしてきましたが、これまでのところすべての試みが失敗しました。私はさまざまな再帰的および非再帰的なソリューションを試しました。私は間違っているかもしれませんが、私は基本的にここでコンピューターに自分自身を考えさせようとしているので、これはニューラルネットワークができることだとほとんど感じています。

私は必要なすべてのリストから始めて、リストを満たすソリューションを実装しようとしていますが、リストに追加していくと、さらに多くの問題が見つかり、すべての可能性をカバーすることはできません。おそらく私はまだ発見していません。全体的に、私は時々非アクティブ化して正しくアクティブ化することができましたが、それは常に信頼できるわけではなく、そうする必要があります。

現在のロジック

ツリーでは、同じタイプのコンポーネントが同じ2つの先頭文字を共有しているため、1234、1233、および1245がグループに含まれ、ユーザーが1234を選択した場合、グループをラジオボタンのように扱います。したがって、選択したコンポーネントを追跡するリストに1234が追加され、無効になっているコンポーネントの別のリストに1233,1245が追加されます。次に、各コンポーネントをチェックし、要件が満たされているかどうかに応じて、ツリー全体が無効または有効になっていることを確認して、ツリー全体を更新します。ただし、チェック中に別のコンポーネントを無効にする必要がある場合は、現在、ツリーをもう一度チェックします。これは、しばらくの間実行し続ける可能性があるため、ひどく非効率的です。再帰の方がうまくいくかもしれないと思いましたが、デバッグが非常に難しく、問題が多すぎるという混乱が生じました。

コンポーネントのリストを確認する場合でも、再帰が方法だと思います。コンポーネントを選択するときに、使用できない他のコンポーネントを無効にしてから、無効にしたコンポーネントを確認してから、無効にしたコンポーネントが原因で無効になっているコンポーネントを確認する必要があるためです。無効など...

例:1234を無効にし、1890が1234を必要とする場合、1890を無効にします。しかし、1770は1890を必要としたため、1770を無効にします。次に1770が必要な場合は、それを無効にする必要があります。

すべてのヘルプと提案をいただければ幸いです。

4

1 に答える 1

0

私の元のロジックの代わりに機能し、実装されたソリューション。

元のロジックでは、ユーザーが選択したノードの影響を受けるすべてのノードをアプリケーションがチェックしていました。ノードの状態 (無効、有効、選択済み) は、ユーザーが選択したノードによって制御され、ユーザーが treeView でコンポーネントを選択するたびに検証されていました。

解決:

私のアプローチを再考することで、コンポーネントの依存関係が強制されることを保証するタスクを達成するアプリケーションの次のロジックを思いつきました。

ユーザーがコンポーネントを選択すると、アプリケーションは次の手順を実行します。

  • コンポーネントに互換性のないオブジェクトがあるかどうかを確認し、コンポーネントのいずれかがユーザーによって選択されているかどうかを確認します。

    • 互換性のないオブジェクトが見つかった場合、ユーザーが選択しようとしていたコンポーネントと競合しているコンポーネントを選択したことを示す情報メッセージがユーザーに表示されます。
  • このコンポーネントに必要な他のコンポーネントのコンポーネントをチェックし、これらのコンポーネントがすでに選択されているかどうかをチェックします。

    • 必要なすべてのコンポーネントが選択されていない場合、ユーザーはどのコンポーネントをまだ選択する必要があるかを示すメッセージが表示され、選択したコンポーネントのテキストが赤色に変わり、treeView で選択されます。
    • すべての要件が満たされている場合、コンポーネントが選択され、コンポーネントに赤いテキストが含まれていた場合、テキストはデフォルトの黒に戻されます。

注: プロンプトは、ユーザーが必要に応じて参照できるようにインターフェイスのログに記録されるため、オプションになります。

結論:

このソリューションにより、構成者はコンポーネントの依存関係と要件が満たされていることを確認できます。ノードを更新することが当初の意図でしたが、元のロジックでは、コンポーネントが無効になった理由をユーザーが理解できるようにする方法を考えていなかったことに気付きました。この新しいアプローチにより、コンフィギュレーターは情報を提供し、ユーザーを混乱させません。

もちろん、元のコンセプトのようなコンフィギュレーターを作成することは可能ですが、私の経験とツールの品揃えを考えると、この別のソリューションは、私のユーザーがより満足している実用的なアプリケーションを提供しました.

于 2012-09-12T23:30:21.367 に答える