软件方法笔记1-建模

1，利润＝需求－设计

2，软件开发中，需求工作致力于解决“产品好卖”的问题，设计工作致力于解决“降低成本”的问题

3，用例是收益面，对象是成本面

4，如果需求和设计不分，利润就会缩水。从需求直接映射设计，会导致功能分解得到重复代码。如果从设计出发来定义需求，会得到一大堆假的“需求”。

5，拿自古以来就有的一个系统“人体”来举例。人体对外的功能是会走路，会跑步，会跳跃，会举重，会投掷，会游泳……但是设计人体的内部结构时，不能从需求直接映射到设计，得到“走路子系统

”、“跑步子系统”、“跳跃子系统”……。人体的“子系统”是“呼吸子系统”、“消化子系统”、“血液循环子系统”、“神经子系统”、“内分泌子系统”……。

6，人体的“子系统”中很多是不能从需求直接映射出来的，需要设计人员的想象力。水店老板要雇一个送水工（即租用一个人肉系统），他只要求这个工人能跑能扛工资低就行，管他体内构造是心肝脾

肺肾还是一块电路板

7，很多时候我们说“本系统分为八大子系统……”，其实说的是“本系统的功能需求分为八大需求包……”需求包是从外部对系统功能所做的简单分包，子系统应根据部件的耦合和内聚切割得到

8，需求       设计

   卖的视角   做的视角

   具体       抽象

   产品当项目做 项目当产品做
设计源于需求，高于需求

9，核心工作流

a. 业务建模——描述组织内部各系统（人肉系统、机械系统、电脑系统……）如何协作，使得组织可以为其他组织提供有价值的服务。新系统只不过是组织为了对外提供更好的服务，对自己的内部重新

设计而购买的一个零件。组织引进一个软件系统，和招聘一名新员工没有本质区别。如果能学会通过业务建模去推导新系统的需求，而不是拍脑袋得出需求，假的“需求变更”会大大减少。

b. 需求——聚焦于待开发系统的边界，详细描述系统要卖得出去必须具有的表现——功能和性能。这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众（Stakeholder）在意的、不能改变的契

约，哪些不是，严防“做”污染“卖”。需求工作流的结果——需求规约是“卖”和“做”的衔接点。

c. 分析——提炼系统内需要封装的核心领域机制。可运行的系统需要封装各个领域的知识，其中只有一个领域（核心域）的知识是系统能在市场上生存的理由。对核心域作研究，可以帮助我们获得基于

核心域的复用。

d. 设计——将核心域知识和非核心域知识结合，最终实现系统。说“代码就是设计”指的是这里说的“设计”。代码确实是设计，但代码不是分析，不是需求，不是业务建模。

10,

需求-提升销售

组织要解决什么问题 业务建模

为了解决组织的问题，待开发系统应该提供什么功能和性能 需求

降低成本--需求规约    

为了提供功能，系统内部应该有什么样的核心机制 分析

为了提供性能，系统的核心机制如何用选定技术实现

设计

图1-3 核

11,     工作流 思考焦点推荐UML元素
业务建模   组织内系统之间  用例图、类图、序列图
需求 系统边界用例图、文本
分析 系统内核心域类图、序列图、（状态机图）
设计 系统内各域之间不画，代码即设计

12,不少开发人员并不喜欢用UML，更喜欢在白板上画个自造的草图，似流程图非流程图，似类图非类图，然后说“来，我给大家讲讲！”。这样的做法有一个巨大的“优点”——怎么画都是对的，关于

这个草图的解释权归“我”所有，同事不好批评我，项目要依赖于“我”头脑中的隐式知识——要是“我”不“给大家讲讲”，大家就玩不转了。上面这种现象，在有一定资历、但又不对项目的成败承

担首要责任的“高手”身上表现更明显。

但是，这样的做法更像是想通过形式上的丑陋来遮掩内容上的丑陋。动乱年代，数学家在牛棚中用马粪纸做数学推导，不代表就可以因为演算工具简陋而允许自己胡乱使用符号和概念；过去的作家没有

电脑，不意味着作家可以随意写错别字和犯语法错误。开发人员故意选择简陋的形式为简陋的内容开脱，就如同作家故意选择不好的纸来掩盖自己文字功力不足的事实，并不是好现象。UML没有强调一定

要用多么昂贵的工具来建模，但是，即使您在海边用手指在沙滩上建模，模型依然要概念清晰，而不是以此为理由遮掩脓包

13,就像数学符号背后隐含着数学的基本共识，五线谱背后隐含着基本乐理一样，UML背后隐含的是对于软件建模的一些基本共识

14,这种沟通仅限于开发团队内部，UML模型不是用来和涉众沟通的

15,经常有人问：客户看不懂UML怎么办？这个问题本身就有问题，提问者潜意识里可能认为“客户”是一个人，其实“客户”是一大堆“涉众”，他们所在领域不同，学历职位有高有低，年龄有大有小

，健康有好有坏，关注的利益更是各自不同，怎么能寄望用一个模型和所有的涉众沟通？

16,和涉众交流的介质是什么呢？不是模型本身，而是模型的各种视图。面对大领导，我们可以给他放幻灯片交流愿景；中层干部喜欢看文档，我们可以按照他喜欢的格式给他炮制文档；一线操作工只关

心他那一小块工作，我们可以制作界面原型和他交流；有时候甚至有的涉众根本不喜欢看任何东西，我们还可以通过“谈话”这种视图和他交流。涉众连谈话都不乐意，我们也可以通过观察来获取素材

。

17,需求调研的技能有许多种，不仅仅是浅薄的“画个界面草图给用户看”，“问用户想要什么功能”。许多伟大的创新正是有心人在涉众不作声的情况下，观察涉众的行为得到的。另外，和涉众交流的

内容应该聚焦于需求的素材——涉众利益（涉众希望什么担心什么），而不是需求。软件的需求规约相当于电影剧本。电影剧本并不是由观众直接提供的，而是由编剧根据不同观众的口味编出来的。同

样，软件需求不是由涉众直接提供的，而是由需求工程师综合不同涉众的利益编造出来的。涉众没有资格、也没有责任提供需求。

18,和涉众交流的形式应该采用视图，而不是模型,和涉众交流的内容应该聚焦涉众利益，而不是需求。
19,不管涉众向我们索取什么材料，都把它看作视图，不管涉众向我们提供什么信息，都把它看作素材（涉众利益）。视图和模型的分离、交流和建模的分离，带来了灵活多变的交流方式和严谨稳定的开发内核

参考:http://blog.csdn.net/joeyon1985