uml

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目 的其中一项不变真理：人是会死的， 需求 是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 2.5 小结与练习 小结 本章最主要的目的其实就是帮你“洗脑”！ 需求分析 的工作其实很复杂，可以足够写一本书的内容。而我希望只通过一个章节能向你讲清楚 需求 分析工作的基本道理，让你认清需求分析工作的根本，并且明白到要做好需求分析工作并没有捷径，只有切实提高自身水平。下面我们一起来回顾一下本章的主要内容： 认识清楚需求分析工作中客户方和 软件 公司一方各种角色的特点，能帮助我们需求分析工作更有针对性。总体来说，客户方的倾向是花小钱办大事，而软件公司一方的倾向是多拿钱少办事。 “双赢”是我们应该追求的目标，软件只有对客户的工作真正有帮助，客户才算“赢”，而在客户能“赢”的基础上，我们软件公司才可能实现自己的“赢”。 不要抱怨客户变来变去，客户对需求的理解总是趋向上升的，而 项目 组也是一样。如果项目组对需求的认识落后于客户，就会陷于“被动”的局面，项目组应该努力提升水平，想办法让自己对需求的认识领先于客户。 需求分析工作是很复杂难度很高的工作，如果看不清楚客户的真正

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目的其中一项不变真理：人是会死的，需求是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 （本书已经发售） 作者： 张传波 网名：Fireball（火球） www.umlonline.org 2.1 需求分析面面观 客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子……很多角色参与项目工作，每种角色会从自身角色出发来理解需求，以致各种角色对需求的理解会不太一样。下表对各种角色的特点进行了分析： 表 2.1 各种角色的特点 另外要说明的是： 客户一方的总倾向是：自己少花钱，让软件公司多做事情。 而软件公司一方的总倾向是：多拿客户的钱，尽量少做事情。 影响各人对需求理解的主要因素有两方面：一方面是角色的思考倾向，上表反应了这点；另外一方面是人的需求分析能力，能力越强的人越能把握需求，本书重点讲解的内容就是如何 活用UML 来提升需求分析能力。 而更“离谱”的是：每个人嘴巴上说的需求和心目中的需求总是有差异的，所谓的“词不达意”，受表达能力所限，不是每个人都能完整准确地表达自己的想法；有时候客户今天想要这个

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目的其中一项不变真理：人是会死的，需求是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 作者： 张传波 www.umlonline.org www.umlonline.org/school/ 本文来自新书《活用UML——需求分析高手》的第二章。 第一章已经在博客园发布，文章名字叫：UML一篇文章就学通 文章链接： http://www.cnblogs.com/umlonline/archive/2011/07/12/2104626.html 以下是正文： 2.1 需求分析面面观 客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子……很多角色参与项目工作，每种角色会从自身角色出发来理解需求，以致各种角色对需求的理解会不太一样。下表对各种角色的特点进行了分析： 表 2.1 各种角色的特点 另外要说明的是： 客户一方的总倾向是：自己少花钱，让软件公司多做事情。 而软件公司一方的总倾向是：多拿客户的钱，尽量少做事情。 影响各人对需求理解的主要因素有两方面：一方面是角色的思考倾向，上表反应了这点

时序图（Sequence Diagrams） 时序图描述对象之间消息的发送顺序，强调时间顺序。时序图是一个二维图，横轴表示对象，纵轴表示时间，消息在各对象之间横向传递，依照时间顺序纵向排列。用箭头 表示消息、用竖虚线表示对象生命线。 时序图的作用 1、展示对象之间交互的顺序。将交互行为建模为消息传递，通过描述消息是如何在对象间发送和接收的来动态展示对象之间的交互； 2、相对于其他 UML 图，时序图更强调交互的时间顺序； 3、可以直观的描述并发进程。 时序图组成元素 角色（Actor） 系统角色，可以是人、机器、其他系统、子系统；在时序图中用表示。 对象（Object） 1、对象的三种命名方式 第一种方式包括对象名和类名 第二种方式只显示类名，即表示它是一个匿名对象， 第三种方式只显示对象名不显示类名， 2、命名方式的选择 三种命名方式均可，哪种最容易让阅读该时序图的人理解，就选择哪种。 3、对象的排列顺序 对象的左右顺序并不重要，但是为了作图清晰整洁，通常应遵循以下两个原则：把交互频繁的对象尽可能的靠拢；把初始化整个交互活动的对象放置在最左端 生命线（Lifeline） 在时序图中表示为从对象图标向下延伸的一条虚线，表示对象存在的时间。 控制焦点（Focus of Control） 又称为激活期，表示时间段的符号，在这个时间段内对象将执行相应的操作。可以理解为 Java

继承关系 继承关系中，子类继承父类的所有功能，父类所具有的属性、方法，子类应该都有。子类中除了与父类一致的信息以外，还包括额外的信息。例如：公交车、出租车和小轿 车都是汽车，他们都有名称，并且都能在路上行驶。其类图如下： 实现关系 接口（包括抽象类）是方法的集合，在实现关系中，类实现了接口，类中的方法实现了接口声明的所有方法。例如：汽车和轮船都是交通工具，而交通工具只是一个可移动 工具的抽象概念，船和车实现了具体移动的功能。 组合关系 组合关系表示类之间整体与部分的关系，整体和部分有一致的生存期。一旦整体对象不存在，部分对象也将不存在，是同生共死的关系。例如：人由头部和身体组成，两者 不可分割，共同存在。 聚合关系 聚合关系也表示类之间整体与部分的关系，成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在。例如：公交车司机和工衣、工帽是整体与部分的关系， 但是可以分开，工衣、工帽可以穿在别的司机身上，公交司机也可以穿别的工衣、工帽。 关联关系 关联关系是类与类之间最常用的一种关系，表示一类对象与另一类对象之间有联系。组合、聚合也属于关联关系，只是关联关系的类间关系比其他两种要弱。 关联关系有四种：双向关联、单向关联、自关联、多重数关联。例如：汽车和司机，一辆汽车对应特定的司机，一个司机也可以开多辆车。 在多重性关系中，可以直接在关联直线上增加一个数字

来自尚学堂《UML建模技术》视频 1 内容 浮光掠影鸟瞰UML UML各种图形的名称及作用 UML如何用于开发过程简略介绍 2 UML--统一的图形语言 描述系统结构 描述系统行为 用例图 需求捕获，测试依据 顺序图 捕获时间顺序 类图 静态系统结构 协作图 强调对象协作 对象图 对象之间的关联 状态图 生命周期状态转换 构建图 构件之间的关联 活动图 工作流程模型 部署图 构件的物理部署 3 9种图的灵活使用 这9种图如何使用呢？ 首先，我们要先画 Use Case Diagrams 也就是 用例图 。用例本身不是这个图，而是 用例文档 ！ 有了用例之后，我们根据这个用例来构建我们的 Activity Diagrams 也就是 活动图 。这个活动图来表示我们use case的活动过程。 有了用例之后，他的每个特殊的场景，我们给他构建不同的 Interaction Diagrams(这里说的是两种图，一种是 sequence diagram 序列图 ；一种是 collaboration diagram 协作图 ) 有了用例之后，我们可以抽象出他的class来，use case抽象出来的class，只是静态的分析类。我们根据Activity Diagrams以及Interaction Diagrams还可以把这个class进一步细化，做成设计类。有了这个设计类我们就可以对他进行编码了