免费智能真题库 > 历年试卷 > 信息系统管理工程师 > 2013年上半年 信息系统管理工程师 上午试卷 综合知识
  第8题      
  知识点:   UML中的图   统一建模语言(UML)的应用   需求分析阶段   角色   需求分析
  关键词:   UML   分析阶段   需求分析   需求        章/节:   系统分析设计基础知识       

 
需求分析阶段,可利用UML中的(8)描述系统的外部角色和功能要求。
 
 
  A.  用例图
 
  B.  静态图
 
  C.  交换图
 
  D.  实现图
 
 
 

 
  第45题    2018年上半年  
   49%
UML中的关系不包括( )。
  第46题    2020年下半年  
   44%
以下选项中,(46) 不属于UML的图。
  第34题    2016年上半年  
   41%
在统一建模语言:(UML)中,(34)给出了系统内从一个活动到另一个活动的流程,它强调对象间控制流程。
 
  第34题    2009年下半年  
   48%
(34)属于UML中的交互图。
  第35题    2016年上半年  
   29%
假设某公司业务的用例模型中,“检验”用例需要等到“生产”用例执行之后才能执行,这两个用例之间的关系属..
  第45题    2018年上半年  
   49%
UML中的关系不包括( )。
   知识点讲解    
   · UML中的图    · 统一建模语言(UML)的应用    · 需求分析阶段    · 角色    · 需求分析
 
       UML中的图
        图(diagram)是一组元素的图形化表示,大多数情况下把图画成顶点(代表事物)和弧(代表关系)的连通图。为了对系统进行可视化,可以从不同的角度画图,这样图是对系统的投影。除了非常微小的系统外,图是系统组成元素的省略视图。有的元素可以出现在所有图中,有的元素可以出现在一些图中(很常见),还有的元素不能出现在图中(很罕见)。在理论上,图可以包含任何事物及其关系的组合。然而,实际上仅存在着少量的常见组合,它们要与5种最有用的组成了软件密集型系统的体系结构的视图相一致。由于这个原因,UML中的图可以分为几下几类:
        ①第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。
        ②第二类是静态图(Static Diagram),包括类图、对象图和包图。
        .类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。
        .对象图是类图的实例,几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
        .包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。
        ③第三类是行为图(Behavior Diagram),描述系统的动态模型和组成对象间的交互关系。包括状态图和活动图。
        .状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实际应用时并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。
        .活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
        ④第四类是交互图(Interactive Diagram),描述对象间的交互关系。包括顺序图和合作图。
        .顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互。
        .合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图被合称为交互图。
        ⑤第五类是实现图(Implementation Diagram)。包括组件图和配置图。
        .组件图描述代码部件的物理结构及各部件之间的依赖关系。一个组件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。组件图有助于分析和理解部件之间的相互影响程度。
        .配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用结点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。在结点内部,放置可执行部件和对象以显示结点跟可执行软件单元的对应关系。
        使用用例图、类图、对象图、构件图和配置图等5个图形建立的模型都是静态的,是标准建模语言UML的静态建模机制;使用状态图、活动图、顺序图和协作图等4个图形建立的模型或者可以执行,或者可以表示执行时的时序状态或交互关系,是动态的、是标准建模语言UML的动态建模机制。因此,标准建模语言UML的主要内容也可以被归纳为静态建模机制和动态建模机制两大类。
 
       统一建模语言(UML)的应用
        UML的目标是以面向对象图的方式来描述任何类型的系统,具有很宽的应用领域。其中最常用的是建立软件系统的模型,但它同样可以用于描述非软件领域的系统,如机械系统、企业机构或业务过程,以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之,UML是一个通用的标准建模语言,可以对任何具有静态结构和动态行为的系统进行建模。
        此外,UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。UML在软件开发不同阶段的应用包括:
               需求分析阶段
               在需求分析阶段,可以用用例来捕获用户需求。通过用例建模,描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。建模的每个用例都指定了客户的需求(他或她需要系统干什么)。
               系统分析阶段
               分析阶段主要关心问题域中的主要概念(如抽象、类和对象等)和机制,需要识别这些类以及它们相互间的关系,并用UML类图来描述。为实现用例,类之间需要协作,这可以用UML动态模型来描述。在分析阶段,只对问题域的对象(现实世界的概念)建模,而不考虑定义软件系统中技术细节的类(如处理用户接口、数据库、通信和并行性等问题的类)。这些技术细节将在设计阶段引入。
               系统设计阶段
               在设计阶段把分析阶段的结果扩展成技术解决方案,加入新的类来提供技术基础结构。用户接口、数据库操作等分析阶段的领域问题类被嵌入在这个技术基础结构中,设计阶段的结果是构造阶段的详细的规格说明。
               系统实施阶段
               实施是一个独立的阶段,其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。在用UML建立分析和设计模型时,应尽量避免考虑把模型直接转换成某种特定的编程语言。因为在早期阶段,模型仅仅是理解和分析系统结构的工具,过早考虑编码问题十分不利于建立简单正确的模型。
               系统测试阶段
               UML模型可作为测试阶段的依据。系统的测试通常分为单元测试、集成测试、系统测试和验收测试几个不同级别。
               .单元测试是对几个类或一组类的测试,通常由程序员进行。
               .集成测试集成组件和类确认它们之间是否恰当的协作。
               .系统测试将系统当成一个黑箱,验证系统是否具备用户所要求的所有功能。
               .验收测试由客户完成,与系统测试类似,验证系统是否满足所有的需求。
               不同的测试小组使用不同的UML图作为测试依据:单元测试使用类图和类规格说明;集成测试使用组件图和合作图;系统测试使用用例图来验证系统的行为;验收测试由用户进行,以验证系统测试的结果是否满足在分析阶段确定的需求。
 
       需求分析阶段
        在需求分析阶段,可以用用例来捕获用户需求。通过用例建模,描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。建模的每个用例都指定了客户的需求(他或她需要系统干什么)。
 
       角色
        考虑一个有很多出纳的银行。每一个出纳必须对同一组关系具有同种类型的权限。无论何时指定一个新的出纳,他都必须被单独授予所有这些授权。
        一个更好的机制是指明所有出纳应该有的授权,并单独标示出哪些数据库用户是出纳。系统可以用这两条信息来确定每一个有出纳身份的人的权限。当一个人被新雇佣为出纳时,必须给他分配一个用户标识符,并且必须将他标示为一个出纳,而不需要重新单独给予出纳权限。
        角色(role)的概念可用于该机制。在数据库中建立一个角色集,和授予每一个单个用户一样,可将权限授予角色。分配给每个数据库用户一些他(或她)有权扮演的角色(也可能是空的)。
        事实上,在银行的数据库里,角色的例子可以包括system-administrator、branch-manager、teller和auditor。一个不是很合适的方法是建立一个teller用户号,允许每一个出纳用这个出纳用户号来连接数据库。该机制的问题是它无法鉴别出到底哪个出纳执行了事务,从而导致安全隐患。应用角色的好处是需要每个用户用自己的用户号连接数据库。
        任何可以授予一个用户的权限都可以授予一个角色。给用户分配角色就跟给用户授权一样。与其他授权一样,一个用户也可以被授予给他人分配角色的权限。这样,可以授予支行经理(branch-manager)分配出纳角色的权限。
 
       需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (1)结构化分析方法。本节后续内容将详细讨论SA的内容。
        (2)面向对象分析方法。将在10.3节中进行详细介绍。
        (3)面向问题域的分析(Problem Domain Oriented Analysis, PDOA)方法。PDOA更多地强调描述,而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素,是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图,但不同的是上下文图的建模对象是针对解系统,而问题框架则是针对问题域。也就是说,问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段,并未广泛应用。
               业务流程分析
               业务流程分析的目的是了解各个业务流程的过程,明确各个部门之间的业务关系和每个业务处理的意义,为业务流程的合理化改造提供建议,为系统的数据流程变化提供依据。
               业务流程分析的步骤如下:
               (1)通过调查掌握基本情况。
               (2)描述现有业务流程(绘制业务流程图)。
               (3)确认现有业务流程。
               (4)对业务流程进行分析。
               (5)发现问题,提出解决方案。
               (6)提出优化后的业务流程。
               在业务流程图中使用的基本符号如下图所示。
               数据流图
               DFD是结构化分析中的重要方法和工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型,在信息系统开发中,一般将它作为需求说明书的组成部分。
               
               业务流程图符号
               DFD从数据传递和加工的角度,利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况,来说明系统所完成的功能。具体来说,DFD的主要作用如下:
               (1)DFD是理解和表达用户需求的工具,是系统分析的手段。由于DFD简明易懂,理解它不需要任何计算机专业知识,因此通过它同客户交流很方便。
               (2)DFD概括地描述了系统的内部逻辑过程,是系统分析结果的表达工具,因而也是系统设计的重要参考资料,是系统设计的起点。
               (3)DFD作为一个存档的文字材料,是进一步修改和充实开发计划的依据。
               在DFD中,通常会出现4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据,在DFD中用标有名字的箭头表示。加工是对数据流的变换,一般用圆圈表示。数据存储是可访问的存储信息,一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者,是不能由计算机处理的成分,它们分别表明数据处理过程的数据来源及数据去向,用标有名字的方框表示。下图是一个典型的DFD示例。
               
               办理取款手续的DFD
               为了表达数据处理过程中的数据加工情况,用一个DFD是不够的。稍微复杂的实际问题,在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解,并以分层的DFD反映这种结构关系,能清楚地表达整个系统。
               下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1,第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说,它的上层图称为父图,在它下一层的图则称为子图。
               
               分层数据流图
               概括地说,画DFD的基本步骤,就是“自顶向下,逐层分解”。检查和修改的原则如下:
               (1)DFD中的所有图形符号只限于前述4种基本图形元素。
               (2)顶层DFD必须包括前述4种基本元素,缺一不可。
               (3)顶层DFD中的数据流必须封闭在外部实体之间。
               (4)每个加工至少有一个输入数据流和一个输出数据流。
               (5)在DFD中,需按层给加工框编号。编号表明了该加工处在哪一层,以及上下层的父图与子图的对应关系。
               (6)规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
               (7)可以在DFD中加入物质流,帮助用户理解DFD。
               (8)图上每个元素都必须有名字。
               (9)DFD中不可夹带控制流。
               数据字典
               数据字典是关于数据的信息的集合,也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD,数据字典难以发挥作用;没有数据字典,DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起,才能共同构成系统的规格说明。
               数据字典的设计包括:数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息:名称、别名或编号、分类、描述、何处使用。
               对加工的描述是数据字典的组成内容之一,常用的加工描述方法有结构化语言、判定树及判定表。
               (1)结构化语言:介于自然语言和形式语言之间的一种半形式语言,在自然语言基础之上加了一些限度,使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句,即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定,与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇:祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               (2)判定树:若一个动作的执行不只依赖一个条件,而与多个条件有关,那么这项策略的表达就比较复杂。如果用结构化语言的判断语句,就有多重嵌套,层次一多,可读性就会下降。用判定树来表示,可以更直观一些。
               (3)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
   题号导航      2013年上半年 信息系统管理工程师 上午试卷 综合知识   本试卷我的完整做题情况  
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题    在手机中做本题