免费智能真题库 > 历年试卷 > 信息系统监理师 > 2018年上半年 信息系统监理师 上午试卷 综合知识
  第29题      
  知识点:   面向对象方法   面向对象软件开发
  关键词:   面向对象   软件开发方法   对象   开发   开发方法   软件开发        章/节:   软件与软件工程知识       

 
( )不属于面向对象软件开发方法的特点。
 
 
  A.  自底向上的归纳
 
  B.  线性模式
 
  C.  自顶向下的分解
 
  D.  以对象模型为基础
 
 
 

 
  第24题    2011年上半年  
   56%
统一建模语言UML中用来反映代码的物理结构的是(24)。
  第34题    2017年上半年  
   50%
(34)不是面向对象技术的基本特征。对象实现了数据和操作的结合,使数据和操作(35)于对象的统一体中。
  第3题    2011年上半年  
   42%
面向对象分析与设计技术中,(3)是类的一个实例。
   知识点讲解    
   · 面向对象方法    · 面向对象软件开发
 
       面向对象方法
        在面向对象方法方面,主要考查面向对象的基本概念、数据隐藏、UML和构件等。
                      基本概念
                      面向对象方法包括面向对象的分析、面向对象的设计和面向对象的程序设计。下面首先介绍面向对象方法的一些基本概念。
                             对象
                             在计算机系统中,对象是指一组属性及这组属性上的专用操作的封装体。属性可以是一些数据,也可以是另一个对象。每个对象都有它自己的属性值,表示该对象的状态,用户只能看见对象封装界面上的信息,对象的内部实现对用户是隐蔽的。封装的目的是使对象的使用者和生产者分离,使对象的定义和实现分开。一个对象通常可由三部分组成,分别是对象名、属性和操作(方法)。
                             类
                             类是一组具有相同属性和相同操作的对象的集合。一个类中的每个对象都是这个类的一个实例(instance)。在分析和设计时,通常把注意力集中在类上,而不是具体的对象上。通常把一个类和这个类的所有对象称为类及对象或对象类。
                             一个类通常可由三部分组成,分别是类名、属性和操作(方法)。每个类一般都有实例,没有实例的类是抽象类。抽象类不能被实例化,也就是说不能用new关键字去产生对象,抽象方法只需声明,而不需实现。抽象类的子类必须覆盖所有的抽象方法后才能被实例化,否则这个子类还是个抽象类。
                             是否建立了丰富的类库是衡量一个面向对象程序设计语言成熟与否的重要标志之一。
                             继承
                             继承是在某个类的层次关联中不同的类共享属性和操作的一种机制。一个父类可以有多个子类,这些子类都是父类的特例。父类描述了这些子类的公共属性和操作,子类还可以定义它自己的属性和操作。一个子类只有唯一的父类,这种继承称为单一继承。一个子类有多个父类,可以从多个父类中继承特性,这种继承称为多重继承。对于两个类A和B,如果A类是B类的子类,则B类是A类的泛化。继承是面向对象方法区别于其他方法的一个核心思想。
                             封装
                             面向对象系统中的封装单位是对象,对象之间只能通过接口进行信息交流,外部不能对对象中的数据随意地进行访问,这就造成了对象内部数据结构的不可访问性,也使得数据被隐藏在对象中。封装的优点体现在以下三个方面。
                             (1)好的封装能减少耦合。
                             (2)类内部的实现可以自由改变。
                             (3)一个类有更清楚的接口。
                             消息
                             消息是对象间通信的手段、一个对象通过向另一个对象发送消息来请求其服务。一个消息通常包括接收对象名、调用的操作名和适当的参数(如有必要)。消息只告诉接收对象需要完成什么操作,并不能指示接收者怎样完成操作。消息完全由接收者解释,接收者独立决定采用什么方法来完成所需的操作。
                             多态性
                             多态性是指同一个操作作用于不同的对象时可以有不同的解释,并产生不同的执行结果。与多态性密切相关的一个概念就是动态绑定。传统的程序设计语言把过程调用与目标代码的连接放在程序运行前进行,称为静态绑定。而动态绑定则是指把这种连接推迟到运行时才进行。在运行过程中,当一个对象发送消息请求服务时,要根据接收对象的具体情况将请求的操作与实现的方法连接,即动态绑定。
                             构件
                             构件(组件)是一个功能相对独立的具有可重用价值的软件单元。在面向对象方法中,一个构件由一组对象构成,包含了一些协作的类的集合,它们共同工作来提供一种系统功能。
                             可重用性是指系统和(或)其组成部分能在其他系统中重复使用的程度。软件开发的全生命周期都有可重用的价值,包括项目的组织、软件需求、设计、文档、实现、测试方法和测试用例,都是可以被重复利用和借鉴的有效资源。可重用性体现在软件的各个层次,通用的、可复用性高的软件模块往往已经由操作系统或开发工具提供,如通用库、标准组件和标准模板库等,它们并不需要程序员重新开发。
                      统一建模语言
                      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)流关系。流关系将一个对象的两个版本以连续的方式连接起来。它表示一个对象的值、状态和位置的转换。流关系可以将类元角色在一次相互作用中连接起来。流的种类包括变成(同一个对象的不同版本)和复制(从现有对象创造出一个新的对象)两种。用“”表示。
 
       面向对象软件开发
        面向对象的方法从问题模型开始,然后进行识别对象、不断细化的过程。它从本质上就是迭代和渐增的。开发过程是一次次的迭代反复过程,随着迭代的进行,系统功能不断完善。典型的面向对象开发方法有RUP(Rational Unified Process)和XP(eXtreme Programming),两者各有侧重,适用于不同的场景。
        1.RUP
        RUP是Rational公司开发和维护的过程产品。RUP以适合于大范围项目和机构的方式捕捉了许多现代软件开发过程的最佳实践。RUP的三个关键特征为迭代(Iterative)、以架构为中心(Architecture-Centric)和用例驱动(Use-Case Driven)。
        RUP的6个基本最佳实践如下:
        .迭代式开发。RUP支持专注于处理生命周期中每个阶段中最高风险的迭代开发方法,极大地减少了项目的风险性。
        .需求管理。RUP描述了如何提取、组织和文档化需要的功能和限制。
        .使用基于构件的体系结构。RUP提供了使用新的及现有构件定义体系结构的系统化方法。
        .可视化软件建模。RUP开发过程显示了对软件如何可视化建模,捕获体系结构及构件的构架和行为。
        .验证软件质量。RUP帮助计划、设计、实现、执行和评估软件质量,并且不是事后型的。
        .控制软件变更。RUP开发过程描述了如何控制、跟踪和监控修改以确保成功的迭代开发。
        RUP的二维开发模型
        RUP可以用二维坐标来描述。横轴表示时间组织,是过程展开的生命周期特征,体现开发过程的动态结构,用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone);纵轴按内容组织为自然的逻辑活动,体现开发过程的静态结构,用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow),如下图所示。
        RUP开发过程的各个阶段和里程碑
        RUP中的软件生命周期在时间上被分解为4个顺序的阶段,分别是初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones);每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。
        
        RUP的二维开发模型
        (1)初始阶段。
        初始阶段有时也称为先启阶段,该阶段的主要目标是为系统建立商业模型并确定项目的边界。任务包括识别和规避项目的主要风险,建立用例模型框架,并制订里程碑日期的阶段计划。
        初始阶段结束时是第一个重要的里程碑:生命周期目标(Lifecycle Objective)里程碑。该里程碑评估项目的基本可行性。
        (2)细化阶段。
        细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。为了达到该目标,必须在理解整个系统的基础上,对体系结构做出决策,包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境,包括创建开发案例,创建模板、准则并准备工具。
        细化阶段结束时是第二个重要的里程碑:生命周期结构(Lifecycle Architecture)里程碑。该里程碑为系统的架构建立了管理基准,并使项目小组能够在构建阶段中进行衡量。
        (3)构造阶段。
        在构造阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详细测试。从某种意义上说,构造阶段是一个制造过程,其重点放在管理资源及控制运作以优化成本、进度和质量。
        构造阶段结束时是第三个重要的里程碑:初始操作(Initial Operational)里程碑。该里程碑确定产品是否已经可以部署到Beta测试环境。
        (4)交付阶段。
        交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代,包括为发布做准备的产品测试,基于用户反馈的少量调整。在生命周期的这一点上,用户反馈应主要集中在产品调整、设置、安装和可用性问题上,所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。
        在交付阶段的终点是第四个里程碑:产品发布(Product Release)里程碑。此时,要确定目标是否实现,是否应该开始另一个开发周期。在一些情况下,这个里程碑可能与下一个周期的初始阶段的结束重合。
        RUP的核心工作流
        RUP中有9个核心工作流,分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段,但应注意迭代过程中的阶段是完全不同的,这些工作流在整个生命周期中一次又一次被使用。9个核心工作流在项目中轮流被使用,在每一次迭代中以不同的重点和强度重复。
        (1)商业建模(Business Modeling)。
        商业建模工作流描述了如何为新的目标组织开发一个构想,并基于这个构想在商业用例模型和商业对象模型中定义组织的过程,角色和责任。
        (2)需求(Requirements)。
        需求工作流的目标是描述系统应该做什么,并使开发人员和用户就这一描述达成共识。为了达到该目标,要对需要的功能和约束进行提取、组织、文档化,最重要的是理解系统所解决问题的定义和范围。
        (3)分析和设计(Analysis&Design)。
        分析和设计工作流将需求转化成未来系统的设计,为系统开发一个健壮的结构并调整设计使其与实现环境相匹配,优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象,由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem),而描述则体现了类的对象如何协同工作实现用例的功能。
        (4)实现(Implementation)。
        实现工作流的目的包括以层次化的子系统形式定义代码的组织结构;以组件的形式(源文件、二进制文件、可执行文件)实现类和对象;将开发出的组件作为单元进行测试以及集成由单个开发者(或小组)所产生的结果,使其成为可执行的系统。
        (5)测试(Test)。
        测试工作流要验证对象间的交互作用,验证软件中所有组件的正确集成,检验所有的需求已被正确地实现,识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法,意味着在整个项目中进行测试,从而尽可能早地发现缺陷,从根本上降低了修改缺陷的成本。测试类似于三维模型,分别从可靠性、功能性和系统性能来进行。
        (6)部署(Deployment)。
        部署工作流的目的是成功地生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动,包括软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下,还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
        (7)配置和变更管理(Configuration&Change Management)。
        配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体,跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。
        (8)项目管理(Project Management)。
        软件项目管理平衡各种可能产生冲突的目标,管理风险,克服各种约束并成功交付使用户满意的产品。其目标包括为项目的管理提供框架,为计划、人员配备、执行和监控项目提供实用的准则,为管理风险提供框架等。
        (9)环境(Environment)。
        环境工作流的目的是向软件开发组织提供软件开发环境,包括过程和工具。环境工作流集中于配置项目过程中所需要的活动,同样也支持开发项目规范的活动,提供了逐步的指导手册,并介绍了如何在组织中实现过程。
        2.XP
        极限编程(eXtreme Propgramming,XP)由Kent Beck在1996年开创,是一种演进式的原型化方法,以最大化发挥人的能量为核心目标,具有沟通高效、设计简单、反馈迅速等特点,是一种轻量级、敏捷的过程方法。
        XP是一种高度动态的过程,它通过非常短的迭代周期来应对需求的变化。XP一般适用于需求不确定、变化快、项目历时不超过半年、人数不超过10个、在同一地点工作的中小型团队。
        XP的生命周期包括4个基本活动:编码(coding)、测试(testing)、聆听(listening)、设计(designing)。
        XP的4个价值目标:
        .沟通:让开发人员集体负责所有代码并结队工作,鼓励与客户及团队内部保持沟通。
        .简化:鼓励只开发当前的功能,避免过多的文档,专注于最小化解决方案,做好为新特性改变设计,在系统隐喻和代码规范下不断重构的准备。
        .反馈:通过单元测试和功能测试获得快速反馈。
        .勇气:提倡积极面对现实和处理问题的勇气,拥抱变化。
        XP的12个最佳实践:
        .有计划的开发。通过结合使用标有优先级的“故事”卡和技术估算,确定下一版本的功能。
        .小型发布。以小的增量版本经常向客户发布软件。
        .系统隐喻。隐喻是一个高层次的系统构想,需要不断地细化架构来指导全部开发。
        .简单设计。通过保持代码简单从而保证设计简单。不断地在代码中寻找复杂点并且立刻进行移除。
        .测试驱动。“先测试,后编码”。用户编写测试内容以对“故事”进行测试。程序员编写测试内容来发现代码中的任何问题。在编写代码前先编写测试内容。
        .重构。这是一项简化技术,用来移除代码中的重复内容和复杂之处。
        .结对编程。团队中的两个成员使用同一台计算机开发所有的代码。一个人编写代码或者驱动,另一个人同时审查代码的正确性和可理解性。
        .集体代码所有权。任何人都拥有所有的代码。提高代码透明度,增强团队合作精神。
        .持续集成。每天按任务多次创建和集成系统,随着需求变化,进行不断的回归测试。
        .每周40小时工作制。程序员在疲劳时无法保证最高效率。连续两周加班是绝对不允许的,否则会影响工作效率。
        .现场客户。至少有一名真实的客户全天候工作于开发环境中,帮助定义系统、编写测试内容并回答问题。
        .编码规范。程序员采用统一的编码规范。
   题号导航      2018年上半年 信息系统监理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第29题    在手机中做本题