实验二 用例图
- 格式:doc
- 大小:279.00 KB
- 文档页数:6
目录实验一 UML建模基础及用例图实验二类图与对象图实验三序列图与协作图实验四状态图实验五活动图实验(一)UML建模基础及用例图实验目的1、熟悉UML建模工具Rational Rose的基本菜单及操作。
2、掌握UML的可见性规则和构造型的作用。
3、掌握用例的概念;掌握UML用例图的组成及作用。
4、掌握用例与用例之间的各种关系。
实验内容1、练习使用建模工具建立各种UML图形,并对图形进行相应编辑和修改。
2、认识各种UML关系,并用工具表示出来。
中南民族大学管理学院学生实验报告3、什么是用例?用例图中有哪些组成元素?在UML中是如何表示的?答:用例是对系统功能的描述,是向参与者提供重要价值的操作序列。
用例图有:用例、参与者、关联(系统边界)等元素。
用来显示在系统或其他实体内的用例与系统参与者之间的关系。
主要使用场合:需求获取、定义、分析4、用例与用例之间的包含关系、扩展关系和泛化关系各代表什么含义?它们之间有何区别?对以上三种关系各举一例,画出用例图,并进行说明。
(1)包含关系:基本用例的行为包含另一用例的行为。
基本用例描述在多个用例中都有的公共行为。
包含关系是本质上比较特殊的依赖关系,它比一般的依赖关系多了一些语义。
在包含关系中箭头的放向是从基本用例到包含用例的。
(2)扩展关系:扩展关系的基本含义和泛化关系相似,但在扩展关系中,对于扩展用例有更多的规则限制。
基本用例必须声明扩展点,而扩展用例只能在扩展点上增加新的行为和含义。
(3)泛化关系:代表一般与特殊的关系。
UML用例图中泛化关系的意思和面向对象程序设计中的继承的概念是类似的。
不同的是继承使用在实施阶段,泛化使用在分析、设计阶段。
在泛化关系中子用例继承了父用例的行为和含义,子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
5、完成书中94页例子,体会用例图建模的分析过程并模仿来画出该学生信息管理系统的用例图。
画出课后习题101页第4题。
实验一:需求分析项目名称:学生成绩管理系统一、用例视图1.用例图如下图 1—12,用例描述图1—1主要描述了学生成绩管理系统的主要参与者在系统中各自的角色和各自可以进行的操作,明确了每个人的基本权限,任何人员都不可以进行自己权限以外的操作。
管理员:管理员参加的操作主要有登录,打开关闭对系统的操作,录入、查看、修改每个使用人员的信息,查看学生成绩并对学生的成绩进行排名。
登陆系统的时候,要选择自己的身份,输入正确的账号和密码登陆进入系统。
在不需要开放系统的时候,管理员要将系统关闭,并对系统进行维护等工作,在期末教师需要录入成绩的时候和开学时学生要查看自己成绩的时候将系统开放使用,让身份为学生和教师的账号也可以进入系统,其他非系统开放时间只有管理员可以进入系统。
录入人员信息主要是在学校新生入学的时候和学校招聘新教师的时候将老师和学生的信息录入系统,并为添加的每一个人分配一个登陆账号和密码,不同的身份的人员具有不同的操作权限。
例如学生只可以查看自己的成绩和自己的排名,不能够修改添加删除自己或别人的成绩,不能够修改自己的基本信息。
老师只能够为自己所教的课程和选择了这门课的学生录入成绩,而不能为别的课程录入信息,不能够修改自己的操作权限和基本信息。
在学生毕业并对自己在校的任何信息都没有异议之后,在学生离校以后,老师离职以后将已经录入的老师和学生信息删除,相应的账号和密码将不能够再登陆系统。
对出现了错误的账号密码等进行修改,解决学生或老师不能登录系统的问题。
管理员可以查看所有学生的成绩,但是没有权利对学生的成绩进行修改。
对学生的成绩按照单科成绩从高到低,总成绩从高到低,按学号顺序给学生成绩进行排名,并把排名结果公布到系统到系统中,每个学生只能够看到自己的排名。
教师人员:教师人员参与的操作主要有登录系统,添加、删除、修改、查找学生成绩。
登陆系统的时候,要选择自己的身份,输入正确的账号和密码登陆进入系统。
教师只能添加删除修改查看自己所教的课程的学生的成绩,在处理完学生的试卷后将相应的学生的成绩录入到系统中去,不能录入不是自己学生的和不是自己教学的学生成绩。
实验二用例图【实验目的】1.掌握用例的概念。
2.掌握UML中用例图的组成、作用以及使用场合。
3.掌握用例与用例之间的各种关系。
4.学习针对具体场景使用用例图进行分析说明的方法。
5.掌握用例描述的概念和基本结构,以及用例描述的作用。
【实验性质】设计性实验。
【实验要求】1.学习针对具体场景识别参与者和用例的方法,设计其用例图。
2.学习通过Rational Rose绘制用例图的方法。
3.掌握如何对每个用例进行用例描述。
【实验内容】一.网上选课系统需求分析1.某学校的网上选课系统主要包括如下功能:管理员通过系统管理界面进入,建立本学期要开的各种课程,将课程信息保存在数据库中并可以对课程进行改动和删除;学生通过客户机浏览器根据学号和密码进入选课界面,在这里学生可以进行三种操作:查询已选课程、选课以及付费。
同样,通过业务层,这些操作结果存入数据库中。
2.对本系统的的用例、参与者进行分析:本系统拟使用java语言通过三层模型实现:数据核心层、业务逻辑层和接入层。
数据核心层包括对数据库的操作;业务逻辑层作为中间层对用户输入进出逻辑处理,在映射到相应的数据层操作;接入层包括用户界面、系统登录界面、管理界面、用户选课界面等。
本系统涉及的用户包括管理员和学生,是用例图中的活动者,他们的主要特征类似,都有学号和姓名等信息,可抽象出“基”活动者people,而register和student则从people 诞生,数据库管理系统是另外一个活动者。
3.写出系统中出现的一些事件流,如添加课程事件流、删除课程事件流、修改课程事件流,选课事件流等。
下面是系统中出现的一些事件流。
添加课程事件流:a)管理员选择进入管理界面,用例开始。
b)系统提示输入管理员密码。
c)管理员输入密码。
d)系统验证密码。
A1:密码错误e)进入管理界面,系统显示目前所建立的全部课程信息。
f)管理员选择添加课程。
g)系统提示输入新课程信息。
h)管理员输入信息。
1. 找出actor和外部系统,确定系统边界.参与者:呼叫者、邮箱用户2. 主要功能分析(参与者期望的系统行为等)(1). 呼叫者保留信息(留言).(2). 邮箱用户管理信息: 收听/存储/删除.(3). 邮箱用户更改问候语.(4). 邮箱用户更改密码.3. 初步找到的用例呼叫者:保留信息邮箱主人:接收信息、更改问候语、更改密码4. 进一步寻找用例邮箱主人:登录邮箱呼叫者、邮箱主人:拨打邮箱号码5. 分析用例之间的关系本例较为简单,只使用“包含关系”即可.6. 绘制初步用例图7. 编写每一个用例的脚本8. 区分脚本中的主事流或异常情况事件流9. 细化用例图,完成用例模型(略)用例1: 拨打邮箱号1. 呼叫者拨打语音邮件系统的主号码.2. 语音邮件系统发出提示音:输入邮箱号码并加#号.3. 呼叫者输入接收者的邮箱号.4. 语音邮件系统发出问候语:已进入XX的邮箱,请留言. 用例2: 保留信息1. 呼叫者完成邮箱号输入操作.2. 呼叫者说出信息.3. 呼叫者挂断电话.4. 语音邮件系统将记录的信息存放在接收者的邮箱中. 用例3: 登录系统1. 邮箱用户完成邮箱号输入操作.2. 邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同)3. 语音邮件系统播放邮箱菜单:按1键接收信息.按2键更改密码.按3键更改问候语.用例4: 接收信息1. 邮箱用户完成登录操作.2. 邮箱用户选择“接收信息”菜单选项.3. 语音邮件系统播放信息菜单:按1收听当前信息; 按2存储当前信息; 按3删除当前信息;按4返回邮箱菜单.4. 邮箱用户选择“收听当前信息”菜单选项.5. 语音邮件系统播放当前新信息,若无新信息,播放当前已有信息.(注意: 只播放,不删除)6. 语音邮件系统播放信息菜单.7. 用户选择”删除当前信息”,则信息被永久删除.8. 继续执行第3步.用例4变体#1: 存储一条信息1.1 以第6步作为开始.1.2 用户选择“存储当前信息”.1.3 当前信息从新信息队列中删除并添加到旧信息队列中.1.4 继承执行第3步.用例5: 更改问候语1. 邮箱用户完成登录操作.2. 邮箱用户选择“更改问候语”菜单选项.3. 邮箱用户说出新的问候语.4. 邮箱用户按下#键.5. 邮件系统设置新的问候语.用例5变体#1: 在确认前挂断电话1.1 以第3步作为开始.1.2 邮件用户挂断电话.1.3 邮件系统保留旧的问候语.用例6: 更改密码1. 邮箱用户完成登录操作.2. 邮箱用户选择“更改密码”菜单选项.3. 邮箱用户输入新的密码.4. 邮箱用户按下#键.5. 邮件系统设置新的密码.用例6变体#1: 在确认前挂断电话1.1 以第3步作为开始.1.2 邮件用户挂断电话.1.3 邮件系统保留旧的密码.。
结果,进行下一步的操作,就是删除读者,在删除的过程中,系统会对查询得到的结果判断该记录是否可以删除,若可以删除,则给删除提示,若不能删除,也给相关的提示信息。
绘图步骤:
(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
4.文件描述
5.实验结论及心得
第一次上机做这门课的实验,心里还是很紧张的,有些知识上课没有听的很清楚,不过第一次实验还不是很难,在老师的帮助下我完成了。
《软件工程》实验指导书计算机学院2017年2月软件工程实验指导前言软件工程实验是为计算机相关专业本科《软件工程》课程配套设置的,是《软件工程》课程讲授中一个重要的、不可或缺的实践环节。
其目的是使学生能够针对具体软件工程项目,全面掌握软件工程管理、软件需求分析、软件初步设计、软件详细设计、软件测试等阶段的方法和技术,通过该课程设计使学生进一步理解和掌握软件开发模型、软件生命周期、软件过程等理论在软件项目开发过程中的意义和作用,培养学生按照软件工程的原理、方法、技术、标准和规范,进行软件开发的能力,培养学生的合作意识和团队精神,培养学生对技术文档的编写能力,从而使学生提高软件工程的综合能力,提高软件项目的管理能力。
按该课程的特点,实验内容包括软件开发的两大方法学的专题训练,即结构化(生命周期学)的方法学和面向对象的方法学,通过对一个简单项目,要求学生利用结构化软件开发技术或面向对象的软件开发技术完成对该项目的开发。
因此设置五个实验项目,从项目发的准备工作,系统分析过程,系统设计过程,软件测试到系统实施,覆盖软件开发的整个过程,此外又引入我国国家《计算机开发规范》,以规范技术文档的书写标准,提高实验教学质量。
通过实验训练,达到如下目的:使学生进一步了解和掌握软件工程原理,提高对实际项目的分析和设计能力,通过实验课程,熟悉和基本掌握软件工程方法学、软件开发的过程,文档资料的编写格式及规范,全面领会和贯通所学习的理论知识,从而培养学生综合运用所学课程知识,分析解决问题的能力,培养学生理论联系实际作风,实事求是,严肃认真的科学态度和良好的工作作风,为今后从事科学研究工作打下基础。
实验要求软件工程实验具体要求如下:每个项目小组必须按照《软件工程实验指导书》附录中给定的文档规范标准提供项目文档;题目自定或采用附录二中的题目;软件开发的方法自定(结构化或面向对象的方法学)。
实验一用Visio进行功能分析和建模1. 实验目的掌握结构化分析的方法。
用例图实验报告一、实验目的本次实验的主要目的是通过绘制和分析用例图,深入理解系统的功能需求和用户与系统之间的交互关系,为系统的设计和开发提供清晰、直观的指导。
二、实验环境1、操作系统:Windows 102、绘图工具:StarUML三、实验内容(一)用例图的概念和作用用例图(Use Case Diagram)是 UML(统一建模语言)中用于描述系统功能的一种图形化工具。
它从用户的角度出发,展示了系统提供的一系列功能(用例)以及不同用户(参与者)与这些用例之间的关系。
用例图的主要作用包括:1、帮助开发团队更好地理解系统的需求和功能,明确系统的边界和范围。
2、作为与用户和其他利益相关者沟通的有效工具,便于他们直观地了解系统的功能和使用方式。
3、为后续的系统设计和开发工作提供基础,如确定系统的架构、模块划分等。
(二)绘制用例图的步骤1、确定参与者参与者是与系统进行交互的外部实体,可以是人、其他系统或设备。
通过对系统的需求分析,找出所有可能与系统交互的参与者,并为每个参与者赋予一个有意义的名称。
2、识别用例用例代表了系统能够为参与者提供的功能或服务。
从参与者的角度出发,思考他们在与系统交互过程中希望系统完成的任务,将这些任务确定为用例。
3、绘制用例图使用绘图工具,将参与者和用例分别用不同的图形元素表示,并通过线条连接参与者和与之相关的用例,以表示它们之间的交互关系。
同时,可以为用例图添加必要的注释和说明,以提高其可读性。
(三)实验案例分析以一个在线购物系统为例,绘制用例图并进行分析。
1、确定参与者顾客:购买商品的用户。
管理员:负责管理系统的人员,包括商品管理、订单处理、用户管理等。
2、识别用例顾客相关用例注册/登录浏览商品搜索商品查看商品详情加入购物车提交订单支付订单查看订单状态评价商品管理员相关用例商品管理(添加、修改、删除商品)订单处理(确认订单、发货、退款)用户管理(添加、修改、删除用户信息)3、绘制用例图(此处插入绘制好的用例图)通过对这个用例图的分析,可以清晰地看到在线购物系统的主要功能和不同用户与系统之间的交互关系。
实验二:建立动态模型一旦定义了一个工程的用例,就可以用它们来指导对系统的进一步开发。
用例的实现描述了相互影响的对象的集合,这些对象将支持用例所要求的功能。
给出系统用例的实现,是从外部视图转到内部结构的第一步。
在UML中,用例的实现用交互图来指定和说明。
交互图通过显示对象之间的关系和对象之间处理的消息来对系统的动态特性建模。
有两种交互图:序列图和协作图。
1、创建交互图的步骤交互图一步一步地显示用例的实现流程。
它包括流中需要什么对象、对象之间发送什么、什么角色启动流、消息按什么顺序发送等。
系统要求实现的所有不同情形都在交互图中记录。
通过从用例建模得到的用例文档说明、词汇表和用例图来创建交互图。
2、实例本节主要以选课系统中的选课用例(Select Course)为例,来学习序列图的设计与实现。
2.1 分析为了使问题更简单一些,不考虑学生的登陆。
假设学生已经成功登陆系统,选课的事件流如下:(1)学生进入选课主界面。
(2)学生点击选课。
(3)系统显示所有课程信息。
(4)学生选择课程。
(5)系统验证课程是否可选。
A1:课程不可选(6)系统提示课程选择成功,提示学生交费。
(7)用例结束。
A1:课程不可选(1)系统提示课程不可选及原因。
(2)学生重新选课。
(3)重新验证直至成功。
(4)转选课事件流第6步。
首先,查找Select Course用例的对象。
从事件流中发现涉及以下对象:(1)界面。
(2)课程。
(3)对于业务层的操作,也应该有对象进行处理。
(4)事件流中设计的角色有:学生、数据库。
然后,分析对象、角色之间交互的消息。
本用例主要有以下交互:(1)学生通过界面发送选课命令。
(2)界面向控制对象请求课程信息。
(3)控制对象向数据库发送查询数据消息。
(4)控制对象暂存数据库的查询结果。
(5)界面对象从控制对象中取得所有的课程信息。
(6)在界面上显示所有的课程信息。
(7)界面对象发送命令要求控制对象删除课程信息。
实验一UML建模基础一、实验目的1.熟悉UML建模工具Rational rose的可视化环境。
2.掌握利用Rational rose进行建模的步骤。
二、实验内容1.熟悉Rational rose建模环境(1)单击“开始—>所有程序—>IBM Rational—>Rational Rose Enterprise Edition”,启动Rational Rose建模环境,软件启动后产生如图1.1所示的建模模型窗口。
图1.1 Rational rose 启动提示界面(2)选项卡【new】用来选择新建模型时采用的模板。
单机【Details】按钮可以查看选中模板的描述。
【Existing】选项卡用于打开一个已经存在的模型。
【Recent】选项卡可以打开一个最近打开的模型文件。
如暂时不需要任何模板,只需要建立一个新的空白模型文件,单击【Cancel】按钮,显示Rational rose主界面,如图1.2所示。
图1.1 Rational rose主界面(3)主界面包含五大部分:导航窗口、绘图窗口、工具栏、文档窗口和日志窗口。
①导航窗口:用于在模型中迅速漫游。
导航窗口类似于windows操作系统的资源管理器,它以树形结构显示了模型中的所有元素,包括参与者、用例、类、组件等。
利用导航窗口可以:a)增加模型元素参与者、用例、类、组件、框图。
b)浏览现有模型元素。
c)浏览现有模型元素间的关系。
d)移动模型元素。
e)更名模型元素。
f)将模型元素加进框图。
g)将文件或UML链接到元素。
h)将元素组成包。
i)访问元素的详细规范。
j)打开图形。
图1.3 导航窗口导航窗口四个视图根结点。
a)用例视图(Use Case View):用于管理需求分析获取的所有用例、参与者和用例图。
b)逻辑视图(Logic View):分析和设计完成的所有制品(如类图、对象图、顺序图、活动图、状态图等)放置在逻辑视图中。
c)组件视图(Component View):逻辑视图中的类实现后成为软件的组件,可以放在组件视图中创建这些组件,并绘制组件图描述它们之间的依赖关系。
用例图设计实验报告1. 引言用例图是一种表示系统交互的图形化工具,它描述了系统中的角色、用例以及它们之间的关系。
用例图常用于需求分析和系统设计过程中,有助于明确系统功能和行为。
本实验旨在通过实际案例,了解用例图的设计过程和使用方法,并熟悉用例图的各种元素及其之间的关系。
2. 实验背景想象一个在线购物系统,我们可以将用户、商家和管理员作为系统中的角色,而登录、浏览商品、下单、支付等操作可以作为系统的用例。
通过用例图的设计,我们可以很清晰地了解用户和商家之间的交互以及各个用例之间的关系。
3. 实验过程及结果3.1 角色的确定在开始设计用例图之前,首先需要确定系统中的角色。
根据实验背景,我们可以确定用户、商家和管理员是系统中的角色。
3.2 用例的分析接下来,我们需要分析系统中的用例,以确定用户和商家与系统交互的动作。
通过与实际业务的对比分析,我们可以确定以下用例:1. 用户登录:用户在系统中登录的操作。
2. 用户浏览商品:用户在系统中浏览商品的操作。
3. 用户下单:用户在系统中下单购买商品的操作。
4. 用户支付:用户在系统中支付订单的操作。
5. 商家登录:商家在系统中登录的操作。
6. 商家发布商品:商家在系统中发布商品的操作。
7. 商家管理订单:商家在系统中管理订单的操作。
8. 管理员登录:管理员在系统中登录的操作。
9. 管理员管理用户:管理员在系统中管理用户的操作。
10. 管理员审核商品:管理员在系统中审核商品的操作。
3.3 用例图的绘制根据上述用例的分析结果,我们可以开始绘制用例图。
用例图由用例、角色和关系三部分组成,其中用例用椭圆表示,角色用方框表示,而关系用箭头表示。
下面是绘制的用例图示例:通过用例图的绘制,我们可以清晰地看到用户、商家和管理员之间的交互关系以及各个用例之间的依赖关系。
3.4 用例图的分析通过对用例图的分析,我们可以得出以下结论:- 用户和商家角色有一些相同的用例,如登录和浏览商品。
UML建模实验1. 环境简介Rose模型〔包括所有框图、对象和其他模型元素〕都保存在一个扩展名为.mdl的文件中。
1.1 Rational Rose可视化环境组成Rose界面的五大局部是浏览器、文档工具、工具栏、框图窗口和日志。
见图1-1。
图1-1:Rose界面●浏览器:用于在模型中迅速漫游。
●文档工具:用于查看或更新模型元素的文档。
●工具栏:用于迅速访问常用命令。
●框图窗口:用于显示和编辑一个或几个UML框图。
●日志:用于查看错误信息和报告各个命令的结果。
1.2浏览器和视图浏览器是层次构造,用于在Rose模型中迅速漫游。
在浏览器中显示了模型中增加的一切,如参与者、用例、类、组件等等。
Rose浏览器见图1-2。
浏览器中包含四个视图:Use Case视图、Logical视图、ponent视图和Deployment视图。
点击每个视图的右键,选择new就可以看到这个视图所包含的一些模型元素。
图1-2:Rose浏览器1.3框图窗口在图1-3所示的框图窗口中,我们可以浏览模型中的一个或几个UML框图。
改变框图中的元素时,Rose自动更新浏览器。
同样用浏览器改变元素时,Rose自动更新相应框图。
这样,Rose就可以保证模型的一致性。
图1-3:框图窗口2.UML各类框图的建立2.1建立用例图use case diagram从用例图中我们可以看到系统干什么,与谁交互。
用例是系统提供的功能,参与者是系统与谁交互,参与者可以是人、系统或其他实体。
一个系统可以创立一个或多个用例图。
创立用例图〔图2-1-1〕在浏览器的Use Case视图中,双击Main,让新的用例图显示在框图窗口中。
也可以新建一个包〔右击Use Case视图,选择new→package,并命名〕,然后右击这个新建包的,选择new→use case diagram。
对系统总的用例一般画在Use Case视图中的Main里,如果一个系统可以创立多个用例图,那么可以用包的形式来组织。
一、实验名称实验一用例图二、实验目的1.熟悉用例图的基本功能和使用方法。
2.掌握如何使用建模工具绘制用例图方法。
三、实验内容分析微商管理系统的需求建模,进行用例图的绘制。
四、实验步骤1.书写“用户登录购买商品信息”和“管理员管理商品”的书面用例1.1. (1)用户登录后,查找想要购买的商品;1.1. (2) “用户接口”组件数据库中,查找待购买的商品名;1.1. (3)如果不存在,则显示错误信息,返回步骤 (1),如果存在则继续;1.1. (4) “用户接口”组件判断“待购买商品”是否可以购买;1.1. (5)如果不可以,则显示出错误信息,返回步骤 (8),如果可以则继续;1.1. (6)在数据库中,添加商品订单;1.1. (7)显示购买成功信息;1.1. (8)结束1.2. (1)管理员登录后,查找的商品;1.2. (2) “业务对象”组件数据库中,查找待管理的商品名;1.2. (3)如果不存在,则显示错误信息,返回步骤 (1),如果存在则继续;1.2. (4) “业务对象”组件判断“待管理商品”是否可以管理;1.2. (5)如果不可以,则显示出错误信息,返回步骤 (8),如果可以则继续;1.2. (6)在数据库中,添加、删除或修改商品;1.2. (7)显示管理成功信息;1.2. (8)结束分析:在微商管理系统中,管理员首先登陆系统,系统验证过后,管理方可向系统查询数据,在查询后,系统会给出提示,有没有相关的数据,管理员根据系统查询的返回结果,进行下一步的操作,就是管理商品,在管理过程中,系统会对查询得到的结果判断是否可以对商品进行管理,若可以,则给管理提示,如不可以,也给相关的提示信息。
而用户则通过管理员所设置的商品信息进行查询,如果查询到相关信息,则系统给出用户可以进行购买操作的提示,如果未查询到相关信息,也给相关的提示信息。
2.1.根据实验指导书画出用户的用例图。
(1)添加一个用户用例(2)设置用户的属性:姓名,性别和用户 ID(3)设置用户的方法:选择商品和购买商品(4)绘制出用户所能进行的活动,并绘制他们之间的关系2. (1)添加一个管理员用例(2)设置管理员的属性:姓名,性别和管理员 ID(3)设置管理员的方法添加商品,删除商品和修改商品(4)绘制出用户所能进行的活动,并绘制他们之间的关系五、实验结论通过本次试验我学会了如何绘制出各个需求关系的用例图,掌握了基本的用例图使用方法。
实验二用例图
一、实验目的
1.熟悉用例图的基本功能和使用方法。
2.掌握如何使用建模工具绘制用例图方法。
3.学习使用Microsoft Project对题目进行进度安排。
二、实验器材
1.计算机一台。
2.Rational Rose 工具软件。
三、实验内容
根据实例,如“图书馆管理系统”开发进度,在完成对系统的需求建模,得到用例模型后,应针对每个用例进行业务分析,说明其具体的业务流程,现系统分析部指派您完成该项任务。
要求:
对其中主要功能的用例书写书面用例。
四、实验步骤
书写“删除读者信息”用例的书面用例。
一般应包含以下信息:
(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
(5)在绘出了用例后,接下来的是绘制参与者与用例实现,如图1.6所示。
图1.6
(6)根据步骤(5),同时完成如图1.7和图1.8。
此时,删除读者用例图就到此完成。
其系统查询读者信息等其他的功能会在时序图和活动图中描绘。
(7)根据分析情况,进一步添加或细化用例图。
图1.7
图1.8
五、实验报告要求
1.整理实验结果。
2.小结实验心得体会。
用例名称添加图书
标识符UC0001
用例描述图书管理员在收到新采购的图书后对之进行入库。
参与者图书管理员
优先级 1
状态通过审查
前置条件图书管理员登录进入系统
后置条件在库图书数目增加
基本操作流程1.图书管理员录入图书书目;
2.系统检查图书书目是否已存在;
3.系统为这本图书生成唯一书号(条形码);
4.系统添加新的图书书号。
可选操作流程系统检查图书书目不存在,系统添加新的图书书目;被泛化的用例无
被包含的用例无
被扩展的用例无
修改历史记录张三,定义基本操作流程,2009年3月20日
张三,定义可选操作流程,2009年3月20日。