源于错题
20 文件传输协议（数据）
21 文件传输协议（控制）//安全
23 Telnet终端仿真协议 //moba处理
67 DHCP（服务端）
25 SMTP简单邮件发送协议
53 域名服务器（DNS）
80 超文本传输协议 《HTTP)
110 POP3服务器(邮箱接收服务器
69 简单文件传输协议(TFTP)
68 DHCP(客户端)
161 SNMP(轮询)
162 SNMP《陷阱)
结构化分析方法是一种面向数据流的需求分析方法，其基本思想是自顶向下逐层分解。数据流图是进行结构化分析时所使用的模型，其基本成分
包括数据流、加工、数据存储和外部实体。
在进行结构化设计时，通过对数据流图进行变换分析
和事务分析可以导出程序结构图。
数据库设计可以分为4个主要阶段：
①用户需求分析。数据库设计人员采用一定的辅助工具对应
用对象的功能、性能、限制等要求所进行的科学分析。
②概念设计。概念结构设计是对信息分析和定义，如视图模型化、视图分析和汇总。对应用对象精确地抽象、概括而形成的独立于计算机
系统的企业信息模型。描述概念模型的较理想的工具是E-R图。
③逻辑设计【】。将抽象的概念模型转化为与选用的DBMS产品所支持的数据模型相符合的逻辑模型，它是物理设计的基础。包括模
式初始设计、子模式设计、应用程序设计、模式评价以及模式求精。
④物理设计。逻辑模型在计算机中的具体实现方案
软件评审是软件质量保证的主要活动之-
边界类：边界类用于封装在用例内、外流动的信息或数据流。
边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。
要寻找和定义边界类，可以检查用例模型，每个参与者和用例交互至少要有一个边界类，边界类使参与者能与系统交互。
边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。
常见的边界类有窗口、通信协议、打印机接口、传感器和终端等。
实际上，在系统设计时，产生的报表都可以作为边界类来处理。
边界类用于系统接口与系统外部进行交互，边界对象将系统与其外部环境的变更（例如，与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响。
通常情况下，边界类可以既有属性也有方法。
外部设计处于软件设计的开始阶段，主要是按系
统需求说明来确定此系统的软件结构和对应于系
统需求说明，设计出各个功能部分的功能和接
口。内部设计处于软件工程中的概要设计阶段，
按照外部设计中确立的系统软件结构，来细化此
系统各个功能部件以及各个部件接口的设计，并
且详细给出各个功能部件详细的数据输入、输出
设计。内部设计细化外部设计中的各种功能。
静态分析通过解析程序文本从而识别出程序语句
的各个部分，审查可能的缺陷和异常之处，静态
分析包括【】五个阶段：
控制流分析阶段找出并突出显示那些带有多重出口或入口的循环以及不可达到的代码段；
数据使用分析阶段突出程序中变量的使用情况；
接口分析阶段检查子程序和过程声明及它们使用的一致性；
信息流分析【】阶段找出输入变量和输出变量之间的依赖关系：
路径分析阶段找出程序中所有可能的路径并画出在此路径中执行的语句。
alpha和beta ,dev和prod关系，用户走在？
②
试，通过a测试以后的产品通常称为a版；P测试
是指由用户在实际使用环境下进行测试，通过P
测试的产品通常称为P版。一般在通过P测试后，
才能把产品发布或交付给用户。
维护分为 4 种类型，即排错性维护、适应性维护、完善性维护和预防性维护。
一般在系统运行初期，排错性维护和适应性维护比较多，而到后来，完善性维护和预防性维护就会比较多。
基于UML的需求分析过程【】大致可分为以下步骤
①利用用例及用例图表示需求。从业务需求描述
出发获取执行者和场景；对场景进行汇总、分
类、抽象，形成用例；确定执行者与用例、用例
与用例图之间的关系，生成用例图。
2利用包图和类图表示目标软件系统的总体框架【】
结构。根据领域知识、业务需求描述和既往经验
设计目标软件系统的顶层架构；从业务需求描述
中提取“关键概念”，形成领域概念模型；从概念
模型和用例出发，研究系统中主要的类之间的关
系，生成类图。
可行性研究的主要内容包括经济可行性、技术可行性、法律可行性、执行可行性和方案的选择 5个部分
在大多数情况下，为测试新系统的性能，用户
必须依靠评价程序来评价机器的性能。对于
真实程序、核心程序、小型基准程序和合成基准程序来说，其评测程度依次递减。
结构化分析方法的基本思想是自顶向下，逐层分
解，把一个大问题分解成若干个小问题，每个小
问题再分解成若干个更小的问题。经过逐层分
解，每个最低层的问题都是足够简单、容易解决
的。结构化方法分析模型的核心是数据字典，围
绕这个核心，有三个层次的模型【】，分别是数据模
型、功能模型和行为模型（也称为状态模型）。
在实际工作中，一般使用E-R图表示数据模型【】，
用DFD表示功能模型【】，用状态转换图表示行为模型【】。
这三个模型有着密切的关系，它们的建立不
具有严格的时序性，而是一个送代的过程。
在系统运行过程中，软件需要维护的原因是多样
的。根据维护的原因不同，可以将软件维护分为
以下4种：
①改正性维护。为了识别和纠正软件错误、改正
软件性能上的缺陷、排除实施中的误使用，应当
进行的诊断和改正错误的过程称为改正性维护。
②适应性维护。在使用过程中，外部环境（新的
硬、软件配置）、数据环境（数据库、数据格式、
数据输入/输出方法、数据存储介质）可能发生
变化。为使软件适应这种变化而修改软件的过程
称为适用性维护。
③完善性维护。在软件的使用过程中，用户往往
会对软件提出新的功能与性能要求。为了满足这
些要求，需要修改或再开发软件，以扩充软件功
能、增强软件性能、改进加工效率、提高软件的
可维护性。这种情况下进行的维护活动成为完善
性维护。
④预防性维护。指预先提高软件的可维护性、可
靠性等，为以后进一步改进软件打下良好基础
采用先进的软件工程方法对需要维护的软件或软
件中的某一部分（重新）进行设计、编码和测
对代码的静态测试包括
控制流分析、数据流分析、接口分析和表达式分
析。
①控制流分析。控制流分析是指使用控制流程图
检查被测程序控制结构的过程。例如，可检查被
测程序是否存在没有使用的语句或子程序、是否
调用并不存在的子程序，以及是否存在无法达到的
语句等。
②数据流分析。数据流分析是指使用控制流程图
分析数据各种异常情况的过程，包括数据初始
化、赋值或引用过程中的异常。例如，引用未定
义的变量、对以前未使用的变量再次陆值等程序
差错或异常情况。
③接口分析。接口分析主要包括模块之间接口的
一致性分析、模块与外部数据库及其他软件配置
项之间的一致性分析、子程序和函数之间的接口
一致性分析等。例如可以检查函数形参与实现的
数量、顺序、类型和使用的一致性。
④表达式分析。表达式分析用于检查程序代码中
的表达式错误。例如，括号不配对、数组引用越
界、除数为零，以及浮点数变量比较时的误差等
错误。
面向对象的设计模型包含以包图表示的软件体系
结构图，以交互图表示的用例实现图，完整精确
的类图，针对复杂对象的状态图和用以描述流程
化处理的活动图等。
解析C.相对于自底向上方法，自顶向下方法可以更
快地得到系统的演示原型
ABSD方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类
架构风格解析：批处理，数据整体传递，因为按顺序执行，不能回头，比较好理解。
基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。