业务建模

每个业务都有一个对应的业务模型，这个业务模型设计的时候，完全不需要考虑任何软件设计的思想，比如对象的抽象、继承、存储、性能，等。我们是从业务本身出发，分析业务边界范围内的各种业务概念，以及业务概念之间的关系，通常我们可以使用一个业务模型的图来表达这些业务概念以及业务概念之间的关系。那么如何得到一个业务模型呢？最常见的有名词动词形容词分析法，还有比如四色原型分析法，都可以。找一个适合自己的就行；业务模型本身非常有价值，它提炼了领域内业务的核心概念及其关系，可以帮助我们更好的理解业务本身。 我的工程实践选题是《基于深度强化学习的智能控制系统设计》， (1) Collect application domain information 该项目的应用场景为：能够让Agent能够不断学习，从周围环境获取信息并能够选择最佳的action来一步步的完成Agent的最终目标，例如让一个机器人或者一个小车能够不碰撞地到达目的地，并且能够自动避障。用户直接用这个训练好的能够规划路径的Agent来实现自己的需求，例如扫地机器人，甚至用在自动驾驶领域。 (2) Brainstorming User Story去找出领域对象： 用户 ：提出要求，指定机器人的工作； 开发人员训练Agent: 确定性模型可以用蒙特卡洛或者时间差分算法来不断的让Agent去根据当前状态选取action

业务领域建模简介 领域建模： 领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。 概念： 业务对象模型（也叫领域模型 domain model ）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务 用例 。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（ “业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 设计步骤： 领域模型设计是需求分析的 关键步骤 。它帮助用户及需求分析人员建立业务概念，确定用户业务的问题域，系统涉及的业务范围等等。 领域模型设计的步骤为： 1. 从业务描述中提取名词； 2. 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合； 3. 从业务实体集合中抽象业务模型，建立问题域的概念（例如在前面的例子中，我们把容易变质的水果称之为“短期保持水果”，当然也可以是其它说法，只要能跟用户达成共识即可）； 4. 用 UML 提供的方法和图例进行领域模型设计、确定模型之间的关系； 针对工程实践进行业务领域建模 一

领域模型 领域模型是什么 领域模型，又称概念模型、领域对象模型、分析对象模型，是对领域内的概念类或现实世界中对象的可视化表示，其将结构的概念和行为的概念结合了起来。在书《UML和模式应用》中，就认为领域模型是需求分析阶段的业务模型，是一种业务概念实体的模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。领域模型构成了您的模型的静态部分的基础，而用例是动态部分的基础。静态部分描述结构;动态部分描述行为。 下面将从领域模型和业务模型之间区别的角度来举个例子对其概念加以说明。如一个读者持借书卡去图书馆借书这个场景，在业务模型中会存在一个借书卡的业务概念，而在领域模型中，我们很可能会去掉借书卡，因为它只是一个借书的工具，是借书系统用来识别读者的一个工具，系统真的的目的是为了知道哪个账号在借书，而不关心如何识别出这个账号。 （业务建模是以 软件 模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架 企业信息系统 ） 对业务领域模型的理解 每一个复杂的软件都应该按层来组织，每一层就代表系统的一个逻辑部件。其中，抽象的讲业务逻辑层是系统的一部分，用来处理和业务相关的任务，其处在一个分层系统的中间，和表现层、数据访问层交换信息。而业务领域模型即为业务层实现一个结构化的视图。

1：领域建模 领域建模（Domain Modeling）表示开发团队用来获取知识的过程； 2：为什么进行领域建模 因为软件工程师在不同的项目或者领域里面工作，他们需要不同领域各自的模型知识来开发系统。而且，开发工程师可能来自不同的背景，这可能会影响他们对整个系统的理解。事实上，领域模型最不同于传统模型的地方在于，领域建模下，接触到需求第一步就是考虑领域模型，也就是将需求大致划分为几个大的领域，而不是按照数据和行为对其进行分割。然后数据部分依靠数据库实现，行为操作使用服务实现，最后使得需求界限清晰明了。也就是说，领域建模首先考虑的是业务，而不是行为，不是数据。它强调业务抽象和OO编程，这和传统的面向过程式的编程有明显差别。 3：模型和领域建模 模型由元素和元素之间的关系组成，这些元素自身和关系依靠简单图形图表来描述，是一种更为简单的类图，能清晰表达元素的本质特征和各个元素模块的的之间的主要关系，领域模型下，元素之间的关系大致分为继承（Inheritance）、聚集（Aggregation）和关联（Association）三种联系： 继承（Inheritance）：表达概念之间的通用型和专业性关系，在继承关系下，通常是一方比另一方更为通用或者专业，这种关系也会称为IS-A关系； 聚集（Aggregation）：表达这样的一个事实：一个对象是另一个对象的一部分。这种关系也称为所属关系。

一、领域建模的概念 　　业务领域建模是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。通俗来说就是我们设计一个系统，总是希望它能解决一些问题，这些问题总是会映射到现实问题和概念。对这些问题进行归纳、分析的过程就是领域建模。 二、建立领域模型的好处： 1、通过建立领域模型能够从现实的问题域中找到最有代表性的概念对象 2、并发现出其中的类和类之间的关系，因为所捕捉出的类是反馈问题域本质内容的信息。 三、结合工程实践进行业务领域建模 　　我的工程实践是视频序列中人脸识别与身份推断，人脸识别主要基于MTCNN人脸检测与FACENET人脸识别算法，系统建模主要在身份推断和用户系统设计。 1.功能需求： 　　系统主要应用场景在于城市小区，可以对于进入小区的人员进行人员识别，对于已存在数据库中并已标注的人，直接显示识别人员信息，对于未标注的人员，根据数据库信息包括已标注人员身份，性别，运动轨迹等等，对人员信息进行身份推断，包括业主，工作人员，外卖人员，临时住户等等，还可以比对公安系统的黑名单，检测犯罪人员信息，以下为主要流程。 2、头脑风暴，列出其中重要的应用程序域概念 我们这个系统主要为小区安保人员使用，所以主要用户信息就是类型也就小区保安。通过摄像头拍摄信息查看人员信息。 用户是一个实体对象 视频读取到的人员是一个领域对象

kubernetes业务领域建模 k8s是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效,Kubernetes提供了应用部署，规划，更新，维护的一种机制。 一、Collecting application domain information 本次工程实践的目标是基于国产芯片集群搭建自动化操作容器的平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么在我们的工程项目中，docker就是我们要管理的目标。 我们需要完成的功能： 自动化容器的部署和复制 随时扩展或收缩容器规模 将容器组织成组，并且提供容器间的负载均衡 很容易地升级应用程序容器的新版本 提供容器弹性，如果容器失效就替换它，等等... 可行性分析(相关参考文档): 寒武纪提供的开发者手册，提供服务器集群相关的API Intel提供的相关接口与寒武纪提供接口的横向对比 开源项目kubernetes已基于Intel芯片实现相关的功能，可基于其做国产芯片的移植 二、Brainstorming 重要领域概念： master主节点 是集群控制节点，来负责整个集群的管理和控制，基本上k8s的所有控制命令都是发给它。我们后面执行的命令基本都是在master节点上运行的。通常它会占据一个独立的x86服务器（或一个虚拟机）。 属性：

　　我的工程实践是基于大数据问答训练的中文自然语言理解系统设计。本系统为聊天机器人，回答的问题基于医学知识问答的特定领域。 1. Collect application domain information – focus on the functional requirements – also consider other requirements and documents 　　本项目的服务场景为： 　　1. 在电脑上直接打开客户端进行咨询。 　　2. 在电脑或者手机上登录网页咨询。 　　3. 医院现场咨询 　　用户群体主要包括电脑客户端用户、手机或电脑的网页端用户以及医院终端用户。 　　 　　用户想通过对自己身体不适状况的描述得到一个确切的答案，所以日常所用的搜索引擎会得到各种各样的结果，用户很难从中选取哪个是自己真正需要的。所以本系统使用深度学习模型，可以给用户一个确切的答案。 　　语音交互系统的重要性：很大一部分用户是老年人，有视力障碍或者不识字的情况，语音交互就可以很好的满足他们的需求。 2. Brainstorming – listing important application domain concepts – listing their properties/attributes – listing their relationships to each

我的工程实践选题是关于室内定位与导航的，以下是对该选题业务建模的分析过程。 业务建模是理解一个业务系统，对业务流程进行分析和优化的必要方法。对于复杂的业务系统来说，业务建模和业务分析是业务软件开发的前提条件，也是链接业务和软件的环节。 通常业务模型是分层分级逐步展开的，一般按照顶层模型-业务域-业务类-业务子类(有时有)-业务流程-业务环节一层层分解。 1. 顶层模型 该模型大致描述会有哪些业务领域，以及各个业务域之间是怎么一种关联关系。本选题的业务领域主要为用户使用系统进行导航。 2. 业务域模型 主要是对上面的模型进行细分，针对本选题可以细分为：搜索目的地、查看相关信息以及相关推荐。 3. 业务类 业务类实际上就可以继续分解和对应到软件需求的功能类了。比如针对“搜索目的地”可分为定位、检索以及导航等功能。 4. 业务环节 将业务每一环节的内容再标准化。 来源： https://www.cnblogs.com/minhui/p/11922553.html

一 领域模型是什么？ 领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也成为概念模型、领域对象模型和分析对象模型 此领域模型的定义源于《UML和模式应用》一书，个人认为这本书中对领域建模的概述是最完整、可操作性最强的。 领域模型是一种概念模型，也叫问题域模型。它表述的是某个领域的现实概念。 二 领域模型有什么特点？ 将书中提到的观点总结，有如下三点内容： 第一，领域模型是业务概念的可视化描述，是需求分析的产物； 第二，领域模型用于指导程序设计，但领域模型与实现方式无关，领域建模时不应该考虑如何实现； 第三，领域模型需要同项目所有成员（客户、项目经理、开发、测试…）达成共识。 三 为什么要做领域建模？ 首先，建模的重要性在所有工程实践中都已经得到了广泛的认同。 建模是一种抽象和分解的方法，它可以将复杂的问题拆解成一个个抽象，代表了特定的一块密集而内聚的信息。 从上世纪80年代开始，人们对于面向对象建模产生了许多思考和方法，其中最流行的就是面向对象分析与设计。面向对象分析，强调的是在问题域发现并描述概念，解决的问题是做正确的事情。面向对象设计，强调的是定义软件对象，解决的问题是正确的做事情。 领域模型就是面向对象分析的主要产物，它表达了对现实问题的描述和抽象。 大多数人可能可能会有质疑：不做分析和设计，我也可以直接去做代码实现

业务领域建模Domain Modeling 业务分析 工程实践的需求是搭建一个视频数据集网站，满足一些基本的视频数据上传与处理服务。用户可以将需要处理的视频发布到网站的个人账号，设置视频访问权限，根据个人需求获取网站处理好的视频并下载到本地。 系统的用户有网站的注册用户与网站的管理者，普通注册用户可以上传下载视频，网站管理者可以审核修改注册用户的当前状态、删除违规视频或禁止违规用户上传下载视频等操作。 管理员可以向所有用户发布公告，让用户遵守视频的发布规则，用户可以查看删除收到的消息。 系统需要的类有：用户类、管理员类、视频类、消息类 用户有以下操作： 注册 登录 注销 上传视频 下载视频 删除视频 管理员有以下操作： 登录 注销 查封用户 解禁用户 删除视频 发布公告 视频类所需方法： 分帧处理 数据标注 用户类属性： userId 姓名 密码 账号状态 管理员类属性： userId 姓名 密码 视频类属性： cvId userId URL 权限 文件名 发布日期 消息类属性： msgId userId 内容 发布日期 UML类图 关系数据库模型 来源： https://www.cnblogs.com/ustca/p/11922534.html