学生管理系统建模
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
学生管理系统建模
步骤
(1)分析并得出系统的主要参与者与主要用况,并画出系统的用况图。为所有的用况撰写脚本,将脚本放于单独的word文档中,并将文档与相应的用况相连接。
1)确定系统的使用者
通过对上面问题陈述的分析,我们可以发现系统的使用者主要有Student和Professor,同时还需要Registrar来维护这个系统。此外,由于需要打印Student列表,故需要参与者Billing System;由于需要自动维护课程目录的改变,故需要参与者Course Catalog。因此应该在用况视图中添加如图5-15所示的参与者。
2)确定系统的用况
通过对上面问题陈述的分析,我们可以知道参与者Student主要要做view report cards和register for courses 两件工作,而参与者Professor主要要做Select Courses to Teach和Submit Grades两件工作。参与者Registrar 要维护信息,即要做Maintain Professor Information和Maintain Student Information两件工作,此外Registrar 还要控制注册何时结束,即要做Close Registration的工作。由于安全性的原因,要使用系统还需要首先做Login的工作。因此,应在用况视图中添加如图5-16所示用况。
3)用况图
通过上面的分析我们确定了系统中的参与者,用况以及它们之间的关系,根据这些关系,可以画出系统用况视图中的Main用况图,如图5-17所示:
(2)实现关键用例。做出相应的顺序图和协作图,对于每一个协作,说明其静态结构和动态结构。
为了说明协作的动态结构,我们可以画出其顺序图与协作图。对于Login协作而言,由于只有一个边界类LoginForm与系统的使用者交互,而任何系统的使用者都必须登陆,故可画出其顺序图和协作图,如图5-18和图5-19所示。
上面我们通过构造Login协作实现了Login用况,这里再给出register for courses用况的顺序图和协作图,如图5-20所示。
图5-21 register for courses协作图
(3)做出系统的关键抽象,并设计相应的类和类图。
1)发现系统中的类
在设计时,可以从问题陈述中提炼出关键的概念,并将其抽象成相应的类。由上面的问题陈述可知,主要有Student和Professor使用系统,Student应该有Schedule,系统关键处理的是Course,而应该由CourseOffering来提供相应的Course。在系统之外还有遗留下来的CourseCatalog系统。
因此可以如下图所示抽象出这些关键概念,以及与之相关的一些概念。同时还可以绘制这些关键抽象的类图,如图5-22所示。
2)确定关键类的属性
以CourseOffering类的属性为例,由于实体类CourseOffering的属性指明了所提供课程的关键性质,故单独对其画出类图CourseOffering (attributes),如图5-23所示。
3)类图
针对每个关键类给出类图。以CourseOffering为例,由于实体类Schedule与实体类CourseOffering存在着主修与选修两种关联,而对于不同的关联存在不同的特征信息与处理,故对于这两个关联分别设置关联类ScheduleOfferingInfo与PrimaryScheduleOfferingInfob,用关联类的属性刻画关联的特征信息,而将关联的处理映射为关联类的操作。这里应特别注意的是对于不同的关联,CourseOffering扮演的角色以及多重性都不同。
根据上面的分析,画出CourseOffering关联类图,如图5-24所示。
在分析过程中,我们已经知道了实体类Schedule与实体类CourseOffering之间的主修与选修两种关联关系,对于不同的关联关系设置了关联类并画出了类图。现在,我们只需要对于分析中得出的类图作进一步完善,加入实体类Schedule的详细设计信息后,画出类图Schedule,如图5-25所示。
对于实体类Professor而言,由于它要给出所提供的课程,因此它与CourseOfferingList类有关联,且Professor在此关联中扮演instructor角色。故可画出类图Professor,如图5-26所示。
对于实体类Student而言,由于它要被分成Fulltime和Parttime两类,因此建立类Classification,并通过实体类Student对于类Classification的聚合来表现出Student所具有的分类特征。此外还须建立类Classification的子类FulltimeClassification和ParttimeClassification,它们的构造型均为entity,故用它们具体表现不同类Student所具有的不同的特征属性。
除了分类之外,由于学生要选课并最终得到自己的课表,因此类Student也要聚合实体类Schedule以代表当前学生的课程表信息。
根据上面对于实体类Student的分析,可以画出类图Student,如图5-27所示。
(4)实施建模分析并得出系统的节点,设计系统的实施图。
1)设计节点
通过对上面问题陈述的分析,我们可以知道Student与Professor通过PC使用本系统,同时应该有一个服务器RegistrationServer维护系统信息并控制课程的注册,还有遗留下来的课程目录系统CourseCatalog System和列表打印系统BillingSystem。同时这些节点都进行相应的处理工作,故应该全部为处理节点。这里应特别注意的是CourseCatalog System和BillingSystem由于是遗留系统,其构造型应该为legacy。故应该给系统的实施视图中添加如图5-28所示的处理节点。
2)设计实施图