岗位技能实训指导书.docx
- 文档编号:26751066
- 上传时间:2023-06-22
- 格式:DOCX
- 页数:97
- 大小:2.58MB
岗位技能实训指导书.docx
《岗位技能实训指导书.docx》由会员分享,可在线阅读,更多相关《岗位技能实训指导书.docx(97页珍藏版)》请在冰豆网上搜索。
岗位技能实训指导书
岗位技能实训(UML)指导书
(使用班级:
140401-03班)
姚庆安吕寻才唐培丽
2016年6月1日
前言
UML面向对象系统分析与设计课程是计算机科学与技术本科专业的一门重要的专业课。
通过本课程的学习,使学生在已有的计算机软、硬件基础知识,程序设计知识,数据库和网络通信知识的基础上系统掌握面向对象系统分析与设计的基本方法和技术,并具有针对特定环境下的应用问题进行信息系统开发(包括系统分析,设计与实现)的能力。
通过学习本课程学生可以理解和掌握面向对象系统的分析和设计的方法和分步过程、掌握面向对象系统分析和设计的建模标准UML语言,能够利用RationalRose(或MicrosoftViso)软件以某一信息系统为例进行系统分析和设计。
本课程主要介绍系统原理的基本概念、系统开发过程RUP、对面向对象分析和面向对象设计的方法、对面向对象分析和设计的建模标准UML等内容。
通过本课程的学习,学生掌握的知识、内容及掌握的程度要求为:
1.使学生理解面向对象的信息系统的开发过程、系统分析和设计的原则和方法;
2.使学生掌握UML语言的基础知识,以及UML在面向对象的软件系统分析和设计中的应用,并能使用UML工具建立系统模型;
3.使学生掌握在UML系统模型下应用高级语言建立应用系统的方法;
4.通过案例教学和实验,提高学生在应用面向对象技术开发软件方面的动手能力和解决问题的能力,并鼓励创新。
本实验所要求的建模工具为RationalRose2003。
本课程通过对CCUT图书馆系统进行建模设计开发。
目录
第一部分实训计划及要求1
第一章实训计划1
第二章时间地点安排8
第三章撰写实训报告9
第二部分UML基础知识10
第三部分设计实例24
设计一用例图及进度安排24
设计二活动图29
设计三状态图37
设计四类43
设计五类的关系50
设计六交互图54
设计七对象图和包62
设计八组件图和部署图64
设计九正向工程71
第一部分实训计划及要求
第一章实训计划
Ø实训日期:
2016.06.27-2016.07.01
Ø实训目的、要求及实训方式:
一.实训目的
1、为了培养学生自我再学习的意识和能力,设计中采用没有学过的统一建模语言UML,训练学生学习的能力。
2、理论和实践相结合,综合运用程序设计知识、数据结构知识、面向对象等知识,提高综合实践的能力。
3、在每个设计题目中,除了必须完成的功能外,都留有自由发挥的空间,以体现软件设计的艺术性和创造性,培养对软件设计较好的鉴赏力风格。
4、训练实训报告或论文的书写能力。
5、加强基本工具软件的使用能力。
6、为后续课程的学习奠定良好的基础。
二.实训要求
1、要求学生在实训期间积极思考,勇于创新,努力将学过的多个知识点转变为实践能力,
2、严格遵守实训纪律,不缺勤,不迟到,不早退,不许玩游戏。
3、设计要求每人一组,独立完成。
4、注意设计作品的数量和质量,撰写实训报告。
三.实训方式
每天提供六个小时的上机时间,用于程序实现;其他时间用于完成软件设计,同时有教师辅导答疑。
Ø拟订题目:
题目一:
银行信息系统
●需求分析:
银行是与人们生活密切相关的一个机构,银行可以提供存款、取款、转账等业务。
在银行设立账户的人或机构被称为银行的客户(customer)。
一个客户可以在银行开设多个账户(account),客户可以存钱到账户中,也可以从自己的账户中取钱,还可以将存款从一个账户转到另一个账户。
另外,客户可以随时查询自己的账户情况,以及查询以前所进行的存款、取款等交易记录。
客户还有权利要求关闭自己的账户。
实际生活中的银行功能其实还要复杂得多,但为了简化系统,本次设计只考虑银行的基本功能。
简化版的银行信息系统至少应具有如下功能:
(1)一个银行可以有多个账户;
(2)一个银行可以有多个客户;
(3)一个客户可以持有多个账户;
(4)一个账户可以有多个持有者;
(5)银行可以为客户开设账户;
(6)银行可以为客户注销账户;
(7)客户可以从自己账户中取钱;
(8)客户可以向自己账户中存钱;
(9)客户可以在同一银行的不同账户之间转账;
(10)客户可以在不同银行的不同账户之间转账;
请完成登录、存款、取款、转账和查询几个模块的设计。
●工作内容及要求
请在一周内完成下列工作内容:
(1)进一步细化需求分析的内容,识别出系统的参与者,并完成用例图;
(2)将用例图中的每个用例都写成相应的事件流文档;
(3)进一步使用活动图来描述每个用例,为后续的系统设计做好准备;
(4)按照系统的功能分析,从用例的描述中提取出系统的对象类和界面类,建立类图;
(5)分析类图中的实体类和实体类之间的关系,画出数据库的逻辑模型图(只包含实体类,且注明角色和阶元)。
(6)对数据库的逻辑模型进行优化,取消多对多的联系,完成最终的逻辑模型设计;
(7)使用交互作用图或状态机图完成系统动态行为的建模。
(建议使用顺序图按功能分别描述)。
●提交结果及要求
(1)请提交用例图(包括事件流文档)、活动图、类图、交互作用图。
(2)可选提交:
状态机图、系统部署图
(3)完成规定格式的实验报告(纸质),上交电子版实验报告和系统建模的成果(各类图和相关文档,电子文档)。
题目二:
某企业的销售管理信息系统
●需求分析:
假设某大型企业需要一个销售管理信息系统,来完成合同信息等销售信息的自动化管理,一般来说,一个常见的销售管理系统的功能应包括收集大客户的基本情况、制定产品销售计划、推销本企业的产品、与客户签订销售合同、检查客户付款单并催缴客户拖欠的应付货款、核对检验并发送货物、核查客户订购的产品、提请生产调度部门组织生产仓库中缺少的产品,检查销售合同履行率、提供售后服务等。
现做一定的简化与合并,得到系统的分解结构如下:
销售管理信息系统包括以下几部分:
(1)大客户管理
为大宗采购本企业产品的大客户建立数据库
(2)销售计划管理
根据企业生产能力核对当前市场行情的预期制定全年销售计划。
(3)销售合同管理
(设计重点)添加、修改、查询销售合同,核对收款单并发送货物,检查收条,催缴欠款,核算销售合同履约率,将履约合同转入历年履约合同库;编制年综合统计报表。
●工作内容及要求
请在一周内完成下列工作内容:
(1)进一步细化需求分析的内容,识别出系统的参与者,并完成用例图;
(2)将用例图中的每个用例都写成相应的事件流文档;
(3)进一步使用活动图来描述每个用例,为后续的系统设计做好准备;
(4)按照系统的功能分析,从用例的描述中提取出系统的对象类和界面类,建立类图;
(5)分析类图中的实体类和实体类之间的关系,画出数据库的逻辑模型图(只包含实体类,且注明角色和阶元)。
(6)对数据库的逻辑模型进行优化,取消多对多的联系,完成最终的逻辑模型设计;
(7)使用交互作用图或状态机图完成系统动态行为的建模。
(建议使用顺序图按功能分别描述)。
●提交结果及要求
(1)请提交用例图(包括事件流文档)、类图、活动图、交互作用图。
(2)可选提交:
包图、状态机图、系统部署图
(3)完成规定格式的实验报告(纸质),上交电子版实验报告和系统建模的成果(各类图和相关文档,电子文档)。
题目三:
汽车租赁系统分析与设计
●需求分析
系统的整体目标是:
利用互联网和信息化技术,结合汽车租赁经营的实际运作情况,建设一个覆盖汽车租赁经营全部业务的“汽车租赁系统”。
功能需求:
“汽车租赁系统”中的功能需求可以包括以下几个方面:
(1)客户可以通过不同的方式(包括电话、前台、网上)预订车辆;
(2)能够保存客户的预订申请单;
(3)能够保存客户的历史记录;
(4)工作人员可以处理客户申请;
(5)技术人员可以保存对车辆检修的结果。
满足上述需求的系统主要包括以下几个模块:
(1)基本数据维护模块:
该模块提供了使用者录入、修改并维护基本数据的途径。
(2)基本业务模块:
在系统中,客户可以填写汽车租赁申请表,工作人员处理这些表格;同时,技术人员还可以提交每辆车的状态,以便工作人员根据这些资料决定是否批准客户的请求。
(3)数据库管理模块:
在系统中,对所有客户、工作人员以及车辆的信息都要进行统一管理,车辆的租赁情况也要进行详细的登记。
(4)信息查询模块:
该模块主要用于查询相关信息。
●工作内容及要求
请在一周内完成下列工作内容:
(1)进一步细化需求分析的内容,识别出系统的参与者,并完成用例图;
(2)将用例图中的每个用例都写成相应的事件流文档;
(3)进一步使用活动图来描述每个用例,为后续的系统设计做好准备;
(4)按照系统的功能分析,从用例的描述中提取出系统的对象类和界面类,建立类图;
(5)分析类图中的实体类和实体类之间的关系,画出数据库的逻辑模型图(只包含实体类,且注明角色和阶元)。
(6)对数据库的逻辑模型进行优化,取消多对多的联系,完成最终的逻辑模型设计;
(7)使用交互作用图或状态机图完成系统动态行为的建模。
(建议使用顺序图按功能分别描述)。
●提交结果及要求
(1)请提交用例图(包括事件流文档)、类图、活动图、交互作用图。
(2)可选提交:
包图、状态机图、系统部署图
(3)完成规定格式的实验报告(纸质),上交电子版实验报告和系统建模的成果(各类图和相关文档,电子文档)。
题目四:
酒店预订系统
●需求分析
基本业务流程:
顾客预约:
记录,取消,修改,查询和显示
顾客到达:
有预约顾客和无预约顾客相分离;
用餐顾客结帐:
同时刷新餐桌和预约信息
显示:
显示当前桌子的状态
完成以下模块:
(1)预约模块
Ø显示预约:
显示当天所有预约,同时桌子根据当前时间显示当前状态
Ø添加预约:
添加一个新的预约,并插入数据库,如果是当天预约则显示在预约状态栏中
Ø修改预约:
修改一个已有的预约,可以修改订餐人数,预约日期,时间以及餐桌
Ø删除预约:
删除一个已有预约,删除数据库信息,如果是当天预约则刷新预约状态栏
Ø查询预约:
根据订餐人姓名,餐桌号,预约日期,时间查询预约状态
(2)到达模块
Ø到达情况有两种,一种是有预约的到达,另一种是无预约的到达
Ø有预约的到达首先要查询预约,故在预约模块中添加到达的功能
Ø无预约的到达,就可以立即找空桌子用餐
在到达操作中还要刷新当前桌子状态,由预约或空闲状态转为用餐状态
(3)结帐模块
Ø显示当前正在用餐的桌子信息,从中选中需要结帐的桌子,进行结帐操作
Ø结帐完成后,将桌子置为空闲状态,若当天还有不同时间预约此桌子的则置该桌为预约状态
●工作内容及要求
请在一周内完成下列工作内容:
(1)进一步细化需求分析的内容,识别出系统的参与者,并完成用例图;
(2)将用例图中的每个用例都写成相应的事件流文档;
(3)进一步使用活动图来描述每个用例,为后续的系统设计做好准备;
(4)按照系统的功能分析,从用例的描述中提取出系统的对象类和界面类,建立类图;
(5)分析类图中的实体类和实体类之间的关系,画出数据库的逻辑模型图(只包含实体类,且注明角色和阶元)。
(6)对数据库的逻辑模型进行优化,取消多对多的联系,完成最终的逻辑模型设计;
(7)使用交互作用图或状态机图完成系统动态行为的建模。
(建议使用顺序图按功能分别描述)。
●提交结果及要求
(1)请提交用例图(包括事件流文档)、类图、活动图、交互作用图。
(2)可选提交:
包图、状态机图、系统部署图
(3)完成规定格式的实验报告(纸质),上交电子版实验报告和系统建模的成果(各类图和相关文档,电子文档)。
题目五:
工资管理系统
●需求分析
基本业务流程:
一个公司由若干部门构成,每个部门经销若干种产品,并有若干名职员和经理。
工资由基本工资、产品销售业绩奖、若干种保险的扣除等组成。
其中的销售业绩奖按如下规定:
职员按其完成额的5%提成,经理按该部门完成额的1%提成。
每个月生成一个工资表,每年末再按个人的总销售额发放1%的奖金。
系统的功能需求:
在一个公司中,工资管理系统是非常重要的,开发者要尽力做到清晰、准确、公正。
通过向有关部门了解,对公司工资管理系统的需求可得到如下描述:
(1)公司的会计负责记录各个部门、各个职员的详细销售信息;
(2)公司的会计根据当月的销售信息,按一定的规则计算各个职员的月工资;
(3)在年终的时候,公司的会计还负责计算各个职员的奖金情况;
(4)公司的每个职员有权利知道自己工资的全部信息,即他们可以查看自己工资的详细信息;
(5)如果发现工资有错误的地方,公司的职员有权利向会计反应;
(6)会计根据反应的错误信息进行核查,并做出相应的处理。
●工作内容及要求
请在一周内完成下列工作内容:
(1)进一步细化需求分析的内容,识别出系统的参与者,并完成用例图;
(2)将用例图中的每个用例都写成相应的事件流文档;
(3)进一步使用活动图来描述每个用例,为后续的系统设计做好准备;
(4)按照系统的功能分析,从用例的描述中提取出系统的对象类和界面类,建立类图;
(5)分析类图中的实体类和实体类之间的关系,画出数据库的逻辑模型图(只包含实体类,且注明角色和阶元)。
(6)对数据库的逻辑模型进行优化,取消多对多的联系,完成最终的逻辑模型设计;
(7)使用交互作用图或状态机图完成系统动态行为的建模。
(建议使用顺序图按功能分别描述)。
●提交结果及要求
(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,而值是对元素负责的人的名字,如CharlesBabbage。
标记值
构造型是在一个已定义的模型元素的基础上构造的一种新的模型元素。
构造型的信息内容和形式与已存在的基本模型元素相同,但是含义和使用不同。
例如,商业建模领域的建模者希望将商业对象和商业过程作为特殊的建模元素区别开来,这些元素的使用在特定的开发过程中是不同的。
它们可以被看作特殊的类—它们有属性和操作,但是在它们与其他元素的关系上和它们的使用上有特殊的约束。
构造型
各种图汇总:
第三部分设计实例
设计一用例图及进度安排
一、实验目的
1.熟悉用例图的基本功能和使用方法。
2.掌握如何使用建模工具绘制活动图方法。
3.学习使用MicrosoftProject对题目进行进度安排。
二、实验器材
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 岗位 技能 指导书