UML九大图.docxVIP

UML九大图介绍目录第一章用例图3一、用例图概念3二、关系及其应用5三、规范及应用8第二章类图12一、类图概述12二、类图关系12三、类图的表示13四、建模类图22五、UML扩展类图24第三章对象图40一、对象图简介40第四章时序图43一、时序图简介43二、时序图元素43三、时序图实例分析46四、总结47第五章协作图48一、活动图概述48二、事务及解释48第六章状态图53一、状态图概述53二、为什么要建模状态图53三、状态机54四、状态图标识55五、状态图创建60六、状态图案例62第七章活动图64一、活动图概述64二、活动图的组成元素65三、活动的分解68四、活动图建模技术69第八章构件图73一、构件图概要73二、构件图解释73三、构件图的示例73第九章部署图75一、部署图概要75二、部署图解释75三、部署图的示例76UML图小结79第十章 E-R图85第一章用例图一、用例图概念用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛化(generalization)几种关系。用例图由三部分组成：参与者、一组（个）用例、关系 参与者：是直接与系统相互作用的系统、子系统或类的外部实体的抽象。它是用户所扮演的角色，是系统的用户。每个参与者定义了一个角色集合。通常，一个参与者可以代表一个人、一个计算机子系统、硬件设备或者时间等角色。典型的参与者如销售部经理、销售员和结账系统。 图形表示：用小人图符表示 参与者的识别：谁将使用系统的主要功能？谁将需要系统的支持来完成他们的日常任务？ 谁必须维护、管理和确保系统正常工作？ 谁将给系统提供信息、使用信息和删除信息？ 系统需要处理哪些硬件设备？系统使用了外部资源吗？系统需要与其他什么系统交互吗？谁/什么对系统产生的结果感兴趣？一个人同时使用几种不同的规则吗？几个人使用相同的规则吗？系统使用遗留下来的应用吗？用例对一组动作序列的描述，系统通过执行这一组动作序列为参与者产生一个可观察的结果用例特征说明了系统具有的一种行为模式 说明了一个参与者与系统执行的一个相关的事务序列提供了一种获取系统需求的方法 提供了一种与最终的用户和领域专家进行沟通的方法 提供了一种测试系统的方法图形表示用椭圆形表示，用例的名字显示在图标的下面或里面用例识别参与者要向系统请求什么功能？ 每个参与者的特定任务是什么？ 参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗？ 是否任何一个参与者都要向系统通知有关突发性的、外部的改变？或者必须通知参与者关于系统中的发生的事件？ 这些事件代表了哪些功能？ 系统需要哪些输入/输出？ 这些输入输出来自哪里或者到哪里去？ 哪些用例支持或维护系统？ 是否所有功能需求都被用例使用了？ 系统当前实现的主要问题是什么？事件流事件流是用例完成需求行为的事件描述。事件流的目的是建立用例中逻辑流程的文档，详细描述系统用户的工作和系统本身的工作，既包括正常状态下系统完成需求行为的事件，也包括在其他状态下不能完成需求行为的事件。事件流通常包括：简要说明、前置条件、事件流、后置条件用例模型一个用例模型由一个或者多个用例图和所有的支持文件（诸如用例规范和参与者定义等）所构成。用例规范是大多数用例模型的产物，而用例图充当将需求模型综合在一起的粘胶剂。用例模型应当从项目投资者的角度进行开发，而不是从开发者的（通常是技术）观点去开发。二、关系及其应用关系反应了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用。在一个用例图中，可能会出现关联关系、依赖关系、泛化关系以及这三种关系的扩展形式：扩展关系、包含关系和精化关系。关联关系关联关系表示一种通信路径，它存在于参与者和用例之间，提供用例和参与者之间的通信途径。建立通信之后，信息可以双向流动。关系方向显示的不是信息的流动方向，而是谁启动信息。表示：工具箱中：一个直角直线模型图中：一条直线或者一条带箭头的直线关联命名：一个动词或者一个动词短语，用于指明关系的类型或者目的。关联关系表示通信途径在用例图中，通常存在两种类型的关联