岗位技能实训指导书模板.docx

岗位技能实训指导书

108

资料内容仅供参考，如有不当或者侵权，请联系本人改正或者删除。

岗 位 技 能 实 训( UML) 指 导 书

( 使用班级: 140401-03班)

姚庆安 吕寻才 唐培丽

6月1日

前言

UML面向对象系统分析与设计课程是计算机科学与技术本科专业的一门重要的专业课。经过本课程的学习, 使学生在已有的计算机软、 硬件基础知识, 程序设计知识, 数据库和网络通信知识的基础上系统掌握面向对象系统分析与设计的基本方法和技术, 并具有针对特定环境下的应用问题进行信息系统开发(包括系统分析, 设计与实现)的能力。经过学习本课程学生能够理解和掌握面向对象系统的分析和设计的方法和分步过程、 掌握面向对象系统分析和设计的建模标准UML语言, 能够利用Rational Rose( 或Microsoft Viso) 软件以某一信息系统为例进行系统分析和设计。
本课程主要介绍系统原理的基本概念、 系统开发过程RUP、 对面向对象分析和面向对象设计的方法、 对面向对象分析和设计的建模标准UML等内容。
经过本课程的学习, 学生掌握的知识、 内容及掌握的程度要求为:
1. 使学生理解面向对象的信息系统的开发过程、 系统分析和设计的原则和方法;
2. 使学生掌握UML语言的基础知识, 以及UML在面向对象的软件系统分析和设计中的应用, 并能使用UML工具建立系统模型;
3. 使学生掌握在UML系统模型下应用高级语言建立应用系统的方法;
4. 经过案例教学和实验, 提高学生在应用面向对象技术开发软件方面的动手能力和解决问题的能力, 并鼓励创新。
本实验所要求的建模工具为Rational Rose 。
本课程经过对CCUT图书馆系统进行建模设计开发。

目录

第一部分 实训计划及要求 1
第一章 实训计划 1
第二章 时间地点安排 8
第三章 撰写实训报告 9
第二部分 UML基础知识 10
第三部分 设计实例 24
设计一 用例图及进度安排 24
设计二 活动图 29
设计三 状态图 37
设计四 类 43
设计五 类的关系 50
设计六 交互图 54
设计七 对象图和包 62
设计八 组件图和部署图 64
设计九 正向工程 71

第一部分 实训计划及要求
第一章 实训计划
Ø 实训日期: .06.27- .07.01
Ø 实训目的、 要求及实训方式:
一. 实训目的
1、 为了培养学生自我再学习的意识和能力, 设计中采用没有学过的统一建模语言UML, 训练学生学习的能力。
2、 理论和实践相结合, 综合运用程序设计知识、 数据结构知识、 面向对象等知识, 提高综合实践的能力。
3、 在每个设计题目中, 除了必须完成的功能外, 都留有自由发挥的空间, 以体现软件设计的艺术性和创造性, 培养对软件设计较好的鉴赏力风格。
4、 训练实训报告或论文的书写能力。
5、 加强基本工具软件的使用能力。
6、 为后续课程的学习奠定良好的基础。
二. 实训要求
1、 要求学生在实训期间积极思考, 勇于创新, 努力将学过的多个知识点转变为实践能力,
2、 严格遵守实训纪律, 不缺勤, 不迟到, 不早退, 不许玩游戏。
3、 设计要求每人一组, 独立完成。
4、 注意设计作品的数量和质量, 撰写实训报告。
三. 实训方式
每天提供六个小时的上机时间, 用于程序实现; 其它时间用于完成软件设计, 同时有教师辅导答疑。
Ø 拟订题目:
题目一: 银行信息系统
l 需求分析:
银行是与人们生活密切相关的一个机构, 银行能够提供存款、 取款、 转账等业务。在银行设立账户的人或机构被称为银行的客户( customer) 。一个客户能够在银行开设多个账户( account) , 客户能够存钱到账户中, 也能够从自己的账户中取钱, 还能够将存款从一个账户转到另一个账户。另外, 客户能够随时查询自己的账户情况, 以及查询以前所进行的存款、 取款等交易记录。客户还有权利要求关闭自己的账户。
实际生活中的银行功能其实还要复杂得多, 但为了简化系统, 本次设计只考虑银行的基本功能。简化版的银行信息系统至少应具有如下功能:
（1） 一个银行能够有多个账户;
（2） 一个银行能够有多个客户;
（3） 一个客户能够持有多个账户;
（4） 一个账户能够有多个持有者;
（5） 银行能够为客户开设账户;
（6） 银行能够为客户注销账户;
（7） 客户能够从自己账户中取钱;
（8） 客户能够向自己账户中存钱;
（9） 客户能够在同一银行的不同账户之间转账;
（10） 客户能够在不同银行的不同账户之间转账;
请完成登录、 存款、 取款、 转账和查询几个模块的设计。
l 工作内容及要求
请在一周内完成下列工作内容:
（1） 进一步细化需求分析的内容, 识别出系统的参与者, 并完成用例图;
（2） 将用例图中的每个用例都写成相应的事件流文档;
（3） 进一步使用活动图来描述每个用例, 为后续的系统设计做好准备;
（4） 按照系统的功能分析, 从用例的描述中提取出系统的对象类和界面类, 建立类图;
（5） 分析类图中的实体类和实体类之间的关系, 画出数据库的逻辑模型图( 只包含实体类, 且注明角色和阶元) 。
（6） 对数据库的逻辑模型进行优化, 取消多对多的联系, 完成最终的逻辑模型设计;
（7） 使用交互作用图或状态机图完成系统动态行为的建模。( 建议使用顺序图按功能分别描述) 。
l 提交结果及要求
（1） 请提交用例图( 包括事件流文档) 、 活动图、 类图、 交互作用图。
（2） 可选提交: 状态机图、 系统部署图
（3） 完成规定格式的实验报告( 纸质) , 上交电子版实验报告和系统建模的成果( 各类图和相关文档, 电子文档) 。

题目二: 某企业的销售管理信息系统
l 需求分析:
假设某大型企业需要一个销售管理信息系统, 来完成合同信息等销售信息的自动化管理, 一般来说, 一个常见的销售管理系统的功能应包括收集大客户的基本情况、 制定产品销售计划、 推销本企业的产品、 与客户签订销售合同、 检查客户付款单并催缴客户拖欠的应付货款、 核对检验并发送货物、 核查客户订购的产品、 提请生产调度部门组织生产仓库中缺少的产品, 检查销售合同履行率、 提供售后服务等。现做一定的简化与合并, 得到系统的分解结构如下:
销售管理信息系统包括以下几部分:
（1） 大客户管理
为大宗采购本企业产品的大客户建立数据库
（2） 销售计划管理
根据企业生产能力核对当前市场行情的预期制定全年销售计划。
（3） 销售合同管理
( 设计重点) 添加、 修改、 查询销售合同, 核对收款单并发送货物, 检查收条, 催缴欠款, 核算销售合同履约率, 将履约合同转入历年履约合同库; 编制年综合统计报表。
l 工作内容及要求
请在一周内完成下列工作内容:
（1） 进一步细化需求分析的内容, 识别出系统的参与者, 并完成用例图;
（2） 将用例图中的每个用例都写成相应的事件流文档;
（3） 进一步使用活动图来描述每个用例, 为后续的系统设计做好准备;
（4） 按照系统的功能分析, 从用例的描述中提取出系统的对象类和界面类, 建立类图;
（5） 分析类图中的实体类和实体类之间的关系, 画出数据库的逻辑模型图( 只包含实体类, 且注明角色和阶元) 。
（6） 对数据库的逻辑模型进行优化, 取消多对多的联系, 完成最终的逻辑模型设计;
（7） 使用交互作用图或状态机图完成系统动态行为的建模。( 建议使用顺序图按功能分别描述) 。
l 提交结果及要求
（1） 请提交用例图( 包括事件流文档) 、 类图、 活动图、 交互作用图。
（2） 可选提交: 包图、 状态机图、 系统部署图
（3） 完成规定格式的实验报告( 纸质) , 上交电子版实验报告和系统建模的成果( 各类图和相关文档, 电子文档) 。
题目三: 汽车租赁系统分析与设计
l 需求分析
系统的整体目标是: 利用互联网和信息化技术, 结合汽车租赁经营的实际运作情况, 建设一个覆盖汽车租赁经营全部业务的”汽车租赁系统”。
功能需求: ”汽车租赁系统”中的功能需求能够包括以下几个方面:
（1） 客户能够经过不同的方式( 包括电话、 前台、 网上) 预订车辆;
（2） 能够保存客户的预订申请单;
（3） 能够保存客户的历史记录;
（4） 工作人员能够处理客户申请;
（5） 技术人员能够保存对车辆检修的结果。
满足上述需求的系统主要包括以下几个模块:
（1） 基本数据维护模块: 该模块提供了使用者录入、 修改并维护基本数据的途径。
（2） 基本业务模块: 在系统中, 客户能够填写汽车租赁申请表, 工作人员处理这些表格; 同时, 技术人员还能够提交每辆车的状态, 以便工作人员根据这些资料决定是否批准客户的请求。
（3） 数据库管理模块: 在系统中, 对所有客户、 工作人员以及车辆的信息都要进行统一管理, 车辆的租赁情况也要进行详细的登记。
（4） 信息查询模块: 该模块主要用于查询相关信息。
l 工作内容及要求
请在一周内完成下列工作内容:
（1） 进一步细化需求分析的内容, 识别出系统的参与者, 并完成用例图;
（2） 将用例图中的每个用例都写成相应的事件流文档;
（3） 进一步使用活动图来描述每个用例, 为后续的系统设计做好准备;
（4） 按照系统的功能分析, 从用例的描述中提取出系统的对象类和界面类, 建立类图;
（5） 分析类图中的实体类和实体类之间的关系, 画出数据库的逻辑模型图( 只包含实体类, 且注明角色和阶元) 。
（6） 对数据库的逻辑模型进行优化, 取消多对多的联系, 完成最终的逻辑模型设计;
（7） 使用交互作用图或状态机图完成系统动态行为的建模。( 建议使用顺序图按功能分别描述) 。
l 提交结果及要求
（1） 请提交用例图( 包括事件流文档) 、 类图、 活动图、 交互作用图。
（2） 可选提交: 包图、 状态机图、 系统部署图
（3） 完成规定格式的实验报告( 纸质) , 上交电子版实验报告和系统建模的成果( 各类图和相关文档, 电子文档) 。

题目四: 酒店预订系统
l 需求分析
基本业务流程:
顾客预约: 记录,取消,修改,查询和显示
顾客到达: 有预约顾客和无预约顾客相分离;
用餐顾客结帐: 同时刷新餐桌和预约信息
显示: 显示当前桌子的状态
完成以下模块:
( 1) 预约模块
Ø 显示预约: 显示当天所有预约,同时桌子根据当前时间显示当前状态
Ø 添加预约: 添加一个新的预约,并插入数据库,如果是当天预约则显示在预约状态栏中
Ø 修改预约: 修改一个已有的预约,能够修改订餐人数,预约日期,时间以及餐桌
Ø 删除预约: 删除一个已有预约,删除数据库信息,如果是当天预约则刷新预约状态栏
Ø 查询预约: 根据订餐人姓名,餐桌号,预约日期,时间查询预约状态
( 2) 到达模块
Ø 到达情况有两种,一种是有预约的到达,另一种是无预约的到达
Ø 有预约的到达首先要查询预约,故在预约模块中添加到达的功能
Ø 无预约的到达,就能够立即找空桌子用餐
在到达操作中还要刷新当前桌子状态,由预约或空闲状态转为用餐状态
( 3) 结帐模块
Ø 显示当前正在用餐的桌子信息,从中选中需要结帐的桌子,进行结帐操作
Ø 结帐完成后,将桌子置为空闲状态,若当天还有不同时间预约此桌子的则置该桌为预约状态
l 工作内容及要求
请在一周内完成下列工作内容:
（1） 进一步细化需求分析的内容, 识别出系统的参与者, 并完成用例图;
（2） 将用例图中的每个用例都写成相应的事件流文档;
（3） 进一步使用活动图来描述每个用例, 为后续的系统设计做好准备;
（4） 按照系统的功能分析, 从用例的描述中提取出系统的对象类和界面类, 建立类图;
（5） 分析类图中的实体类和实体类之间的关系, 画出数据库的逻辑模型图( 只包含实体类, 且注明角色和阶元) 。
（6） 对数据库的逻辑模型进行优化, 取消多对多的联系, 完成最终的逻辑模型设计;
（7） 使用交互作用图或状态机图完成系统动态行为的建模。( 建议使用顺序图按功能分别描述) 。
l 提交结果及要求
（1） 请提交用例图( 包括事件流文档) 、 类图、 活动图、 交互作用图。
（2） 可选提交: 包图、 状态机图、 系统部署图
（3） 完成规定格式的实验报告( 纸质) , 上交电子版实验报告和系统建模的成果( 各类图和相关文档, 电子文档) 。

题目五: 工资管理系统
l 需求分析
基本业务流程:
一个公司由若干部门构成, 每个部门经销若干种产品, 并有若干名职员和经理。工资由基本工资、 产品销售业绩奖 、 若干种保险的扣除等组成。其中的销售业绩奖按如下规定: 职员按其完成额的5%提成, 经理按该部门完成额的1%提成。每个月生成一个工资表, 每年末再按个人的总销售额发放1%的奖金。
系统的功能需求 :
在一个公司中, 工资管理系统是非常重要的, 开发者要尽力做到清晰、 准确、 公正。 经过向有关部门了解, 对公司工资管理系统的需求可得到如下描述:
( 1) 公司的会计负责记录各个部门、 各个职员的详细销售信息;
( 2) 公司的会计根据当月的销售信息, 按一定的规则计算各个职员的月工资;
( 3) 在年终的时候, 公司的会计还负责计算各个职员的奖金情况;
( 4) 公司的每个职员有权利知道自己工资的全部信息, 即她们能够查看自己工资的详细信息;
( 5) 如果发现工资有错误的地方, 公司的职员有权利向会计反应;
( 6) 会计根据反应的错误信息进行核查, 并做出相应的处理。
l 工作内容及要求
请在一周内完成下列工作内容:
（1） 进一步细化需求分析的内容, 识别出系统的参与者, 并完成用例图;
（2） 将用例图中的每个用例都写成相应的事件流文档;
（3） 进一步使用活动图来描述每个用例, 为后续的系统设计做好准备;
（4） 按照系统的功能分析, 从用例的描述中提取出系统的对象类和界面类, 建立类图;
（5） 分析类图中的实体类和实体类之间的关系, 画出数据库的逻辑模型图( 只包含实体类, 且注明角色和阶元) 。
（6） 对数据库的逻辑模型进行优化, 取消多对多的联系, 完成最终的逻辑模型设计;
（7） 使用交互作用图或状态机图完成系统动态行为的建模。( 建议使用顺序图按功能分别描述) 。
l 提交结果及要求
（1） 请提交用例图( 包括事件流文档) 、 类图、 活动图、 交互作用图。
（2） 可选提交: 包图、 状态机图、 系统部署图
（3） 完成规定格式的设计报告( 纸质) , 上交电子版实验报告和系统建模的成果( 各类图和相关文档, 电子文档) 。

其它: 题目能够结合自己所学过的课程中内容自定。

第二章 时间地点安排
17周上机实验安排
星期
时间
班级
试验室
指导教师
星期一
至
星期五
上午: 8:30-11:30
下午: 13:00-16:00
140401
140402
140403
652
654
646
姚庆安
吕寻才
唐培丽

第三章 撰写实训报告
实训报告的书写格式:
封皮写明班级、 姓名、 指导教师。
内容提要
目录
正文
题目
时间
用例图及进度安排
活动图
状态图
类
类的关系
交互图
对象图和包
组件图和部署图
正向工程
参考资料
实训总结报告

第二部分 UML基础知识
UML简介
在80年代末至90年代中, 对面向对象分析与设计方法的研究发展到一个高潮。可是, 诸多流派在思想和术语上有很多不同的提法, 在术语、 概念上的运用也各不相同, 需要一种统一的符号来描述面向对象的分析和设计活动。UML应运而生。它不但统一了Booch、 Rumbaugh和Jacobson的表示方法, 而且有进一步的发展, 最终成为大众所共同接受的标准建模语言。统一建模语言( UML) 是一个通用的可视化建模语言, 用于对软件进行描述、 可视化处理、 构造和建立软件系统制品的文档。它记录了对必须构造的系统的决定和理解, 可用于对系统的理解、 设计、 浏览、 配置、 维护和信息控制。UML适用于各种软件开发方法、 软件生命周期的各个阶段、 各种应用领域以及各种开发工具, UML 是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模方法。它融入了软件工程领域的新思想、 新方法和新技术。不但支持面向对象的分析与设计, 还支持从需求分析开始的软件开发全过程。
UML模型、 视图、 图
UML的概念和模型能够分成以下几个概念域: 静态结构、 动态行为、 实现构造、 模型组织、 扩展机制
UML视图和图
主要的域
视图
图
主要概念
静
态
结
构
静态视图
类图
类、 关联、 泛化、 依赖关系、 实现、 接口
用例视图
用例图
用例、 参与者、 关联、 扩展、 包括、 用例泛化
实现视图
构件图
构件、 接口、 依赖关系、 实现
部署视图
部署图
节点、 构件、 依赖关系、 位置
动
态
状态视图
状态图
状态、 事件、 转换、 动作、
行
活动视图
活动图
状态、 活动、 完成转换、 分叉、 结合
为
交互视图
顺序图
交互、 对象、 消息、 激活

协作图
协作、 交互、 协作角色、 消息
模型管理
模型管理视图
类图
包、 子系统、 模型
扩展机制
所有
所有
约束、 构造型、 标记值

静态视图
1、   类元
类元是模型中的离散概念, 拥有身份、 状态、 行为和关系。有几种类元包括类、 接口和数据类型。其它几种类元是行为概念、 环境事物、 执行结构的具体化。这些类元中包括用例、 参与者、 构件、 节点和子系统。图列出了几种类元和它们的功能。元模型术语类元中包括了所有这些概念。

类元
功能
表示法
参与者
系统的外部用户

类
类代表了被建模的应用领域中的离散概念。
最重要的特性是多重性

状态类
局限于某个给定状态的类

类元角色
在合作中局限于某个使用的类元

构件
系统的一个物理组成单元

接口
刻划行为特征的操作命名集.

节点
计算资源

信号
对象间的异步通信

子系统
作为且有规范、 实现和身份的单元的包

用例
与外界代理交互中的实体行为说明

2、 类元之间关系
类元之间的关系有关联、 泛化、 各种形式的依赖关系, 包括实现关系和使用关系。

关联: 对象一般要和其它对象发生关联, 关联能够具有多层形式。多重性问题( 一对一、 一对多) 。在UML中关联用一条直线来表示。
泛化: 一个类继承了其它类的属性和操作。在UML中泛化用”从之类画一条带空心三角形箭头的连线指向父类”来表示。
依赖: 一个类使用了另一个类。在UML中依赖用”从依赖类到被依赖的带箭头的虚线”表示。
聚集是关联的一种, 聚集对象由部分对象组成。也就是整体与部分关联。在UML中用”整体和部分之间用带空心菱形箭头的连线连接”来表示。
组合是一种特殊的聚集, 在一个组合对象中, 部分对象只能作为组合对象的一部分与组合对象同时存在。在UML中用”整体和部分之间用带实心菱形箭头的连线连接”来表示。
实现: 类和接口之间的关系被称为实现。在UML中实现关系用一个带空心三角形箭头加虚线来表示, 箭头指向接口。
关系的种类
关系
功能
表示法
关联
类实例之间连接的描述

依赖
两个模型元素间的关系

泛化
更概括的描述和更具体的种类间的关系, 适用于继承

实现
说明和实现间的关系

聚集
聚集对象由部分对象组成。也就是整体与部分关联。

组合
一种特殊的聚集.

图举例:

关联

依赖

限定关联

聚集和组成

泛化

实现关系

用例视图
当用例视图在外部用户前出现时, 它捕获到系统、 子系统或类的行为。它将系统功能划分成对参与者(即系统的理想用户)有用的需求。而交互功能部分被称作用例。用例使用系统与一个或多个参与者之间的一系列消息来描述系统中的交互作用。参与者能够是人,也能够是外部计算机系统和外部进程。
用例之间的关系: 关联、 扩展、 泛化、 包含。
关系
功能
表示法
关联
参与者与其参与执行的用例之间的通信途径

扩展
在基础用例上插入基础用例不能说明的扩展部分

泛化
用例之间的一般和特殊关系, 其中特殊用例继承了一般用例的特性并增加了新的特性

包含
在基础用例上插入附加的行为, 而且具有明确的描述

图举例:

用例图

用例关系图

交互视图
交互视图描述了执行系统功能的各个角色之间相互传递消息的顺序关系。类元是对在系统内交互关系中起特定作用的一个对象的描述, 这使它区别于同类的其它对象。交互视图显示了跨越多个对象的系统控制流程。交互视图可用两种图来表示: 顺序图和协作图, 它们各有不同的侧重点。协作图也展示对象之间的交互关系, 强调交互的语境和参与交互的对象的整体组织。协作图按照空间组织布图, 而顺序图按照时间顺序布图。

顺序图

协作图
状态视图
状态视图是一个类对象所可能经历的所有历程的模型图。状态图由对象的各个状态和连接这些状态的转换组成。状态图是对单个对象的”放大”, 它说明对象所经历的状态变化。强调单个对象内状态的变化。

状态图
活动视图
活动图是状态图的一个变体, 用来描述执行算法的工作流程中涉及的活动。活动状态代表了一个活动: 一个工作流步骤或一个操作的执行。活动图描述了一组顺序的或并发的活动。活动视图用活动图来体现。活动图很像流程图, 它显示出工作步骤, 判定点和分支。可用于表示一个对象的操作和一个业务过程。

活动图

物理视图
物理视图对应用自身的实现结构建模, 例如系统的构件组织和建立在运行节点上的配置。这类视图提供了将系统中的类映射成物理构件和节点的机制。物理视图有两种: 构件图和部署视图。

构件图

部署图

模型管理视图
模型管理视图对模型自身组织建模。一系列由模型元素( 如类、 状态机和用例) 构成的包组成了模型。一个包(package)可能包含其它的包, 因此, 整个模型实际上可看成一个根包, 它间接包含了模型中的所有内容。包是操作模型内容、 存取控制和配置控制的基本单元。每一个模型元素包含于包中或包含于其它模型元素中。

包
扩展机制
UML提供了几种扩展机制, 允许建模者在不用改变基本建模语言的情况下做一些通用的扩展。这些扩展机制已经被设计好, 以便于在不需理解全部语义的情况下就能够存储和使用。由于这个原因, 扩展能够作为字符串存储和使用。对不支持扩展机制的工具来说, 扩展只是一个字符串, 它能够作为模型的一部分被导入、 存储, 还能够被传递到其它工具。我们期望后端工具设计成能够处理各种扩展, 这些工具会为它们需要理解的扩展定义特定的语法和语义。扩展机制包括约束、 标记值和构造型。
约束是用文字表示式表示的语义限制。

约束
标记值是一对字符串—一个标记字符串和一个值字符串—存储着有关元素的一些信息。标记值能够与任何独立元素相关, 包括模型元素和表示元素。标记是建模者想要记录的一些特性的名字, 而值是给定元素的特性的值。例如, 标记能够是author, 而值是对元素负责的人的名字, 如Charles Babbage。

标记值
构造型是在一个已定义的模型元素的基础上构造的一种新的模型元素。构造型的信息内容和形式与已存在的基本模型元素相同, 可是含义和使用不同。例如, 商业建模领域的建模者希望将商业对象和商业过程作为特殊的建模元素区别开来, 这些元素的使用在特定的开发过程中是不同的。它们能够被看作特殊的类—它们有属性和操作, 可是在它们与其它元素的关系上和它们的使用上有特殊的约束。

构造型

各种图汇总:

第三部分 设计实例
设计一 用例图及进度安排
一、 实验目的
1．熟悉用例图的基本功能和使用方法。
2．掌握如何使用建模工具绘制活动图方法。
3．学习使用Microsoft Project对题目进行进度安排。
二、 实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、 实验内容
根据CCUT的图书管理系统开发进度, 在完成对系统的需求建模, 得到用例模型后, 应针对每个用例进行业务分析, 说明其具体的业务流程, 现系统分析部指派您完成该项任务。要求:
对其中主要功能的用例书写书面用例。
四、 实验步骤
书写”删除读者信息”用例的书面用例。一般应包含以下信息:
( 1) 管理员在录入界面, 输入待删除的读者名;
( 2) ”业务逻辑”组件在数据库中, 查找待删除的读者名;
( 3) 如果不存在, 则显示出错信息, 返回步骤( 1) , 如果存在则继续;
( 4) ”业务逻辑”组件判断”待删除的读者”是否能够删除;
( 5) 如果不能够, 则显示出错信息, 返回步骤( 8) , 如果能够则继续;
( 6) 在数据库中, 删除相关信息;
( 7) 显示删除成功信息;
( 8) 结束。
分析:
在图书管理系统中,管理员首先登录系统,系统验证经过后,管理方可向系统查询数据,在查询后,系统会给出提示,有没有找到相关的数据,管理员根据系统查询的返回结果,进行下一步的操作,就是删除读者,在删除的过程中,系统会对查询得到的结果判断该记录是否能够删除,若能够删除,则给删除提示,若不能删除,也给相关的提示信息。
绘图步骤:
(1)在用例图上双击main,出现如图1.1所示,为绘制用例图做好准备。

图1.1
(2)在图中的工具栏选取Actor图标, 在右边的图中添加一个Actor, 并输入名称:administrator,如图1.2所示。
(3)在左边的工具栏中, 选取用例的图标, 在右边的图中画出一个用例, 并输入用例的名称: login 。

图1.2
( 4) 按照步骤( 3) , 绘制出如图1.4和图1.5的两个用例。

图1.3

图1.4

图1.5
( 5) 在绘出了用例后, 接下来的是绘制参与者与用例实现, 如图1.6所示。

图1.6

( 6) 根据步骤( 5) , 同时完成如图1.7和图1.8。此时, 删除读者用例图就到此完成。其系统查询读者信息等其它的功能会在时序图和活动图中描绘。
( 7) 根据分析情况, 进一步添加或细化用例图。

图1.7

图1.8
五、 实验报告要求
1． 整理实验结果。
2． 小结实验心得体会。

设计二 活动图
一、 实验目的
1．熟悉活动图的基本功能和使用方法。
2．掌握如何使用建模工具绘制活动图方法。
二、 实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、 实验内容
根据CCUT的图书管理系统开发进度, 在完成对系统的需求建模, 得到用例模型后, 应针对每个用例进行业务分析, 说明其具体的业务流程, 现系统分析部指派您完成该项任务。要求:
用活动图来描述系统中已知用例的业务过程:
1．描述删除读者用例。
四、 实验步骤
绘制”删除读者信息”用例的活动图。删除读者信息一般按照以下步骤进行:
( 1) 管理员在录入界面, 输入待删除的读者名;
( 2) ”业务逻辑”组件在数据库中, 查找待删除的读者名;
( 3) 如果不存在, 则显示出错信息, 返回步骤( 1) , 如果存在则继续;
( 4) ”业务逻辑”组件判断”待删除的读者”是否能够删除;
( 5) 如果不能够, 则显示出错信息, 返回步骤( 8) , 如果能够则继续;
( 6) 在数据库中, 删除相关信息;
( 7) 显示删除成功信息;
( 8) 结束。
绘图步骤:
( 1) 在用例图中, 找到删除的用例, 如图2.1所示, 在删除用例上单击右键, 在弹出的快捷菜单中选”New”, Rose工具也会弹出一个菜单, 选”Activity Diagram”, 选中后单击, 便能够新建好一个活动图。如图2.2所示。

图 2.1

图2.2
(2)新建好活动图后, 双击删除的活动图, 得到如图2.3所示, 然后把在左边的工具栏内点击”Swinlane”, 在右边的图添加一个泳道, 如图2.4所示, 并命名为administrator.按照此步骤, 再添加另一个泳道, 并命名为SystemTool, 得到图2.5。

图2.3
( 3) 接着在左边的工具上选取开始点, 并在administrator的泳道上添加, 如图2.6所示; 添加完开始结点后, 再来为此活动图添加活动, 图2.7所示, 在左边的工具栏上选中Activity这个图标, 在administrator这边的泳道上添加一个活动, 命名为登录( login) , 再在开始结点和活动登录( login) 之间添加活动关系, 如图2.8所示。

图2.4

图2.5

图2.6

图2.7
图2.8
( 3) 完成步骤( 2) 后, 登录输入需要对输入的信息进行验证, 则在图中添加一个验证框, 如图2.9所示: 添加验证框后, 验证的内容, 如果经过, 则允许管理员进行查询操作, 如图2.10所示; 如不能经过, 则结束, 如图2.11所示。

图2.9

图2.10

图2.11
( 4) 验证后, 下一步的操作是查询需要删除的记录, 添加一个活动, 命名为delete, 如图2.12和图2.13所示。

图2.12

图2.13
( 5) 最后, 在删除后, 系统会返回操作结果给操作者, 图2.14所示; 删除成功或删除失败系统都会有信息返回给操作者。
( 7) 根据分析设计情况, 进一步添加或细化活动图。

图2.14
五、 实验报告要求
1． 整理实验结果。
2． 小结实验心得体会。

设计三 状态图
一、 实验目的
1．熟悉活动图的基本功能和使用方法。
2．掌握如何使用建模工具绘制活动图方法。
二、 实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、 实验内容
经过前面内容的学习, 完成了对CCUT图书馆的图书馆管理系统的需求的初步分析, 得出系统的用例图和相应的活动态。经过这两类图我们能够初步了解系统的业务处理过程, 但对业务处理过程的处理状态间转换了解仍不够, 这不利于设计人员对系统业务的进一步理解, 而状态图能从对象的动态行为的角度去描述系统的业务活动。因此, 指派你运用本节所学的状态图, 完成如下任务:
1. 完成图书业务模块中还书用例的状态图。
四、 实验步骤
1．业务分析: 由前面章节对图书馆管理系统中的还书主要业务的描述和分析可知, 还书业务的动态行为是由: 空闲( idle) 、 图书查找( finding) 、 还书( reversion) 、 失败( Failure) 、 归还成功( Success) 5种状态及激活相互转换的事件。
2．绘制状态图: 请您根据分析运用UML绘制还书用例的状态图。
分析:
还书的状态图, 还书的主要业务都是由管理员来完成, 首先管理员必须先登录系统, 并经过验证后, 便能够进行下一步的操作, 查找该书的相关信息, 如存在, 则进行还书操作, 如不存在该信息, 则给出提示信息;
绘图步骤:
( 1) 在用例图中的还书( revesion) 用例, 单击右键, 如图3.1所示, 新建一个状态图, 命名为revesion状态图, 图3.2所示。

图3.1

图3.2
( 2) 双击”receivesion”状态图, 展开后, 在左边的工具栏上选取一个实心圆点, 此结点为开始结点, 图3.3所示; 当还书的时候, 操作者先要询问系统的状态, 如果系统忙, 操作者则必须等待, 因此, 得到系统的两种状态, 如图3.5所示。

图3.3

图3.4

图3.5
( 3) 操作者在询问系统和状态后, 得到的图3.6所示两种状态, 如果系统忙, 操作者必须要等待、 结束, 如图3.7和图3.8所示, 重返步骤( 1) 。

图3.6

图3.7

图3.8
( 4) 如系统空闲, 则进行对还书的信息进行查询操作, 图3.9所示; 查询也有两种结果, 一是查询得到该书的相关信息, 二查询不到该书的相关信息; 则此时有两种状态, 需要建立两种状态, 如图3.10所示。

图3.9

图3.10
( 5) 最后, 操作者进行了操作后, 系统会给出操作的结果给操作者; 操作成功或失败, 都会有提示信息给出。整个的还书的过程便完成; 图3.11所示。
( 7) 根据分析设计情况, 进一步添加或细化状态图。

图3.11
五、 实验报告要求
1．整理实验结果。
2．小结实验心得体会。

设计四 类
一、 实验目的
1．理解类的基本概念。
2．掌握如何从需求分析中抽象出类的方法。
3．掌握在Rational Rose中绘制类的操作方法。
二、 实验器材
1．计算机一台。
2．Rational Rose 工具软件。
三、 实验内容
经过前面内容的学习, 完成了对CCUT图书馆的图书馆管理系统的需求的初步分析, 得出系统的用例图和相应的活动态和状态图。经过这两类图我们能够初步了解系统的业务处理流程。现在需要对系统进行静态建模, 这就需要从系统的用例图、 活动图和状态图去寻找和发现类。因此, 指派你运用本节所学的有关如何抽象出类的知识, 完成如下任务:
1． 寻找和抽象出书籍管理功能中的类。
四、 实验步骤
1．分析: 由前面章节对图书馆管理系统中的书籍管理功能可知, 该模块是由书籍信息类、 书目类、 新增书籍界面类、 修改书籍界面类、 删除书籍界面类和书籍管理类6个类组成。
2．绘制类的步骤:
( 1) 打开前