UML需求和设计

基本的概念

软件开发，不是计算机科学，而是经济学。软件开发，和其他所有经济过程一样，本质是追求利润的最大化，有:

利润 = 销售 - 成本

那么对软件开发而言，销售是什么？成本是什么?

软件开发的产出，是一个系统。这个系统将被用于某个组织，对某个过程进行一个可以被度量的改进。这个组织可以是一个人，一个机构或者某类机构。当这个系统能满足组织的需求的时候，这个系统才能完成销售的目标。所以，我们认为：

销售 = 需求

当我们讨论软件开发的成本的时候，我们讨论的是团队的成本。我们希望:

1. 当需求变动的时候，我们只需要很少的工作量，就能应对需求的变化，而不是需要大动干戈。

2. 当团队成员发生变动的时候，我们可以快速的调整，而不是手忙脚乱。

因此我们需要在软件开发的过程中，试图创建并维护一个好的设计。一个好的设计，是对软件系统所在领域的建模，它清楚的隔离，变化的部分和不变的部分，来应对需求的变化。所以，我们认为：

成本 = 设计

然后我们提出，对于软件开发这门经济学来说，有：

利润 = 需求 - 设计

产品经理的职责和产出

产品经理的职责是，提高销售，为达到这个目的，产品经理需要研究组织，研究改进过程，通过使用业务用例, 业务序列图, 系统用例等产出，来定义具体的需求。

等等，产品经理的职责不是画UE吗？

我们多半不能拿UML和老板讨论需求，UE是一个好的交流工具，特别是对外交流的时候。同时，我们应该将需求和交流分开。我们认为，UE是业务序列图和系统用例的一种形象化描述，它具有很好的启发性，在大部分的情况下，它是这两者的一个不严谨的代替品。

软件工程师的职责和产出

软件工程师的职责是，降低成本, 为达到这个目的，软件工程师需要建立系统在具体的领域中的映射，通过使用系统序列图, 类图, 状态机图等产出，来描述具体的设计。

等等，程序员的职责不是写代码吗？

程序员通过编写易于维护的代码，可以帮助团队降低成本。而易维护的代码，一定是来自于好的设计。应该说，设计的颗粒度是有限的，按照同一份设计，不同的程序员写出来的代码，在性能和效能方法，也有天壤之别。好的代码，我们甚至可以从艺术的角度来欣赏。而同时，一个能写出好代码的人，一定对设计有好的理解。