一个项目必须设计好之后，才能进行编码，今天黎老师给我们介绍了怎样用uml画图！
1要做软件先得了解软件的生命周期

1、问题的定义及规划： （可行性分析报告和软件开发计划）
 此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2、需求分析： (需求分析说明书和初步的用户手册)
 在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
3、软件设计： (概要设计、详细设计)
 此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
4、程序编码： （提交源程序及清单)
 此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
5、软件测试： (提交软件维护测试报告)
 在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试（白盒）、集成测试（黑盒，功能测试、强度性能测试）以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
6、运行维护：软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。（提交软件维护报告）

2.增量和迭代模型

 增量迭代是RUP （Rational Unified Process）统一过程常采用的软件开发生命周期模型。增量和迭代有区别但两者又经常一起使用，所以这里要先解释下增量和迭代的概念。假设现在要开发A、B、C、D四个大的业务功能，每个功能都需要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增量来完成，第一个增量完成A,B功能，第二次增量完成C,D功能。而对于迭代开发来将则是分两次迭代来开发，第一次迭代完成A、B、C、D四个基本业务功能但不含复杂的业务逻辑，而第二个功能再逐渐细化补充完整相关的业务逻辑。在第一个月过去后采用增量开始时候A、B全部开发完成，而C、D还一点都没有动，而采用迭代开发的时候A,B,C,D四个的基础功能都已经完成。

 RUP强调的每次迭代都包含了需求、设计和开发、测试等各个过程，而且每次迭代完成后都是一个可以交付的原型。迭代不是并行，在每次迭代过程中仍然要遵循需求->设计->开发的瀑布过程。迭代周期的长度跟项目的周期和规模有很大的关系。小型项目可以一周一次迭代，而对于大型项目则可以2-4周一次迭代，如果项目没有一个很好的架构师，很难规划出每次迭代的内容和要到达的目标，验证相关的交付和产出。因此迭代模型虽然能够很好的满足与用户的交付和需求的变化，但确是一个很难真正用好的模型。

3.软件设计的重要性

当今软件开发已不再是个人英雄时代，一个软件通常需要一个团队进行集体开发，为了便于开发成员交流和记忆。在你开始动手开发前，必须把你要做什么？做成什么样，怎么个做法？用文字和图例表示出来。
虽然表面上看来，一些人没做设计就开始做项目，其原因有二：太有经验，在做之前他就构思了，只是没把构思的内容用文字规范划记录下来；太没经验，不懂得如何做，只是是边做边调整思路，在做的过程中隐含设计，这样更浪费时间。不搞设计的结果，往往是返工和推倒重来。
设计不用太在意文档的规范性，否则就会本末倒置，只要能把你的思路整理出来，表达清楚即可。爱因斯坦做7个小板凳的故事对我们的启发非常大，不要因为担心做不好就不做，这样永远只会裹足不前，只要开了头，就有进步的机会，永远没有最好的东西，只有更好，更好需要基于第一次开始。

5.UML——Unified modeling language
一件复杂事情的做法怎样才能想清楚呢？是不是可以借助一些道具、技巧和方法来帮助想呢？想清楚以后是不是应该在纸面上留下一些结果，以方便自己使用和与人交流？这个结果用什么格式来记录，别人才容易看懂呢？UML是一种用于软件系统分析和设计的语言工具，它用于帮助软件开发人员进行思考和记录思路的结果。
uml本身是一套符号的规定，就像数学符号和化学符号一样，之所以出现这些符号定义，是因为这些符号背后对应着一套思想和方法，这些符号用于帮助描述这套思想和方法的，这些符号是由这套思想和方法催生的。要学uml，就是要借助这些符号来掌握背后的思想和方法，这些符号虽然必须掌握，但它远不如它背后对应的思想和方法重要。
必须熟练掌握了某种面向对象的编程语言和跟着实施了若干个软件项目，才适合学习uml和理解uml中的一些内容，才会有好的学习效果。很难想象一个没有在铁路工地上工作过的人，怎么去设计铁路！！！ UML解决编码前的设计问题，而不解决编码过程的实施问题，我们前面学习的各种编程技术是解决编码过程的实施，必须有了这些基础才能理解和运用UML。

6.UML图

用例图
静态结构图：类图、对象图、包图、组件图、部署图
动态行为图：交互图（时序图与协作图）、状态图、活动图

画UML图与写文章差不多，都是把自己的思想描述给别人看，关键在于思路和条理，图好看与否就是看你的字是否规范，至于工具，就像你用什么笔，不算非常重要，关键在于意，而不在于形。

7.用例描述

    用例图只是简单地用图描述了一下系统，对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。
　　对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。下面说说各个部分的意思：
　　简要描述：对用例的角色、目的的简要描述；
　　前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；
　　基本事件流：描述该用例的正常基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流。
　　其他事件流：表示这个行为或流程是可选的或备选的，并不是总要执行它们；
　　异常事件流：表示发生了某些非正常的事情所要执行的流程；
　　后置条件：用例一旦执行后系统所处的状态；

用例图和用例描述设计实例请看附件文档

8.类图和对象图
用于描述系统中的对象类本身的组成和对象类之间的各种静态关系。
类之间的关系：依赖、泛化（继承）、实现、关联、聚合与组合
对象图描述一组对象和它们之间的联系，它是系统状态的某一时刻的快照，它的使用相当有限，它主要用于了解系统在某个特定时刻的具体状况和数据结构。
对象图表示方法与类图大体相同，对象图中的对象属性可以有具体值，类图中的一个类可以对应成对象图中多个对象，例如，部门类的自关联就可以对应成多个部门对象之间的关联。