UML建模工具
UML:
Unified Modeling Language (UML)又称统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
UML规范用来描述建模的概念有，类、对象、关联、职责、行为、接口、用例、包、顺序、协作，以及状态
UML可以辅助我们分析和设计复杂的系统，它用于帮助软件开发人员进行思考和记录思路的结果；
uml本身是一套符号的规定，就像数学符号和化学符号一样，之所以出现这些符号定义，是因为这些符号背后对应着一套思想和方法，这些符号用于帮助描述这套思想和方法的，这些符号是由这套思想和方法催生的。要学uml，就是要借助这些符号来掌握背后的思想和方法，这些符号虽然必须掌握，但它远不如它背后对应的思想和方法重要。
必须熟练掌握了某种面向对象的编程语言和跟着实施了若干个软件项目，才适合学习uml和理解uml中的一些内容，才会有好的学习效果。很难想象一个没有在铁路工地上工作过的人，怎么去设计铁路！！！ UML解决编码前的设计问题，而不解决编码过程的实施问题，我们前面学习的各种编程技术是解决编码过程的实施，必须有了这些基础才能理解和运用UML。
UML的特点:
UML(统一建模语言): 是一种基于面向对象的可视化建模语言.
UML 本身定义了一套图形符号，采用这些符号(如类图)作为建模语言, 使用这些符号可以形象地描述系统的各个方面,它用于帮助软件开发人员进行思考和记录思路的结果。
UML 通过建立图形之间的各种关系(如类与类之间的关系)来描述模型关系。
UML解决编码前的设计问题，而不解决编码过程的实施问题，我们前面学习的各种编程技术是解决编码过程的实施，必须有了这些基础才能理解和运用UML。
通用性
可视性
分析设计专用语言，凌驾于所有开发语言之上
业界的最佳实践和成功经验
面向对象的语义
UML不能做什么？
是一种描述语言，不能直接用于验证
只是一种表示方式，而不是建模方法
UML要结合一种程序开发方法
软件工程:
1968年在联邦德国召开的北大西洋公约软件可靠性会议(NATO)上,首次提出"软件工程"的概念,提出了在软件生产中采用工程化的方法,采用一系列科学的、现代化的方法技术来开发软件.这种工程化的思想贯穿到软件开发和维护的全过程.
软件生命周期: 软件的产生直到报废的生命周期
软件生命周期内有：问题定义, 可行性分析, 总体描述, 系统设计,编码, 调试和测试, 验收与运行, 维护升级到废弃等阶段
1、问题的定义及规划(可行性分析报告和软件开发计划): 此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2、需求分析(需求分析说明书和初步的用户手册): 在确定软件开发可行的情况下，对软件需要实现的各功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。
3、软件设计(概要设计、详细设计): 此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。
4、程序编码(提交源程序及清单): 此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
5、软件测试(提交软件维护测试报告): 在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试（白盒）、集成测试（黑盒，功能测试、强度性能测试）以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
6、运行维护（提交软件维护报告): 软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。
软件开发流程:
1,瀑布模型:
特点：
1). 各阶段间具有顺序性和依赖性: 后一阶段工作，必须在前一阶段工作完成后才能进行。
2). 质量保证机制的依赖性。即每一步都必须循序渐进，及早消除故障隐患，保证本阶段的工作的质量，从而达到保证整体软件质量的目的。
3). 推迟实现原则。前一阶段工作做的越细, 越扎实，后一阶段工作进行的就越顺利，强调”宁慢求好”。因此，各阶段工作总是一拖再拖，致使整个工期推迟实现。显然瀑布模型不能满足呈爆炸状增长的社会应用需求
2,螺旋迭代:
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3） 实施工程：实施软件开发和验证；
（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
但是，螺旋模型也有一定的限制条件，具体如下：
（1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
（2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
（3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险 一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。
极限编程（Extreme Programming，XP）
TDD (Test-Driven Development):以不断的测试推动代码的开发，既简化了代码，又保证了软件质量
“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。
40小时工作制：
结对编程：技术是一个非常简单和直观的概念：两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法、同一段代码或者同一组测试。
结对编程的好处是，一个人编写代码时另一个人在思考。思考者的头脑中保持总体概念，不仅手头问题的这一段，而且还有XP指导方针。例如，如果两个人都在工作，就不太可能会有其中一个说“我不想首先写测试”而离开。如果编码者遇到障碍，他们就交换位置。如果两个人都遇到障碍，他们的讨论可能被在这个区域工作的其他人听到，可能给出帮助。这种结对方式，使事情顺畅、有章可循。也许更重要的是，他能使程序设计更具有社交性和娱乐性。
敏捷开发:是一种以人为核心、迭代、循序渐进的开发方法.
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
RUP
统一软件开发过程(Rational Unified Process,RUP): 一个通用的软件流程框架, 以架构为中心, 用例驱动的迭代化开发流程. RUP 是从几千个软件项目的实践经验中总结出来的, 对于实际的项目具有很强的指导意义.
RUP 用二维坐标来描述. 横轴通过时间来组织, 是过程展开的生命周期特征, 体现开发过程的动态结构; 纵轴以内容来组织, 体现开发过程的静态结构.
软件生命周期的四个阶段：初始、细化、构造、交付；
初始: “获得项目的基础”. 该阶段的主要人员是项目经理和系统设计师. 所要完成的主要任务包括对系统的可行性分析; 创建基本的需求; 识别系统的关键任务.
细化: 主要目标是创建可执行构件基线; 精化风险评估; 捕捉大部分的系统功能需求用例; 为构造阶段创建详细需求. 该阶段并不是要创建可执行的系统, 而是展现用户所期望的需求.
构建: 完成所有的需求, 分析和设计. 该阶段的制品将演化成最终系统
交付: 将完整的系统部署到用户所处的环境中.
9个核心工作流.=6个核心过程工作流+ 3个核心支持工作流 ；
尽管6个核心过程工作流类似于传统瀑布模型中的几个阶段, 但迭代过程中的阶段是完全不同的, 这些工作流在整个生命周期中一次又一次被访问.
9个核心工作流在项目中轮流被使用, 在每一次迭代中以不同的重点和强度重复.
UML的图形分类：
1，用例图：用例建模的最主要功能就是用来表达系统的功能性需求或行为,规范系统的边际；
2，类图：用于描述系统中的对象类本身的组成和对象类之间的各种静态关系；
3，领域模型图：领域模型(domain model),概念模块,领域对象模型、分析对象模型、在开始项目分析时都会创建领域模型；
4，活动图：活动图本质上就是流程图,它描述了为了完成某一个目标需要做的活动以及这些活动的执行顺序；
5，状态图：用来描述一个特定对象的所有可能的状态，以及由于各种事件而引起状态之间的变化和转移。一般使用状态图描述业务实体对象；
6，时序图：时序图（Sequence Diagram）是强调消息时间顺序的交互图。时序图描述类系统中类和类之间的交互，它将这些交互建模成消息交换。时序图是一个模型，用于描述对象组如何随着时间在某些行为方面进行协作。
7，部署图：部署图用来帮助读者了解软件中的各个组件驻留在什么硬件位置，以及这些硬件之间的交互关系。
用例建模是UML建模的一部分，用例建模的最主要功能就是用来表达系统的功能性需求或行为。
1,参与者（Actor）：参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是其他系统等等。需要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。参与者在画图中用简笔人物画来表示;
2,用例是是系统为参与者提供的功能。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称：
要求：能看懂用例图即可；
用例：用例是文本形式的场景描述，是一种通过用户的使用场景来获取需求的技术。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。
区别用例和用例图。
用例的三个重要概念：参与者，场景，系统边界
创建用例图流程：
1.找出系统涉众发现和定义涉众(先询问客户的公司有哪些部门,部门里面有不同的职位:角色)
2.画定业务边界
3.获取用例
4.绘制用例场景图
5,编写用例描述文档；
6.绘制业务实体模型（领域模型）
7.绘制词汇表
用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。
对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。下面说说各个部分的意思：
简要描述：对用例的角色、目的的简要描述；
前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；
基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；
其他事件流（扩展点）：表示这个行为或流程是可选的或备选的，并不是总要执行它们；
异常事件流：表示发生了某些非正常的事情所要执行的流程；
后置条件：用例一旦执行后系统所处的状态；
类图:
用于描述系统中的对象类本身的组成和对象类之间的各种静态关系。
类之间的关系：泛化（继承）、依赖、关联、聚合与组合
依赖关系:
关联关系：
聚合关系：
聚合关系（Aggregation）表示的是整体和部分的关系，整体与部分可以分开。聚合关系是关联关系的特例，所以他具有关联的导航性与多重性。
使用带空心菱形的实线来表示：
组合关系:
也是整体与部分的关系，但是整体与部分不可以分开。
组合关系使用实心菱形：
继承关系:
泛化关系实际上就是继承关系，他是依赖关系的特例
使用空心的三角形：
活动图;
在UML里,活动图本质上就是流程图,它描述系统中事物或对象的变化流程。
开始状态：一个活动图一定有一个且只有一个开始状态，开始状态用一个实心圆表示；
结束状态：一个活动图必须有至少一个结束状态，可以有多个结束状态（正常结束状态和分支流程结束状态）；
活动：代表一个动作；
活动流：代表活动（流程）的运行方向；
分支：代表流程中的判断或者选择；
分叉和汇合：分叉代表流程中并行执行的流程；汇合代表并行执行的流程的汇总；
泳道：泳道可以规划出参与活动的各个角色；
时序图（Sequence Diagram）是强调消息时间顺序的交互图。时序图描述系统中类和类之间的交互，它将这些交互建模成消息交换。时序图是一个模型，用于描述对象组如何随着时间在某些行为方面进行协作。
时序图是一种强调消息时序的交互图，他由活动者（Actor）、对象（Object）、消息（Message）、生命线（Lifeline）和控制焦点（Focus of control）组成。在UML中，对象表示为一个矩形，其中对象名称标有下划线；消息在时序图中由有标记的箭头表示；生命线由虚线表示，控制焦点由薄薄的矩形表示(也称可为Activation Bar “活动条”)。
状态图：用来描述一个特定对象的所有可能的状态，以及由于各种事件而引起状态之间的变化和转移。
状态图的要素：开始状态/状态/事件/转移/结束状态
