免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2014年上半年 信息系统项目管理师 上午试卷 综合知识
  第11题      
  知识点:   可视化建模与UML   观察   用例图
  关键词:   用例图   用例        章/节:   信息系统及其技术和开发方法       

 
用例图主要用来描述用户与系统功能单元之间的关系,它展示了一个外部用户能够观察到的系统功能模型图。在一个订票系统中,下图表现的是(11)关系。
 
 
  A.  泛化
 
  B.  继承
 
  C.  扩展
 
  D.  依赖
 
 
 

 
  第25题    2018年上半年  
   52%
在面向对象的基本概念中,()体现对象间的交互,通过它向目标对象发送操作请求。
  第25题    2017年上半年  
   62%
为了将面向对象的分析模型转化为设计模型,设计人员必须完成以下任务:设计用例实现方案、设计技术支撑设施、()、精化设计模型..
  第27题    2018年下半年  
   19%
UML的()描述了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转移。
   知识点讲解    
   · 可视化建模与UML    · 观察    · 用例图
 
       可视化建模与UML
        1.统一建模语言
        概念
        统一建模语言(Unified Modeling Language,UML)是一种通用的可视化建模语言,它是面向对象分析和设计的一种标准化表示,用于对软件进行描述、可视化处理、构造和建立软件系统的文档。
        UML描述了系统的静态结构和动态行为,它将系统描述为一些独立的相互作用的对象,构成为外界提供一定功能的模型结构,静态结构定义了系统中重要对象的属性和服务,以及这些对象之间的相互关系,动态行为定义了对象的时间特性和对象为完成目标而相互进行通信的机制。
        特征
        UML具有如下语言特征:
        .不是一种可视化的程序设计语言,而是一种可视化的建模语言。
        .是一种建模语言规范说明,是面向对象分析与设计的一种标准表示。
        .不是过程,也不是方法,但允许任何一种过程和方法使用它。
        .简单且可扩展,具有扩展和专有化机制,便于扩展,无须对核心概念进行修改。
        .为面向对象的设计与开发中涌现出的高级概念(如协作、框架、模式和组件)提供支持,强调在软件开发中对架构、框架、模式和组件的重用。
        .与最好的软件工程实践经验集成。
        发展
        面向对象技术和UML的发展经历了长期的过程。1996年底,UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。1997年,OMG采纳UML1.1作为基于面向对象技术的标准建模语言,至今,UML已发展至2.X版本。UML代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景。
        2.UML设计目标
        UML设计目标包括:
        .使UML成为一个通用的建模语言,可供所有建模者使用。
        .应能够很好地支持设计工作。
        .应该能够准确表达当前软件开发中的热点问题,比如软件规模、分布、并发、方法和团队开发等。
        .在尽可能简单的同时能够对应用系统的各个方面建模。
        3.UML中的关系
        UML中有4种关系:依赖、关联、泛化和实现。
        依赖(Dependency)
        表示两个事物间的语义关系,其中一个事物(独立事物)发生变化会影响另一个事物(依赖事物)的语义。用可能有方向的虚线表示,如下图所示。
        
        依赖关系
        关联(Association)
        是一种结构关系,它描述了一组链,链是对象之间的连接。聚集(Aggregation)是一种特殊类型的关联,它描述了整体和部分间的结构关系。关联用下图表示,可以标注重复度和角色。
        
        关联关系
        聚集的图形化表示如下图所示。
        
        聚集的图形化表示
        泛化(Generalization)
        是一种特殊/一般关系,特殊元素(子元素)的对象可替代一般元素(父元素)的对象。用这种方法,子元素共享了父元素的结构和行为。图形上表示为一条带有空心箭头的实线,指向父元素,如下图所示。
        
        泛化关系
        实现(Realization)
        是类元之间的语义关系,其中一个类元指定了由另一个类元保证执行的契约。有两种情况需要用到实现关系:一种是在接口和实现它们的类或构件之间;另一种是在用例和实现它们的协作之间。图形上用一条带有空心箭头的虚线表示,如下图所示。
        
        实现关系
        4.UML中的图
        UML提供了9种主要的图来对待建系统进行建模。
        类图(Class Diagram)
        显示了一组对象、接口、协作和它们间的关系。在面向对象系统的建模中所建立的最常见的图就是类图,类图给出系统的静态设计视图,如下图所示。
        
        类图
        对象图(Object Diagram)
        显示了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照。和类图一样,对象图给出系统的静态设计视图或静态进程视图,但它们是从真实的或原型案例的角度建立的。这种视图主要支持系统的功能需求。利用对象图可以对静态数据结构建模。
        用例图(Use Case Diagram)
        显示了一组用例、参与者(actor)以及它们之间的关系。用例图通常包括用例、参与者、扩展关系、包含关系,如下图所示。
        
        用例图
        包含(include)关系为用例建模提供了从两个或更多用例的描述中抽取通用部分的能力。一般情况下,如果若干个用例的某些行为是相同的,则可以把这些相同的行为提取出来作为一个单独的用例,这个用例称作抽象用例,其他用例可以包含该抽象用例。所以,在描述用例之前就开始抽取包含用例是不可取的。在UML的较早版本中也有uses关系,在UML2.2中uses和includes被include取代,称为包含关系。
        扩展(extend)关系提供了使用另外的可选流程来补充或插入到一个已存在的用例中的能力。因此,这是一种能够扩展原用例却不用对原来的用例进行重新描述的方法。
        包含关系和扩展关系的区别:
        .包含关系中,对基用例来说,如果缺少了被包含用例,则基用例不完整;扩展关系中,如果去掉扩展关系,基用例仍然完整。
        .包含关系中,被包含用例对基用例是可见的;扩展关系中,基用例对扩展用例可见,而扩展用例对基用例不可见。
        .扩展关系中,扩展用例本身具有独立的功能,而非从其他用例中抽取。
        .包含关系中,被包含用例通常应被两个以上的其他用例所包含。
        用例图用于对系统的静态用例视图进行建模。这个视图主要支持系统的行为,即该系统在它的周边环境的语境中所提供的外部可见服务。
        交互图
        序列图和协作图均被称为交互图,它们用于对系统的动态方面进行建模。一张交互图显示的是一个交互,由一组对象和它们之间的关系组成,包含它们之间可能传递的消息。序列图是强调消息时间顺序的交互图;协作图是强调接收和发送消息的对象的结构组织的交互图。交互图一般包含对象、链和消息。
        (1)序列图(Sequence Diagram)。
        序列图是场景的图形化表示,描述了以时间顺序组织对象之间的交互活动。如下图所示。
        
        序列图
        序列图有两个不同于协作图的特征:
        .序列图有对象生命线。对象生命线是一条垂直的虚线,表示一个对象在一段时间内存在。
        .序列图有控制焦点。控制焦点是一个瘦高的矩形,表示一个对象执行一个动作所经历的时间段,既可以是直接执行,也可以是通过下级过程执行。
        (2)协作图(Collaboration Diagram)。
        协作图强调收发消息的对象的结构组织。协作图有两个不同于序列图的特征:
        .协作图有路径。为了指定一个对象如何与另一个对象链接,可以在链的末端附上一个路径构造型。通常只需要显式地表示local(局部)、parameter(参数)、global(全局)以及self(自身)这几种链的路径,不必表示association(关联)。
        .协作图有顺序号。为表示一个消息的时间顺序,可以给消息加一个数字前缀(从1号开始),在控制流中,每个新消息的顺序号单调增加(如2、3等)。为了显示嵌套,可使用带小数点的号码(1表示第一个消息,1.1表示嵌套在消息1中的第一个消息,等等)。嵌套可为任意深度。另外,沿同一个链可以显示许多消息,且每个消息都有唯一一个顺序号。
        协作图和序列图是同构的,它们之间可以相互转换。
        状态图(Statechart Diagram)
        显示了一个状态机,它由状态、转换、事件和活动组成。状态图关注系统的动态视图,它对于接口、类和协作的行为建模尤为重要,强调对象行为的事件顺序。状态图通常包括简单状态和组合状态、转换(事件和动作)。如下图所示。
        
        状态图
        活动图(Activity Diagram)
        活动图是一种特殊的状态图,它显示了在系统内从一个活动到另一个活动的流程。活动图专注于系统的动态视图,它对于系统的功能建模特别重要,并强调对象间的控制流程。活动图一般包括活动状态和动作状态、转换和对象。
        活动图可以表示分支和汇合。当对一个系统的动态方面建模时,通常有两种使用活动图的方式:
        .对工作流建模。此时所关注的是与系统进行协作的参与者所观察到的活动。
        .对操作建模。此时把活动图作为流程图使用。
        构件图(Component Diagram)
        显示了一组构件之间的组织和依赖。构件图关注系统的静态实现视图,它与类图相关,通常把构件映射为一个或多个类、接口或协作。
        部署图(Deployment Diagram)
        显示了运行处理节点以及其中构件的配置。部署图给出了体系结构的静态实施视图。它与构件图相关,通常一个节点包含一个或多个构件。
        5.UML视图
        为方便起见,用视图来划分UML中的概念和组件。视图只是表达系统某一方面特征的UML建模组件的子集,在每一类视图中使用一种或多种特定的图来可视化地表示视图中的各种概念。
        在上层,视图被划分成三个视图域:结构、动态行为和模型管理。
        结构描述了系统中的结构成员及其相互关系。
        动态行为描述了系统随时间变化的行为。
        模型管理说明了模型的分层组织结构。包是模型的基本组织单元,特殊的包还包括模型和子系统。模型管理视图跨越了其他视图,并根据系统开发和配置组织这些视图。
        下表列出了UML的视图和视图所包括的图以及每种图有关的主要概念。
        
        UML视图
 
       观察
        观察是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。当产品使用者难以或不愿清晰说明他们的需求时,就更需要通过观察来了解他们的工作细节。观察,也称为“工作跟踪”,通常由观察者从外部来观看业务专家如何执行工作。也可以由“参与观察者”来观察,他通过实际执行一个流程或程序,来体验该流程或程序是如何实施的,以便挖掘出隐藏的需求。
 
       用例图
        用例是一种描述系统需求的方法。用例图(use case diagram)展现了一组用例、参与者(Actor)以及它们之间的关系。
        用例图中通常包含三种元素:用例、参与者、用例之间的关系,如下图所示。
        
        UML用例图
        参与者是指存在于系统外部并与系统进行交互的任何事物,既可以是使用系统的用户,也可以是其他外部系统和设备等外部实体。
        用例是描述系统的一项功能的一组动作序列,这样的动作序列表示参与者与系统间的交互。
        用例之间通常存在三种关系:包含(include)、扩展(extend)和泛化(generalization)。
        (1)包含关系。当可以从两个或两个以上的用例中提取公共行为时,应该使用包含关系来表示它们。其中被提取出来的公共用例称为抽象用例,而把原始用例称为基本用例或基础用例。当多个用例需要使用同一段事件流时,抽象成为公共用例,可以避免在多个用例中重复地描述这段事件流,也可以防止这段事件流在不同用例中的描述出现不一致。当需要修改这段公共的需求时,也只要修改一个用例,避免同时修改多个用例而产生的不一致和重复性工作。另外,当某个用例的事件流过于复杂时,为了简化用例的描述,也可以将某一段事件流抽象成为一个被包含的用例。
        (2)扩展关系。如果一个用例明显地混合了两种或两种以上的场景,即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例。
        (3)泛化关系。当多个用例共同拥有一种类似的结构和行为时,可以将它们的共性抽象成为父用例,其他的用例作为泛化关系中的子用例。在用例的泛化关系中,子用例是父用例的一种特殊形式,子用例继承了父用例所有的结构、行为和关系。
        用例图用于对系统的静态用例视图进行建模。这个视图主要支持系统的行为,即该系统在它的周边环境的语境中所提供的外部可见服务。
        当对系统的静态用例视图建模时,可以用下列两种方式来使用用例图:
        (1)对系统的语境建模。
        对一个系统的语境进行建模,包括围绕整个系统画一条线,并声明有哪些参与者位于系统之外并与系统进行交互。在这里,用例图说明了参与者以及它们所扮演的角色的含义。
        (2)对系统的需求建模。
        对一个系统的需求进行建模,包括说明这个系统应该做什么(从系统外部的一个视点出发),而不考虑系统应该怎样做。在这里,用例图说明了系统想要的行为。通过这种方式,用例图使我们能够把整个系统看作一个黑盒子。你可以观察到系统外部有什么,系统怎样与哪些外部事物相互作用,但却看不到系统内部是如何工作的。
   题号导航      2014年上半年 信息系统项目管理师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第11题    在手机中做本题