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

 
在用UML对信息系统建模过程中,(27)来描述用户需求,主要从用户的角度描述系统的功能。
 
 
  A.  用例图
 
  B.  类图
 
  C.  对象图
 
  D.  部署图
 
 
 

 
  第51题    2009年上半年  
   35%
系统组织结构与功能分析中,可以采用多种工具,其中(51)描述了业务和部门的关系。
  第26题    2016年下半年  
   28%
以下关于UML的叙述中,不正确的是(26)。
  第2题    2013年上半年  
   40%
面向对象开发方法主要分为分析、设计和实现三个阶段,下面属于分析阶段主要工作的是(2)。
   知识点讲解    
   · 可视化建模与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视图
 
       建模
        建模是在计算机上创造三维形体的过程,建模是三维动画的基础,没有一个好的模型,其他好的效果都难以表现。三维建模的基本方法主要有:利用二维形体的技术、直接进行三维物体建模、造型组合等。
        利用二维形体进行建模的技术的主要思想是首先创建简单的二维形体,如样条线和形状等,然后对这些创建的二维形体进行挤压、旋转、放样等操作以创建三维造型。
        直接进行三维物体建模的常用方法有多边形建模、面片建模、NURBS建模等。
        造型组合是把已有的物体组合成新的物体,其中布尔运算是最重要的组合技术。
 
       系统建模
        通常软件开发项目是要实现目标系统的物理模型,即确定待开发软件的系统元素,并将功能和数据结构分配到这些系统元素中,它是软件实现的基础。但是目标系统的具体物理模型是由它的逻辑模型经实例化,即具体到某个业务领域而得到的。与物理模型不同,逻辑模型忽视实现机制与细节,只描述系统要完成的功能和要处理的数据。作为目标系统的参考,系统分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的“做什么”的问题。
        结合现有系统(当前)的分析,进行新系统设计的过程如下图所示。
        
        现有系统的研究和分析过程
        (1)获得当前系统的物理模型。当前系统可能是需要改进的某个已在计算机运行的数据处理系统,也可能是一个人工的数据处理过程。在这一步首先分析、理解当前系统是如何运行的,了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程,并用一个具体模型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。
        (2)抽象出当前系统的逻辑模型。在理解当前系统“怎样做”的基础上,抽取其“做什么”的本质,从而从当前系统的物理模型中抽象出当前系统的逻辑模型。在物理模型中有许多物理因素,随着分析工作的深入,有些非本质的物理因素就成为不必要的负担,因而需要对物理模型进行分析,区分出本质的和非本质的因素,去掉那些非本质的因素即可获得反映系统本质的逻辑模型。
        (3)建立目标系统的逻辑模型。分析目标系统与当前系统逻辑上的差别,明确目标系统到底要“做什么”,从当前系统的逻辑模型导出目标系统的逻辑模型。
        (4)建立目标系统的物理模型。根据新系统的逻辑模型构建出相应的物理模型。
        原有系统可以是一个正在运行的软件系统,也可以是一个纯手工运作的流程。
 
       用户需求
        收集用户需求是要找出用户需要的重要服务和功能。收集用户需求的机制主要包括与用户群的交流、用户服务和需求归档3个方面。
        收集用户需求最常用的方式有观察和问卷调查、集中访谈、采访关键人物。在整个设计和实施阶段,应始终保持与关键人员之间的交流,以确保网络工程建设不偏离用户需求。
        用户服务表用于表示收集和归档的需求信息,也用来指导管理人员和网络用户进行讨论。
   题号导航      2016年上半年 信息系统项目管理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第27题    在手机中做本题