用例模型

我的工程实践项目是面向大数据分析的成绩预判系统，在日常学习过程中产生的大量数据（期中考试成绩、多次实验分数等）及相关学生的评价信息，并通过有效的数据分析技术可以对教学过程提供有益的决策支持。 1.抽取Abstract use case 根据成绩预判的工作流程，我将其分为三部分：获取数据，创建模型和进行预判 2.确定用例范围High level use case 获取数据用例包括获取日常学习过程中产生的大量数据（期中考试成绩、多次实验分数等）及相关学生的评价信息 创建模型部分，需要对预处理后的数据建立模型，采用数据挖掘及机器学习等理论，通过大量的基础数据，建立相关模型。 预判部分，用户输入信息后需要对其进行解析，然后返回预判结果 3.画出用例图 来源： https://www.cnblogs.com/lcw12356/p/11786123.html

一.用例建模的简单描述 用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例。用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。用例建模主要有两个产物。第一个是用例图，第二个产物就是用例描述。 用例建模具有以下的优点： 首先，用例模型是一种标准的语言，很容易成为开发人员之间交流和沟通的媒介，用例模型可以精确地定义软件需求，出现歧义的可能性很小，这可以保证用户和开发人员对需求理解的一致性。 其次，用例模型可以成为我们评估压法工作量的一个标准，特别是对于迭代式开发言。迭代式开发模型里，通常依据用例模型来划分软件的开发周期：优先级别高的用例会在早期的迭代周期中实现，而优先级别低的用例则被安排在后续的迭代周期中完成。可以通过限制每个迭代周期中的用例个数来保证迭代周期长度的合理性。 再次，用例模型在整个开发过程中都扮演着非常重要的角色，它可以驱动软件的分析和设计逐步细化。 最后，测试过程中使用的测试用例-----特别是那些关注软件功能的测试用例---往往也是根据用例模型来确定的。 二.参与者、用例之间的关系 1.关联关系 这是最常使用的关系，用带箭头的实线来描述。 2.泛化关系

---恢复内容开始--- 一.用例建模的简单描述 用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例。用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。用例建模主要有两个产物。第一个是用例图，第二个产物就是用例描述。 用例建模具有以下的优点： 首先，用例模型是一种标准的语言，很容易成为开发人员之间交流和沟通的媒介，用例模型可以精确地定义软件需求，出现歧义的可能性很小，这可以保证用户和开发人员对需求理解的一致性。 其次，用例模型可以成为我们评估压法工作量的一个标准，特别是对于迭代式开发言。迭代式开发模型里，通常依据用例模型来划分软件的开发周期：优先级别高的用例会在早期的迭代周期中实现，而优先级别低的用例则被安排在后续的迭代周期中完成。可以通过限制每个迭代周期中的用例个数来保证迭代周期长度的合理性。 再次，用例模型在整个开发过程中都扮演着非常重要的角色，它可以驱动软件的分析和设计逐步细化。 最后，测试过程中使用的测试用例-----特别是那些关注软件功能的测试用例---往往也是根据用例模型来确定的。 二.参与者、用例之间的关系 1.关联关系 这是最常使用的关系，用带箭头的实线来描述。 2

　　我的工程实践选题是《风扇调度》，这是一个系统工具，主要用于分布式系统的性能和功耗调优。 　　在分布式系统中，任何一个硬件的功耗都是及其重要的，包括风扇，如何使得风扇的调度既可以保证系统的正常运行，又能使系统的功耗尽量的低，这是一个很重要的课题。 一、用例图 　　 如下图所示，这是风扇调度的用例图。其实现的主要功能是：在保证系统正常运行，NPU不掉频的情况下，尽力保证系统的低功耗。首先我们将系统的运行情况分类，对不同的运行情况采取不同策略的方法进行应对。比如正常情况，比如在分布式训练不同的模型的情况，比如环境温度不正常的情况，每一种情况都有它的特殊性，应该有不同的风扇调度方案。 二、High level use case 　　下面对于每个用例范围的High level use case进行分析： 　　1.普通情况风扇调度 　　　　这应该是一种常规情况，而且是服务器的常态，这种情况下服务器没有高负载，一般情况下也不需要风扇进行特殊的调度策略，只需要风扇处于一个较低的值，不使得温度出现极大的抖动即可。 　　2.分布式训练 　　　　具有NPU的服务器经常进行分布式训练，那么不同的分布式训练模型应该具有不同的特点，在这里将其分解成三类模型： 　　　　a.深度神经网络训练 　　　　b.传统机器学习训练 　　　　c.其他训练方法 　　　　对于不同的训练模型应该具备不同的特点

工程实践简介： 　　基于深度学习的脱机手写汉字识别。 手写汉字识别(Handwritten Chinese Character Recognition，HCCR)可广泛应用于拍照文档、支票、表单表格、证件、邮政信封、票据、手稿文书等光学字符识别(Optical Character Recognition, OCR)图像识别系统以及手写文字 输入设备中。自从上个世纪80年代以来,手写汉字识别一直是模式识别的一个重要研究领域，得到了学术界的广泛研究和关注。 用例建模的简单描述： 　　用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例。 用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。用例建模主要有两个产物。第一个是用例图，第二个产物就是用例描述。 参与者和用例简单描述： 　　从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。用例模型主要由以下模型元素构成： 参与者(Actor) 参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。 用例(Use

我的工程实践项目是《基于情感词典的影视评论大数据分析》，文本情感分析又称意见挖掘、倾向性分析等。简单而言,是对带有情感色彩的主观性文本进行分析、处理、归纳和推理的过程。互联网(如豆瓣电影、猫眼电影、大众点评)上产生了大量的用户参与的、对于影视等有价值的评论信息。这些评论信息表达了人们的各种情感色彩和情感倾向性,如喜、怒、哀、乐和批评、赞扬等。基于此,潜在的用户就可以通过浏览这些主观色彩的评论来了解大众舆论对于某一影视作品的看法。 以下是使用StarUML画出的用例图： High level use case: -获取数据 -处理数据 -构建情感词典 -情感分析 Expanded use case： 获取数据：网络爬虫——抓取网络上的用户影视评论内容。 构建情感词典：扩充情感词典——通用的情感词典并不适用于所有领域，因此需要我们再已有基础上通过各种方法对其进行扩充，使之能够应用于影视评论方面。 情感分析：制定匹配规则——过制细化补充语义规则，运用基于计算情感词权值的方法来进行情感分析；构建LDA主题模型——为了准确获得用户的情感色彩和情感倾向性，使用LDA主题模型获取具有概括性的主题词。 来源： https://www.cnblogs.com/haorw/p/11785891.html

　　我的工程实践是做一款类似于facerig的软件，拥有网络摄像头的任何人都可以以数字方式体现出虚拟的角色的角色。 它旨在成为一个开放的创作平台，因此每个人都可以制作自己的角色，背景或道具并将其导入FaceRig。 用例图 角色 　　用一个小人图标代表，角色可以是人、也可以是物。 用例 　　 用一个椭圆表示，用例就是系统的功能需求，就是待开发系统将要完成的功能。 关系 　　 包括角色和用例之间的关系、用例和用例之间的关系、角色和角色之间的关系，而关系种类较多，故在此不一一赘述。 ————————————————————————————————————— 　　我的工程实践用例并不复杂，如下图所示： High level use case 　　上述用户的用例中的High level use case是对系统的的回答进行反馈，包括正面和负面的反馈。 　　上述管理员的用例中的High level use case是对系统做出调整，包括收集更多的数据用深度学习算法对模型进行重新训练，也可以根据用户提出的反馈做出定向的设置调整。 Expanded use case 　　 对系统的回答进行反馈进行Expanded use case分析，上述的普通用户用例中使用模型进行换形象操作是用户主动的行为，对它进行扩展增强的话，可以是在每次使用模型进行换形象操作之后由系统主动询问反馈

我的工程实践项目为基于情感词典的文本情感分析，下面是我对我的工程实践进行用例建模的分析，主要经过以下四个步骤的分析：确定研讨的系统、识别 Actors、识别用例、建立 Actor 和 Use Cases 之间的关联。其中Actors是主要的开发人员，主要的用例有三个部分： 1.获取数据集。这个大致有三个方法，可以直接从网上下载现成的数据集，可以通过企业开放的API获取数据，然后是自己编写爬虫从网页上爬取数据。 2.构建情感词典。这部分是利用现有的情感词典并对其进行语义扩充。 3.情感分析。主要是利用文本分词与领域情感词典的匹配情况，得到情感值。 用例图如下： High level use case: 获取数据集 构建情感词典 情感分析 Expanded use case ： 获取数据集Expanded use case：下载公开数据集、 通过API接口获取、 爬虫抓取 ，。 构建情感词典 Expanded use case： 扩展情感词典，公开的情感词典可能并不适用于商品领域，为了得到更精确的结果，需要利用语义的相识度来扩展得到电商领域的情感词典。 情感分析 Expanded use case： 构建LDA主题模型，主要目的就是要识别主题，将结果清晰地展现地出来。 来源： https://www.cnblogs.com/zcs224/p/11785482.html

　　 此次工程实践课题为软件打包与分发渠道调研与实践。下面将在项目需求的基础上进行用例建模。抽取Abstract use case，画出用例图，并确定每一个用例的范围High level use case，对关键用例进一步进行Expanded use case分析。首先明确以下几个概念。 　　用例建模： 　　用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例。用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。用例建模主要有两个产物。第一个是用例图，第二个产物就是用例描述。 　　用例图： 　　用例图描述的是参与者所理解的系统功能，主要元素是用例和参与者。虽然用例图不能取代文本形式的用例文档，但它简要地概括了用例文档的主要内容，项目的基本需求和需求之间的关系一目了然。在项目初始阶段，用例图可以帮助开发团队以一种可视化的方式理解系统的功能需求，从而快速地进行需求分析。 　　用例图组成元素： 1、Actor 　　参与者指与系统交互的人或物。参与者不仅包括产品的用户，还包括维护人员、外设（人、打印机）、相连的系统等等。 在用例图中，参与者用一个小人来表示。 2、Use Case 　

　　我的工程实践题目为手写文本行识别，是一个根输入系统相关的实际项目。 　　用例是应用程序开发中的一个关键技术，主要用来捕获系统的高层次（High Level）用户功能性需求。这个绕口的描述 主要是因为用例不能用于捕获非功能性需求，也不能用于捕获内部的功能性需求。试图这样做将会造成灾难。首先因为用例 是一个非正式的和不精确的建模技术。其次用例的另一个用途是建立我们系统的基本结构，它不仅是定义需求的单位，而且 是估计我们的工作量的单位。 　　建立用例模型的顺序： 步骤1：　确定谁会直接使用该系统。这些都是参与者（Actor） 步骤2：　选取其中一个参与者 步骤3：　定义该参与者希望系统做什么，参与者希望系统作的每件事成为一个用例 步骤4：　对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用例的基本过程 步骤5：　描述该用例的基本过程。例如： 步骤6：　考虑一些可变情况，把他们创建为扩展用例。例如： 步骤7：　复审不同用例的描述，找出其中的相同点，抽出相同点作为共同的用例。这是发现“used”用例的唯一途径。例如： 步骤8：　重复步骤2-7找出每一个例。　　　 　　根据步骤画出的用例图如下： 　　 来源： https://www.cnblogs.com/songfeixiang1997/p/11785421.html