统一建模语言UML课程设计报告.docx
《统一建模语言UML课程设计报告.docx》由会员分享，可在线阅读，更多相关《统一建模语言UML课程设计报告.docx（22页珍藏版）》请在冰点文库上搜索。
统一建模语言UML课程设计报告
统一建模语言UML课程设计报告
姓名：
学号：
班级：
指导教师：
2015年6月
树人大学信息科技学院
系统UML设计报告要求：
●要求学生尽量设计出一个完整的UML模型，每一个学生根据自己的设计写出报告。
两个人完成一份，标出完成情况。
●设计报告容根据要求共分十五项，要求学生书写完整
●学生对要求作整体细化，最后达到能根据报告就可直接编写程序，不要再交流与具体分析
●对于设计报告中的图片都要有文字说明（让用户能明白其含义）
●要求150页以上
●图形要求保证在能看清的情况下最小化，表有表名与表号、图有图名与图号
●UML画图工具可选择Visio或Rose
●图片与文字应相互交差，只有图片的位置加入相应的文字说明图片容
UML建模设计报告
新生报到注册系统
一、系统需求分析
1.1系统功能需求
新生报到注册系统主要用于提高高校新生报到注册工作效率、提高数据准确性,及时统计有关数据信息,为各项相关管理和决策提供依据。
基于B/S模式的新生报到注册统计系统按其功能划分为教务处管理子系统、学生处管理子系统、后勤管理子系统、学院管理子系统、计财处管理子系统、用户管理系统、后台管理系统、学生查询模块等。
实现用户信息管理、新生基本信息的导入、报到交费、系统实时情况查询、报到数据表信息的生成等功能。
由于学校教职工按其职责不同，系统的权限不同，新生报到注册系统设置一个身份验证模块，对系统参与者进行身份识别。
（细化补全，最后完成所有红字删除）
1.2系统基本模块
新生报到注册系统共分教务管理、计财管理等十个模块，系统基本模块如图1.1所示：
系统基本模块
学生处管理
班主任管理
学院管理
教务管理
后勤宿舍管理
学生查询
计财管理
后台管理
图1.1系统基本模块
（1）后台管理模块：
招生信息导入（系统管理员可以招生信息）、修改学生基本信息：
（系统管理员可以修改更新学生基本信息）。
（2）后勤宿舍管理模块：
寝室资源管理、可用寝室资源分配、可回收寝室资源信、寝室信息查询、卫生检查。
（3）计财管理模块：
包括，从银行的数据导入、交费处理、交费标准设置、取消交费
（4）教务管理模块：
专业设置、班级设置、根据专业自动生成班级、自动分班、班级微调、班级查询、自动生成学号、学号查询、学号微调、要求设定同名同姓查询与其它的一些查询功能
（5）学院管理模块：
（补全）
（6）学生处管理模块：
对学生的入学信息的统一管理，如贷款处理、欠费处理等。
（7）班主任管理模块：
对学生的寝室的分配、特长等个性的处理
（8）学生查询模块
（细化补全）
二、系统用例建模
2.1识别参与者
创建用例图前需要确定参与者，新生报到注册系统的参与者可分为，教务管理员、学生管理员、后勤管理员、学院管理员、计财处人员、系统管理员、班主任、学生。
创建用例图必须明确每一个参与者就明确其业务活动的容、对系统的服务要求。
●教务管理员
教务管理员参与的主要用例有：
●学生处管理员
●后勤管理员
●学院管理员
●计财处人员
●系统管理员
●班主任
●学生
（细化补全）
2.2识别用例
2.2.1系统顶层用例
统顶层用例可分为后台管理，后勤宿舍管理，计财管理，教务管理，学院管理，学生处管理，班主任管理、学生查询系统。
2.2.2子用例
各顶层用例拥有各自的子用例
●后勤宿舍管理用例
后勤宿舍管理分为寝室资源管理、可用寝室资源分配、可回收寝室资源信息、寝室信息查询、卫生检查、相关信息的打印输出与倒出等用例。
●计财管理
（细化补全）
2.2.3建立系统用例文档
1、后勤宿舍管理模块用例图
后勤宿舍管理模块包括****等用例，具体如图2.2所示：
图2.2后勤宿舍管理用例图
这里列出寝室资源管理这个用例的描述。
（要求学生写完所有的用例，最后完成所有红字删除）：
（1）寝室资源管理用例
表2.1寝室资源管理用例描述
用例名称：
寝室资源管理
用例标识号：
203
参与者：
后勤管理员、系统管理员
简要说明：
后勤管理员实现对寝室资源的管理。
寝室资源包括园区号、园区名、楼号、楼名、寝室号、寝室人数、可用否、是否为新公寓、sex、寝室朝向、收费标准、寝室。
功能：
增、删、改、查、自动分批生成。
前置条件：
管理员必须先登入。
基本事件流：
1．后勤管理员鼠标点击“寝室资源”菜单
2．系统出现一个界面，显示着原来的寝室资源信息（如新增则为空）
3．后勤管理员可在窗口修改寝室资源信息，也可以增加或删除信息
4．后勤管理员编辑完信息，按“提交”按钮，寝室资源信息被修改
5．用例终止
其他事件流A1：
在按“提交”按钮之前，后勤管理员随时可以按“返回”按钮，文本框的任何修改容都不会影响数据库信息
异常事件流：
1．提示错误信息，后勤管理员确认
2．操作完成返回到后勤管理系统主页面
后置条件：
寝室资源信息被修改
注释：
无
寝室资源管理相关的活动图如下:
用户界面参见*****。
a）学生寝室添加的活动图
b）学生寝室修改的活动图
c）学生寝室查询的活动图
d）学生寝室自动分批生成的活动图
学生寝室自动分批生成用户界面参见图3.2,,活动图如下：
（要求写出具体的算法，最后完成所有红字删除）
2、后台管理（由×××完成）
3、后勤宿舍管理（由×××完成）
4、计财管理
（说明与银行接口的实现方法，与3.3节对应）
5、教务管理
6、学院管理
7、学生处管理
8、班主任管理
9、学生查询系统
（细化补全，最后完成所有红字删除）
10、权限分配
三、在net环境或MyEclips环境下建立系统结构
在.net环境或MyEclips环境下建立系统的用户界面。
以.net环境为例。
3.1建立系统的项目
（说明及截图）
3.2建立系统目录
（要求建立合理，后面建立系统包图要用）
3.3建立银行的WebService服务，供系统调用
（只要求接口，不要求完整的程序）
3.4建立图形用户界面
（可用Dreamwear等工具，用户界面在需求分析中用到）。
应用系统通过用户界面与用户交互的，用户界面已成为所有计算机系统的有机组成部分，它决定了人类如何控制和操纵系统。
一个好的用户界面应该为用户提供统一、规的交互界面，从而提高用户工作效率，增强用户对系统的认可程度。
因此可以说，用户界面设计的优劣已经成为计算机应用系统成功与否的关键因素之一。
用户界面设计应从系统开发、设计的实际出发，用户界面设计包括窗体布局、界面配色、控件风格、字体、交互信息等。
用户界面的设计，无论是控件、信息提示措辞、界面配色等，都要遵循统一的标准，做到真正的一致。
（要求设计主要的用户界面，说明要完整）
1、专业收费标准设置用户界面（ProfessionalCharge）
（注：
ProfessionalCharges为文件名）
图3.1专业收费标准设置界面
（2）页面项目说明
编号文本框：
text，名称TNo，要求合法性，数字，不能为空
保险费：
text,名称InsurancePremium，要求合法性：
数字，不能为空
学费：
text,名称TuitionFees，要求合法性：
数字，不能为空
后勤代管费：
text,名称OgisticsEscrowFee，要求合法性：
数字，不能为空
书费：
text,名称BookFees，要求合法性：
数字，不能为空
住宿费：
text,名称accommodation，要求合法性：
数字，不能为空
应交合计：
text，名称TotalPayable，要求自动计算，供参考
（3）功能
将专业收费标准信息存入数据表（professionalcharges）。
作为学生收费的一个标准，学生收费依据专业自动出现该信息。
2、学生寝室自动分批生成
（1）学生寝室自动分批生成（DormitoryBatch）
图3.2学生寝室自动分批生成界面
（细化补全）
四、活动建模
为了更好地理解用例，可用活动图来加以说明，新生报到注册活动中引用活动图的描述目的为：
描述一个操作执行过程中（操作实现的实例化）所完成的工作（动作）；描述对象部的工作；显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象；显示用例的实例是如何执行动作以及如何改变对象状态；说明一次活动中的工作者（角色）、工作流、组织和对象是如何工作的。
新生报到注册系统主要的活动图有：
学生基本信息管理、….等。
（补全，这时的为全局用的活动图，各部分的在活动图在用例图中说明）
4.1创建“学生基本信息管理”活动图
学生基本信息管理由特权用户管理操作，管理员用户录入后，可修改学生基本信息，删除学生基本信息（转出学生），增加学生基本信息（转入学生）、操作完成退出系统，具体如图4.1所示：
图4.1：
“学生基本信息管理”活动图
（细化补全）
五、静态结构建模
类图是在面向对象的系统模型中使用得最普遍的图。
类图包含了一组类、接口和协作以及他们之间的关系。
使用类图来为系统的静态视图建模，包括模型化系统的词汇（从系统的词汇表中发现类），模型化协作，或则模型化模式。
类图还是一些相关的图的基础，包括组件图、分布图。
类图的重要性不仅仅体现在为系统建立可视化的、文档化的结构模型，同样重要的是构建通过正向和反向工程建立执行系统。
类图是一组类、接口和协作以及他们之间的关系构成的。
类图通常包含如下的容：
●类
●接口
●协作
●依赖关系、继承关系、关联关系
同其他的图一样，类图也可以包含注解和限制。
5.1定义系统实体类
新生报到注册系统主要涉及后台管理、后勤宿舍管理、计财管理、教务管理、学院管理、学生处管理模、班主任管理、学生查询等模块。
后勤宿舍管理主要的类有：
寝室资源管理、可用寝室资源分配、可回收寝室资源、寝室信息查询、卫生检查等。
…….
5.2定义类属性
1、寝室基本信息管理
寝室基本信息管理主要的属性有：
园区号、园区名、楼号、楼名、寝室号、寝室人数、可用否、是否为新公寓、sex、寝室朝向、收费标准、寝室。
（细化补全）…..
5.3确定类间关系
定义了类之后，接下去必须建立类间关联，类与类之间存在的关系有:
（1）泛化（Generalization）
（2）关联（Association） （3）依赖（Dependency） （4）聚合（Aggregation）。
（1）泛化
泛化关系的类有：
（2）关联
（3）依赖
（4）聚合
5.4确定类之间的关系并建立类图
（类图可正向或逆向生成，C#的逆向工程只能由Visio完成）
1、系统相关类
（1）数据库连接相关类
ConnectDB类建立在NewStudentReg..db包下（包图参见十系统包图）
（2）系统操作公共类
2、用户信息相关类
（1）用户持久信息类
（2）用户信息相关类
用户信息操作涉及用户界面（），用户用户操作（UserInfor）、用户持久类（User）三个类，从ConnectDB类获取一个连接，…..具体类图如下：
（相关的类放在一起,在此说明（如PublicClass）,相关的类可在多个类图中出现，如PublicClass等）
图4.1：
用户信息相关类图
3、用户信息相关类
1）学生类（Student）
一个表示学生信息的类Student,它有四个私有整型变量学生（Student）、学号（studentNo）、班级（Class）、和编号（No）；定义一个有**个参数的公有构造函数，定义一个能显示学生信息的公有函数Show（），……；
班级类（ClassName）
（细化补全）
六、在net环境或MyEclips环境下建立类
（说明：
系统结构与（三）相对应）
新生报到注册系统开发环境为MyEclips，采用Java语言开发，采用三层架构的开发模式。
6.1建立类
（说明：
可利用反向工程建立，必须与（五）的静态类型对应，用截图表示。
）
1、公共类（PublicClass）
图6.2公共类（PublicClass）详细信息
2、用户信息类（user）
用户信息类（user）包括用户名vsername，登录名lgname，登录密码passwd;User作为单独的实体对象，它仅仅是数据的载体，不包括业务逻辑方法（如果是JavaBean对象）。
以lgname作为惟一的对象来标识，以使程序能区别不同的对象。
具体结构如下：
图6.1用户信息类（user）详细信息
（细化补全）
6.2建立类相关的包
（这里的包用截图形式，最后完成所有红字删除）
七、数据库设计
ER建模本身定义了在基于信息的系统的分析和设计中用到的方法。
数据库设计者通常使用该方法来收集需求，并定义数据库系统的构架。
该方法的输出是实体类型、关系类型和约束条件的清单。
统一建模语言（UML）是一种分析人员和软件开发人员广泛使用的语言，特别适合ER图的图形化表示。
通过使用UML应用建模和数据建模的普遍使用，从分析到实施再到部署的统一表示，以及规格说明书的完整性。
（细化补全）
根据ER建模在SQLServer下建立数据库，（写出完整的表信息）
新生报到注册系统数据表如下：
1、学生基本信息表（StudentBase）
学生基本信息表为新生报到注册系统的基础，具体数据可在报到前同（高校招生系统修倒入），主要包括学生,学号,班级,专业等信息，具体如表7.1所示：
…..
表7.1学生基本信息表（StudentBase）
序号
字段名
类型
中文说明
备注
1
name
Vchar（30）
学生
2
No
Vchar（20）
学号
Key
3
ClassNo
Vchar（40）
班级
4
Specially
Vchar（50）
专业
八、顺序图建模
UML顺序图是一种动态建模方法,一般用于确认和丰富一个使用情境的逻辑。
一个使用情境就是系统潜在的使用方式的描述，也就是它的名称所要描述的。
一个使用情境的逻辑可能是一个用例的一部分，或是一条备选线路；一个贯穿单个用例的完整流程，例如动作基本过程的逻辑描述，或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述。
或是包含在几个用例中的流程。
新生报到注册系统涉及到多个工作顺序，但并不是每个用例都需要画顺序图，只有比较重要的、复杂的对系统有很大影响的用例（核心用例）才画顺序图。
8.1后勤管理登入顺序图
后勤管理登入顺序图如图5.1所示：
图5.1：
后勤管理登入顺序图
【后勤管理登入顺序图说明】
登录：
用户进行登录
成功则可以进行相应的各种操作（寝室资源管理），失败则退出系统。
●新生报到顺序图
新生报到顺序图如图5.2所示：
图5.2新生报到顺序图
●寝室分配顺序图
（细化补全）
九、状态图建模
状态图（StatechartDiagram）是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。
通常我们创建一个UML状态图是为了以下的研究目的：
研究类、角色、子系统、或组件的复杂行为。
状态图用于显示状态机（它指定对象所在的状态序列）、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。
9.1新生交费状态图
9.2床上用品领用状态图
主要包括交费、领用、确认三个环节
十、系统组件包设计
UML用例图可将相关联的用例放在一起，组织为包图。
包含用例、扩展用例以及继承的用例，都要和其对应的基或父用例放在同一个包中。
在用例包图中包含参与者有助于将包放在对应的上下文中，便于理解。
可按照主要参与者的需要组织用例。
如新生报到注册系统用例包图（根据系统布局要求修改）。
图10.1新生报到注册系统用例包图
（细化补全）
十一、协作设计
协作图在很多方面都与顺序图相同。
二者都用来记录对象的交互方式。
但是，顺序图基于时间，而协作图显示对象及相应关联，不强调时间。
协作图显示实现交互的消息序列。
二者的区别仅在于此，因此，顺序图的相关容也适用于协作图。
这两类图仅是表达事物的两种不同方式。
协作图用来查看系统的动态容。
因为协作图中的消息不强调时间，所以要编号，以便了解它们的出现顺序。
协作图包含三个基本元素：
●对象
●（对象之间）
●消息
（1）学生寝室分配协作图
图8.1学生寝室分配协作图
贷款申请协作图
学生申请—班主任批准—学院批准-学校领导批准这一过程，具体如下图：
（细化补全）
十二、建立物理模型
12.1系统的组件图
新生报到注册系统的组件图主要有：
业务对象组件图和用户界面组件图
●业务对象组件图
系统建立在一个含有学生基本信息（Student）、寝室信息（bedchamber）、学生交费信息（Tuitionfee）、交费标准信息（Feestandard）和班级设置（Class）、专业信息（speciality）、学生班级分配信息（Classsplit）的中央数据库上。
（只给出部分）
图8.1业务对象组件图
●用户界面组件图
除了业务对象以外，系统与用户交互的部件也能创建一个组件图。
（只给出部分）
图8.2用户界面组件图
●系统组件图
系统组件图如图8.3所示。
图8.3系统组件图
12.2系统的配置图
配置图主要是用来说明如何配置系统的软件和硬件。
系统硬件由3节点构成，应用服务器负责整个系统的总体协调工作；数据库负责数据管理；Web应用程序模块用于信息处理；
涉及业务操作模块等多个模块：
业务操作模块用于处理报到、分班等一般的业务流程；信息维护模块用于系统管理员维护整个系统的数据信息，如添加和修改学生信息、添加和修改专业、班级等。
系统使用涉及节点主要有：
10个学院、各班班主任。
（画出配置图）
（细化补全）
十三、系统实施情况和升级
（要求与十一、十二对应）
新生报到注册系统在B/S模式下，以ASP.NET2010作为开发工具，数据库采用SQLServer2005。
ASP.NET2010
SQLServer2005
C#
部署
十四、系统测试方案
（根据软件测试课程要求完成，要求手工测试及选择一种自动化测试工具，并写出相应的测试用例）
十五、总结
升级会员 