基本要求
请在看完后告知我①价格②交付时间
格式要求
- 必须使用startUML,画图符合UML图基本标准
- 严格按照文字说明来画
- 画图结果导出为.mdj(startUML的保存格式),多张图放在同一个.mdj文件中
如这里就是有三张图
以下是需要你画的图
图1 新闻搜索-顺序图
【新闻搜索顺序图】
对象排列(从左到右):【:App】 → 【:Gateway】 → 【:ArticleSearchController】 → 【:ArticleSearchService】 → 【:ApUserSearchService】 → 【:EsService】 → 【:Elasticsearch】
生命线:各对象下方贯穿全流程的垂直虚线
消息交互(时间顺序,从上到下):
1. 【:App】向【:Gateway】发送「/api/v1/article/search/search」消息(同步消息)
- 用户在App搜索框输入关键词并点击搜索按钮,发送HTTP POST请求
2. 【:Gateway】向【:ArticleSearchController】转发「search(UserSearchDTO)」消息(同步消息)
- 网关根据路由规则将请求转发到搜索服务的控制器
3. 【:ArticleSearchController】向【:ArticleSearchService】发送「search(UserSearchDTO)」消息(同步消息)
- 控制器调用服务层处理搜索请求
4. 【:ArticleSearchService】内部执行「校验搜索参数」(自消息)
- 检查关键词是否为空,设置默认的最小时间等
5. 【:ArticleSearchService】向【:ApUserSearchService】发送「insert(UserSearchDTO)」消息(异步消息)
- 异步记录用户搜索历史
6. 【:ArticleSearchService】内部执行「构建搜索请求」(自消息)
- 创建Elasticsearch查询条件,包括关键词匹配、分页、高亮和排序等
7. 【:ArticleSearchService】向【:EsService】发送「search(SearchSourceBuilder, Class, String)」消息(同步消息)
- 将构建好的查询请求发送给ES服务
8. 【:EsService】向【:Elasticsearch】发送「搜索请求」(同步消息)
- ES服务将请求转发给Elasticsearch引擎
9. 【:Elasticsearch】向【:EsService】返回「搜索结果」(返回消息)
- Elasticsearch执行查询并返回结果
10. 【:EsService】向【:ArticleSearchService】返回「PageResponseResult」(返回消息)
- ES服务将查询结果封装为分页响应对象
11. 【:ArticleSearchService】内部执行「处理搜索结果」(自消息)
- 处理图片URL和静态资源路径等
12. 【:ArticleSearchService】向【:ArticleSearchController】返回「ResponseResult」(返回消息)
- 服务层将处理后的结果返回给控制器
13. 【:ArticleSearchController】向【:Gateway】返回「ResponseResult」(返回消息)
- 控制器将结果返回给网关
14. 【:Gateway】向【:App】返回「搜索结果JSON」(返回消息)
- 网关将结果返回给前端App
条件分支:
1. 若搜索参数校验失败(alt分支):
- 【:ArticleSearchService】向【:ArticleSearchController】返回「参数错误响应」
- 流程提前结束
关键说明:
- 搜索结果包含标题高亮处理,便于用户识别匹配内容
图2 系统实体-类图
【系统实体类图】
实体类:
1. ApUser
- 属性:id(主键)、salt、name、password、phone、image、sex、is_certification、is_identity_authentication、status、flag、created_time、role
- 描述:用户基本信息实体类
2. ApArticle
- 属性:id(主键)、title、author_id、author_name、channel_id、channel_name、layout、flag、images、labels、likes、collection、comment、views、province_id、city_id、county_id、created_time、publish_time、sync_status、origin、static_url、uniquekey、status
- 描述:文章核心信息实体类
3. ApArticleContent
- 属性:id(主键)、article_id、content
- 描述:文章详细内容实体类
4. ApTimeline
- 属性:id(主键)、title、content、publish_time、similarity、generated_time
- 描述:热门主题时间线实体类
5. ApBehaviorEntry
- 属性:id(主键)、type、entry_id、created_time
- 描述:用户行为实体类
6. ApUserSearch (MongoDB)
- 属性:id、entry_id、keyword、status、created_time
- 描述:用户搜索记录实体类
7. AiCache
- 属性:id(主键)、article_id、opt、params、ai_response、created_time
- 描述:大模型API回复缓存实体类
实体关系:
1. ApUser ← → ApBehaviorEntry
- 关系类型:一对一关联
- 描述:一个用户对应一个行为实体
2. ApArticle → ApArticleContent
- 关系类型:一对一组合
- 描述:一篇文章包含一个内容对象
3. ApArticle → ApTimeline
- 关系类型:一对多关联
- 描述:一篇文章可以出现在多个时间线中
4. ApUser → ApTimeline
- 关系类型:一对多关联
- 描述:一个用户可以有多个时间线项
5. ApBehaviorEntry → ApUserSearch
- 关系类型:一对多关联
- 描述:一个行为实体可以有多条搜索记录
6. ApArticle → AiCache
- 关系类型:一对多关联
- 描述:一篇文章可以有多条AI处理缓存
注意事项:
- ApUserSearch虽然存储在MongoDB中,但在类图中仍然作为核心实体(画图中可备注,要无视也行)