序言
事务需求的研发进程中，无论是产品依据事务画流程状况图，仍是研发画类图，测验画用例剖析图都会消耗很多的时刻。ChatGPT+PlantUML可以作为一种效率东西快速出草稿，而且学习本钱约等于零。
本文叙述了怎么运用ChatGPT+PlantUML快速生出建模图，有助于消弭多方人物（包含事务方，产品，开发和测验等）间的认知差。文中所用东西PlantUML和ChatGPT，选用PlantUML是因为ChatGPT作图能力不够完善，所以需求有一种东西能将文本转换成图文形式，图文形式信息量更丰厚，更易于了解。PlantUML是将代码转为图文，可以随时将PlantUML代码作为ChatGPT的前置知识，不必ChatGPT丢失上下文信息。
正文
接下来会用文字模仿一个事务需求会看ChatGPT怎么快速生成建模图。灰底的文字块为ChatGPT答复的内容，呈现的图均运用PlantUML进行绘制。
我：事务方和产品司理开谈判事务需求，产品将会议纪要转为成事务流程图给到技能开发，技能开发依据流程图规划技能方案画出UML图并转化成代码言语，开发完结后测验人员依据事务规划各种测验用例剖析来验证代码的正确性。 请将以上的流程转为成PlantUML
@startuml
actor 事务方
actor 产品司理
actor 技能开发
actor 测验人员
事务方 -> 产品司理 : 提出事务需求
产品司理 -> 技能开发 : 会议记载转为事务流程图
技能开发 -> 技能开发 : 规划技能方案
技能开发 -> 技能开发 : 画出 UML 图
技能开发 -> 技能开发 : 转化成代码言语
技能开发 -> 测验人员 : 供给代码
测验人员 -> 测验人员 : 规划各种测验用例
测验人员 -> 测验人员 : 剖析验证代码的正确性
@enduml
事务方说我想要一个作业流。产品司理说：流程的运转简略吗。事务方说简略的。产品司理说：那规划一个有限状况机的作业流程就行了，chatgpt请规划一个有限状况机的作业流程
好的，下面是一个简略的有限状况机作业流程规划：
1. 初始状况（Start）：作业流开端的状况，表明还未开端处理使命。
2. 待处理状况（Ready）：在这个状况下，作业流已收到使命，但还未开端处理。
3. 处理中状况（In Progress）：在这个状况下，作业流正在处理使命，或许需求花费必定的时刻和资源。
4. 审阅状况（Review）：在这个状况下，作业流已完结使命，但需求进行审阅或承认。
5. 完结状况（Done）：在这个状况下，作业流已完结使命，而且现已得到认可或同意。
依据实际情况，状况之间可以有不同的转换行为。比方：
1. 从初始状况到待处理状况：在这个进程中，作业流接收使命并预备处理。
2. 从待处理状况到处理中状况：在这个进程中，作业流开端处理使命，并进入执行阶段。
3. 从处理中状况到审阅状况：在这个进程中，作业流现已处理完使命并预备提交审阅。
4. 从审阅状况到完结状况：在这个进程中，作业流现已得到审阅成果，并承认使命完结。
以上仅为示例规划，详细的有限状况机作业流程还需求依据详细事务场景进行进一步的规划和调整。
产品：稍等我去画个流程状况图。要不chatgpt你用PlantUML给我画个图吧。
好的，下面是运用PlantUML画的有限状况机作业流程图：
@startuml
[*] --> Start
Start --> Ready
Ready --> InProgress
InProgress --> Review
Review --> Done
Done --> [*]
@enduml
以上是一个简略的有限状况机作业流程图，其中 Start 表明初始状况，[*] 表明停止状况，
Ready 表明待处理状况，InProgress 表明处理中状况，Review 表明审阅状况，Done 表明完结状况。
箭头表明状况之间的转换，其中 Ready --> InProgress 表明从待处理状况到处理中状况的转换，
依次类推。经过这个图形化的表明，事务方可以愈加直观地了解有限状况机作业流程。
事务方:看这张图就好懂多了，可是内容太单薄了，能否表现一下人工处理使命的进程
当涉及到人工处理使命时，以下是一个或许的进程：
1. 使命指使：一个使命被指使给一个作业人员或团队。
2. 了解使命：作业人员开端阅览使命说明和要求，保证他们了解使命的意图和方针。
3. 数据搜集：作业人员开端搜集和收拾使命所需的数据和信息，这或许包含查找数据库、文件或与其他人沟通。
4. 数据处理：一旦数据被搜集，作业人员开端剖析、分类、收拾和清洗数据以满意使命要求。
5. 解决问题：使命或许涉及到困难、杂乱或技能性的问题。作业人员需求花时刻研究这些问题并提出解决方案。
6. 审阅和验证：一旦使命完结，作业人员需求进行审阅和验证以保证作业的准确性、完整性和合规性。
7. 交付成果：一旦使命取得同意，作业人员将使命成果提交给事务方或其他相关方。
8. 反应和调整：假如使命成果未达到预期方针，作业人员需求承受反应并作出调整以保证使命成功完结。
以上是人工处理使命的基本进程。随着事务的不同以及使命的性质，该进程或许会有所不同。
产品司理：用PlantUML来描绘，下面我说的画图的意思都是用PlantUML来描绘
好的，PlantUML是一种轻量级的图形描绘言语，它可以很方便地描绘软件体系架构、流程图、时序图等等，以下是一个或许的人工处理使命进程的PlantUML描绘:
@startuml
title 人工处理使命进程
|使命指使|
:一个使命被指使给
一个作业人员或团队;
|了解使命|
:作业人员开端阅览使命说明和要求，
保证他们了解使命的意图和方针;
|数据搜集|
:作业人员开端搜集和收拾使命所需的数据和信息，
这或许包含查找数据库、文件或与其他人沟通;
|数据处理|
:一旦数据被搜集，作业人员开端剖析、分类、
收拾和清洗数据以满意使命要求;
|解决问题|
:使命或许涉及到困难、杂乱或技能性的问题
作业人员需求花时刻研究这些问题并提出解决方案;
|审阅和验证|
:一旦使命完结，作业人员需求进行审阅
和验证以保证作业的准确性、完整性和合规性;
|交付成果|
:一旦使命取得同意，作业人员将
使命成果提交给事务方或其他相关方;
|反应和调整|
:假如使命成果未达到预期方针，作业人员需求
承受反应并作出调整以保证使命成功完结;
@enduml
以上是一个运用PlantUML来描绘人工处理使命进程的示例。每一个进程都用一个盒子和对应的说明表明，箭头表明进程之间的联系。这种简略的语法和图形化办法，使得人们更容易了解整个进程的流程和进程。
事务方说，那我想要一个财政作业流，大致流程如下：开端—>出纳制单—> 付款审阅 —> 付款 —> 付款成果回填 —> 完毕，也画张图吧
好的，以下是运用PlantUML描绘财政作业流的暗示图：
@startuml
title 财政作业流
|开端|
start
:财政流程开端;
|出纳制单|
: 出纳依据需求制单;
|付款审阅|
:付款审阅人员依据
付款单核查付款信息;
|付款|
:出纳担任付出;
|付款成果回填|
: 付款后将回填付款成果;
|完毕|
:财政流程完毕;
end
@enduml
事务：内容有点单薄，我想表现各个节点间的流通进程。产品司理司理说：那你给一下流程条件啊。事务说：我相信chatgpt，勇敢地画吧。
好的，我可以为您运用PlantUML绘制一张愈加详细的财政作业流程图，展示各个节点之间的流通进程，一起增加流程条件来作为判断的依据。以下是示例：
@startuml
title 财政作业流程图
start
if (是否需求付款) then (是)
:出纳制单;
if (订单信息是否正确) then (是)
:付款审阅;
if (审阅经过) then (是)
:付款;
if (付款是否成功) then (是)
:付款成果回填;
else (否)
:付款失利;
endif
else (否)
:付款审阅不经过;
endif
else (否)
:订单信息有误;
endif
else (否)
:不需求付款;
endif
stop
@enduml
以上暗示图中，运用了循环和判断条件，形成了一个完整的条件流程。假如需求付款，则进入出纳制单环节，然后再进行相关的校验和审阅，并依据审阅成果挑选是否要付款。假如付款成功，则回填成果，不然流程到此完毕。假如不需求付款，则直接退出流程。这样的办法可以愈加直观地展示整个流程，而且让人一望而知地看到各个进程之间的相关。
事务方你看吧，我就知道它行的。可是这张图是流程图，我还要一张状况图。产品司理说：你还要啥自行车。
好的，以下是运用PlantUML描绘财政作业流的状况图示例：
@startuml
title 财政作业状况图
[*] --> 未开端
state 出纳制单 {
state 待制单
state 制单中
state 制单完结
}
state 付款审阅 {
state 待审阅
state 审阅中
state 审阅完结
}
state 付款 {
state 待付款
state 付款中
state 付款完结
}
state 付款成果回填 {
state 待回填
state 回填中
state 回填完结
}
[*] --> 出纳制单
出纳制单 --> 付款审阅 : 制单完结
付款审阅 --> 付款 : 审阅经过
付款 --> 付款成果回填 : 付款成功
付款 --> 出纳制单 : 付款失利
付款成果回填 --> [*] : 回填完结
@enduml
以上暗示图中，运用了状况图的办法来描绘整个进程的不同状况，每种进程都是一个状况，状况之间运用箭头进行切换。初始状况是未开端，然后进入到出纳制单的状况，处理完毕后进入下一个状况，以此类推。这样的状况图愈加明晰地展示了整个财政作业流程的状况改变，便于人们了解整个流程的状况。
事务：太棒了，那能用活动图来表明吗
@startuml
|初始状况|
start
:职工填写申请表并提交;
|出纳制单|
if (是否需求出纳制单?) then (yes)
:申请单送至出纳制单节点;
if (出纳是否制单?) then (yes)
:出纳制单;
:将申请单和制单成果提交给付款审阅节点;
else (no)
:制单未完结;
endif
else (no)
:不需求出纳制单;
:将申请单提交给付款审阅节点;
endif
|付款审阅|
:付款审阅节点审阅申请单;
if (是否审阅经过?) then (yes)
:将申请单提交给付款节点;
else (no)
:审阅未经过;
|完毕状况|
end
endif
|付款|
:付款节点进行付款;
if (是否付款成功?) then (yes)
:将付款成果回填到申请单中;
else (no)
:付款未成功;
endif
|付款成果回填|
:将申请单及付款成果送回申请人承认;
if (申请人是否承认?) then (yes)
:将申请单及付款成果提交给财政部;
else (no)
|完毕状况|
end
endif
|完毕状况|
end
@enduml
这时候测验插话了，这个状况话还没有流程图明晰好懂，帮我也规划一下用例剖析吧.
好的，以下是运用PlantUML描绘的财政作业的用例图示例：
@startuml
title 财政作业用例
actor 事务
actor 财政
actor 出纳
usecase "制单" as make_bill
usecase "审阅" as audit
usecase "付款" as pay
usecase "回填" as fill
事务 --> make_bill
make_bill --> 出纳
出纳 --> audit
audit --> 财政
财政 --> pay
pay --> 出纳
出纳 --> fill
@enduml
以上暗示图中，运用用例图的办法来描绘了此财政作业流程中的各个参与者和操作。其中，有三个参与者：事务，财政和出纳。事务向出纳提交需求财政处理的单据或请求，出纳经过制单环节生成单据并移交给审阅人员进行审阅，审阅完结后移交给财政处理付款事宜，财政经过付款环节进行付出。在付出进程中，出纳需求进行实际操作，并回填付出成果。这样的用例图可以更好地展示每个参与者的效果和职责，一起展示了各个进程之间的相关。
测验说事务你看符合你的需求吗，事务说最好能再丰厚一下信息，各个节点经过和回绝都会到哪个人物哪个状况。产品说chatgpt持续靠你了.
@startuml
|事务|
start
:登录体系并具有提交单据请求的权限;
:提交单据或请求;
|体系|
:正确接收并记载单据或请求信息;
|事务|
:承认体系可以正确记载并保存单据或请求信息;
|体系|
:保存单据或请求信息;
|事务|
stop
@enduml
@startuml
|出纳|
start
:登录体系并具有制单的权限;
:依据事务提交的单据或请求信息生成单据;
:移交审阅人员进行审阅;
|体系|
:正确接收并记载单据信息;
:将单据移交给审阅人员;
|审阅人员|
:依据单据信息进行审阅;
:将审阅完结的单据移交给财政进行付出处理;
|体系|
:正确接收并记载单据审阅状况信息;
:将审阅完结的单据正确移交给财政;
|财政|
:依据审阅完结的单据信息进行付款操作;
|体系|
:正确处理付款事宜;
:将付款成果回填给出纳;
|出纳|
:回填付出成果，承认付出完结;
|体系|
:正确接收并记载付款成果信息;
:将已完结付出的单据标记为已完结状况;
|出纳|
stop
@enduml
测验说你真的太棒了。产品说这图我咋这么眼熟，真的是一秒出图啊。开发这时候发话了，能帮我把上述的信息收拾成UML类模型吗。一起我想完成节点可配置，表现一个作业流对应多个流程节点，且每个节点之间有先后顺序。对了把节点的状况也加进去。
@startuml
interface I状况{
批阅中: int
经过: int
回绝: int
}
interface I节点{
+进入节点(): void
+处理(): void
+回绝(): void
}
class 作业流{
-开端: I节点
-完毕: I节点
-当时节点: I节点
-节点列表: List[I节点]
+增加节点(I节点): void
+发动流程(): void
+进入下一个节点(): void
+完毕流程(): void
}
abstract class 流程节点 implements I节点{
#称号: string
#状况: int
-下一节点: I节点
-回绝节点: I节点
#处理办法: Function
#回绝办法: Function
+进入节点(): void
+处理(): void
+回绝(): void
+修改状况(I状况): void
}
class 出纳制单节点 extends 流程节点{
+制单(): void
}
class 付款审阅节点 extends 流程节点{
+审阅(): void
+发送审阅告诉(): void
}
class 付款节点 extends 流程节点{
+付款(): void
+发送付款告诉(): void
}
class 付款成果回填节点 extends 流程节点{
+回填(): void
}
enum 状况 implements I状况{
批阅中
经过
回绝
}
作业流 -> I节点
I节点 <|.. 流程节点
I节点 <|.. I状况
流程节点 o-- I状况
@enduml
开发：请将上述的模型转换成PHP代码，而且只要批阅中的节点才干进行详细的事务逻辑操作
<?php
interface IStatus {
const 批阅中 = 0;
const 经过 = 1;
const 回绝 = 2;
}
interface INode {
public function 进入节点();
public function 处理();
public function 回绝();
}
class 作业流 {
private $开端;
private $完毕;
private $当时节点;
private $节点列表 = array();
public function 增加节点($节点) {
$this->节点列表[] = $节点;
}
public function 发动流程() {
$this->开端->进入节点();
$this->当时节点 = $this->开端;
}
public function 进入下一个节点() {
$下一节点 = $this->当时节点->get下一节点();
if ($下一节点 != null) {
$下一节点->进入节点();
$this->当时节点 = $下一节点;
} else {
$this->完毕流程();
}
}
public function 完毕流程() {
$this->完毕->进入节点();
}
}
abstract class 流程节点 implements INode {
protected $称号;
protected $状况 = IStatus::批阅中;
protected $下一节点;
protected $回绝节点;
protected $处理办法;
protected $回绝办法;
public function 进入节点() {
// do something
}
public function 处理() {
if ($this->状况 == IStatus::批阅中) {
$this->处理办法();
$this->修改状况(IStatus::经过);
}
}
public function 回绝() {
if ($this->状况 == IStatus::批阅中) {
$this->回绝办法();
$this->修改状况(IStatus::回绝);
}
}
public function 修改状况($状况) {
$this->状况 = $状况;
}
public function get下一节点() {
if ($this->状况 == IStatus::经过) {
return $this->下一节点;
} else if ($this->状况 == IStatus::回绝) {
return $this->回绝节点;
} else {
return null;
}
}
}
class 出纳制单节点 extends 流程节点 {
public function 制单() {
if ($this->状况 == IStatus::批阅中) {
// do something
}
}
}
class 付款审阅节点 extends 流程节点 {
public function 审阅() {
if ($this->状况 == IStatus::批阅中) {
// do something
}
}
public function 发送审阅告诉() {
// do something
}
}
class 付款节点 extends 流程节点 {
public function 付款() {
if ($this->状况 == IStatus::批阅中) {
// do something
}
}
public function 发送付款告诉() {
// do something
}
}
class 付款成果回填节点 extends 流程节点 {
public function 回填() {
if ($this->状况 == IStatus::批阅中) {
// do something
}
}
}
?>
在 流程节点 类中的 处理 和 回绝 办法中增加了状况查看，只要 批阅中 的节点才干执行详细的事务逻辑操作。
例如，在 出纳制单节点 类中的 制单 办法，只要在该节点处于 批阅中 状况时才干进行详细的制单操作。
跋文
ChatGPT+PlantUML完全可以作为一种效率东西，前期快速出草稿和搭建相应代码结构。特别是基础知识这一块ChatGPT的表现得十分优异，作为人类知识库它基本能掩盖到所有场景。可是牢记必定要review，有时候ChatGPT也会抽风。
