基于uml的网上选课系统

学生网上选课系统 随着高校教育教学改革的深入, 很多高等院校都开始对课程设置结构进行优化, 从传统课程结构的单一性转向现代课程结构的基础性和综合性, 从纵深型转向宽广型, 越来越多的高校实行学分制教学, 开设了大量的选修课, 但是目前大多数学校使用教务管理软件是诸如面向过程方法等非面向对象技术开发的, 这使得这些管理软件在可扩充性、交互性、网络应用等方面存在很多不尽人意的地方, 很难适应教育需求的变化。UML (Unified Modeing Language) 统一了Booch、Rumbaugh和Jacobson的表示方法, 融入了软件工程领域的新思想、新方法和新技术, 提出如模板、扩展机制、活动图等新概念, 使它不但适用于面向对象的软件分析与设计, 还支持从需求分析开始的软件开发的全过程, 最终统一为大众所接受的标准建模语言。 1、需求分析 网上选课系统是一个高等院校用来进行对学生选修课程管理的管理信息系统（MIS）。网上选课系统的产生是因为在校学生日益的增多。如果仍然通过传统的纸上方式选课，既浪费大量的人力物力，又浪费时间。同时，在人为的统计过程中不可避免出现的错误。因此，通过借助网络系统，让学生只要在电脑中输入自己的个人选课信息来替代有纸化的手工操作成为高校管理的必然趋势。该信息系统能够为学生提供方便的选课功能，也能够提高高等院校对学生和教学管理的效率。网上选课系统的功能性需求包括以下内容： （1）系统管理员负责系统的管理维护工作，维护工作包括课程的添加、删除和修改，对学生基本信息的添加、修改、查询和删除。 （2）学生通过客户机浏览器根据学号和密码进入选课界面，在这里学生可以进行查询已选课程、指定自己的选修课程以及对自己基本信息的查询。 满足上述需求的系统主要包括以下几个小的系统模块： （1）基本业务处理模块。基本业务处理模块主要用于实现学生通过合法认证登录到该系统中进行网上课程的选择和确定。 （2）信息查询模块。信息查询模块主要用于实现学生对选课信息的查询和自身信息的查询。 （3）系统维护模块。系统维护模块主要用于实现系统管理员对系统的管理和对数据库的维护，系统的管理包括学生信息、课程信息等信息的维护。数据库的维护包括数据库的备份、恢复等数据库管理操作。 2、系统建模 2.1、创建系统用例模型 需求分析的目标就是建立需求模型, 即从功能需求出发建立用例模型, UMl 的用例视图从用户的需求中提取,每个用例都指定了客户的需求，他们需要系统干什么。用例图为设计活动不仅记录需求而且还提供了一种挖掘的信息, 它记录了需求到设计结果之间的映射关系,能够确保设计结果具有明确的根据或者说具有可维护性, 基于UML的软件开发过程是以用例驱动的。 用例图(Usecase Diagram) , 用于描述系统的功能, 并且从用户的角度指出每个功能的执行者(Actor) ,一个用例图详细描述一个系统或系统的一部分的行为。创建系统用例的第一步是确定系统的参与者。网上选课系统的参与者包含以下二种： （1）Student(学生 ) （2）SystemManager(系统管理员) 2.1.1  学生用例图 学生用例能够通过该系统进行如下活动： （1）查询选课信息。学生可以在查询界面了解可供自己选择的各门课程的详细信息。 （2）登录选课系统。学生能够根据自己的学号和密码登录选课系统，如果身份验证失败，不得进行下一步操作。如果通过身份验证才能进入下一个操作界面。 （3）选择所修课程。在选择课程的界面选择自己要选修的课程并确认提交。 （4）查询个人信息。可以通过查询界面查询本人的基本信息。 2.1.2  系统管理员用例图 系统管理员用例能够通过该系统进行如下活动： （1）登录。系统管理员使用账号和登录密码登陆系统进行本系统的管理和维护工作。 （2）添加学生信息。将新入校的新生的个人基本信息录入到本系统，在数据库中保存。 （3）修改学生信息。对于个人基本信息发生变化的学生，修改数据库中相关学生的个人基本信息并保存。 （4）删除学生信息。将不需要再保存的学生个人基本信息从数据库中删除。 （5）查询学生信息。根据学生的学号和姓名对在校学生的个人基本信息进行相关的查询。 （6）添加选修课程。将新的课程添加到选课系统并保存到数据库。 （7）修改选修课程。对数据库中原有的课程信息进行修改并保存到数据库中。 （8）删除选修课程。将不再开设的选修课程从数据库中删除。 2.2、创建系统静态模型 用例图描述了系统的功能, 但对于系统内功能的具体设计及协作关系的描述, 则需要进一步进行静态建模和动态建模。系统静态模型可以根据问题描述及用例, 通过词法分析提炼出系统的对象, 进而画出类图,用以表示系统静态模型。建立静态模型后, 为了表达系统的动态特征, 可以建立系统的动态模型。 类图(Class Diagram) , 描述系统的静态结构, 是用于表示不同的基础构件, 它们之间的相互关系以及它们属于哪个子系统, 类图包括属性、操作以及许多类型的角色和关联; 对象图(Object Diagram) , 描述系统在某个时刻的静态结构, 多用于具体示例的设计。对象处理个别的单独物, 而类处理的对象则更一般些。从前面的需求分析中，我们可以根据主要的五个类对象：学生类、系统管理员类、课程类、数据控制类和界面类创建完整的类图。 2.3创建系统动态模型 在系统的动态模型中有许多种不同的图, 包括序列图、协作图、状态图和活动图，我重点说的是其中的活动图，所以所列出的只有活动图。 2.3.1.学生选择课程的活动步骤。 (1)进入选择课程的界面 (2)选择需要的课程 (3)查询课程信息 (4)数据控制类判断课程可以被选择 (5)数据库执行选课并保存信息 (6)返回选课成功的信息 (7)在界面显示选课成功的信息 2.3.2.根据学生选课的活动步骤 ，我们可以创建的活动图。 活动图(Activity Diagram) , 描述了系统元素的活动, 分析用例中的行为, 并显示它们之间的交互作用。活动图描述一系列活动, 活动之间的顺序流动或分支流动, 常用于反映某个用例或操作执行的活动状况。它适用于工作流和并发的处理行为, 其主要任务描述并发活动和跨用例的协同任务, 2.4创建系统部署模型 2.4.1系统构件图 组件图(Component Diagram) , 描述了实现系统的元素的组织, 说明系统的组件之间如何交互, 显示源文件与类之间的依赖性以及它们属于哪个组件。 在网上选课系统中，我们可以对系统的主要参与者和主要的业务实体类分别创建对应的构件进行映射。我们前面在类图中创建Student类、SystemMananger类、Control类、Form类和Course类，所以可以映射出相同的这些构件，包括学生构件、系统管理员构件、业务逻辑构件、页面构件和课程构件。除此之外，我们必须有一个主程序构件。 2.4.2系统部署图 部署图(Deployment Diagram) , 描述了环境元素的配置, 并把实现系统的元素映射到配置上。 在网上选课系统中，系统包括四种节点，分别是：数据库节点，由一台数据库服务器负责数据的存储，处理等；系统服务器节点，用于处理系统的业务逻辑。客户端浏览器节点：用户通过客户端登录系统进行操作。打印机节点：用于打印数据报表。