UML基础概念
UML的基本概念
UML(Unified Modeling Language)
1.通用的可视化建模语言，能与所有的开发方法一同使用，可用于软件开发的整个生命周期。
2.UML能表达系统静态结构和动态信息，能管理复杂的系统模型。
3.UML便于软件团队之间的合作开发。
4.UML不是编程语言，支持UML语言的工具可以提供从UML到各种编程语言的代码生成，提供从现有程序逆向构建UML模型。
5.UML并不是万能的，它是一种离散的建模语言，对于特定的领域，比如：GUI、VLSI电路设计或基于规则的人工智能，用特定的语言和工具可能更合适。
6.UML是所有建模人员可以使用的通用建模语言。它包含主流建模方法的概念，从而可以替代现有的软件分析和设计方法，比如：OMT，Booch，OOSE等。
7.UML不是完整的开发方法，它不包括逐步的开发流程，但它提供所有必要的概念，具备足够的表达能力。
8.UML的另一个目标是：能尽量简洁地表达系统的模型。
UML概念可以划分为以下范围：
系统概念、静态结构、动态行为、交互行为、物理实现、各种图之间的关系、模型组织、扩展机制。
系统需求
用例视图：
1.从外部用户的角度来描述系统的行为，它将系统功能划分为对用户有意义的事物，这些事物被称为用例，用户被称为执行者。
2.用例试图 也就是描述活动者在各个用例中的参与情况，它指导所有的行为视图。
静态结构
静态视图(Static View)：
1.一个模型必须首先定义各种事物的内部特征和相互之间的关系。
2.应用概念建模成类，为描述事物的属性 和以及在这些属性上的操作。
3.类之间可以存在不同的关系，比如泛化(继承)、关联 和依赖 等。静态视图表示成类图，静态视图在某一时刻的快照称为对象图。
动态行为
状态机视图(State Machine View)：
1.对每个类的对象的生命周期进行建模。
2.描述对象时间上的动态行为。
3.由状态和迁移 组成的图，状态机通常附属于类，描述类实例对接受事件 的响应。
活动视图(Activity View)：
1.利用状态机对运算和工作流 进行建模的特殊形式。
2.活动图 的状态代表了运算执行的状态，而非一般对象的状态。
3.活动图和流程图很相似，不过它支持并发。
交互行为
交互视图(Interaction View)：
对象通过交互来实现行为，通过协作来进行建模，协作有结构和行为两方面。
1.结构包含为行为方面而定义的一系列角色和关系。
2.行为方面是绑定于角色的对象间的一系列交换的消息。
3.消息在协作中称为交互。
4.消息序列可用两种图来表示：顺序图 (重点在消息的时间顺序)、协作图 (重点在交换消息的对象间的关系)
物理实现
物理视图(Physical View)：
1.许多系统模型独立于最终的实现，在实现方面，必须充分考虑系统的重用性和性能。
2.UML有两种视图来表示系统的实现：实现视图 将可重用的系统片段打包成组件、部署视图 描述系统运行时资源的物理分布，这些资源称为结点。
各种图之间的关系
1.静态视图(类图，对象图)，物理视图(实现视图，部署视图)是描述系统的静态结构，没有交互、动作在里面。
2.用例图是描述系统的外部视图，反应系统和外部的交互。
3.活动图描述系统的外部 / 内部视图。
4.交互视图(顺序图，协作图)描述系统的内部视图，是动态的、交互的关系。
5.状态图描述单个类的动态行为。
模型组织
模型管理视图(Model Management View)：
1.任何大系统必须划分为较小的单元，以使人们能在某一时刻只接触有限的信息，不影响团队间的并行工作。
2.模型是利用包(Package) 和包的依赖 来进行管理的。
3.包是UML模型中通用的层次组织结构，包上的依赖总结了包内容的依赖关系。
扩展机制
扩展机制(Extension Mechanisms)：
1.UML能满足绝大部分系统建模的需要，但任何语言都不是万能的，它必须考虑一定的扩展机制。
2.UML的扩展机制包括约束 、标签值 和原型。
3.这些扩展机制可以用来为特定领域剪裁UML的配置，根据自身需要来使用建模语言。相当于模板，在模板的基础上进行扩展。
静态建模
一个模型必须首先定义各种事物的内部特征和相互之间的关系，下面介绍一些基本的模型元素：
类
类是具有相同属性、操作和关系的对象集合的总称。
通常在UML中类被画成矩形，包括三个部分：名称、属性 和操作 。
名称 ：每个类都必须有一个名字，用来区分其他的类。类名是一个字符串，称为简单名字。路径名字是在类名前加包含类的包名为前缀。
属性 ：类可以有任意多个属性，也可以没有属性，在类图中属性只要写上名字就可以了，也可以在属性名后跟上类型甚至缺性取值。
操作 ：操作室内的任意一个实例对象都可以调用的，并可能影响该对象行为的实现。
例如，以下为一个类的例子，
接口
接口是未给出实现的对象行为的描述，包含操作，但没有属性。一个或多个类可以实现接口，每个类实现接口的操作。
子系统（包）
1.任何大系统都必须划分为较小的单元，以使人们在某一时刻可以在有限的信息工作，使团队的工作不互相影响。
2.包可以包含各种模型元素和其他的包，包之间还可能存在一定的依赖。
3.子系统 是具有独立的说明和实现部分的包，代表了与系统其他部分具有清晰接口的清晰单元；通常代表了系统在功能或实现范围上的划分。
执行者、用例
1.执行者是与系统、子系统或类交互的外部人员，进程或事务。
2.在运行时，具体人员会充当系统的多个执行者，不同用户可能会成为一个执行者。
3.用例是系统提供的外部可感知的功能单元，目的是定义清晰的系统行为，不解释系统的内部结构。
4.用例可以与执行者关联，也可以参与其他的多种关系，比如扩展、泛化和包含等。
5.用户的动态部分用交互视图来描述，比如顺序图、协作图。
6.用例用椭圆来表示，用例名称标在椭圆下方，用实线与同自身通信的用户相连。
用例图
用例图描述执行者在各个用例中的参与情况
描述执行者在各个用例中的参与，即用用例图反应谁要使用这个系统，要什么样的功能。
组件、结点
1.组件是可重用的系统片段，具有良好定义接口的物理实现单元，每个组件包含系统设计中某些类的实现。
2.组件设计的原则：良好的组件不直接依赖于其它组件，而是依赖于其它组件所支持的接口，好处是系统中的组件可以被支持相同接口的组件所取代。
3.一个组件可能是源代码 、可执行程序 或动态库 。
4.结点代表系统运行时的物理对象，通常拥有运算能力，它可以容纳对象和组件实例。
注释
注释用于解释设计的思路，便于理解，一个好的模型应该有详尽的注释。
关联
1.关联描述了系统中对象和其它实例之间的离散的连接，关联是有序的，它允许重复，关联的实例是链 。
2.关联至对象的连接点称为关联端点 ，很多信息被附在关联端点上，它拥有角色名、重数(多少个类的实例可以关联于另一个类的实例)，可见性等。
3.关联有自己的名称，可以拥有自己的属性，这时关联本身也是类，称为关联类 。
聚集、组合
**聚集(Aggregation)**用来表达整体 - 部分关系的关联。
**组合(Composition)**是一种聚集，是关联更强的形式。
泛化
1.泛化是一般化和具体化之间的一种关系。
2.继承就是一种泛化关系，更一般化的描述称为双亲 ，双亲的双亲称为祖先 ，更具体化的描述称为孩子 ，在类的范畴，双亲对应超类，孩子对应子类。
多重继承
多重继承，一个孩子可以从多个双亲继承属性和方法。多重继承可能存在冲突 ，因为被继承的双亲可能存在相同的类声明，这时，最好显式解决冲突问题。
依赖
1.依赖指明两个或两个以上模型元素之间的关系。
2.依赖有很多种类，比如：实现(realize)、使用(usage)、实例化(instantiate)、调用(call)、派生(derive)、访问(access)、引入(import)、友元(friend) 等等。
实现
实现是依赖的一种，但由于它具有特殊意义，实现是连接说明和实现之间的关系。
约束
约束用来表示各种限制，如关联路径上的限制，和属性特征检测(存在、所有)。
类图
静态视图是UML的基础，静态视图表示为类图，主要是描述类和类之间的关系。
对象图
对象图是系统在某一时刻的快照。
动态建模
状态机图
状态机图：
1.对单个类的对象的生命周期进行建模◆描述了对象时间上的动态行为
2.每个对象被认为是事件驱动 的孤立实体。
3.由状态 和跃迁 组成的图，通常状态机附属于类，描述类实例对接受事件的响应。
4.事件表达对象间的调用、显式信号、值的改变或时间的推移。调用事件、变更事件、信号事件、时间事件。
5.状态描述对象生命周期的一. 段时间，可以是等待其它事件时所处的时间，或是执行某一活动时所处的时间，状态分为简单状态 和复合状态 。
跃迁定义对象对某一事件发生的反应
1.迁移具有触发事件 、跃迁条件、动作 和目标状态 。
2.跃迁的种类有外部跃迁 和内部跃迁 。外部跃迁是最普通的跃迁，会发生状态改变；内部跃迁不发生状态改变。
3.跃迁有两个隐式动作：进入动作 和退出动作。无论何时进入和退出时都要执行，这方便进入时进行初始化工作，退出时进行资源的释放工作。
用例图
用例图描述各个执行者在各个用例中的参与情况，描述系统为用户所感知的外部视图。通过用例图才把需求真正地反映出来。
用例图的功能：
1.捕获系统用户需求描述系统边界。
2.指明系统外部行为。
3.指导系统开发者的功能开发。
4.系统建模的起点，指导所有的类图和交互图的设计。
5.产生测试用例，用户文档。
6.估计项目大小和进度。
7.用例可以参与多种关系：关联、扩展、泛化和包含。
活动图
1.活动图是用状态机对工作流进行建模的特殊形式，它和流程图很类似，不过它支持并发控制。活动图强调的是活动的关系，而状态图强调的是状态的变化。
2.活动图一般不描述所有的运算细节，它显示活动的流，但不显示执行活动的对象。
3.活动图处于系统的外部和内部视图之间，所以它可以作为设计的起点，为了完成设计，每个活动必须扩展成一个和多个操作，每个操作被指派给特定的对象来实现。
4.将商业组织控制的活动划分在一起，这类划分可以通过分隔的区域来表达，由于它们的外观，每个区域称为泳道(swimlane) 。
交互图
1.对象行为是通过交互来实现的，交互是对象间为完成某-目的而进行的一系列消息 交换。
2.消息是对象间的单向通信，从发送者到接受者的携带信息的控制流。消息可能带有值参 。
3.消息序列可用两种图表示：顺序图(重点在消息的时间顺序) 和协作图(重点在交换消息的对象间的关系) 。对协作图来说，时间顺序可以从顺序号获得。
4.顺序图用二维表来表示交互，纵向是时间轴，横向是参与的角色以及它们交换的消息。
5.角色的生命周期表现为生命线，- 条垂直的线，在**的时间段里是双线，在状态保持的时间里是虚线。
6.消息表示为从一条生命线出发到另- -条生命线的有向线，从上而下，表示消息的时间顺序。
协作图
1.协作图包含分类角色和关联角色，当它实例化时，对象被绑定到分类角色，链被绑定到关联角色关联角色还可能被各种暂时性的链来充当，如过程参数和局部过程变量，链可以指定暂时性的原型：{parameter}、{local}或自身调用{self}。
2.协作图对实现协作的对象和链进行建模，而忽略其他对象。
3.通常在一个协作图中每个对象分配一个符号，然而有时不同状态的对象需要显式指出，流 将同一个对象的不同状态版本关系在一起，使用{become}原型。流的{copy}原型不太常用。
物理架构
实现视图
实现视图描述可重用的系统组件以及组件之间的物理依赖，比如动态链接库、应用程序。
部署视图
部署视图描述系统资源在运行时的物理分布，系统资源成为结点。
建模步骤
- UML是一种建模语言而不是方法，这是因为JML中没有过程的概念，而过程正是方法的一个重要组成部分。UML本身独立于过程，这意味着用户在使用UML进行建模时，可以选用任何适合的过程。
一般采用的建模过程有：瀑布开发模型、迭代递增开发模型，如下图所示，
瀑布开发模型 ↓↓↓
迭代递增开发模型 ↓↓↓
- 基于UML 的系统开发采取增量迭代开发模型。
[1]需求 最初需求规格说明 应当由代表系统最终用户的人员提供，内容包括系统基本功能需求和对计算机系统的要求。
[2]分析 分析的任务是找出系统的所有需求并加以描述，同时建立模型，以定义系统中的关键领域类，应由系统用户和开发人员合作完成。
分析的第一步是定义用例 ，以描述所开发系统的外部功能需求。用例分析包括阅读和分析需求说明，此时需要与系统的潜在用户进行讨论
[3]设计 设计阶段的任务是通过综合考虑所有的技术限制，以扩展和细化分析阶段的模型。
设计阶段可以分为两个部分：结构设计 是高层设计，其任务是定义包(子系统)，包括包间的依赖性和主要通信机制。我们希望得到尽可能简单和清晰的结构，各部分之间的依赖尽可能的少，并尽可能的减少双向的依赖关系。第二部分是详细设计 ，细化包的内容，使编程人员得到所有类的一个足够清晰的描述。
结构设计 一个设计良好的系统结构是系统可扩充和可变更的基础。包实际上是一些类的集合。类图中包括有助于用户从技术逻辑中分离出应用逻辑(领域类)，从而减少它们之间的依赖性。
详细设计 详细设计的目的是通过创建新的类图、状态图和动态图(顺序图、协作图和活动图)，描述新的技术类，并扩展和细化分析阶段的对象类。
[4]实现 构造或实现阶段是对类进行编程的过程。可以选择某种面向对象对象编程语言(如Java)作为实现系统的软件环境。Java很容易实现从逻辑视图到代码部件的映射，因为类到Java代码文件之间是一 一映射关系。
在实现阶段中，可以选取各种图的说明来辅助编程，比如:类图，状态图和动态图等。
[5]测试和配置 完成系统编码后，需要对系统进行测试，它通常包括:单元测试 、集成测试 、系统测试 和验收测试 。
在单元测试中使用类图和类的规格说明，对单独的类或一组类进行测试;在集成测试中，使用组件图和合作图，对各组件的合作情况进行测试;在系统测试中，使用用例图，以检验所开发的系统是否满足例图所描述的需求。系统的配置是实际地交付系统，包括文档和组成模型等。