题型
1.名词解析 10题
2.简答 5题
3.综合 2题
重点看标记的，了解出小题，理解出小题或者大题，掌握出大题。
结合课本：
2结构化分析的过程
结构化分析的过程可以分为如下4个步骤
- 理解当前的现实环境,获得当前系统的具体模型(物理模型)。
- 从当前系统的具体模型抽象出当前系统的逻辑模型。
- 分析目标系统与当前系统逻辑上的差别,建立目标系统的逻辑模型。
- 为目标系统的逻辑模型作补充。
3.结构化分析模型的描述形式（重点部分，要知道几个图是什么）
结构化分析方法导出的分析模型采用图5.2所示的描述形式。
图5.2中，数据字典是模型的核心，包括对软件使用和产生的所有数据的描述。围绕数据字典有3重图以及相应的规范或描述。
数据流图用于软件系统的功能建模，描述系统的输入数据流如何经过一系列的加工，逐步变换成系统的输出数据流，这些对数据流的加工实际上反映了系统的某种功能或子功能。数据流图中的数据流、文件、数据项、加工都应在数据字典中描述。加工规约是对数据流图中的加工的说明，在结构化方法中用加工的“小说明”作为加工规约。
实体-关系图（E-R图）用于数据建模，描述数据字典中数据之间的关系。数据对象的属性用：”数据对象描述“来描述。通常存放在数据字典中。
状态转换图用于行为建模，描述系统接收哪些外部事件，以及在外部事件的作用下系统的状态迁移（即从一个状态迁移到另一个状态）。
控制规约用来描述控制方面的附加信息。
结构化分析的分析结果包括：一套分层的数据流图、一本数据字典（包括E-R图）、一组加工规约以及其他补充材料（如非功能性需求等）。
5.4数据字典
数据字典和数据流图结合起来构成软件的逻辑模型（分析模型）
5.4.2字典条目（理解）
1.数据流条目（重点）
数据流条目的描述内容如下。
- 名称:数据流名(可以是中文名或英文名).
- 别名：名称的另一个名字。
- 简述:对数据流的简单说明。
- **数据流组成:**描述数据流由哪些数据项组成。
- 数据流去向:描述数据流流入哪个加工或宿。
- 数据量:系统中该数据流的总量,如考务处理系统中“ 名单”的总量是100 000或者单位时间处理的数据流数量,如80000张/天。
- 峰值:某时段处理的最大数量,如每天上午9:00~11:00处理60000张表单。
- 注解;对该数据流的其他补充说明。
其中：
- 别名给出描述对象的另一个名字。通常人们不希望对同一个实体赋予两个不同的名字,这容易引起混淆。但实际开发中,别名也经常出现。例如,当名称用中文表示时,常常将其对应的英文名作为别名;当名称用英文表示时,常常用英文缩写作为别名。还有一种情况,在旧系统的改造过程中,对某个实体名称重新命名,这时旧系统的名称就是新系统中名副其实的别名。对这种情况在必要时可以在数据字典中增加一个“别名条目”
- 峰值是一个与性能相关的信息,例如,对一个每天处理80000张表单的软件来说,并不意味着每小时处理10000张(以一天工作8小时计),可能在每天上午9:00-11:00要处理60000张,在这个时间段里平均每小时要处理30000张。因此该软件应以30000张/小时的处理速度设计系统。
- 数据流组成是数据流条目的核心,它列出组成该数据流的各数据项。现实生活中的数据流是多种多样的,可以用表5.1给出的描述符 来描述数据流的组成。
2.文件条目
文件条目的描述内容如下。
- 名称：文件名。
- 别名：同数据流条目。
- 简述:对文件的简单说明。
- 文件组成:描述文件的记录由哪些数据项组成。
- 写文件的加工:描述哪些加工写文件。
- 读文件的加工:描述哪些加工读文件。
- 文件组织:描述文件的存储方式(顺序、索引),排序的关键字。
- 使用权限:描述各类用户对文件读、写、修改的使用权限。
- 数据量:文件的最大记录个数。
- 存取频率:描述对该文件的读写频率。
- 注解:对该文件的其他补充说明。
其中,文件组成的描述与数据流条目相同。
3数据项条目(重点)
数据项条目的描述内容如下。
- 名称;数据项名。
- 别名:同数据流条目。
- 数据类型:描述数据项的类型,如整型、实型、字符串等。
- 简述:对数据项的简单描述。
- 计量单位:指明数据项值的计量单位,如公斤、吨等。
- 取值范围:描述数据项允许的值域,如1… 100.
- 与其他数据项的关系:描述该数据项与数据字典中其他数据项的关系。
- 注解：对数据项的其他补充说明。
其中,“与其他数据项的关系”可用于对数据的校验。
4加工条目
加工条目的描述内容如下。
- 名称：加工名。
- 别名：同数据流条目。
- **加工 :**加工在DFD中的编 。
- **简述:**对加工功能的简要说明。
- 输入数据流:描述加工的输入数据流,包括读哪些文件。
- 输出数据流:描述加工的输出数据流,包括写哪些文件。
- 加工逻辑:简要描述加工逻辑,或者对加工规约的索引。
- 异常处理:描述加工处理过程中可能出现的异常情况,及其处理方式。
- 加工激发条件:描述执行加工的条件,如“身份认证正确”、“收到 名单”。
- 执行频率:描述加工的执行频率,如每月执行一次、每天0点执行。
- 注解:对加工的其他补充说明。
其中,加工逻辑是加工描述的核心。加工分为基本加工(无DFD子图的加工)和非基加工(有DFD子图的加工),基本加工的加工逻辑用小说明描述(见5.5节),在加工条目中可填写对加工规约的索引。非基本加工分解而成的DFD子图已反映了它的加工逻辑,不书写小说明,可在加工条目中对加工逻辑作简要介绍。
5.源或宿条目
由于源或宿表示系统外的人员或组织,当采用人员或组织的名称作为源或宿的名字时源和宿的含义已经比较清楚了,因此,开发人员常常不将源或宿据字典中、考到字典的完整性,以及便于对DFD和数据字典进行检查,在数据字典中,仍可保留源或宿目,其描述内容如下。
名称:源或宿的名称(外部实体名).
别名:同数据流条目。
简要描述:对源或宿的简要描述(包括指明该外部实体在DFD)中是用作“源”,还是“宿”,还是“既是源又是宿”).
输入数据流:描述源向系统提供哪些输人数据流。
输出数据流:描述系统向宿提供哪些输出数据流。注解:对源或宿的其他补充说明。
6,别名条目
并非所有的别名都要有别名条目,只有那些有必要补充说明的别名才给出相应的别名条目。
- 别名条目的描述内容如下。
- 别名：别名的名字。类型:指出别名属于那个种类(数据流、文件、数据、加工、源或宿).
- 基本名:别名的正式名称(原名)。
- 简述：同正式名称的简述。
- 说明：对别名的补充说明。
第七章面向对象方法基础
7.1面向对象的基本概念（了解，重点）
使用下列等式识别面向对象方法：
面向对象（Object oriented） = 对象（Object） + 分类 （classification）+继承（inheritance）+通过消息的通信（communication with massage）
可以说，采用这4个概念开发的软件系统是面向对象的。
1.对象
在现实世界中,每个实体都是对象,如大学生、汽车、电视机、空调等,都是现实世界中的对象每个对象都有它的属性和操作,如电视机有颜色、音量、亮度、辉度、频道等属性,可以有切换频道、增大/减低音量等操作。电视机的属性值表示了电视机所处的状态,而这些属性值只能通过其提供的操作来改变。电视机的各组成部分,如显像管、印制板、开关等都封装在电视机机箱中,人们不知道也不关心电视机是如何实现这些操作的。
2,类
**类(class)是一组具有相同属性和相同操作的对象的集合。**一个类中的每个对象都是这个类的一个实例(instance),例如,“轿车”是一个类,“轿车”类的实例“张三的轿车”.“条四的轿车”都是对象。也就是说,对象是客观世界中的实体,而类是同一类实体的抽象描述在分析和设计时,人们通常把注意力集中在类上,而不是具体的对象上。人们也不必为每个对象逐个定义,只需对类作出定义,而对类的属性的不同赋值即可得到该类的对象实例,图7.1所示。类和对象之间的关系类似于程序设计语言中的类型(type)和变量(variable)之间的关系。通常把一个类和这个类的所有对象称为类及对象,或称为对象类。
3.继承
一个类可以定义为另一个更一般的类的特殊情况,如“轿车”类是“汽车”类的特殊情况称一般类是特殊类的父类或超类(superclass),特殊类是一般类的子类(subeclass)。例如“汽车”类是“轿车”类的父类,“轿车”类是“汽车”类的子类。同样,“汽车”类还可以是“交工具”类的子类,“交通工具”类是“汽车”类的父类。这样可以形成类的一种一般特殊的5次关系,如图7.2所示。
在这种一般特殊的关系中,子类可以继承其父类(或祖先类)的所有属性和操作,同子类中还可以定义自己特有的属性和操作。所以,子类的属性和操作是子类中的定义部分和其祖先类中的定义部分的总和。
继承是类间的一种基本关系,是基于层次关系的不同类共享属性和操作的一种机制父类中定义了其所有子类的公共属性和操作,在子类中除了定义自己特有的属性和操作外还可以对父类(或祖先类)中的操作重新定义其实现方法,称为重例如,矩看是多边形的子类,在多边形类中定义了属性;顶点坐标序列,x移、旋转.1示、计算面积等。在矩形类中,可定义它自己的属性长和宽,还可以对操作“计算面积”重新定义。
有时,人们定义一个类,这个类把另一些类组织起来,提供一些公共的行为,但并不需要使用这个类的实例,而仅使用其子类的实例。这种不能建立实例的类称为抽象类(abstract class),例如,图7.2中的交通工具就是一个抽象类。通常一个抽象类只定义这个类的抽象·操作,抽象操作是指只定义操作接口,其实现部分由其子类定义。如果一个子类只有唯一一个父类,这个继承称为单一继承。如果一个子类有一个以上的父类,这种继承称为多重继承。如图7.3所示的“水陆两栖交通工具”类既可继承“陆上交通工具”类,又可以继承“水上交通工具”类的特性。
4.消息
**消息(message)传递是对象间通信的手段,一个对象通过向另一个对象发送消息来请求其服务。**一个消息通常包括接收对象名、调用的操作名和适当的参数(如果有必要的话)。消息只告诉接收对象需要完成什么操作,但并不指示接收者怎样完成操作。消息完全由接收者解释,接收者独立决定采用什么方法完成所需的操作。
5,多态性和动态绑定
多态性(polymorphism)是指同一个操作作用于不同的对象上可以有不同的解释,并产·生不同的执行结果。例如,“画”操作,作用在“矩形”对象上则在屏幕上画一个矩形,作用在“圆”对象上则在屏幕上画一个圆。也就是说,相同操作的消息发送给不同的对象时,每个对象将根据自己所属类中定义的这个操作去执行,从而产生不同的结果。
与多态性密切相关的一个概念就是动态绑定(dynamic binding),动态绑定是指在程序运行时才将消息所请求的操作与实现该操作的方法进行连接。传统的程序设计语言的过程调用与目标代码的连接(即调用哪个过程)放在程序运行前(编译时)进行,称为静态绑定,而动态绑定则是把这种连接推迟到运行时才进行。在一般与特殊关系中,子类是父类的一个特例,所以父类对象可以出现的地方也允许其子类对象出现。因此,在运行过程中,当一个对象发送消息请求服务时,要根据接收对象的具体情况将请求的操作与实现的方法进行连接。
第八章 面向对象建模
8.1用况建模（了解，定义）
用况建模是用于描述一个系统应该做什么的建模技术，用况建模不仅用于新系统的需求获取，还可以用于已有系统的升级。
通过开发者和客户之间为导出需求规约而进行的交互过程来建立用况模型。用况模型主要成分有用况、执行者和系统。系统被视为一个提供用况的黑盒，系统如何做，用况如何实现、内部他们如何工作，这些对用况建模都是不重要的。系统的边界定义了系统所具有的功能。功能用用况来表示，每个用况指明了一个完整的功能。用况的主要目标如下：
- 确定和描述系统的功能要求。
- 给出清晰和一致的关于系统做什么的描述。
- 为验证系统所需要的测试提供基准。
- 提供从功能需求到系统的实际类和操作的跟踪能力。
人们可以通过更改用况模型，然后跟踪用况所影响到的系统设计和实现，使系统的修改和扩充简单化。
任何一个涉及系统功能活动的人都会用到用况模型。对客户而言,用况模型指明了系统的功能,描述了系统能如何使用。用况建模时客户的积极参与是十分重要的,客户的参与铁模型能反映客户所希望的细节,并用客户的语言和术语来描述用况。对开发者而言,用况模型帮助他们理解系统要做什么,同时为以后的其他模型建模、结构设计、实现等提供依据。集成测试和系统测试人员根据用况来测试系统,以验证系统是否完成了用况指定的功能。
8.1.1用况建模步骤
- 定义系统
- 确定执行者
- 确定用况
- 描述用况
- 定义用况间的关系
- 确定模型
第九章 基于构件的软件开发
9.1基于构件的软件开发概述
基于构件的软件开发是指使用可复用的构件来开发应用软件的开发方法。通常也称其为基于构件的软件工程(CBSE)。
9.1.1构件（重点，要能写出其中一点定义）
1.定义
目前对构件一次尚无统一的定义，这里给出几种典型的定义。
- Pressman的定义：构件是某种系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某种清晰的功能。
- Brown的定义：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。
- 《计算机科学技术百科全书》中的定义：软件构件是软件系统中具有独立相对功能，可以明确辨识，接口由规约指定，与语境有明显依赖关系，可独立部署，且多由第三方提供的可组装软件实体。软件构件需承载有用的功能，并遵循某一种构建模型。可复用构件是指具有可复用价值的构件。
在基于构件的软件开发中经常会使用到的商用成品构件，是指由第三方开发的满足一定构建标准并且可以组装的软件构件。
2.构件的要素
Brown在其著作中指出,构件具有如下5个要素。
(1)规格说明
规格说明建立在接口概念之上,构件应有一个关于它所提供的服务的抽象描述,作为服务提供方与客户方之间的契约。规格说明应包括定义可用的操作,特殊情况下构件的行为约束条件,以及客户与构件的交互等。
(2)一个或多个实现
一个构件在符合规格说明的前提下,可以有一个或多个实现,例如,不同编程语言或不同算法的实现。构件的实现者可以选择任何一种合适的实现方法,但必须确保其实现是满足规格说明的。必要时,还需按某种构件标准进行包装。
(3)受约束的构件标
准由于实现不同构件的程序语言可能不同,运行环境也可能不同,因此,构件必须符合某种标准,才能支持异质构件间的互操作(访问服务),目前常用的构件标准有Microsoft的CM/DCOM,Sun的EJB和OMG的CORBA.
(4)包装方法
构件可以按不同的方式分组(称为包)来提供一套可替换的服务。通常从第三方获取的构件就是这些包,它们代表了系统中的功能单元。使用包时需要某种对包的注册机制。
(5)部署方法
一个成品构件安装在运行环境中,通过创建构件的可执行实例,并允许与它进行交互来实现部署。一个构件可以部署多个实例,而每一个实例都是独立的,并在自己的进程或线程中执行。
3,构件描述模型
构件模型是关于构件本质特征的抽象描述。目前,学术界与产业界已经提出了许多构件模型,本节介绍3C模型和REBOOT模型。
(1) 3C模型
3C模型是在1989年的Reuse in Practice Workshop中由一些系统工程领域的专家提出的，是关于构件的一个指导性模型。
该模型由构件的3个不同方面的描述组成
(2) REBOOT模型
REBOOT(reuse based on object-oriented technology,基于面向对象技术的复用)构作模型是一种基于刻面(facet)的模型。刻面是在对领域进行分析的基础上得到的一组基本的描述特征。刻面可以描述构件实现的功能、所操作的数据、构件应用的周境或任何其他特征。通常刻面描述限制在不超过7或8个刻面。一个构件通常包括以下刻面。①抽象(abstraction):构件概念的抽象性描述。②操作(operation);构件所提供的操作的描述。③操作对象(operand):描述操作的对象。④依赖(dependency) :描述构件与外界的依赖关系。
4,常用的构件
标准为了将多个构件组装成一个应用系统,支持异质构件间的互操作,软件产业界出现了多种构件标准,其中最常用的构件标准有国际对象管理组织(OMG)的CORBA, MicrosetCOM/DCOM,Sun公司的EJB.
第十章敏捷软件开发
10.1敏捷软件开发方法概述
10.1.3敏捷方法综述（了解，这也是定义。重点）
从20世纪90年代开始，逐渐产生了一大批敏捷软件开发方法。其中比较有影响的包括：极限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发方法、自适应软件开发等。
敏捷软件开发方法具有以下一些共同的特征：
1.致力于降低变化带来的成本
敏捷方法提倡软件开发的适应性，这就意味着能够通过软件过程和方法来降低变更带来的代价。Kent beck认为，可以通过诸如增量和迭代、测试驱动开发、重构、简单设计等手段，”抚平“变更成本的曲线。
2.强调价值
敏捷软件开发关注客户价值，并且强调快速的支付。通过增量和迭代的开发，敏捷软件开发方法可以在早期就交付最有价值、最重要的功能。而不必等到所有的开发完成。
同时，敏捷软件开发基于价值来衡量工作流的各个环节，尽量消除不必要的文档和环节，从而消除开发过程中的浪费。
3.强调人的作用
敏捷方法不仅仅强调适应性，更强调”人的因素“在成功的软件开发中的重要性。软件开发从本质上是从一种创造性的活动，只有充分激发每个人的能动性，才能更好地实现软件开发的目的。而经典的过程模型忽略人和人的差异，这对于充分发挥个人的价值是不利的。敏捷软件开发方法中重视给予团队相应的授权，信任，帮助建立自组织的团队。
4.使用增量和迭代的开发方式
增量和迭代并不是敏捷软件开发的发明。一直以来就存在很多增量和迭代的软件开发模型。但是，敏捷软件开发强调每次迭代都产生真正可以运行的软件，这样更容易获得客户的反馈，便于做出及时的，正确的适应性改变。同时，由于使用增量和迭代的方法，可以在很短的时间间隔内交付软件增量，能够更快的满足客户的需求。
第十一章人界界面设计
11.4.3黄金原则（了解，三条原则需要写出）
1.让用户拥有控制权
用户希望控制计算机，而不是被计算机控制，因此在设计人机界面的时候要遵循以下原则，
(1)交互模式的定义不能强迫用户进入不必要的或不希望的动作的方式
(2)提供灵活的交互
如允许用户通过键盘命令、鼠标移动、语音识别命令等方式进行交互,以适应不同用户的偏好。
(3)允许用户交互可以被中断和撤销
在设计人机界面时,允许用户交互可以被中断和撤销。
(4)当技能级别增长时可以使交互流水化并允许定制交互
用户经常发现他们重复地完成相同的交互序列。设计“宏”机制,使高级用户能定制界面,以方便交互。
(5)使用户隔离内部技术细节
设计应允许用户与出现在屏幕上的对象直接交互。例如,某应用界面允许用户直接操纵屏幕上的某对象(如“拉伸”其尺寸)。
2,减少用户的记忆负担
要求用户记住的东西越多,与系统交互时出错的可能也越大,因此好的用户界面设计不应加重用户的记忆负担。下面是减少用户记忆负担的设计原则。
(1)减少对短期记忆的要求
当用户涉及复杂的任务时,要求很多的短期记忆。界面设计应设法减少需要记住的过去的动作和结果。例如,可以通过提供可视的提示,使用户能识别过去的动作。
(2)建立有意义的默认值
允许用户根据个人的偏爱,定义初始的默认值。例如,设置Reset选项,让用户重定义初始的默认值。
(3)定义直觉性的捷径
当使用助忆符来完成某系统功能时(如用Alt+P激活打印功能),助忆符应以容易记忆的方式(如使用将被激活的任务的第一个字母)联系到相关的动作。
(4)界面的视觉布局应该基于真实世界的隐喻
例如,一个账单支付系统应该使用支票本和支票登记隐喻来指导用户的账单支付过程。这使得用户能依赖已经很好理解的可视提示,而不是记住复杂难懂的交互序列。
(5)以不断进展的方式揭示信息
层次式地组织界面,通过点击感兴趣的界面对象,逐层展开其详细信息。
3,保持界面一致
用户应该以一致的方式展示和获取信息,这意味着:所有可视信息的组织遵循统一的设计标准,所有屏幕显示都遵守该标准。输入机制被约束到有限的集合内,在整个软件系统中被一致地使用,同时从任务到任务的导航机制也被一致地定义和实现。保持界面一致性的设计原则包括以下内容。
(1)允许用户将当前任务放在有意义的语境中
很多界面使用数十个屏幕图像来实现复杂的交互层次,提供指示器(如窗口题目、图形图符、一致的颜色)使用户能知道目前工作的语境。此外,用户应该能确定该任务来自何处以及到某新任务的变迁存在什么选择。
(2)在应用系列内保持一致性
一组应用应该统一实现相同的设计规则,以保持所有交互的一致性。
(3)不要改变用户已经熟悉的用户交互模型
除非有不得已的理由,一旦一个特殊的交互序列已经变成一个事实上的标准(如使用Alt+S来存储文件),则用户在其遇到的每个应用中均是如此期望的。改变其含义将导致混淆,让用户不知所措。
第十三章 软件测试
13.1.2软件测试的基本原则 （理解）
Davis提出了一组指导软件测试的基本原则：
- 所有的测试都应可追溯到客户需求。测试的目的是发现错误，而最严重的错误是那些导致程序无法满足需求的错误。
- 应该在测试工作真正开始前的较长时间就进行测试计划。从现代软件工程的眼光来看，测试计划可以在需求模型完成时就开始，测试用例可以在设计模型确定后立即开始。
- Pareto原则可用于软件测试。即测试中发现的80%的错误可能来自于20%的程序代码。这表明，如果测试模块A时发现的错误比测试模块B时发现的错误多，那么模块A中潜藏的错误可能仍比模块B中潜藏的错误多，此时不能放松对模块A的测试。
- 测试应该从”小规模“开始，逐步转向”大规模“。先测试单个模块，再测试集成的模块簇，最后测试整个系统。
- 穷举测试是不可能的。例如，测试一个包含五个分支的循环程序，其循环次数为20，那么，该程序就有 5 20 5^{20} 520条不同的执行路径，要穷举测试的所有路径是不可能的。
- 为了达到最有效的测试，应由独立的第三方来承担测试。”最有效“指发现错误的测试可能性最高的测试。由于
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！