会员登录
会员注册
本文中描述了一个框架，在该框架中可以使用任何层次的用例来形成工作量估计。为了展示这些观点，本文描述了一些简单的规范结构，这些结构具有相关的一定实践基础上的维度和规模。本文中大多是大胆的(或者应该说缺乏根据的)推测，因为我没有其他的方法来解决这个领域中缺少的工作和数据的问题。本文引用了"互连系统构成的系统"思想。
接下来，我将暂时撇开主题来介绍一些将我引入本文主题的一些背景想法。
避免功能分解吗?
功能分解的思想对于软件开发领域中的许多人来说像一个"诅咒"。我对功能分解的体验更是其中的极端(在一个很大的数据流图中有 3000 个原始转换，五层或者六层深，在除了基础设施层外没有使用任何构架的思想的情况下完成)，让我感到异常悲观。在该用例中存在的问题不仅仅与功能分解思想有关，还和下面这种想法有关，即直到分解到功能的原始层次才描述一个进程。在该层次上规格说明的长度应该少于一页。
所得到的结果难以理解――所需要的更高层次的行为如何从这些原始转换中显现出来，这一点很难搞清楚。另外，功能结构如何映射到物理结构上来满足性能和其他质量方面的要求并不是特别明显。这就产生了一种自相矛盾情况，我们一直进行分解直到达到了能够"解决问题"(原始层次)的那一层，但是，这些原始层是否能够实际上协同工作以满足更高层的目标却并不清楚或者可以被证明。没有办法以这种方式来考虑非功能性需求。从总体上讲，构架和基础设施(通讯，操作系统等等)都应该随着分解而不断演进，并且每一次分解都应该对其它分解产生影响。
那么 Bauhaus 规则"形式服从功能"又如何呢? 有许多好的设计源自功能主义方法，但也不乏一些不良设计。例如，随处可见的平屋顶结构的使用。如果您只关心屋顶的功能，并且将其完全设计为居民所需的一个房盖，那么至少在一些特定的领域中是不能够令人满意的 。这种屋顶很难防水，并且容易积雪。
现在这些问题可以解决了，但是在一个更大的范围内而不是在您已经选择的不同设计中。尽管看上去有些过时，但是形式还是应该服从所有的功能和非功能性需求，以及后续的美学要求。架构师面对的问题经常是非功能性需求经常表达模糊，并且过多的依赖于架构师的"事情就应该是这样"的经验。因此如果功能分解仅仅用来驱动构架(即分解产生了几个向下的层次并且功能的原始层次与"模块"一一匹配)和定义其接口，那么将一无是处。
像这样的考虑使我确信，在完成构架工作之前，将用例向下分解到标准化的水平(这可以通过类的协作来实现)，这没有任何意义。对于一定规模的系统而言，这些分解确实必要，(参见 Jacobson 97)但是分解的标准和实施过程至关重要――特别是当功能分解不是足够好的时候。
系统考虑
系统工程师完成功能分析、功能分解和功能分配工作(当综合一项设计时)，但是功能并不是系统构架的唯一驱动因素，一个专门的工程师团队就能够在评估不同的设计方面做出贡献。IEEE Std 1220，系统工程过程的应用和管理标准(Standard for Application and Management of the Systems Engineering Process)在 6.3 节中描述了功能分解的使用，功能分析(Functional Analysis)在 6.3.1 节，功能分解(Functional Decomposition)，和系统产品解决方案等综合在 6.5 节中。6.5.1 节包含了一些特别有趣的内容，分组(Group)功能和分配(Allocate)功能，6.5.2 节是物理解决方案的选择(Physical Solution Alternatives)。在 6.3.1 节中指出，分解是用来清晰地理解系统必须完成哪些功能，并且一般情况下一层分解就足够了。