①这些内容可能被称为“库”,也可能被称为“构件”,还可能被称为“依赖项”,如此等等。②例如对象库或类库的交付物称为“类包”(class package),可执行应用及其完整交付称为“安装包”(install package),而linux/debian环境下一个产品或产品系列的发布称为“debian package”。

没有软件开发人员会用代码去“写一个模型”,反而是在系统的分析建模完成之后，用代码去描述上述“建模的结果”(即模型)。换言之，编程语言所描述的模型，其实只是建模结果的一个方面，这就如同书面语言、口头语言等都只是语言的一个方面。我们若是仅局限在一个方面去讨论模型本身，便又回到了盲人摸象的困局。

正因为模型描述的是现实目标的一个或多个侧象——这也如同编程语言中的数据并不能描述现实目标的整体一样，所以不同的人从不同的角度观察和理解现实目标时所得到的模型也就不一样。最终在建模过程中所讨论的仅是对系统的一个相对“清晰一些”的理解，所以在建模过程中也往往会有“识别(出某个模型)”这样的说法。

我们不可能也不必要描述系统的全像，这是必然的。因此到底要描述哪些方面，就成了一个实际问题。而这个问题的解，要追溯到问题产生之处。也就是说：谁需要建模?谁做建模?以及作为中介的模型，表达了谁与谁之间的沟通需求?总的来说，一个“建模者”所面临的需求主要来自这几个方面，

建模者并非一个单一职能的角色，因为整个系统将涉及多个不同领域、不同对话对象的建模。例如，在产品域看来，建模的目的是要保证产品是否实施或者实施过程是否可控，因而需要在这些问题上提供一个“可讨论的对象”;而在实施域看来，同样需要提供一个“可讨论对象”,以保证在用户需求和产品提供之间的一致。

类似这种“可讨论对象”有一个重要的前提，即建模者必须能够提供一种在讨论双方或多方之间理解一致的东西。关于这一点，在敏捷工程与传统工程中存在极大的分歧：传统工程认为应该通过“建模”来得到一个多方共同认识的抽象对象—-即模型，并围绕这些模型来推动从决策到实施的全程；而敏捷工程则认为对于多方来说，最好的、能够无碍理解的东西是产品原型而非抽象模型，因此应该将工程中的多方全部纳入一个基于产品原型的、迭代实施的推进过程中，由具体的过程环节来决定沟通的细节。yipindushu.com

但问题是：为什么不能将“原型”也理解为“模型”?为什么非得将画在图纸上、用几何线条描绘的东西才视为模型，并将这些东西的抽象与绘制过程才称为建模呢?建模的目的是得到一个“可讨论对象”,而(多数情况下)原型就是——在敏捷工程所设定的场景中—-可以被多方认可并予以讨论的对象。既然如此，那么再讨论“是做原型还是画图纸”的问题就没什么价值了。