20231130 by elderman
灵感来源
源于我自己的某一门专业课需要绘制大量的UML图，烦不胜烦。遂产生此想法
想法
UML Helper
在软件需求分析领域，
帮助你从流程描述文字或者文档绘制出可供参考的UML图。
目前手动操作的流程如下：
流程
网址
绘图网址
支持绘制的UML图一览
大模型调用
我自己搭的chatgpt-next-web-langchain项目
注意事项
不注册也能用。注册并登录后，绘制文件保存在网站云端
导出时SVG最清晰，PNG的中文有字体问题
需再SVG->PNG
全程用gpt3.5-turbo-1106
GPT联网功能使用的是chatgpt-next-web-langchain中的联网插件，其基本原理是加入搜索引擎api（白嫖duckduckgo搜索api）
迭代-可行性验证
-
用例图，酒店预定系统
1-1 初次完整过程
原材料
网上某家酒店预订场景如下：
⑴游客可以浏览网站，但不能订房，游客可以输入用户名、身份证、电话、密码等信息注册为会员；
⑵用户可以按房间类型、价格、日期查询房间，会员选中房间后以订单形式提交给酒店；订单必须在指定时间内交纳房费，否则订单自动取消；
⑶会员可以申请取消、修改订单；
⑷会员可以查询自己的入住记录，可以查询、修改自己的登记信息；
⑸管理员能够增加、删除和修改房间的信息，能够查看订单；对用户申请的取消、修改订单进行处理。
用例图元素提取prompt
用例图总共包含以下四项元素：
用例：对业务工作的描述，或者说是对系统功能的称述。
参与者：发起或出发用例的外部用户以及其他软件系统等角色。它们代表的是与系统进行交互的角色。
关系：主要包含五种。
-- 关联：用例和参与者之间的关系，描述了用例和参与者之间的交互。
-- 包含：多个用例都会发生同样的行为，将这个这些共同的行为提取为抽象用例。此关系描述了用例与其包含的抽象用例之间的关系
-- 扩展：在原有用例的基础上扩展附加用例
-- 用例泛化：用例间的用力泛化关系指子用例继承了父用例的特征并增加了新的特征
-- 参与者泛化：用例间的参与者泛化是指子参与者继承了父参与者的特征并增加了新的特征
系统边界：指一个系统所包含的系统成分与系统外事物的边界线。
请从下面的材料中，为“预定房间”提取出用例图的四项元素。
材料内容：
元素提取结果-微调
用例（Use Case）：
a. 浏览网站
b. 游客注册为会员
c. 查询房间
d. 提交订单
e. 取消订单
f. 修改订单
g. 查询入住记录
h. 查询登记信息
i. 修改登记信息
j. 管理员操作（增加、删除、修改房间信息，查看订单，处理取消、修改订单）
参与者（Actors）：
a. 游客
b. 会员
c. 管理员
关系（Relationships）：
a. 关联（Association）：会员和管理员与各自的操作用例相关联。
b. 包含（Inclusion）：订单提交、取消订单、修改订单是用户操作的共同行为，可以将它们提取为抽象用例。
c. 扩展（Extension）：会员可以根据需要扩展订单操作。5
d. 参与者泛化：会员泛化自游客
系统边界（System Boundary）：
酒店预订系统的边界包含了会员、管理员和相关的操作用例。
代码生成prompt
这是一个可以使用代码生成UML图的网站：https://www.planttext.com/
请根据我下面给出的材料，生成可以在这个网站上画出用例图的代码。
用例（Use Case）：
a. 浏览网站
b. 游客注册为会员
c. 查询房间
d. 提交订单
e. 取消订单
f. 修改订单
g. 查询入住记录
h. 查询登记信息
i. 修改登记信息
j. 管理员操作（增加、删除、修改房间信息，查看订单，处理取消、修改订单）
参与者（Actors）：
a. 游客
b. 会员
c. 管理员
关系（Relationships）：
a. 关联（Association）：会员和管理员与各自的操作用例相关联。
b. 包含（Inclusion）：订单提交、取消订单、修改订单是用户操作的共同行为，可以将它们提取为抽象用例。
c. 扩展（Extension）：会员可以根据需要扩展订单操作。
d. 参与者泛化：会员泛化自游客
系统边界（System Boundary）：
酒店预订系统的边界包含了会员、管理员和相关的操作用例。
代码结果
在网站https://www.planttext.com/ 上，您可以使用PlantUML语言生成UML图。以下是用例图所需的PlantUML代码，您可以将其粘贴到网站上进行编辑和渲染。
```plantuml
@startuml
left to right direction
skinparam packageStyle rectangle
:游客:
:会员:
:管理员:
rectangle "酒店预订系统" {
usecase "浏览网站" as UC1
usecase "游客注册为会员" as UC2
usecase "查询房间" as UC3
usecase "订单操作" as UC4
usecase "查询入住记录" as UC5
usecase "查询登记信息" as UC6
usecase "管理员操作" as UC7
:会员,管理员:
UC4 <|-- "订单提交"
UC4 <|-- "取消订单"
UC4 <|-- "修改订单"
UC4 <|-- "修改订单"
UC4 <|-- "订单扩展"
UC1 -|> UC2
UC1 --> UC3
UC1 --> UC4
UC1 --> UC5
UC1 --> UC6
UC1 --> UC7
UC7 <|-- "增加、删除、修改房间信息"
UC7 <|-- "查看订单"
UC7 <|-- "处理取消、修改订单"
}
@enduml
```
您可以复制以上代码到PlantText网站上的编辑器中，然后单击"提交"按钮，即可在网站上绘制出用例图。
生成的用例图
绘图网站导出的SVG最清晰且无字体格式问题，但wps不支持导入。
在线转换图像文件 (aconvert.com)转一下png
转出来的png有灰底
可以看的出来，生成的用例图还是有不少错误的。
-
-
1-1批注
-
！关于元素提取和用例图
元素提取丢失了一些【关系】上的细节。
生成的用例图【语法？】不对
！关于生成的SVG
SVG是能从官网得到的图片效果最好的格式。
不过最好另外转换成png格式，更通用。
1-2 让元素提取prompt明确关系的细节
元素提取prompt
每一项关系是谁与谁之间的关系
用例图总共包含以下四项元素：
用例：对业务工作的描述，或者说是对系统功能的称述。
参与者：发起或出发用例的外部用户以及其他软件系统等角色。它们代表的是与系统进行交互的角色。
关系：主要包含五种。
-- 关联：用例和参与者之间的关系，描述了用例和参与者之间的交互。
-- 包含：多个用例都会发生同样的行为，将这个这些共同的行为提取为抽象用例。此关系描述了用例与其包含的抽象用例之间的关系
-- 扩展：在原有用例的基础上扩展附加用例
-- 用例泛化：用例间的用例泛化关系指子用例继承了父用例的特征并增加了新的特征
-- 参与者泛化：用例间的参与者泛化是指子参与者继承了父参与者的特征并增加了新的特征
系统边界：指一个系统所包含的系统成分与系统外事物的边界线。
请从下面的材料中，为“预定房间”提取出用例图的四项元素。
对于元素【关系】，请详细指出是什么个体之间的关系。
材料内容：
元素提取结果
根据提供的场景，我们可以提取出用例图的四项元素，分别是：用例、参与者、关系和系统边界。
**1. 用例**
- 预定房间
- 浏览房间
- 查询房间
- 提交订单
- 取消订单
- 修改订单
- 查询入住记录
- 查询登记信息
- 增加房间信息
- 删除房间信息
- 修改房间信息
- 查看订单
- 处理订单变更请求
**2. 参与者**
- 游客
- 用户/会员
- 管理员
**3. 关系**
- 关联：会员提交订单、取消订单、修改订单，查询入住记录和登记信息。
- 包含：管理员能够处理订单变更请求，这可以被提取为一个抽象的用例。
- 扩展：会员可以按房间类型、价格、日期查询房间，这可以被视为对查询房间的扩展。
- 用例泛化：用户和会员之间有用例泛化关系，表示会员继承了用户的功能并增加了新的特性。
- 参与者泛化：用户和会员之间有参与者泛化关系，表示会员继承了用户的属性并增加了新的特性。
**4. 系统边界**
- 酒店预订系统的边界包括与外部的用户、订单和房间信息的交互界面。
以上元素可以组成用例图，展现了酒店预订系统中各个角色的功能和交互关系。
代码生成prompt-删除参与者中“/会员”
这是一个可以使用代码生成UML图的网站：https://www.planttext.com/
请根据我下面给出的材料，生成可以在这个网站上画出用例图的代码。
绘制用例图所需材料：
**1. 用例**
- 预定房间
- 浏览房间
- 查询房间
- 提交订单
- 取消订单
- 修改订单
- 查询入住记录
- 查询登记信息
- 增加房间信息
- 删除房间信息
- 修改房间信息
- 查看订单
- 处理订单变更请求
**2. 参与者**
- 游客
- 用户
- 管理员
**3. 关系**
- 关联：会员提交订单、取消订单、修改订单，查询入住记录和登记信息。
- 包含：管理员能够处理订单变更请求，这可以被提取为一个抽象的用例。
- 扩展：会员可以按房间类型、价格、日期查询房间，这可以被视为对查询房间的扩展。
- 用例泛化：用户和会员之间有用例泛化关系，表示会员继承了用户的功能并增加了新的特性。
- 参与者泛化：用户和会员之间有参与者泛化关系，表示会员继承了用户的属性并增加了新的特性。
**4. 系统边界**
- 酒店预订系统的边界包括与外部的用户、订单和房间信息的交互界面。
代码结果-去掉了杂话
@startuml
left to right direction
skinparam packageStyle rect
actor 游客 as Guest
actor 用户 as Member
actor 管理员 as Admin
rectangle 酒店预订系统 {
usecase 预定房间 as ReserveRoom
usecase 浏览房间 as BrowseRooms
usecase 查询房间 as SearchRoom
usecase 提交订单 as SubmitOrder
usecase 取消订单 as CancelOrder
usecase 修改订单 as ModifyOrder
usecase 查询入住记录 as CheckInRecords
usecase 查询登记信息 as CheckRegistrationInfo
usecase 增加房间信息 as AddRoomInfo
usecase 删除房间信息 as DeleteRoomInfo
usecase 修改房间信息 as ModifyRoomInfo
usecase 查看订单 as ViewOrders
usecase 处理订单变更请求 as ProcessOrderChange
Guest --|> Member
Member --|> Admin
Member -- ReserveRoom
Member -- BrowseRooms
Member -- SearchRoom
Member -- SubmitOrder
Member -- CancelOrder
Member -- ModifyOrder
Member -- CheckInRecords
Member -- CheckRegistrationInfo
Admin -- ProcessOrderChange
}
@enduml
用例图
-
-
1-2 批注
-
+ 用户可修改中间步骤
从原材料提取出的元素可能存在一些瑕疵，这些瑕疵在后续生成的绘图代码，放在绘图网站上可能会报错。
建议【元素提取结果】和【代码结果】可以人工审阅，修改。
参与者中【用户】和【会员】其实算是同样事物，取1即可
否则在绘图网站上会报语法错误
+ 输出结构添加分隔符
每一次gpt的回复都会额外添加一些话。
其生成的代码 是由 ``` ```隔开的，这个可以提取出来
至于元素提取，建议在prompt中要求
仅输出结果不说别的
/指定输出格式
/把输出结果用指定分隔符分隔开
/不管，直接丢给代码生成prompt
！元素提取中的理解错误
之前仅暴力删除了“/会员”，在【参与者泛化】中涉及“会员”的没删除。
另外，管理员应该还和用例
- 增加房间信息
- 删除房间信息
- 修改房间信息
- 查看订单
有关联，但是被省略了。
！代码和用例图错误
我并不确定管理员是不是由【用户】经过参与者泛化得到的
然后由于管理员和四个用例之间的关联缺失，用例图中也缺失了。
2604
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
