业务建模

建立模型应该考虑的几个问题 数 据仓库建模质量直接影响数据仓库项目的质量，甚至成败。在进行建模之前，要对数据仓库的规模、组成及模型不同部分的功能定位有明确的定义。影响数据仓库建 模的因素众多，且根据不同项目的具体情况而变化口下面的几个问题是较为通用和常见的，远远不是建立模型应该考虑的全部问题。 数据仓库的业务特点对建模的要求 1 数据仓库的数据组织是面向主题的，而不是面向报表的 数据仓库是面向业务分析的主要主题领域的，进行形成数据模型的定义。典型的主题领域主要包括: · ·顾客购买行为 · ·产品销售情况 · ·企业生产事务 · ·原料采购 · ·合作伙伴关系 · ·会计科目余额 要 对现有的报表需求进行细致的分类、分析和调整，不能为了实现单个报表而进行大量的建模工作。要根据分析的不同内容和主题对报表进行分类，明确报表中每一个 数据的定义、统计口径及不同数据之间的关系，建立在整个数据仓库内统一的数据指标的定义，将数据指标按分析主题及分析维度进行归集，从而形成面向主题的数 据模型。 例如：我们的利润表报表，当业务部门发我们一个利润表 的报表，作为需求时，我们应该进行细致的分析，最终我们确定我们面向的主题不是利润表，而是比利润表更大的一个层次的所有科目业务量的主题，这样我们在做 别的报表，例如资产负债表，现金流量表等报表时，就不用重复建模的工作了，做到了软件工程中的可重用规则。 2.

小结： 1、 模型服务需求，既快速完成分析又 维度模型是数据仓库领域大师Ralph Kimall所倡导。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能 https://mp.weixin.qq.com/s/1CO9eIZFqvZlVLDQ3j1Kwg 漫谈航空业务维度建模之六脉神剑 原创： 大飞叔 数澜 2018-05-29 文字也说不清楚，甚至还把票价 燕子斜阳来又去，如此江山。 02 航空公司 发展时：等闲识得东风面，万紫千红总是春 衰退时：朝朝暮暮阳台下，雨雨云云楚国亡 票价下跌：昔日芙蓉花，今成断根草 票价上涨：欲把西湖比西子，浓妆淡抹总相宜 03 乘客 想买票：问世间，情（票）是何物，直教人生死相许 盼低价票：明月几时有？把酒问青天 买不起票：照之有余辉，揽之不盈手 买错票：一杯愁绪，几年离索 04 媒介 票价落：无可奈何花落去，似曾相识燕归来 何时涨：思君令人老，轩车来何迟 05 策划人 命运：志士幽人莫怨嗟，古来材大难为用 甲方：出塞复入塞，处处黄芦草 有创意：我欲因之梦吴越，一夜飞渡镜湖月 结款难：多情却似总无情，唯觉樽前笑不成 06 航空专家 观点：只在此山中，云深不知处 点评：穿花蛱蝶深深见，点水蜻蜓款款飞 07 过客 星沉海底当窗见，雨过河源隔座看 总结

业务流程管理综述 业务流程管理综述 TJDLUT 摘要：业务流程管理包括支持业务过程分析、设计、执行、管理的方法、技术及工具。它可以被看作是经典工作流管理系统和方法的扩展。本文主要介绍业务流程管理的基本概念、相关技术，以及讨论形式化方法 / 语言对业务流程管理的作用（例如 Petri 网，过程代数等）。 关键词：业务流程管理 工作流管理形式化方法 引言 首先了解一下信息技术演化的过程是有助于我们地更好的了解业务流程管理系统的相关知识。从图 1 中，我们可以看到当今信息系统发展的趋势 [3] 。该图表明当今的信息系统包含了几个层。中心层是直接和硬件打交道德操作系统；第二层是通用的应用程序，这些应用程序在企业中有广泛使用，比如 Microsoft Office ；第三层是为某些特定领域所开发的软件，这些软件局限于专业的企业或者部门内部使用，比如人力资源管理系统， Call Center 系统等；第四层是专业定制软件，这些软件仅仅为特定的公司组织开发，通用性较小，专业化程度很高。 图 1 信息系统技术演化趋势 在二十世纪六十年代，信息系统中不包含第二层和第三层。信息系统建立在一个小型的操作系统上，仅仅有特别局限的功能。因为那时没有通用软件也没有行业专用软件，当时的信息系统仅仅包含专业定制软件。从那时开始，第二层和第三层软件逐渐发展起来，此外第四层软件的种类逐渐增多，同时增加了更多的功能

业务流程管理综述 TJDLUT 摘要：业务流程管理包括支持业务过程分析、设计、执行、管理的方法、技术及工具。它可以被看作是经典工作流管理系统和方法的扩展。本文主要介绍业务流程管理的基本概念、相关技术，以及讨论形式化方法 / 语言对业务流程管理的作用（例如 Petri 网，过程代数等）。 关键词：业务流程管理 工作流管理形式化方法 引言 首先了解一下信息技术演化的过程是有助于我们地更好的了解业务流程管理系统的相关知识。从图 1 中，我们可以看到当今信息系统发展的趋势 [3] 。该图表明当今的信息系统包含了几个层。中心层是直接和硬件打交道的操作系统；第二层是通用的应用程序，这些应用程序在企业中有广泛使用，比如 Microsoft Office ；第三层是为某些特定领域所开发的软件，这些软件局限于专业的企业或者部门内部使用，比如人力资源管理系统， Call Center 系统等；第四层是专业定制软件，这些软件仅仅为特定的公司组织开发，通用性较小，专业化程度很高。 图 1 信息系统技术演化趋势 在二十世纪六十年代，信息系统中不包含第二层和第三层。信息系统建立在一个小型的操作系统上，仅仅有特别局限的功能。因为那时没有通用软件也没有行业专用软件，当时的信息系统仅仅包含专业定制软件。从那时开始，第二层和第三层软件逐渐发展起来，此外第四层软件的种类逐渐增多，同时增加了更多的功能。当今

本章介绍UML建模元素 1： Stereotype-也被称为类型、构造型 UML里的元素扩展，简单来说其功能就是在已有的类型上添加一些标记，类似于打个戳，从而生成新的东西。 简单的说加一句话来更加清楚准确描述这个类。 2： Actor（主角、参与者）-是在系统之外与系统交互的某人或某事物，在建模过程中处于核心地位。 参与者和系统之间有一个明确的边界，参与者只能存在于边界之外，边界之内的所有人和事物都不是参与者。 人或物都可以时参与者； 3：如何确定参与者-一定是启动业务的主角 4：业务主角和业务工人 业务主角（business actor）是参与者的一个版型，用于定义业务的主角，不依赖计算机系统。业务主角是与业务系统有着交互的人和事物，用来确定业务范围。 业务范围：项目所涉及的所有客户业务的客观存在；系统范围：软件将要实现对应业务的系统功能。 业务工人被动参与业务 5：参与者和干系人 干系人-是与要建设的这个系统有利益相关的一切人和事 参与者就是干系人代表，对系统提出要求来获得他所代表的涉众的利益。 用户（user），指的是系统的使用者，是参与者的代表，一个用户可以代理多个参与者。 角色（role），指的是参与者的职责，一个角色代表了系统中的一类职责。 6:用例：一种把现实世界的需求捕获下来的方法。用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 对于软件开发来说，领域建模是最重要的活动，领域模型是最重要的产物。领域模型反映了软件所要服务的现实业务领域的本质，体现了我们对业务领域的认识、理解和洞见。 领域模型应该是一切领域开发活动的出发点和依归。 本系列文章以组织结构的领域建模为例，演示领域建模的方法和技巧。 领域模型的重要性 领域模型的重要性体现在： 领域模型的正确性决定了软件在业务上的正确性。 领域模型代表我们对问题域——即软件所要服务的现实业务领域——的组成、结构、行为、机制和规则的认识和理解。模型错误就是对问题域的认识错误，根据错误的模型开发出来的软件（解决方案）必然错漏百出，不符合业务需要。正如同解数学题，如果我们对试题的理解是错误的，我们给出的答案必然是错的。正如同赛跑，如果方向错误了，跑得快是没有什么用的。高超的设计思想和编码技巧都无法弥补领域模型的缺陷。 领域模型的抽象性决定了软件在未来业务上的扩展性。 我们知道在问题域中，既存在共性，也存在个性。好的领域模型通过抽象和分解等等方式，既实现了共性，也使个性化成为可能。不好的领域模型，或者无法进行个性化扩展，或者扩展的成本很高，需要对系统进行伤筋动骨的改动。 好的领域模型既满足当前客户的需要，也支持相同领域其他客户的需要；既符合当前业务需要，也支持未来业务扩展的需要

面向对象与领域建模 板桥里人 http://www.jdon.com 2006/12/6（转载请保留） 多变且复杂的需求 　　如果没有多变的需求，也许就没有今天的面向对象软件，我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击，可是这样下去的结果只有一个：使得软件更加僵化；或者程序员更加 劳累。 　　需求不但多变，而且经常是不可能第一次就能掌握，需求反映了某个领域的专业知识，例如数学、管理、财务或 电子商务等等，每个特定案例需求又有其特别复杂之处，几乎没有人能够第一次接触就可以深入掌握这些专业领域的 需求本质，就是专门的建模专家也不例外。 　　既然需求是多变而且复杂的，所以，就不能使用“堵”式方法对其进行控制和管理，只能顺势而为，通过灵活多变的 以及迭代反复的方式逐步抓住需求，并且作为需求的实现软件系统必须能够迅速应对需求变化，需求变化有多快，软件 变化就有多快。 　　因此，对于多变的需求，我们的解决之道是：引入灵活多变的架构，面向对象OO架构正是应对多变需求而生，强调软件的可维护性 和拓展性，OO可能不是最好方式，但是目前是最合适的；对于复杂的需求，我们的解决之道是：委派专门的建模专家跟踪理解需求， 在需求和需求实现之间搭建桥梁，项目方法上采取多次迭代的敏捷软件开发方式，逐步了解学习掌握需求。 　　在这里稍微说明一下，很多人总是将软件和数学、管理

以您的工程实践项目为例，在深入理解需求的基础上进行业务领域建模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的情况要进一步给出关系数据库的模型。 记住：我们是对业务建模

我的工程实践项目是实现一个多轮对话机器人。其中该机器人可在封闭领域应用，随项目进度而言，也可以考虑做开放领域的机器人 业务描述： “封闭领域” 指的是对话机器人在与用户对话的过程中，仅围绕特定主题展开，相对于开放领域而言实现难度会小一些。 “开放领域” 指对话机器人可以在开放的语境中进行对话，不限主题。 在自然语言处理领域，这是一项生成式任务。 Collect application domain information： 工程实践题目为生成式聊天机器人，目标为基于现在的深度学习模型构建生成式模型。 目前在市场上，该类产品的应用极其有限，最成功的案例是微软团队的小冰，但即使是该团队在相关方向上的研究也没能让小冰达到接近人类交流的基本水准。 该工程实践希望在语料库内容相对开放的程度上尽可能使模型关联上下文产生良好回复。 Brainstorming： 该系统的核心组成包括语料库，预处理模型，网络模型，网络训练及对话生成部分。 这几部分是顺序链接的关系。 最终的成品仅包含对话生成部分或视部署的服务端而定，也将包括模型。 Classifying the domain concepts into： 最主要的类是网络模型，其中包含各种序列模型的模块（RNN,LSTM,GRU,TRANSFORMER...) 其余类可能包括：训练批的获取类，预测结果评估类等 其中

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