06用例描述

UML系统建模基础教程文档名称：校园兼职管理系统1、需求分析：校园兼职系统的产生是因为大学生在校时间充裕，对便捷又小量的兼职需求日益增多，其次学生之间需要寻求帮助的问题，比如回家拼车、快递拿取、寻求观众、宣传活动、互助补课等都面临一些问题。

因此，创建一个很好的互助平台是极为需要的。

校园兼职管理系统是面向高等院校的本校学生，为学生群体中提供一个资源共享平台，为需要兼职的学生提供一个安全便捷的渠道，既可以赚取外快又安全快捷，既不需要面临很大的工作量，服务对象都是学生，真正实现学生之间的互助和沟通。

校园兼职系统的功能需求性包括以下内容：（1）学生通过该平台浏览兼职信息，然后提交申请后，要完成兼职任务，如果按规定完成兼职任务就提交完成确认。

学生还可以发布兼职信息，当有人接单并完成，调取订单详情核对完成情况，然后进行支付。

如果对接单者的完成情况不满意可以申请投诉。

（2）支付完成后，接单学生会受到已支付通知。

（3）管理员负责用户管理，进行注册的客户进行信息审核或者删除用户操作。

或对投诉信息进行处理，包括对用户发出警告或者注销用户操作。

对提交的订单和招聘信息进行审核、发布、管理，然后消息通知。

2、系统用例模型2.1参与者分析（1）学生（Students）。

校园兼职系统的服务对象是高等院校的学生，学生通过该系统进行浏览兼职信息和申请接单。

还具有提交招聘兼职信息给管理员。

（2）管理人员（Administrators）。

管理人员负责用户管理和投诉处理。

对学生提交的招聘信息进行审核、发布、管理。

（3）数据库（Database）。

存储用户信息，还有所产生的订单进行存放。

2.2用例图模块2.2.1学生用例图图1 学生用例图支付费用2.2.2管理员用例图警告用户行为注销用户图2 管理员用例图3、创建系统静态模型3.1参与者的实体类Students类：学生类Administrators类：管理者Database类：数据库2.边界类2.1 Students边界类Register类Apply类Check_order类Complaint类Manage orders类Order record类Release类User management类Handling类Notice类Sign in类Order query类Order类MainWindow类3控制类QueryStatusWindow Payment类InputOrderWindow类2.2.3系统类包图图3 校园兼职管理系统类的包图4.系统类图图4 系统类图4、创建时序图 4.1登录顺序图图5 登录时序图1）学生登录工作流程(1) 学生登陆时要先注册，先进入Register 注册界面，inputinfomation 填入个人信息。

订单状态测试用例订单状态是指在购物或交易过程中，订单所处的不同状态，包括待确认、待支付、待发货、已发货、已收货等。

各个状态的变化依据不同的订单流程和商家政策而有所不同，下面将分别描述并给出相应的测试用例。

1.待确认状态：待确认状态一般指商家需要确认订单后方可进行后续的操作，如确认收到订单、确认库存等。

以下是一些测试用例：-输入不存在的订单号，应该提示订单不存在。

-输入已被取消的订单号，应该提示订单已被取消。

-输入异常订单号，如字母、特殊字符等，应该提示输入有误。

-输入已确认的订单号，应该提示订单已确认。

2.待支付状态：待支付状态是指买家已提交订单，但尚未支付。

以下是一些测试用例：-输入无效的支付信息，如错误的银行卡号、过期的信用卡等，应该提示支付信息有误。

-输入无效的支付密码，如错误的密码、超过最大尝试次数等，应该提示支付密码有误。

-输入已支付的订单号，应该提示订单已支付。

3.待发货状态：待发货状态是指商家已收到订单款项，准备发货。

以下是一些测试用例：-输入物流单号，应该成功录入物流单号。

-输入错误的物流单号，应该提示物流单号有误。

-输入已发货的订单号，应该提示订单已发货。

4.已发货状态：已发货状态是指商家已经将订单商品发出，等待买家收货。

以下是一些测试用例：-输入收货地址，应该成功录入收货地址。

-输入错误的收货地址，应该提示收货地址有误。

-输入已收货的订单号，应该提示订单已收货。

5.已收货状态：已收货状态是指买家已经收到订单商品。

以下是一些测试用例：-输入申请退款的原因，应该成功申请退款。

-输入评论内容，应该成功提交评论。

-输入已退款的订单号，应该提示订单已退款。

总结而言，订单状态测试用例主要关注订单的核验、支付、发货、收货等关键流程，并针对每个流程中的正常和异常情况进行测试，确保订单状态的正确转换和相应操作的准确性。

UML各种图例——用例图、类图、状态图、包图、协作图、顺序图面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.∙决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.每个类图包括类，关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型. dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。

测试：安装测试⽤例安装测试⽤例1. 启动安装程序序号01功能描述测试⾃动启动安装程序⽤例⽬的测试系统是否能够⾃动启动安装程序测试类型安装测试前提条件程序的安装⽂件已经存在安装盘，电脑安装了CD-ROM或其他光驱测试⽅法与步骤输⼊插⼊系统的安装盘期望输出电脑能⾃动播放安装盘的内容测试结果根据程序的具体情况，如果存在安装盘的就可进⾏这个测试⽤例。

功能完成是□否□序号02功能描述测试安装程序⽤例⽬的测试系统是否能够在CD盘中突出显⽰setup.exe⽂件，双击该⽂件启动安装程序测试类型安装测试前提条件程序的安装⽂件已经存在安装盘，电脑安装了CD-ROM或其他光驱测试⽅法与步骤输⼊ 1. 插⼊系统的安装盘，2. 选择打开⽂件，期望输出在⽂件夹中能突出显⽰setup.exe⽂件，不要将安装的setup.exe⽂件放到难以找到的⽂件夹下，双击该⽂件能启动安装程序测试结果根据程序的具体情况，如果存在安装盘的就可进⾏这个测试⽤例。

功能完成是□否□序号03功能描述测试安装程序⽤例⽬的直接复制安装程序到电脑上测试类型安装测试前提条件软件的安装程序已经打包，并拷贝到要安装的电脑上测试⽅法与步骤输⼊直接双击安装程序setup.exe 期望输出能成功启动安装程序测试结果正常，能正确进⼊安装程序的页⾯功能完成是□否□2. 安装步骤界⾯序号04功能描述检查每个安装步骤页⾯提⽰信息明确，并没有⼆意性⽤例⽬的测试安装过程中的步骤页⾯上的提⽰信息是否明确，⽆歧义测试类型安装测试前提条件进⼊安装程序测试⽅法与步骤输⼊根据安装程序的提⽰信息安装程序期望输出能根据提⽰信息安装程序，页⾯上的提⽰信息明确，没有歧义，1. ⽆异常出现2. 所有的⽂字可以正常显⽰（⽆截断）3. 界⾯上的版本信息，公司信息（图标，时间，地址等）正确4. 许可证协议信息完整、正确测试结果正常。

功能完成是□否□序号05功能描述查看在安装过程中存在的提⽰信息的正确性、意思明确⽤例⽬的测试在安装过程中如果存在提⽰信息的话，提⽰信息是否正确、意思明确测试类型安装测试前提条件安装过程中存在提⽰信息测试⽅法与步骤输⼊根据安装过程中存在的提⽰信息，⽐如安装过程中如果⽤户将程序安装在系统中没有的⽬录下，程序会给予提⽰信息“系统中没有这个⽬录，是否新建⽬录，并将程序安装在这个新⽬录下？”期望输出如果⽤户选择“是”，那么会在系统的相应⽬录下新增⽤户新建的⽬录，在安装完成后，在这个新建的⽬录中能查看到程序的安装⽂件信息；如果⽤户选择“否”，那么安装向导提⽰⽤户重新选择⽬录安装程序。

软件需求分析中的用例模型软件开发是现代科技的重要表现形式，而软件需求分析是软件开发的第一环节。

软件需求分析的主要任务是将用户需求转化为软件所需功能的详细规格说明，这些规格说明成为软件开发中的基准标准，同时也是软件测试的基础。

需求分析有很多方法，用例分析是常用的一种。

用例是针对某一特定场景下的系统行为、功能、性能等的具体描述，它从用户的角度出发，描述了用户与系统之间的交互过程。

本文主要介绍在软件需求分析过程中的用例模型。

一、用例的定义用例主要是用来描述软件的功能以及用户与软件的互动过程。

用例模型是一种面向对象的需求分析方法，它把用户使用系统的一组典型路径描述清楚，并通过文档的形式来呈现这些标准路径，让开发人员和客户都能够理解。

用例模型的主要作用在于记录与评审需求、澄清需求和确认需求。

二、用例模型构建过程用例模型的构建过程可以分为以下几个步骤：1、识别参与角色：用例模型最基本的概念就是参与角色，用户就是用例模型中的参与角色之一，系统管理员、客户或其他用户等也是用例模型的参与角色。

用例模型的构建需要准确地识别并区分参与角色。

2、确定用例：用例是由一系列的动作和反应组成的流程，需要通过观察用户与系统的交互，并记录下来，以便将来进行分析。

在用例构建过程中需要考虑应用场景、功能需求以及业务规则等因素。

3、撰写用例：用例的撰写需要遵循一定的规范，一般情况下用例会包括一个简要的描述、用例步骤和用例结束时需要达到的状态等信息。

撰写好的用例需要经过严格的问题验证与测试操作，以保证其描述的准确性。

三、用例模型的应用用例模型不仅可以用于需求分析，还可以用于测试与开发过程中，如下图所示：图1 用例模型在需求分析、测试与开发中的应用在需求分析中，用例模型可以协助开发人员更好地了解用户需求，并且设计满足用户需求的软件系统。

在开发过程中，通过回顾用例模型可以评估软件的质量和性能，找出潜在的问题并进行修正。

而在测试过程中，用例模型可以作为测试计划的一部分，并且可以作为测试人员在测试过程中的参考依据。