用例图

在UML的 类图 中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization）, 关联（Association), 聚合（Aggregation）, 组合(Composition), 依赖(Dependency) 1. 泛化（ Generalization ） 【泛化关系】：是一种继承关系 , 表示一般与特殊的关系 , 它指定了子类如何特化父类的所有特征和行为 . 例如：老虎是动物的一种, 即有老虎的特性也有动物的共性. 【箭头指向】：带三角箭头的实线，箭头指向父类 2. 实现（ Realization ） 【实现关系】：是一种类与接口的关系 , 表示类是接口所有特征和行为的实现 . 【箭头指向】：带三角箭头的虚线，箭头指向接口 3. 关联（ Association) 【关联关系】：是一种拥有的关系 , 它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子 关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。 【代码体现】：成员变量 【箭头及指向】：带普通箭头（或实心三角形箭头）的实心线，指向被拥有者 上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。 上图为自身关联： 4. 聚合（

1、什么是用例图 　　用例图源于Jacobson的OOSE方法，用例图是需求分析的产物，描述了系统的参与者与系统进行交互的功能，是参与者所能观察和使用到的系统功能的模型图。它的主要目的就是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的“角色”关系以及系统各个功能之间的关系。它通过用例（Use Case）来捕获系统的需求，再结合参与者（Actor）进行系统功能需求的分析和设计。 2、用例图的组成 　　用例图有四部分组成：用例（Use Case）、参与者（Actor）、系统边界、关联 2.1 参与者 　　 在一个系统开发前，我们必定首先要确定系统的用户，系统的用户就是系统的参与者。除此以外，我们还会想打，我们开发的系统与其他的系统有什么关联？因此，系统的参与者可分为两类，一类是人，包括系统的使用者、维护者等，另外一类是其他系统。 2.2 用例 　　用例（Use Case）是参与者（Actor）可以感受到的系统服务或功能单元。 　　任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例，所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。 　　用例是有粒度的，用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 2.3 系统边界 　　

此博客转载自http://www.cnblogs.com/Yogurshine/archive/2013/01/14/2859248.html UML-Unified Model Language 统一建模语言 ，又称标准建模语言。是用来对 软件 密集系统进行可视化 建模 的一种语言。 在UML系统开发中有三个主要的模型： 　　功能模型: 从用户的角度展示系统的功能，包括用例图。 　　对象模型: 采用对象，属性，操作，关联等概念展示系统的结构和基础，包括 类图 、对象图、包图。 　　动态模型: 展现系统的内部行为。 包括序列图，活动图，状态图。 UML的重要内容可以由以下五种类图定义 用例图 ：从用户角度描述系统功能，并指各功能的操作者。 静态图 ：包括类图，包图，对象图。 类图：描述系统中类的静态结构 包图：是包和类组成的，表示包与包之间的关系，包图描述系统的分层结构 对象图：是类图的实例 行为图 ：描述系统动态模型和对象组成的交换关系。包括状态图和活动图 活动图：描述了业务实现用例的工作流程 状态图：是描述状态到状态控制流，常用于动态特性建模 交互图： 描述对象之间的交互关系 顺序图：对象之间的动态合作关系，强调对象发送消息的顺序，同时显示对象之间的交互 合作图：描述对象之间的协助关系 实现图： 配置图：定义系统中软硬件的物理体系结构 UML包括用例图、类图、构件图、部署图

团队成员：施蓓蓓 许晴 冯越 姜金金 石莉静 陈晖 朱瑾 贡献比例：1:1:1:1:1:1:1 [ 必做 1 ] 列出成绩录入系统功能需求。 [ 必做 2 ] 画出该学生成绩录入系统的用例图。 [ 必做 3 ] 将系统开发工作分解为若干任务，画出WBS [ 必做 4 ] 将任务分配到团队成员。列出任务分配表。 [ 选做 5 ] 陈述团队协作的出现的问题、矛盾、以及你是如何解决的，等。 功能需求分析： 用例图描述： wps描述： 任务分配： 总结：这次的团队合作并不是很顺利，但我们还是完成了它。过程中摩擦不断，因为不是一个宿舍的，所以当面交流的机会并不多，所以完成的有些困难。在当面探讨了一番之后，我们建了一个讨论组以供我们讨论，在分配任务的时候产生了分歧，但在沟通协调后还是完满的解决了这个问题。经过这次合作，我们学习到了更多知识，俗话说三个臭皮匠顶个诸葛亮，在大家智慧的结合下，我们还是愉快的完成了作业。 来源： https://www.cnblogs.com/shibeibei/p/5436729.html

UML用例图介绍 用例图主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示这些元素之间的各种关系，如泛化、关联和依赖。 【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。 一般在用户需求部分予以描述，本文主要记录本人在画UML图时经常忘记的知识点。 关联 关联关系用于用户和用例之间，为一条直线。直接从用户小人连到用例椭圆上即可。表示用户可以使用的用例。 泛化 就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。 上面说的是啥意思呢，主要是说泛化可用于继承，但是一般不怎么用。要使用泛化关系可以直接将子用例的特殊项给作为父用例备选，然后在连线上下功夫就行了。 泛化线的箭头为空心三角箭头，意为“继承于”。 包含（include） 包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时

用例图介绍 用例图(Use-Case Diagram),是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图可以直观呈现系统与功能模块之间的互动关系，便于软件设计初期的建模。借助于用例图，开发相关人员，客户与专业人士能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。 用例图关键要素 参与者 参与者是指独立于系统，并与系统存在交互的对象，可以是人，物体，其他系统等等。 系统边界 设计系统，需要明确系统边界，知道哪些是系统内部的东西，哪些是系统外部的东西，方便后期的统一设计规划。 用例 系统里面的功能，模块或者属性，行为等。 关系 参与者与用例的关系，参与者与参与者的关系 关系的介绍 不同的关系用不同的线条来表示，以下是主要关系。 包含(include) 比如管理学生信息，包含增添学生信息，修改学生信息，删除学生信息，一般是对行为与功能的进一步细化，细化的程度需要掌握好，不然设计的用例图效果不好。 扩展(extend) 例如，查询操作可以对结果进行导出、打印。对于查询而言，能不能导出、打印，查询都是一样的，它们不是必须做的操作。扩展一般是行为与功能的一些可选，非必须的细化操作。 泛化(generalization) 比如车和公交车，是一种继承泛化的关系。 关联(Association)

简介：回顾20世纪晚期--准确地说是1997年，OMG组织(Object management Group对象管理组织)发布了统一建模语言(Unified Modeling Language，UML)。UML的目标之一就是为开发团队提供标准通用的设计语言开发和构建计算机应用。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提供了一套IT专业人员期待多年的统一的标准建模符号，这些人员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设计图一样。 到了21世纪--准确地说是2003年，UML已经获得了业界的认同。在我所见过的专业人员的简历中，75%都声称具备UML的知识。然而，在同绝大多数求职人员面谈之后，可以明显地看出他们并不真正了解UML。通常地说，他们将UML用作一个术语，或对UML一知半解。大家对UML缺乏理解的这种情况，促进我撰写这篇关于UML 1.4的快速入门文章。当阅读完本文是，您还不具备足够的知识可以在简历上声称自己掌握了UML，但是您已具有了进一步钻研该语言的良好起点。 一些背景知识 正如前面提到过的，UML的本意是要成为一种标准的统一语言，使得IT专业人员能够进行计算机应用程序的建模。UML的主要创始人是Jim Rumbaugh、Ivar Jacobson和Grady Booch，他们最初都有自己的建模方法(OMT

　　1997年，OMG组织（Object Management Group对象管理组织）发布了 统一建模语言 （Unified Modeling Language，UML）。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划 —— 就像建筑工人多年来所使用的建筑设计图一样。 到了21世纪--准确地说是2003年，UML已经获得了业界的认同。在我所见过的专业人员的简历中，75%都声称具备UML的知识。然而，在同绝大多数求职人员面谈之后，可以明显地看出他们并不真正了解UML。通常地，他们将UML用作一个术语，或对UML一知半解。大家对UML缺乏理解的这种状况，促进我撰写这篇关于UML 1.4的快速入门文章。当阅读完本文时，您还不具备足够的知识可以在简历上声称自己掌握了UML，但是您已具有了进一步钻研该语言的良好起点。 一些背景知识 　　正如前面曾提到过的，UML的本意是要成为一种标准的统一语言，使得IT专业人员能够进行计算机应用程序的建模。UML的主要创始人是Jim Rumbaugh、Ivar Jacobson和Grady Booch，他们最初都有自己的建模方法（OMT、OOSE和Booch），彼此之间存在着竞争。最终

目录 背景知识 用例图 类图 序列图 状态图 活动图 组件图 部署图 结束语 　　英文原文： UML basics: An introduction to the Unified Modeling Language 　　到了21世纪——准确地说是2003年，UML已经获得了业界的认同。在我所见过的专业人员的简历中，75%都声称具备UML的知识。然而，在同绝大多数求职人员面谈之后，可以明显地看出他们并不真正了解UML。通常地，他们将UML用作一个术语，或对UML一知半解。大家对UML缺乏理解的这种状况，促进我撰写这篇关于UML 1.4的快速入门文章。当阅读完本文时，您还不具备足够的知识可以在简历上声称自己掌握了UML，但是您已具有了进一步钻研该语言的良好起点。 　　 背景知识 　　正如前面曾提到过的，UML的本意是要成为一种标准的统一语言，使得IT专业人员能够进行计算机应用程序的建模。UML的主要创始人是Jim Rumbaugh、Ivar Jacobson和Grady Booch，他们最初都有自己的建模方法（OMT、OOSE和Booch），彼此之间存在着竞争。最终，他们联合起来创造了一种开放的标准。（听起来是不是很熟悉？这个现象类似J2EE、SOAP和Linux的诞生。）UML成为"标准"建模语言的原因之一在于，它与程序设计语言无关。（IBM

　　 软件工程（软件工程中的各种图一般用于以下三个阶段）： 需求分析阶段： 　　用例图：用例图是指由参与者（Actor）、 用例 （Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。是系统的蓝图。 　　 　　流程图：以特定的图形符号加上说明，表示算法的图，称为流程图或 框图 。 　　 概要设计阶段： 　　类图:类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。 　　 详细设计阶段： 　　时序图：（Sequence Diagram），又名序列图、循序图，是一种UML交互图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。 　　 　　状态图:状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。 　　 　　活动图：活动图（activity diagram，动态图）是阐明了业务 用例 实现的工作流程。 　　 　　顺序图：顺序图是将交互关系表示为一个二维图。纵向是 时间轴 ，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。 　　 来源： https://www.cnblogs.com