ユーザーがパスワードを忘れる機能のためのUMLアクティビティ図の描画
私は、ユーザーがパスワードを忘れたときに自分のパスワードを取得する機能のUMLアクティビティ図を作成しようとしています。次のようになります。
ご覧のとおり、この機能には、異なる段階で2つのリクエストが必要です。1つはユーザー名の入力用で、もう1つは確認コードの入力用です。したがって、プロシージャ全体を2つのサブプロシージャに分割して、それぞれが単一の要求と応答のペアを表すようにすることができます。そのため、この機能を説明するために1つまたは2つのアクティビティ図を使用する必要があるのではないかと思います。アクティビティ図は、単一の機能または単一の要求/応答ペアに対応する必要がありますか？
私の意見では、前者は完全性をもたらしますが、複雑さが増します。複雑さは後者で解決できますが、パーティションと依存関係の問題も発生します。私にとって決めるのは難しいです、私にいくつかの提案をしてください。
1つまたは2つの図を使用するかどうかは、表示する内容によって異なります。
- 機能全体の動作
- 特定のリクエストが届いたときにシステムが行うべきこと
私にとっては、機能全体の1つのアクティビティ図を作成するのが理にかなっています。次に、特定の要求を受信したときにシステムが実行することの詳細を調べる必要があると感じた場合は、nr2も実行してください。おそらく、リクエストと、どのエンティティ（Javaクラス）など）がその処理に参加するかを示したいので、シーケンス図が適切なレベルになるでしょう。この場合は、ダイアグラムを作成せずにコーディングしますが、練習として、アクティビティとシーケンスダイアグラムの違いとそれらがどのように関連しているかを確認するための簡単なシーケンス図を作成できます。ハッピーラーニング！:-)
華麗なデザイン。したがって、どのハッカーも「パスワードを忘れた」機能を使用して、使用中のユーザー名を判別できます。ユーザー名を入力して「パスワードを忘れた」を押すだけで、ハッカーがエラーを受け取った場合、それは無効なユーザー名です。
10倍悪いのは、ユーザーのパスワードを表示できることです。それは犯罪的に過失です。百万年以内にユーザーのパスワードを表示できるようになってはいけません。可能であれば、システムに侵入したハッカーがそれを表示する可能性があります。保存するのは、ソルトされたパスワードのハッシュです。そして、ソルトされたパスワードのハッシュがわからない場合は、パスワードを知って実装できるようになるまで、パスワードの処理を避けてください。
「パスワードを忘れた」場合の正しい方法は、ユーザーに伝えるのではなく、新しいパスワードを入力できるようにすることです。そのため、確認コードは限られた時間だけ機能する必要があります。これは、ハッカーが電話を手に入れ、確認コードを読み、パスワードを自分のいずれかに変更する機会をハッカーに与える可能性があるため、たとえば1時間機能する場合です。選択。