学习编程，热爱编程

第一次写软工文档，感觉好多地方按照给的标准文档不知道该填些什么，或者说是知道填什么----UML的图。但是对于什么是UML，UML的图又是什么几乎都不了解。终于开始学习UML（这样的学习让我感觉很有层次感，一环扣一环，知识的循软件系统模型环，重复。），希望通过接下来的学习能再次完善自己破烂不堪的第一次机房收费文档。UML(Unified Modeling Language )即统一建模语言是一

时序图（sequence diagrams）描述了对象之间传递消息的时间顺序，它用来表示用例中的行为顺序，是强调消息时间顺序的交互图。时序图描述类系统中类和类之间的交互，它将这些交互建模成消息交换。也就是说，时序图描述了类以及类间相互交换以完成期望行为的消息。当执行一个用例行为时，时序图中的每一条消息对应了一个类操作或状态机中引起转换的触发事件。序列图简单的构成：其中：1：角色 ：

构件图（Component diagrams）是面向对象系统的物理方面建模时使用的两种图之一，另一种是配置图。构件图描述了软件组件以及组件之间的关系，组件本身是代码的物理模块，构件图显示了代码的结构。在UML中每一个构件图只是系统实现视图的一个图形表示，也就是说任何一个构件图都不能描述系统实现视图的所有方面，当系统的构件组合起来，这时才能系统完整的实现视图，而其中的一个构件图只是表示实现视图的一部

WHAT:活动图（Activity Diagram）是UML中描述系统动态行为的图之一，它用于展现参与行为的类的活动或动作。它是UML用于对系统的动态行为建模的一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图本质上就是一种流程图，着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。活动图模型如下图：HOW:在系统建模过程中，活动图

状态图主要描述一个对象在其生命周期内的状态变化，对象由事件驱动并满足一定的条件从一个状态转换到另一个状态。可以看出状态图其实是针对一个对象来说的，主要描述了对象的行为如何影响对象状态的改变。简单说一下状态图的构成：状态图是对系统的动态方面的建模，适合描述跨越多个用例的对象在其生命周期中的各种状态之间的转换。对象可以是类，接口，构件，节点。状态图描述了状态间的转换顺序，通过状态的转换

用例图（Use Case Diagram）主要用来描述用户需求，从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者提供什么功能。通俗说用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给

用例图是解决用户需求的图，画好用例图一定要理清用例之间的关系。用例之间有三种关系：包含（include）扩展（extend）和泛化（generalization）。下面介绍三者的相同点和不同点以便区分：相同点： 三者都是从现有的用例中抽取公共信息的那部分，作为一个单独的用例，然后采用不同的方法来重用这个公共的用例。（感觉都是面向对象里的继承思想，减少模型维护的工作量）。不同点：1.包含

类图（Class Diagram）由许多静态说明性的模型元素等组成。显示出类，接口以及他们之间的静态结构和关系，用于描述系统的结构化设计。同时类图是定义其他图的基础，在类图基础上可以使用状态图，协作图，组件图和配置图等进一步描述系统其他方面的特性。简单来说，类，接口和关系构成了类图：由于每个人寻找类的角度不同，所以画出的类图可能有所不同，下面是我从不同角度绘制的机房收费系统的类图，不足之处

A relationship is a general term covering the specific types of logical connections found on class and object diagrams.UML(Unified Modeling Language)shows the following relationships:1   General

UML总结UML是一种建模语言，是一种建模的标准。UML致力于用自己的语言来描述软件，不仅仅是从程序人员的角度，更是从用户的角度。更清晰明确的处理用户的需求，描述软件的静态结构和动态结构，从而使各个部门更好的协同合作，更高效，准确的设计软件。UML的理论落实到最终的实物便是我们常说的UML九种图。下面先大概的描述下这九种图的用途：1：用例图       描述参与者与用例之间的关系，是一