业务建模

1、领域建模Domain Modeling：开发团队获取领域知识的过程 2、进行业务领域建模原因：因为软件工程师需要在不同的领域或不同的项目中工作，来自不同的背景，这可能会影响他们对应用程序域的感知。他们需要领域知识来开发系统。比如，团队中的每个人都在说不同种类的语言。德语、法语、希伯来语等。每次有人发言，其他人完全错误的理解发言者真正想表达的话。系统在开发的过程中，每个人都会以不同的方式解释需求和设计。领域模型是一个灵活的，协作的”工做组件“。它对整个项目进行了细化和更新，从而反映了目前对需求空间的理解。领域建模，其目的是通过建立映射问题空间的常用词汇来解决项目沟通不畅的问题。 3、模型(Model)通常由2部分组成： 1）元素(Element) 2）元素间的关系(Relationship) 领域模型以图形方式显示了所有这些不同的术语如何相互关联。是一个简化的类图，在不同的类（领域对象）之间使用线条进行描绘，以显示它们如何相互关联。领域模型显示领域类之间的聚合和泛化关系（has-a和is-a关系） 4、领域建模（Domain Modeling）/业务分析的主要就是： 　 1）寻找业务对象（Business Object） 2）恰当建立这些对象间的关系 5、如何进行领域建模 1）收集应用程序域信息–关注功能需求，同时考虑其他需求和文档 2）头脑风暴–列出重要的应用程序域概念

一、什么是业务领域建模 领域建模： 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。领域模型是描述业务领域（业务实体）的静态结构。 理论派观点： Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型； 所有同行企业，其业务模型必定有非常大的共性和内在的规律性。 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。 领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 实战派观点： 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。 是需求分析人员与用户交流的有力工具，是彼此交流的语言。 领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。 业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。

以您的工程实践项目为例，在深入理解需求的基础上进行业务领域建模Domain Modeling ♦ 1) Collect application domain information – focus on the functional requirements – also consider other requirements and documents ♦ 2) Brainstorming – listing important application domain concepts – listing their properties/attributes – listing their relationships to each other ♦ 3) Classifying the domain concepts into: – classes – attributes / attribute values – relationships • association, inheritance, aggregation ♦ 4) Document result using UML class diagram 最终画出业务类图，并说明业务类图中每一个类、属性、方法的来源，对于有关联类Association Class的情况要进一步给出关系数据库的模型。 记住：我们是对业务建模

1、什么是Domain Modeling 　　业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务 用例 。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 业务角色显示了一个人承担的一系列职责。业务实体表示使用或产生的可交付工件、资源和事件。业务 用例 实现显示了协作的业务角色和业务实体如何执行某个工作流程。使用以下几种图来记录业务用例实现： 图显示参与的业务角色和业务实体。活动图，其中泳道显示业务角色的职责，而对象流显示如何在 工作流程 中使用业务实体。 序列图描述业务角色和业务主角之间交互的详细情况，并显示如何在业务用例执行过程中访问业务实体。 业务对象模型将结构的概念和行为的概念结合了起来。 它是一个纽带工件，用于对业务关系进行清晰的表述，表述方式与软件开发人员的思考方式类似，同时仍保留一些纯粹的业务内容。将我们所知道的有关业务的信息按照对象、属性和职责进行了合并。 它探索业务领域知识的本质，所采用的方式使我们能够从对业务问题的思考转变到对软件应用程序的思考上来。 它是一种确定需求的方法

我的工程实践题目是面向银行领域的自然语言理解系统设计，下面通过类图描述该项目的业务领域。 Collect application domain information (1) 系统提供的服务有四大类包括：贷款、信用卡、理财和金融。 (2) 每个业务有不同的语料库，每个语料库中有不同类型的问题的多种问询语句以及它们的解答语句。 (3) 根据不同的语料库训练不同的模型。 (4) 用户在使用时，系统首先语音询问用户要选择哪类服务，得到用户答复后调用对应的模型，准备工作。 (5) 用户语音输入后，系统调用语音识别API，生成文本数据喂给模型进行分类以找到对应的问题。 (6) 从数据库中匹配对应问题的答复语句，最后通过语音回复用户。 Brainstorming 名词：用户、贷款、信用卡、理财、金融、业务、语料库、问询语句、解答语句、模型、语音识别API、文本数据。 动词：语音输入、语音输出、语音识别、选择模型、生成文本数据、分类、寻找、匹配。 “...是...”表达式：贷款、信用卡、理财、金融是业务。 “...分成...”、“...组成...”表达式：语料库由问询语句和解答语句组成。 Classifying the domain concepts into 类 属性 用户 业务、模型、问询语句 语音 语音识别API、文本数据 处理 文本数据、模型 语料 语料库 交互 询问语句、解答语句

我的工程实践项目是实现一个室内三维地图可视化系统。 业务描述是：将点云数据进行处理及转换后，建立八叉树模型（CAD建模），通过OpenGL渲染实现可视化，可以进一步应用于虚拟现实交互中。 经分析，采用四色原型图法： 1.实体（绿色）：表示一个参与者。 2.角色（黄色）：实体、时刻时段的角色。 3.描述（蓝色）：用来对实体、时刻时段的公共属性进行述。 4.时刻时段（粉色）：实体在某个时间段内的参与事件。 该模型是领域（技术、工具、平台）无关的。可以用任何技术实现它。 故结合我的工程实践项目，做的分析如下： 1.实体：涉及到有点云数据，八叉树模型，最终的三维地图。 2.角色： 　　点云数据的格式：一开始是在数据库里，需要转换成八叉树格式。 　　八叉树模型的格式：需要进行CAD建模，然后转换成能导入OpenGL平台渲染的格式。 3.描述：就实体和时刻时段的公共属性而言，有：点云数据的信息（三维坐标XYZ和颜色信息） 4.时刻时段：按照流程，可分为：点云数据的处理和转换->八叉树模型的建立->地图渲染->漫游路线建立。 四色原型图如下： 来源： https://www.cnblogs.com/Teresa-Chenchen/p/11926426.html

♦ 1) Collect application domain information – focus on the functional requirements – also consider other requirements and documents ♦ 2) Brainstorming – listing important application domain concepts – listing their properties/attributes – listing their relationships to each other ♦ 3) Classifying the domain concepts into: – classes – attributes / attribute values – relationships • association, inheritance, aggregation ♦ 4) Document result using UML class diagram 　领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也成为概念模型、领域对象模型和分析对象模型。领域模型是一种概念模型，也叫问题域模型。它表述的是某个领域的现实概念。上世纪80年代开始

领域建模 Collect application domain information focus on the functional requirements – also consider other requirements and documents Brainstorming listing important application domain concepts – listing their properties/attributes – listing their relationships to each other Classifying the domain concepts into: classes – attributes / attribute values – relationships association, inheritance, aggregation Document result using UML class diagram 1 Collect application domain information 我的工程实践题目是《 多人对话场景中音频分离 》，题目要求的任务即说话人区分（Speaker Diarization）任务。说话人区分是声纹识别领域中的一个任务，具体是指根据说话者身份将输入的音频划分为同类片段的过程

1、Collect application domain information – focus on the functional requirements – also consider other requirements and documents 创建领域模型时，请确保将问题领域与实际对象集中在一起。 尝试着围绕现实世界来组织您的软件架构。 现实世界往往比软件需求变化要小。下图显示了两种不同类型的类符号。在完整的详细类图上，您将使用左侧的版本，其属性和操作。然而，在初始领域建模过程中，分配类的这些部分为时尚早。最好使用右边所示的简单符号。此版本仅显示领域类的名称。 2、Brainstorming – listing important application domain concepts – listing their properties/attributes – listing their relationships to each other 随着时间的推移，您将会使用新的领域类别来识别您的领域模型。您还会注意到他们之间的联系（或关联） - 例如，书评属于书，采购订单（purchase order）和信用卡（credit card）是两种，因为它们都是付款类型。 第一个关系（书评属于一本书）被称为聚合（has-a，因为一本书都会有一书评）。第二个关系