UML实用技术介绍用例类图时序图（开发流程）课件

Uml实用技术UnifiedModelingLanguageUml实用技术UnifiedModelingLangua1

我们动手做做练习

UML帮助我们做需求简单了解UMLUML在设计阶段如何发挥作用主题我们动手做做练习UML帮助我们做需求简单了解UMLUML在2

我们动手做做练习

UML帮助我们做需求简单了解UMLUML在设计阶段如何发挥作用主题我们动手做做练习UML帮助我们做需求简单了解UMLUML在3软件开发过程详解目前的现实是什么？——业务建模在这个现实下，开发系统是为了达到什么目标？——愿景为了达到目标，系统应对外提供什么样的功能和性能？——需求为了提供这些功能，系统内部应该有什么样的核心业务机制？——分析为了满足性能，系统的核心机制如何在选定的架构上实现？——设计找到问题解决问题软件开发过程详解目前的现实是什么？——业务建模找解4UML三个主要作用使用可视化建模来获取并表现商业逻辑和对象使用可视化建模来分析和设计计算机应用程序理由一：UML是客户、系统分析员和程序员之间的“桥梁”用例图活动图状态图时序图对象图部署图……UML三个主要作用使用可视化建模来获取并表现商业逻辑和对象使5UML三个主要作用理由二：UML从客户的角度将复杂的系统整理清楚UML三个主要作用理由二：UML从客户的角度将复杂的系统整理6UML三个主要作用software可移植技术交互性能全面容量稳定性错误处理容错性功能需求成本兼容性理由三：UML能使越来越复杂的软件系统架构更加合理和健壮UML三个主要作用software可移植技术交互性能全面容量7系统模型可由“4+1”视图展现逻辑视图场景视图系统功能分析设计结构系统并发工作情况实现视图实现模块和代码间的关系部署视图系统物理拓扑架构进程视图4+1视图模型，从5个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容系统模型可由“4+1”视图展现逻辑视图场景视图系统功能分析设8系统模型可由“4+1”视图展现逻辑视图LogicView逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务.在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析，这些主要来自问题领域（ProblemDefinition)。在面向对象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类图（ClassDiagram）来描述逻辑视图。系统模型可由“4+1”视图展现逻辑视图LogicV9系统模型可由“4+1”视图展现开发视图Development/ModuleView开发视图主要用来描述软件模块的组织与管理（通过程序库或子系统）。服务于软件编程人员，方便后续的设计与实现。它通过系统输入输出关系的模型图和子系统图来描述。要考虑软件的内部需求：开发的难易程度、重用的可能性，通用性，局限性等等。开发视图的风格通常是层次结构，层次越低，通用性越好（底层库：JavaSDK，图像处理软件包）。上升到组件概念系统模型可由“4+1”视图展现开发视图Developm10系统模型可由“4+1”视图展现进程视图

ProcessView进程试图侧重系统的运行特性，关注非功能性的需求（性能，可用性）。服务于系统集成人员，方便后续性能测试。强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。现在公司里不再考虑功能能不能实现，而在于PK性能，可扩展性等非功能性。系统模型可由“4+1”视图展现进程视图ProcessVi11系统模型可由“4+1”视图展现

物理视图(physicalview)物理试图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。系统模型可由“4+1”视图展现物理视图(physical12系统模型可由“4+1”视图展现场景(Scenarios)

场景用于刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系。文本、图形表示皆可。n小结逻辑视图、开发视图，都主要是用来描述系统的静态结构。进程视图、物理视图，主要是用来描述系统的动态结构。并非每个系统都必须把5个视图都画出来，而是各有侧重。例如MIS系统侧重于逻辑视图、开发视图，而实时控制系统则侧重于进程视图、物理视图系统模型可由“4+1”视图展现场景(Scenarios)13模型可由9个图来展现UseCaseDiagramUseCaseDiagram用例图ScenarioDiagramScenarioDiagram协作图StateDiagramStateDiagram组件图ComponentDiagramComponentDiagram部署图StateDiagramStateDiagram对象图ScenarioDiagramScenarioDiagram状态图UseCaseDiagramUseCaseDiagram时序图StateDiagramStateDiagram类图活动图模型墨绿色表示动态图粉红色表示静态图（可把用例图单列出来）功能静态结构物理架构动态行为用例图，类图，时序图经常用模型可由9个图来展现UseCaseUseCase用例图S14UML9种图用例图描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。类图类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。对象图与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。活动图描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。UML9种图用例图描述角色以及角色与用例之间的连接关系。说15UML9种图状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；序列图（顺序图）序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。协作图和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。构件图（组件图）描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。部署图（配置图）是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。UML9种图状态图描述类的对象所有可能的状态，以及事件发生16UML9种图用例图：业务建模、需求、测试类图：业务建模、分析、设计对象图：业务建模、分析、设计组件图：设计部署图：设计顺序图：业务建模、分析、设计协作图：业务建模、分析、设计状态图：需求、分析、设计活动图：业务建模、设计结构行为敏捷建模原则：需要时再添加可互换可互换UML9种图用例图：业务建模、需求、测试结构行为敏捷建模原则17主要步骤主要步骤18

我们动手做做练习

UML帮助我们做需求简单了解UMLUML在设计阶段如何发挥作用主题我们动手做做练习UML帮助我们做需求简单了解UMLUML在19UML之用例图

需求分析中我们如何整理和抽象我们从用户那得到的业务描述。

用流程图描述业务流程、用用例图表达用户业务工作UML之用例图 需求分析中我们如何整理和抽象我们从用户那得20识别执行者执行者要点：系统外——必须和它交互系统边界——直接与系统交互有意义的交互——属于目标系统的责任任何事物——人、外系统、外部因素、时间识别执行者执行者要点：21识别执行者抽象出执行者的思路：谁使用了系统的主要功能？谁改变了系统的主要数据？谁从系统获取信息？谁需要系统的支持以完成日常工作任务？谁负责维护、管理并保持系统正常运行？系统需要应付（处理）哪些硬件设备？系统需要和哪些外部系统交互？谁（或什么）对系统运行产生的结果感兴趣？有没有自动发生的事件？识别执行者抽象出执行者的思路：22识别执行者责任类似或重叠——抽象出执行者UML之执行者Actor之间也有继承关系。且注意图形表示。识别执行者责任类似或重叠——抽象出执行者UML之执行者Act23识别用例用例的基本定义： 用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。

——IvarJacobson（RUP）通俗地讲：执行者通过系统达到某个有用目标步骤路径目标识别用例用例的基本定义：通俗地讲：执行者通过系统达到某个有用24识别用例设计用例要注意以下要点：价值结果→有意义的目标系统执行→价值结果由系统生成执行者可见→业务语言，用户观点注意：抽象一组用例实例时控制好用例的粒度识别用例设计用例要注意以下要点：25识别用例有意义的目标：√×识别用例有意义的目标：√×26识别用例用户观点而非系统观点：用户观点系统观点识别用例用户观点而非系统观点：用户观点系统观点27识别用例用例命名：执行者视角动词（+宾语）状语定语如：批量修改登录记录编号识别用例用例命名：执行者视角动词（+宾语）状语28识别用例执行者使用这个系统达到什么目标？语法测试：【执行者】使用系统来【用例】识别用例执行者使用这个系统达到什么目标？语法测试：【执行者】29用例命名：慎用弱动词、弱名词30弱动词：进行、使用、复制、加载、重复……弱名词：数据、报表、表格、表单、系统……会掩盖真正的业务识别用例用例命名：慎用弱动词、弱名词30弱动词：进行、使用、复制、加识别用例讨论：几个登录？或注意角色的划分和公共用例的定义要不把用户抽象成三种，或者把登录抽象成三种。识别用例讨论：几个登录？或注意角色的划分和公共用例的定义要不31识别用例用例的粒度：四轮马车任何业务归根到底都可以看作CURD，但光CURD能为Actor提供价值吗？

CRUD是Create（创建）、Read（读取）、Update（更新）和Delete（删除）缩写警惕CURD泛滥！一般要避免全部使用，要抽象，公用的，其它的不要，但默认有。识别用例用例的粒度：四轮马车任何业务归根到底都可以看作CUR32识别用例用例的粒度：在四轮马车之前尽量细致另注：多个用例会操作同一项数据，即对一个数据项操作用例未必是同一个用例识别用例用例的粒度：在四轮马车之前尽量细致另注：多个用例会操33识别用例讨论：登录怎么处理？（确定用例之间的关系）用例有先后或前提关系时不要简单认为是简单的包含或者是扩展关系识别用例讨论：登录怎么处理？（确定用例之间的关系）用例有先后34更进一步的精度

用例图可以作用例文档的总图，进一步的精度：有层次的文档，文档中每一句话都有其价值更进一步的精度 用例图可以作用例文档的总图，进一步的精度：有35通过关系整理用例——用例的关系扩展：分离扩展路径包含：提取公共步骤，便于复用泛化：同一业务目的的不同技术实现大多数为包含关系通过关系整理用例——用例的关系扩展：分离扩展路径包含：提取公36include

是指用例中的包含关系，通常发生在多个用例中，有可以提取出来的公共部分（就象提取公因式一样），例如UseCaseA中包括了a和b两个流程，而UseCaseC中包含了c和b两个流程。为了提高复用性，可以把b提取出来，形成另一个用例UseCaseB，此时，UseCaseAincludeUseCaseB（表现为一条指向UseCaseB的虚线，箭头在UseCaseB侧），UseCaseC也includeUseCaseB。因而，当有include关系时，被include的用例通常会被两个以上的其他用例include（否则就不需要重用，也就不需要提取出来了），用例图如下：通过关系整理用例include是指用例中的包含关系，通常发生在多个用例中，37通过关系整理用例——包含关系的误用通过关系整理用例——包含关系的误用38extend

则恰好相反。假设UseCaseA的功能描述为“发送一条通知”，可是，发送通知的方式可能有许多种，例如通过邮件发送、通过短信发送等。在需求分析阶段，可能无法明确到底有多少种方式，在用例分析阶段，UseCaseA需要留出扩展接口，然后把已知的发送方式作为扩展用例给出，例如UseCaseB是“通过短信发送”，而UseCaseC是“通过邮件发送”，此时，UseCaseB和UseCaseCextend了UseCaseA，表现为两根虚线，箭头指向UseCaseA，用例图如下：通过关系整理用例extend则恰好相反。假设UseCaseA的功能描述39如果两个用例之间，一个要调用另一个时，怎么办？”（有可能是混淆了用例和模块的关系），那么，首先要区分概念，用例就是用例，用例不是模块，也不是组件（虽然一个用例能发展成为“一个或多个”模块或组件）；其次，从用例分析的角度来看，如果用例A确实要调用到用例B，那么，可以进一步分析：A是调用了B的所有流程呢，还是其中一部分流程？

（1）如果是调用了一部分，此时可以把B中的那部分流程提取出来，形成用例C，然后A和B都includeC；

（2）如果是调用了所有流程，那么，A直接includeB即可；

（3）如果A没有调用B中的任何流程…那自然不用画两者的关系了通过关系整理用例如果两个用例之间，一个要调用另一个时，怎么办？”（有可能是混40通过关系整理用例用例间不存在“角色与用例”的关系！通过关系整理用例用例间不存在“角色与用例”的关系！41泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在通过关系整理用例泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将42书写用例文档——用例的内容用例编号：用例名执行者前置条件后置条件涉众利益基本路径1……XXXX2……XXXX3……XXXX扩展2a.……XXXX2a1.……XXXX字段列表业务规则非功能需求设计约束待解决问题书写用例文档——用例的内容用例编号：用例名43书写用例文档——涉众利益利益的冲突银行的用户的法律的谁的？书写用例文档——涉众利益利益的冲突银行的用户的法律的谁的？44书写用例文档——涉众利益谁关心这个系统,会涉及到他的什么利益?

对于同一件事情,不同的人看的视角可能各不相同,而不同的视角则是基于不同的利益。探索系统的需求,就是探索不同的涉众之间的利益的最佳平衡点。涉众的位置不同,利益会有所不同,开发人员要从最前排的涉众(老大)的利益为出发点,否则会影响需求必须明确,涉众的利益是不会轻易改变的,稳定的利益关系书写用例文档——涉众利益谁关心这个系统,会涉及到他的什么利45书写用例文档——路径交互步骤的描述只写“可观测的”使用主动语句句子必须以执行者或系统作为主语每一句都要朝目标迈进分支和循环不要涉及界面细节书写用例文档——路径交互步骤的描述只写“可观测的”46书写用例文档——字段列表+→数据序列[]→可选项{}*→多个{|||}→可能取值A=B→把B的结构赋给A可以用自然语言，也可以用表达式书写用例文档——字段列表+→数据序列可以用自然语言，也可47书写用例文档——字段列表注册信息=公司名+联系人+电话+{联系地址}*联系地址=州+城市+街道+邮编保存信息=注册信息+注册时间客房状态={空闲|已预定|占用|维修中}书写用例文档——字段列表注册信息=公司名+联系人+电话+{联48书写用例文档——可用性系统应易于使用第一次使用时30分钟内能学会添加员工（任务时间）5次击键能完成客人入住服务，不需要使用鼠标（操作次数）80%的用户认为系统易学，并且使用效率高（用户调查）系统界面应如XX附件所示的屏幕图像（小心）可用性需求的表达√×？书写用例文档——可用性系统应易于使用可用性需求的表达√×？49书写用例的书面格式书写用例的书面格式50其他简单视图活动图之流程图其他简单视图活动图51其他简单视图活动图之泳道图泳道用于对于多个用户一起完成一个过程，非常有用。其他简单视图活动图泳道用于对于多个用户一起完成一个过程，非常52其他简单视图状态图其他简单视图状态图53

我们动手做做练习

UML帮助我们做需求简单了解UMLUML在设计阶段如何发挥作用主题我们动手做做练习UML帮助我们做需求简单了解UMLUML在54系统详细设计主要目的 详细设计的目的是在具体编写代码前，在代码结构层面上的一次设计，构层面的意思是只要表达出代码的主要属性和方法命名就可以，不必编写方法体代码。 将系统架构实现的功能所涉及到的代码结构都设计出来，这样的做法能够帮助开发人员明确开发思路，且能够较为清楚的了解系统全局结构，作出相应的调整，避免代码开发过程中再去调整代码结构造成的开发资源的浪费。 另一个主要的目的是，将系统的代码结构清晰、直观的描述成文，便于其他开发人员、维护人员对系统的扩展与维护。系统详细设计主要目的 详细设计的目的是在具体编写代码前，在55Uml语言类图基本画法1.类设计简单的讲，就是创建一个类然后定义类中的属性和方法。2.类间关系的设计，包括两个层次包关系设计及类关系设计，两个层次间可以认为是总与分的关系。具体的做法，根据各类间的应用或调用的方式不同明确其之间的关系，类间关系一般分成关联、依赖、累计关系。3.关系确定规则见以下实例（包关系与类关系基本一致包关系有包中类关系决定）Uml语言类图基本画法1.类设计简单的讲，就是创建一个类然后56类中常见的继承表达1继承通过指向超类的一条闭合的，单箭头的实线表示类中常见的继承表达1继承通过指向超类的一条闭合的，单箭头的实57类中常见的继承表达2一个使用树形记号的继承实例类中常见的继承表达2一个使用树形记号的继承实例58类中常见的接口与实现表达Professor类和Student类实现Person接口的类图实例类中常见的接口与实现表达Professor类和Student59类中常见的关联关系表达两个类间的双向关联一个类知道另一个类的属性和方法，前者具有取得后的方法，则形成了单向关联，反之亦然。类中常见的关联关系表达两个类间的双向关联一个类知道另一个类60类中常见的关联关系表达两个类间的单向关联单向关联关系，前者能向后者发送消息取得他的属性类中常见的关联关系表达两个类间的单向关联单向关联关系，前者61类中常见的关联关系表达描述两个或多个类的结构性关系。一个完整的关联定义包含三部分，分别是类之间的关联直线和两个关联端点主要特性：角色，多重性，导航性角色：当一个类处于关联的某一端时，该类就在这个关系中扮演了一个特定的角色；角色是关联中靠近它的一端的类对另外一端的类呈现的职责。类中常见的关联关系表达描述两个或多个类的结构性关系。62类中常见的关联关系表达多重性：关联角色的多重性是说明一个关联的实例中有多少个相互连接的对象。导航性：给定两个类的关联，从一个类的对象能够导航到另一个类的对象，导航可以是双向的。ExactlyoneZeroormoreOneormoreZeroorOneSpecifiedrangeMultiple,disjointranges10..*1..*0..12..42,4..6类中常见的关联关系表达多重性：关联角色的多重性是说明一个关联63类中常见的关联关系表达[具体表现]关联关系是使用实例变量来实现[现实例子]比如客户和订单，每个订单对应特定的客户，每个客户对应一些特定的订单；再例如公司和员工，每个公司对应一些特定的员工，每个员工对应一特定的公司[代码表现]publicclassEmployee{publicvoidstartWorking(){}}publicclassCompany{privateEmployeeemployee;publicEmployeegetEmployee(){returnemployee;}publicvoidsetEmployee(Employeeemployee){this.employee=employee;}//公司运作

publicvoidrun(){employee.startWorking();}}类中常见的关联关系表达[具体表现]关联关系是使用实例变量来实64类中常见的依赖关系表达方式 依赖关系中flight中没有customer属性，因此要用其他方法查找coustomer。如果customer是全局的（包含静态方法），则flight知道他的存在。如果coustomer作为参数传递到flight的方法中，则flight能够引用到它，最后，如果customer事例化为flight方法中的本地变量，则flight就引用到了它的存在，在依赖关系中，必须采用三种方法之一类中常见的依赖关系表达方式 依赖关系中flight中没有cu65类中常见的关联关系表达[具体表现]依赖关系表现在局部变量，方法的参数，以及对静态方法的调用[现实例子]比如说你要去拧螺丝，你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作[代码表现]publicclassPerson{

/**拧螺丝*/

publicvoidscrew(Screwdriverscrewdriver){

screwdriver.screw();

}

}

类中常见的关联关系表达[具体表现]依赖关系表现在局部变量，方66类中常见的聚合关系和组合关系类中常见的聚合关系和组合关系67类中常见的聚合关系和组合关系

聚合：指的是整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构。从而找出一些组成类，该整体类和组成类之间就形成了聚合关系。例如一个航母编队包括海空母舰、驱护舰艇、舰载飞机及核动力攻击潜艇等。需求描述中“包含”、“组成”、“分为…部分”等词常意味着聚合关系。

组合：也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在。部分对象与整体对象之间具有共生死的关系。

聚合和组合的区别在于：聚合关系是“has-a”关系，组合关系是“contains-a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。

类中常见的聚合关系和组合关系

聚合：指的是整体与部分的关系。68类中常见的聚合关系和组合关系 我们用浅显的例子来说明聚合和组合的区别。“国破家亡”，国灭了，家自然也没有了，“国”和“家”显然也是组合关系。而相反的，计算机和它的外设之间就是聚合关系，因为它们之间的关系相对松散，计算机没了，外设还可以独立存在，还可以接在别的计算机上。在聚合关系中，部分可以独立于聚合而存在，部分的所有权也可以由几个聚合来共享，比如打印机就可以在办公室内被广大同事共用

关联和聚合的区别主要在语义上，关联的两个对象之间一般是平等的，例如你是我的朋友，聚合则一般不是平等的，例如一个公司包含了很多员工，其实现上是差不多的。聚合和组合的区别则在语义和实现上都有差别，组合的两个对象之间其生命期有很大的关联，被组合的对象是在组合对象创建的同时或者创建之后创建，在组合对象销毁之前销毁。一般来说被组合对象不能脱离组合对象独立存在，而且也只能属于一个组合对象，例如一个文档的版本，必须依赖于文档的存在，也只能属于一个文档。聚合则不一样，被聚合的对象可以属于多个聚合对象，例如一个员工可能可以属于多个公司。类中常见的聚合关系和组合关系 我们用浅显的例子来说明聚合和组69识别类之间的关联——聚合vs.组合组合/部分容器/内容集合/成员识别类之间的关联——聚合vs.组合组合/部分70识别类之间的关联——绘制关联关系识别类之间的关联——绘制关联关系71Uml语言时序图基本画法1.类设计简单的讲，就是创建一个类然后定义类中的属性和方法。2.类间关系的设计，包括两个层次包关系设计及类关系设计，两个层次间可以认为是总与分的关系。具体的做法，根据各类间的应用或调用的方式不同明确其之间的关系，类间关系一般分成关联、依赖、累计关系。3.关系确定规则见以下实例（包关系与类关系基本一致包关系有包中类关系决定）Uml语言时序图基本画法1.类设计简单的讲，就是创建一个类然72Uml语言时序图基本画法在分析阶段边界类：用例的每个执行者映射一个边界类责任：输入、输出、过滤控制类（可选）：一个用例映射一个控制类责任：控制事件流，负责为实体类分配责任实体类：一个用例有多个实体类参与，一个实体类可以参与多个用例责任：业务行为的主要承载体Uml语言时序图基本画法在分析阶段73顺序图解说顺序图解说74顺序图和类图的映射顺序图和类图的映射75顺序图绘制要点顺序图绘制要点76顺序图绘制要点顺序图绘制要点77顺序图绘制要点顺序图绘制要点78总结

软件质量是设计出来的，而不是测试出来的！设计思想是比开发语言更重要的东西！ 现在还有不少程序员在使用Java语言来进行结构化编程，使用Rose进行面向功能的分析！

Rose不仅仅是OO的设计工具，更重要的是通过用例、类图和顺序图三者来实现OO的思考！ 我们呢……总结 软件质量是设计出来的，而不是测试出来的！设计思想是79演讲完毕，谢谢观看！演讲完毕，谢谢观看！80Uml实用技术UnifiedModelingLanguageUml实用技术UnifiedModelingLangua81

我们动手做做练习

UML帮助我们做需求简单了解UMLUML在设计阶段如何发挥作用主题我们动手做做练习UML帮助我们做需求简单了解UMLUML在82

我们动手做做练习

UML帮助我们做需求简单了解UMLUML在设计阶段如何发挥作用主题我们动手做做练习UML帮助我们做需求简单了解UMLUML在83软件开发过程详解目前的现实是什么？——业务建模在这个现实下，开发系统是为了达到什么目标？——愿景为了达到目标，系统应对外提供什么样的功能和性能？——需求为了提供这些功能，系统内部应该有什么样的核心业务机制？——分析为了满足性能，系统的核心机制如何在选定的架构上实现？——设计找到问题解决问题软件开发过程详解目前的现实是什么？——业务建模找解84UML三个主要作用使用可视化建模来获取并表现商业逻辑和对象使用可视化建模来分析和设计计算机应用程序理由一：UML是客户、系统分析员和程序员之间的“桥梁”用例图活动图状态图时序图对象图部署图……UML三个主要作用使用可视化建模来获取并表现商业逻辑和对象使85UML三个主要作用理由二：UML从客户的角度将复杂的系统整理清楚UML三个主要作用理由二：UML从客户的角度将复杂的系统整理86UML三个主要作用software可移植技术交互性能全面容量稳定性错误处理容错性功能需求成本兼容性理由三：UML能使越来越复杂的软件系统架构更加合理和健壮UML三个主要作用software可移植技术交互性能全面容量87系统模型可由“4+1”视图展现逻辑视图场景视图系统功能分析设计结构系统并发工作情况实现视图实现模块和代码间的关系部署视图系统物理拓扑架构进程视图4+1视图模型，从5个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容系统模型可由“4+1”视图展现逻辑视图场景视图系统功能分析设88系统模型可由“4+1”视图展现逻辑视图LogicView逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务.在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析，这些主要来自问题领域（ProblemDefinition)。在面向对象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类图（ClassDiagram）来描述逻辑视图。系统模型可由“4+1”视图展现逻辑视图LogicV89系统模型可由“4+1”视图展现开发视图Development/ModuleView开发视图主要用来描述软件模块的组织与管理（通过程序库或子系统）。服务于软件编程人员，方便后续的设计与实现。它通过系统输入输出关系的模型图和子系统图来描述。要考虑软件的内部需求：开发的难易程度、重用的可能性，通用性，局限性等等。开发视图的风格通常是层次结构，层次越低，通用性越好（底层库：JavaSDK，图像处理软件包）。上升到组件概念系统模型可由“4+1”视图展现开发视图Developm90系统模型可由“4+1”视图展现进程视图

ProcessView进程试图侧重系统的运行特性，关注非功能性的需求（性能，可用性）。服务于系统集成人员，方便后续性能测试。强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。现在公司里不再考虑功能能不能实现，而在于PK性能，可扩展性等非功能性。系统模型可由“4+1”视图展现进程视图ProcessVi91系统模型可由“4+1”视图展现

物理视图(physicalview)物理试图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。系统模型可由“4+1”视图展现物理视图(physical92系统模型可由“4+1”视图展现场景(Scenarios)

场景用于刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系。文本、图形表示皆可。n小结逻辑视图、开发视图，都主要是用来描述系统的静态结构。进程视图、物理视图，主要是用来描述系统的动态结构。并非每个系统都必须把5个视图都画出来，而是各有侧重。例如MIS系统侧重于逻辑视图、开发视图，而实时控制系统则侧重于进程视图、物理视图系统模型可由“4+1”视图展现场景(Scenarios)93模型可由9个图来展现UseCaseDiagramUseCaseDiagram用例图ScenarioDiagramScenarioDiagram协作图StateDiagramStateDiagram组件图ComponentDiagramComponentDiagram部署图StateDiagramStateDiagram对象图ScenarioDiagramScenarioDiagram状态图UseCaseDiagramUseCaseDiagram时序图StateDiagramStateDiagram类图活动图模型墨绿色表示动态图粉红色表示静态图（可把用例图单列出来）功能静态结构物理架构动态行为用例图，类图，时序图经常用模型可由9个图来展现UseCaseUseCase用例图S94UML9种图用例图描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。类图类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。对象图与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。活动图描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。UML9种图用例图描述角色以及角色与用例之间的连接关系。说95UML9种图状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；序列图（顺序图）序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。协作图和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。构件图（组件图）描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。部署图（配置图）是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。UML9种图状态图描述类的对象所有可能的状态，以及事件发生96UML9种图用例图：业务建模、需求、测试类图：业务建模、分析、设计对象图：业务建模、分析、设计组件图：设计部署图：设计顺序图：业务建模、分析、设计协作图：业务建模、分析、设计状态图：需求、分析、设计活动图：业务建模、设计结构行为敏捷建模原则：需要时再添加可互换可互换UML9种图用例图：业务建模、需求、测试结构行为敏捷建模原则97主要步骤主要步骤98

我们动手做做练习

UML帮助我们做需求简单了解UMLUML在设计阶段如何发挥作用主题我们动手做做练习UML帮助我们做需求简单了解UMLUML在99UML之用例图

需求分析中我们如何整理和抽象我们从用户那得到的业务描述。

用流程图描述业务流程、用用例图表达用户业务工作UML之用例图 需求分析中我们如何整理和抽象我们从用户那得100识别执行者执行者要点：系统外——必须和它交互系统边界——直接与系统交互有意义的交互——属于目标系统的责任任何事物——人、外系统、外部因素、时间识别执行者执行者要点：101识别执行者抽象出执行者的思路：谁使用了系统的主要功能？谁改变了系统的主要数据？谁从系统获取信息？谁需要系统的支持以完成日常工作任务？谁负责维护、管理并保持系统正常运行？系统需要应付（处理）哪些硬件设备？系统需要和哪些外部系统交互？谁（或什么）对系统运行产生的结果感兴趣？有没有自动发生的事件？识别执行者抽象出执行者的思路：102识别执行者责任类似或重叠——抽象出执行者UML之执行者Actor之间也有继承关系。且注意图形表示。识别执行者责任类似或重叠——抽象出执行者UML之执行者Act103识别用例用例的基本定义： 用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。

——IvarJacobson（RUP）通俗地讲：执行者通过系统达到某个有用目标步骤路径目标识别用例用例的基本定义：通俗地讲：执行者通过系统达到某个有用104识别用例设计用例要注意以下要点：价值结果→有意义的目标系统执行→价值结果由系统生成执行者可见→业务语言，用户观点注意：抽象一组用例实例时控制好用例的粒度识别用例设计用例要注意以下要点：105识别用例有意义的目标：√×识别用例有意义的目标：√×106识别用例用户观点而非系统观点：用户观点系统观点识别用例用户观点而非系统观点：用户观点系统观点107识别用例用例命名：执行者视角动词（+宾语）状语定语如：批量修改登录记录编号识别用例用例命名：执行者视角动词（+宾语）状语108识别用例执行者使用这个系统达到什么目标？语法测试：【执行者】使用系统来【用例】识别用例执行者使用这个系统达到什么目标？语法测试：【执行者】109用例命名：慎用弱动词、弱名词110弱动词：进行、使用、复制、加载、重复……弱名词：数据、报表、表格、表单、系统……会掩盖真正的业务识别用例用例命名：慎用弱动词、弱名词30弱动词：进行、使用、复制、加识别用例讨论：几个登录？或注意角色的划分和公共用例的定义要不把用户抽象成三种，或者把登录抽象成三种。识别用例讨论：几个登录？或注意角色的划分和公共用例的定义要不111识别用例用例的粒度：四轮马车任何业务归根到底都可以看作CURD，但光CURD能为Actor提供价值吗？

CRUD是Create（创建）、Read（读取）、Update（更新）和Delete（删除）缩写警惕CURD泛滥！一般要避免全部使用，要抽象，公用的，其它的不要，但默认有。识别用例用例的粒度：四轮马车任何业务归根到底都可以看作CUR112识别用例用例的粒度：在四轮马车之前尽量细致另注：多个用例会操作同一项数据，即对一个数据项操作用例未必是同一个用例识别用例用例的粒度：在四轮马车之前尽量细致另注：多个用例会操113识别用例讨论：登录怎么处理？（确定用例之间的关系）用例有先后或前提关系时不要简单认为是简单的包含或者是扩展关系识别用例讨论：登录怎么处理？（确定用例之间的关系）用例有先后114更进一步的精度

用例图可以作用例文档的总图，进一步的精度：有层次的文档，文档中每一句话都有其价值更进一步的精度 用例图可以作用例文档的总图，进一步的精度：有115通过关系整理用例——用例的关系扩展：分离扩展路径包含：提取公共步骤，便于复用泛化：同一业务目的的不同技术实现大多数为包含关系通过关系整理用例——用例的关系扩展：分离扩展路径包含：提取公116include

是指用例中的包含关系，通常发生在多个用例中，有可以提取出来的公共部分（就象提取公因式一样），例如UseCaseA中包括了a和b两个流程，而UseCaseC中包含了c和b两个流程。为了提高复用性，可以把b提取出来，形成另一个用例UseCaseB，此时，UseCaseAincludeUseCaseB（表现为一条指向UseCaseB的虚线，箭头在UseCaseB侧），UseCaseC也includeUseCaseB。因而，当有include关系时，被include的用例通常会被两个以上的其他用例include（否则就不需要重用，也就不需要提取出来了），用例图如下：通过关系整理用例include是指用例中的包含关系，通常发生在多个用例中，117通过关系整理用例——包含关系的误用通过关系整理用例——包含关系的误用118extend

则恰好相反。假设UseCaseA的功能描述为“发送一条通知”，可是，发送通知的方式可能有许多种，例如通过邮件发送、通过短信发送等。在需求分析阶段，可能无法明确到底有多少种方式，在用例分析阶段，UseCaseA需要留出扩展接口，然后把已知的发送方式作为扩展用例给出，例如UseCaseB是“通过短信发送”，而UseCaseC是“通过邮件发送”，此时，UseCaseB和UseCaseCextend了UseCaseA，表现为两根虚线，箭头指向UseCaseA，用例图如下：通过关系整理用例extend则恰好相反。假设UseCaseA的功能描述119如果两个用例之间，一个要调用另一个时，怎么办？”（有可能是混淆了用例和模块的关系），那么，首先要区分概念，用例就是用例，用例不是模块，也不是组件（虽然一个用例能发展成为“一个或多个”模块或组件）；其次，从用例分析的角度来看，如果用例A确实要调用到用例B，那么，可以进一步分析：A是调用了B的所有流程呢，还是其中一部分流程？

（1）如果是调用了一部分，此时可以把B中的那部分流程提取出来，形成用例C，然后A和B都includeC；

（2）如果是调用了所有流程，那么，A直接includeB即可；

（3）如果A没有调用B中的任何流程…那自然不用画两者的关系了通过关系整理用例如果两个用例之间，一个要调用另一个时，怎么办？”（有可能是混120通过关系整理用例用例间不存在“角色与用例”的关系！通过关系整理用例用例间不存在“角色与用例”的关系！121泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在通过关系整理用例泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将122书写用例文档——用例的内容用例编号：用例名执行者前置条件后置条件涉众利益基本路径1……XXXX2……XXXX3……XXXX扩展2a.……XXXX2a1.……XXXX字段列表业务规则非功能需求设计约束待解决问题书写用例文档——用例的内容用例编号：用例名123书写用例文档——涉众利益利益的冲突银行的用户的法律的谁的？书写用例文档——涉众利益利益的冲突银行的用户的法律的谁的？124书写用例文档——涉众利益谁关心这个系统,会涉及到他的什么利益?

对于同一件事情,不同的人看的视角可能各不相同,而不同的视角则是基于不同的利益。探索系统的需求,就是探索不同的涉众之间的利益的最佳平衡点。涉众的位置不同,利益会有所不同,开发人员要从最前排的涉众(老大)的利益为出发点,否则会影响需求必须明确,涉众的利益是不会轻易改变的,稳定的利益关系书写用例文档——涉众利益谁关心这个系统,会涉及到他的什么利125书写用例文档——路径交互步骤的描述只写“可观测的”使用主动语句句子必须以执行者或系统作为主语每一句都要朝目标迈进分支和循环不要涉及界面细节书写用例文档——路径交互步骤的描述只写“可观测的”126书写用例文档——字段列表+→数据序列[]→可选项{}*→多个{|||}→可能取值A=B→把B的结构赋给A可以用自然语言，也可以用表达式书写用例文档——字段列表+→数据序列可以用自然语言，也可127书写用例文档——字段列表注册信息=公司名+联系人+电话+{联系地址}*联系地址=州+城市+街道+邮编保存信息=注册信息+注册时间客房状态={空闲|已预定|占用|维修中}书写用例文档——字段列表注册信息=公司名+联系人+电话+{联128书写用例文档——可用性系统应易于使用第一次使用时30分钟内能学会添加员工（任务时间）5次击键能完成客人入住服务，不需要使用鼠标（操作次数）80%的用户认为系统易学，并且使用效率高（用户调查）系统界面应如XX附件所示的屏幕图像（小心）可用性需求的表达√×？书写用例文档——可用性系统应易于使用可用性需求的表达√×？129书写用例的书面格式书写用例的书面格式130其他简单视图活动图之流程图其他简单视图活动图131其他简单视图活动图之泳道图泳道用于对于多个用户一起完成一个过程，非常有用。其他简单视图活动图泳道用于对于多个用户一起完成一个过程，非常132其他简单视图状态图其他简单视图状态图133

我们动手做做练习

UML帮助我们做需求简单了解UMLUML在设计阶段如何发挥作用主题我们动手做做练习UML帮助我们做需求简单了解UMLUML在134系统详细设计主要目的 详细设计的目的是在具体编写代码前，在代码结构层面上的一次设计，构层面的意思是只要表达出代码的主要属性和方法命名就可以，不必编写方法体代码。 将系统架构实现的功能所涉及到的代码结构都设计出来，这样的做法能够帮助开发人员明确开发思路，且能够较为清楚的了解系统全局结构，作出相应的调整，避免代码开发过程中再去调整代码结构造成的开发资源的浪费。 另一个主要的目的是，将系统的代码结构清晰、直观的描述成文，便于其他开发人员、维护人员对系统的扩展与维护。系统详细设计主要目的 详细设计的目的是在具体编写代码前，在135Uml语言类图基本画法1.类设计简单的讲，就是创建一个类然后定义类中的属性和方法。2.类间关系的设计，包括两个层次包关系设计及类关系设计，两个层次间可以认为是总与分的关系。具体的做法，根据各类间的应用或调用的方式不同明确其之间的关系，类间关系一般分成关联、依赖、累计关系。3.关系确定规则见以下实例（包关系与类关系基本一致包关系有包中类关系决定）Uml语言类图基本画法1.类设计简单的讲，就是创建一个类然后136类中常见的继承表达1继承通过指向超类的一条闭合的，单箭头的实线表示类中常见的继承表达1继承通过指向超类的一条闭合的，单箭头的实137类中常见的继承表达2一个使用树形记号的继承实例类中常见的继承表达2一个使用树形记号的继承实例138类中常见的接口与实现表达Professor类和Student类实现Person接口的类图实例类中常见的接口与实现表达Professor类和Student139类中常见的关联关系表达两个类间的双向关联一个类知道另一个类的属性和方法，前者具有取得后的方法，则形成了单向关联，反之亦然。类中常见的关联关系表达两个类间的双向关联一个类知道另一个类140类中常见的关联关系表达两个类间的单向关联单向关联关系，前者能向后者发送消息取得他的属性类中常见的关联关系表达两个类间的单向关联单向关联关系，前者141类中常见的关联关系表达描述两个或多个类的结构性关系。一个完整的关联定义包含三部分，分别是类之间的关联直线和两个关联端点主要特性：角色，多重性，导航性角色：当一个类处于关联的某一端时，该类就在这个关系中扮演了一个特定的角色；角色是关联中靠近它的一端的类对另外一端的类呈现的职责。类中常见的关联关系表达描述两个或多个类的结构性关系。142类中常见的关联关系表达多重性：关联角色的多重性是说明一个关联的实例中有多少个相互连接的对象。导航性：给定两个类的关联，从一个类的对象能够导航到另一个类的对象，导航可以是双向的。ExactlyoneZeroormoreOneormoreZeroorOneSpecifiedrangeMultiple,disjointranges10..*1..*0..12..42,4..6类中常见的关联关系表达多重性：关联角色的多重性是说明一个关联143类中常见的关联关系表达[具体表现]关联关系是使用实例变量来实现[现实例子]比如客户和订单，每个订单对应特定的客户，每个客户对应一些特定的订单；再例如公司和员工，每个公司对应一些特定的员工，每个员工对应一特定的公司[代码表现]publicclassEmployee{publicvoidstartWorking(){}}publicclassCompany{privateEmployeeemployee;publicEmployeegetEmployee(){returnemployee;}publicvoidsetEmployee