建模软件

人体的需求和设计 如果需求和设计不分，利润就会缩水。从需求直接映射设计，会导致功能分解，得到重复代码。如果从设计出发来定义需求，会得到一大堆假的“需求”。拿自古以来就有的一个系统“人体”来举例。人体对外的功能是会走路，会跑步，会跳跃，会举重，会投掷，会游泳……但是设计人体的内部结构时，不能从需求直接映射到设计，得到“走路子系统”、“跑步子系统”、“跳跃子系统”……人体的“子系统”是“呼吸子系统”、“消化子系统”、“血液循环子系统”、“神经子系统”、“内分泌子系统”…… 确实如此，人体的子系统是各个模块，当你需要完成某个动作时是调用各个模块共同完成的。例如你想跑步就需要“呼吸子系统”“，血液循环子系统”，“神经子系统”和“消化子系统”等等共同合作。而不是你要完成什么动作就需要有什么子系统，那样就会出现一大堆的假的需求。所以应该是这样的： “人体的“子系统”中很多是不能从需求直接映射出来的，需要设计人员的想象力。水店老板要雇一个送水工（即租用一个人肉系统），他只要求这个工人能跑能扛工资低就行，管他体内构造是心肝脾肺肾还是一块电路板。同样，也不能从设计推导出需求——因为人有心肝脾肺肾，所以人的用例是“心管理”、“肝管理”。送水工能这样找工作吗：“老板，我有心脏管理功能，你请我吧！” 很多时候我们说“本系统分为八大子系统……”，其实说的是“本系统的功能需求分为八大需求包……”

一、需求工程过程概念介绍 （一）概述 1.规格说明 需求工程过程是系统开发中需求开发活动的集成，它以用户所面临的业务问题为出发点进行分析和各种转换，最终产生一个能在用户环境下解决用户业务问题的系统方案，并将其文档化为明确的规格说明。 2.生命周期 需求工程也有属于它自己的生命周期模型， 即存在针对需求开发的需求工程过程，这个过程又作为系统工程和软件工程的一个子过程部署在系统开发的初期阶段。 3.活动分类 需求获取、需求分析、需求规格说明、需求验证为需求开发活动，需求管理为项目管理活动。 （二）需求开发活动成果文档类型简述 1.项目前景和范围文档 定义系统业务需求，明确系统开发的努力方向和工作范围。 2.用户需求文档 定义系统用户需求，以用户立场表达行为期望。例如，用例文档就属于用户需求文档中的一种。 3.需求规格说明文档 定义系统的系统级需求，指出开发者应该完成的任务。需求规格说明文档按照 需求范围大致可以分为以下两类： （ 1）系统规格说明文档 定义软、硬件需求、其他需求。 （ 2）软件规格说明文档 仅仅用于描述软件需求。 （三）系统开发后续阶段 在所有的系统开发活动结束之后，定义良好的需求被转入系统开发的后续阶段 ——设计、实现和测试等，这时往往会面对一个重要问题——需求变化。因此，在需求开发结束之后，在后续阶段中采取有效的方法统一管理开发的需求和需求变化

引言 在讨论DDD分层架构的模式之前，我们先一起回顾一下DDD和分层架构的相关知识。 DDD DDD（Domain Driven Design，领域驱动设计）作为一种软件开发方法，它可以帮助我们设计高质量的软件模型。在正确实现的情况下，我们通过DDD完成的设计恰恰就是软件的工作方式。 UL（Ubiquitous Language，通用语言）是团队共享的语言，是DDD中最具威力的特性之一。不管你在团队中的角色如何，只要你是团队的一员，你都将使用UL。由于UL的重要性，所以需要让每个概念在各自的上下文中是清晰无歧义的，于是DDD在战略设计上提出了模式BC（Bounded Context，限界上下文）。UL和BC同时构成了DDD的两大支柱，并且它们是相辅相成的，即UL都有其确定的上下文含义，而BC中的每个概念都有唯一的含义。 一个业务领域划分成若干个BC，它们之间通过Context Map进行集成。BC是一个显式的边界，领域模型便存在于这个边界之内。领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。 从广义上来讲，领域即是一个组织所做的事情以及其中所包含的一切，表示整个业务系统。由于“领域模型”包含了“领域”这个词，我们可能会认为应该为整个业务系统创建一个单一的、内聚的和全功能式的模型。然而

一. 工程实践项目分析 在使用用例以及用例建模的方法之前，我简要介绍一下我的工程实践项目： 首先，我所选的是一个企业项目，题目为 “物联网组网智能分析引擎” ； 其次，项目描述为：通过爬取现有物联网设备组网的数据或采用现场调研的方式，运用数据挖掘方法对这些数据进行分析，为开发新型物联网设备提供参考与依据。数据分析结果可以包括成本、典型组网方式、开发周期、测试标准、交付周期、功能。 所以，能够提取出其中的关键词为：物联网；数据挖掘及可视化； Web 编程等。 下面的内容主要分为两个部分，一是叙述用例一些基本知识，二是针对于我的工程实践项目，展示用例的分析以及建模的过程。 二. 用例建模的作用与步骤 2.1 什么是用例方法？优势何在？ 首先来看一下传统的需求表述方式——"软件需求规约"(Software Requirement Specification)。 传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。 采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计

用例建模Use Case Modeling 一.用例建模的简单描述及优点 用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例。用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。用例建模主要有两个产物。第一个是用例图，第二个产物就是用例描述。 用例建模具有以下的优点： 提供了捕捉功能需求的工具 有助于将系统范围分解成更易管理的小块 提供了与用户以及其他关心系统功能的关联人员进行交流的工具。用例是容易被各种关联人员理解的公共语言 提供了确定、分配、跟踪、控制和管理系统开发活动（尤其是增量开发和迭代开发活动）的手段 辅助估计项目范围、投入和进度 为定义测试计划和测试用例提供了一个基准 为用户帮助系统和手册以及系统开发文档提供了一个基准 提供了需求跟踪的工具 提供了确定数据对象或实体的起点 提供了设计用户和系统接口的功能规格说明 提供了定义数据库访问需求（增加、修改、删除和读取）的手段 提供了驱动系统开发项目的一个框架 二、关键术语描述： 　　用例建模：使用业务时间、发起业务事件的人，以及系统如何相应这些事件来建模系统功能的过程 　　用例图：描述系统与外部其他系统以及用户之间交互的图形

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

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

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

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

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