系统分析与设计实习报告

上传人:博****1 文档编号:487963364 上传时间:2024-02-14 格式:DOC 页数:30 大小:1.14MB
返回 下载 相关 举报
系统分析与设计实习报告_第1页
第1页 / 共30页
系统分析与设计实习报告_第2页
第2页 / 共30页
系统分析与设计实习报告_第3页
第3页 / 共30页
系统分析与设计实习报告_第4页
第4页 / 共30页
系统分析与设计实习报告_第5页
第5页 / 共30页
点击查看更多>>
资源描述

《系统分析与设计实习报告》由会员分享,可在线阅读,更多相关《系统分析与设计实习报告(30页珍藏版)》请在金锄头文库上搜索。

1、信息系统分析与设计教学实习报告 题目:基于UML的班级管理系统建模 学生姓名 学 号 专业班级 信息管理与信息系统(2)班 成绩评定 学 期 2011-2012第一学期 2011年12月 II目 录1绪论11.1立题依据或研究背景及意义11.2教学实习结构安排12基于UML的班级管理系统建模22.1引言22.2应用UML建模22.2.1需求收集22.2.2系统分析32.2.3系统设计43结论与展望253.1教学实习工作总结253.2教学实习创新点253.3进一步的工作与展望25参考文献261 绪论在日常的班级管理中,涉及到很多事务,班级管理人员(班委)经常需要组织各种班级活动,发布考试信息,班

2、级上课考勤,及提交各种课程作业,及有事情需要通知某位同学等相当多的一些事务。在目前的高校班级管理中,班级管理人员(班委)需要花费相当大的时间和精力来完成这些事情,而且不停地重复着大量的工作,但在已有的软件中很难找到一个精简实用高效的班级管理系统。1.1 立题依据或研究背景及意义基于以上需求,我在查阅了班级管理相关资料并且咨询了班委以及辅导员后,选择开发基于WEB的高校班级管理系统。根据课程设计要求,本系统使用UML建模方法完成班级管理这一具体业务紧密结合的信息系统的分析与设计,使用SQLServer2005存储数据,开发平台采用常见的JSP技术,用JDBC实现数据库访问交互。1.2 教学实习结

3、构安排基于WEB的高校班级管理系统主要服务与高校各院系的日常班级信息管理中,通过学生档案管理、学生成绩管理、班级任务管理、班级组织管理、班级费用管理、学生考勤管理以及用户管理等几个功能模块,利用发展迅速的高校校园网实现各班级信息的集中管理、分散操作和信息共享,使班级管理数字化、无纸化、智能化,为高校的班级管理打造一个新的网络信息管理平台。2 基于UML的班级管理系统建模2.1 引言面向对象的分析与设计(OOA&OOD)方法的发展在20世纪80年代至90年代快速发展,UML是这个时代的产物。而且对其做了进一步发展,并最终统一为大众所接受的标准建模语言。UML的目标是以面向对象的方式来描述任何类型

4、的系统,其中最常见的是建立软件系统的模型,本文就建立班级管理系统体现UML的功能与应用。2.2 应用UML建模基于UML的系统软件建模实践过程遵循Rational统一过程(Rational Unified Process,RUP)的核心思想和基本原则,即以Use Case(用例)为驱动的、体系构架为核心的迭代化的面向对象分析和设计过程。所谓RUP是 Brooch等人在 Rational公司支持下提出的一种面向对象的软件开发过程模型。RUP将分析设计过程主要分为以下几个阶段:业务需求分析、系统体系架构设计、系统分析与设计以及系统实现阶段。各阶段的主要成果为需求模型、体系架构模型、分析与设计模型以

5、及实现模型。2.2.1 需求收集 根据当前班级管理的实际情况,以下是经过与班委和辅导员交流后发现的问题:班主任与学生之间信息传递效率低。班委们之间分工不明确,信息传递繁琐效率低。班委劳动强度较大且大量重复,班委会开的较多。学生信息不便于更新、查询和分析。班委们容易忘事,工作落实不到位。这些问题都不仅给班委们增加了很多麻烦,而且也不利于校园信息系统的升级和维护。所以我将根据高校班级管理系统的特殊需求,以不同的方式来改进传统管理,开发适当的信息系统以解决以上提到的问题,提高班级管理的效率。2.2.2 系统分析本系统的开发,在技术、经济、操作、社会等方面都是可行的。现在大多数班级的平时事务管理主要包

6、括学生的基本信息管理、班级同学上交作业的管理、同学上课情况的管理、班级同学的奖惩管理、班级日常事迹的管理。这些管理中全部都是属于信息系统管理的范围,不涉及到太多复杂的业务逻辑;开发此系统的方法没有太大困难的要求,开发所需的设备资源都是我们平时使用的个人电脑,所以不需要设备经费。因此,通过开发本系统来完善高校班级管理业务是切实可行的。本项目基本业务有:班委或辅导员在管理中要进行学生的基本信息管理,同时会记录学生日常的上课情况;班委在学生提交课程作业的时候也需要做相应的记录,以便统计学生课程作业的上交情况;班委应随时掌握班上学生的获奖情况和被惩罚的情况;班委或辅导员对日常的班级事情需要一个完整的记

7、录情况,以便随时查阅和检查班上还有哪些事情没有通知。因此当前业务的现状主要有学生档案管理、学生考勤管理、作业提交情况、学生奖惩管理、日常事务管理以及用户管理。(1)学生档案管理。该模块负责管理学生的个人档案信息,班委与老师可通过它来查阅和更新学生的个人信息。(2)学生考勤管理。该模块负责学生的考勤登记与管理,班委提交学生上课的考评,学生与老师可通过它来查阅考评情况。(3)作业提交情况。该模块用以登记班级的作业上交情况,学生可根据它提交作业以及查询作业提交情况。(4)学生奖惩管理。该模块负责记录班上学生的获奖情况和被惩罚的情况,班委通过它来添加、修改、删除学生奖惩记录,学生与老师可通过它来查阅奖

8、惩信息。(5)日常事务管理。该模块负责记录班上的日常事务活动以及班委的待办工作,班委可通过它添加、修改、删除班里的日常或待办工作,学生与老师可通过它来查阅班级活动,起到监督班委的工作的目的。2.2.3 系统设计2.2.3.1用例图(Use Case Diagram)用例图从用户(或外界系统)的角度描述用户与系统的交互。它可用来理解系统的功能并指出各功能的参与者。用例现已成为面向对象方法中捕获用户需求以及驱动开发过程的重要手段。用例图用来表达用例之间以及参与者和用例之间的关系。系统所有的用例(图)共同组成了系统的用例模型。构成用例图的元素有:1) 用例(Use Case):一个用例是一个系统或一

9、个类提供的紧凑的功能单元,它是由系统与一个或多个外部交互者(即参与者)之间交换的消息序列以及系统执行的活动共同体现的;2) 参与者(Actor):参与者是直接与系统交互的外部对象所扮演的角色;3) 用例图中的关系(Use Case Relationship):其包括如下四种关系:l 通信(Communicate):这是参与者与用例之间仅有的关系,是参与者对用例的参与;l 扩展(Extend):用例间的扩展关系描述了一般行为的变化。在用例A的执行过程中,可能会出现某些特殊情况,而一个用例一般只包含一条顺利执行的主线,不进行过多的逻辑判断而产生许多分支,这些特殊情况就可以被放到另一个用例B中处理。

10、类似编程语言中的异常处理;l 包含(Include):从用例A到用例B的包含关系表明用例A的实例也包括了在用例B中说明的行为,即用例A要使用用例B所提供的功能;l 泛化(Generalization):用例A到用例B的泛化,指的是用例A继承了用例B的特性并增加了新的特性。2.2.3.1 业务用例图通过以上分析,可得出实际参与该项目业务过程的业务主角有:班委、辅导员、学生,其中班委由学生扩展出来。同时,也可得出6个重要的业务用例:学生档案管理用例、学生考勤管理用例、作业提交情况用例、学生奖惩管理用例以及日常事务管理用例。其业务用例视图如下所示:2.2.3.2 系统用例图通过综合分析最终得出,在班

11、级管理系统最高层用例图中,系统边界内共有6个用例,系统边界外有3个参与者。系统内6个用例如下:(1)“学生档案管理”用例:用户通过它来查阅和更新学生的个人信息。(2)“学生考勤管理”用例:用户使用其记录学生考勤情况。(3)“作业提交情况”用例:用户根据它提交作业以及查询作业提交情况。(4)“学生奖惩管理”用例:用户通过它记录班上学生的获奖情况和被惩罚的情况。 (5)“日常事务管理”用例:用户使用其记录班上的日常事务活动以及班委的待办工作。(6)“用户管理”用例:辅导员使用其管理用户权限。2.2.3.2静态图(Static Diagram)静态图包括类图、对象图和包图;其中类图描述系统中类的静态

12、结构;对象图是类图的实例;包图由包或类组成,表示包与包之间的关系,包图用于描述系统的分层结构。1)类图(Class Diagram):类图用来描述系统中类与类之间的关系。它描述的是系统的静态结构。类用来表示系统中需要处理的事物或概念,有着相同结构、行为和关系的一组对象的描述符号。类由类名、属性和操作组成。类与类之间通过多种方式连接:l 关联(Association):表示类之间的关系。有二元关联和多元关联;l 聚集(Aggregation):表示类的对象之间整体和部分的关系;l 组合(Composition):更强的聚集关系,整体拥有部分,部分与整体共存亡,若整体不存在了,部分随之消失;l 依

13、赖(Dependency):有两个类(或包)X和Y,如果修改X会影响到Y,则称Y依赖于X;l 实现(Realization):接口由类来实现;l 泛化(Generalization或继承 Inheritance):表示元素之间的分类关系。类和类之间的关系通过类的内部结构(属性和操作)来实现。一个系统可以由多个类组成,一个类可以出现在多个类图中,一个类图并不需要表现系统所有的类。一般的,每个类图由关系密切的类组成。2)对象图(Object Diagram):对象图可看作类图的一个变形,它包括对象和数据的值,对象图实际上是类图的一个实例,它显示了在一个时间点上系统细节状态的一个快照。类图中也可以有

14、对象,一个有对象而没有类的类图便是一个“对象图”。对象与类的图形表示相似,不同之处是对象名有下划线。对象图用于表示复杂的类图的一个实例,基本上很少使用。3)包图(Package Diagram):包是用来对一个图的元素(如类和用例)进行分组。把分组后的元素用一个带标签的文件夹包围起来,就完成了对其打包。如果给包起一个名字,就命名了一个组,包为这组元素提供一个命名空间(Namespace),这组元素属于这个包。包也有泛化与依赖关系。通过以上对类的设计与规范,进一步明确了系统实体类的属性与操作,从而得到以下系统实体类图:2.2.3.3交互图(Interactive Diagram)交互图描述对象间

15、的交互关系。其包括顺序图与协作图(也称合作图)。顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;协作图描述对象间协作关系,显示对象间的动态合作关系。实质上,顺序图与协作图是等价的,一般情况下只需要其中之一即可。2.2.3.3 顺序图在UML的分析模型中,使用的MVC 模式,使用边界对象、控制对象、实体对象,这个三者来建立用例场景的对象模型。因此,回顾以上分析,仔细分析系统用例场景中的活动,以此发现和定义各个用例的对象,并得知对象间如何交互来实现用例的。本项目使用顺序图来描述个用例的对象交互;其中,由于查询功能模块是三个用户都可以进行,而且交互过程相同,故以班委为代表展示其过程的交互。

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 大杂烩/其它

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号