【问题标题】:Who will be the actors in this scenario for the use-case diagram?在这个场景中,谁将成为用例图的参与者?
【发布时间】:2016-01-16 18:33:35
【问题描述】:
  • 这两种情况下的演员都是学生和系统吗? (这两个案例整体指向一个系统)

    1. 在大学注册学生:学生提供他或她的 个人详细信息(姓名、地址、出生日期)以及代码 他或她所在的课程(例如计算机科学学士) 希望报名。创建学生记录,并创建一个唯一的学生 ID 号分配给学生。系统自动 为学生招收该课程的任何核心第一年科目。

    2. 为学生注册一门学科:学生提供他或她的学生 ID号和他或她所在主题的主题代码 想报名。系统检查请求的主题 学生被允许参加学生注册的课程。 如果不是,则拒绝注册请求。系统检查什么 科目(如果有的话)被指定为该科目的先决条件 学生希望注册的。如果学生通过了所有 先修科目,他或她就读于所需的科目。 否则,注册请求将被拒绝。

【问题讨论】:

    标签: actor use-case


    【解决方案1】:

    用例的参与者将是用户。学生(或可能是大学雇员)。您可能有一个通用用户,并从中扩展出不同的用户类型。

    在这种情况下,系统可能是用户正在与之交互的实际程序。所以用例代表了系统用户如何与系统交互。有点像下图,虽然我的图在系统边界内没有细节。

    在某些用例中,您可能正在检查系统的一部分,然后可能有来自相关案例之外的系统参与者与之交互。

    在这种情况下,您的系统可能是参与者,具体取决于系统(或程序)的模块化方式。访问数据库也是如此。

    第二张图片是对上述用例“运行”的仔细观察。它正在查看系统中的一个模块。

    您可以从我的图片中看到,这取决于系统边界的定义方式。 UML 图变化很大,其中大部分取决于预期的详细程度。如果是学校作业、工作规范、引用、想法或简单的想法表达。

    我希望这会有所帮助。

    【讨论】:

    • 系统在这里扮演着不同的角色,例如:1. 大学招收学生,2. 学科招收学生 3. 创建一个新科目,那么每个角色会有不同的演员吗?我可以给这些演员起什么名字?
    • 但是系统也必须执行不同的任务,例如注册学生或检查条件
    猜你喜欢
    • 2020-07-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-01-08
    • 1970-01-01
    • 2013-02-06
    相关资源
    最近更新 更多