免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2015年下半年 信息系统项目管理师 上午试卷 综合知识
  第26题      
  知识点：   可视化建模与UML   功能需求   建模   角色   统一建模语言
  关键词：   开发   统一建模语言   需求   建模   语言        章/节：   信息系统及其技术和开发方法       

 
在统一建模语言中（26）的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求包括基于基本流程的“角色”关系等。
 
 
  A.  用例图
 
  B.  类图
 
  C.  序列图
 
  D.  状态图
 
 
 

 
  第26题    2017年下半年  
   65%
UML2.0中共包括14种图，其中（ ）属于交互图。
  第8题    2013年下半年  
   44%
软件设计过程中，视图可以从不同角度描述软件结构，以下关于几个常见视图的说法中，（8）是错误的。
  第26题    2011年上半年  
   49%
假设ICBCA_ACCOUNT和CBCA_ACCOUNT是用计算机语言定义的两个不同的类。前者代表工商银行账户，后者代表建设银行账户。ZhangSan_IC..
   知识点讲解    
   · 可视化建模与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建模等。
        造型组合是把已有的物体组合成新的物体，其中布尔运算是最重要的组合技术。
 
       角色
        考虑一个有很多出纳的银行。每一个出纳必须对同一组关系具有同种类型的权限。无论何时指定一个新的出纳，他都必须被单独授予所有这些授权。
        一个更好的机制是指明所有出纳应该有的授权，并单独标示出哪些数据库用户是出纳。系统可以用这两条信息来确定每一个有出纳身份的人的权限。当一个人被新雇佣为出纳时，必须给他分配一个用户标识符，并且必须将他标示为一个出纳，而不需要重新单独给予出纳权限。
        角色（role）的概念可用于该机制。在数据库中建立一个角色集，和授予每一个单个用户一样，可将权限授予角色。分配给每个数据库用户一些他（或她）有权扮演的角色（也可能是空的）。
        事实上，在银行的数据库里，角色的例子可以包括system-administrator、branch-manager、teller和auditor。一个不是很合适的方法是建立一个teller用户号，允许每一个出纳用这个出纳用户号来连接数据库。该机制的问题是它无法鉴别出到底哪个出纳执行了事务，从而导致安全隐患。应用角色的好处是需要每个用户用自己的用户号连接数据库。
        任何可以授予一个用户的权限都可以授予一个角色。给用户分配角色就跟给用户授权一样。与其他授权一样，一个用户也可以被授予给他人分配角色的权限。这样，可以授予支行经理（branch-manager）分配出纳角色的权限。
 
       统一建模语言
        UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
        在这个知识点，要求掌握UML的图形和类之间的关系，以及用例之间的关系。
               UML的图形
               UML2.0包括14种图，分别列举如下。
               （1）类图（Class Diagram）：展现了一组类、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出了系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。
               （2）对象图（Object Diagram）：展现了一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。
               （3）构件图（Component Diagram）：展现了一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。
               （4）组合结构图（Composite Structure Diagram）：它可以描绘结构化类（例如构件或类）的内部结构，包括结构化类与系统其余部分的交互点。它显示联合执行包含结构化类的行为的部件配置。组合结构图用于画出结构化类的内部内容。
               （5）用例图（Use Case Diagram）：展现一组用例、参与者（一种特殊的类）及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。
               （6）顺序图和通信图：两者都是交互图。交互图（Interaction Diagram）展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图（Sequence Diagram）是强调消息的时间次序的交互图；通信图（Communication Diagram）也是一种交互图，它强调收发消息的对象或角色的结构组织。顺序图和通信图表达了类似的基本概念，但每种图所强调的概念不同，顺序图强调的是时序，通信图则强调消息流经的数据结构。
               （7）状态图（State Diagram）：展现一个状态机，它由状态、转移、事件和活动组成。状态图展现了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。
               （8）活动图（Activity Diagram）：将进程或其他计算的结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模特别重要，并强调对象间的控制流程。
               （9），部署图（Deployment Diagram）：展现了对运行时的处理结点及在其中生存的构件的配置。部署图给出了体系结构的静态部署视图，通常一个结点包含一个或多个部署图。
               （10）制品图（Artifact Diagram）：展现了计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理位集合。制品图通常与部署图一起使用。制品也展现了它们实现的类和构件。
               （11）包图（Package Diagram）：展现了由模型本身分解而成的组织单元，以及它们的依赖关系。
               （12）定时图（Timing Diagram）：是一种交互图，它展现了消息跨越不同对象或角色的实际时间，而不仅仅只是关心消息的相对顺序。
               （13）交互概览图（Interaction Overview Diagram）：是活动图和顺序图的混合物。
               用例之间的关系
               两个用例之间的关系可以概括为两种情况：一种是用于重用的包含关系，用构造型include或use表示；另一种是用于分离出不同行为的扩展关系，用构造型extend表示。
               （1）包含关系：当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个构件来实现某一个用例很重要的部分功能时，应该使用包含关系来表示它们。
               （2）扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，则可以断定将这个用例分为一个主用例和一个或多个辅用例进行描述可能更加清晰。
               另外，用例之间还存在一种泛化关系。用例可以被特别列举为一个或多个子用例，这被称做用例泛化。当父用例能够被使用时，任何子用例也可以被使用。例如，购买飞机票时，既可以通过电话订票，也可以通过网上订票，则订票用例就是电话订票和网上订票的抽象。
               类之间的关系
               （1）关联关系。描述了给定类的单独对象之间语义上的连接。关联提供了不同类之间的对象可以相互作用的连接。其余的关系涉及类元自身的描述，而不是它们的实例。用“”表示。
               （2）依赖关系。有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。在UML中，使用带箭头的虚线“”表示依赖关系。
               在类中，依赖由各种原因引起，例如，一个类向另一个类发送消息；一个类是另一个类的数据成员；一个类是另一个类的某个操作参数。如果一个类的接口改变，则它发出的任何消息都可能不再合法。
               （3）泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类继承的，而父类则是子类的泛化。在UML中，使用带空心箭头的实线“”表示泛化关系，箭头指向父类。
               （4）聚合关系。聚合是一种特殊形式的关联，它是传递和反对称的。聚合表示类之间的关系是整体与部分的关系。例如一辆轿车包含4个车轮、一个方向盘、一个发动机和一个底盘，就是聚合的一个例子。在UML中，使用一个带空心菱形的实线“”表示聚合关系，空心菱形指向的是代表“整体”的类。
               （5）组合关系。如果聚合关系中表示“部分”的类的存在与否与表示“整体”的类有着紧密的关系，例如“公司”与“部门”之间的关系，那么就应该使用“组合”关系来表示这种关系。在UML中，使用带有实心菱形的实线“”表示组合关系。
               （6）实现关系。实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类之中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。实现关系用“”表示。
               （7）流关系。流关系将一个对象的两个版本以连续的方式连接起来。它表示一个对象的值、状态和位置的转换。流关系可以将类元角色在一次相互作用中连接起来。流的种类包括变成（同一个对象的不同版本）和复制（从现有对象创造出一个新的对象）两种。用“”表示。
   题号导航      2015年下半年 信息系统项目管理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第26题    在手机中做本题