业务建模

1. Concepts 1.1 领域模型概念 领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。 业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。 软件开发过程：业务建模、需求、分析、设计 1.2 领域模型作用 分析如何满足系统功能性需求。 指导项目后续的系统设计。 1.3 如何领域建模 领域模型如此重要,很多同学可能会认为领域建模很复杂,需要很高的技巧。事实上领域建模非常简单,概括一下就是“找名词”! 一个关键的问题还没有说明:从哪里找? 如果你还记得领域模型是“需求到面向对象的桥梁”,那么你肯定一下子就能想到:从需求模型中找,具 体来说就是从用例中找。 归纳一下域建模的方法就是“从用例中找名词”。 当然,找到名词后,为了能够更加符合面向对象的要求和特点,我们还需要对这些名词进一步完善,这就 是接下来的步骤:加属性,连关系! 最后我们总结出领域建模的三字经方法:找名词、加属性、连关系。 A. 发现类和对象：尽可能多的找出概念类（识别方法：概念类分类列表、名词性短语） a.概念分类列表：人、事物、地点、组织、概念、事件、规则、抽象名词、交易项目、角色、设备、组织结构（对用例进行识别：实体、过程中的信息、角色的输入输出、操作设备等） b.名词分析法

领域建模 理论派观点： Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型； 所有同行企业，其业务模型必定有非常大的共性和内在的规律性。 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。 实战派观点： 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。 是需求分析人员与用户交流的有力工具，是彼此交流的语言。 领域模型是一种特殊业务模型，作用都是： 帮助分析理解复杂业务领域问题。 行业内沟通、交流。 业务建模 我的工程实践是web漏洞扫描器 ♦ 1) Collect application domain information 　　web漏洞扫描器，主动发起扫描请求，尽可能多的收集信息，对所收集到的内容进行漏洞发现，在漏洞发现之后还需要进行漏洞验证，避免出现大量误报，提高准确率。最后生成HTML格式报告。 ♦ 2) Brainstorming 　　信息收集：收集IP信息，指纹信息，HTTP请求响应信息 　　漏洞发现与验证：识别端口服务并进行相应的爆破；URL参数识别并进行注入；HTTP请求改变参数，进行FUZZ。 　　生成报告：报告格式为HTML。 ♦ 3) Classifying the domain

一、什么是业务领域建模 　　 业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 二、为什么要进行领域建模 　　软件的世界里没有银弹，是用事务脚本还是领域模型没有对错之分，关键看是否合适。实际上，CQRS就是对事务脚本和领域模型两种模式的综合，因为对于Query和报表的场景，使用领域模型往往会把简单的事情弄复杂，此时完全可以用奥卡姆剃刀把领域层剃掉，直接访问Infrastructure。我个人也是坚决反对过度设计的，因此对于简单业务场景，我强力建议还是使用事务脚本，其优点是简单、直观、易上手。但对于复杂的业务场景，你再这么玩就不行了，因为一旦业务变得复杂，事务脚本就很难应对，容易造成代码的“一锅粥”，系统的腐化速度和复杂性呈指数级上升。 　　目前比较有效的治理办法就是领域建模，因为领域模型是面向对象的，在封装业务逻辑的同时，提升了对象的内聚性和重用性，因为使用了通用语言（Ubiquitous Language），使得隐藏的业务逻辑得到显性化表达

业务领域建模Domain Modeling 业务建模其实是一个从多方面描述系统的综合。大约要划分为四个方向： 1.是组织机构和人员模型。 也就是信息化手段应用后对组织、机构和人员的影响和变化。包括工作内容，职责，以及因此带来的制度规范的变化。 2.是业务/处理模型，这里所谓的处理包含的是所有业务过程中的处理。例如把软件打包邮递出去，这个过程完全没有软件参与，但是它是整体工作流程中的一个环节。业务/处理模型，可以根据需要作层次化的细化，此处不再赘述。 3.信息模型。信息模型至少包括了静态的信息形式化后的数据表示，数据规范，数据标准，数据字典、术语、元数据定义等等静态的东西。也包括了数据经过处理后变化的形式、比如显示在屏幕上，打印在报表上，存储在文件中，加载在XML内被传输给一个WebService理解，这种动态的转换和流动的模型。 在大多数MIS系统中，对静态数据的管理就足够解决业务模型中所针对的问题了。但在某些系统中，信息的变化意味着特殊的含义。比如银行系统中你账户上的金额，在这种情况下，就必须要技术手段，例如交易的完整性来保证数据变化和准确性，又例如一个监控系统从外部传感器获取的数据，这种数据的变化常常在业务中有着重要的含义，因此软件必须时刻关注这种数据状态的变化并作出反应，就是很重要的事情。。如此类推。 4.环境模型。环境模型描述了软件系统所运行需要的环境。例如软件环境，OS

业务领域建模 〇，业务领域建模 　　What ：开发团队获取相关领域知识的过程 　　Why ：软件工程师需要在不同领域和项目中工作 　　How ：收集相关领域信息，头脑风暴，分类，使用 UML 图进行描述 一，Collect application domain information（收集应用相关领域的信息） 　　业务领域建模的第一步就是手机业务领域的相关信息。首先要做的就是要关注业务领域的功能性需求，此外还需要考虑其他的相关需求以及文档。 　　考虑到本次工程实践的题目是设计一个高并发低延迟的区块链框架，结合上次作业中用例建模的相关结果，将收集到的信息归纳如下： 　　　　本次项目的目的是实现一个区块链系统，其应满足用户通过区块链完成交易的需求。具体的需求可由下图表示。 二，Brain Storm （集思广益） 　　在信息收集之后，需要对收集的信息进行整理，为下一步的分类做好基础。根据上一步的结果和 Brain storm 的规则，可以罗列归纳出如下信息帮助进行分类： 　　（1）提取名词 　　　　1) 用户（ Class ） 　　　　2) 交易（ Class ） 　　　　3) 区块（ Class ） 　　　　4) 钱包（ Class ） 　　　　5) 密钥（ Attribute ） 　　　　6) 区块链（ Class ） 　　　　7) 时间戳（ Attribute ） 　　　　8)

金融文本挖掘的业务领域建模 领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系 领域模型设计是需求分析的关键步骤。它帮助用户及需求分析人员建立业务概念，确定用户业务的问题域，系统涉及的业务范围等等。 领域模型设计的步骤为： 从业务描述中提取名词； 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、>实例，形成问题域中操作实体的集合； 从业务实体集合中抽象业务模型，建立问题域的概念（例如在前面的例子中，我们把容易变质的水果称之为“短期保持水果”，当然也可以是其它说法，只要能跟用户达成共识即可）； 用UML提供的方法和图例进行领域模型设计、确定模型之间的关系 领域模型本质上应该是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题领域相关。领域模型是需求分析人员与用户交流的有力工具，是需求分析人员与用户共同理解的概念，是彼此之间交流的语言。而数据模型是系统设计、实现的一部分，描述的是对用户需求在数据结构上的实现，仅此而已。当然数据模型中的概念模型设计与领域模型类似，缺乏的是实体之间更广泛的关系描述。 通常大家会考虑数据怎么存放的问题

使用领域建模可以对现实中的事务进行充分的抽象，让我们发掘重要的业务领域概念，同时建立各个业务领域之间的联系，让我们对业务有更加清晰的认识。 ·如何进行领域建模？ 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:

我的工程实践选题为ESP32低功耗的实现，本项目基于ESP32嵌入式开发平台.下文将以需求为基础，对该项目进行领域建模。 一、概念介绍 1、业务建模 1.1 概念介绍 业务建模(Business Modeling)是以 软件 模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架 企业信息系统 。 1.2 分类 业务建模(Business Modeling)是一种建模方法的集合，目的是对业务进行建模。这方面的工作可能包括了对 业务流程 建模，对 业务组织 建模，改进业务流程，领域建模等方面。 2 领域建模 2.1 概念介绍 领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。 业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务 用例 。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象("业务类和对象")之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。

一.领域建模Domain Modeling定义 领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也成为概念模型、领域对象模型和分析对象模型。 二.业务领域建模原因 领域建模可以降低软件和现实世界之间的差异，用真实的业务概念划分职责，目的是实现一个可以高效低成本维护的可持续发展的软件系统。 从领域模型推导到系统实现是一套引导思考的方式，也是一套科学的开发流程。其核心目的在于提供了系统设计的“指导方针”。领域模型必须站在用户需求和业务发展的角度上，既可以用来同客户沟通验证需求，又可以避免模型因实现的考量而带偏（实现成本、遗留系统） 软件工程师需要在不同的领域或不同的项目中工作，来自不同的背景，这可能会影响他们对应用程序域的感知。他们需要领域知识来开发系统。 三.模型(Model)通常由2部分组成： 1.对象（Object） 2.对象间的关系(Relationship) 四. 领域建模（Domain Modeling）/业务分析的主要就是： 1.寻找业务对象（Business Object） 2.恰当建立这些对象间的关系 3.添加关联和属性 五.领域模型设计的步骤（如何进行领域建模）： 5.1用例分析法 用例分析法是进行领域建模最简单可行的方式。其步骤如下： 1.获取用例描述 既然我们的领域模型指的是问题域模型，那么建模也一定要从问题域入手

业务领域建模 Domain Modeling 好的模型应该是建立在对业务深入理解的基础上，建模是一个不断迭代的过程，一开始可以简单点来。下面开始进行一个简单的业务领域建模。 领域建模共有4个步骤：收集领域信息，进行团队头脑风暴、分类和使用UML类图可视化领域知识。 1. 收集领域信息 收集领域信息包含两个方面的内容： - 聚焦在功能需求 focus on the functional requirements - 也要考虑其他的需求和文档 also consider other requirements and documents 我的项目是构建一个适用于PC端和移动端的专注于某一学科的智能题库，用户开始时，题库会对用户进行一次测评，可以根据测评结果智能的推算出用户在这门学科的知识水平，为用户的提供有针对性的题训练。 2.进行团队头脑风暴 头脑风暴包含三个方面的内容 - 列出重要的应用程序领域概念 - 列出类和属性 - 列出它们之间的关系：继承关系（IS-A）、聚合关系（part of)、关联关系。 团队成原在一起识别这些类型：名词/名词短语、 X of Y表达式、及物动词、形容词、数字、占有式表达、成分/组成部分、包含表达式、X是Y表达式等 3. 分类 类 - classes 属性/属性值 - attributes / attribute values 关系：继承关系、聚合关系