私はシステムをモデリングしており、次のユースケースがあります{教師の任命(管理者)、成績の記録(教師)、学生の管理(管理者)、出席の記録(教師)、共同カリキュラムの管理(管理者)}ユースケースのステップとユースケースのシナリオを考え出す際の問題。私はすでに概念クラス図を描いています。誰かがそれについてどうやって行くかについて考えを持っていますか?
前もって感謝します
私はシステムをモデリングしており、次のユースケースがあります{教師の任命(管理者)、成績の記録(教師)、学生の管理(管理者)、出席の記録(教師)、共同カリキュラムの管理(管理者)}ユースケースのステップとユースケースのシナリオを考え出す際の問題。私はすでに概念クラス図を描いています。誰かがそれについてどうやって行くかについて考えを持っていますか?
前もって感謝します
このような記事が役立つ場合があります。
私の考え方。ユースケースの一般的な説明があるので、構築しているシステムが何をすべきかがわかります。しかし、これらのユースケースには多くのしわや特殊なケースがあることは間違いありません。[ちなみに、「学生の管理」は、「教師の任命」とはかなり異なる粒度のように見えますが、「学生の登録」、「学生の一時停止」、「大学院生」などが必要であると思われます。]
したがって、次のステップは、ユースケースの詳細を提供することで、システムの要件をより多く把握することです。それを人やシステムの行動で表現しています。システム コンテキスト図などはありますか? これにより、システムがやり取りするすべてが表示されます。次に、アクター、システム、および他のシステムによる一連のアクションとして、シナリオを表現します。
The Teacher logs on
TheSystem presents a menu
The Teacher selects "record grade"
The System presents a list of classes taught by the teacher
The Teacher selects class
etc.
しわは、発生する可能性のあるバリエーションを考慮した結果です。不合格の場合の特別な措置はありますか? 特定のタイプの学生の採点に関する制限はありますか? そのため、そのような「興味深い」ケースに対して追加のシナリオを作成します。
私の理解では、この段階では特定のクラスとクラス図は必要ありません。後で、「システムが教師によって教えられたクラスのリストを提示する」などの 1 つのステップを検討し、クラス図を使用してシステムがそれをどのように実装するかを検討できます。
ここでの目的を思い出してください。満たす必要のある要件の全体像を把握してください。
さらに、クラスでこれを行う必要はないかもしれませんが (受講しているクラスのように聞こえます)、要件収集のもう 1 つの有用なステップは、誤用のケースを特定することです。つまり、システムでどのような問題が発生する可能性があるかを把握する必要があります。たとえば、誰かがシステムにハッキングしているという誤用のケースが考えられ、そのような誤用のケースを修正するために実行する手順を書き出すことができます。ちょうど考えるべきこと。