用例模型

软件工程项目这周要交一个设计文档，其中涉及UML图的画法，根据上课给的ppt做一个记录。 有关于UML的介绍在这里不再赘述，直接开整！ 当然必要的介绍必不可少，这里先介绍UML的基本模型，之后的介绍将按照下图的顺序进行。 之后简单介绍一下面向对象的程序设计原则。这部分是我对之前知识的一个复习，想看UML的朋友可以直接跳到下一章。 瀵硅薄 对象是包含现实世界物体特征的抽象实体，它不仅表示具体的事物，还可以表示具体的规则或者事件。举个例子，公费医疗报销系统中的报销用户就是一个对象。 对象具有 ״̬ ，也就是对象还拥有 属性 。举例来说，报销用户有姓名、年龄、单位等等状态。 对象中还包括 操作 ，我们称之为 方法 ，操作用来改变对象的状态。举例来说，报销用户中的操作可能是对自己个人信息的修改。 对象大体可以分为5类：分别是物理对象，角色，事件，交互和规格说明。 物理对象 多表示现实生活中最容易被抽象的对象，比如报销系统中的某个单位的学生或者老师就是物理对象； 角色 举例来说，报销系统中，某个单位的学生老师的角色都是报销用户。 事件 这里的理解不太确定，个人理解是事件对象的作用是对出现的事件相关的状态进行存储，以便后续操作中读取。 交互 交互表示两个对象之间的关系。它的实际应用是在实体之间是多对多的关系时，使用交互对象可以简化为两个一对多的关系。个人理解

Unified Modeling Language (UML)又称统一建模语言或标准建模语言，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。 UML分类 （1）静态模型（系统结构）： 用例图、类图、对象图、构件图、部署图 （2）动态模型（系统行为）：状态图、活动图、顺序图、协作图 UML中有4种事务： （1）结构事务：名词、静态部分、物理元素。 （2）行为事务：动词、动态部分、行为。 （3）分组事务：包。 （4）注释事务：注解。 用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图，用于需求分析阶段。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。 用例之间的关系 （1）包含 (include) 关系 父用例包含子用例，父用例执行，子用例必然被执行 当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行

用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。参与者和用例由对功能性需求的分析来确定，用例图是参与者和用例的可视化表示。用例图中的四种关系： 　　1.关联：建立参与者与用例通信的渠道，当然关联可以是双向的，可以是单向的。箭头的方向表示消息的传递方向。 　　2.依赖：一个用例受到另一个用例的影响。 　　3.包含：基USE CASE图本用例的行为包含了另一个用例的行为 　　4.扩展：扩展用例是基本用例的一个扩展 　　5.泛化：存在于Actor和Use case之间，例如数学老师是老师的泛化，从特殊指向一般。 用例建模的作用： 用例模型是一种标准的语言，是开发人员之间交流和沟通的媒介，可以精确地定义软件需求，出现歧义的可能性很小，这可以保证用户和开发人员对需求理解的一致性。用例模型在整个开发过程中都扮演着非常重要的角色，它可以驱动软件的分析和设计逐步细化。最后，测试过程中那些关注软件功能的测试用例，往往也是根据用例模型来确定的。 用例步骤： 确定系统边界 确定参与者 找出所有的用例 确定每个用例的级别 撰写用例的文字描述 画出以整个系统为对象的顺序图 我的工程实践的目的是手势识别，模拟键盘鼠标操作等，下图展示了项目的部分用例图。只是手势交互业务建模，不是对系统建模。 　　　　　　　　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　　　　

接口测试的流程 　　接口测试也是属于 功能测试 ，所以跟我们以往的功能测试流程并没有太大区别，测试流程依旧是：1.测试接口文档（需求文档） 2.根据接口文档编写 测试用例 （用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法） 3. 执行测试，查看不同的参数请求，接口的返回的数据是否达到预期。 接口测试和功能测试一样，流程也大致遵守V模型，请看下图 为什么要写用例 理清思路，避免漏测和重复测 提高测试效率 跟进测试进度 告诉领导做过 跟进重复性工作 更好的记录问题，发现问题，复现问题 同时这也是是接口测试流程中的一个产物（测试用例） 　　上面七点，结合自己测试实际经验，应该来说是很好理解和认同的。有用例，自己做到心中有数，不要一个测试点重复测好多次，就有思路，避免漏掉测试点。跟着用例测试，避免随机测试那种没有目的性的测试，提高测试效率。有用 例，上级问你完成的进度，你好用数据回答。有用例，用来标记你执行的结果，证明你做过测试。避免将来发生问题，人家说你没有测试，有数据和证据说话。有用例，测出问题你可以根据用例将问题轻而易举的浮现出来，不至于等你反馈或 者复现的问题时，你忘记是如何操作才回出现问题。接口测试也需要重复跑，跑几轮，或者用自动化天天跑。这样的重复性工作，用例可以保证每次重复做的是一样的情况。 接口主要设计用例点 主要从四个方面来设计接口用例：功能

我的工程实践是印章检测，通过生成含有印章的文本图像，使用适合的目标检测算法训练模型，再利用训练好的模型检测出印章的位置以及类别。Include为用例之间包含关系，extend为用例之间扩展关系。 1. Abstract use case 首先针对项目进行分析，得到的抽象用例有：生成数据集、检测目标和显示结果。 生成数据集：生成数据集是整个项目的基础，需要在数据集上对模型进行训练。 检测目标：在训练好的模型上，对一个新输入的图片进行检测，识别是否有相关的印章 显示结果：对于识别到的印章，显示其分类 2.用例图 3. High Level use case 在不同的抽象用例中，需要对用例进行进一步的分析，得到高级用例。如生成数据集，它包括了“选择背景”和“选择印章”两项用例，这些都是对生成数据集进一步的细分。 4. Expanded use case分析 生成图片：是对生成文本行的扩展，将生成的文本行转成图片。 加噪图像：对图片进行加噪，这样才可以在之后的模型训练中让模型的泛化能力更强。 处理图像：图像在训练之前可以统一图像大小、分辨率，从而使训练速度加快。 分析准确率：通过对准确率进行分析来判断模型的性能，可以作为微调模型的依据。 来源： https://www.cnblogs.com/yll333/p/11762508.html

我的工程实践的题目是基于OpenGL ES 2.0的车载虚拟表盘软件的开发，是一个纯开发的项目，这个软件主要是面向房车的用户，因为这款软件的功能包括控制车载系统的灯光，有睡眠，夜晚，日常等模式，还有显示电压和水压，包括车内外温度等信息最后在界面上面显示出来。对于此次工程实践我选择用例建模： 用例建模的定义 ：用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者（抽象成为Actor），这些使用者与被定义系统发生交互；针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。 用例建模的主要步骤 ： 确定业务参与者——可以是与系统有交互的外部硬件、软件、组织、人等。 确定业务需求用例——参与者需要系统提供的完整功能。 创建用例图——标识参与者与用例之间、用例与用例之间的关系 1.抽取Abstract use case 此次工程实践的项目通过用例建模得到的Abstract use case为 主题选择、语音控制、灯光控制、车内信息管理、异常报警。 2.用例图 3.High level use case

　 　我的工程实践题目是基于情感词典的文本情感分析，下面是以我的工程实践为例，对业务进行建模的用例图。由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。Include为用例之间包含关系，extend为用例之间扩展关系。 　　我的工程实践主要是以购物评论作为数据集进行分析。对购物评论进行情感分类，就是按照评论文本所表达的情感倾向进行分析、处理、归纳和推理 ，判别评论中用户想要表达的观点 、喜好、感受以及对商品或者商家服务的态度 ，进而为用户提供更有效和更可靠的商品信息，辅助用户做出合理的决策，提高网上购物效率和服务质量。目前，针对评论文本情感分类的研究主要是将购物评论分为两类，即正向情感评论和负向情感评论。也有部分研究是将其分为三类，即正向情感评论、负向情感评论和中性情感评论。购物评论的情感分类研究属于文本情感分类研究的一个分支。 主要的高级用例（High level use case）为获取数据集，构建情感词典，情感分析。 获取数据集Expanded use case：爬虫抓取，通过API接口获取，以及下载公开数据集。 构建情感词典Expanded use case：使用的是一种基于情感词典与机器学习中 SVM 分类技术相结合的电影评论文本情感分析方法。首先，构造基础情感词典、领域情感词典、否定词词典和程度副词词典

在软件测试过程中，一个成熟的团队一般都有自己的公共测试用例库。公共测试用例库即可复用的测试用例库。今天我们就讨论一下如何开发有效的可复用测试用例，并学会如何使用和管理。 一. 可复用测试用例的开发 测试用例是为了验证最小功能点的一组输入、输出及操作序列的集合。可复用测试用例是指“为了复用目的而设计的测试用例”。复用的意义在于通过可复用测试用例验证功能相同或相近的模块，加快测试用例的设计进度、减少测试人员的负担；也可以帮助产品在设计类似功能时的需求细节补充；还可以与开发人员达成协议，后期在开发类似功能的时候，可以事先有一个既有的标准，提高开发效率和代码质量； 1. 可复用维度分析 为高效使用可复用测试用例，测试用例的复用性可从三个维度分析： 1)时间角度：使用以前软件版本的测试用例作为新版本测试用例的基础，可作为软件维护和回归测试时复用。 2）通用角度：以某平台或硬件为基础的软件，测试其平台特性的测试用例可以复用。如测试B/S结构网络应用产品，针对该网络结构数据传输安全的测试用例基本都可以复用。 3）应用角度：以某特定领域模型为基础构建的测试用例，在同一领域不同应用系统中的测试过程中可以复用。 2. 可复用测试用例的质量特性 为构建高质量的可复用测试用例，需要规定可复用测试用例的本质特征，即对其质量特性进行分析。本文基于ISO9126质量模型和ISO9241标准

1、一般的ERP系统设计大概包括以下几方面： 功能测试 、业务流程测试、数据逻辑测试、接口测试、兼容性测试、 性能测试 、易用性测试、用户体验测试等等； 2、ERP系统测试用例分为几类来写比较好：功能用例、业务流程用例、数据逻辑用例、接口用例， 最好是把功能与流程类的测试用例分开来写； 测试用例应该从以下几个方面入手： 一、功能用例设计：相对而言比较简单，根据需求规格说明书、界面原型提取测试功能点/项， 运用等价类、边界值、错误猜测、正交表等基本用例设计方法来设计； 需要根据文档/功能点/业务的变化进行修订/细化用例，提高功能用例的覆盖度； 如：身份证输入文本框，需要用到等类、边界值等方法，需要考虑15位和18位的身份证，需要考虑末位为字母的情况等…… 二、业务流程用例设计：关键在于理解实际业务、实际应用场景，最常用的操作过程和使用方法，必要时还要考虑操作习惯； 首先，需要结合业务模型或业务流程图，同需求分析人员、业务专家共同确认实际业务流程/运用场景，整理清楚最基本最常用的业务流程和应用场景； 接着，理清用例设计思路，画出用例设计流图，确定流程用例模板和风格； 然后，运用场景法、数据流程设计法、基本路径等方法设计业务流程用例； 1、简单模块流程单一，无分支或者分支少，用例设计也比较容易，根据业务流程设计测试数据； 2、复杂模块/子系统/系统，必定会存在多个分支

背景 此微博，引发了朋友们的大量讨论：赞同者有之；批评者有之；当然，更多的朋友，是希望我能更详细的解读C/C++ Volatile关键词，来佐证我的微博观点。而这，正是我写这篇博文的初衷：本文，将详细分析C/C++ Volatile关键词的功能 (有多种功能)、Volatile关键词在多线程编程中存在的问题、Volatile关键词与编译器/CPU的关系、C/C++ Volatile与Java Volatile的区别，以及Volatile关键词的起源，希望对大家更好的理解、使用C/C++ Volatile，有所帮助。 Volatile，词典上的解释为：易失的；易变的；易挥发的。那么用这个关键词修饰的C/C++变量，应该也能够体现出”易变”的特征。大部分人认识Volatile，也是从这个特征出发，而这也是本文揭秘的C/C++ Volatile的第一个特征。 Volatile：易变的 在介绍C/C++ Volatile关键词的”易变”性前，先让我们看看以下的两个代码片段，以及他们对应的汇编指令 (以下用例的汇编代码，均为VS 2008编译出来的Release版本)： 测试用例一：非Volatile变量 b = a + 1;这条语句，对应的汇编指令是：lea ecx, [eax + 1]。由于变量a，在前一条语句a = fn(c)执行时，被缓存在了寄存器eax中，因此b = a + 1