贯彻体系结构决策

手册在体系结构中扮演什么角色？

• 地位: 手册是产品的外部规格说明, 描述和规定用户所见的每一个细节, 是结构师的主要工作产物;
• 双重内容: 必须描述所有界面在内的用户可见的一切, 同时避免描述用户看不见的事物;
• 版本化: 随着用户和实现人员的反馈, 规格说明要反复修改, 但修改必须阶段化, 进度表上应有带日期的版本信息;
• 风格要求: 清晰、完整、准确; 每条说明必须重复所有基本要素, 所以文字必须相互一致;
• 代价: 精确比生动更重要, 因此读起来枯燥乏味;
• 作者一致性: System/360 Principles of Operation 的一致完整性来自它只有两名作者;

形式化定义和记叙性定义各自解决什么问题？

维度	形式化定义	记叙性定义
优点	精确、倾向更完整、差异更明显、完成更快	显示结构性原则, 描述层次结构, 提供例子, 表达异常和对比, 解释原因
缺点	不易理解	不够精确
工具	巴科斯范式、抽象语法、Iverson 的 APL、Bell 和 Newell 的标注法	英语等自然语言

• 结论: 将来的规格说明应同时包括两种方式, 形式化保证精确, 记叙性保证可领会和讲授;

为什么不能同时用两个标准？

• 格言: "决不要携带两个时钟出海, 带一个或三个";
• 规则: 若同时采用两种方式, 必须以一种作为标准, 另一种作为辅助, 并明确划分;
• 三种实例: Algol 68 以形式化定义为标准; PL/I 以记叙性定义为主; System/360 以记叙性文字为标准, 形式化定义作派生论述;

用实现当定义有什么风险？

• 用法: 硬件或软件系统的仿真装置可以充当形式化定义, "问一问机器"即可得到答案;
• 优点: 所有问题通过试验即可澄清, 答案精确、正确、快捷;
• 缺点一: 实现过度规定了外部功能--无效语法产生副作用, 而这些"古玩"可能被广泛使用并被视为定义的一部分（如 System/360 模拟 1401 时被使用的 30 个无效操作副作用）;
• 缺点二: 尖锐问题时, 实现会给出计划外的意外答案, 这些定义往往粗糙, 在别的实现中低效或代价高昂（如乘法后在被乘数寄存器中遗留的"运算垃圾"）;
• 缺点三: 实现充当标准时, 还必须防止对实现的任何修改;

直接整合、周例会、年度大会分别解决什么？

• 直接整合: 用于建立模块间接口的语法而非语义--把被传递参数和共享存储器的声明作为设计传递物, 实现时通过编译期操作（PL/I 宏或 %INCLUDE）包含这些声明; 改接口只需增删声明并重编译;
• 周例会: 每周半天, 由所有结构师、软硬件实现人员代表和市场人员参加, 首席结构师主持; 建议以书面形式会前分发; 达成共识则通过, 否则由首席结构师决定;
• 周例会为何有效: 小组固定且每周交流无需额外培训; 参与者睿智且与产品密切相关, 没有"顾问"角色; 书面建议集中注意力并强制决策; 首席结构师被明确授予决策权, 避免妥协和拖延;
• 年度大会: 典型持续两周, 在手册冻结前夕召开; 议程约 200 条, 逐条决策, 每天早晨参与者拿到更新后的手册说明;
• 年度大会的作用: 解决堆积的小要求、公开问题和不愉快; 让每个人都参与, 从而更透彻理解约束与决策之间的关系;

多重实现为什么能强制规格说明？

• 常见情况: 大多数项目中机器与手册出现不一致时, 人们忽略手册, 因为改手册更容易、成本更低;
• 多重实现下的反转: 存在多个实现时, 如实遵从手册更新机器所耗延迟和成本更低;
• 语言定义的应用: 若一开始至少有两种以上实现, 定义会更整洁和规范;
• 前提条件: System/360 的结构师同时拥有充足的工作时间和与实现人员相同的策略影响力;

电话日志和产品测试起什么作用？

• 电话日志: 结构师记录每个问题和相应回答, 每周合并整理并发布给用户和实现人员;
• 使用规则: 鼓励实现人员打电话询问结构师而不是自行猜测, 且答案必须是可以告知每个人的权威性结论;
• 独立产品测试小组: 按规格说明检查机器和程序, 充当麻烦的代言人, 查明每个可能的缺陷和相互矛盾处;
• 地位: 项目经理最好的朋友就是他每天要面对的敌人; 必须与设计同时实施, 是使设计决策得以贯彻的必要手段;