07｜通过业务建模应用业务知识

Mar 22, 2024

07｜通过业务建模应用业务知识-徐昊 · AI时代的软件工程-极客时间



下载APP





关闭

渠道合作

推荐作者

07｜通过业务建模应用业务知识

徐昊 · 徐昊 · AI时代的软件工程

课程介绍



讲述：徐昊

时长08:18大小7.60M



你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
从今天开始，我们进入到第二部分的学习：如何使用大语言模型（Large Langauge Model，LLM）辅助我们的软件研发和交付过程。在前面一节课里，我们已经从宏观层面上厘清了这个思路：将软件交付看作知识过程，识别其中的认知行为模式，并选择恰当的 LLM 交互模式，有目的性和针对性地提高整个知识过程的效率。
在这个过程中，我们将着重看待不同种类的知识是如何发挥作用的，以及如何将它们转化为 LLM 易于理解的结构。
那么今天我们先从业务模型开始，看一下业务模型是如何帮助我们理解业务的。
业务模型是如何发挥作用的我们都知道，软件开发的核心难度在于处理隐藏在业务知识中的复杂度，模型就是对这种复杂度的简化与精炼。
我们通过模型捕捉领域或业务知识，使用模型构造更易维护的软件。模型就是精粹的知识。我们借助模型形成统一语言（Ubiquitous Language），达成对于问题或解决方案的理解。
我们通过建模获得模型，而建模是一个非常复杂的问题，有各种不同方法。我之前有一个专门的课程讲述这个问题，这里就不再赘述了。有需要了解这方面知识的同学，可以参看相应的课程。
我们目前关注的是，当得到了模型之后，怎么使用模型，帮助我们应用凝结在模型中的业务知识。这个过程，我称之为模型展开。所谓模型展开，就是在给定的业务上下文中，将模型中的概念实例化，通过实例化的模型，解释业务上发生了什么。下面看一个例子。
假设我们现在为某学校研发学籍管理系统，那么它的模型可能是这样的：
这是一个简化的领域模型，描述了学籍管理系统的核心知识：
学院提供不同的教学计划，比如信息学院可能提供计算机科学与技术学士学位教学计划，或是计算机科学与技术硕士学位教学计划；
不同教学计划有对应的教学大纲。教学大纲中则规定了学生需要学习的课程。比如，计算机科学与技术学士学位教学计划的教学大纲中，规定了学生的必修课离散数学；
学院为学生发放录取通知，通知学生被哪个教学计划录取，比如张三录取为学士学位学生；
学生根据录取通知将学籍注册到指定的教学计划，比如，张三根据录取通知注册为 2023 年入学的计算机科学与技术学士学位教学计划学生；
学士在学籍有效期内，需要根据教学大纲选课。比如，张三在攻取学士学位的时候，学习了离散数学。
接下来，我们就可以在具体的业务场景或是功能需求中，通过模型来应用这些知识了。让我们看几个例子。这里所有的需求我都会以用户故事（User Story）的形式给出。
以学生入学为例，按照我们要求学生需要拿到录取通知后，方能入学，那么用户故事可以写成：
作为学校的教职员工（As a faculty），
我希望学生可以根据录取通知书将学籍注册到教学计划上（I want the student to be able to enroll in an academic program with given offer），
从而我可以跟踪他们的获取学位的进度（So that I can track their progress）
第一个验收条件是可以成功注册的情况。我们使用如果 / 当 / 那么（Given/When/Then）的形式描述验收条件：
如果获取了录取通知书的学生没有注册学籍时（Given student with offer hasn’t enrolled any program），
当这个学生注册时（When the student enroll），
那么这个学生将能成功注册学籍到录取通知书指定的教学计划中（Then the student will successfully enroll the program specified in the offer）
那么我们可以在这个验收条件的上下文中将模型展开。
如上图所示，我们将模型在这个验收条件的上下文中做了实例化。对应验收条件中，Given 的描述是“获取了录取通知的学生没有注册学籍时”，这表示存在一个 Offer 对象实例，而没有 Program Enrollment 的实例；而 Then 的描述“这个学生将能成功注册学籍”，则表示我们可以生成 Program Enrollment 的实例，并将这个实例与 Offer 中的教学计划关联。
另一个验收条件是，如果没有拿到 offer 则不能注册。我们仍然使用如果 / 当 / 那么（Given/When/Then）的形式描述验收条件：
如果学生没有获取录取通知书（Given student doesn’t have an offer），
当他尝试注册时（When the student try to enroll），
那么这个学生将无法注册学籍（Then the student can’t enroll any program）
同样我们可以根据这个验收条件的上下文将模型展开。
展开之后，这个模型就简单明了了，Given 的描述是“学生没有获取录取通知”，那么也就是不存在 Offer 对象实例；而 Then 的描述“这个学生将无法注册学籍”，则表示我们不会生成 Program Enrollment 的实例。
在这两个例子中，我们关注的是学生学籍注册这个行为或功能。但是我们并没有直接描述它，而是从状态 / 数据改变的角度，描绘了业务行为发生前后模型实例的变化。这样，我们就使用了静态的模型解释了动态的行为或功能。
在使用模型解释业务的时候，是否会出现多种不同的解决方案呢？在解释的过程中，我们只使用了模型中的概念和关系，因而对于某一个场景，实际只存在唯一符合业务场景的描述。这是因为在模型中还隐藏着时间维度。
模型中的时间维度让我们再仔细看一下前面的模型，就会发现其中实际存在着时间顺序。首先是学院。学院是早于教学计划的。没有对应的学院，也就不存在各种学位的教学计划。然后教学计划是早于录取通知书的，如果没有教学计划也不可能发放相应的录取通知书；最后是录取通知书是早于学籍，因为学生是根据录取通知书注册的，如果没有录取通知书，学籍注册也就无法完成。
模型中的时间维度，与模型中关系的性质有关。这就是为什么无论在面向对象设计还是领域驱动设计，抑或是其他什么设计方法中，对于聚合、组合、引用等概念都要详加区分。因为它们表示了不同的时间关系。
如上图所示，我们在模型中标注了引用与聚合关系。不难看出：
聚合根要先于被聚合的对象存在。比如，学院 - 教学计划。
被引用的对象要先于引用对象存在。比如，录取通知 - 教学计划。
那么我们在展开模型的时候，也可以把时间维度单独标示出来，这样更利于我们处理数据持久化时，理解不同对象的生命周期。比如，在针对这个验收条件：
如果获取了录取通知书的学生没有注册学籍时（Given student with offer hasn’t enrolled any program），
当这个学生注册时（When the student enroll），
那么这个学生将能成功注册学籍到录取通知书指定的教学计划中（Then the student will successfully enroll the program specified in the offer）
进行模型展开的时候，我们可以加入时间的维度：
图中最下方的横轴，表示时间轴，也就是时间的顺序。图形在时间轴上的位置，表示了它们产生的时间的顺序，也就是学院早于教学计划，早于学生，早于录取通知书，早于学籍。当然，严格来说，学生与学院哪个是最先产生的并不重要。它们可能是从其他数据源导入的，是时间不敏感的信息，类似的还有课程，也是一样的情况。
时间轴上有一个关键节点，就是我们当前的业务场景注册。在注册之后，我们产生了新的实体学籍，同时产生了新的关联关系，也就是图中用虚线表示的张三 - 张三的学籍，还有教学计划 - 张三的学籍。
类似的，对于第二个验收条件“如果没有拿到 offer 则不能注册”。
如果学生没有获取录取通知书（Given student doesn’t have an offer），
当他尝试注册时（When the student try to enroll），
那么这个学生将无法注册学籍（Then the student can’t enroll any program）
包含时间线的模型展开后是这样的。
可以看到，我们既没有生成新的实体，也没有建立新的关联。
在理解了模型中的时间维度之后，通过模型展开，在产生了什么样的实体与关联，这些实体和关联产生的顺序是怎么样的这两点上，我们就能容易地达成共识。也就是使用了模型帮助我们理解了业务。
小结今天我们讲解了模型展开，以及如何利用模型展开去理解业务。通常我们会更关注于建模，也就是模型的提取过程，而往往忽略了模型提取后如何有效应用模型。
行业里有大量关于建模的讨论，但是涉及真正使用模型去形成统一语言，就很少有人提及了。这一方面是因为利用模型形成的统一语言，是一种不可言说知识。另一方面也是因为，我们往往更关注知识的产生，而忽略知识的消费。
从知识工程的角度来看，在我们应用模型来理解业务的过程中，我们处在什么样的认知行为模式呢？很显然，我们是处在庞杂的认知行为模式上的。通过分析，我们将模型中定义的模式（对象类型与关系种类）应用到当前的上下文中。
那么我们使用 LLM 帮助提效的思路是什么呢？思路就是构建思维链（Chain of Thought），也就是通过思维链辅助 LLM 理解模型应该如何展开，这就是我们下节课要讲的内容。
思考题模型展开这部分推荐你自己练习一下，才能充分掌握。请你结合你的工作实践，思考另外几个业务场景，并做模型展开。
欢迎在留言区分享你的想法，我会让编辑置顶一些优质回答供大家学习讨论。

本文介绍了业务建模在软件研发和交付过程中的应用，以及模型在解释业务过程中的重要作用。作者强调了模型是对业务知识复杂度的简化与精炼，通过模型构造更易维护的软件，并形成统一语言，达成对问题或解决方案的理解。文章通过学籍管理系统的领域模型展示了模型的具体应用，以及如何在具体的业务场景或功能需求中应用这些知识。作者以用户故事的形式给出了学生入学的例子，并通过模型展开，解释了业务行为发生前后模型实例的变化。此外，文章还探讨了模型中的时间维度，强调了模型中关系的性质与时间顺序的关联，以及在模型展开中加入时间维度的重要性。最后，作者指出通过模型展开，可以容易地达成共识，使用模型帮助理解业务。整体而言，本文深入浅出地介绍了模型在解释业务过程中的作用，以及如何利用模型展开去理解业务。

分享给需要的人，Ta购买本课程，你将得29元

生成海报并分享

2024-03-22

赞 11

提建议

直播专场（一）｜如何理解知识工程？

08｜使用LLM辅助业务理解

 写留言

全部留言(8)

最新
精选

临风
置顶
2024-03-22 来自广东
一开始看今天的模型，感觉有点懵，因为我没有经历老师的思维过程，不知道模型是怎么得出的。然后在老师的《如何落地业务建模》的第三讲，我看到了这样一句话，“我们始终要记住，模型是对问题的抽象，没有对错，只有角度不同“。于是我就大胆按我自己的想法构建模型，如果让我设计一个学籍管理系统，我可能第一个想到的对象就是学籍。那么谁拥有学籍，一定是某个学生；学生是如何拥有学籍的，一定是学生进行了报道，注册了学籍；为什么他能报道，一定是学院给了他offer；那为什么学院会给他offer，一定是他报名了这个学院的专业并且达到了分数（这里可能会涉及到报名录取的一个外部依赖API）。学生拥有学籍后要干嘛，上课呗，然后才能毕业，于是我们又得到了课程；那课程是怎么来的呢，是教学大纲规定的，然后教学大纲又是教训计划所指导编写的，我们又可以得到教学计划和教学大纲；最后，学生要怎么才能上课呢，就又涉及到选课。可能我还会设计一个学分的对象，这样就能知道这个学生是否满足毕业的学分要求。可能最后画出图来，和老师的也差不多吧，最重要的是经过这个思路的整理，再看老师的模型图就清楚多了。难怪在过去的时候，构建领域模型是十分困难的一件事，下节课就要讲CoT，期待会有新的思考和启发。
展开
6
aoe
2024-03-25 来自浙江
模型展开太厉害了，还带时间属性又学会了一个新技能，感谢老师
编辑回复: 欢迎结合自己熟悉的业务练习模型展开～
2
范飞扬
2024-04-04 来自广东
原文：聚合根要先于被聚合的对象存在。比如，学院 - 教学计划。 --- 那既然是聚合，模型图里应该用空心菱形而不是实心吧？钟敬老师在《ddd》课是这样说的
作者回复: 那是因为eric evans弄反了aggregation和composition的含义 ddd社区讲的aggregation在oo/uml社区就是composition
共 3 条评论
1
赫伯伯
2024-03-22 来自河北
上完课，感觉似乎用另一种方式，把活动图，序列图和状态机图干的事儿又搞了一遍。是为了让大语言模型能更好的吸收知识吗？
共 1 条评论
1
大卫
2024-03-22 来自浙江
模型的展开过程就是形成统一语言的过程，也就是不可言知识的传递过程！此过程会涉及功能需求的描述和功能模块的划分甚至更细致的TODOs！正如《落地建模》中所讲的模型/统一语言/业务需求三者关系。模型在时间维度的展开就是用UL来描述需求，如果有不能描述的需求就要再次提取知识演化模型，形成新的UL来描述需求也就是用户故事的产生！如果CoT能高效生成正确的用户故事，那么CoT模板就提高不可言知识的传递效率！
共 1 条评论
1
6点无痛早起学习的和...
2024-05-03 来自北京
2024年05月03日09:48:22 看到这节课的内容，画的图，在思考公司里技术方案按照这么标准的画图，又有多少呢？我在某个大厂的某个金融业务下就没有见到，能把 uml 的关系图画如此标准
术子米德
2024-03-24 来自浙江
🤔☕️🤔☕️🤔 【R】模型，用统一语言（Uniquitous Language）描述，将高复杂度的业务知识，进行简化与精炼，用于构造更容易维护的软件。模型之前，可用DDD的方法，之前，模型之后，开发人员理解模型、以不可言说知识去实现、并完成交付；如今，模型之后，如何跟LLM一起、提取出可复用的、不可言说知识为提示词，来达到知识复用、进而提高知识传递效率，即所谓【LLM based BizModel Applies，基于大模型的业务模型应用】。【.I.】根据业务建模型，这是架构师的活，让业务域的所需以问题的样子，被技术域的所能以求解的样子，合起来变成题目和答案的业务模型样子，开发人员拿着模型去实现。开发人员之所以能理解模型、能实现模型，既有显性知识，还有更多不可言说知识。这就是收购时，为啥不能只买几个架构师，得把整个团队成员都买去的缘故。如果，现在切换到基于大模型的开发范式，架构师的活，还得继续干，他要交付模型，开发人员的活，每干一轮，就会被LLM提取些不可言说知识出来。【Q】LLM会像吸血鬼一样，持续吸出开发人员的不可言说知识吗？ — by 术子米德@2024年3月24日
展开
一只豆
2024-03-22 来自广东
这节课的内容不算太难理解，不过因为是新一章的开篇，而且是为了下一讲铺垫，我在使劲试着找背后的脉络感来调整注意力的姿势。我理解，建模是一件昂贵的事情，所以要充分发挥（精炼业务知识后才得到的）模型的作用才没有白白建模。所以，模型像是一个以关系数据库状态存在的，很干很干的信息内核，未来会在这个内核外面漂浮很多信息场景，即被用户以不同业务场景的视图来访问。要想开发好这些信息场景，就需要开发人员深度理解这些场景。但一方面很干很干的信息内核对开发人员不友好，再者团队内部的业务认知也非常不均衡，所以存在很多误解和反复沟通的日常痛苦剧情。于是我们可以利用LLM 丰富的常识和知识储备，让 LLM基于信息内核（一种强编码的上下文描述），并且使用 CoT 的方式（因为这是不可言说知识的提取）来把这个干货变湿，让人类开发者用自然语言就get 到很多具体的业务场景到底会怎么运转。这样就实现了第六课中提到的，在庞杂认知模式下，通过复用思维链实现团队成员之间不可言说知识的高效传递。这样既解决了团队中认知分布不均衡的问题，也充分发挥了（辛辛苦苦才建立）业务模型的作用。这就是利用 LLM 进行业务模型（给人类）展开的价值。
展开

