免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2012年上半年 信息系统项目管理师 上午试卷 综合知识
  第8题      
  知识点：   可视化建模与UML   进程   软件需求   视图   数据流
  关键词：   进程   开发   数据   物理视图   需求   视图        章/节：   信息系统及其技术和开发方法       

 
Philippe kruchten提出的4+1视图模型从（8）几个方面来描述软件需求。
①逻辑视图②进程视图③物理视图④开发视图⑤数据流视图⑥场景视图
 
 
  A.  ③④⑤⑥
 
  B.  ①②③④
 
  C.  ①②③④⑥
 
  D.  ①③④⑤⑥
 
 
 

 
  第11题    2009年下半年  
   42%
以下关于UML的叙述，错误的是（11）。
  第27题    2017年下半年  
   47%
（ ）又称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
  第11题    2014年上半年  
   40%
用例图主要用来描述用户与系统功能单元之间的关系，它展示了一个外部用户能够观察到的系统功能模型图。在一个订票系统中，下图表..
   知识点讲解    
   · 可视化建模与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视图
 
       进程
        简单而言，一个进程就是一个正在运行的程序。一般来说，一个进程至少应该包括以下几个方面的内容。
        .相应的程序：进程既然是一个正在运行的程序，当然需要有相应程序的代码和数据。
        .CPU上下文：指程序在运行时，CPU中各种寄存器的当前值，包括：程序计数器，用于记录将要取出的指令的地址；程序状态字，用于记录处理器的运行状态信息；通用寄存器，用于存放数据或地址；段寄存器，用于存放程序中各个段的地址；栈指针寄存器，用于记录栈顶的当前位置。
        .一组系统资源：包括操作系统用来管理进程的数据结构、进程的内存地址空间、进程正在使用的文件等。
        进程有动态性、独立性和并发行三个特性。
        （1）动态性。进程是一个正在运行的程序，而程序的运行状态是在不断地变化的。例如，当一个程序在运行的时候，每执行完一条指令，PC寄存器的值就会增加，指向下一条即将执行的指令。而CPU中用来存放数据和地址的那些通用寄存器，它们的值肯定也不断地变化。另外，堆和栈的内容也在不断地变化，每当发生一次函数调用时，就会在栈中分配一块空间，用来存放此次函数调用的参数和局部变量。而当函数调用结束后，这块栈空间就会被释放掉。
        （2）独立性。一个进程是一个独立的实体，是计算机系统资源的使用单位。每个进程都有自己的运行上下文和内部状态，在它运行的时候独立于其他的进程。
        （3）并发性。从宏观上来看，在系统中同时有多个进程存在，它们相互独立地运行。
        下图表示四个进程A、B、C、D在系统中并发地运行。从中可以看出，虽然从宏观上来说，这四个进程都是在系统中运行，但从微观上来看，在任何一个特定的时刻，只有一个进程在CPU上运行。从时间上来看，开始是进程A在运行，然后是进程B在运行，然后是进程C和进程D。接下来又轮到了进程A去运行。因此，在单CPU的情形下，所谓的并发性，指的是宏观上并发运行，而微观上还是顺序运行，各个进程轮流去使用CPU资源。
        
        四个进程在并发运行
        在具体实现上，以CPU中的程序计数器PC为例，真正物理上的PC寄存器只有一个。当四个进程在轮流执行时，PC取值的运动轨迹是先在进程A内部流动，然后再到进程B的内部流动，再到进程C和D。从进程的独立性角度来说，每个进程都有“自己”独立的PC寄存器，即逻辑上的PC寄存器，它们的取值相互独立、互不影响。所谓的逻辑PC，其实就是一个内存变量。例如，在上图中，当进程A要执行的时候，就把A的逻辑PC的值拷贝到物理PC中，然后开始运行。当轮到B运行的时候，先把物理PC的当前值保存到A的逻辑PC中，然后再把B的逻辑PC的值装入到物理PC中，即可运行。这样就实现了各个进程的轮流运行。
 
       软件需求
        在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。
        （1）功能需求。
        （2）性能需求。
        （3）用户或人的因素。
        （4）环境需求。
        （5）界面需求。
        （6）文档需求。
        （7）数据需求。
        （8）资源使用需求。
        （9）安全保密要求。
        （10）可靠性要求。
        （11）软件成本消耗与开发进度需求。
        （12）其他非功能性要求。
               需求分析的任务
               需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
               （1）确定软件系统的综合要求，包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
               （2）分析软件系统的数据要求，包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
               （3）导出系统的逻辑模型，在结构化方法中可用数据流图来描述；在面向对象分析方法中可以用类模型来描述。
               （4）修正项目开发计划。
               （5）如有必要，可开发一个原型系统以验证用户的需求。
               软件需求的分类
               下面介绍软件需求的分类。
               （1）功能需求。所开发的软件必须具备什么样的功能。
               （2）非功能需求。它是指产品必须具备的属性或品质，如可靠性、性能响应时间、容错性和可扩展性等。
               （3）设计约束。其也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。
               软件需求分析方法
               需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
 
       视图
        幻灯片视图功能为用户提供了各种适应不同使用情况的操作界面，其中包括普通视图、幻灯片浏览视图、幻灯片放映视图。当启动PowerPoint时，系统默认的是普通视图工作方式。
               普通视图。
               普通视图也称为编辑视图。在该视图工作方式下，可进行演示文稿的编辑和制作，如输入文字、绘制图形和插入图片、插入声音和视频、设置动画及切换效果、设置超链接等。普通视图有4个工作区域，如上图所示。
               .大纲／幻灯片工作区：位于窗口的左侧，可通过单击“大纲”选项卡或“幻灯片”选项卡在幻灯片文本大纲或幻灯片缩略图之间切换。
               .主工作区：位于窗口的中部，用于显示和编辑当前幻灯片。
               .任务窗格：位于窗口的右侧，提供常用命令的窗口。主要操作包括创建新演示文稿；选择幻灯片的版式；选择设计模板、配色方案和动画方案；创建自定义动画；设置幻灯片切换等。
               .备注区：位于窗口的下方，用户可以添加备注信息。
               幻灯片放映视图。
               在该视图方式下，可以放映演示文稿中的所有幻灯片。若幻灯片添加了切换效果，则会播放出来；若为幻灯片中的对象设置了动画效果，则在放映时即可展现动画效果。设置的超链接只有在幻灯片放映视图中才有效。
               幻灯片浏览视图。
               在该视图方式下，可以观察演示文稿的全局并了解演示文稿的风格，还可以调整演示文稿的顺序。可以对幻灯片进行选择、复制、删除、隐藏等操作，设置幻灯片的切换效果。
 
       数据流
        数据流由一组固定成分的数据组成，表示数据的流向。在DFD中，数据流的流向可以有以下几种：从一个加工流向另一个加工；从加工流向数据存储（写）；从数据存储流向加工（读）；从外部实体流向加工（输入）；从加工流向外部实体（输出）。
        DFD中的每个数据流用一个定义明确的名字表示。除了流向数据存储或从数据存储流出的数据流不必命名外，每个数据流都必须有一个合适的名字，以反映该数据流的含义。
        数据流或者由具体的数据属性（也称为数据结构）构成，或者由其他数据流构成。组合数据流是由其他数据流构成的数据流，它们用于在高层的数据流图中组合相似的数据流，以使数据流图更便于阅读。
        控制流是对数据流图的补充，采用虚线表示，是对由触发系统功能的事件进行描述。
        另外，一个加工可以有多个输入数据流和多个输出数据流，此时可以加上一些扩充字符符号或图形元素来描述多个数据流之间的关系。如：
        （1）星号（*）。星号表示数据流之间存在“与”关系。如果是输入流则表示所有输入数据流全部到达后才能进行加工处理；如果是输出流则表示加工结束将同时产生所有的输出数据流。
        （2）加号（+）。加号表示数据流之间存在“或”关系。如果是输入流则表示其中任何一个输入数据流到达后就能进行加工处理；如果是输出流则表示加工处理的结果是至少产生其中一个输出数据流。
        （3）异或（⊕）。异或表示数据流之间存在“互斥”关系。如果是输入流则表示当且仅当其中一个输入流到达后才能进行加工处理；如果是输出流则表示加工处理的结果是仅产生这些输出数据流中的一个。
   题号导航      2012年上半年 信息系统项目管理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第8题    在手机中做本题