1、软件的特性1. 软件是一种逻辑实体，而不是具体的物理实体。它具有抽象性2. 软件的开发设计、生产、维护与硬件不同3. 在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题4. 大多数软件是定制的5. 软件的开发和运行常常受到计算机系统的限制对计算机系统有着不同程度的依赖性6. 软件开发至今尚未完全摆脱手工艺的开发方式7. 软件是复杂的8. 软件成本相当昂贵9. 相当多的软件工作涉及到社会因素软件危机的表现 、原因软件危机-主要表现：1. 对软件开发成本和进度的估计不准确2. 用户不满意3. 软件质量不高、可靠性差4. 软件常常不可维护、错误难以改正5. 缺乏适当的文档资料6. 软件成本占系
2、统总成本的比例逐年上升（1985-90%）7. 软件开发速度跟不上计算机发展速度归结为主要为三方面-“时间、成本、质量”软件危机-原因：1. 软件规模日渐庞大（数量、功能、成本、质量、时间）2. 软件开发管理困难。逻辑部件而不是物理部件。在写出程序代码并在计算机运行之前，软件开发过程的进展情况较难衡量，软件开发的质量也较难评价。因此，管理和控制软件开发过程相当困难。3. 开发人员错误的观念、方法和技术重编程、轻需求。生产方式落后：个体手工方式。开发技术落后开发工具落后4. 忽视软件开发前期的需求分析 5. 开发过程缺乏统一的、规范化的方法论的指导6. 文档资料不齐全或不准确7. 忽视与用户之间
3、、开发组成员之间的交流8. 忽视测试的重要性9. 不重视维护或由于上述原因造成维护工作的困难10. 需求变化预料不足用例归约用例规约-进行用例阐述用例规约：更进一步的精度用例文档的核心，而用例图作为用例文档的总图进一步的精度：有层次的文档文档中每一句话都有其价值用例规约组成1. 用例名称：处理销售2. 用例标识3. 涉及的参与者4. 涉及的用例5. 描述6. 用例的规格说明前置条件 与 后置条件 正常事件流备选事件流7. 其它非功能需求、设计约束、尚存在的问题举例(非正式型 )处理退货主要成功场景：顾客带着商品到收款处退货，出纳员使用 POS 终端记录每一件被退回的商品。 。 。 。可选场景：
4、如果系统中找不到商品标识，那么就通知出纳员并建议他手工输入商品标识码（或许商品的标识已经破损） ；如果系统检测到和外部税金计算系统之间的通信失败，那么就。 。 。正式型1. 用例 UC1：处理销售2. 主要参与者：出纳员3. 受益人及其利益：1) 出纳员：需要精确、快速的输入，并且不出现支付错误2) 销售人员：需要销售款得到更新3) 顾客：需要购买并花费最小的精力得到快速的服务，并需要支持退货功能4) 公司：需要精确地记录交易并满足客户的利益。需要支付授权服务记录可接受的支付。需要一些容错功能。需要账目和存货清单得到自动的快速更新5) 政府税务机构：需要从每一次销售中收税。6) 支付授权服务：
5、需要用正确的格式和协议传来的数字授权请求。需要精确计算它们可支付给商店的款额4. 前置条件：出纳员需要身份识别并授权5. 后置条件：存储了销售情况，正确地计算了税金，更新了账目和存货清单，记 录了销售额，打印了收据6. 主要成功场景：1) 顾客带着商品到 POS 终端出准备购买2) 出纳员开始一次新的销售3) 出纳员输入商品标识码4) 系统记录销售的商品并给出商品的描述、单价和折扣，并根据某些价格规则计算所应付的款额。出纳员重复步骤 3 和步骤 4，一直到处理完所有商品为止。5) 系统给出所应支付的总款额并计算税金6) 出纳员告诉顾客总价并请求付款7) 顾客付款，系统处理支付8) 系统记录下已
6、完成的销售，并将销售和支付信息发送给外部的账目系统以及存货清单系统9) 系统打印收据10) 顾客带着收据和商品离开类与类图类及类之间的关系案例李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。发现类李小平 是一个爱书之 人
7、 ， 家里 各类 书籍 已过千册，而平时又时常有 朋友外借，因此需要一个 个人图书管理系统 。该系统应该能够将书籍的 基本信息按 计算机类 、 非计算机类 分别建档，实现按 书名 、 作者 、 类别 、 出版社 等 关键字 的组合查询 功能 。在使用该系统录入 新书籍 时 系统 会自动按 规则 生成 书号 ，可以修改 信息 ，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行 记录 ，可对 外借情况列表 打印。另外，还希望能够对书籍的 购买金额 、 册数 按 特定时间周期 进行统计。 筛选备选类 “李小平” 、 “人” 、 “家里”很明显是系统外的概念，无须对其建模； 而“个人图书管
8、理系统” 、 “系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模； 很明显“书籍”是一个很重要的类，而“书名” 、 “作者” 、 “类别” 、 “出版社” 、 “书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。 “基本信息”则是书名、作者、类别等描述书籍的基本信息统称， “关键字”则是代表其中之一，因此无需对其建模； “功能” 、 “新书籍” 、 “信息” 、 “记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；筛选修
9、选类 “计算机类” 、 “非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍” ，以减少歧义； “外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表” ，而外借情况中一个很重要的角色是“朋友”借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录” ，而将“外借情况列表”改名为“借阅记录列表” ； “购买金额” 、 “册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的
10、范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类书籍列表，也就是执行统计的主体。得到候选类在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无需太过咬文嚼字 关联分析建模多重性分析建模职责分析 书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。 书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是新增、修改、查询（按关键字查询） 、统计（按特定时限统计册数与金额） 。 借阅记录类：借阅人（
11、朋友） 、借阅时间。 借阅记录列表类：主要职责就是添加记录（借出） 、删除记录（归还）以及打印借阅记录 顺序图 定义：也可叫作序列图、时序图 Sequence Diagram 以可视化方式为系统中逻辑的流程建模，通常用于（用例）分析和设计阶段。 描述对象是如何交互的，即描述消息如何在对象间发送和接收。 纵轴时间、横轴对象 描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序 显示了交互的参与者以及参与者之间的消息顺序，也显示了系统为了执行全部或部分用例而与参与者交互。 注意：一个事件流一个顺序图顺序图示例-还书顺序图示例-POS 机软件测试白盒测试1) 也称玻璃盒测试建立在对程序的结构和
12、语句的了解，以及对程序代码内部结构的了解的基础上2) 测试覆盖率3) 测试的目标4) 两种测试方法 控制结构测试条件测试数据流测试循环测试 基本路径测试测试覆盖率 采用白盒法进行测试时，考虑的是测试用例对程序内部逻辑的覆盖程度。 最彻底的白盒法是覆盖程序中的每一条路径，但这往往大到无法实现。 因此采用其它一些标准来量度覆盖的程度，并希望覆盖程度尽可能高些。条件测试错误原因布尔运算符错误布尔变量错误布尔括号错误关系运算符错误算术表达式错误策略分支测试：每个分支至少执行一次域测试：为每个关系运算符使用 3-4 个用例白盒测试的目标黑盒测试黑盒测试定义又称功能测试或数据驱动测试，主要关注软件的整体功能已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求要在软件的接口处进行，不考虑程序内部的逻辑结构和内部特性发现错误类型是否有不正确或遗漏的功能界面错误输入能否正确地接受，能否输出正确的结果是否有数据结构错误或外部信息（如数据文件）访问错误性能上是否满足要求是否有初始化或终止性错误
