200603071000275.html

软件工程的红包书

<P><FONT face=Verdana>　　有很多业务用例是由业务主角触发的，RUP中也把和业务主角有关联关系的业务用例称为核心业务用例（Core Business Use Case）。这强调了构建业务模型的目的是为了提供以用户为中心的服务。这也是我们建立业务用例的时候应该注意的。 </FONT></P>
<P><FONT face=Verdana>　　当然，有时候业务用例的触发是为了产生用户需要的结果。例如企业的市场调查行为就不是由业务主角触发，而是企业积累了大量用户请求的结果。而对于管理型、支持型的，不直接和业务主角的客户类发生联系，但是也有其特定的业务主角，如管理型的业务用例需要和董事会为发生联系，支持型的业务用例可能和供应商发生联系。 </FONT></P>
<P><FONT face=Verdana>　　在建立了基本的业务用例模型之后，对此模型进行精化是非常有必要的，这时候，在上一章中我们介绍的用例的<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200603101440455.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200603101440455.html'" tppabs="http://www.itisedu.com/phrase/200603101440455.html" target="_new">扩展关系</a>和使用关系就有了用武之地。除了这两种关系，还有一种新的关系。 </FONT></P>
<P><FONT face=Verdana>　　7. 在业务建模中使用关系 </FONT></P>
<P><FONT face=Verdana>　　<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200603101456365.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200603101456365.html'" tppabs="http://www.itisedu.com/phrase/200603101456365.html" target="_new">泛化关系</a>（Generalization）：根据我的理解，可以把它看作我们比较熟悉的继承关系很相似的一种关系。Generalization一词含有一般化、概括的意思。它是一个相对抽象的词。虽然它和继承关系非常相似，但是它们在使用环境和产生目的方面都有相异之处。下图描述了四个业务实体之间的泛化关系： </FONT></P>
<P align=center><FONT face=Verdana><IMG src="2006415173427928.gif" tppabs="http://www.itisedu.com/manage/Upload/image/2006415173427928.gif" border=0></FONT></P>
<P><FONT face=Verdana>　　当你去麦当劳的时候（不要误会，我并不是很经常去的），会选择麦香鸡汉堡、麦香鱼汉堡或是吉士汉堡。但是分别对这三种汉堡建立业务实体就非常没有意义。所以可以将它们概括为汉堡这个业务实体。同样的道理，企业的业务流程中也可以概括出一些共有的属性和行为。为了避免多次说明同一个工作流程，您可以将共有的行为放在一个单独的业务用例中。称为父用例，执行子用例的用例实例将遵循父用例的事件流，同时插入附加行为或修改在子用例事件流中定义的行为。 </FONT></P>
<P><FONT face=Verdana>　　8. 方法的选择 </FONT></P>
<P><FONT face=Verdana>　　以上的原理我采用了UP的方法。但是除了UP方法，还有<a href="200604231325145.html" tppabs="http://www.itisedu.com/phrase/200604231325145.html" target="_new">XP</a>、<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200604241235245.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200604241235245.html'" tppabs="http://www.itisedu.com/phrase/200604241235245.html" target="_new">FDD</a>等方法。所以在做业务建模的时候，也要根据不同的方法选择适当的工件。例如素材和功能。方法的好坏并不是我们这片文章讨论的重点，我会在另一篇文章中讨论方法。再一次需要强调的是，上面讨论的RUP的工件只是为了学习，所以才定义了比较复杂的工件，区分了它们之间的区别。但是在实际中，并不需要这么多的工件，那只会使你的项目涉众和开发人员糊涂。这些工件的区别只要在你心中就可以了。<BR></FONT></P></FONT>
<P><FONT face=Verdana>&nbsp;</P>
<P><BR></P></FONT><FONT face=Verdana>
<P><FONT face=Verdana><STRONG>六、业务建模的原则（Principle）</STRONG> </FONT></P>
<P><FONT face=Verdana>　　1. 谁才是"上帝" </FONT></P>
<P><FONT face=Verdana>　　我们说客户是上帝，是因为客户的重要性，客户占有决定性的地位。可是在<a href="200603282233345.html" tppabs="http://www.itisedu.com/phrase/200603282233345.html" target="_new">软件开发</a>中，到底是谁有决定权呢？是出资方，还是项目经历，或是程序员？ </FONT></P>
<P><FONT face=Verdana>　　职责不清，是业务建模失败的主要原因之一。我们可以很容易的看见客户把自己的要求用几句话高度浓缩之后扔给开发人员，或是开发人员按照自己的意思开发程序。难道说，客户和开发人员之间真的是"心有灵犀"，完全不用沟通的吗。 </FONT></P>
<P><FONT face=Verdana>　　我在前文中已经提到过项目涉众和开发人员的权利和义务，我想这里还有必要再次强调。Scott W. Ambler说： </FONT></P>
<P><FONT face=Verdana>　　it is the role of project stakeholders to provide requirements, it is the role of developers to understand and implement them. </FONT></P>
<P><FONT face=Verdana>　　在我一次开发过程中，遇到过一个很有意思的涉众，他在他的<a href="200603062220345.html" tppabs="http://www.itisedu.com/phrase/200603062220345.html" target="_new">需求分析</a>中这样写："总之，要实现那种能够想到就能做到功能。"我想，这位涉众对我们的计算机工业有着非常远大的抱负。但我不得不客气的告诉他目前实现是不太现实的。 </FONT></P>
<P><FONT face=Verdana>　　大家听了可能会觉得好笑，但是在我自己和客户打交道的生涯中，这种客户不在少数。现实就是这样，你要怎么做？是一笑之后，弃之不顾吗？我想大多数人会这样做。因为他的要求太荒唐了嘛。可是，你有没有花时间去了解一下，他这句荒唐的话背后代表了他的什么意思呢？我觉得，软件开发人员负有教育涉众的义务，你需要引导你的涉众，让他们说出自己的心声。我在看到这位涉众的这句话后，就花了一些时间去了解，其实呢，事情很简单，他就是想要一个能够定制报表模板的功能。而在项目结束后，我和这位涉众有幸再一次的合作，这时候，他已经成为了一个出色的客户方的项目领导者了。 </FONT></P>
<P><FONT face=Verdana>　　这个例子说明了什么呢？涉众往往都是领域专家，对自己的工作有很深的认识，可是由于对软件开发的不了解，涉众往往表达不清，甚至表达不出自己的需求。这时候，就是体现你的功力的时候了。记住，象对待上帝一样对待你的客户。 </FONT></P>
<P><FONT face=Verdana>　　2. 耐心是首要的 </FONT></P>
<P><FONT face=Verdana>　　明白了谁是"上帝"，那就要耐心的对待上帝。学理工科的人，一般在逻辑思维上会比较好，可是对于涉众来说，可不一定是这样。我就遇到过一位做档案工作的涉众，在了解需求的时候，扯东扯西，含糊不清。明明一分钟前才否定的方法，下一分钟又提出来了。我觉得我的脾气应该是不错的，可到最后也几乎发飚。所幸，最后我终于撑了下来。我想，在经历过这件事情之后，我的耐心指数又会有一个很大的提高了吧。 </FONT></P>
<P><FONT face=Verdana>　　我有一位同事的耐性是我所佩服的，在一个网站项目中，他负责系统分析。他整整花了三天的时间，和网站项目的负责人住在一起。最后系统分析出来之后，他的精神还不错，可是那位负责人已经快不行了。 </FONT></P>
<P><FONT face=Verdana>　　当然，这只是个笑话，并不是去鼓励大家拼命。劳逸结合还是很重要的，身体是革命的本钱嘛。但是这告诉我们，如果缺少耐心，需求是很难成功的。例如在业务建模的讨论会上，你虽然规定了这次的会议讨论的是高阶需求，可是与会者总会时不时的争辩一些芝麻绿豆的小事儿。你怎么办？我相信这种情况是很普遍的。 </FONT></P>
<P><FONT face=Verdana>　　耐心最后会仍会体现为沟通，只有耐心的沟通，你才能揭开需求的重重面纱。人的行为总是会受到思想的指导，如果你解不开涉众的心结，你就不可能了解他真正需要的。 </FONT></P>
<P><FONT face=Verdana>　　我的一位项目涉众的表现很奇怪，她总是在不停的说一件事情："她要实现报表自动生成。"她的需求讲来讲去好像总脱不出这个范围，可是我从她那里几乎听不到别的东西了。这时候，我决定放弃了，我想从她哪里可能已经没有更多的资料了。但在我了解到她的工作中报表处理占用了她大量的时间之后，我改变了想法。在我花了一些时间帮她理清了报表处理的思路之后，她还在其他方面给了我很大的帮助。 </FONT></P>
<P><FONT face=Verdana>　　3. 参与是重要的 </FONT></P>
<P><FONT face=Verdana>　　XP方法的一个重要实践，就是提倡"现场客户"（on-site customer）。也就是说，客户应该随时和开发人员在一起，随时提供资料和做出决策。而这个客户，也必须领域专家，而且能够有权做出决策。 </FONT></P>
<P><FONT face=Verdana>　　这种现场客户相信国内的软件组织多半还做不到。但是一定要往这方面努力。我认为，这种现场客户有两种人：一种是项目涉众，还有一种是行业专家。其实很多软件公司都会配备一些管理咨询人员，这些人就是行业专家。有数据统计说，目前广东省软件公司中的咨询人员和开发人员的比例达到了3：1。我觉得这是好事。项目涉众往往对自己的工作中的事务性部分有很深的认识，但是很难将之提升到一个理论的水平。这时候就需要一些行业专家来帮助了。让行业专家和项目涉众共同探讨，还能够激发项目涉众的灵感，想到原来他想不到的方面。这就是"潜在需求"的开发。 </FONT></P>
<P><FONT face=Verdana>　　另一方面，参与还意味着需要项目涉众全身心的投入到业务建模的过程中来，要能够调动他们的积极性。因此呢，太复杂的流程会阻碍涉众的参与。所以，使用一些简单的、能够为客户所接受的工件（Artifact）来进行业务建模是很有必要的。我说过前面讨论的那些"主角"啊，"用例"啊，那是理论，是给开发人员看的，让开发人员心里有个底。你给涉众看这些，他们能懂吗？等他们了解了这套机制，恐怕黄花菜都凉了吧。 </FONT></P>
<P><FONT face=Verdana>　　素材（User Story）、特性（Feature）、CRC卡片这些都是很不错的工件，既简单，又能够满足需要。 </FONT></P>
<P><FONT face=Verdana>　　知识点：素材和特性都表述了用户的一个简单的要求，它能够在较短的时间内完成。素材是XP方法中的工件，特性是FDD方法中的工件。CRC是<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200604231359565.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200604231359565.html'" tppabs="http://www.itisedu.com/phrase/200604231359565.html" target="_new">class</a>、 responsibility、collaborator的缩写，它是一张分为三个部分的卡片，分别标记了类名，类的责任，以及类之间的合作关系。非常的贴近客户，甚至可以在做游戏的过程中完成卡片的填写，能带来很强的客户参与度。 </FONT></P>