1实验指导书一第1周.docx
- 文档编号:11242599
- 上传时间:2023-02-26
- 格式:DOCX
- 页数:14
- 大小:447.80KB
1实验指导书一第1周.docx
《1实验指导书一第1周.docx》由会员分享,可在线阅读,更多相关《1实验指导书一第1周.docx(14页珍藏版)》请在冰豆网上搜索。
1实验指导书一第1周
实验一安装使用UML建模工具RationalRose2003
一、教学目的
1.理解UML基本绘图元素及13种图的含义;
2.熟悉使用RationalRose2003建立UML模型。
二、实验内容
超市进销存管理系统的UML建模-----使用UML进行系统的分析和设计
1.超市进销存管理系统需求分析;
2.超市进销存管理系统UML建模。
.
三、仪器、设备、材料
电脑
四、实验准备
理解UML基本绘图元素含义。
五、实验原理或操作要点简介
1.对系统功能进行必要的描述;
2.绘制系统的主要模型图;
3.模型图要有说明性文字解释。
六、注意事项
七、实验过程与指导
一、超市进销存管理系统的需求分析
1、系统功能需求
超市进销存管理系统要求能对超市的进、销、存行为进行管理,并且能根据不同权限的系统用户的需求进行报表的生成和查询,为超市管理者的决策提供协助。
(1)营业管理
1)营业员接收顾客订购,输入顾客购买的商品,计算总价;
2)顾客选择现金或者信用卡付款;
3)营业员保存顾客购买的商品的记录;
4)营业员打印销货清单给顾客。
(2)库存管理
1)库存管理员每天进行盘点(统计)一次;
2)库存管理员当发现库存商品有损坏时,及时到相关部门报损;
3)在商品到货时,库存管理员检验商品是否合格,并对合格的商品进行验收入库,退回不合格的商品;
(3)进货管理
1)进货员用新商品供应商信息更新供应商数据库的信息;
2)进货员统计库存商品是否低于库存下限,然后制作订货单;
3)进货员订购货物,并接收货物,同时协助货物入库。
(4)会计活动
1)会计人员根据订货单支付货款;
2)会计人员根据所有营业数据结收营业金额,并收取现金;
3)会计人员定期进行所有数据统计,并制作统计报表;
(5)经理管理
1)经理对日常流程进行审核,包括审核订货单、审核会计报表、审核汇总订单表;
2)经理对各类员工进行人事调动等人事管理;
3)经理在促销期间或节日期间,注明相关商品的促销价格和促销时段;
4)经理按市场情况经常变动商品价格。
2.设计方法、思路和主要技术
RUP开发过程是“用例驱动”的开发过程,在RUP开发过程中,开发人员首先捕获客户的需求,并以用例的形式组织成用例模型;然后对需求模型进行分析、整理、验证,建立分析模型;最后以分析模型为基础,设计系统,来满足这些用例模型的要求。
因此,软件的整个开发过程,就是建立模型的过程,从建立用例模型开始,其次是分析模型,接着是设计模型和实现模型,在建立了这些模型之后,还将根据用例模型设计出测试模型来对系统进行验证。
所有模型的建立过程不是线性转变的,而是是一个迭代、增量的开发过程。
也就是在整个项目开发周期中,将会多次经过这五个模型的迭代、修改、删除、优化、精化的过程。
下面是对5个模型的定义:
●用例模型:
能够有效地帮助开发人员发现真正的功能需求,并用UML设计语言来描述需求,如,用例图。
●分析模型:
通过协作图来描述用例,检验、验证用例的一致性、正确性、完备性、可行性。
分析的结果表示为类图、包图。
●设计模型:
在分析模型的基础上,把分析阶段的类分解为语言能实现的软件类,利用各种实现技术构造系统、子系统;并把设计类进行分组,打包、定义子系统和类的接口。
这一阶段的产品有:
(类图、对象图、包图、构件图)
●部署模型:
定义可计算节点系统的物理结构,并验证运行在这些节点上的构件想法是否实现了用例。
(构件图、部署图)
●测试模型:
根据用例中所描述的功能来构建测试模型。
采用用例技术的优点有2点:
一是,用例表达了用户对软件的目标要求,用例是系统向其用户提供的增值功能。
二是,用例很直观,用户和客户根本无法了解复杂符号,而用例这种简单、自然的表述法可以使其易于阅读,并提出修改意见。
根据以上确定的设计方法,我们使用RationalRose2003进行建模及设计,确定设计思路如下:
1.在UseCaseView中建立三个层次模型,逐步分析出用例图,建层如下图:
2.在LogicalView中也建立三个层次模型,该层内容是在UseCaseView分析的基础上逐步设计出具体的类及其类关系,数据结构,并根据需要确定时序图、协作图、活动图、状态图等,建层如下图:
二、系统的UML建模
1、系统的用例图
先学习一下用例分析的方法。
用例图是描述用例、参与者及其关系的图。
与所有UML的其它图一样,用例图可以包括注释、约束。
下图是棋牌管理系统对应的用例图。
图中的元素包括:
参与者、用例、一个方框和一些表示关系的连接线,所有的用例都位于方框之内,该方框称为“系统边界”。
方框内是棋牌管理系统的多个用例,方框外是外部参与者。
用例的表示
用例是对一组场景共同特征的抽象,即,用例是对一组场景共同行为的抽象,场景就是用例的一次完整的、具体的执行过程。
用例与场景的关系,如同类与对象的关系,用例应该给参与者带来可见的价值。
1.场景
在系统中,按照某个顺序执行的一系列相关的动作后,实现了某种功能,把完成了这一功能的操作的集合称为场景。
“场景”就是用户使用系统的一个实际的、特定的场面。
下面列举一个场景例子。
开发者与用户、客户进行交流,构建场景和用例规格描述。
一个场景就是描述用户与系统之间的一系列交互活动,描述了系统一次具体执行的行为路径,即,一次完整的事件流。
如,小刘通过银行柜员机(ATM系统)取款3000元的场景,如下图所示。
开发者获取需求的步骤是:
第一步,开发者首先将用户的工作流程表示为场景,然后,将同一类场景抽象为用例,以描述系统的功能;第二步,客户和用户通过审查场景,并测试开发者提供的原型系统,以验证和确认需求规格说明书。
第三步,当系统需求定义成熟和稳定后,开发者和客户共同对需求规格说明进行确认,包括,系统的功能性需求、非功能需求、用例和场景在内的需求确认。
识别参与者
需求获取的第一步是,标识参与者。
这一服务定义了系统的边界,并从开发者要考虑的系统中,找出所有的观察点。
开发者通过回答下面问题来寻找参与者:
系统支持哪些用户组完成他们的工作?
哪一个用户组执行系统的主要功能?
次要功能由哪一个用户组完成,比如维护或管理?
与该系统进行交互的外部硬件和软件系统是哪些?
在确定具体参与者时,可以通过以下一些常见的问题来帮助分析:
谁使用这个系统、谁安装这个系统、谁启动这个系统、谁维护这个系统、谁关闭这个系统、哪些其他的系统使用这个系统、谁从这个系统获取信息、谁为这个系统提供信息。
是否有事情自动在预计的时间发生(说明有定时器
系统是否需要与外部实体交互以帮助自己完成任务。
一旦参与者被标识出来后,需求获取的下一步活动是,决定每一个参与者将访问的功能。
识别用例
在需求分析时,当标识出了参与者以后,下一步就是识别用例,寻找用例最好的方法是,从参与者的角度看,参与者是如何使用系统的,通过回答以下问题,可以识别用例:
每个参与者希望系统提供什么功能?
系统是否存储和检索信息?
如果是,由哪个参与者触发?
系统改变状态时,是否通知参与者?
哪些外部事件触发系统?
哪个参与者发出事件?
通过回答以上问题,得到一个候选用例列表。
标识用例间的关系
下面以一个“棋牌馆管理系统”的局部用例模型为例,说明用例之间的三种关系:
包含关系、扩展关系、泛化关系
该系统的主要功能是:
以Internet的形式向客户提供座位预订服务,如果暂时无法获取座位信息时,允许客户进入“等候队列”,当有人退订之后将及时通知客户。
另外,该系统还将为总台服务员提供座位安排以及结帐的功能,要求能够支持现金和银行卡两种结帐方式。
在图中可以看到4种元素:
参与者、用例、一个方框和一些表示关系的连接线。
不难知道该图中有客户、总台服务员和银联POS系统3个参与者,还包括预订座位、安排座位、办理结帐等8个用例。
下面我们来理解上图表示的用例图的含义。
这张用例图定义了三个基用例:
预定座位、安排座位和处理结帐。
•1)客户通过Internet启动“预定座位”用例,在“预定座位”用例的执行过程中,将“检查座位信息”(包含用例),如果没有空闲的座位或满意的座位,可以选择进入等候队列,这样就将启动扩展用例“处理等候队列”。
•2)在客户到棋牌馆时,总台服务员启动“安排座位”用例,在执行过程中,将启动包含用例“检查座位信息”。
•3)当客户要离开棋牌馆时,总台服务员将启动“处理结账”用例,并且定义了两种“收款”用例,一个是“处理现金结账”,另一个是“处理银行卡结账”,后一个用例将通过与外部系统“银联POS系统”交互完成。
对用例的描述有两种方法:
用例图和用例描述。
用例图只能描述了系统的大概功能,是一种视图;用例描述才能表示系统活动的细节。
用例描述又分为用例概述和用例详述.
用例描述的是一个系统做什么(what)的信息,并不说明怎么做(how),怎么做是设计模型的事。
用例描述模板
为了说明一个用例的行为,描述一个用例的关键要素包括:
用例何时开始(前置条件)、何时结束(后置条件)、参与者何时与用例交互、交互了什么信息,以及用例执行的基本事件流和扩展事件流。
1.事件流
事件流就是用例执行时,由一序列活动组成的控制流。
事件流分为基本事件流和扩展事件流两种.下面是事件流模型,如图下所示.
2.用例描述模板
用例描述有两种格式:
一种是纯文本格式,另一种是表格形式,下表所示就是一个经典的表格式用例描述模板,其中加粗显示的是必须编写的部分。
用例编号
[为用例制定一个唯一的编号,通常格式为UCxx]
用例名称
[应为一个动词短语,让读者一目了然地知道用例的目标]
用例概述
[用例的目标,一个概要性的描述]
范围
[用例的设计范围]
主参与者
[该用例的主Actor,在此列出名称,并简要的描述它]
次要参与者
[该用例的次要Actor,在此列出名称,并简要的描述它]
项目相关人
利益说明
项目相关人
利益
[项目相关人员名称]
[从该用例获取的利益]
……
……
前置条件
[即启动该用例所应该满足的条件。
]
后置条件
[即该用例完成之后,将执行什么动作。
]
成功保证
[描述当前目标完成后,环境变化情况。
]
基本事件流
步骤
活动
1
[在这里写出触发事件到目标完成以及清除的步骤。
]
2
……(其中可以包含子事件流,以子事件流编号来表示)
扩展事件流
1a
[1a表示是对1的扩展,其中应说明条件和活动]
1b
……(其中可以包含子事件流,以子事件流编号来表示)
子事件流
[对多次重复的事件流可以定义为子事件流,这也是抽取被包含用例的地方。
]
规则与约束
[对该用例实现时需要考虑的业务规则、非功能需求、设计约束等]
•1)前置条件:
指在用例启动时参与者(actor)与系统应置于什么状态,这个状态应该是系统能检测到的、可观测的。
•2)后置条件:
用例结束时系统应置于什么状态,这个状态也应该是系统能检测到的、可观测的。
•3)基本事件流:
基本事件流是对用例中常规、预期路径的描述,也被称为Happyday场景,这是大部分事件所遇到的场景,它将体现系统的核心价值。
•4)扩展事件流:
主要是对一些异常情况、选择分支进行描述。
用例描述分三个步骤:
第一步,对用例概要描述,第二步,对用例详细描述,第三步,补缺漏。
1、用例概要描述
在最初的迭代中,应该对每个用例都写出概要描述。
概要描述阶段中,在填写各个部分的内容时,应分别注意以下几个要点:
•用例名称:
应该与用例图相符,并写上其相应的编号。
•简要说明:
对该用例对参与者所传递的价值结果进行描述,应该注意语言要简要,使用用户能够阅读的自然语言。
•前置条件:
是执行用例之前必须存在的系统状态,这部分内容如果现在不容易确定可以在后面再细化。
•后置条件:
用例执行完毕系统可能处于的一组状态,这部分内容如果现在不容易确定也可以在后面再细化。
•扩展点:
如果包含扩展用例或者包含用例,则写出扩展或包含用例名,并说明在什么情况下使用。
在本例中,用例图里没有相应的内容,因此可以直接写“无”;如果有,则应该在编写事件流的同时进行编写。
•优先级:
说明用户对该用例的期望值,可以为今后开发时制定先后顺序。
可以采用满意度、不满意度指标进行说明,其中满意度的值为0-5,是指如果实现该功能,用户的满意程度;而不满意度的值为0-5,是指如果不实现该功能,用户的不满意程度。
2、用例详细描述
详细描述就是将事件流进行细化,在实际的开发工作中,要不要对一个用例进行细化、细化到什么程度主要根据项目的迭代的计划来决定。
事件流的编写过程是可以分阶段、迭代进行的,对于优先级高的用例花更多的时间,更细化;对优先级低的用例,可以先简略地将主要事件流描述清楚,其余的留到以后处理。
另外,对于一些较为复杂的事件流,可以在用例描述中引用顺序图、状态图、协作图等手段。
3、补缺漏
在将用例描述细化以后,要多与用户的沟通,对用例描述进行验证,然后不断地进行补缺漏,以保证用例描述完整、清晰、正确。
用例粒度
用例的粒度,就是用来描述用户目标的大小的程度。
从大到小可将用例分成三个层次:
概述级、用户目标级、子功能级。
下面以读者阅读图书为例,说明用例的三个级别。
1.概述级
概述级,参与者把整个系统看成一个用例。
2.用户目标级
目标级用例是对概述级进一步细化。
3.子功能级
子功能级用例是对目标级用例的进一步细化。
下面说一下分析大致分三大步骤:
1.问题描述
•当需求分析人员对用户和客户进行访谈后,就要记录下用户和客户对业务系统的描述。
开发人员必须把客户对业务系统的陈述转化为完整的,清晰的、可用于开发系统的描述,这种描述业务系统的格式,必须是客户能理解的、认可的标准格式。
当然,“完整”和“清晰”实际上是做不到的。
第一次是不可能非常接近这些目标的。
但是,最终应有一个文档描述了系统应完成的所有工作(和系统不应完成的工作),而且没有误解。
2.定义术语表
•每个业务领域都具有它本身独一无二的词汇,需求分析的目的就是理解和定义这些词汇。
词汇应该被项目相关人所理解。
术语表必须解决同音异义和同义异音问题。
标识参与者
•首先,需要标识业务参与者。
参与者是在业务中扮演某个角色的人、部门或者独立的软件系统。
一般来说,参与者使用系统或给系统提供服务。
3.标识系统用例
•一旦有了参与者,就可以从参与者的角度看系统,问系统能给参与者提供哪些服务?
通过一问一答,就可以查找用例。
下面说明一下建模要点:
构建结构良好的用例:
1)为系统和部分系统中单个的、可标识和合理的原子行为命名;
2)将公共的行为抽取出来,放到一个被包含用例中,再将它《include》进来;
3)对于变化部分,将其抽取出来,放到一个扩展用例(用《extent》连接)中;
4)清晰地描述事件流,使得读者能够轻而易举地理解
•构建结构良好的用例图:
摆放元素时,应该避免交叉线的出现;对于语义上接近的行为和角色,最好使它们在物理上也更加接近;
•根据系统实际情况控制粒度
前面对创建用例图的相关内容进行了学习,下面进行用例图的设计,创建用例图之前首先需要确定参与者。
系统的参与者主要有6类:
超市管理员、营业员、进货员、库存员、会计员、经理。
(1)系统角色
(2)企业级用例图
(3)系统级用例图
超市管理用例主要分为五个用例:
营业管理、库存管理、经理管理、会计活动、进货管理。
八、思考与提高
九、实验总结
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 实验 指导书