Douglass 博士曾在几百个项目上提供过超过 30 年的咨询。在这一面向基于模型系统工程的十大建模建议清单里，他分享了他的观点及深度经验。在过去 20 年里，系统工程领域经历了重大的改变。尤其是，系统工程从基于文本文档描述分析
转变为基于模型方法，从而实现抽象出系统的核心特性来更好地关注和应用严格的分析工作。这也就是说，很大程度上，得益于统一建模语言（Unified Modeling Language，UML）使用的日渐广泛，导致另一伴随衍生出的标准建模语言，系统建模语言（Systems Modeling Language，SysML）也得以发展。我曾有幸参与到制定这两项标准的工作当中。作为一名工作了很长一段时间的系统和嵌入式软件工程师，我为标准提供了来自系统工程师的分析性和代表性的需求。我的建议同样帮助确定这些建模语言在其制定目标上的适用性，即“支持和
改善系统工程的实践现状”。
在我过去工作的几十年里，我曾工作在多种系统工程环境中，从小型可植入">医疗设备到通讯系统，再到直升机航空电子设备和宇航设备。我曾见过多种不同精确度、完成度、正确性和价值的模型。这一经验和多样性帮助我形成那些适用于系统工程建模的重要观点，以及明确哪些，换句话说是“不那么有效”的观点。我与您分享我相信的，关于为系统工程有效进行建模的十大洞察。当然，这并不完全包括我关于这一主题所有想说的观点，不过还是让我们开始吧。
10：忘掉 7 ± 2
打断我，如果您曾经听到过这句话：“所有模型图都应包括七个元素，或加减二。”（"All diagrams should contain seven elements, plus or minus two."）
您是否曾经质疑这句话的出处？
在 1956 年，George Miller 曾在《心理学评论》（Psychology Review）期刊发表过一篇文章，题为“魔法的数字‘七’，或加减二：我们处理信息的极限能力。”（"The magical number seven, plus or minus two: some limits on our capacity for processing information."）这篇文章研究关于刺激回忆（stimulus recall）的两个方面。第一方面称为一维绝对判断（one-dimensional absolute judgment），这是关于我们区分一组在一维上发生变化的刺激（例如，尺寸或颜色），并返回一个先前已学会的反应（例如按下按钮）作为结果的能力的度量。另外一个方面的研究是记忆广度（memory span） – 我们回忆一系列展现过后即从眼前移走的物品的能力。巧合的是，这两方面都表明这些物品的数量是有限的（50% 准确度），即七个元素或加减二。
在本文这里一个有趣的问题是，“这跟现在要把多少东西放在一个模型图上有何关系？”
回答是，当然，“毫无关联。”
需要记住的是，与 Miller 博士所做的实验不同的是 – 在他的实验中他展现了一系列元素，随后移除该系列元素，然后在一段时间延迟后让实验参与者根据记忆复述该系列元素的清单 – 而在模型图上的元素在您看图的时候它们仍然在您面前。
另一方面，一个有任意合理尺寸的模型往往会有几百上千个元素。显然，您也同样无法将所有元素都放在一张模型图上。所以您应该怎么做？
作为 Harmony 过程（Harmony Process）的作者之一，我的建议是：每一个模型图都应有一个想要展示的单一概念或问题，并且把所有与该概念相关的元素都展示出来。这也被称为模型图的“任务”。
有些模型图拥有非常清晰的任务。例如一个 UML 或 SysML 的状态图，展现了系统中一个单独的类（class）或模块（block）的状态行为。其他模型图在其用途方面则更灵活。
序列图（Sequence diagram），例如，可以用于 目的 展示在一个用例（use case）的执行过程中，系统在其环境中如何与参与者（actor）进行交互 捕获围绕一个用例的场景（scenario）中的需求 展示一个特定案例中的内部设计元素之间如何交互 展示随着时间而展开的利益之间的协作 定义一个期待的输入-输出（input-output）转换序列 展示一个测试用例（test case） 重现系统在某些特定测试用例里的真实行为 展示一个测试结果
类图（class diagram）或块图（block diagram）还可以更加灵活。类图或块图的常见任务陈述包括：
展示实现一个大规模行为的协作所涉及的设计元素，例如一个用例中的设计元素 展示需求分配到结构化元素或用例上的分配情况 展示一个一般化的分类学（generalization taxonomy） 展示一个模型的组织情况（或称为“包图”，"package diagram"）
注解：
UML 及 SysML 标准在区分模型图的类型（types）及其使用（uses）的差别上做得很差。任务图（task diagram）是目的主要是用于展示并发架构的类图（class diagram），正如结构图是目的为了显示类内部结构的类图一样。但两者都是类图。
展示架构方面，例如： 子系统及组件架构 部署架构（不同的工程实践规程的职责分配情况） 并发及资源管理架构 分布式架构 可靠性架构（包括安全性、可靠性及安全保护） 展示设计模式抽象 展示实例快照（也称为“对象图”，"object diagram"） 展示软件元素之间的接口 展示工程规程之间的接口 展示一个结构化类的结构（也称为“结构图”，"structure diagram"）
任务（mission）的概念表示每一个模型图只应尝试回答一个问题或支持一条特定原因。在我的经验里，多数很差劲的模型图都失败在它们不是没有清晰的任务，就是尝试去回答过多的问题。
我喜欢清晰，并且喜欢在模型图上标注注解来清晰地陈述模型图的任务。图 1-3 展示了一个典型例子。
图 1. 任务：展示用例被分配的需求
图 2. 任务：展示实现一个用例所需要协调的设计元素
图 3. 任务：为用例展示一个使用场景（包括前置条件和后置条件）
这显然表明同样一个元素拥有在不同的图中展示的潜在可能，但这不是个问题。许多优秀的建模工具都会维护一个语义信息的存储库，来作为关于该模型的唯一可信信息来源，而模型图总是描绘许多围绕这些可信信息的子集。
这就是我的清单上的第十条建议。下面您将会了解到第九条，“所有模型都是抽象，但只有一部分是有用的”。敬请期待。