全部科目 > 软件设计师 >
2014年上半年 下午试卷 案例
第 3 题
知识点 功能需求   面向对象方法   需求分析   需求分析阶段  
 
 
(共15分)
阅读下列说明和图,回答问题1至问题3,将解答填入答题纸的对应栏内。
【说明】
某高校图书馆欲建设一个图书馆管理系统,目前已经完成了需求分析阶段的工作。功能需求均使用用例进行描述,其中用例“借书(Check Out Books)”的详细描述如下。
参与者:读者(Patron)。
典型事件流:
1.输入读者ID;
2.确认该读者能够借阅图书,并记录读者ID;
3.输入所要借阅的图书ID;
4.根据图书目录中的图书ID确认该书可以借阅,计算归还时间,生成借阅记录;
5.通知读者图书归还时间。
重复步骤3-5,直到读者结束借阅图书。
备选事件流:
2a.若读者不能借阅图书,说明读者违反了图书馆的借书制度(例如,没有支付借书费用等)
①告知读者不能借阅,并说明拒绝借阅的原因;
②本用例结束。
4a.读者要借阅的书无法外借
①告知读者本书无法借阅;
②回到步骤3。
说明:图书的归还时间与读者的身份有关。如果读者是教师,图书可以借阅一年;如果是学生,则只能借阅3个月。读者ID中包含读者身份信息。
现采用面向对象方法开发该系统,得到如图3-1所示的系统类模型(部分);以及如图3-2所示的系统操作“checkOut(bookID)(借书)”的通信图(或协作图)。
 
问题:3.1   根据说明中的描述,以及图3-1和图3-2,给出图3-1中C1~C4处所对应的类名(类名使用图3-1和图3-2中给出的英文词汇)。

问题:3.2   根据说明中的描述,以及图3-1和图3-2,给出图3-2中M1~M4处所对应的方法名(方法名使用图3-1和图3-2中给出的英文词汇)。
问题:3.3   用例“借书”的备选事件流4a中,根据借书制度来判定读者能否借阅图书。若图书馆的借书制度会不断地扩充,并需要根据图书馆的实际运行情况来调整具体使用哪些制度。为满足这一要求,在原有类设计的基础上,可以采用何种设计模式?简要说明原因。




 
 
 
知识点讲解
· 功能需求
· 面向对象方法
· 需求分析
· 需求分析阶段
 
        功能需求
        功能需求即网络在用户单位业务中应该提供的功能,可以通过了解用户单位所从事的行业、该单位在行业内的地位以及和其他单位的关系等来确定其功能需求。另外,还可以通过了解项目背景来明确用户单位建网的目的,从而有助于描述详细的功能需求。
 
        面向对象方法
        面向对象方法是当前的主流开发方法,拥有大量不同的方法,主要包括OMT(Object Model Technology,对象建模技术)方法、Coad/Yourdon方法、OOSE(Object-Oriented Software Engineering,面向对象的软件工程)及Booch方法等,而OMT、OOSE及Booch最后统一成为UML(United Model Language,统一建模语言)。
               Coad/Yourdon方法
               Coad/Yourdon方法主要由面向对象的分析(Object-Oriented Analysis, OOA)和面向对象的设计(Object-Oriented Design, OOD)构成,特别强调OOA和OOD采用完全一致的概念和表示法,使分析和设计之间不需要表示法的转换。该方法的特点是表示简炼、易学,对于对象、结构、服务的认定较系统和完整,可操作性强。
               在Coda/Yourdon方法中,OOA的任务主要是建立问题域的分析模型。分析过程和构造OOA概念模型的顺序由5个层次组成,分别是类与对象层、属性层、服务层、结构层和主题层,它们表示分析的不同侧面。OOA需要经过5个步骤来完成整个分析工作,即标识对象类、标识结构与关联(包括继承、聚合、组合及实例化等)、划分主题、定义属性和定义服务。
               OOD中将继续贯穿OOA中的5个层次和5个活动,它由4个部分组成,分别是人机交互部件、问题域部件、任务管理部件和数据管理部件,其主要的活动就是这4个部件的设计工作。
               Booch方法
               Booch认为软件开发是一个螺旋上升的过程,每个周期包括4个步骤,分别是标识类和对象、确定类和对象的含义、标识关系、说明每个类的接口和实现。Booch方法的开发模型包括静态模型和动态模型,静态模型分为逻辑模型(类图、对象图)和物理模型(模块图、进程图),描述了系统的构成和结构。动态模型包括状态图和顺序图。该方法对每一步都做了详细的描述,描述手段丰富而灵活。
               Booch不仅建立了开发方法,还提出了设计人员的技术要求,以及不同开发阶段的人力资源配置。Booch方法的基本模型包括类图与对象图,主张在分析和设计中既使用类图,也使用对象图。
               OMT方法
               OMT作为一种软件工程方法学,支持整个软件生存周期,覆盖了问题构成分析、设计和实现等阶段。OMT方法使用了建模的思想,讨论如何建立一个实际的应用模型。从3个不同而又相关的角度建立了3类模型,分别是对象模型、动态模型和函数模型,OMT为每一个模型提供了图形表示。
               (1)对象模型。描述系统中对象的静态结构、对象之间的关系、属性和操作。它表示静态的、结构上的、系统的“数据”特征。主要用对象图来实现对象模型。
               (2)动态模型。描述与时间和操作顺序有关的系统特征,如激发事件、事件序列、确定事件先后关系的状态。它表示瞬时、行为上的和系统的“控制”特征。主要用状态图来实现动态模型。
               (3)函数模型。描述与值的变换有关的系统特征,包括功能、映射、约束和函数依赖。主要用数据流图来实现功能模型。
               在进行OMT建模时,通常包括4个活动,分别是分析、系统设计、对象设计和实现。
               (1)分析:建立可理解的现实世界模型。通常从问题陈述入手,通过与客户的不断交互及对现实世界背景知识的了解,对能够反映系统的3个本质特征(对象类及它们之间的关系,动态的控制流,受约束的数据的函数变换)进行分析,构造出现实世界的模型。
               (2)系统设计:确定整个系统的体系结构,形成求解问题和建立解答的高层策略。
               (3)对象设计:在分析的基础上,建立基于分析模型的设计模型,并考虑实现细节。其焦点是实现每个类的数据结构及所需的算法。
               (4)实现:将对象设计阶段开发的对象类及其关系转换为程序设计语言、数据库或硬件的实现。
               OOSE
               OOSE在OMT的基础上,对功能模型进行了补充,提出了用例(use case)的概念,最终取代了数据流图来进行需求分析和建立功能模型。
               OOSE方法采用5类模型来建立目标系统。
               (1)需求模型:获取用户的需求,识别对象,主要的描述手段有用例图、问题域对象模型及用户界面。
               (2)分析模型:定义系统的基本结构。将分析模型中的对象分别识别到分析模型中的实体对象、界面对象和控制对象三类对象中。每类对象都有自己的任务、目标并模拟系统的某个方面。实体对象模拟那些在系统中需要长期保存并加以处理的信息。实体对象由使用事件确定,通常与现实生活中的一些概念相符合。界面对象的任务是提供用户与系统之间的双向通信,在使用事件中所指定的所有功能都直接依赖于系统环境,它们都放在界面对象中。控制对象的典型作用是将另外一些对象组合形成一个事件。
               (3)设计模型:分析模型只注重系统的逻辑构造,而设计模型需要考虑具体的运行环境,即将分析模型中的对象定义为模块。
               (4)实现模型:用面向对象的语言来实现。
               (5)测试模型:测试的重要依据是需求模型和分析模型,测试的方法与9.8节所介绍的方法类似,而底层是对类(对象)的测试。测试模型实际上是一个测试报告。
               OOSE的开发活动主要分为3类,分别是分析、构造和测试。其中分析过程分为需求分析和健壮性分析两个子过程,分析活动分别产生需求模型和分析模型。构造活动包括设计和实现两个子过程,分别产生设计模型和实现模型。测试过程包括单元测试、集成测试和系统测试三个过程,共同产生测试模型。
               用例是OOSE中的重要概念,在开发各种模型时,它是贯穿OOSE活动的核心,描述了系统的需求及功能。用例实际上是描述系统用户(使用者、执行者)对于系统的使用情况,是从使用者的角度来确定系统的功能。因此,首先必须分析确定系统的使用者,然后进一步考虑使用者的主要任务、使用的方式、识别所使用的事件,即用例。
 
        需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (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)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
 
        需求分析阶段
        . 确定软件的可靠性目标;
        . 分析可能影响可靠性的因素;
        . 确定可靠性的验收标准;
        . 制定可靠性管理框架;
        . 制定可靠性文档编写规范;
        . 制定可靠性活动初步计划;
        . 确定可靠性数据收集规范。



更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2025 All Rights Reserved
软考在线版权所有