要点：对系统的组织
UML是一种可视化的建模语言，对其各建模元素可进行详细说明，并能生成所建模型的文档。使用UML时，要从不同的角度观察系统，为此定义了一个概念“视图”。视图是对系统的模型在某方面的投影，注重于系统的某个方面。每个视图是图的协作，UML定义了9种图。下表是UML中的5种视图，各视图在静态和动态方面表示了系统的模型。
用况视图由用况图组成，描述可被最终用户、分析人员和测试者看到的系统行为；设计视图包含类图、对象图、交互图、状态图和活动图，主要反映系统的功能需求；进程视图包含类图、对象图、交互图、状态图和活动图，主要描述形成系统并发与同步机制的线程和进程；实现视图包含构件图、交互图、状态图和活动图，反映用于装配与发布物理系统的构件和文件，主要针对系统发布的配置管理，可以用各种方法装配它们。部署视图包含部署图、交互图、状态图和活动图，主要描述对组成物理系统的部件的分布、交付和安装。根据实际需要，可以组合使用这些视图。
由视图可以定义模型，模型在语义上是闭合的，它从特定的角度（系统的规约或者设计）在一定抽象层次上描述目标系统。可以把视图组织成模型，开发人员可从各视角观察使用模型。
用以描述系统的模型可以是结构性的，强调系统的组织；也可以是行为性的，强调系统的动态方面。例如，RUP有9种模型，分别是业务模型、领域模型、用况模型（也称需求模型）、分析模型、设计模型、过程模型、部署模型、实现模型和测试模型，用于从不同的角度表示系统。
系统是一组反映不同侧面的子系统的集合，为了完成特定的目的要对这些子系统进行组织（在逻辑、功能和物理位置上是高内聚、低耦合的）。
子系统是一组元素的聚集，其中的元素还可以是子系统。它由一组模型从不同的角度进行描述。子系统本身几乎应是独立的，有自己应用的环境，相互间不重叠，它们之间用接口联系。
UML的概念模型
为了理解UML，需要掌握UML的概念模型，这要求学习三个要素：UML的基本构造块、支配这些构造块如何放在一起的规则和一些运用于整个UML的机制，下面逐一予以介绍。
1. 基本构造块
UML中有三种基本构造块，分别是事物、关系和图。
事物分结构事物（包括类、接口、协作、用况、主动类、构件和节点）、行为事物（包括交互和状态机）、分组事物（包）和注释事物（注解）。
UML中有四种关系，分别是依赖、关联、泛化和实现关系。
对于上述两种构造块，通过研读相应的书籍，绝大多数不难掌握，这里就不再赘述。下面对UML中的图的要点进行阐述。
类图 类图展示了一组类、接口和协作及它们间的关系，在建模中所建立的最常见的图就是类图。用类图说明系统的静态设计视图，包含主动类的类图——专注于系统的静态进程视图。系统可有多个类图，单个类图仅表达了系统的一个方面。要在高层给出类的主要职责，在低层给出类的属性和 *** 作。
对象图 对象图展示了一组对象及它们间的关系。用对象图说明类图中所反应的事物实例的数据结构和静态快照。对象图表达了系统的静态设计视图或静态过程视图，除了现实和原型的方面的因素外，它与类图作用是相同的。
用况图 用况图展现了一组用况、参与者以及它们间的关系。可以用用况图描述系统的静态使用情况。在对系统行为组织和建模方面，用况图的是相当重要的。
交互图 交互图展现了按一定的目的进行的一种交互，它由在一个上下文中的一组对象及它们间交互的信息组成。交互图也可用于描述一个用况的行为。顺序图和协作图都是交互图，顺序图和协作图可以相互转换。
顺序图 展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。用顺序图说明系统的动态视图。
协作图 展现了一组对象，这组对象间的连接以及这组对象收发的消息。它强调收发消息的对象的结构组织，按组织结构对控制流建模。
状态图 展示了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态间的转移。一个状态图描述了一个状态机，用状态图说明系统的动态视图。它对于接口、类或协作的行为建模尤为重要，可用它描述用况实例的生命周期。
活动图 活动图是一种特殊的状态图，描述需要做的活动、执行这些活动的顺序（多为并行的）以及工作流（完成工作所需要的步骤）。它对于系统的功能建模特别重要，强调对象间的控制流程。
高层活动图用于表示需要完成的一些任务，即用于分析用况，理解涉及多个用况的工作流、多线程及并行，显示相互联系的行为整体，还可用于对企业过程建模，对系统的功能建模。低层活动图用于表示类的方法。但活动图不适用于描述动作与对象间的关系，显示对象间的合作以及显示对象在生命周期内的运转情况。
构件图 构件图展现了一组构件之间的组织和依赖，用于对原代码、可执行的发布、物理数据库和可调整的系统建模。
部署图 部署图展现了对运行时处理节点以及其中构件的配署。它描述系统硬件的物理拓扑结构(包括网络布局和构件在网络上的位置)，以及在此结构上执行的软件.
UML用于描述事物的语义规则分别是：为事物、关系和图命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。另外，UML还允许在一定的阶段隐藏模型的某些元素、遗漏某些元素以及不保证模型的完整性，但模型逐步地要达到完整和一致。
3. 机制
有四种在整个语言中一致应用的机制，使得该语言变得较为简单。这四种机制是详细说明、修饰、通用划分和扩展机制。
UML不只是一种图形语言。实际上，在它的图形表示法的每部分背后都有一个详细说明，提供了对构造块的语法和语义的文字叙述。
UML表示法中的每一个元素都有一个基本符号，这些图形符号对元素的最重要的方面提供了可视化表示，对元素的描述还包含其他细节。例如，一个类是否是抽象类，或它的属性和 *** 作是否可见。要把这样的修饰细节加到基本符号上。
在对面向对象的系统建模中，至少有两种通用的划分世界的方法：对类和对象的划分；对接口和实现的划分。UML中的构造块几乎都存在着这样的两分法。UML是开放的，可用一种受限的方法扩展它。UML的扩展机制包括构造型、标记值和约束。
UML的应用
UML是一种建模语言，不是一种方法，它独立于过程。利于它建模时，可遵循任何类型的建模过程。该建模语言的作者们给出了一种推荐性的建模过程指导，即RUP。本部分阐述RUP如何支持UML的应用。
问题一：在系统中为什么要画用例图,作用是什么 用例图是由use case（用例），actor（角色）和系统边界组成的。用来表示系统做了哪些事情的骸是帮助你分析系统有哪些功能，以及让你明确系统内部和系统外部（也就是角色）的交互的。
问题二：用例图的作用 用例图主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。角色之间的关系角色之间的关系。由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。用例之间的关系：包含关系：基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。泛化关系：代表一般与特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。用例的泛化、包含、扩展关系的比较。一般来说可以使用“is a”和“has a”来判断使用那种关系。泛化和扩展关系表示用例之间是“is a”关系，包含关系表示用例之间是“has a”关系。扩展与泛化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。在扩展关系中基本用例是独立存在。在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当描述正常行为的变形希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。通常先获得基本用例，针对这个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。用例之间的关系举例包含：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。扩展：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导出、打印和查询相对独立，而且为查询添加了新行为。泛化：子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。将每个系统中的用户分出工作状态的属......>>
问题三：什么是用例图？用例图有什么作用 用例图：从用户角度描述系统功能，并指各功能的 *** 作者。
UML2系列框图--用例图详解
trufun/...8
问题四：什么是用例图？用例图有什么作用 UML用例框图的详细介绍如下，可以参考他们的在线帮助，中文UML *** 作手册。
问题五：什么是用例图？用例图有什么作用 UML用例框图的详细介绍如下，可以参考他们的在线帮助，中文UML *** 作手册。
问题六：用例，用例图，用例视图是什么？ 你好！
用例(Use Case)，就是外部可见的系统功能，对系统提供的功能进行描述。
用例图(Use Case Diagrams)，在用例视图中，用例图显示了各个参与者、用例以及它们之间的交互。在用例图下可以连接与用攻图相关的文件和URL地址。
用例视图，我个人理解就是用例图。只不过可视化强点，在UML中！
问题七：功能图和用例图有什么区别 用例图和类图都是静态图,顺序图是动态图.用例图是从外部描述的系统功能；类图是以类为中心,描述的是系统的内部结构；顺序图则是描述用例之间的行为顺序.
问题八：总结用例图的重要作用，讨论并指出哪些场合下可以使用用例图 用例图的作用是比较重要的，因为它是一个大家都能看懂的UML视图。
在需求时我们要创建需求分析模型，首先就要用到用例图，由需求分析得出的用例图，在进行细化到设计层面的用例图，到测试层面的用例图。
用例图能够准确的表达系统的功能，同时引入其他视图的辅助说明，比如活动图，可以对一个用例的流程进行详细的描述。
经常我们用到的用例图不仅仅是表面看到一个简单的用例，角色等关系的表示，还有其内部动态的过程。
问题九：功能图和用例图有什么区别 用例图是uml规范的框图之一，功能图则没有规范，可以自由表达，
用例图可以表达系统的功能和需求内容。
问题十：我们应当怎样做需求分析：功能角色分析与用例图 在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。
但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。一些问题想到了就做了，没有想到则忽略掉了。实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。
需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。
对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。
一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。但是，通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。根据这样一个思路，我以往常常将外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。随后我改变了思路，将外部系统和自动触发器绘制成另一种表达形式――类元符号表示法，并在构造型上标注为Actor。
上图是一个考核系统中一个子模块的用例图。图中的用例就是这个系统提供给用户的各项功能。注意，这里仅仅是在罗列功能而不表示它们之间诸如流程调用等相互关系，这是一些初学者常常犯的毛病。参与者与用例通过实线关联起来，代表的是一种使用关系。箭头代表的是一种导航，即动作施与的方向。在这个用例图中，普通用户执行查询 *** 作，查询系统提供的“预警监控单项查询”、“预警监控汇总查询”等查询报表；每日......>>
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）