免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2013年下半年 信息系统项目管理师 上午试卷 综合知识
  第8题      
  知识点:   可视化建模与UML   软件设计   设计过程   视图
  关键词:   软件设计   视图        章/节:   信息系统及其技术和开发方法       

 
软件设计过程中,视图可以从不同角度描述软件结构,以下关于几个常见视图的说法中,(8)是错误的。
 
 
  A.  逻辑视图从功能需求角度描述了软件结构
 
  B.  组件视图从实现角度描述了软件结构
 
  C.  过程视图从质量角度描述了软件结构
 
  D.  部署视图从分布问题角度描述了软件结构
 
 
 

 
  第26题    2018年上半年  
   35%
关于UML的描述,不正确的是:()。
  第27题    2015年上半年  
   27%
以下关于UML的叙述中,()是正确的。
  第25题    2013年下半年  
   26%
在面向对象开发方法中,(25)是指同一消息发送给不同的对象,会有不同的响应。
   知识点讲解    
   · 可视化建模与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视图
 
       软件设计
               软件设计的任务
               在给定系统的需求规格说明书后,需要对软件的结构进行设计,并对设计的过程进行管理。在嵌入式系统的软件设计过程中,需要完成以下一些任务。
                      准备工作计划
                      在软件设计之前,首先要制订详细的工作计划,其内容包括:
                      .过程管理方案:包括软件开发的进度管理、软件规模和所需人年的估算、开发人员的技能培训等;
                      .开发环境的准备方案:包括开发工具的准备、开发设备的准备、测试装备的准备、分布式开发环境下的开发准则等;
                      .软硬件联机调试的方案:联调的起始时间、地点、人员和具体的准备工作;
                      .质量保证方案:包括质量目标计划、质量控制计划等;
                      .配置控制方案:包括配置控制文档的编写、配置控制规则的制订等。
                      确定软件的结构
                      设计软件的各个组成部分,包括:
                      .任务结构的设计:使用操作系统提供的函数,设计出一个最佳的任务结构;
                      .线程的设计;
                      .公共数据结构的设计:在确保系统一致性的基础上,设计出所需的公共数据;
                      .操作系统资源的定义;
                      .类的设计;
                      .模块结构设计:在设计时要充分考虑模块的划分、标准化、可重用和灵活性等;
                      .内存的分配与布局。
                      设计评审
                      对于软件设计的结果,进行一次设计评审,并在必要时对设计进行修正。具体内容包括:
                      .确认每件工作的执行方法是否恰当,其内容是否完善;
                      .确认该设计完成了系统需求规格说明书所要求的功能和服务;
                      .评估任务结构设计、评估类的设计、评估模块结构设计;
                      .对软件设计的结果进行总结,编写出相应的文档。
                      维护工作计划
                      执行软件设计工作控制,在每日、每周和每月的时间粒度上对进度进行控制,确保软件设计能够如期完成。
                      与硬件部门密切合作、相互协调
                      根据工作计划中的安排,定期与硬件部门召开会议,协调各自的进展。如果软件规格说明书发生了变化,立即进行调整,重新进行软件设计。
                      控制工作的结果,把工作记录存档
                      掌握当前的工作进展情况,尽早地发现和分析问题,并采取相应的措施。对各种事件进行跟踪记录,包括:
                      .执行过程控制,跟踪进展情况并定期记录、存档。
                      .执行质量控制,保留质量记录。
                      .记录产品的配置、版本变化、bug的发现和处理等信息。
               软件架构设计
               软件架构也称为软件体系结构,需要考虑如何对系统进行分解,对分解后的组件及其之间的关系进行设计,满足系统的功能和非功能需求。软件架构形成过程如下图所示。
               
               架构的形成过程概要
               软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变,随后的架构设计需要通过一系列的迭代开发完善,使得软件架构日趋成熟、稳定。
               软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构,包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐,确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求,也具有可扩展、可移植性,从而为一个软件带来长久的生命力。
               在大量开发实践中,有很多广泛使用并被普遍接受的软件架构设计原则,这些原则独立于具体的软件开发方法,主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。
               (1)抽象:这是软件架构的核心原则,也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性,从具体的事务中通过封装来忽略细节,并且运用这些特征和属性,描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象,从而有多个不同层次架构。
               (2)信息隐藏:包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中,减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。
               (3)强内聚和松耦合:强内聚是指软件组件内的特性,即组件内所有处理都高度相关,所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性,软件组件之间应尽量做到没有或极少的直接关系,使其保持相对独立,这样使得未来的修改、复用简单,修改之后带来的影响最小。
               (4)关注点分离:所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件,需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分,使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单,那么就更容易理解和实现。但“展示某些关注点得到满足时,可能会影响到其他方面的关注点,但架构师必须能够说明所有关注点都已得到满足”。
               以上的原则中,删除需求细节或对细节进行抽象是最重要的工作,为用户的需求创建抽象模型,通过抽象将特殊问题映射为更普遍的问题类别,并识别各种模式。
               软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层,横向分解就是将每一个层面分成相对独立的部分。经过分解之后,可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装,功能独立、功能高度内聚、之间低耦合的一个组件。
               类似于建筑架构,软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性,好的软件架构也给人完整、明确、清晰等赏心悦目的感觉,具有较长的生命力。
               架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则,在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素,而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒,架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础,在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计,开发人员需要关注各子问题或要素的进一步分解和实现,是根据架构设计所定义的每个要素的功能、接口,进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下,考虑实现组件内部的细节及其实现方法。对于其中的公共子问题,形成公共类和工具类,从而可以达到重用的目的。
               一般的软件构架是根据需求自上而下方式来设计,即首先掌握和研究利益相关方的关键需求,基本思路是首先进行系统级的软件架构设计,需要将软件组件与其外部环境属性绑定在一起,关注软件系统与外部环境的交联设计;其次将一个大的系统划分成各组成部分,这些部分可以按照架构设计的不同方法,分为层次或成为模块;之后再开始研究所涉及到的要素,再实现这些要素以及定义这些要素之间的关系。
               在实际工作中,软件构架也可采用自底向上的方法,前提是已经建立了一个成熟稳定的软件架构,也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路,是为了解决共有问题解的方案模板,但并不是一个问题的设计或设计算法。
               模式常常整合在一起使用,提供解决更大、更复杂问题的解决方案,而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具,而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架,这时其他重要元素可以在这个架构基础上针对新的需求进行扩展,有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计,采用成熟的先进的设计框架和工具提高开发的效率,保证设计正确性。
               下图所示是针对架构设计中非功能需求的多维度分析,从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分,但超越了系统内部的算法和数据结构的详细设计。
               
               架构的多维度分析
               在架构设计阶段,需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。
               软件设计方法
               在将系统分解为各个组件的过程中,需要采取不同的策略,而每个策略则关注不同的设计概念。根据分解过程中所采用的不同策略,设计方法有基于功能分解的设计方法、基于信息隐藏的设计方法和基于模型驱动开发的设计方法等分类。
               (1)基于功能分解的设计方法。实时结构化分析与设计采用了功能分解,系统被分解为多个函数,并且以数据流或控制流的形式定义函数之间的接口;基于并发任务结构化的设计(Design Approach for Real-Time Systems,DARTS)提供了任务结构化标准,辅助人员确定系统中的并发任务,并指导定义任务接口。
               (2)基于信息隐藏的设计方法。面向对象(Object Oriented,OO)设计方法将数据和数据上操作封装在对象实体中,对象外界不能够直接对对象内部进行访问和操作,只能通过消息间接访问对象,符合人类思维方式,提高软件的扩展性、维护性和重用性。
               (3)基于模型驱动开发的设计方法。通过借助有效的(Model Driven Development,MDD)工具,构建和维护复杂系统的设计模型,直接产生高质量的代码,将开发的重心从编码转移到设计。当前使用较为广泛的MDD工具有IBM公司的Rhapsody。
 
       设计过程
        结构化设计的过程如下。
        (1)精化DFD。
        (2)确定DFD的信息流类型(变换流或事务流)。
        (3)根据流类型分别将变换流或事务流转换成程序结构图。
        (4)根据软件设计的原则对程序结构图做优化。
        (5)描述模块功能、接口及全局数据结构。
        (6)复查。
 
       视图
        幻灯片视图功能为用户提供了各种适应不同使用情况的操作界面,其中包括普通视图、幻灯片浏览视图、幻灯片放映视图。当启动PowerPoint时,系统默认的是普通视图工作方式。
               普通视图。
               普通视图也称为编辑视图。在该视图工作方式下,可进行演示文稿的编辑和制作,如输入文字、绘制图形和插入图片、插入声音和视频、设置动画及切换效果、设置超链接等。普通视图有4个工作区域,如上图所示。
               .大纲/幻灯片工作区:位于窗口的左侧,可通过单击“大纲”选项卡或“幻灯片”选项卡在幻灯片文本大纲或幻灯片缩略图之间切换。
               .主工作区:位于窗口的中部,用于显示和编辑当前幻灯片。
               .任务窗格:位于窗口的右侧,提供常用命令的窗口。主要操作包括创建新演示文稿;选择幻灯片的版式;选择设计模板、配色方案和动画方案;创建自定义动画;设置幻灯片切换等。
               .备注区:位于窗口的下方,用户可以添加备注信息。
               幻灯片放映视图。
               在该视图方式下,可以放映演示文稿中的所有幻灯片。若幻灯片添加了切换效果,则会播放出来;若为幻灯片中的对象设置了动画效果,则在放映时即可展现动画效果。设置的超链接只有在幻灯片放映视图中才有效。
               幻灯片浏览视图。
               在该视图方式下,可以观察演示文稿的全局并了解演示文稿的风格,还可以调整演示文稿的顺序。可以对幻灯片进行选择、复制、删除、隐藏等操作,设置幻灯片的切换效果。
   题号导航      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题    在手机中做本题