上下文图的内容原则与形式原则

上下文图（Context Diagram）是”辅助说明”需求范围的方式，清晰描述待开发系统与周围所有事物之间的界限与联系，可以由市场部门用PowerPoint随意绘制，也可以由架构师用UML用例图的顶级视图绘制。它的价值在于始终以”待研发的系统”为中心：待研发系统位于图的中心，所有和它有关联的系统、环境、活动围绕在周围，但上下文图不提供系统内部结构的任何信息，目的是通过明确外部因素和事件，促进更完整地识别系统需求和约束。这可以归纳成两条判断原则：内容原则——只关注本系统以及和本系统有关联的因素，既不关注内部功能也不关注内部结构；形式原则——明确标识出要研发的系统、保持它为黑盒、画在图的中央，其他相关因素环绕周围。这两条原则最容易在实践中被混淆的地方，是把”需求范围框图”或”总体架构图（物理视图）”误当成上下文图——书中用银行综合前置系统的三张图做对比：满足两条原则的才是真正的上下文图（中心是”综合前置系统”这个黑盒，周围环绕主机、外挂、第三方、渠道4类关联系统）；而”银行核心系统总体架构图”内容上讲的是整个核心系统而非综合前置系统本身、形式上也不是”中心+四周”的组织方式，实质是物理视图而非上下文图；”综合前置系统的架构图”则进一步展开了内部设计决策（中心前置业务平台/分行前置业务平台/网银接入平台等具体架构元素及其部署位置），这已经是设计成果而非需求范围说明。上下文图最终能明确四件事：哪个系统是待研发的软件系统、哪些方面在系统之外、谁使用该系统、此系统需要和哪些相关软件系统交互。

结构图：

flowchart TB
    subgraph 上下文图["上下文图（满足内容+形式两原则）"]
        direction TB
        Center1["综合前置系统\n（黑盒，不展开内部）"]
        Center1 --- 主机
        Center1 --- 外挂
        Center1 --- 第三方
        Center1 --- 渠道
    end
    subgraph 总体架构图["总体架构图/物理视图（内容+形式均不满足）"]
        direction TB
        Whole["银行核心系统整体\n（非'中心+四周'组织）"]
    end
    subgraph 架构图["综合前置系统架构图（设计成果，非需求范围）"]
        direction TB
        A2["中心前置业务平台"] --- B2["分行前置业务平台"]
        A2 --- C2["网银接入平台"]
        B2 --- D2["电话接入前置平台"]
    end