| | | | | | | [文章信息] | | | 作者: | | | 时间: | 2005-03-27 | | 出处: | 思达网校 | | 责任编辑: | 方舟 | |
| [文章导读] | | | 大家应该对这两个词很熟悉了,但是对词里包含的意义可能并不是特别清楚 | |
| |
|
| | | |
|
|
|
|
|
计划的回报
如果没有仔细拟定的设计图，当然不可能建起一所房子。如建立的是一所狗舍，尽管设计图可以不必那么详尽，但仍然需要一些草图，以做到心中有数。软件开发则完全不同，它的“设计图”（计划）必须详尽而完备。在很长的一段时间里，人们在他们的开发过程中并没有太多的结构，但那些大型项目很容易就会遭致失败。通过不断的摸索，人们掌握了数量众多的结构和详细资料。但它们的使用却使人提心吊胆在意——似乎需要把自己的大多数时间花在编写文档上，而没有多少时间来编程（经常如此）。我希望这里为大家讲述的一切能提供一条折衷的道路。需要采取一种最适合自己需要（以及习惯）的方法。不管制订出的计划有多么小，但与完全没有计划相比，一些形式的计划会极大改善你的项目。请记住：根据估计，没有计划的50％以上的项目都会失败！
非常佩服作者对软件构建过程的精辟见解，软件工程是一门内容非常繁杂的学科，但是作者能够用浅显易懂的句子把它描述出来，真的是非常不简单。软件工程最早的提出者并不是计算机的专业人士，而是一位建筑设计师，所以软件工程的很多思想来自于建筑学。经过了几十年的发展，软件工程经历了很多次的蜕变。形成了今天的世界上以一些大公司提出的架构为主的形式：比如微软提出的COM及COM+以及基于其上的DNA体系，SUN提出的EJB，CORBA，还有BEA、WebLogic、IBM等公司的架构。虽然架构有不同，但是他们的思想都是相通的，架构的作用都是起到辅助开发者实现规范的、科学的软件开发过程。至于谈软件项目的管理和开发，那么Rational公司就是这方面的鼻祖。综合来说，目前世界范围内的软件工程提倡的就是以渐进的、螺旋式的开发方法构建基于组件的软件产品。现在说这些东西可能有些画饼的嫌疑，随着我们专题讨论的继续深入，这些概念就会很清晰的展现在面前。
虽然很希望能够继续的讨论软件工程方面的东东，但是我们的这个专题毕竟是讨论如何编写优美的程序的，离题还是不要太过分的好，至于软件工程的详细讨论，我会在接下去的专题中继续。在接下去的篇幅中，我们会继续讨论程序员和系统分析员之间的差别。
四个阶段
这里我不想举一大堆的数字和实例来描述软件危机和论证软件工程的重要性，这方面的资料有很多，如果一一列举的话，会被怀疑别有用心。事实上，建造狗舍和写一个小的软件没有很大的区别。虽然你认为你的能力可以很轻松的完成小型的软件系统，根本不需要任何的计划。好！我来问问你，你在写程序代码的时候，有没有过漏这漏那，程序快接近完成的时候却发现少了一个很重要的模块；有没有过在书写了大量的代码之后觉得自己写出来的东西不堪入目，恨不得重头开始；有没有过写程序花了两天的时间，但是Debug却花了一个星期的时间；有没有过听到软件的使用者说要改需求，你就恨不得狠狠揍他一顿。如果都没有，那么只有两种可能：你是个超级天才，所有人类能够想到的美好品质你都具有，另一种可能：你根本没有开发过软件。
即便是个人开发的软件，软件工程科学中也有相应的方法来指导软件的开发过程，这种方法叫做PSP（个人软件开发过程），与此相对的，还有TSP（小组软件开发过程）。这些被事实证明行之有效的方法包括了一整套的规范，帮助你开发你的软件，不让你的程序变得无法控制。可以说，对于任何一个软件系统来说，只要你花一些时间去设计，即便你的设计仅仅只是在草稿纸上随便的涂抹，在软件开发完成后，你就会惊喜的发现，你在软件开发早期的小小投入，已经为你带来了额外的好处。
路标和RUP
在阶段0中，我想最重要的思想就是就是“路标”的概念了，和这个概念相类似的概念还有“周期”和“里程碑”的概念，这些概念在Rational公司的RUP(Rational Unified Process 软件统一过程)中有详细的论述。不论这些概念叫做什么，他们体现出来的是一种迭代开发的思想。面对当今的复杂的软件系统，使用连续的开发方法：如首先定义整个问题，设计完整的解决方案，编制软件并最终测试产品，是不可能的。需要一种能够通过一系列细化，若干个渐进的反复过程而生成有效解决方案的迭代方法。
Rational Unified Process支持专注于处理生命周期中每个阶段中最高风险的迭代开发方法，极大地减少了项目的风险性。迭代方法通过可验证的方法来帮助减少风险－－经常性的，可执行版本使最终用户不断的介入和反馈。因为每个迭代过程以可执行版本告终，开发队伍停留在产生结果上，频繁的状态检查帮助确保项目能按时进行。迭代化方法同样使得需求、特色、日程上战略性的变化更为容易。(出自《Rational Unified Process白皮书》)
上面这段好像很复杂，但是他所要说明的思想却是很简单的，就拿搭建狗舍来说，你的第一个“路标”可能是要搭一个框架，这个框架是由几根结实的木头组成，等到框架完成之后，你会把你的小白叫来，让他试一下，糟糕的是，这个框架对于小白来说小了一些，这时候你嘘了一口气，因为你原来是打算把整个狗舍搭好以后再叫小白来试一下的，如果你那样做的话，你剩下的木头可能就不够再盖一间狗舍了。好吧，既然有了些问题，我们就把框架调整一下，可能这个过程也花了你一些木头，不过所幸木头还够。在修整完毕后，你觉得第一步的计划虽然有些挫折，不过仍可以算是成功的，接下来你就要建立第二个“路标”了：第二个的“路标”是为狗舍钉上墙板和做出一个底座，你可能花了一些时间来思考以及和你的小白商量是否要在墙壁上开一个窗户和给底座加上轮子，在决定之后，你很快的达成了第二个“路标”。而且在经过了小白的测试后，你发现完全没有问题，你自己都觉得有些佩服自己了，很快的，你又完成刷油漆等“路标”。整个过程进展的非常顺利，而你在做狗舍方面很有天赋的名声也在你的街坊四邻间不胫而走。
很简单是吧，其实本来就是简单的，软件工程的目的就是要把复杂的软件开发过程条理化，简单化。记住，在你使用迭代开发方法的时候，它在每个周期后的产品是一份可执行代码，是一份可以让你的用户品头论足的东西。而这份可执行代码不仅包括了程序本身，可能还有其他的产成品，例如：文档等。
问题和场景
在阶段1中，非常重要的一点是问题描述，在多数情况下，问题描述来自于你的软件的使用者，就是用户。用户的需求决定了问题描述，糟糕的是，用户多半不懂计算机，对他们来说，他们只能够用日常的语言来表达自己的需要。而你的任务就是要把他们的语言翻译成计算机语言，不过并不是指象C那样的高级语言，而是便于你构造系统的需求描述语言。这同样很简单：你只需要问自己几个问题就可以：在什么场合？有什么条件？做些什么事？回答好这三个问题，你就完成了一个完整的问题描述了。
举一个简单的例子：一个银行的信贷系统有这样的问题描述：
“若顾客采取信用贷款方式，销售员就请求信用部门的审核人员查核顾客的信用，此时审核人员会向销售员取得顾客信用编号和销货总金额。”
在某种条件下应该做什么事情，这就是这个问题描述的表现形式，很简单是吧。
实际上，这里可以引申出两个概念：场景(context)和问题(problem)，场景指的是一种特定的情况，会导致某种问题的发生；而问题是在某个场景之中，但它也有可能产生出新的场景。
过程和对象
有必要说明一下以前基于过程的软件开发和目前基于对象的软件开发的不同。在没有OO的年代里，DFD(Data Flow Diagram 数据流程图)是一份软件设计中的非常重要的文档，注意力的关键也是集中在数据如何在各个系统之间传递。可是在现在的OO概念中，数据大有为消息(message)所替代的趋势。比如你到麦当劳快餐店，要花10块钱买一份汉堡。在DFD的时代，就是这样表示的：
如果你用消息表示法来表示话，就是另一种方式：
怎么样，你觉得那一种方式更自然呢。(如果你敢回答第一种的话我就...)。再比如上一段话中关于问题描述的例子，如果用传统的数据描述的方法的话，就会是这样子的：
“若采取信用贷款方式，销售员就将顾客信用编号及总金额交给信用部门的信用审核人员。”
请比较其中的两句话：
“若采取信用贷款方式，销售员就将顾客信用编号及总金额交给信用部门的信用审核人员。”
“若顾客采取信用贷款方式，销售员就请求信用部门的审核人员查核顾客的信用，此时审核人员会向销售员取得顾客信用编号和销货总金额。”
了解其中的不同之处了吗，用自然的语言去描述你的问题，这是写出好的软件的第一步。
|
|
|
|
|
|
|
|
|
