「画面の状態」：それらすべてを簡潔に表現するにはどうすればよいですか？
ソフトウェアにいくつかの画面がある場合、それらの画面のさまざまな状態をどのように表現しますか？たとえば、画面に3つのチェックボックスがある場合、合計で8つの組み合わせがあり、最初はその画面に8つの状態があると思います。ポップオーバーウィジェットやスライドなどがある場合はどうなりますか...そして、これらすべてのバリエーションを組み合わせると、1つの画面の多くの状態が表されます。
私のソフトウェアは20の画面しか持つことができませんでしたが、2000または無制限の数の「状態画面」を持つことができました。
これらすべてを簡潔に表現するにはどうすればよいですか？このための図はありますか？ UMLダイアグラムは、プログラムの機能面とその実装方法、およびUIに使用されますか？ある種のユーザーインターフェイスモデリング言語はありますか？
UML（または他のタイプの実用的な設計）では、指摘したように、状態の可能なすべての組み合わせを設計する必要はありません。それは不可能です。
UMLは何かをモデル化することを目的としており、それだけです。考えられるすべての状態の組み合わせを思い付く必要はありません。
デザイナーまたはUX担当者は、通常、コンポーネントごとに3つの異なる状態を覚えておく必要があります。
1 /空の状態2 /空でない状態3 /エラー状態
一般的に、さまざまなコンポーネントの構成は、一般的なユースケースをカバーする手段として提示されます。たとえば、5つのテキストボックスのフォームを持つことができます。空のテキストボックスの状態がどのように見えるかの1つの例とエラー状態の1つの例をデザインが提供するだけで十分です。互いに異なる組み合わせで5 * 3の状態を持つことは完全な狂気です。それどころか、それに付加価値はありません。
ポップオーバーやその他のコンポーネントがある場合は、同じルールに従ってください。経験則では、実際には、コンポーネントの動作に関するデフォルトのルールセットを作成することです。そうすれば、これらのコンポーネントの組み合わせについてあまり心配する必要はありません。
たとえば、モーダル画面をウィンドウの中央にポップアップする画面として定義し、Zインデックスが何よりも高く、さらにその上でアクティブにできるのは、モーダルのタイプのみである場合、他のコンポーネントを気にすることなく、特定のコンポーネントのルールを定義するだけで、モーダルが（ユースケースに応じて）非常に予測可能な動作をするように、適切なルールのセットを定義しました。
だから、物事を非常に細かくしてください！特別なルールを定義する必要がある特定の「状態」にさまざまな組み合わせを混在させないでください。これにより、実際には必要のない複雑さが増すだけです。