用例模型

目　录 1. 引言 1 1.1. 背景 1 1.2. 参考资料 1 1.3. 假定和约束 1 1.4. 用户的特点 1 2. 功能需求 1 2.1. 系统范围 1 2.2. 系统体系结构（二层架构的系统可剪裁本小节） 1 2.3. 系统总体流程 2 2.4. 需求分析 2 2.4.1. XXXXXXX(功能需求名称) 2 2.4.1.1. 功能描述 2 2.4.1.2. 业务建模 2 2.4.1.3. 用例描述 3 2.4.1.4. 用户界面 5 2.4.2. XXXXXXX(功能需求名称) 5 3. 非功能需求 5 3.1. 性能要求 5 3.1.1. 精度 5 3.1.2. 时间特性要求 6 3.1.3. 输人输出要求 6 3.2. 数据管理能力要求 6 3.3. 安全保密性要求 6 3.4. 灵活性要求 6 3.5. 其他专门要求 6 4. 运行环境规定 6 4.1. 设备 6 4.2. 支持软件 7 4.3. 接口 7 4.4. 控制 7 5. 需求跟踪 7 6. 签批单 7 1. 引言 1.1. 背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.2. 参考资料 列出本说明书中引用和参考的资料，如： a．本项目的经核准的 计划任务书 或合同

UML各种图总结-精华 UML（Unified Modeling Language）是一种统一建模语言，为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。 一、基本概念　　 　　如下图所示，UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又可以静动分为静态视图和动态视图。静态图分为：用例图，类图，对象图，包图，构件图，部署图。动态图分为：状态图，活动图，协作图，序列图。 　　1、用例图（UseCase Diagrams）： 　　用例图主要回答了两个问题：1、是谁用软件。2、软件的功能。从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。 　　2、类图（Class Diagrams）： 　　　　用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。 在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。 　　　各种关系的强弱顺序： 泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖 　　2.1.泛化 　　　　【泛化关系】

4. 测试设计技术 2015-06-24 目录 4.1 测试开发过程 4.1.1 测试用例生命周期 4.1.2 测试用例的质量评估 4.1.3 测试用例的组织 4.2 测试设计技术的种类 4.6 选择测试技术 4.1 测试开发过程 [1] 返回 4.1.1 测试用例生命周期 测试条件标识：简单的说，就是确定测试什么？需求文档中的需求条目，我们可以认为是测试条件！ 测试用例设计：说明如何来识别测试什么(用白盒设计技术还是黑盒设计技术)？即如何详细识别需求中的测试条件！ 测试用例实现：得到的是详细的测试用例步骤！ 测试用例执行：是通过运行测试用例（自动或手动）来对系统进行测试！ 测试用例管理：是如何来组织、跟踪和维护测试用例过程！ 4.1.2 测试用例的质量评估 测试用例与系统需求（测试条件）之间进行关联，保证需求的可追溯性；测试用例包含明确的测试输出预期结果； 确定测试覆盖率 需求变更对测试设计和测试执行的影响 测试用例在发现缺陷方面的有效性； 4.1.3 测试用例的组织 按照软件功能模块组织； 按照测试用例的测试类型组织； 按照测试用例的优先级组织； 4.2 测试设计技术的种类 [1][2] 返回 基于规格说明的测试技术（黑盒测试技术）具有以下共同特点： 使用正式或非正式的模型来描述需要解决的问题、软件或其组件等； 根据这些模型，可以系统地导出测试用例。 基于结构的技术

为了支持业务层中的事务，我试图在Go中查找类似Spring的声明式事务管理，但是没找到，所以我决定自己写一个。 事务很容易在Go中实现，但很难做到正确地实现。 需求: 石头文学网 https://www.10tou.com 将业务逻辑与事务代码分开。 在编写业务用例时，开发者应该只需考虑业务逻辑，不需要同时考虑怎样给业务逻辑加事务管理。如果以后需要添加事务支持，你可以在现有业务逻辑的基础上进行简单封装，而无需更改任何其他代码。事务实现细节应该对业务逻辑透明。 事务逻辑应该作用于用例层（业务逻辑） 不在持久层上。 数据服务（数据持久性）层应对事务逻辑透明。 这意味着持久性代码应该是相同的，无论它是否支持事务 你可以选择延迟支持事物。 你可以先编写没有事务的用例，稍后可以在不修改现有代码的情况下给该用例加上事务。你只需添加新代码。 我最终的解决方案还不是声明式事务管理，但它非常接近。创建一个真正的声明式事务管理需要付出很多努力，因此我构建了一个可以实现声明式事务的大多数功能的事务管理，同时又没花很多精力。 方案: 最终解决方案涉及本程序的所有层级，我将逐一解释它们。 数据库链接封装 在Go的“sql”lib中，有两个数据库链接sql.DB和sql.Tx. 不需要事务时，使用sql.DB访问数据库; 当需要事务时，你使用sql.Tx. 为了共享代码，持久层需要同时支持两者。

为了支持业务层中的事务，我试图在Go中查找类似Spring的声明式事务管理，但是没找到，所以我决定自己写一个。 事务很容易在Go中实现，但很难做到正确地实现。 需求: 将业务逻辑与事务代码分开。 在编写业务用例时，开发者应该只需考虑业务逻辑，不需要同时考虑怎样给业务逻辑加事务管理。如果以后需要添加事务支持，你可以在现有业务逻辑的基础上进行简单封装，而无需更改任何其他代码。事务实现细节应该对业务逻辑透明。 事务逻辑应该作用于用例层（业务逻辑） 不在持久层上。 数据服务（数据持久性）层应对事务逻辑透明。 这意味着持久性代码应该是相同的，无论它是否支持事务 你可以选择延迟支持事物。 你可以先编写没有事务的用例，稍后可以在不修改现有代码的情况下给该用例加上事务。你只需添加新代码。 我最终的解决方案还不是声明式事务管理，但它非常接近。创建一个真正的声明式事务管理需要付出很多努力，因此我构建了一个可以实现声明式事务的大多数功能的事务管理，同时又没花很多精力。 方案: 最终解决方案涉及本程序的所有层级，我将逐一解释它们。 数据库链接封装 在Go的“sql”lib中，有两个数据库链接sql.DB和sql.Tx. 不需要事务时，使用sql.DB访问数据库; 当需要事务时，你使用sql.Tx. 为了共享代码，持久层需要同时支持两者。 因此需要对数据库链接进行封装，然后把它作为数据库访问方法的接收器。

测试方法的划分 一般的，从看不看代码来划分黑、白盒测试。看代码和内部接口称为白盒测试，否则是黑盒测试方法。 而从软件是否运行的角度来划分静态和动态测试。不运行代码是静态测试，反之就是动态测试。 那么从我们人来参与的角度来看人工测试和自动化测试的。 黑、白、灰盒测试 刚才说了，我们从看不看代码来划分黑、白盒测试。 那黑盒测试可以有静态测试和动态测试，也可以有人工测试和自动化测试。 当然，白盒测试也是一样的。 比如我们要测这个自动售货机。 我们投币然后得到饮料；或者刷卡、扫码等都能得到想要的饮料。 我们做黑盒测试就是测试投币相关的逻辑、选择饮料相关的逻辑，找零或其他的逻辑。 这是我们不管内部结构，只是根据一些数据测试输入输出，比如投币5毛钱，却能得到一瓶2.5的饮料，这就是bug了。 等等等..... 除此之外，我们还需要看内部代码的逻辑，比如如何处理银行和第三方支付的接口逻辑，本地的饮料存储、统计等，看看相关关联的数据之间的交互。这些都是白盒测试范畴。 在测试之前，我们要搞清楚被测对象应该是什么样的，然后实际做出来的和预期进行比较，这样就能及时的发现缺陷；根据被测对象不同，而采用不同的测试方法。 白盒测试 白盒测试是依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况。 白盒测试是基于程序结构的逻辑驱动测试。

级别: 初级 John Smith , 技术工程师 2005 年 1 月 01 日 本文描述了基于用例进行评估的一个框架。为了使描述更加具体，本文为框架的参数选择了一些值，尽管这些值有待于论证，但它们并不总是错误的。像往常一样，随着数据的搜集，这种估计应该根据实际情况和重新估计的参数值进行测试。这种框架对于不同种类的系统考虑了用例层次、规模和复杂度等思想，并且不再采取细粒度的功能分解。为减轻计算的负担，对于诸如 Estimate Professional 这样的工具，可以构建一个前端，从而提供一种基于用例的规模输入的不同的方法。 问题 直观上看起来似乎根据用例模型的特征，可以对开发工作所需的规模和工作量进行估计。毕竟，用例模型捕获了功能性需求，那么难道不应该有基于等价于功能点的用例吗？这里存在许多困难： 有许多不同的用例规格样式和形式，很难定义一个度量标准，例如，某人可能希望能够度量用例的长度； 用例应该代表外部参与者对于系统的观点，因此，500,000 sloc 系统的用例就与 5,000 sloc 子系统的用例在完全不同的层次上（Cockburn 97 讨论了层次和目标的概念）； 用例可能在复杂性方面不同，编写时是显式的，实现时又是隐式的。 用例应该从参与者的角度来描述行为，但是这可能相当复杂，特别是当系统具有状态时（绝大多数情况是这样的）。所以描述这种行为需要系统的模型

12.23 快考试了，要开始复习了。这学期学分绩还是比较重要的。加油，奥力给 一给洛！！ 大纲： 1. 软件过程核心思想 软件工程的两个映射 概念映射：问题空间的概念和解空间的模型化概念之间的映射 业务逻辑映射：问题空间的处理逻辑与解空间处理逻辑之间的映射 软件工程所关注的对象 产品 过程 软件工程所关注的目标 软件工程的核心思想： 分治，复用，折中，演化 软件过程模型 1. 瀑布模型 2. 增量模型 3.演化模型 快速原型法： 包括抛弃式原型和演化式原型 螺旋式模型 敏捷方法 极限编程：一种应用最广泛的敏捷开发模型 敏捷模型与其它模型的分析 软件项目管理 软件开发团队的组织方式 一窝蜂模式 ：没有明确分工，存活的时间一般都不长 **主治医生模式：**一个人带着其它人干 明星模式： 社区模式 ：linux操作系统的社区 交响乐团模式 ：门类齐全，各司其职 爵士乐模式： ： 功能团队模式： 官僚模式： 产品结构分解 ： 项目管理里通常使用产品结构分解作为产品分解的工具 产出物：项目结束时需要提交的最终产品，在项目之初就可以准确预计 项目关注的四方面： 范围，时间，成本，质量 项目管理的主要任务： 可行性分析，进度安排，分线管理，质量管理，项目跟踪与控制 可行性分析与估算： 在项目开始之前，至少i要预估： 需要多少工作量 需要多少时间 需要多少人员 从而得出该项目是否可行 确定范围 ：

我们应当怎样做需求分析？ 成功的软件项目都是一样的，失败的项目却各有各的问题。不过归根到底还是需求的问题。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。 只有深入地去理解客户的业务，最后做出来的东西必然是客户满意的。当客户提出业务变更的时候，一定不能被客户牵着走。要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。 客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。所以我们必须要基于技术实现去引导客户的需求。 软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。 在敏捷开发过程中，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。 我们应当怎样做需求调研？ 首先是双方初步认识，这个时候需要树立良好的职业威信，在交谈中进行详细角色分析，将与会各方代表对号入座，最后从宏观上制订目标与方案。 做好初步认识之后，接下来就要一一去拜访这些对应角色了。需求不是一蹴而就，在这漫长的时间里

在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency) 1. 泛化（ Generalization ） 【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。 【箭头指向】：带三角箭头的实线，箭头指向父类 　　　 2. 实现（ Realization ） 【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现. 【箭头指向】：带三角箭头的虚线，箭头指向接口 　　　　 3. 关联（ Association) 【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。 【代码体现】：成员变量 【箭头及指向】：带普通箭头的实心线，指向被拥有者 　　　　 上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。 下图为自身关联： 　　　 4. 聚合（ Aggregation