component_sequence naming-consistency check ignores 'actor' participant type, contradicting own docs example
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
调研方向
首先从 plantuml/parser/puml_parser/src/sequence_diagram/ 开始,经过 validation/core/src/models/sequence_diagram_models.rs,追踪到 component_sequence_validator.rs 中的 ParticipantType::Actor。将 bazel/rules/rules_score/docs/user_guide/architectural_design.md 中记录的 actor 示例与命名和接口检查进行比较。当 actor participant 仍然可区分,并且被排除在相关一致性检查之外,同时不削弱对已验证 participant 的检查时,即视为完成。
由索引模型根据 Issue 内容生成。
描述
Summary
component_sequence_validator's naming-consistency check (check_participant_aliases) enforces exact SET equality between <<unit>> aliases in component diagrams and all participant aliases used in sequence diagrams. This appears to discard the PlantUML actor participant type, even though the parser tracks it, and even the tool's own documentation example looks like it would fail this check.
Observed behavior
In validation/core/src/models/sequence_diagram_models.rs, SequenceDiagramIndex::from_diagrams builds used_participants purely from interaction.caller/interaction.callee (and ret.caller/ret.callee), with no distinction based on participant kind (participant vs actor vs boundary, etc.):
if !interaction.caller.is_empty() {
used_participants.insert(interaction.caller.clone());
}
if !interaction.callee.is_empty() {
used_participants.insert(interaction.callee.clone());
}
component_sequence_validator.rs::check_participant_aliases then requires this set to equal exactly the set of <<unit>> aliases from the component diagrams (bidirectional check: "Missing sequence participant" and "Unexpected sequence participant").
Meanwhile, the PlantUML sequence-diagram parser (plantuml/parser/puml_parser/src/sequence_diagram/src/syntax_parser.rs) does parse actor as a distinct ParticipantType::Actor ("actor" => Some(ParticipantType::Actor)), and the component-diagram parser has an equivalent ComponentType::Actor. This information appears to be dropped before it reaches the FlatBuffers model consumed by SequenceDiagramIndex.
Expected behavior
architectural_design.md itself documents the following canonical dynamic-view example:
@startuml MySeooc_WriteSequence
actor Caller
participant KeyValueStore
participant StorageBackend
Caller -> KeyValueStore : write(key, value)
KeyValueStore -> StorageBackend : flush()
StorageBackend --> KeyValueStore : OK
KeyValueStore --> Caller : Result::Ok
@enduml
Here Caller is declared with the actor keyword and is not a <<unit>> in the paired static diagram (only KeyValueStore and StorageBackend are). Based on the validator code, Caller would be collected into used_participants (it appears as caller/callee of two interactions) and then fail "sequence participant not found in component unit aliases," since no <<unit>> alias named Caller exists.
Expected: actor-typed sequence participants represent entities outside the validated architectural boundary (external callers, consumers, generated/out-of-tree code, etc.) and should be excluded from the naming-consistency SET-equality check — consistent with standard UML "actor" semantics and with the tool's own documented example.
Why this looks like a tooling bug, not a deliberate design choice
- The parser already distinguishes
actorfromparticipant/boundary/etc. at the syntax level for both sequence and component diagrams. - The static-side validator (
bazel_component_validator) does filter by stereotype (<<unit>>/<<component>>/<<SEooC>>), ignoring plain/unstereotyped elements — the dynamic-side validator has no equivalent filter, seemingly because participant-kind information is lost between parsing and the FlatBuffers model consumed here. - The docs' own reference example (
architectural_design.md, Dynamic Architecture section) would not pass validation as written, based on this code path.
Impact
There's currently no supported way to document an interaction with an out-of-boundary actor (e.g. an external caller, or code generated outside the dependable element's own Bazel package) in a sequence diagram without either:
- inventing a fictional Bazel
unit()purely to satisfy the validator, or - omitting the actor from the sequence entirely and only referencing it in prose/notes.
Suggested fix
Preserve ParticipantType/ComponentType (or at least an is_actor flag) through to the FlatBuffers model, and exclude actor-typed participants from the naming-consistency and interface-consistency checks in component_sequence_validator.rs. This would align enforced behavior with the tool's own documented example and with standard UML actor semantics.
Suspected area
plantuml/parser/puml_parser/src/sequence_diagram/(parser retainsParticipantType::Actor, downstream FlatBuffers model may not)validation/core/src/models/sequence_diagram_models.rs(used_participantscollection, no kind filter)validation/core/src/validators/component_sequence_validator.rs(check_participant_aliases)bazel/rules/rules_score/docs/user_guide/architectural_design.md(documented example that appears inconsistent with current validator behavior)
- 主要语言
- Rust
- 星标
- 8
- 派生
- 37
- 平均合并
- 1 天 9 小时
- 30 天内合并 PR
- 22
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
eclipse-score/tooling 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 48/100
eclipse-score/tooling#458 · 1 条评论 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
eclipse-score/tooling#452 · 1 条评论 ·
维护者通常 2 天内回复
-
coverage: integration mode — scope external module roots (reference_integration)可能重新可做 @dcalavrezo-qorix 于 34 天前认领,目前没有进行中的 PR。 未关闭
eclipse-score/tooling#445 · 1 条评论 · 已指派 1 人 ·
维护者通常 2 天内回复
-
Migration path rst to trlc可能重新可做 @antonkri 于 37 天前认领,目前没有进行中的 PR。 未关闭
eclipse-score/tooling#441 · 已指派 1 人 ·
维护者通常 2 天内回复
-
coverage: on-target (QNX) coverage support in the shared coverage module可能重新可做 @dcalavrezo-qorix 于 44 天前认领,目前没有进行中的 PR。 未关闭
eclipse-score/tooling#427 · 已指派 1 人 ·
维护者通常 2 天内回复
查看 eclipse-score/tooling 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 88/100
aws-samples/sample-pacer#76 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 86/100
axodotdev/cargo-dist#2523 ·
维护者通常 2 天内回复