系统分析师每日练习错题知识点1

软件工程---逆向工程

1. 实现级：包括程序的抽象语法树、符号表等信息
2. 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图等
3. 功能级：包括反映程序段功能以及程序段之间关系的信息。
4. 领域级：包括反映程序分量或程序实体与应用领域概念之间的对应关系的信息

   

需求工程---需求验证：

需求是软件项目成功的核心所在，它为其他许多技术和管理活动奠定基础，在软件需求工程中，需求管理贯穿整个过程。需求管理最基本的任务是明确需求、并且使项目团队和用户达成共识，即建立需求基线。

软件工程---需求工程：

需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。而非对需求开发的管理，需求开发包括：需求获取、需求分析、需求定义和需求验证。需求的跟踪属于需求管理的范畴

软件工程---需求获取

若想获取用户对系统的想法和建议等定性特征，则开调查会方法比较合适，因为开调查会的方式会强调需求分析人员与用户之前的交互，在交互过程中可以获取用户对系统的想法和建议。

若想获取系统某些较为复杂的流程和操作过程，则现场观摩方法比较合适，俗话说，“百闻不如一见”，对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户的讲解，从而更直观的了解客户需求。

软件工程---需求工程：

在结构化分析中，主要进行三个方面的建模：

1. 功能建模：一般采用DFD
2. 行为建模：一般采用状态转换图
3. 数据建模：一般采用E-R图

   

需求分析---UML

UML中有4种事物：

1. 结构事物是UML模型中的名词，他们通常是模型的静态部分，描述概念或物理元素；
2. 行为事物是UML模型的动态部分，他们是模型中的动词，描述了跨越时间和空间的行为；
3. 分组事物是UML模型的组织部分，它们是一些由模型分解成“盒子”
4. 注释事物是UML模型的解释部分，这些注释事物用来描述、说明和标注模型的任何元素

   

需求工程---UML

在UML中，把组织模型的组块称为包。包是用于把元素组织的通用机制，有助于组织模型中的元素，使得对他们的理解变得更容易，也使得用户能够控制对包的内容的访问，从而控制系统体系结构中的接缝

构件是系统中遵从一组接口且提供实现的物理的、可替代的部分，可以利用构件为可能存在于结点上的物理事物（如可执行体、库、表、文件以及文档等）进行建模。一般情况下，构件表示将类、接口和协作等逻辑元素打包而形成的物理模块。好的构件应采用定义良好的接口来定义灵活的对象，以便将来可以用更新的、且接口兼容的构件来替换较旧的构件。

需求工程---UML

定时图：是一种新增的、特别适合实时嵌入式系统建模的交互图，也称为计时图，计时图关注沿着线性时间轴、生命线内部和生命线之间的条件改变。它描述对象状态随着时间改变的情况，很像示波器，适合分析周期和非周期性任务。定时图强调消息快约不同对象或参与者的实际时间，而不仅仅关心消息的相对顺序。

通信图：强调收发消息的对象结构组织，在早期的版本中也被称为协作图。它强调参加交互的对象组织

交互概览图是UML2.0新增的交互图之一，是活动图的变体，描述业务过程中的控制流概览，软件工程中的详细逻辑概览，以及将多个图进行连接，抽象掉了消息和生命线。

序列图是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动。

需求工程---UML

UML采用4+1视图来描述软件和软件开发过程，其中的4个视图分别是：

1. 逻辑视图：用来描述所设计的静态、动态对象模型
2. 进程视图：用来描述所设计的并发与同步结构
3. 实现视图：用来描述软件在开发环境中的静态结构
4. 部署视图：表示软件到硬件的映射以及分布结构
5. UML中的类图可以用来表示其中的逻辑视图

   

需求工程---需求分析：

面向对象的分析是基于用例模型，通过对象建模记录确定的对象、对象封装的数据和行为以及对象之间的关系。面向对象分析包括三个活动：

1. 建模系统功能
2. 发现并且确定业务对象
3. 组织对象并确定其关系

   

需求工程---需求分析：

根据需求分析的定义：

需求分析是一种软件工程活动，它在系统级软件分配和软件设计间起到桥梁作用。需求分析使得系统工程师能够刻画出软件的功能和性能、指明软件和其他系统元素的接口、并且建立软件必须满足的约束。

需求分析的任务是发现、求精、建模和规约的过程。包括详细地精化初始由系统工程师建立并在软件项目计划中精化的软件范围，创建所需数据、信息和控制流以及操作行为的模型，此外还有分析可选择的解决方案，并将他们分配到各个软件元素中。

框架是类库的一种扩展形式

软件工程---软件设计

软件设计包括体系结构设计、接口设计、数据设计和过程设计

1. 结构设计：定义软件系统各主要部件之间的关系。
2. 数据设计：将模型转换成数据结构的定义，好的数据设计将改善程序结构和模块划分，降低过程复杂性
3. 接口设计（人机界面设计）：软件内部，软件和操作系统间以及软件和人之间如何通信
4. 过程设计：系统结构部件转换成软件的过程描述。

系统设计---处理流程设计

1. 工作流执行服务
2. 工作流引擎
3. 客户端应用
4. 调用应用
5. 管理监控工具

系统设计---结构化设计

一个模块的扇出是指模块直接调用下级模块的个数，扇出大表示模块的复杂度高，需要控制和协调过多的下级模块。

扇出过大一般是因为缺乏中间层次，应当适当增加中间层次的控制模块；

扇出过小时可以把下级模块进一步分解若干个子功能模块，或者合并到它的上级模块中去。

一个模块的扇入是指直接调用该模块的上级模块的个数

扇入大表示模块的复用程度高。设计良好的软件结构通常顶层扇出表大，中间扇出比较小，底层模块则有大扇入

软件模块内部的内聚程度从高到低排序为：

1. 功能内聚：完成一个单一的功能，各个部分协同工作，缺一不可
2. 顺序内聚：处理元素相关，而且必须顺序执行
3. 通信内聚：所有处理元素集中在一个数据结构的区域上
4. 过程内聚：处理元素相关，而且必须按特定的次序执行
5. 瞬时内聚（时间内聚）：所包含的任务必须在同一时间间隔内执行
6. 逻辑内聚：完成逻辑上相关的一组任务
7. 偶然内聚：完成一组没有关系或者松散关系的任务

需求工程：UML

用例之间有三种关系：包含（include）、扩展（extend）、继承（generalize）。

当两个用例之间具有继承关系时，以为者子用例可以继承父用例的行为，并可以在此基础上添加新的行为或重置父用例的行为，子用例可以出现在父用例出现的任务位置上。

软件架构设计---软件架构风格

1. 架构模式是软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策；
2. 设计模式主要关注软件系统的设计，与具体的实现语言无关；
3. 惯用法则是实现时通过某种特定的程序设计语言来描述构件与构件之间的关系，例如引用---计数就是C++语言中的一种惯用法。

   

软件工程---设计模式

设计模式可以分为三种：

1. 创建型模式：主要用于创建对象，为设计类实例化新对象提供指南；

1. 1. 工厂方法（factory Method）：定义一个创建对象的接口，但由子类决定需要实例化哪一个类，工厂方法使得子类实例化的过程推迟（动态生产对象）
   2. 抽象工厂模式（Abstractory Factory）：提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类（生产系列对象）
   3. 构建器模式（Builder）：将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示（复杂对象构造）
   4. 原型模式（Prototype）：用原型实例制定创建对象的类型，并且通过拷贝这个原型来创建新的对象（克隆对象）
   5. 单例模式（Singleton）：保证一个类只有一个实例，并且提供一个访问它的全局访问点（单实例）

1. 结构型模式：主要用于处理类或对象之间的组合，对类如何设计以形成更大的结构提供指南；（适配器模式（Adapter）、桥接模式（bridge）、组合（composite）、装饰（decorator）、外观（facade）、享元模式（flyweight）、代理模式（proxy））
2. 行为型模式：主要用于描述类或对象的交互以及职责的分配，对类之间交互以及分配责任的方式提供指南（ 责任链模式（chain of responsibility）、命令模式（command）、解释器模式（interpreter）、迭代器模式（iterator）、中介者模式（mediator）、备忘录模式（memento）、观察者模式（observer）、状态模式（state）、策略模式（strategy）、模板方法（template method）、访问者模式（visitor））

软件工程---设计模式

1. 抽象工程模式（abstract factory）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类
2. chain of responsilility（责任链模式）：为解除请求的发送者和接收者之间的耦合，而使用多个对象都有机会处理这个请求。将这些对象连成一条链，并且沿着这条链传递该请求，直到有一个对象处理它。
3. 组合模式（componsite）：将对象组合成树形结构以表示“部分---整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性
4. 装饰模式（Decorator）：动态地给一个对象添加一些额外的职责。就扩展而言，它比生成子类方式更为灵活。

IPSec提供即可用于IPv4也用于IPv6的安全性机制，它是IPv6的一个组成部分，也是IPv4的一个可选扩展协议。

IPsec为跨越LAN/WAN，Internet的通讯提供安全性：

1. 分支办公机构通过Internet互连（Secure VPN ）
2. 通过Internet的远程访问
3. 与合作伙伴建立Extranet与Internet的互连
4. 增强电子商务的安全性

IP安全性协议是针对IPv4和IPv6的，IPsec的主要特征是可以支持IP级所有流量的加密或者认证，增强所有分布式应用的安全性。IPSec在IP层提供安全服务，使得系统可以选择所需要的安全协议，确定该服务所用的算法，并且提供安全服务所需任何加密秘钥

目前的全球因特网所采用的协议族是TCP、IP协议族。IP是TCP、IP协议族中网络层的协议，是TCP、IP协议族的核心协议。目前IP协议的版本号是4（简称为IPv4），发展至今已经使用了30多年了。IPv4地址位数为32位，也就是最多是2的32次方的电脑可以连接到Internet。

IPv6是下一个版本的互联网协议，也可以说是下一代互联网的协议，它的提出最初是因为随着互联网的迅速发展，IPv4定义的有限地址空间将被耗尽，地址控制的不足必将妨碍互联网的进一步发展。为了扩大地址空间，逆通过IPv6重新定义地址空间。IPv6采用的128位地址长度，几乎可以不受限制地提供地址。按保守方法估算IPv6实际可以分配的地址，整个地球的每平方面积仍可分配1000多个地址。在IPv6的设计过程中除了一劳永逸地解决了地址短缺问题以外，还考虑在IPv4中解决不好的其他问题，主要端到端IP连接，服务质量、安全性、多播、移动性、即播即用等。

信息安全---其他

业务流分析属于信息安全威胁的一种，它通过对系统进行长期监听，利用统计分析方法诸如通信频度、通信的信息流向、通信总量的变化等参数进行研究，从中发现有价值的信息规律

信息安全---其他

作为全方位的、整体的系统安全防范体系也是分层次的，不同层次反映了不同的安全问题，根据网络的应用现状结构，可以将安全防范体系的层次划分为物理安全、系统安全、网络安全、应用层安全和安全管理。

1. 物理环境的安全性：物理层的安全包括通信线路，物理设备和机房的安全等。物理层的安全主要体现在通信线路的可靠性（线路备份、网关软件和传输介质）、软硬件设备和安全性（替换设备、拆卸设备、增加设备）、设备的备份、防灾害能力、防干扰能力、设备的运行环境（温度、湿度、烟尘）和不间断电源保障。
2. 操作系统的安全性。系统层的安全问题来自计算机网络内使用的操作系统的安全，例如说windows server和Unix等，主要表现在三个方面，一个是操作系统本身的缺陷带来的不安全因素，主要包括身份认证、访问控制和系统漏洞等；二是读操作系统的安全配置问题；三是病毒对操作系统的威胁。
3. 网络的安全性。网络层的安全问题主要体现在计算机网络方面的安全性，包括网络层的身份认证、网络资源的访问控制、数据传输的保密与完整性、远程接入的安全、域名系统的安全、路由系统的安全、入侵检测的手段和网络设施防病毒等
4. 应用的安全性，应用层的安全问题主要由提供服务所采用的应用软件和数据的安全性产生，包括Web服务、电子邮件系统和DNS等。此外，还包括病毒对系统的威胁
5. 管理的安全性，安全管理包括安全技术和设备的管理、安全制度管理、部门与人员的组织规则等。管理的制度化极大程度低影响着整个计算机网络的安全，严格的安全管理制度、明确的部门安全职责划分与合理的人员角色配置，都可以在很大程度上降低其他层次的安全漏洞。

项目管理---范围管理

在初步项目范围说明书中已文档化的主要的可交付物、假设和约束条件的基础上准备详细项目范围说明书，是项目成功的关键，范围定义的输入包括如下内容：

1. 项目章程，如果项目章程或初始的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以生产详细的项目范围说明书。
2. 项目范围管理计划
3. 组织过程资产
4. 批准的变更申请

项目管理---时间管理---时间管理的过程包括

1. 活动定义
2. 活动排序
3. 活动的资产估算
4. 活动历时估算
5. 制定计划
6. 进度控制

项目管理---时间管理

通过绘图找最长路径可知：

关键路径为：ADFH，长度为13，所以项目的工期为13周。

当C拖延3周之后，关键路径变为：ACEH，长度为15周，所以工期拖延2周

项目管理---软件配置管理

配置项式构成产品配置的主要元素，配置项主要有一下两个大类：

1. 属于产品组成部分的工作成果：如需求文档、设计文档、源代码和测试用例等
2. 属于项目管理和机构支撑过程域产生的文档：如工作计划、项目质量报告和项目跟踪报告等。这些文档虽然不是产品的组成部分，但是值得保存。

非网络知识---软件开发基础

1. 动态测试是指通过运行程序发现错误，分为黑盒测试法、白盒测试法和灰盒测试法。常用的黑盒测试用例的设计方法有等价类划分、边界值分析等等。常用的白盒测试用例设计方法有基本路径测试、循环覆盖测试、逻辑覆盖测试。
2. 静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态分析中进行人工测试的主要方法有桌面检测（程序员自查）、代码审查和代码走查。

软件工程---软件测试

驱动模块是用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启用被测模块，并且打印相应的结果。

桩模块（stub）是指模拟被测试的模块所调用的模块，而不是软件产品的组成部分。主模块作为驱动模块，与之直接相连的模块用桩模块代替。在集成测试前要被测模块编制一些模拟其下级模块功能的替身模块，以代替之直接相连的模块用桩模块代替。在集成测试前要被测模块一些模拟其下级模块功能的替身模块，以代替被测模块的接口，接收或传递被测模块的数据，这些专供测试用的假模块称为被测模块的桩模块。

软件工程---软件测试

根据测试目的不同，性能测试 主要包括压力测试、负载测试、并发测试和可靠性测试等

1. 强度测试：是在系统资源特别低的情况下考查软件系统极限运行的情况
2. 负载测试：用于测试超负荷环境中程序是否能够承担，确定在各种工作负载下系统的性能，测试当负载逐渐增加时，系统各项性能指标的变化情况
3. 压力测试：通过确定系统的瓶颈不能接收的性能点，来获得系统能够提供的最大服务级别的测试。负载测试和压力测试可以结合进行，统称为负载压力测试。
4. 容量测试：并发测试也称为容量测试，主要用于测试系统可同时处理的在线最大用户数量。

软件的维护并不只是修正错误，为了满足用户提出的增加新功能，修改现有功能以及一般性的改进要求和建议，需要进行完善性维护，它是软件维护工作的主要部分；软件测试不可能揭露旧系统中所有潜在的错误，所以这些程序在使用过程中还可能发生错误，诊断和更正这些错误的过程称为改正性错误；为了改进软件未来的可维护性或可靠性，或者为了给未来的改进提供更好的基础而对软件进行修改，这类活动称为预防性维护。