1.4.3替代流
E-1如果所选的书该书店没有存货，系统提示该书缺货无法购买，顾客可选择其他书进行购买；；
E-2如果所选的书数量超过该书店的所拥有的数量，则系统提示书的数量过多无法购买，并提示可选择少量进行购买。
五、分析与讨论
1.建模用例图的步骤、方法？ 1.寻找参与者寻找参与者
所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。 2.确定用例
找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。 3.描述用例规约
应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的. 4.检查用例模型
用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。
6
2.如何识别系统的参与者？
? 谁是系统的主要用户 ? 谁向系统提供信息 ? 谁改变系统的数据 ? 谁从系统获取信息
? 谁需要系统的支持以完成日常工作任务 ? 谁负责日常维护、管理并保证系统正常运行 ? 系统需要操纵那些硬设备 ? 系统需要和那些外部系统交互
? 谁（或什么）对系统运行产生的结果（值）感兴趣 ? 时间、气温等内部外部条件 ? ??
3.应该如何划分用例，应注意哪些问题？
1、使用功能点划分，细化每个功能点，到这个功能点不能再拆分。 2、所要测试模快对该系统的整体影响。看其重要性。
3、最好在用例编写前，项目的测试工程师可以讨论出一个适合项目的统一测试粒度。 应注意：
1、测试粒度不宜过细，测试用例分解的测试粒度过细会给测试工程师带来成倍的额外工作量，对于项目管理来讲，这样是不合算的。
2、测试粒度不宜过粗，这是因为如果一个测试用例，里面包含了太多验证点。比如在写取钱的用例时，要检查余额查询，用户最大额度查询类似的本可以单独一个用例的东西都硬拼到了一起，那么用例的执行进度和项目的进度肯定不能划等号。简单说就是有的用例简单有的用例复杂，所以有的也许要验证半天，有的只需要10分钟。这样的话，文章开头的等式就当然不相等了。
粒度过粗还有个麻烦就是，发现很多bug都对应着一个用例。这样给缺陷管理和统计起来也带来麻烦。在项目后期的报告中不能清晰的统计缺陷。
7
4.．心得
我认为，用例就是功能，用例图就是对功能的图示描述；也就是功能模块的表示。同时用例图是对用户的需求进行描述，所以，从用例图中能看出现实的功能需求，貌似是对现实世界想要完成某件事情的物理结构进行画图表示。用例图的粒度是第一次听说，经过老师的讲解，感觉粒度就是个数的意思，搞不懂为什么翻译为粒度（granularity）。也就是一个软件划分为多少个模块。这就涉及到模块的耦合和内聚了。模块太少不能把用户的需求功能描述清楚，太多了，又过于冗杂，同样不能把功能描述清楚。 用例图是开发一个软件时用到的第一个图，所以，UML用例图画好了，对后面的开发至关重要。用例图就是对现实需求的第一步抽象，把功能用图表述出来。在画用例图的时候就应该把用各个用例之间的关系表达清楚。
8
实验二 类图
一、 实验目的
了解类图的基本用法；初步掌握UML类图的创建及其方法。
二、实验要求
1、结合工具StartUML，熟悉UML类图的模型元素。 2、建模网上书店类图。
三、实验主要设备：台式或笔记本计算机 四、实验内容：
创建类图的步骤如下： （1）使用名词识别法识别类。 （2）建模类与类之间的关系。
（3）为类图中的关联关系添加合适的角色名。 （4）为已被封装到类中的独立功能建模类。 （5）为类图中的类添加必要的特性和操作。 （6）迭代并细化该模型
1.识别类：（删除以下样式 ， 填写）
顾客（普通顾客，会员），书店工作人员，虚拟购物车，图书（特价图书）
2. 定义类：（删除以下样式 ， 填写）
9
书店工作人员订单1...n顾客虚拟购物车0...n普通顾客会员特价图书图书
图 2.1 定义类
书店工作人员+姓名+性别-年龄订单+订单号+订单日期+查看订单()+处理订单()顾客1...n+姓名+性别+订购图书()+付款()虚拟购物车+管理图书()+提交订单()+取消订单()0...n普通顾客+姓名+性别+查看资料()会员+姓名+性别+保留个人信息()+保留购买记录()特价图书+书名+价格图书+图书编号+书名
图2.2完善后的类图
10