学生管理系统建模

《学生管理系统建模》由会员分享，可在线阅读，更多相关《学生管理系统建模（8页珍藏版）》请在装配图网上搜索。

1、学生管理系统建模步骤（1）分析并得出系统的主要参与者与主要用况，并画出系统的用况图。为所有的用况撰写脚本，将脚 本放于单独的 word 文档中，并将文档与相应的用况相连接。1）确定系统的使用者通过对上面问题陈述的分析，我们可以发现系统的使用者主要有Student和Professor，同时还需要 Registrar来维护这个系统。此外，由于需要打印Student列表，故需要参与者Billing System；由于需要自 动维护课程目录的改变，故需要参与者Course Catalog。因此应该在用况视图中添加如图5-15所示的参与 者。-|_| Use Case ViewM ai nE-s-s-s

2、.-s:Billing SystmmC uni- s a 匚注t ：1 u gFrufessur Regi s tr：ir Et uderLt2）确定系统的用况通过对上面问题陈述的分析，我们可以知道参与者Student主要要做view report cards和register for courses 两件工作，而参与者 Professor 主要要做 Select Courses to Teach 和 Submit Grades 两件工作。参与者 Registrar 要维护信息，即要做 Maintain Professor Information 和 Maintain Student Info

3、rmation 两件工作，此外 Registrar 还要控制注册何时结束，即要做Close Registration的工作。由于安全性的原因，要使用系统还需要首先做 Login的工作。因此，应在用况视图中添加如图5-16所示用况。Cl o e e Regi ei 皿S-O1 LoginMaintzin. FrotesEur IrLiurmationM ai n tzin. Et iiden t Inf or ma tior.Regi e for C cnii- e e eHn-O Selert Cum-eee to TeachHn-O Siibmit -Ti-adeE Hn-O Vi ew R

4、epurt Card.3）用况图通过上面的分析我们确定了系统中的参与者，用况以及它们之间的关系，根据这些关系，可以画出系统 用况视图中的Main用况图，如图5-17所示：2）实现关键用例。做出相应的顺序图和协作图，对于每一个协作，说明其静态结构和动态结构。为了说明协作的动态结构，我们可以画出其顺序图与协作图。对于Login协作而言，由于只有一个边界 类 LoginForm 与系统的使用者交互，而任何系统的使用者都必须登陆，故可画出其顺序图和协作图，如图 5-18 和图 5-19 所示。上面我们通过构造 Login 协作实现了 Login 用况，这里再给出 register for course

5、s 用况的顺序图和协作图 如图5-20 所示。图 5-21 register for courses 协作图（3）做出系统的关键抽象，并设计相应的类和类图。1）发现系统中的类在设计时，可以从问题陈述中提炼出关键的概念，并将其抽象成相应的类。由上面的问题陈述可知，主要有Student和Professor使用系统，Student应该有Schedule，系统关键处理的是Course,而应该由 CourseOffering来提供相应的Course。在系统之外还有遗留下来的CourseCatalog系统。因此可以如下图所示抽象出这些关键概念，以及与之相关的一些概念。同时还可以绘制这些关键抽象的 类图，如

6、图5-22 所示。二目 C Milt- e eOffer ins gt tr i but e e .)Key Ab e a: t i otle| - s :zzzzzzz瓦Main+ H：BillingSyE tmm+ O ClueeRegi etrati unCurLtruller+ClueeRegi etrati uriFarm1-Q Course+罔 C Milt- e eC ：mt al o g+C Milt- e eC ：mt al o gSys t em+ Q CuiifEeOffer ing+ Q FulltimeStudmnt+Lu gi tlF erm+ Q Farttime

7、Studmnt+ Q Fr i m ：ryS che dill eOffer i nglrLfub + Q FrufesEur+Regi sterForCom-sesForm+ O Regi etrati unCuntroller 0 -Q Schedule+ Q S che dill eOffer i rLglnf o0 -Q Student-O丄 Ass01：i:mti unE2)确定关键类的属性以 CourseOffering 类的属性为例，由于实体类 CourseOffering 的属性指明了所提供课程的关键性质，故 单独对其画出类图CourseOffering (attributes

8、),如图5-23所示。ICey Ab e trac t i unEL-l a e eRe gi e tr 注11 口nF urmCuizrEeOfferingEusiness ServiUse-Case RealizationsAssociation Class Exampl3)类图LjLj目目目目 Q-OQ 0|白 Q +:+:-：s-e-e-e-e-.s-.e针对每个关键类给出类图。以 CourseOffering 为例,由于实体类 Schedule 与实体类 CourseOffering 存在 着主修与选修两种关联,而对于不同的关联存在不同的特征信息与处理,故对于这两个关联分别设置关联

9、类ScheduleOfferinglnfo与PrimaryScheduleOfferinglnfob，用关联类的属性刻画关联的特征信息，而将关联 的处理映射为关联类的操作。这里应特别注意的是对于不同的关联, CourseOffering 扮演的角色以及多重性 都不同。根据上面的分析，画出 CourseOffering 关联类图，如图 5-24 所示。在分析过程中，我们已经知道了实体类 Schedule 与实体类 CourseOffering 之间的主修与选修两种关联关 系，对于不同的关联关系设置了关联类并画出了类图。现在，我们只需要对于分析中得出的类图作进一步 完善，加入实体类Schedule

10、的详细设计信息后，画出类图Schedule,如图5-25所示。对于实体类Professor而言，由于它要给出所提供的课程，因此它与CourseOfferingList类有关联，且 Professor在此关联中扮演instructor角色。故可画出类图Professor，如图5-26所示。对于实体类Student而言，由于它要被分成Fulltime和Parttime两类，因此建立类Classification，并通过 实体类 Student 对于类 Classification 的聚合来表现出 Student 所具有的分类特征。此外还须建立类 Classification 的子类 Fulltim

11、eClassification 和 ParttimeClassification，它们的构造型均为 entity，故用它们具 体表现不同类Student所具有的不同的特征属性。除了分类之外，由于学生要选课并最终得到自己的课表，因此类Student也要聚合实体类Schedule以代 表当前学生的课程表信息。根据上面对于实体类Student的分析，可以画出类图Student，如图5-27所示。（4）实施建模分析并得出系统的节点，设计系统的实施图。1）设计节点通过对上面问题陈述的分析，我们可以知道Student与Professor通过PC使用本系统，同时应该有一个 服务器RegistrationSe

12、rver维护系统信息并控制课程的注册，还有遗留下来的课程目录系统CourseCatalog System和列表打印系统BillingSystem。同时这些节点都进行相应的处理工作，故应该全部为处理节点。这 里应特别注意的是CourseCatalog System和BillingSystem由于是遗留系统，其构造型应该为legacy。故应 该给系统的实施视图中添加如图 5-28 所示的处理节点。白“回QJ flmgzcyBillirLgSyE tEm仃5s gai：y C Milt- e eC atalug E严 tmm田口 Desktop FCRegi eionS旺v北2）设计实施图通过上面的分析我们已经确定了系统的处理节点。在这些节点中，PC机和遗留下来的Coursecatalog System和BillingSystem都不能作为系统的中心，故应该让RegistrationServer居中协调，其它的节点通过校 园网络与 RegistrationServer 进行通讯。这里应特别注意的是由于是通过校园网络进行通讯，故连接的构造 型应该为 Campus LAN。根据上面的分析，可以画出系统的实施图，如图 5-29 所示。