基于UML2.0的系统设计思想.doc

基于基于 UML2.0 的系统设计思想的系统设计思想原文链接 Language)是一种建模语言，更是一种系统分析设计的最佳实践方法我从 2003 年开始接触 UML，从 UML1.1 到 2.0，感受到了 UML 的独特魅力，它不仅仅成为在项目和产品分析设计过程中的统一标准，还逐步成为了从需求到测试的最常用公共语言我记得在最早接触 UML 的那段时间，项目组还在辛苦的用着面向结构化的设计思想，写着 SRS，画着流程图和数据流图；对 OO 的设计思想还未真正接触，对于 UML 只知道系统的设计可以通过 9 种不同的图来解剖系统，9 种图代表了系统的 9 种纬度，至于如何用到项目中是完全没有概念后来，随着 Java 盛行，OO 的思想占据主导，因此接触 UML 更多了发觉了解 UML 越深入就越被其吸引，UML 不仅仅是一些图，不仅仅是系统的不同剖面，更是一种业务和系统模型的构造过程并开始在项目中推动使用 UML 的标准语言，比如用例图，比如类图直到现在，基于 UML2.0 的应用设计思想仍然是团队中需求、设计、开发人员的主要指导思想虽然 UML1.0 的 9 种图如今扩展到 2.0 的 13 种图，然而思想却没有太大变化，在设计中我们依然以用例为驱动，在设计中注重对象的状态变化的分析，注重类的分析和对象间的关系行为分析。

如下图所示，概括了基于 UML2.0 的 APP 设计思想UML 的用法的用法在我所接触到的项目中，UML 是一种设计的指导思想，是一种标准我经常把UML，CMMI 和 Prototype 合称为项目成功的三驾马车现在Agile比较流行，特别是在需求容易变化，项目规模不大的前提下，RUP和Scrum为代表的敏捷方法是可以取代CMMI的一些做法CMMI 负责对项目的各个过程域提供最佳实践方法指导，通过流程、模版和规范来约束和指导操作行为，以减少项目风险和提升项目质量，同时确保组织级的资产成为可持续发展的财富Prototype 是对需求过程最好的一种检验，我一直认为需求捕获和分析的能力是项目是否能够交付的最大保障所以，我迷信通过 Prototype 来与用户迭代的确认，与开发测试人员按原型来验收成果UML 不用多说了，是指导需求，设计和开发过程的一种思想另一方面，Martin 把 UML 的用法从深浅分作三个层次：草稿草稿：是最常用的一种方法，主要用于沟通系统的某些层面如果希望使用的更深入一些，可以通过正向工程和反向工程，实现模型和程序框架的互相推导蓝图蓝图：展现完整的系统设计细节，能够指导开发。

与草稿的区别在于，草稿并不是完整，而是注重强调需要交流的重点；而蓝图是完整的，把程序工作变得更简单草图是探索式的，蓝图是系统性的程序程序：以 MDA（模型驱动开发）为基础，能够自动从 PIM 转化为 PSM，再从 PSM 转化为程序代码的过程下面谈谈从我的理解如何把 UML 的思想映射到项目的各个过程中，这些图又如何配合起来使用UML2.0 包括 13 种图，其中类图，组件图，合成结构图，部署图，对象图和包图被归于为静态结构图；活动图，用例图，状态机图，时序图，通讯图，交互概览图和时间轴图归属于动态行为图在需求分析阶段，可以用到的是用例图，类图，活动图和状态图在设计阶段，一般用到类图，时序图，包图，状态图和部署图用例图（用例图（use case））用例图，用来描述人机交互，与系统的互动是定义和描述需求的最好方法，同时一个好的用例设计，一定是将用例映射到系统实现的类，用例说明了类的迁移和操作如下面的用例图所示，在用例中描述了这些内容：用例的关联角色是 Customer 系统边界是 TeeMall OnlineSystem 基础用例是 Place Order Place Order 用例包了(Include)了 Supply Customer Data ,Order Product, Arrange Payment 用例 Request Catalog 用例是 Place Order 用例的扩展(Extend)用例Arrange Payment 用例概括了 Pay Cash 和 Arrange Credit 两个子用例状态机图（状态机图（State Machine））状态机图是类的对象生命周期进行建模。

状态机是由状态和迁移构成，是对象局部化视图通常，使用状态机图来反映对象状态的变化和其生命周期的模型比如，以一个信用卡自助电影票购买终端的状态控制机为例在一般情况下，终端为空闲状态 Idle；当用户插入卡后，进入买票流程状态 1：验证信用卡密码验证，如果验证失败，则购票过程结束，终端退出用户的信用卡，状态变为空闲状态 2：选择信用卡密码验证成功后，进入选择状态选择电影场次和座位，并添加到自己的选择箱中状态 3：确认用户选择是否确认选择的电影票，如果选择继续，则返回到状态 2；如果选择支付，进入状态 4状态 4：购买系统完成支付扣账和打印出票，购买过程完成特殊操作，在上述四个状态中，都可以进行 cancel 操作，则进入 Idle 状态如下图所示，画状态机图有几个需要注意的地方：状态的变迁原因要在图上说明清楚；最好标明清楚状态的开始和结束；不要遗漏任何状态之间的切换状态机是一种深度关注细节的图，是观察对象状态变化的紧缩型视图然而，通过状态机图很难看到全局，系统的整体行为一定是通过多个状态机的结果来决定的，交互视图则正好起到了这个作用活动图（活动图（Activity））活动图用来表示用例的执行流程，一般活动图和状态机图结合使用，很多状态的变迁都是一个活动单元。

很多人将 UML 的活动图理解成为大家经常使用的业务流程图，特别在活动图中也可以使用泳道，就认为这个和 Visio 流程图中泳道的意义一样其实，UML 的活动图和一般的流程图最大区别在于，活动图是以 OOAD 为指导的，是以对象为分析基础，配合状态机图使用，为的是对用例的执行流程进行描述，而并不是以现实中的业务流程为视角如下图所示，描述了一个并行的泳道活动图以订单为核心的对象，并基于订单的几种不同状态进行的流程活动角色有：Customer，Sales，Stockroom订单状态有：Placed，Entered，Filled，Delivered订单活动有：Request Service, Pay, Take Order, Fill Order, Deliver Order, CollectOrder序列图（序列图（Sequence Diagram））序列图用来表示系统内部一群对象之间互传信息的情况，配合用例来使用的话，可以针对每一个用例设计系统内部的一群对象实现用例的运行情况对于程序员的编码工作来说，类图和序列图是最值得参考的两款图例如下图所示：交互概览图（交互概览图（Interaction Overview））交互概览图是活动图和序列图的混合使用形式，其主要结构像活动图，表示流程，但是参与流程的节点不是一般的动作(action)，取而代之的是“交互”(interaction)片段。

一个交互片段的内容，正是序列图的一小段交互片段对于复杂的对象交互，交互概览图可以用来表示交互片段之间的控制流程，其实可以弥补序列图不易表示控制流程的缺点不过，换个角度来看，假如序列图复杂到需要搭配交互概览图的话，这张序列图可能就需要拆解成两张图，或者进行重构以降低复杂度下图即是一个交互概览图的示例：对象图（对象图（Object）和类图（）和类图（Class））如要搞清楚类，先要明白什么是对象：“带有良好定义的边界、封装了状态和行为的具体实体，就是对象也称作类的实例；类是有相同属性、操作、方法、关系或行为的一组对象的描述符类和对象之间的关系就是《instantiate》比如，上面图中 BankAccount 就是一个标准的实体类表示方法，包括了类名，属性（属性类型，多重性，初始值），操作（操作名，参数，返回类型），类范围等除了实体类《Entity》外，还有接口类《Boundary》和控制类《Control》下图是一个典型的类图，描述了众多类之间的关系除此之外，还有多重性，自反关联等多种用法包图（包图（Package））包是模型元素的容器和物主，每个包都具有自身的命名空间，所有名称必须唯一。

包可以包含用例和类在设计过程中，一般设计好的包图，都将和程序源代码包目录结构一一对应起来如下图所示，就是一个包的关系图，反应包之间，包与边界，包内等关系下图是更为详细的类包关系图，反应了包所包含的类，及包之间的依赖关系通讯图（通讯图（Communication））通信图跟序列图的功用相似，都是用来表示一群对象互传信息的交互情况只是，通信图采用网状图形，强调对象之间的链接而序列图采用栅栏状图形，强调依次发送信息合成结构图（合成结构图（Composite Structure））组合结构图算也是一种类图，但是它的实用性并不是在一般的业务系统，而是侧重于实时系统或嵌入式系统类图用来表示系统内部的静态结构，而且它表示的不是系统某一个时刻的静态结构，它表示的是系统在任何时刻下都必须遵守的静态结构而组合结构图，它表示某一对象的内部结构，其内部由一组小对象组成这种图有两个特色：其一，它锁定的范围是对象内部，而不是一般业务系统的系统内部；其二，它强调对象内部的组成对象，一般在业务系统中对象是平等的部署图（部署图（Deployment））组件图和部署图都是用来表示实际元素的图，前者表示实际的软件程序，后者表示实际的硬件设备。

实际上，部署图最常用来表示系统的硬件设备及架构如下图所示：组件图（组件图（Component））组件图表示系统的组成组件(component)、组件所提供的接口(interface)或者是所需要的接口，以及组件之间的依赖关系组件指一个具体的模块单元(modular unit)，但是必须具备定义明确的接口(well-definedinterface)，并且易于替换(replaceable)如下图所示：时间图（时间图（Timing））前面提到的状态图用来表示对象因为事件的触发而转换状态，所以它着重于事件与状态的关系而时间图也是在表示状态变化，但是它着重于状态与时间的关系，用来表示对象在某一状态停留了多久的时间后，将转换到下一个状态时间图很像心电图，通过高高低低的曲线来强调状态的变化如下图所示：本文参考了：《《UML 精粹：精粹：UML Distilled Third Edition》》Matin Fowler 《《The Unified ModelingLanguage Reference Manual》》Jacobson,Booch, Rumbaugh《《UML 2.0 and UnifiedProcess》》Jim Arlow, Ila Neustadt。