系统架构设计师考试

第 一章 系统架构设计师考试介绍

第二章 计算机组成原理与体系结构

Flynn 分类法

CISC与RISC

流水线技术

存储系统

校验码

并行处理

1.计算机体系结构分类-Flynn

体系结构类型 结构 关键特性 代表

单指令流单数据流SISD 控制部分:一个

处 理 器:一个

主存模块:一个 单处理器系统

单指令流多数据流SIMD 控制部分:一个

处 理 器:多个

主存模块:多个 各处理器以异步的形式执行同一条指令 并行处理机

阵列处理机

超级向量处理机

多指令流单数据流MISD 控制部分:多个

处 理 器:一个

主存模块:多个 被证明不可能,至少是不实际 目前没有,有文献称流水线计算机为此类

多指令流多数据流MISD 控制部分:多个

处 理 器:多个

主存模块:多个 能够实现作业、任务、指令等各级全面并行 多处理机系统

多计算机

考题:

哪一种体系结构?

哪种体系类型不具备哪种特色、特征,哪些系统是属于哪些特性及特征?

2.CISC与RISC

指令系统类型 指令 寻址方式 实现方式 其它

CISC(复杂) 数量多,使用频率差别大,可变长格式 支持多种 微程序控制技术(微码) 研制周期长

RISC(精简) 数量少,使用频率接近,定长格式,大部分为单周期指令,操作寄存器,只有Load、store操作内存 支持方式少 增加了通用寄存器;硬布线逻辑控制为主;合适采用流水线 优化编译,有效支持高级语音

考题:

CISC与RISC 的描述,选择哪个说法正确、错误或两个的特点

掌握两个指令类别的区别;

CISC是在计算机没有大量的使用的时候提出来的。

3.层次化存储结构

1. 了解存储结构

2. Cache相关的知识

3. 内存掌握的知识

存储结构

1. 基本层次是怎么划分的?

2. 哪些存储器性能比较好的?

3. 哪些存储器容量比较大的?为什么要以这样的层次来组织存储体?

速度最快,效率最高的是寄存器,寄存器在什么地方呢,存在CPU当中,在CPU当中会有运算器、控制器,运算器、控制器当中会有寄存器,寄存器的容量是极小的,但速度极快,所以它是存储最高层顶层的。

Cache 是高速缓存存储器 (按内存存取) k 字节 /M 兆

内存(主存) G

外存(辅存) 包括硬盘、光盘、U盘等

基于性价比考虑

在整个体系存储结构中不同的存储器各有优势,速度极快,往往容量小的;容量大的,速度相对较慢,这是基于性价比考虑;如果所有的存储器都做成寄存器或则cache速度级别的,成本是难以接受的;反之,用外存存储器的,速度又跟不上;cpu 和外存储器速度相差好多倍,这样就出现多极;

Cache 存储的内容均来自内存(主存),所以Cache当中是存储主存当中的一部分内容。量相当小,k、M、 G

当加上极小的Cache,速度提升十倍、百倍、千倍;

为什么会有这样的情况?

之所以有这样情况,有了局部性原理存在,什么是局部性原理? 就是我们程序运行当中,执行完某一条指令,很可能再次执行,会频繁去执行相同块里面的内容,这称之为时间的局部性。如循环语句,输出的就是初始值和结果,循环当中就可以放到Cache执行,这样就是CPU和Cache 频繁交互,不和内存交互,这样速度就极大的提升了。

外存与内存也是这样的过程。要运行的东西,外存的东西都调到内存。

以上内容: 为什么要按这样的层次去处理,引用Cache目的是什么,它是一种性价比方案,提高速度同时,没有增加多少成本,Cache有个显著特色是按内存存取,存储信息,我们就会考虑信息的内容,不同的内容就存在不同的区域,当要读取区域块的内容出来的时候,通过内容一算,就知道内容存在哪一个块当中,按内容存储器,也叫相连存储器,速度效率会远高于按地址存储方式。

4.Cache- 概念

Cache 工作于cpu和主存之间,为了提高访问速度而提出来的,寄存器容量极小且集成在CPU中;

运行速度最快的,如果没有提供寄存器的,就选择Cache;

引入cache如何计算使用cashe+主存储器梯度式层次型的存储体系的存取的平均周期时间。

公式怎么使用?

h 代表对cache的访问命中率;

t1表示cache的周期时间;

t2表示主存储器周期时间;

以读取作为列,使用cache+主存储器 的系统的平均周期为t3

公式: t3 = h *t1+(1-h)*t2

(1-h) 称为失效率(未命中率)

假设:

t1 =1nm

t2 = 1ms =1000ns

h =95%

命中率说明: CPU处理数据的时候,首先会考虑从Cache获取数值,需要从cache得到的数值,就称为命中;如果CPU获取Cache没有需要的数据,则去内存获取。CPU获取Cache等到需要的数据的h就是cache的访问命中率。

公式: t3 = h *t1+(1-h)*t2

1ns *95%+(1-95%)*1000ns

0.95+0.05*1000= 50.95ns

5.局部性原理

局部性原理:计算机在处理相关数据和程序的时候,一般会有一时段集中的去访问某些指令,或则某些时段去读取某些空间的数据;这样的特性,把这样的特性拉出来研究,基于它对于我们采用多层级存储体系来解决量和速度的矛盾的解决方案

时间局部性(Temporal Locality):如果一个信息项正在被访问,那么在近期它很可能还会被再次访问。程序循环、堆栈等是产生时间局部性的原因。

空间局部性(Spatial Locality):在最近的将来将用到的信息很可能与现在正在使用的信息在空间地址上是临近的。如:数组

6.随机存储器与只读存储器

随机存储器 ram 断电及丢失;

只读存储器 rom 断电仍存在;

主存-编址

主存编址把芯片主存相应的存储器。

8*4位的存储器代表 8代表8个地址空间,每个空间存储4位数;

7.磁盘工作原理

磁盘结构与参数

1、磁盘运作的原理,读取一次数据,磁盘需要做什么,消耗哪方面的时间?

软盘、硬盘(机械硬盘)不包含固态硬盘;

磁盘用的是环形的盘片,上面涂上特殊的材质来保存数据,盘面用来存储数据,读取数据必须用专业的设备,就是磁头,读取信息,将磁头定位到磁道上面,需要时间,称为寻道时间;旋转时间,也叫等到时间

存取时间 = 寻道时间+等待时间(平均定位时间+转动延迟)

注意:寻道时间是指磁头移动到磁道所需的时间,等待时间为等待读写的扇区到磁头下方所用的时间。

机械硬盘,固态硬盘具有读写速度快,运行安静等优点,而缺点主要就是价格太高,损坏后数据难以恢复。

答案: c 、b

解析:单缓存区

8.流水线-概念

9.流水线周期及流水线执行时间计算

考点:流水线的问题,流水线时长的问题。

10.流水线吞吐率计算

11、流水线加速比计算

完成同样一批任务,不使用流水线所用的时间与使用流水线所用的时间只比称为流水线加速比。 公式如下:

S = 不使用流水线所用的时间 除以 使用流水线所用的时间

(2+2+1)*100=500

(2+2+1)+99*2=203

S= 500 除以 203

加速比越高越好。

第八章 软件工程

1、信息系统开发方法: 结构化法、原型法、面向对象方法、面向服务方法;

1. 1.1 结构化方法

2. 用户至上

3. 严格区分工作阶段,每个阶段有任务与成果

4. 强调系统开发过程的整体性和全局性

5. 系统开发过程工程化,文档资料标准化

6. 自顶向下,逐步分解(求精)

最大问题:系统和现实有较大的差异,开发完,它的流程是固态的,不灵活的;

1.2 原型法

1. 适用于需求不明确的开发

2. 包括抛弃式原型和演化式原型

补充了结构化方法,结构化方法典型代表瀑布模型就有重大的缺陷,而原型法就弥补了这个缺陷;

原型法就是做个简易的界面,不能运行的,原型直接看需求更直观,原型包括抛弃式原型和演化式原型;

1.3 面向对象方法

1. 更好的复用性

2. 关键在于建立一个全面、合理、统一的模型

3. 分析、设计、实现三个阶段,界限不明确

开发系统之前,有些人抽象为对象,一个对象和另一个对象由属性来区分,一个对象和另一个对象里的操作方法,能干什么,写成方法;这样就更好的复用性;对象在这个系统里面把它创建出来,在另一个系统里面,也可以复用部分的对象;分析、设计、实现三个阶段,界限不明确。

1.4 面向服务方法

了解

2、软件开发模型

软件开发模型是软件开发的一种指导思想、开发体系;

瀑布模型,有缺陷,十有八九会失败,失败的体现在,要么延期、成本超支、要么根本做不下去,

软件计划-->需求分析-->软件设计-->编程代码-->软件测试-->运行维护

每个结尾都有软件评审工作;评审相关步骤的产出物是否符合相关要求;强调文档化,标准化,瀑布模型是结构化方法的模型;后来改进瀑布模型加了一个回溯的通道,阶段末尾或下个阶段遇到问题,可以回到上个阶段,把问题解决了再到下个阶段;

看起来很不错,为什么说十有八九会失败呢?

原因在需求阶段难以把控,软件初期阶段往往是不明确的,初期把所有的需求弄明确几乎不可能,把我们认为就是客户想要的东西,从软件设计-->编程代码-->软件测试-->运行维护 等给用户使用的时候,客户就会提出,这个不行那要改,这个和我们思路想要的不一样,这样就要从需求要改,在一路需改下来,

瀑布模型:需求明确或二次开发,大部分需求稳定,否则不适合;

总结: 瀑布模型是结构化方法、适合需求明确或二次开发。

3、原型模型、演化模型、增量模型

原型是瀑布模型相当互补的模型,瀑布模型的缺陷就是在应对业务需求变化,没有灵活的应对,无法把握需求所以导致后面问题的产生;

原型模型诞生,就定位在业务需求不明确的情况下;无论和用户详细沟通需求,客户都很难把他需求表达明确、全面;原因就是用户也不知道想要什么样的系统,客户和团队开发有一定的隔阂,隔阂的在于双方的领域不一样,开发人员知道的是技术,客户知道的是业务层面的东西;所以在沟通时,有些理解不一致的内容,导致后面开发出现系列的问题

原型法是怎么做的呢?

项目初期开发一个简易的系统,简易可以是一个界面,系统开发完之后是什么的样子,在哪里显示什么按钮,点击什么按钮会产生什么现象,界面式的原型,没有功能支持,也是可以是一个简易的系统出来,给客户看看、用用,

演化模型

客户使用发现问题,我们一一记录,再调整这个简易系统,经过多轮的沟通修改,就知道客户想要什么样的系统,这样客户也有个心理预期,系统开发出来是什么样子的,

简易系统比较低的成本获取比较全面准确的客户需求的信息,原型法只是适用于开发之前的需求分析阶段,如果将初步的原型经过演化成最终产品就成演化模型(从简易的系统转化成最终的产品)

增量模型

什么思路,客户有多种多样的需求,核心模块是哪个模块的,先把核心模块开发,这个周期可能只有项目的20%的时间;给客户先用,有问题题则修改,下个月再开发下个模块,不断的开发一个一个模块,这样就减少了风险;

原型法,主要构造一个简易的系统,且是需求不明确的情况;

4、螺旋模型

螺旋模型,融合多种模型特征,原型、瀑布模型,最显著的特征是引入了风险分析;

题目考试:有不明确的项目,选择有开发模型,有原型、有螺旋模型

有遵行的是最匹配的原则,只能选择原型。

5、V模型

V模型和瀑布模型有些相似,

特点:

5.1 V模型将测试提高到更重要的地位,V模型细化到单元测试、集成测试、系统测试、验收测试,而不是瀑布模型就用一个测试来替代;

5.2 需求分析与验收测试有着对应的关系,在需求分析阶段我们就去写验收测试和系统测试的测试计划,为什么? 就是为了提早发现问题;而瀑布模型把测试压到尾端有什么不好呢?当发现问题想去改正不好去更改;要修改需要从需求分析开始改起,消耗的成本过高;如果我们从需求分析阶段来写验收测试计划,会从测试的眼光来看待问题,就能必能发现需求当中产生的问题;

5.3 概要设计阶段会去写集成测试的测试计划,概要设计主要是概要的模块的划分,集成测试的就是概要模块的衔接,也会发现模块化分衔接的问题;

5.4 详细设计阶段回去写单元测试的测试计划;

V模型强调的是测试模型,强调及早的进行测试,强到测试贯通于开发始终;而不是压在系统开发的最尾端;

6、喷泉模型与RAD

喷泉模型 面向对象方法

RAD 是快速开发 如vb、 dephil 组件式

7.构件组装模型(CBSD)

构件组装模型(CBSD)思路是是把软件开发中的各个模块,都可以考虑做成标准的构建,做成构建然后进行组装成需要的软件;

为什么大量的使用和推广呢?

主要是极大了提高软件的复用性,极大的缩短开发的周期,使软件的成本降低,同时使软件的可靠性增加;

为什么说使软件的可靠性增加呢?

构件组装模型会构建一个构架库,如果在新的项目当中,如果能用得上的,就提取出来应用到系统,这样意味着有很多构架库是以前使用在其它系统里面,这些构建已经经过了很长时间的验证,如果有问题,已经在别的系统经行发现及修正过了;使用在应用在新的系统中,它的出错的概率会远远的小于新的系统开发新的构建;所以有将强的竞争力;

8、统一过程(UP)

统一过程模型应用广泛,比较大型的项目;

Q:统一过程有哪些特点?

有三大特点: 1.用例驱动 2.以架构为中心 3.迭代和增量

用例驱动体现在哪里呢?

在最初开始的时候,相应的设计出一些用列来,通过需求分析,挖掘出用列,然后去实现用列, 同时用列又作为指导测试用列、开发的依据,用列把各个阶段串起来,推动各个各阶段的,所以叫用列驱动。

以架构为中心,统一强调把架构设计好,然后在里面填充相应的构建,完成整个系统开发。

迭代和增量,以环形要走,每个循环走完之后,会有一些增量的内容完成,每走一轮会增加一些东西;所以有迭代和增量的特点。

统一过程 称UP 或RUP

Q:统一过程有哪些阶段?统一过程每个阶段的任务是什么?

把开发过程分为四个阶段:初始、细化、构建、交付;

初始

1、确定项目的范围和边界,就是需求方面

2、识别系统的关键用例,关键用例如果没有做好,往往系统是失败的,28定理:80%的时间,是用系统的20%的功能。这个对应的28定理,如果没有把20%的功能做好,整个系统都是失败的。

3、展示系统的候选架构,架构是多样的,看那些架构合适;

4、估计项目费用和时间

5、评估项目风险

细化

1、分析系统问题领域

2、建立软件架构基础 (建立软件架构基础是在细化、精化)

3、淘汰最高风险元素

构建

1、开发剩余的构建

2、构件组装与测试

交付

1、进行贝塔测试 针对产品,用户的环境里面,由用户发起的测试,如qq下来用几天,就是贝塔测试,阿法是在测试环境测试。

2、制作发布版本

3、用户文档定稿

4、确认新系统

5、培训、调整产品

9、敏捷开发方法

发展历程:最初没有模式、没有方法,开发产出的软件质量难控制,开展了一系列的开发模式、方法,当一系列的开发模式、方法规范程度越来越高的时候,按一些重量型模型去开发得不到很好的效果;一些重量型模型关注流程、文档来规范开发,对于开发人员来说负担越来越重,而产生的这些文档又不见得真正用得上,花了很多时间,做出来的东西不见得那么好;所以就要给开发人员减负;把不必要得流程、文档减去,就形成敏捷开发方法;

敏捷开发方法并不是一个模型,针对适合小的项目,小步快跑;规模大的项目不适合敏捷开发方法;

4大价值观:沟通、简单、反馈、勇气;

沟通,对内对外都很重要;

简单,不要过度设计,留很多拓展、留很多接口,后期不一定用得上;

反馈,及时的向客户反馈反应相关的情况,有问题及时调整;

勇气,强调有勇气去变更,对于开发人员变更不是好事,但变更不可避免的,既然如此,迟变不如早变,早变有比较大的主动性,成本会更低一些;

论文可以根据知识点拓展的。

10、逆向工程

12、UML

用例图在考试时注意,先把其它图区分了,再来区分是属于静态的或属于静态的;

类图,表达的是类与类之间的关系;

对象图,对象与对象的关系;

包图,包与包之间的关系及包内部的结构;

部署图,应用部署到那个节点上;

用例图,系统与外部交互的关系;小人一样的符号。

顺序图,强调按时间顺序关系;

通信图,按顺序关系,与顺序图不一样是不强调时间顺序;

状态图,状态的变迁,转移的情况;

活动图,流程图一致;

13、需求分类

Quality(质量)、Function(功能)与Deployment(展开),简称QFD。

基本需求,客户提出来的,对于开发团队,必须要开发完成的;

期望需求,客户没有明确提出来的,但客户认为这话我没有讲应该你是要做    的,他认为要理所应当达成这样的效果,这部分也是必须去做的;需求难做,有时候客户没有提出来,但要领会把他做出来;

兴奋需求,用户没有提出要做这个事情,也没有提出必须要做的,但是你给做了,对于客户来说,也不会有影响的;

14、需求的获取

1. 收集资料,了解企业的情况,收集企业的现状什么情况,收集资料来做为依据;

2. 联合需求计划,表现的形式就是开会,一般是获取到初步需求的情况来用到,获取到的需求,看有哪些想法是和客户一致的,哪些是不一致的,和客户组织会议,把客户各个负责人邀请过来,也把相关项目需求调研、分析人员也组织起来,来宣布目前的需求目前有哪些成果,那些地方怎么做?目前的得到信息是怎么样的?参会的人员都是各方的,所以都会从自身的考虑,这样需求是否和我的想法是一致的;如果有冲突的可以提出来进行讨论;

弊端: 好的形式,但参与的人越多,消耗资源越多,项目开发的,人力资源是非常宝贵的;

3. 用户访谈,获取用户的需求,往往要找一些代表性的、核心关键的角色人员,看他们需求的想法是什么样的?

访谈分为结构化和非结构化形式.

结构化,逻辑非常严谨,依据非常充分,所以事先准备充分一系列的问题,在访谈过程中有针对性的去问这一系列的问题;比较针对性的、但可能局限性会小一些;非结构化,开始只是一个粗劣的想法,根据访谈的情况来灵活的调整。

经验:新手建议使用结构化,充分准备。

用户访谈需注意三个方面:准备好访谈,提前准备访谈的内容,进行分析、研究,如何做才能访谈取得更好得效果。

访谈得目的,

访谈得对象,可以一对一得,可以一对多,一对一相对耗时更多一些;一对多,人数过多,又难以控制,单次得访谈时间过长;准备问题有开放问题和封闭问题;

访谈过程问题要一一记录,会后有相应得总结,访谈纪要总结,

猜你喜欢

转载自blog.csdn.net/itdada/article/details/78952590