[观点]架构师如何界定项目边界 把握系统全局

关键词：架构师 | 作者：王小虎 | 收藏这篇资讯

导语：架构方法论的重要性已经毋庸置疑，传统方法已经越来越不能适应日益变化的IT架构。然而，架构方法论实践过程中遇到的挑战和陷阱依然无处不在。为此，IBM软件集团大中华区合作伙伴技术支持总经理王小虎撰写了“架构师挑战与武器”开篇文章，后续内容将根据CSDN网站上“架构师挑战”的调查投票结果邀请专家撰写专稿，陆续刊登于CSDN网站。

挑战——如何界定项目边界 把握系统全局

现实挑战：新上一个IT系统，往往不是独立存在的，一般都需要与外围实体和系统进行交互，而需要集成交互的内容很多，哪些集成是本系统需要实现的呢？同时，因为时间紧张，有一些集成工作需要在第一阶段去完成，但另外还有一些工作需要放到第二阶段，怎样界定系统的边界呢？

传统的应对办法：与客户进行多次会议研讨，反复讨论，用文字零星地记录。

危害：

场景一，突然有一天客户说，我们系统的客户数据应该从SAP中取得，而订单数据需要送到数据仓库中去。突然冒出来这两个新的集成任务，增加了工作量不说，另外由于没有提前协调这两个系统的实施商，还得从预算中抠出一部分费用让他们做一定的开发修改，造成项目延期、预算超支。

场景二，临上线时发现，该系统和办公系统的集成需要跨越内外网，内外网不允许直接连接，需要双方都开发新的连接组件透过网闸来连接。

传统办法的症状分析：缺乏直观正式的工作件来记录系统边界，记录系统范围的文字很多，但却很容易忽略和遗漏重要的系统以及约束。

架构师的十八般武器之一：用好系统环境图，高瞻远瞩把握全局

系统环境图是什么？系统环境图用图形结合文字的方式直观地描述系统的边界。它把系统当成一个黑盒子。让待建系统与其他需要与待建系统接受和发送信息的外部实体在一个图中展示出来，构成一幅系统级别的视图。

系统环境图长什么样子？图1显示了一个银行应用程序的系统上下文关系图例子。

• 将待构建系统表示为黑盒。
• 描述其与外部实体（系统和最终用户）的交互。
• 标识系统和外部实体间的信息和控制流。

系统环境图的四大元素

Actor和Users

表明与系统交互的Actor和用户。

通道

用户将使用不同的通道来访问系统。具体包括通道及通常使用此通道与系统交互的角色和用户的类型、通道使用的设备、通道支持的网络和带宽，用于在系统之间发送和接收数据的访问协议。

外部系统

必须记录系统在执行所需的功能时与之交互的外部系统。

信息流

信息流是在该系统和外部系统、用户角色和通道间流动的内容。信息可以传统批量或实时方式传送。将信息及其特征作为系统环境的一部分加以记录在定义总体软件架构时极为重要。

对于当期要实现的集成，使用实线表示；对于当期不实现但是未来需要实现的集成，可以用虚线表示。

系统环境图也有多种视图

从功能层面和运行层面来看。系统环境图可以是功能层面的，描述功能层面需要集成的信息。系统环境图也可以运行层面的，描述外部系统或者组织坐落的位置、连接的方式、透过的协议。

系统环境图也可以是逻辑的和物理的。比如对于外部用户和角色，在逻辑的角度，会考虑用Actor来抽象化描述用户；在物理的角度，会用User来记录有多少用户以及他们所处的位置。

如果剔除外围系统，逻辑功能层面的系统环境图有点像最高级别的用例集合。使用系统环境图的好处是显而易见的， 包括以下内容。

• 可以快速地框定系统边界。透过系统环境图，可以表明将哪些外部实体纳入整体解决方案的范畴内，以清晰地框定系统的边界。
• 可以与客户直观地展示和讨论。如果拿着一个冗长的记录不全的文档去和客户交流，客户很容易遗漏一些外围实体、通道以及重要的信息流。
• 容易厘定责任。图形是精确化的建模方法。通过图形来圈定本次要实现的内容，避免模棱两可的文字。如果将来还需要集成新的系统，还可以和客户协商新增需求部分的费用。
• 避免未来需求和现在需求纠缠不清，对于系统能建立一个整体的概念和认识。
• 帮助梳理大的非功能需求。在系统环境图的文字部分，记录信息交互的特性。比如：将信息分类为批处理、实时或半实时类别，每个单位时间必须支持的事务信息，组成典型事务的数据类型，每个事务通常涉及的数据量，事务执行的频率。
• 指导后续设计。可以指导后续用例、组件模型和运行模型的设计。用例是系统环境图的逻辑功能层面的细化。组件模型是功能层面的细化，运行模型是物理层面的细化。
• 赢得客户的信任。使用正规的工作产品， 可以更好地与客户沟通需求，可以帮助客户梳理对系统整体的认知，正规的做法让客户心里更有底，从而赢得客户的青睐和信任。

关于系统环境图的更详细的资料，可以参见developerWorks网站文章《编写软件架构文档说明，第2部分：开发系统上下文》。

备注：架构师挑战与武器系列文章之后续内容敬请关注，包括：进行合理的架构决策，重用架构资产，设计高性能系统、如何合理估算系统尺寸和资源，设计安全的架构，设计高可靠性的架构，设计灵活高效的信息架构，画架构总揽图，设计可集成的系统，找到正确的组件，正确的摆放组件，灵活的领域模型，设计可运维的系统，如何找到合理的服务，如何把握架构设计的粒度，编写合理的架构文档，评估架构可行性，规避架构设计中的风险。