UML精髓之概要开发过程

        UML是一种建模语言，不是一种方法，UML没有过程的表示法，过程是方法的重要部分，但是，我相信不了解建模技术如何适应过程，建模技术也就不会有丝毫意义。这就是为什么我们先讨论过程的理由。这里我们介绍一个一般的软件开发过程，他分为初始-细化-构作-移交这样的几个部分。

• 初始部分

        在初始中，一般确定项目的业务基理，并决定项目的范围，本质上说，初始是一种可行性研究，决定是否启动这个项目。个人建议初始不要花太多的时间。

• 细化部分

        在细化中，你获准开动项目了，开始的时候你对项目只是有一个模糊的概念，这时你必须对问题有一个更好的了解，主要要解决下面两个问题：

1. 1. 实际上要构作的是什么?
   2. 如何构作?

        为了解决这两个问题，首先你必须确定你项目中的风险，一般风险可以归为四类，这里来分别介绍如何对付这四类风险。

• •  对付需求风险：需求是重要的，需求的起点是用例，用例也启动了整个开发过程。用例是用户为了达到某一目标和系统进行的典型交互。对一个用例来说，关键要素是每一用例表示一种用户可以理解并对该用户有价值的功能。在细化阶段要做的最重要的事就是发现所有的最为重要且最有风险的用例。为了收集用例，你应该安排几次和用户的面谈。用例并不需要很详细，用例也并不是项目的整个形象，另外细化还有一个重要任务就是提出领域模型，领域模型主要展现了计算机系统正在支持的领域。有两种UML技术在构建领域模型中特别重要，用于领域模型的主要技术是从概念视面绘制的类图，另外一个是活动图或者交互图，他们阐述了具体的业务过程或者探讨了业务中各种角色的交互。构建领域模型的诀窍就是发现并专注于重要的细节。对付需求风险中最重要的要素之一就是熟悉领域的专业知识，值得花相当的时间和财力把实际懂得领域的人引进到你的开发组中来，这对于软件的品质来说是非常重要的。
  • 对付技术风险： 在对付技术风险中最重要的工作是针对那些估计有重大风险的用例构建原型，以考验你使用的技术的各个部分。在这个阶段你应该着手进行体系结构设计的抉择，这个抉择通常是关于什么是主要成分以及如何构作它们的想法。在这一过程中，你将用到一些代表性的UML技术、这其中包括类图和交互图、包图和部署图。
  • 对付技艺风险：主要的问题是如何找到你需要的人以及如何培训组织他们。一种办法是让成员进行有组织的培训，另外一种就是导师指导，每个成员将与一位有经验的开发人员在项目中共事，开始的时候，导师是一名组员，帮组你提出解决方案，随着你的能力的增强，导师就做更多的检查工作，而不是亲自去做项目本身的工作，作为一名的导师的目标应该是努力让自己变成多余的人。如果项目中本身没有经验丰富的人，可以考虑为整个项目聘请一名导师，每隔一段时间让导师做一次项目审查。你也可以通过阅读来补充技艺，至少每两个月读一本扎实精深的技术书，作为一个读书小组的成员去读书，效果甚至更好一些。你在细化工作中始终都要放开眼界，留意你在技艺或经验不足的方面，并计划在你需要的时候去取得那方面的经验。
  • 对付政治风险：考虑在内，此处不再赘述。

       在确定了项目的风险之后，你就可以开始构作阶段的计划制定了。计划制定的要素包括对构作建立一系列迭代并定义每次迭代要发布的功能，在计划制定中，需要考虑两组人，客户和开发人员。客户是指为一个机构内部开发使用系统的人，是可以评价正在实现的用例的业务价值的人。开发人员是指构作系统的人，他们必须了解在构作一个用例中所包含的代价与工作。构作计划可以分成几步走。

• 第一步是对用例进行分类，可以按照两种方法进行分类，一是按照用例的业务价值，二是按照开发风险。在这些事完成后，开发人员就应估计出每一用例所需的时间，在做这一估计时，假定需要进行分析、设计、编码、单元测试、集成以及编制文档等工作，还要假定有一位全身心投入而不情绪波动的开发人员。
• 第二步就是确定迭代长度，每次迭代的长度应该可以长到让你完成少量用例。
• 最后一步就是给迭代指派用例。优先级高且具开发风险的用例应优先处理。不能把风险推迟到最后，大的复杂的用例还需要分解。
• 另外，为了移交，分配构作的时间的10%-35%用于发布前的调整和包装。

        何时细化结束?
 
        我靠实践得出的结论是：细化大约要占项目全过程的1/5。有两件事是细化完成的标志：

1. 开发人员能够毫无困难地估计出构作一个用例所用的时间。
2. 已辩认出所有的重要风险，并知道如何应对主要风险。

• 构作阶段

        构作以一系列迭代来制作系统，每一迭代都是一个小项目，你对指派给每一迭代的用例进行分析、设计、编码、测试以及集成。这一过程的目的是降低风险，不把所有的风险都压到最后，测试和集成都是大任务，它们往往占用的时间比人们想象得更长，把它们留到结尾来做，任务就会艰巨，并会使士气低落。 在构作阶段，所有的UML技术都有用，因为构作的分析设计都要基于细化工作，且在构作过程中，还要经常的更改设计。

         在构作阶段，需要强调一些有用的技术。

• •  测试：测试应是一个连续的过程，在知道如何去测试代码以前不应该去编写代码。一旦代码写好，就要写对它的测试，没有测试，不能宣称代码已经完成。测试一旦写成，就应永远保存。建立你的测试代码使得用一个简单的命令行或者GUI(图形用户接口)按钮即可运行测试。代码应回答"OK"或一张失败表。还有就是所有测试应对其自身核查。如果测试输出一个使你必须进行研究的数，则是最为浪费时间的事。测试可分为单元测试、功能测试和系统测试。单元测试应该由开发人员编写，然后,以包为基础进行组织并编码，以测试所有各类的接口，功能测试或者系统测试应由一个独立的小组编写，这个小组惟一的任务就是测试，它应对系统持黑盒观点并以发现错误为特有乐事。
  • 重构: 重构是代码迭代中一种非常有用的技术，重构应该是一个持续的过程，重构可以减轻重新设计的短痛，可以提高代码质量，可以提高后续的开发效率。按以下原则进行重构可使它更加容易:
     1 不要同时对一个程序既重构又增添功能，要把这两者分开
     2 确信在重构前已经作了良好的测试
     3 重构后的每一步都要进行测试
  • 模式:模式表述为通常做事的方法，并由设计中重复论题的人们收集，在分析、设计、编码的过程中，应该寻找任何可用的模式。模式是前人经验的总结，可以给你提供很好的解决方案，也让你的代码更为灵活和健壮。

 

• 移交

        移交阶段最重要的事情就是为了提高性能对系统进行优化。优化可能会降低系统的清晰度和扩张性，不宜早做。