OOA&D实践之路――真实案例解析OO理论与实践

OOA&D实践之路——真实案例解析OO理论与实践（一、导言）2008-12-0812:35byEricZhang(T2噬菌体),4371visits,网摘,收藏,编辑查看本系列全部文章：《OOA&D实践之路——真实案例解析OO理论与实践》索引贴为什么要写这个系列“OO都是一个已经被讨论烂的话题了，还有什么可写的！”不知当你看到文章标题时，是不是有这种疑问，或者鄙夷。不错，OO从诞生到现在经历了不短的岁月，与其相关的理论、技术、原则、实践、模式、语言已经出了一大堆。可是，你真的了解OO的本质吗？真的能挥洒自如的将OO应用于软件开发中吗？真的能发挥OO的能量，从而提高软件质量吗？如果对这三个问题，你不能很干脆的点头说：“是的，当然！”那么也许你可以抽一点时间，往下看一看。这个系列文章不打算大篇幅重述各种OO理论，也不打算谈各种OO心法。这系列文章着重于通过实践澄清一些对OO的误会，帮助朋友们更好的使用正确的方法将OO应用于实际开发中。同时，在必要的地方简要叙述一下OO相关知识。所以，这个系列不是关于OO理论的天书或OO参考大全，而是告诉你“你对OO可能存在哪些误会与认识上的偏差”以及“如何走出误会更好的OO应用于实践”。OO是技术，不是理论OO，我认为全称应该叫做“面向对象技术”。其实，OO自诞生那天起其全部目的就是应用于软件开发实践中，提高软件开发质量。这也是OO存在的全部意义。所以，搞OO和搞数论、搞理论物理不一样，不能脱离应用。搞OO的人应该算是工程师，而不是科学家。两者最大的区别是：科学家可以不考虑自己研究的成果有没有什么应用价值。而工程师不一样，他们要更“势利”，要时刻关心自己研究出的东西有什么应用价值。所以一切OO的研究要以可应用性为向导，不能天马行空夸夸其谈。当然，OO需要理论支撑，但是一定要是有现实意义的理论，而不能像数学家那样为了理论而研究理论，更不能将已有理论当做教条机械性使用。因此，在学习和实践OO的过程中，要时刻注意和应用性联系起来，才能避免走入理论OO和教条OO的歧途。到底什么是OO“什么是OO？”对于这个问题，很难一言以蔽之。但正是由于对这个概念的误解和偏差，才使得某些朋友一直不能正确使用OO，不能让OO真正服务于软件开发，到最后开始怀疑OO、鄙视OO甚至唾弃OO。在所有对OO的偏差性认识中，最普遍的一点就是“金锤”式理论，即“XX就是OO。”例如，“把所有东西看成对象就是OO”，“遵循封装、继承、多态就是OO”，“应用良好的OO原则进行设计就是OO”，“使用UML就是OO”。显然，这种“一锤子敲定”的方式会让人割裂的看问题，从而无法从全局角度正确把握OO。在这里，我斗胆给OO下一个定义：OO，即面向对象技术，是一种旨在提高软件质量的综合性技术，其贯穿于软件系统的调研、分析、设计、开发、测试、维护、扩展、升级等整个生命周期，它包含一系列概念、思想、理论、目标、原则、实践、模式、工具、语言等要素，这些要素既相互区别又相互联系，同时从宏观和微观两个角度共同协作，指导和引导开发人员开发出高质量软件，并指导与开发有关的一切过程。从上面可以看出，OO并不是孤立的概念或技术，而是一系列要素的复合体，并贯穿于整个软件开发周期。所以，仅仅从某个时间或控件切面切入而应用OO，这样的OO是不完整的，也不可能发挥出其应有的作用。打个比方：如果使用OO的方法和工具进行分析、设计，但是编码过程不能做到OO，就好比制造了一辆豪华的轿车却找头驴拉着走，是不能提高你出行效率的。反过来，如果你是一个C#或Java高手，但分析设计过程不遵循OO，直到编码时才用C#或Java试图OO，这无异于你听说开车能提高出行速度，于是你苦学驾驶技术，并掌握了高超的驾驶本领，但最终却坐在一头驴子上，于是你开始大喊：驾驶技术是骗人的！根本没法用！是啊，驴子上连方向盘、离合器都没有，空有一身驾驶本领又如何发挥出来呢。这个系列的文章概要和内容组织这系列文章的大体写作方式，是通过一个实际案例《XX食品公司连锁店在线定料系统》的调研、分析、设计、开发等一系列过程，帮助大家更好的认清OO如何实践，同时澄清一些误会。这个系统是我曾经参与过的实际案例，为了文章需要，将进行一定程度的修改，但一些很关键的东西都会原汁原味保留下来。在整个过程中，请各位不拘泥于具体技术相关问题，而要一直保持一个较高的视端，一睹OO的全貌。文章的大概组织方式：第一部分：需求分析之前的故事很多人认为就软件开发来说，第一步是需求分析，其实非也。如果想更好实践OO，需求分析之前还有很多工作，如特性调研、降低风险等环节，这一部分我们讲讲需求分析之前的故事。第二部分：分析步步高这一部分开始对系统进行真正的分析，让我们来看看OO是如何引导和指导我们分析的。第三部分：设计的方方面面设计是一个繁杂的过程，诸多OO原则与模式都会应用于其中，这一部分不会细讲各种原则及模式，而是看看正确应用原则与模式的方式是怎么样的。第四部分：让所有努力开花结果这一部分，我们将前面的成果付诸实践。通过这一部分，可以清楚的看到前面做的一切工作都不是飘在云里的空中楼阁，而是开发高质量软件不可缺少的部分。以上是目前的规划，当然，在整个过程中可能会出现变化，但是大体条理不会打乱。希望本系列文章能给您带来帮助。OOA&D实践之路——真实案例解析OO理论与实践（二、第一项任务：特性列表）2008-12-0821:56byEricZhang(T2噬菌体),3560visits,网摘,收藏,编辑查看本系列全部文章：《OOA&D实践之路——真实案例解析OO理论与实践》索引贴第一份说明当这个项目开始时，我们得到的关于我们要做的系统的唯一说明是一页Word文档，这是一份简单的不能再简单的说明。文档里只有一行字：我们需要一个系统，使得全国各地的代理加盟商和连锁店能够通过网络订购原料。另外，我们还知道这是一个食品公司，主营面包、麻花、肉夹馍等食品，在全国各地有多家连锁机构。除此之外，我们一无所知。永远不要和客户谈需求软件开发的第一步是什么？很多人觉得是需求分析。显然这短短的一句说明无法满足我们的要求，于是很自然的，你希望找客户谈话，详细了解情况，然后做出详细的需求分析。于是，你心里有了这么一个算盘：和客户谈话-问清所有需求-进行需求分析-生成需求文档乍看之下，这是很合理的步骤，但是实际上这是不可行的。原因有如下几点。1.客户不关心系统的所有方面每个开发人员都希望，客户可以清楚的把自己需要的东西的方方面面清楚无误告诉你，然而，这只是一厢情愿罢了。因为，任何一个客户在需要什么东西的时候，只会大致想想要个什么东西，并不会将所有地方都仔细想清楚。2.有时客户并不清楚自己到底要什么东西有时候，客户并不是很清楚自己想要什么。这不是天方夜谭。很多时候，客户仅仅有一个“想要实现某个目的的动机”，而没有“我需要一个什么系统”这么明确的概念。例如，从上文那个“一句话说明”中，可以看出，我们的客户仅仅是有一个动机：希望有一个系统，能使得他们公司的代理商和加盟店在线定料，至于这是一个什么样的系统，他们并没有明确的概念，更不用说这个系统有什么样具体的需求了。基于以上两点，你是不可能从客户那里问清所有需求的。实际上，就不该和客户谈需求，因为需求从来就不是“客户面”的东西，而是“开发人员面”的东西。需求需要包含方方面面系统需要实现的功能，而客户往往并没有如此精细想过，甚至客户自己对自己想要的东西什么样子都不清晰。面对这种客户，你一本正经往他面前一坐，开发笔记本说：“我们谈谈需求吧”，或说“我们进行需求分析吧”，我想客户会立马崩溃，而你也不可能得到你想要的所有东西。作为开发人员，不应该一开始就和客户谈需求，而要先谈特性。很多需求并不需要客户告诉你，开发人员应该能通过常识识别出来，就如没有哪一个买汽车的客户会说：我需要一个辆汽车，要有方向盘，还要有四个轮子。他们通常会说：“我要一辆家用车、要省油、舒适，要至少能坐3个人。”这“家用车”、“至少能坐三个人”就是特性。特性是一些描述，一条特性简要描述了系统的一个客户最关心的核心功能。最为开发人员，首要任务不是做需求分析，而是帮助用户整理出一份特性列表。这里之所以说“帮助”，是因为很多时候，客户由于自身太关注于某个方面，而漏掉了十分重要的特性，这是你要帮客户想想，并将想到的特性询问客户是否是需要的。如果客户很高兴的说“对！对！”，那么这就是大功一件。所以，在初期阶段，开发人员一定要想客户之所想，急客户之所急，尽快帮客户理清系统有什么特性。所以，正确的过程应该是：询问客户系统都有什么功能-写出初期特性列表-想想什么遗漏特性，并询问客户-查漏补缺生成特性列表下面回到案例。虽然客户的说明只有一句话，我们还是整理出一份初期的特性列表，并将其作为我们向客户展示的第一份工作成果。这份特性列表内容如下：1.可以将各种原料信息发布到系统上2.加盟商和连锁店可以通过系统在线定料没错，我们的初期文档只有两项特性。我们把这个给客户看，客户说：“嗯……大约是这个东西吧。”很显然，我们的客户是比较懒的那种，这时，我们有义务引导客户想起更多需要的特性。下面是当时大约对话：开发人员（简称D），客户（简称C）D：你这个加盟商和连锁店是要如何区分呢？C：我们公司有一个加盟商和连锁店的记录。D：那么你们是准备将各个加盟商的信息全部录入系统吗？C：不是，我希望他们能自己注册，就和论坛那种。D：那么你要如何确认他们的身份，总不能任何人都可以在这个系统注册吧。C：嗯，我们公司有各个加盟商的详细信息，我们希望他们注册时提供足够的信息，我们进行核对。（于是我们飞快写下一个特性：加盟商和连锁店通过网络进行注册，总店负责人审核后才可以正式使用系统。）D：你们得在后台能发布各种原料的信息吧。C：嗯，使得。D：这里有没有什么特别的要求。C：没有吧……D：好的，那么你们准备设立几个人负责管理这个系统。C：就一个人吧，就信息部那个。我们就这一个比较懂计算机的。D：也就是说不需要有多个人分别管理这个系统？C：不需要。（写下一个特性：系统需要一个管理员，可以对系统进行管理）D：在你们的加盟商进行定料时，你希望他们怎么操作啊。C：这个，我没仔细想过……（看客户对这个地方比较不清晰，我们打开了一个网上书店的网站，给他演示了一下购物车购物的过程）D：你看，你的这个定料过程是不是和这个购物过程很相似，加盟商定料是不是就相当于从总公司购买原料啊。C：对对！就要这种效果的！（这里要记住，在特性不能直接说清楚时，找相似事物是一个不错的选择。也就是说，说明这个特性像什么，不像什么）（我们又加一条特性：使用购物车功能进行网上定料）D：付钱这一块怎么弄，需要网上支付吗？C：不了，我们一般又财务专门做钱这一块工作。D：那买完原料后要不要什么凭证呢？C：买完后生成一份定料单吧，打印出来，交给财务，财务清算款项，款到账后通知原料那边发货。（又一条特性：定料完成后生成定料单，并可以打印）D：那么关于这些交易，你一定希望能查询吧，你希望怎么查询。C：哦，这些我们财务那边有专门的财务软件。你这个系统只要能让加盟商定料就行了。到这里谈话基本结束，我们得到如下一张补充过的特性列表：1.可以将各种原料信息发布到系统上2.加盟商和连锁店可以通过系统在线定料3.加盟商和连锁店通过网络进行注册，总店负责人审核后才可以正式使用系统4.系统需要一个管理员，可以对系统进行管理5.使用购物车功能进行网上定料6.定料完成后生成定料单，并可以打印我们将补充后的特性列表给客户看了看，基本得到了认可。到了这里，我们第一步就差不多做完了。但是，我们还是不能马上进入需求分析，因为这之前还有很多事情要做。例如，特性整理，风险规避，这都是后面要讨论的话题。重点总结1.客户不会想到方方面面。2.有时客户并不明确自己想要什么东西，而仅仅是有个动机。3.不要和客户谈需求，要谈特性。4.开发人员有义务引导和帮助客户挖掘系统的特性。5.当客户描述不清某个特性时，可以采用找类似事物的方法，说说这个特性像什么，不像什么。6.在软件开发初期，我们需要首先整理出一