同一套租赁代码可以画出多张准确的图，评审仍然可能遗漏问题。客服询问重复提交是否产生两次预留，开发者看到类关系，运维看到部署节点，却没有人说明重启后的回执从哪里恢复。图本身没有画错，缺失的是从问题到答案的组织关系。

第 E09 篇建立了与真实 HTTP 实验一致的多视图。本篇继续使用这份实现，将干系人、关注点、视点、视图、决策和质量场景放入一份可检查的描述。实验目标是拒绝遗漏关注点与矛盾边界；它不构成标准认证，也不以文档完整代替运行能力。

三份资料各自解决什么问题

ISO/IEC/IEEE 42010:2022 面向架构描述。本篇读取了 ISO 官方公开摘要，用它确认标准主题和版本，没有读取付费标准全文，因此不逐条声称满足规范条款。公开摘要能够支持术语方向，不能代替完整符合性评估所需的条文、解释与审查证据。

SEI 的 Views and Beyond 关注以视图为基础记录架构，同时记录超出单张视图的信息。本文依据 Paul Clements 等人的第二版官方书目介绍与 SEI 培训说明。引用范围限于已读取资料，不把其他作者著作误写成这本书。对当前样例有用的部分，是按读者需要选择视图，并维护视图之间的关系。

arc42 提供十二个文档章节，用来安放目标、约束、上下文、方案、构件、运行、部署、横切概念、决策、质量、风险和术语。它能减少文档组织的遗漏，却不会自动推导一个正确架构。一份填满章节的文档，仍然可能把内存仓储写成数据库，或者把目标部署写成现状。

这三种资料并不需要竞争成为唯一模板。本篇采用自己的有限数据结构记录关注点及视图映射，用 arc42 检查章节目录，再用实际源码和运行证据约束文档事实。检查规则属于本实验，不冒称是任何框架官方提供的完整机器验证器。

先登记需要答案的人

租赁操作人员关心两件事：重复确认不能额外占用设备，非法输入不能改变既有合同。开发者关心源码可追溯，能够从视图元素找到实际实现。运维关注进程边界以及重启恢复，因为部署和恢复的判断依赖状态到底位于哪里。

这些角色是本教学案例的需求假设，不是真实企业访谈结果。文档将它们写成 stakeholder 到 concern 的映射，评审者可以修改、补充或删除假设，但不能让已经登记的关注点悄悄消失。新增安全审计角色后，如果没有任何视点覆盖认证与授权，检查应当提醒描述尚不完整。

关注点应有可以讨论的含义。“高性能”过于宽泛，无法决定看哪张图；“一次确认响应期间是否调用远程维修服务”则能定位到运行视图和部署视图。对尚未确定的响应时间目标，应记录待决策，而不是随意填入毫秒数来制造可测量的外观。

角色也不能等同于图的读者权限。运维可以阅读开发视图，开发者也需要知道业务重放的语义。关注点映射说明哪些问题必须得到解释，不规定每种人只能阅读某个章节。这样能避免文档按组织边界切成互不相通的孤岛。

视点规定怎么描述，视图描述当前系统

本实验定义 runtime、development、deployment 三个视点。运行视点覆盖重复预留和非法输入，开发视点覆盖源码追踪，部署视点覆盖运行边界与恢复。相应视图引用 E09 的实际工件，并声明一个进程、内存存储的共同事实。

视点相当于描述约定：需要哪些元素、关系、边界和证据。视图则是这套约定在当前租赁系统上的具体内容。把两者混写，容易出现“部署图模板已存在，所以部署事实已确认”的错误。模板只能说明等待填写什么，不能说明系统已经怎样运行。

下图表达关注点怎样追到证据。箭头是文档对应关系，不是业务调用。一次 HTTP 请求不会沿着这些箭头执行，但评审者能够沿着它定位主张的依据。

flowchart TD
  S["干系人：租赁操作人员"] --> C["关注点：重放不重复预留"]
  C --> P["运行视点：请求与状态变化"]
  P --> V["运行视图：确认和重放路径"]
  V --> Q["质量场景：同请求号重复提交"]
  Q --> E["第38篇真实HTTP断言与轨迹"]

跨视图对应关系需要明确同一身份。本例的 repository 在开发视图指向 MemoryRepository，在运行视图参与事务，在部署视图属于本机 JVM。它们描述的是同一实例职责，而不是三套存储。术语表把 commit 限定为内存快照提交，避免读者把日志词汇理解成磁盘持久化。

当前检查器只要求 correspondence 非空，并由正文解释其具体含义；它没有实现通用对应关系逻辑求解。文件存在和映射存在不能证明所有架构语义正确。若后续增加多实例部署，需要把实例身份与逻辑职责区分，再添加有区分力的跨视图规则。

十二个章节怎样落到这个案例

简介与目标记录租赁确认及主要质量问题。约束写明 Java 二十一、单 JVM 和教学输入限制。上下文与范围解释 HTTP 客户端以及固定维修查询的关系。方案策略说明模块门面、应用服务、内存仓储的选择理由，这些内容在模型中各有对应条目。

构件视图登记模块和源码，运行视图保留确认、重放、非法输入路径，部署视图如实写出回环网络与同 JVM。横切概念记录请求身份和事务边界，架构决策说明为何采用内存状态，以及这一决定暂时放弃了哪些恢复能力。

质量章节不只放形容词，而是引用具体场景。风险章节记录进程退出丢状态、缺少认证和远程依赖故障实验。术语表解释 Module 是内部类、commit 是内存提交。十二个栏目因此各有具体职责，不需要为每个栏目凑同样长度的段落。

模型检查验证十二个编号均出现且内容非空，并不判断段落是否足够深入。这是刻意保留的边界：章节清单适合自动检查，决策是否合理仍需要读者审阅。如果某节确实不适用，应写清理由；当前入口也会拒绝空字符串，避免把空白章节视为完成。

决策记录还需要描述后果。本例选择内存仓储降低了独立运行成本，同时使重启恢复没有实现。读者若计划引入数据库，需要重新评估事务、请求回执持久化和事件发布窗口，而不是只把部署图里的“内存”替换成数据库图标。

质量场景必须带上运行状态

重放场景的刺激是同一请求号再次经 HTTP 提交，响应是继续返回确认，度量是有效预留数仍为一。非法输入场景的刺激是提交感叹号，响应是返回错误，度量是前后快照相同。确认场景则要求正常请求改变真实仓储状态。这些场景在第 38 篇实际入口中运行。

E10 检查器调用 E09，E09 再调用第 38 篇。原始输出保留真实回环地址、运行边界和 TRACE，E10 只接受输出中已经出现的断言标签作为 VERIFIED_LOCAL 的依据。因此删除底层运行或改坏断言，不能依靠文档中的状态字段继续通过。

恢复场景不同：刺激是进程退出并重启，期望是请求回执和设备占用得以恢复，目标可写成不丢已经确认的业务状态。但当前内存实现没有完成这项实验，因此状态为 NOT_RUN，原因直接写出缺少持久化恢复路径。它是待解决需求，不是一次通过的测试。

下图区分已跑证据与尚未实现的目标。两条分支都属于有效文档内容，但只有上面的分支能够支持当前能力声明。

flowchart TD
  Q["质量场景目录"] --> R["确认、重放、非法输入"]
  R --> H["真实HttpClient → HttpServer"]
  H --> A["断言与原始日志：VERIFIED_LOCAL"]
  Q --> D["退出后恢复回执与占用"]
  D --> M["当前只有内存状态"]
  M --> N["NOT_RUN：等待持久化与恢复实验"]

本地通过也不能升级成生产质量承诺。实验没有认证、真实网络分区、数据库故障或多节点竞争。一次顺序重放只能说明这个实现对该输入的行为，无法证明所有请求规模下的幂等性、延迟分位数或高可用性。文档应让读者看见证据的条件，而不只是绿色状态。

能力与证据标签之间还要有对应关系。当前检查器只允许重放、非法输入、部署边界分别引用各自的运行断言；恢复能力没有已验证标签。因此，即使某条 HTTP 成功日志真实存在，也不能用它为未运行的恢复场景签署 VERIFIED_LOCAL。

三种坏文档怎样被拒绝

第一份错误样本删除部署视点，保留运维关于运行边界与恢复的关注点。检查器计算所有已登记关注点与视点覆盖集合，发现剩余关注点无人回答后退出一。失败发生在模型层，不是因为 Java 编译或端口绑定失败，原始 stderr 保留相应断言信息。

第二份错误样本把某个视图的进程数改成二。实际基线仍是同 JVM，其他视图也仍声明一个进程，因此检查器以跨视图边界矛盾拒绝该文件。反例只修改一个边界事实，能够区分检查器是否真正核对这一约束。

正常文件、缺失关注点、矛盾边界分别独立执行，每次都先跑真实基线。代价是重复编译与 HTTP 运行，但这避免复用过期日志造成误判。对于更大系统，可以把带摘要和时间的运行证据作为独立输入，不过必须同时建立新旧证据的匹配规则。

这样的检查不证明关注点集合已经穷尽。登记表本身仍来自需求假设，漏掉一个从未登记的角色不会被集合运算发现。评审需要同时追问问题清单是否完整、证据是否相关、未运行目标是否被误标，自动检查只承担已经明确的有限规则。

第三份错误样本保留恢复响应与零丢失目标，却把状态改成已验证，并借用正常 HTTP 确认标签。检查器按能力与证据映射拒绝该样本。该反例说明真实性与相关性需要同时成立：一条真实的成功日志也可能被错误地用于另一个能力。

下载包与继续修改

1
bash examples/software-modeling/labs/E10/run.sh

入口需要 Python 标准库、JDK 二十一和允许本机回环监听的环境。错误文件可以作为入口参数传入，所有命令、版本、退出码及原始输出位于对应 evidence/E10 目录。下载包包含 E09 与第 38 篇的编译依赖，解压后不需要引用作者工作区里的绝对路径。

修改架构描述后应重新运行检查，并同步源码摘要。若修改的是恢复需求而实现没有改变，应继续保留 NOT_RUN；若增加了真实数据库与退出恢复实验，才有条件扩展证据标签和质量场景状态。文档中的一个词从“目标”变成“现状”，应当能找到相应运行证据。

这份架构描述的用途，是让评审发现哪些问题已有有限答案，哪些问题只有目标，哪些视图互相矛盾。标准、书籍和模板提供组织思路，当前能力仍由代码、运行条件和可复现结果来界定。

下载累计实验源码与证据

参考资料