综合知识
码制
正数的反码与原码相同,负数的反码则是其绝对值按位求反,符号位不变
正数的补码与其原码和反码相同,负数的补码则等于其反码的末位加 1
无论正数负数,都是将该原码的补码的首位(符号位)取反得到移码。
补码,移码0有唯一的编码
纯小数转原码:
先求整数的二进制,在求小数的
小数就是一直×2,去小数点前一位的数,直到为0
计算0.1875的二进制,采用"乘2取整,顺序排列"法。
0.1875*2=0.3750 取整数部分0
0.3750*2=0.7500 取整数部分0
0.7500*2=1.5000 取整数部分1
0.5000*2=1.0000 取整数部分1
至到小数部分为0,停止计算结果从上到下为:0011
浮点数
N=F ×(2^E) =F × 2的E次方,其中E称为阶码,F称为尾数。
浮点数所能表示的数值范围主要由阶码决定,所表示数值的精度则由尾数决定。
规格化就是将尾数的绝对值限定在区间[0.1,1]。
运算
1、对阶。使两个数的阶码相同,小阶向大的对,浮点数向右移。(不是小数点右移)
校验码
循环冗余校验码(CRC)
生成多项式为k个数据位产生r个校验位来进行编码,其编码长度为 k+r。
然后对 k+r / 多项式,r全部是0
设需要发送的信息为M = 1010001101,
G(x)=X⁵+X⁴+X²+1
这里X从5开始,有5有4没3有2没1有0
产生多项式对应的代码为P = 110101
R= 生成多项式位数 - 1; 校验码位R=5。
在M后加5个0为计算序列:1010001101 00000
然后对P做模2除法运算,1010001101 00000 / 110101
得余数r(x)对应的代码:01110。
注意:除法是异或,相同为0,相异为1。
故实际需要发送的数据是1010001101 01110。其中CRC校验码就为:01110。
注意:余数不足r,则余数左边用若干个0补齐
海明码
公式:(2^k)-1>=n+k,其中k是检验位,n是数据位
Flynn
分类有两个因素,即指令流和数据流
一条指令可以控制一条或多条数据流,但条数据流不能被多条指令控制
多指令单数据 MISD 不可能
流水线
执行时间最长的段为流水线周期。
流水线执行时间:1条指令总执行时间 + (总指令条数-1) × 流水线周期。
流水线吞吐率:吞吐率即单位时间内执行的指令条数。公式:指令条数 / 流水线执行时间。
流水线的最大吞吐率与实际吞吐率主要是由流水线中执行时间最长的那个流水段来决定的。1 / 流水线周期
如果是所有执行时间一样的话,流水线公式:(多少段 + 总指令条数 -1)× 执行时间。
如果度为4,就是把: 总指令条数 / 4
单缓冲区和双缓冲区
单缓冲区:缓冲区的数据必须先取出,才能开始下一个;所以读入缓冲区→送入用户区可以合并。
计算单缓冲区花费的时间 (T+M)*n+C;读写合并 最后加处理时间,
T为输入的时间,M为传输的时间,n为作业的个数,C为处理的时间
双缓冲区:有2个缓冲区交替读入,可以并行,所以是读入缓冲区→送入用户区→数据处理三段。
计算双缓冲区花费的时间 T*n+M+C; 写处合并
磁盘冗余阵列技术 RAID
RAID 0:没有提供冗余和错误修复技术;它不提供数据校验或冗余备份,因此一旦磁盘损坏了,数据就直接丢失,无法恢复。
理解:就是把多块磁盘组合在一起形成一个大容量的存储。当我们要写数据的时候,会将数据分为N份,以独立的方式实现并发读写,执行性能非常高。
可以用在对可靠性要求不高,对读写性能要求高的场景中。
例如:假如有3块80 T的硬盘,采用RAID 0的容量是:240 T
RAID 1:在成对的独立磁盘上产生互为备份的数据,可提高读取性能;将同一份数据无差别的写两份到磁盘。
理解:实际空间使用率只有50%,成本高,数据的可靠性非常强。
例如:假如有3块80 T的硬盘,采用RAID 1的容量是:80 T
你只有3块,其中2块会被用来做备份。
RAID 2将数据条块化的分布于不同硬盘上,并使用海明码校验;
理解:实际是RAID 0 的改进版,组中的第1、2、4、…2 n 个磁盘驱动器是专门的校验盘,用于校验和纠错。其它磁盘存数据。
RAID 3使用奇偶校验,并用单块磁盘存储奇偶校验信息;
理解:和PAID 4一样,单独用一个磁盘存储校验信息,RAID 3采用位交叉奇偶校验码(水平),RAID 4采用块交叉奇偶校验码(垂直)。
例如:假如有3块80 T的硬盘,采用RAID 3的容量是:160 T
RAID 5:在所有磁盘上交叉的存储数据及奇偶校验信息(所有校验信息存储总量为一个磁盘容量),读/写指针可同时操作;
理解:不再需要用单独的磁盘写校验码了。它把校验码信息分布到各个磁盘上。
例如:假如有3块80 T的硬盘,采用RAID 5的容量是:160 T
RAID 6:具有独立的数据硬盘与两个独立的分布式校验方案
理解:RAID 6与RAID 5相比,增加了第二个独立的奇偶校验信息块。使用不同的算法,数据的可靠性非常高,即使两块磁盘同时失效也不会影响数据的使用。
至少需要4个磁盘,“写性能”非常差,高可用。
RAID 10 :RAID 1和RAID 0的优点。首先基于RAID 1模式将磁盘分为2份,当要写入数据的时候,在两份磁盘上同时写入,且在每一份磁盘上又会基于RAID 0技术将数据分为N份并发的读写,这样也保障了数据的效率。
理解:高可靠性与高性能的组合,RAID 1是一个冗余的备份阵列,而RAID 0是负责数据读写的阵列
系统可靠性分析
系统可用性 = (运行总时长 - 故障修复时间)/ 运行总时长
串并联系统可靠性
串联系统:一个设备不可靠,整个系统崩溃,整个系统可靠性R = R1…R2….×Rn。
并联系统:所有设备都不可靠,整个系统才崩溃,整个系统可靠性 R=1-(1-R1)×(1-R2)×….×(1-Rn)。
混合系统:划分串联、并联,先把并算出来,在算串。
成熟性子特性是指系统避免因错误的发生而导致失效的能力;
容错性是指在系统发生故障或违反指定接口的情况下,系统维持规定的性能级别的能力;
使用多处理机系统的主要目的是实现作业级和任务级代码的并行性。
系统性能
处理能力或效率:又可分为三类指标,第一类指标是吞吐率(系统在单位时间内能处理正常作业的个数),第二类指标是响应时间(从系统得到输入到给出输出之间的时间),第三类指标是资源利用率,即在给定的时间区间中,各种部件(包括硬设备和软件系统)被使用的时间与整个时间之比。
指令执行速度法: 用加法指令的运算速度来衡量计算机的速度。
综合理论性能法 CTP:美国政府限制计算机出口。先算出处理部件每个计算单元的有效计算率,再按不同字长加以调整,得出该计算单元的理论性能。
基准程序法:把用得最多、最频繁的那部分核心程序作为评估计算机系统性能的标准程序,是目前一致承认的测试系统性能的较好方法。
嵌入式
可定制:从减少成本和缩短研发周期考虑,要求嵌入式操作系统能运行在不同的微处理器平台上,能针对硬件变化进行结构与功能上的配置。
易移植性:为了提高系统的易移植性,通常采用硬件抽象层和板级支撑包的底层设计技术。
根据任务的紧急程度确定任务的优先级,这种算法称之为抢占式优先级调度(Preemptive Priority Scheduling,PPS)算法。
而最早截止时间优先( Earliest Deadline First)算法、最低松弛度优先(Least Laxity First)算法和单调速率调度(Rate Monotonic Scheduling,RMS)算法则是根据任务的截止时间、松弛度和周期等特性来确定调度策略的。因此,选项D是正确答案。
计算机启动的基本流程为:BIOS→主引导记录→操作系统。
死锁与线程
进程资源:先分配在申请
能不能化简,就是看别人释放了资源,你能不能执行完。
阻塞节点:资源全部分配完毕,无法获取所需资源,只能自己申请。
只要满足 m>=n×(k-1)+1 那就不会发生死锁,m为资源数量,n为进程数量,k为每个进程需要的资源数量
切记:减的是所需资源数,助记(加1减1)
线程不能共享线程独有的资源,如线程的栈指针等标识数据。
在并行处理系统中,将程序的模块划分得越小,程序模块间的数据相关性越大,通信开销也越大。模块越小就需要越多的线程,由于相互切换而影响性能,也需要更多的内存空间,即开销更大。
信号量操作
P操作是对信号量减1,意味着请求系统分配一个单位资源,若系统无可用资源,则进程变为阻塞状态;
V操作是对信号量加1,意味着释放一个单位资源,加1后若信号量小于等于0,则从就绪队列中唤醒一个进程,执行V操作的进程继续执行。
使用信号量机制实现进程互斥时,需要为临界资源设置一个互斥信号量S,其初值通常为1。在每个进程中将临界区代码置于 P(S)和 V(S)之间。
P对它-1,表示一个资源被使用了,如果S=0了,就要等待它被释放,V对它+1,表示一个资源被释放了。
注意:S就是能用的资源数,为0,就是没资源用了,程序就要等待释放在执行
索引文件结构
系统中有 13 个索引节点,0-9为直接索引,即每个索引节点存放的是内容,假设每个物理盘大小为 4KB,共可存 4KB*10=40KB 数据;
10号索引节点为一级间接索引节点,大小为4KB,存放的并非直接数据,而是链接到直接物理盘块的地址,假设每个地址占 4B,则共有 1024 个地址,对应 1024 个物理盘,可存 1024*4KB=4098KB数据。
某系统磁盘数据块的大小为1024KB,系统磁盘管理采用索引文件结构,每个索引指针占用4个字节。一个索引文件的索引节点有8个直接块地址、1个一级间接块地址、1个二级间接块地址和1个三级间接块地址。假设索引节点已经在内存中,那么访问该文件偏移地址9089k字节的数据需要再访问()次磁盘
直接块地址:可以直接定位到 8 个数据块,每个数据块大小为 1024KB,所以总共可以定位到 8 * 1024KB = 8192KB 的数据。
一级间接块地址:可以定位到一个数据块,这个数据块中存放的是指向其他数据块的指针。由于每个指针占用 4 个字节,所以这个间接块可以存放 1024KB / 4B = 262144 个指针,即可以定位到 262144 * 1024KB = 268435456KB 的数据。
因此,除了已经在内存中的索引节点外,我们还需要访问一次磁盘(即一级间接块对应的数据块)来获取指向目标数据块的指针,然后再访问一次磁盘来获取目标数据块中的数据。
所以总共需要再访问 2 次磁盘
相对路径:是从当前路径开始的路径。
绝对路径:是从根目录开始的路径。
全文件名=绝对路径+文件名。
注意:绝对路径和相对路径是不加最后的文件名的,只是单纯的路径序列。
位示图法:对每个物理空间用一位标识,为1则使用,为0则空闲,形成一张位示图。
先淘汰未访问,在淘汰未修改
例如:计算机系统字长64位,第0个逻辑编号对应的是0-63物理块。第1个对应的是64-127物理块。
将 256 号物理块分配给某文件,那么该物理块的使用情况在位示图中编号为 4 的字中.
由于物理块从 0 开始,从第 0 块到第 255 块 刚好占用了 4 个字(256/64=4),
第256块应该是第五个字(编号为 4 的字)的 0 号位置。该字的 0 号位置“1” ,为1则使用了。
切记是整数的话,字号 就要+1了
例如:某文件管理系统在磁盘上建立了位示图(bitmap),记录磁盘的使用情况。若计算机系统的字长为32位(注:每位可以表示一个物理块“使用“还是“未用“的情况),若磁盘的容量为400GB,物理块的大小为4MB,那么位示图的大小需要(48)个字。
根据题意,计算机系统中的字长为32位,每位可以表示一个物理块的“使用“还是“未用”,一个字可记录32个物理块的使用情况。又因为1G=1024/4=256个物理块,磁盘的容量为400GB可划分成400X256=102400个物理块,位示图的大小为3200个字(102400/32=3200)。
输入输出技术
I/O:用户进程一设备无关软件一设备驱动程序一中断处理程序一硬件
程序控制(查询)方式:CPU主动查询外设是否完成数据传输,效率极低。无法检测错误,只能串行工作。
程序中断方式:外设完成数据传输后,向CPU发送中断,等待CPU处理数据,效率相对较高。适用于键盘等实时性较高的场景。
中断响应时间指的是从发出中断请求到开始进入中断处理程序。
中断处理时间指的是从中断处理开始到中断处理结束。
中断向量提供中断服务程序的入口地址。多级中断嵌套,使用堆栈来保护断点和现场。
注意:由于中断次数多,因而CPU仍需要花费较多的时间处理中断,而且能够并行操作的设备台数也受到中断处理时间的限制,中断次数增多也导致数据丢失。
因此:程序直接控制方式和中断控制方式都只适用于简单的、外设很少的计算机系统。
DMA方式(直接主存存取):CPU 只需完成必要的初始化等操作,数据传输的整个过程都由 DMA控制器来完成,在主存和外设之间建立直接的数据通路,效率很高。适用于硬盘等高速设备。不需要CPU参与数据传输
通道:也是一种处理机,内部具有独立的处理系统,使数据的传输独立于CPU。分为字节多路通道的传送方式(每一次传送一个通道的一个字节,多路通道循环)和选择通道的传送方式(选择一个通道,先传送完这个通道的所有字节,再开始下一个通道传送)。外设和内存直接交换数据的方式
DMA方式与通道控制方式的区别是,DMA方式要求CPU执行设备驱动程序来启动设备,给出存放数据的内存起始地址以及操作方式和传送字节长度等;
而通道控制方式则是在CPU发出I/O启动命令之后,由通道指令来完成这些工作。
cache
时间局部性原理:如果一个数据项正在被访问,那么在近期它很可能会被再次访问,例如循环语句,即在相邻的时间里会访问同一个数据项。
空间局部性原理:在最近的将来会用到的数据的地址和现在正在访问的数据地址很可能是相近的,例如程序顺序执行数组的访问,即相邻的空间地址会被连续访问。
地址映射,由硬件自动完成
直接映像:主存的块与 Cache 块的对应关系是固定的,直接映像方式的优点是地址变换很简单,缺点是灵活性差。
Cache 中有多少块,主存的一个组就由多少块组成。
主存中每个组的第 i 块会映射到Cache中的第 i 块
Cache 与主存之间是一对多的关系,主存中的块只能存放在Cache存储器的相同块号中。
全相联映像:主存的块调入 Cache 的位置不受限制,十分灵活。其主要缺点是无法从主存块号中直接获得 Cache 的块号,变换比较复杂,速度比较慢。
Cache 中的任意一块可以存放主存中的任意一块
Cache 和主存之间是多对多的关系
组组相连映像:前面两种方式的结合,将 Cache 存储器先分块再分组,主存也同样先分页(页跟cache块是同一级别的)再分组,组间采用直接映像,即主存中组号与 Cache 中组号相同的组才能命中,但是组内全相联映像,也即组号相同的两个组内的所有块可以任意调换。
Cache 中**若干个连续的块组成了一组,其中主存每个组中的第 i 块对应Cache中的第 i 组
- 直接映像(Direct Mapping)是最简单的地址映射方式,但它并不总是最快的。在直接映像中,主存的每一块只能映射到Cache的固定位置,这可能导致冲突(多个主存块映射到同一个Cache块),从而降低了命中率。
- 组相联(Set-Associative)和全相联(Fully-Associative)提供了更高的灵活性,减少了冲突的可能性,从而提高了命中率。在速度要求较高的场合,我们更可能选择组相联或全相联以获得更高的命中率。
Cache 置换算法 最近不经常使用LFU是要计数的,很难实现。
常用算法:随机替换算法、先进先出算法FIFO、近期最少使用算法LRU
冲突:直接映像一组相联映像一全相联映像。
相联存储器是一种按内容访问的存储器。可用在高速缓冲存储器(Cache)中。
数据库的设计
需求分析:即分析数据存储的要求和边界,产出物有数据流图、数据字典、需求说明书。
概念结构设计:设计用户的数据模型,与具体DBMS(数据库管理系统)无关的概念模型,一般是设计E-R图,也即实体-属性图,与物理实现无关,就是说明有哪些实体,实体有哪些属性。
逻辑结构设计:将E-R图,转换成关系模式,也即转换成实际的表和表中的列属性,这里要考虑很多规范化的东西。
物理设计:根据生成的表等概念,生成物理数据库。
概念结构设计步骤:抽象数据,设计局部视图,合并取消冲突,修改重构消除冗余
逻辑结构设计步骤:转换为数据模型一关系规范化一模式优化一设计用户子模式。
**数据模型三要素:**数据结构(所研究的对象类型的集合)、数据操作(对数据库中各种对象的实例允许执行的操作的集合)、数据的约束条件(一组完整性规则的集合)。
投影ó:实际是按条件选择某关系模式中的某列,列也可以用数字表示。selet ? from ?
选择π:实际是按条件选择某关系模式中的某条记录。where
自然连接⨝:结果显示全部的属性列,但是相同属性列只显示一次,显示两个关系模式中属性相同且值相同的记录。from A,B
部分函数依赖:A可确定C,(A,B)也可确定C,(A,B)中的一部分(即A)可以确定C,称为部分函数依赖。
传递函数依赖:当A和B不等价时,A可确定B,B可确定C,则A可确定C,是传递函数依赖;若A和B等价,则不存在传递,直接就可确定C。
自反律:若属性集Y 包含于属性集 X,属性集 x 包含于 U,则 x→γ 在 R 上成立。(此处 X→Y是平凡函数依赖)
增广律:若X→Y在R上成立,且属性集Z 包含于属性集 U,则XZ→YZ 在R上成立。
传递律:若X→Y和Y→Z在R上成立,则X→Z在R上成立。
合并规则:若X→Y,X→Z同时在R上成立,则X→YZ在R上也成立。
分解规则:若X→W在R上成立,且属性集Z包含于W,则X→Z在R上也成立。
伪传递规则:若X→Y在R上成立,且WY→Z,则XW→Z。
1 NF:不可分的数据项。
2 NF:每一个非主属性不会依赖复合主键中的某一个
3 NF:其他属性传递依赖时,不能依赖主键
BCNF:没有任何属性完全函数依赖于非键属性
无损连接:如果两个或两个以上的关系模式通过自然连接可以恢复为原来的关系模式,并且不丢失信息(即元组),则称这些关系模式的分解是无损连接的。
做题方法:把关系模式做交集,也就是大家都有的,看它是不是超码(唯一的)
保持函数依赖:如果关系模式的分解能够保持原关系模式中所有的函数依赖,则称该分解是保持函数依赖的。
假设关系模式R(U,F),属性集U={A,B,C),函数依赖集F={A→B,B→C).若将其分解为p={R1(U1, F1), R2(U2, F2)),其中U1={A, B),U2={A,C}。那么,分解p()。
A.有损连接但保持函数依赖
B.既无损连接又保持函数依赖
C.有损连接且不保持函数依赖
D.无损连接但不保持函数依赖
检查无损连接:
由于U1和U2的交集是{A},且A在F中是一个决定因素(即A→B和A→C(由B→C和A→B传递得到)),因此这是一个无损连接的分解。
检查保持函数依赖:
分解后的F1和F2分别是:F1 = {A→B}(因为U1只包含A和B),F2 = {A→C}(由于B→C和A→B,我们可以在U2上得到A→C)。
但是,原函数依赖集F中的B→C在分解后的任何一个关系模式中都没有得到保持。
授权 grant…on…to,允许其将权限再赋给另一用户 with grant option;
GRANT<权限update> ON 表名[(列名)] TO 用户 WITH GRANT OPTION。
收回权限 revoke…on…from;
数据仓库四大特点:面向主题、集成的、相对稳定的、相对稳定的
数据挖掘的分析方法:关联分析、序列分析(一定时间间隔内接连发生的事件)、分类分析、聚类分析(物以类聚)
商业智能 BI:包括数据预处理、建立数据仓库、数据分析和数据展现四个主要阶段。
- 数据预处理是整合企业原始数据的第一步,它包括数据的抽取(Extraction)、转换(Transformation)和加载(Load)三个过程(ETL过程);
- 建立数据仓库则是处理海量数据的基础;
- 数据分析是体现系统智能的关键,一般采用联机分析处理(OLAP)和数据挖掘两大技术。
转换步骤一般还要包含数据清洗的过程,针对源数据库中,对出现二义性、重复、不完整、违反业务或逻辑规则等问题的数据进行清洗操作。
网络
巫术忘传会飙英
物理就是光纤,数据链路层是网桥/MAC,网络层是路由器与IP,传输层有TCP/UDP,会话层/表示层/应用层可以统一为应用层。
其中lPSec协议应用在网络层,保护和认证IP 数据包,传输模式中只对IP数据加密。
SMTP主要用于发送邮件,POP 3则用来接收电子邮件。
IMAP 协议同步服务器和客户端之间的邮件列表。
UDP:效率高,但是不可靠,因此发送报文时,应该短些
- 第一次握手:客户端发送一个SYN包(SYN=1,seq=x)到服务器,并进入SYN_SEND状态,等待服务器确认。
- 第二次握手:服务器收到SYN包后,发送一个SYN/ACK包(SYN=1,ACK=1,ack=x+1,seq=y)给客户端以确认连接请求,并同时自己也发送一个SYN包,此时服务器进入SYN_RECV状态。
- 第三次握手:客户端收到服务器的SYN/ACK包后,向服务器发送一个ACK包(ACK=1,ack=y+1,seq=x+1)以确认,此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。
SMTP,简单邮件传输协议,25端口
POP 3,邮局协议3,110端口
HTTP,超文本传输协议,WEB浏览器,80端口
HTTPS,加密的超文本传输,443端口
FTP,文件传输服务,20数据端口,21命令控制端口
DNS,域名服务,53端口
Telnet,远程登录,23端口
SSH, 安全 Shell 远程登录协议,22端口
IPv4 中的地址分为组播、广播和单播三种,
IPv6 中的地址分为多播、任播和单播三种。
每个IP地址由两部分组成,分别是网络号和主机号
将主机号拿出几位作为子网号,划分出多个子网,此时地址组成为:网络号+子网号+主机号。
子网掩码也是一个32位的二进制数,但其 网络标识和子网标识部分全为1,主机标识部分全为0。
11111111 11111111 11110000 00000000,即255.255.240.0。
判断两台计算机是否在同一个子网内,需要用到子网掩码,
将两个IP地址与给定的子网掩码分别进行逻辑与运算,如果结果相等,则属于同一个子网。
示例:
I P 地址 192.168.0.1
子网掩码 255.255.255.0
转化为二进制进行运算:
I P 地址 11010000.10101000.00000000.00000001
子网掩码 11111111.11111111.11111111.00000000
AND运算
11000000.10101000.00000000.00000000
转化为十进制后为:
192.168.0.0
I P 地址 192.168.0.254
子网掩码 255.255.255.0
转化为二进制进行运算:
I P 地址 11010000.10101000.00000000.11111110
子网掩码 11111111.11111111.11111111.00000000
AND运算
11000000.10101000.00000000.00000000
转化为十进制后为:
192.168.0.0
无分类编址格式为:IP 地址 / 网络号
示例:128.168.0.11/20
表示的 IP 地址为 128.168.0.11,其网络号占 20 位,因此主机号占 32-20=12位,也可以划分子网。
如 : 128.14.35.7/20, 表示该 IP 地址 , 前20位是网络前缀;
① 先将 128.14.35.7/20地址转为二进制形式;
10000000 00001110 00100011 00000111
前 20位是 网络前缀 , 为 :
10000000 00001110 0010
② 地址块地址 : 二进制形式如下 :
10000000 00001110 00100000 00000000
转为十进制为 :
128.14.32.0/20
③ 最小地址 : 最小地址就是 主机号 全 0; 也就是地址块地址;
④ 最大地址 : 最大地址就是 主机号 全 1 ;
10000000 00001110 00101111 11111111
⑤ 子网掩码 : 又称为 “地址掩码” , 网络前缀对应的前 20位 为 1 , 主机号对应的位数为 0 ;
11111111 11111111 11110000 00000000
转为十进制为 : 255.255.240.0
某校园网的地址是 202.115.192.0/19,要把该网络分成 32 个子网,则子网掩码应该是?
解:其网络号占 19位,因此主机号占 32-19=13位;
将网络号分成32个,需要5个比特,2^n >= 32;
网络号占 19 位,要分成32个,就得再加5位,即24位。
IP都是8位一起的,24位就是前3个ip数字。
网络标识和子网标识部分全为1,主机标识部分全为0。
8个1的2进制为255
即:255.255.255.0
对称加密:DES(共享密钥,112位)、AES(128)
非对称加密技术:RSA(1024)
摘要算法:MD5(128位)、SHA-1(160位)。
病毒
文件型:感染DOS下的COM,EXE文件
引导型:启动DOS系统时,病毒被触发
宏病毒:针对0ffce的一种病毒,由0ffice的宏语言编写
VB脚本病毒:通过IE浏览器激活
蠕虫:有些采用电子邮件附件的方式发出,有些利用操作系统漏洞进行攻击
木马:通常是病毒携带的一个附属程序
黑客程序:一个利用系统洞进行入侵的工具
知识产权
商业秘密权:保护软件的技术信息、经营信息。是具有实用性的。规定了才有
商标权权利人:注册商标所有人。同音字也算同一个商标
国家版权局是国务院著作权行政管理部门,主管全国的著作权管理工作。
中国版权保护中心的主要职能之一是计算机软件著作权登记。
发表权有时间限制
署名权、修改权、保护作品完整权 不受时间限制,就是永久保护
要退休1年,才跟公司没有关系。
企业信息化
业务与IT整合。BITA适用于信息系统不能满足当前管理中的业务需要,业务和IT之间总是有不一致的地方。建立业务模型
企业IT架构。EITA适用于现有信息系统和IT基础架构不一致、不兼容和缺乏统一的整体管理的企业。
市场营销和客户服务是 CRM 的支柱性功能
CRM 必须能与ERP很好地集成。
CRM 的核心是客户价值管理
信息资源规划( IRP)是将需求分析与系统建模紧密结合起来。
软件工程
集成定义方法 IDEF
IDEF 是一系列建模、分析和仿真方法的统称,从IDEFO到IDEF14(包括IDEF1X在内)共有 16套方法,每套方法都是通过建模程序来获取某个特定类型的信息。
IDEFO:业务流程(功能)建模;
IDEF1:信息建模;
IDEFIX:数据建模(如 ER 模型);
IDEF2:仿真建模设计;
IDEF3:过程描述获取;
IDEF4:面向对象设计;
IDEF5:本体论描述获取;
IDEF6:设计原理获取;
IDEF7:信息系统审计;
IDEF8:用户界面建模;
IDEF9:场景驱动信息系统设计;
IDEF10:实施架构建模;
IDEF11:信息制品建模;
IDEF12:组织结构建模;
IDEF13:三模式映射设计;
IDEF14:网络规划。
工作流执行服务:工作流执行服务是WFMS(工作流管理系统)的核心模块,它的功能包括创建和管理流程定义,创建、管理和执行流程实例。
工作流引擎:工作流引擎是为流程实例提供运行环境,并解释执行流程实例的软件模块,即负责流程处理的软件模块。
流程定义工具:流程定义工具是管理流程定义的工具,它可以通过图形方式把复杂的流程定义显示出来并加以操作。
客户端应用:客户端应用是通过请求的方式与工作流执行服务交互的应用。
调用应用:调用应用是被工作流执行服务调用的应用,调用应用与工作流执行服务交互。
管理监控工具:管理监控工具主要指组织机构和参与者等数据的维护管理和流程执行情况的监控,管理监控工具与工作流执行服务交互。
软件工程的基本要素:方法、工具、过程。
1.系统规划阶段:任务是对组织的环境、目标及现行系统的状况进行初步调查,根据组织目标和发展战略确定信息系统的发展战略,对建设新系统的需求做出分析和预测,同时考虑建设新系统所受的各种约束,研究建设新系统的必要性和可能性。根据需要与可能,给出制建系统的备选方案。(可行性分析与项目开发计划)
输出:可行性研究报告、系统设计任务书。
2.系统分析阶段:任务是根据系统设计任务书所确定的范围,对现行系统进行详细调查,描述现行系统的业务流程,指出现行系统的局限性和不足之处,确定新系统的基本目标和逻辑功能要求,即提出新系统的逻辑模型。系统分析阶段又称为逻辑设计阶段。这个阶段是整个系统建设的关键阶段,也是信息系统建设与一般工程项目的重要区别所在。(需求分析)
输出:系统说明书。
3.系统设计阶段:系统分析阶段的任务是回答系统“做什么”的问题,而系统设计阶段要回答的问题是“怎么做”。该阶段的任务是根据系统说明书中规定的功能要求,具体设计实现逻辑模型的技术方案,也就是设计新系统的物理模型。这个阶段又称为物理设计阶段,可分为总体设计(概要设计)和详细设计两个子阶段。(概要设计(选择系统解决方案,规划子系,模块结构图)、详细设计(设计子系统内部具体实现))
输出:系统设计说明书(概要设计、详细设计说明书)。
4.系统实施阶段:是将设计的系统付诸实施的阶段。这一阶段的任务包括计算机等设备的购置、安装和调试、程序的编写和调试、人员培训、数据文件转换、系统调试与转换等。这个阶段的特点是几个互相联系、互相制约的任务同时展开,必须精心安排、合理组织。系统实施是按实施计划分阶段完成的,每个阶段应写出实施进展报告。系统测试之后写出系统测试分析报告。(编码、测试)
输出:实施进展报告、系统测试分析报告。
5.系统运行和维护阶段:系统投入运行后,需要经常进行维护和评价,记录系统运行的情况,根据一定的规则对系统进行必要的修改,评价系统的工作质量和经济效益。(维护)
用户界面设计
置于用户控制之下。
减轻用户的记忆负担。
保持界面一致性。
软件过程模型
瀑布模型(SDLC):瀑布模型是一个经典的软件生命周期模型,一般将软件开发分为:可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段。
瀑布模型特点
- 从上一项开发活动接受该项活动的工作对象作为输入。
- 利用这一输入,实施该项活动应完成的工作内容。
- 给出该项活动的工作成果,作为输出传给下一项开发活动。
- 对该项活动的实施工作成果进行评审。若其工作成果得到确认,则继续进行下一项开发活动;否则返回前一项,甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件。
注意:瀑布模型适用于需求明确的项目!
螺旋模型是一个演化软件过程模型,将原型实现的迭代特征与线性顺序(瀑布)模型中控制的和系统化的方面结合起来。在螺旋模型中,软件开发是一系列的增量发布。
开发过程具有周期性重复的螺旋线状。四个象限分别标志每个周期所划分的四阶段:制订计划、风险分析、实施工程和客户评估。
螺旋模型强调了风险分析,特别适用于庞大而复杂的、高风险的系统。
V模型的特点如下:
- 单元测试的主要目的是针对编码过程中可能存在的各种错误;(单编)
- 集成测试的主要目的是针对详细设计中可能存在的问题;集详(吉祥)
- 系统测试主要针对概要设计,检查系统作为一个整体是否有效地得到运行;系概(膝盖)
- 验收测试通常由业务专家或者用户进行,以确认产品能真正符合用户业务上的需要。验需(延续)
V模型用于需求明确和需求变更不频繁的情形。
原型法认为在很难一下子全面准确地提出用户需求的情况下,原型应当具备的特点如下。
- 实际可行
- 具有最终系统的基本特征
- 构造方便、快速,造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。
针对的就是需求不明确的情况,采用的是迭代的思想。不适合超大项目开发。
增量模型:首先开发核心模块功能,而后与用户确认,之后再开发次核心模块的功能,即每次开发一部分功能,并与用户需求确认,最终完成项目开发,优先级最高的服务最先交付。
特点:但由于并不是从系统整体角度规划各个模块,因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不用的是增量模型的每一次增量版本都可作为独立可操作的作品,而原型的构造一般是为了演示。
喷泉模型:是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。
基于构件的开发模型CBSD:利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件,也可以是商品化成品软件构件。
特点是增强了复用性,在系统开发过程中,会构建一个构件库,供其他系统复用,因此可以提高可靠性,节省时间和成本。
形式化方法模型:建立在严格数学基础上的一种软件开发方法,主要活动是生成计算机软件形式化的数学规格说明。
统一过程 UP是一个通用过程框架。
三大特点
用例和风险驱动、以架构为中心、迭代并且增量。
开发的四个阶段
起始(初始):确认需求和风险评估,确定系统的边界问题,产出物是项目蓝图文档、用例模型、项目计划。
精化(细化):完成架构设计,淘汰高风险因素。
构建:开发剩余构件,组装构件,产出物是UML模型、测试用例。
移交(交付):进行测试,交付系统,产出物是可运行的软件产品、用户手册、用户支持计划。
UP 的每一次迭代都是一次完整的软件开发过程,包括整个软件开发生命周期,有五个核心工作流(需求、分析 、设计 、实现 、测试)。
RUP(Rational Unified Process)中的9个核心工作流是项目成功的关键。这些工作流分为6个核心过程(业务建模、需求、分析和设计、实现、测试、部署)和3个核心支持工作流(配置和变更管理、项目管理、环境)。
一、案例
教程上:8 9 10 11 12 13 章是重点,通篇过一遍,重点是理解,不是死记硬背,答题过程中只要写上了关键点都会给分。
5道题,一共要做3道,25分一道,选题时,先看题目,题目都看不懂就可以直接放弃。
第一道是必答题,其他4道题选2道答,其中一道是嵌入式的题(不考虑,嵌入式是一个领域);
每道题25分,其中18分是书中能找到答案的;
一道题如果能拿到15分以上,就可以选了。
喜欢出技术对比的题目
1、解答技巧
- 标出问题要点,以此作为主要线素进行分析和思考(先看问题);
- 对照问题要点仔细阅读正文;
- 从出题者的思路出发,构思答案的要点;
- 以最简练的语言写出答案(言简意赅,列1234);
- 把自己认为对的,都写上;
- 分析题目问题的倾向性,顺势答题。
1.1、没接触到的知识点
软件过程模型:6个核心过程(业务建模、需求、分析和设计、实现、测试、部署)和3个核心支持工作流(配置和变更管理、项目管理、环境)。
开发方法:
(1)初始研究:项目范围,项目价值、机会和问题,进度表和预算
(2)问题分析:研究问题领域,分析问题和机会、分析业务、改进目标
(3)需求分析:定义需求,需求优先
(4)决策分析:确定候选方案并分析所有候选方案的可行性,选择出最优的解决方案。
2、系统规划
规划是什么?长远的发展计划。
2.1、系统规划步骤
- 对现有系统进行初步调查。根据企业战略和发展目标,从类似企业和本企业内部收集各种信息,站在管理层的高度观察企业的现状,分析现有系统的运行状况。
- 分析和确定系统目标。系统目标应包括服务的质量和范围、政策、组织和人员等,它不仅包括信息系统的目标,还要反映整个企业的目标。
- 分析子系统的组成和基本功能。自顶向下对系统进行划分,并且详细说明各个子系统应该实现的功能。
- 拟定系统的实施方案:可以对子系统的优先级进行设定,以便确定子系统的开发顺序。
- 进行系统的可行性研究,编写可行性研究报告,召开可行性论证会。
- 制订系统建设方案。对可行性研究报告中提出的各项技术指标进行分析、比较,落实各项假设的前提条件,制订系统建设方案,并根据该方案及其实施计划编写成系统设计任务书。系统设计任务书经上级主管部门批准后,正式作为系统建设的依据。
助记:对现在的自己做个初步调查,分析和确定你的人生目标,人生要分阶段当中重要的是组功,制作实施方案也就确定优先级决定顺序,分析这样的人生可不可行,能就制定建设目标。整个人生
2.2、项目机会选择
立项目标和动机→立项价值判断→项目选择和确定→初步调査→可行性分析。
项目的立项目标和动机
立项目标和动机就是你干嘛要做这个项目,你出于什么目的,一共就4种类型
- 进行基础研究(探索性研究,由大学,国家提出和实施)。为了开拓未来的市场,创造全新概念的产品、产业或生活方式,建立企业、行业甚至国家的竞争优势。
- 进行应用研发(办公软件、杀毒软件),基本动机是得到应用产品,并向目标客户群进行销售。
- 提供技术服务(提供比较全面的技术服务,而不是单一的软件产品)提供技术和解决方案的咨询。
- 产品的使用者(用户通过采购产品或技术服务来得到使用价值)定制开发。
项目的选择和确定
- 选择有核心价值的项目:和企业的核心业务相关的
- 评估所选择的项目:项目实施的约束、风险、成本和效益。(可行性研究完成),约束就是不能做什么。
- 项目优先级排序:评估后还有多个建议项目,但企业资源有限,你就要进行成本效益分析,考察净现值、投资回收期等指标。
- 评估项目的多种实施方式:对于已确认有价值、并且有能力开发的项目,则进一步参照企业现状,考察项目的实施方式。
- 平衡地选择合适的方案:在选择可行的方案时,总是希望能尽量得到一种高质量、低成本的产品和方案。
初步调查
- 目标:掌握用户的概况,从整体上了解企业信息系统建设的现状,对用户提出的各种问题和初始需求进行识别,明确系统的初步目标,为可行性研究提供工作基础。
- 方式:最佳方式是与企业高层管理人员座谈,通过座谈了解企业高层对信息系统所设定的目标和系统边界计划的资金投入和对工期的要求。
- 内容:初步需求分析,企业基本状况,管理方式和基础数据管理状况,现有系统状况。
2.3、可行性分析
可行性包括两个方面
- 必要性:动机,是否有必要建设新系统?
- 可能性:建设新系统的工作是否具备必要的条件?
软件系统的可行性分析包括四个方面
-
经济可行性:主要评估项目的建设成本、运行成本和项目建成后可能的经济收益。
-
技术可行性:研究的对象是信息系统需要实现的功能和性能,以及技术能力约束。(技术、资源、目标3个方面论证)
-
法律可行性:具有比较广泛的内容,它需要从政策、法律、道德、制度等社会因素来论证信息系统建设的现实性。
-
用户使用可行性:从信息系统用户的角度来评估系统的可行性,包括企业的行政管理和工作制度、使用人员的素质和培训要求等。可以细分为管理可行性(从企业管理上分析系统建设可行性)和运行可行性(分析和测定信息系统在确定环境中能够有效工作,并被用户方便使用的程度和能力)。
可行性研究步骤
- 复查系统目标和规模
- 分析现有系统
- 导出新系统的高层逻辑模型:上下文关系图,ER图,用例图,领域模型,IPO(输入/处理/输出)图
- 用户复核
- 提出并评价解决方案
- 确定最终推荐的解决方案
- 草拟开发计划
- 编制和提交可行性研究报告
可行性研究报告的内容(文档本身的内容+可行性研究的内容)
引言、引用文件、可行性研究的前提、可选的方案、所建议的系统、经济,技术,法律,用户使用可行性、其他与项目有关的问题、注解、附录。
2.4、成本效益分析
成本分类
- 固定成本:是指其总额在一定期间和一定业务量范围内,不受业务量变动的影响而保持固定不变的成本。例如,管理人员的工资、办公费、固定资产折旧费、员工培训费等。
- 变动成本:也称为可变成本,是指在一定时期和一定业务量范围内其总额随着业务量的变动而成正比例变动的成本。例如,直接材料费、产品包装费、外包费用、开发奖金等。(销量增加,成本也会增加的)
- 混合成本:就是混合了固定成本和变动成本的性质的成本。例如,水电费、电话费等。这些成本通常有一个基数,超过这个基数就会随业务量的增大而增大。
- 直接成本:直接投入在项目上。
- 间接成本:分摊到项目上。
- 沉没成本:已经投入到项目中,无法挽回的成本,不需要再去考虑。
固定成本很容易跟固定资本相联系在一起,以为是那种看得见的才是固定成本,比如房租,电脑采购费这种;
实现上固定成本是在一段时间内不会随着销量增加而变动的。
可变成本与销售收入(销量)成正比,固定成本一直不变
计算问题
-
现值:未来的钱,在现在的价值。
-
静态收益计算方式:不考虑金钱的时间价值,只看项目周期内投入和产出的绝对数字。
-
动态收益计算方式:考虑金钱具有时间价值,现在的钱比未来值钱。
-
公式 1/(1+i)ⁿ 计算各年度的折现系数,如果题目给了折现系数,那么现值P = F x 折现系数
-
每年折现率为 i,原价值为F的东西:现值P = F / ( 1 + i )ⁿ
净现值 NPV:总收益 - 总成本
-
未来的纯利润在现在值多少钱。
-
有助于公司判断项目是否盈利。
-
总收入现值 - 总投资现值。
净现值率 NPVR:净利润 / 总成本
- 有助于公司选择投入小,产出高的项目
- NPV / 总投资现值
投资回收期:就是看多少年回本
-
静态投资回收期 = 累计净现金流量出现正值的年份数 - 1 + ( (前一年累计总成本 - 前一年累计总收益) / 当年收益 - 当年成本)。
-
动态投资回收期 = 累计折现值出现正值的年份数 - 1 + (前一年总成本折现值 - 前一年总收益折现值) / (当年收益折现值-当年成本折现值)。
-
理解:看哪一年你回本了,然后算出上一年你还差多少回本,把这个值 / 回本的那一年总收入,算出它的占比,在加上上一年的回收期
-
投资回收率=1/动态投资回收期×100%
-
投资收益率 = 投资总收益 / 投资成本 × 100%。注意这个是所有收益不是净利润
3、开发方法
3.1、面向对象
认为客观世界是由各种“对象”组成的,任何事物都是对象,每一个对象都有自己的运动规律和内部状态,都属于某个对象“类”,是该对象类的一个元素。复杂的对象可由相对简单的各种对象以某种方式而构成,不同对象的组合及相互作用就构成了系统。
面向对象方法的特点
- 使用OO方法构造的系统具有更好的复用性,其关键在于建立一个全面、合理、统一的模型(用例模型和分析模型)。
- OO方法也划分阶段,但其中的系统分析、系统设计和系统实现三个阶段之间已经没有“缝隙”。也就是说,这三个阶段的界限变得不明确,某工作既可以在前一个阶段完成,也可以在后一个阶段完成;前一个阶段工作做得不够细,在后一个阶段可以补充。
- 面向对象方法可以普遍适用于各类信息系统的开发。
面向对象方法的不足之处
必须依靠一定的面向对象技术支持,在大型项目的开发上具有一定的局限性,不能涉足系统分析以前的开发环节。
当前,一些大型信息系统的开发,通常是将结构化方法和OO方法结合起来。首先,使用结构化方法进行自顶向下的整体划分;然后,自底向上地采用OO方法进行开发。因此,结构化方法和OO方法仍是两种在系统开发领域中相互依存的、不可替代的方法。
基本概念
实体类映射需求中的每个实体,实体类保存需要存储在永久存储体中的信息。
边界类用于封装在用例内、外流动的信息或数据流。
控制类是用于控制用例工作的类,用于对一个或几个用例所特有的控制行为进行建模。
-
对象。是指一组属性及这组属性上专用操作的封装体。由 对象名、属性、操作(方法) 组成。
-
类。类是一组具有相同属性和方法的对象的集合。一个类中的每个对象都是这个类的一个实例(instance)。由类名、属性、操作(方法)组成;类是面向对象类型扩展的重要机制,利用属性和方法将数据和与数据相关的行为封装起来
-
继承。继承是在某个类的层次关联中不同的类共享属性和方法的一种机制。父类与子类的关系是一般与特殊的关系,一个父类可以有多个子类,这些子类都是父类的特例。父类描述了这些子类的公共属性和方法,子类还可以定义它自己的属性和方法。一个子类只有唯一的父类,这种继承称为单一继承;一个子类有多个父类,可以从多个父类中继承特性,这种继承称为多重继承。对于两个类A和B,如果A是B的子类,则B是A的泛化(generalization)。继承是OO方法区别于其他方法的一个核心思想。
-
封装。面向对象系统中的封装单位是对象,对象之间只能通过接口进行信息交流,对象外部不能对对象中的数据随意地进行访问。封装的目的是使对象的定义和实现分离,能减少耦合,类内部的实现可以自由改变而不会影响其他的类或对象。类具有严密的接口保护,使对象的属性或服务不会随意地被使用,对象的状态易于控制,可靠性随之增强。
-
消息。消息是对象之间通信的手段,一个对象通过向另一个对象发送消息来请求其服务。一个消息通常包括以下信息:提供服务的对象标识、服务类型和相关参数(输入信息和回答信息)。只告诉接收对象需要完成什么操作,但不指示如何完成,完全由接收者解释。
-
多态。多态是指同一个操作作用于不同的对象时可以有不同的解释,并产生不同的执行结果。
多态有多种不同的形式,其中参数多态(同一对象、方法能以一致的形式用于不同的类型)包含多态(定义于不同类中的同名方法的多态行为)统称为通用多态,
过载多态(同一方法名表示不同的功能)和强制多态(通过语义操作把一个属性的类型加以改变)称为特定多态。动态绑定:把过程调用与目标代码的连接推迟到程序运行时进行
静态绑定 :把过程调用与目标代码的连接放在程序运行前进行
3.2、结构化
结构化方法假定待开发的系统是一个结构化的系统,其基本思想是将系统的生命周期划分为系统规划、系统分析、系统设计、系统实施、系统维护等阶段。这种方法遵循系统工程原理,按照事先设计好的程序和步骤,使用一定的开发工具,完成规定的文档,在结构化和模块化的基础上进行信息系统的开发工作。
结构化方法的开发过程一般是先把系统功能视为一个大的模块,再根据系统分析与设计的要求对其进行进一步的模块分解或组合。其精髓是自顶向下、逐步求精和模块化设计。
主要特点
- 开发目标清晰化。结构化方法的系统开发遵循“用户第一”的原则。开发中要保持与用户的沟通,取得与用户的共识,这使得信息系统的开发建立在可靠的基础之上。
- 开发工作阶段化。结构化方法每个阶段的工作内容明确,注重对开发过程的控制。每个阶段工作完成后,要根据阶段工作目标和要求进行审查,这使各阶段工作有条不紊地进行,便于项目管理与控制。
- 开发文档规范化。结构化方法每个阶段工作完成后,要按照要求完成相应的文档,以保证各个工作阶段的衔接与系统维护工作的便利。
- 设计方法结构化。在系统分析与设计时,从整体和全局考虑,自顶向下地分解;在系统实现时,根据设计的要求,先编写各个具体的功能模块,然后自底向上逐步实现整个系统。
缺点
- 开发周期长。采用结构化方法进行系统开发,按照顺序历经各个阶段,直到系统实施阶段结束后,用户才能使用系统。
- 难以适应需求变化。在信息系统项目中,用户需求的变化是不可避免的,然而,结构化方法要求系统分析师在系统分析阶段充分掌握和理解用户需求。
- 很少考虑数据结构。结构化方法是一种面向数据流的开发方法,比较注重系统功能的分解与抽象,兼顾数据结构方面不多。
3.3、面向服务的方法
面向对象、基于构件、面向服务是三个递进的抽象层次。
以粗粒度、松散耦合的系统功能为核心,强调系统功能的标准化和构件化,加强了系统的灵活性、可复用性和可演化性。
从概念上讲,SOA 中有三个主要的抽象级别:
- 操作:代表单个逻辑工作单元(LUW)的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA 操作可以直接与面向对象(00)的方法相比。它们都有特定的结构化接口,并且返回结构化的响应。操作位于最底层。
- 服务:代表**操作的逻辑分组。**例如,如果我们将客户画像视为服务,则按照电话号码查找客户、 按照名称和邮政编码列出顾客和保存新客户的数据就代表相关的操作。
- 业务流程:为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。业务流程的例子有: 接纳新员工、 出售产品或服务和完成订单。
3.4、原型化
原型化方法也称为快速原型法,它是一种根据用户初步需求,利用系统开发工具,快速地建立一个系统模型展示给用户,在此基础上与用户交流,最终实现用户需求的信息系统快速开发的方法。
在获得一组基本需求说明后,通过快速分析构造出一个小型的系统,满足用户的基本要求,使得用户可在试用原型系统的过程中得到亲身感受和受到启发,做出反应和评价,然后开发者根据用户的意见对原型加以改进。随着不断试验、纠错、使用、评价和修改,获得新的原型版本,如此周而复始,逐步减少分析和通信中的误解,弥补不足之处,进一步确定各种需求细节,适应需求的变更,从而提高了最终产品的质量。
按是否实现功能分类:
水平原型(行为原型)用来探索预期系统的一些特定行为,并达到细化需求的目的。只是功能的导航,未实现功能。用在界面上;
垂直原型(结构原型)实现了一部分功能。用在复杂的算法实现上。
按最终结果分类:
抛弃式原型:达到预期目的后,原型本身被抛弃。主要用在解决需求不确定性、二义性、不完整性、含糊性等;
演化式原型:为开发增量式产品提供基础,逐步将原型演化成最终系统。主要用在必须易于升级和优化的场合,适用于Web项目。
开发步骤
- 确定用户基本需求。这些需求可能是不完全的、粗略的,但却是最基本的、易于描述和定义的。
- 设计系统初始原型。在快速分析的基础上,根据基本需求,尽快实现一个可运行的系统。
集成原则(尽可能用现有系统和模型来构成,这需要相应的原型工具)和 最小系统原则(耗资一般不超过总投资的10%)。 - 试用和评价原型。用户在开发人员的协助下试用原型,根据实际运行情况,评价系统的优点和不足,指出存在的问题,进一步明确用户需求,提出修改意见。
- 修正和完善原型。根据修改意见和新的需求进行修改。开发人员和用户在一次次的迭代过程中不断将原型完善,以接近系统的最终要求。
- 整理原型和提供文档。如果经过修改或改进的原型,得到参与者一致认可,则原型开发的迭代过程可以结束。
原型法的特点
- 原型法可以使系统开发的周期缩短、成本和风险降低、速度加快,获得较高的综合开发效益。
- 原型法是以用户为中心来开发系统的,用户参与的程度大大提高,开发的系统符合用户的需求,因而增加了用户的满意度,提高了系统开发的成功率。
- 由于用户参与了系统开发的全过程,对系统的功能和结构容易理解和接受,有利于系统的移交,有利于系统的运行与维护。
原型法的不足之处
- **开发的环境要求高。**开发人员和用户的素质、系统开发工具。成败的关键及效率的高低,在于原型构建的速度。
- **管理水平要求高。**系统的开发缺乏统一的规划和开发标准,难以对系统的开发过程进行控制。例如,如何确定用户的满意程度,如何控制对系统原型的修改次数等,都是较难协调的问题。
原型法的优点主要在于能更有效地确认用户需求。从直观上来看,原型法适用于那些需求不明确的系统开发。
目前的原型法不是一种独立的系统开发方法,而只是一种开发思想。
4、系统分析和需求工程
4.1、需求层次
- 业务需求:反映企业或客户对系统高层次的目标要求。通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。
- 用户需求:用户的具体目标,或用户要求系统必须能完成的任务。用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式,对用户使用的场景进行整理,从而建立用户需求。
- 系统需求:从系统的角度来说明软件的需求,包括功能需求、非功能需求和设计约束等。
功能需求(开发人员必须实现的功能,用户利用这些功能来完成任务,满足业务需要)、
非功能需求(系统必须具备的属性或品质,性能需求、软件质量属性)、
设计约束(为限制条件或补充规约,通常是对系统的一些约束说明)。
质量功能部署:将用户要求转化成软件需求的技术
- 常规需求:需求明确规定的功能。
- 期望需求:除了基本需求外,客户认为理所应当包含在内的其他功能。
- 意外需求:客户未要求的其他功能需求,会浪费项目开发时间和成本。
4.2、需求获取
- 用户访谈 :1对1、1对3;有代表性的用户;其形式包括结构化和非结构化两种。
结构化是指事先准备好一系列问题,有针对地进行;
非结构化则是只列出一个粗略的想法,根据访谈的具体情况发挥。
优点:具有良好的灵活性,有较宽广的应用范围。
缺点:记录较为困难,难以安排时间,对系统分析师有较高的要求。 - 问卷调查:用户多,不可能一一访谈。
优点:在短时间内,以低廉的代价从大量的回答中收集数据。结果比较好整理和统计。
缺点:缺乏灵活性;没有机会立即澄清对问题有含糊或错误的回答;不认真对待,从而使得反馈的信息不全面。 - 采样:从种群中系统地选出有代表性的样本集的过程。
样本大小=α ×(可信度系数/可接受的错误)²
α称为启发式因子,一般取值为0.25;
优点:加快了数据收集的过程,提高了效率,降低了开发成本。
缺点:样本选择不好就会有偏差,对系统分析师有较高的要求。 - 情节串联板 :一系列图片,通过这些图片来讲故事。
优点:用户友好、交互性强,对用户界面提供了早期的评审。
缺点:花费的时间很多,使需求获取的速度大大降低。 - 联合需求计划 JRP:它通过联合各个关键用户代表、系统分析师、开发团队代表一起,通过有组织的会议来讨论需求。
优点:发挥用户与管理人员在系统开发过程的积极性,提高开发效率,降低需求获取的时间成本,特别适合需求不清晰有歧义的问题,具有原型化开发方法的特点。
缺点:比较考验会议的组织和相关人员的能力,要气氛开放。 - 需求记录技术:任务卡片、场景说明、用户故事和Volere白卡。
个人理解:用户参与的就选用户访谈;涉及到各种人员而且还强调多选择问卷;
从已有的,已存在的选择实地考察,如果还要分析原因就只能选JRP或者用户访谈了。
谈及到改进、增加就是还没有实现的功能,用JRP;
解决冲突,需求不明确,JRP。
4.3、需求分析
把杂乱无章的用户要求和期望转化为用户需求,这就是需求分析的工作。
4.3.1、需求分析的工作
绘原可优魔术QFD
- 绘制系统上下文范围关系图:用于定义系统与系统外部实体间的界限和接口的简单模型,它可以为需求确定一个范围。
- 创建用户界面原型:帮助用户更好地理解所要解决的问题,更好地理解系统。
- 分析需求的可行性:进行成本、性能和技术实现方面的可行性研究,以及是否有冲突,有对外的依赖关系。
- 确定需求的优先级:需求的优先级是制订迭代计划的一个最重要的依据。
- 为需求建立模型:逻辑模型。图形化地描述需求将使得其更加清晰、易懂。OOA中的用例模型和领域模型,SA中的DFD和E-R图。
- 创建数据字典。对系统用到的所有数据项和结构进行定义,以确保开发人员使用了统一的数据定义。
- 使用QFD(质量功能部署)。升华,将产品特性、属性与对用户的重要性联系起来。
需求分析的方法
4.3.2、问题域PDOA
助记:强描述,少建模,关注问题域,解系统待求行为,收集基收集详并文档说需求。
他核心问题框架,域分关联子域,他目标大量获取有关域信息
他特点定位域需求,通过域分类,提供问题指南,成果是域的描述和需求列表
- 更多地强调描述,而少强调建模。
- 关注问题域。用一个文档对含有的问题域进行相关的描述,并列出需要在该域中求解的问题列表,也就是需求列表。只有这个文档是在分析时产生的。
- 关注解系统(即系统实现)的待求行为。用一个文档对解系统的待求行为进行描述。该文档将在需求定义阶段完成。
- 问题框架是PDOA的核心元素
在PDOA方法中,对整个过程有着一个清晰的定义:
- 收集基本的信息并开发问题框架,以建立问题域的类型。
- 在问题框架类型的指导下,进一步收集详细信息,并给出一个问题域相关特性的描述。
- 基于以上两点,收集并用文档说明新系统的需求
问题框架是PDOA的核心元素,是将问题域分为一系列相互关联的子域,而一个子域可以是那些可能算是精选出来的问题域的一部分。也可以把问题框架看作是开发上下文范围关系图,但不同的是,上下文范围关系图的建模对象是针对解系统,而问题框架则是针对问题域。也就是说,问题框架的目标就是大量地获取更多有关问题域的信息。
PDOA的特点是重新将重点定位在问题域和需求上,通过对问题域的分类,向系统分析师提供具体问题的相关指南。并且它将规格说明作为另外的任务处理,它的成果只是一份问题域的全面描述和一份需求列表而已。PDOA丰富和完善了SA和OOA方法,然而人们对它的了解和掌握还有一定的距离。
4.3.3、结构化SA
基本思想是自顶向下,逐层分解,把一个大问题分解成若干个小问题,每个小问题再分解成若干个更小的问题。经过逐层分解,每个最低层的问题都是足够简单、容易解决的,于是复杂的问题也就迎刃而解了。
- 特点:自顶向下,逐步分解,面向数据,强调分析对象的数据流。
- SA方法分析模型的核心是数据字典,围绕这个核心,有三个层次的模型
- 三大模型:功能模型(数据流图DFD,就是上下文联系图)、行为模型(状态转换图)、数据模型(E-R图)
数据流图DFD
助记:数据流图,表达数据流动,通过数据流描述系工
数据传递加工角度,逐层系分描各个部件功能数据传递情况,说明系工
他作用,理解表达需求工具,描述系统内逻,存档文字材料
DFD是SA方法中的重要工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。
DFD从数据传递和加工的角度,通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况,来说明系统所完成的功能。
主要作用
- DFD是理解和表达用户需求的工具,是需求分析的手段。由于DFD简明易懂,不需要任何计算机专业知识就可以理解它,因此,系统分析师可以通过DFD与用户进行交流。
- DFD概括地描述了系统的内部逻辑过程,是需求分析结果的表达工具,也是系统设计的重要参考资料,是系统设计的起点。
- DFD作为一个存档的文字材料,是进一步修改和充实开发计划的依据。在信息系统开发中,如果采用结构化方法,则一般将DFD作为需求规格说明书的一个组成部分。
画DFD
顶层图用来描述系统有什么输入和输出数据流,与哪些外部实体直接相关,可以把整个系统的范围勾画出来。
对顶层图进行的分解,其实就是对加工进行更细化的描述。
- 所有图形符号只限于4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点);
每个元素都必须有名字。 - 每个加工至少有一个输入数据流和一个输出数据流,而且要保持数据守恒。
黑洞:一个加工只有输入数据流而无输出数据流。
白洞:一个加工只有输出数据流而无输入数据流。
灰洞:若一个加工的输入数据流无法通过加工产生输出流。 - 在DFD中,需按层给加工编号。编号表明了该加工处在哪一层,以及上下层的父图与子图的对应关系。
- 规定任何一个DFD子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
- 在整套DFD中,每个数据存储必须既有读的数据流,又有写的数据流。但是在某张子图中,可能只有读没有写,或者只有写没有读。
- 可以在DFD中加入物质流,帮助用户理解DFD,但不可夹带控制流。
状态转换图
助记:大多业务数据驱动,实时控制系事件驱动,行为模型最有效描述
通过描述系统状态和引起它转换事件,表示系统行为。
大多数业务系统是数据驱动的,所以适合使用DFD。但是,实时控制系统却主要是事件驱动的,因此,行为模型是最有效的描述方式。STD通过描述系统的状态和引起系统状态转换的事件,来表示系统的行为。此外,STD还指出了作为特定事件的结果将执行哪些动作(例如,处理数据等)。
状态是任何可以被观察到的系统行为模式,每个状态代表系统的一种行为模式
事件是在某个特定时刻发生的事情,它是对引起系统从一个状态转换到另一个状态的外界事件的抽象。
事件就是引起系统状态转换的控制信息。
数据字典
助记:DFD描述系统分解,由几部分组成,各部分联系,但,数据详内无法反映
数据字典在它基础,对它出现元素加定义,有确切解释。相互配合,从图文两方面对系统逻辑模型完整描述
DFD描述了系统的分解,即系统由哪几部分组成,各部分之间的联系等,但是,对于数据的详细内容却无法在DFD中得到反映。
数据字典是在DFD的基础上,对DFD中出现的所有命名元素都加以定义,使得每个图形元素的名字都有一个确切的解释。DFD和数据字典等工具相配合,就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。
数字字典与DFD一起使用,可以帮助开发人员更好地理解系统中各个数据元素的含义和属性,从而更好地设计和开发系统。同时,数字字典也可以帮助开发人员更好地进行数据管理和维护工作,提高系统的可靠性和效率。
数据字典的条目:元素结构流,存储加逻外部实体
- 数据元素。数据元素也称为数据项,是数据的最小组成单位。例如,课程号、课程名等。
- 数据结构。数据结构用于描述某些数据元素之间的关系,它是一个递归的概念,一个数据结构可以包括若干个数据元素或(和)数据结构。数据结构的描述重点是数据元素之间的组合关系,即说明数据结构包括哪些成分。
有三种特殊情况,分别是任选项、必选项和重复项。
任选项是可以出现也可以省略的项,用“[]”表示;
必选项是在两个或多个数据元素中,必须出现其中的一个。用“{}”括起来。
重复项是可以多次出现的数据项,“ 课程细节* ”。 - 数据流。数据流由一个或一组数据元素组成,对数据流的描述应包括数据流的名称、编号、简要说明、来源、去处、组成和流通量(含高峰时期的流通量)。
- 数据存储。数据存储的条目主要描写该数据存储的结构,以及有关的数据流和查询要求。
- 加工逻辑。需要描述加工的编号、名称、功能的简要说明、有关的输入数据流和输出数据流。
- 外部实体。外部实体是数据的来源和去向,对外部实体的描述应包括外部实体的名称、编号、简要说明、外部实体产生的数据流和系统传给该外部实体的数据流,以及该外部实体的数量。
作用
- 按各种要求列表。可以根据数据字典,把所有数据条目按一定的顺序全部列出,保证系统设计时不会遗漏。
- 相互参照,便于系统修改。
- 由描述内容检索名称。
- 一致性检验和完整性检验。
E-R 模型
数据模型的三要素:数据结构、数据操作、数据的约束条件。
在 E-R 模型中,使用椭圆表示属性(一般没有)、长方形表示实体、菱形表示联系,联系的两端要填写联系类型。
联系类型:一对一 1:1、一对多 1:N、多对多 M:N。
属性分类:简单属性和复合属性(属性是否可以分割)、单值属性和多值属性(属性有多个取值)、NULL属性(无意义)、派生属性(可由其他属性生成)。
E-R模型如何转换为关系模型(实际就是转换为多少张表)
每个实体都对应一个关系模式;
联系分为三种:1:1联系中,联系可以放到任意的两端实体中,作为一个属性(要保证 1:1 的两端关联);
1:N 的联系中,联系可以单独作为一个关系模式,也可以在 N 端中加入1端实体的主键;
M:N 的联系中,联系必须作为一个单独的关系模式,其主键是M和N端的联合主键。
4.3.4、面向对象OOA
OOA的基本任务是运用OO方法,对问题域进行分析和理解,正确认识其中的事物及它们之间的关系,找出描述问题域和系统功能所需的类和对象,定义它们的属性和职责,以及它们之间所形成的各种联系。最终产生一个符合用户需求,并能直接反映问题域和系统功能的OOA模型及其详细说明。
面向对象的分析:是为了确定问题域,理解问题。包含五个活动:认织想操内
- 认定对象、
- 组织对象、
- 描述对象间的相互作用、
- 确定对象的操作、
- 定义对象的内部信息。
统一建模语言
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。
UML结构的三个部分
- 构造块:UML有三种基本的构造块,分别是事物、关系和图。事物是UML的重要组成部分,关系把事物紧密联系在一起,图是多个相互关联的事物的集合。
- 公共机制:公共机制是指达到特定目标的公共UML方法,主要包括规格说明(详细说明)、修饰、公共分类(通用划分)和扩展机制4种。
规格说明:事物语义的细节描述,它是模型真正的核心;
修饰:UML为每个事物设置了一个简单的记号,还可以通过修饰来表达更多的信息。
公共分类:类与对象(类表示概念,而对象表示具体的实体)、接口与实现(接口用来定义契约,而实现就是具体的内容);
扩展机制:包括约束、构造型和标记值。 - 规则:规则是构造块如何放在一起的规定,包括为构造块命名;给一个名字以特定含义的语境,即范围;怎样使用或看见名字,即可见性;事物如何正确、一致地相互联系,即完整性;运行或模拟动态模型的含义是什么,即执行。
视图:
- 逻辑视图。逻辑视图也称为设计视图,它表示了设计模型中在架构方面具有重要意义的部分,即类、子系统、包和用例实现的子集。
- 进程视图。进程视图是可执行线程和进程作为活动类的建模,它是逻辑视图的一次执行实例,描述了并发与同步结构。
- 实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
- 部署视图。部署视图把构件部署到一组物理节点上,表示软件到硬件的映射和分布结构。
- 用例视图。用例视图是最基本的需求分析模型。
事务:
- 结构事物:模型的静态部分,代表概念上或物理上的元素。如类、接口、协作、用例、活动类、构件和节点。;
- 行为事物:模型的动态部分,代表时间和空间上的动作。如交互、状态机;
- 分组事物:模型的组织部分,模型可以在其中进行分解。如包;
- 注释事物:模型的解释部分,依附于一个元素或一组元素之上对其进行约束或解释的简单符号。
关系:
箭头:两个事物之间是内部关系就是实线,比如关联和泛化。 一个事物的改变影响另外的事物就是实心
-
依赖:两个事物之间的语义关系,其中一个事物发生变化会影响另一个事物的语义。(包含和扩展本质也是依赖)
使用关系,即一个类的实现需要另一个类的协助。
【箭头指向】带普通箭头的虚线,普通箭头指向被使用者。- - - - - ▶ -
关联:描述一组对象之间连接的结构关系。
拥有关系:它使得一个类知道另一个类的属性和方法。
【箭头指向】带普通箭头的实线,指向被拥有者。双向关联可以没有箭头。**一一▶ 或者 就是一根直线 **分为组合和聚合,都是部分和整体的关系,其中组合事物之间关系更强。
【聚合关系】是一种整体与部分的关系。且部分可以离开整体而单独存在。
【箭头指向】带空心菱形的实线,空心菱形指向整体。一一◇【组合关系】是一种整体与部分的关系。但部分不能离开整体而单独存在
【箭头指向】带实心菱形的实线,实心菱形指向整体。一一◆ -
泛化:一般/特殊的关系,描述特殊元素的对象可替换一般元素的对象。
继承关系:表示子类继承父类的所有特征和行为。
【箭头指向】带三角箭头的实线,箭头指向父类。一一▷ -
实现:实现是类之间的语义关系,其中的一个类指定了由另一个类保证执行的契约。
类与接口的关系:表示类是接口所有特征和行为的实现。
【箭头指向】带三角箭头的虚线,箭头指向接口。- - - - -▷
图:
-
◉类图:静态图,描述一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中,最常见的图就是类图。类图给出了系统的静态设计视图,活动类的类图给出了系统的静态进程视图。
实体类映射需求中的每个实体,实体类保存需要存储在永久存储体中的信息。
边界类用于封装在用例内、外流动的信息或数据流。
控制类是用于控制用例工作的类,用于对一个或几个用例所特有的控制行为进行建模。是最常见的:有各种关系,1对多的关联
-
对象图:静态图,描述某一时刻一组对象及它们之间的关系,对象图描述了在类图中所建立的事物实例的静态快照。和类图一样,这些图给出系统的静态设计视图或静态进程视图,但它们是从真实案例或原型案例的角度建立的。
实例化后的名称:类名,它们之间的关系
-
构件图(组件图):静态图,描述一个封装的类和它的接口、端口,以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说,构件图是很重要的。构件图是类图的变体。
构件是可复用的模块,一个构件可能是由多个类组成的,掌握上供接口,需接口
-
组合结构图:静态图,描述结构化类(例如,构件或类)的内部结构,包括结构化类与系统其余部分的交互点。它显示联合执行包含结构化类的行为的构件配置。组合结构图用于画出结构化类的内部内容。
-
◉用例图:静态图,描述了一组用例、参与者以及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。
包含关系使用符号**《include》,当可以从两个或两个以上的原始用例中提取公共行为**,或发现能够使用一个构件来实现某一个用例很重要的部分功能时。其中这个提取出来的公共用例称为抽象用例。。 -----《include》---->
扩展关系使用符号**《extend》,如果一个用例明显地混合了两种或两种以上的不同场景**,即根据情况可能发生多种事情,则可以断定将这个用例分为一个主用例和一个或多个辅用例进行描述可能更加清晰。<-----《extend》----**
泛化关系,子用例继承父用例所有结构、行为和关系。 -
序列图(顺序图):交互图,交互图展现了一种交互,它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。
描述了以时间顺序组织的对象之间的交互活动。强调消息的时间次序的交互图。同步消息(进行阻塞调用,调用者中止执行,等待控制权返回,需要等待返回消息,用实心三角箭头表示),
异步消息(发出消息后继续执行,不引起调用者阻塞,也不等待返回消息,由空心箭头表示)
返回消息(由从右到左的虚线箭头表示)它的旁边有生存期,对象放在上面,编号1调哪个对象的接口,2又调哪个对象的接口
-
通信图(协作图):交互图,强调收发消息的对象或参与者的结构组织。
顺序图强调的是时序,通信图则强调消息流经的数据结构。编号1调哪个对象的接口,2又调哪个对象的接口,没有生存期,对象也可以随便放,所以它强调的是结构组织。
-
定时图:交互图,强调消息跨越不同对象或参与者的实际时间,而不仅仅只是关心消息的相对顺序。
生命线,下方有时间刻度
-
◉状态图:动态图,描述一个状态机,它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要,而且它强调事件导致的对象行为,这非常有助于对反应式系统建模。
包括简单状态和组合状态。
转换可以通过事件触发器触发,事件触发后相应的监护条件会进行检查。
状态图中转换和状态是两个独立的概念,方框代表状态,箭头上的代表触发事件,实心圆点为起点和终点。开始是什么状态,通过事件,转移成了另一个状态,它们之间的活动。
-
◉活动图:动态图**,将进程或其他计算结构展示为计算内部一步步的控制流和数据流。**
活动图专注于系统的动态视图。它对系统的功能建模特别重要,并强调对象间的控制流程。活动的分岔和汇合线是一条水平粗线。牢记并发分岔、并发汇合、监护表达式、分支、流等名词及含义。
每个分岔的分支数代表了可同时运行的线程数。 -
部署图:静态图,描述对运行时的处理节点及在其中生存的构件的配置。
部署图给出了体系结构的静态部署视图,通常一个节点包含一个或多个部署图。 -
包图:静态图,描述由模型本身分解而成的组织单元,以及它们之间的依赖关系。
用例模型
从用户的角度来看,他们并不想了解系统的内部结构和设计,他们所关心的是系统所能提供的服务,这就是用例方法的基本思想。用例方法是一种需求合成技术,采用获取需求(方法),记录下来,然后从这些零散的要求和期望中进行整理与提炼,从而建立用例模型。
构建用例模型一般需要经历4个阶段,分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型。
分析模型
对系统进行了用例建模,但捕获了用例并不意味着分析的结束,还要对需求进行深入分析,获取关于问题域本质内容的分析模型。分析模型描述系统的基本逻辑结构,展示对象和类如何组成系统(静态模型),以及它们如何保持通信,实现系统行为(动态模型)。
建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等。
4.4、需求分析方法的对比
SA方法关注于功能的分层和分解,这非常符合人们自上而下、逐步分解问题直到可解决的自然思考方式。SA方法本身隐含着几个基本假设,即问题域是可定义的、问题域是有限的、通过有限的步骤总可以将复杂问题分解到可解决的程度。
OOA方法则遵循完全不同的思维方式,它基于抽象、信息隐藏、功能独立和模块化这些基本理念对系统进行分析。OOA方法首先对问题域的事物的**“外在表象”进行观测,然后在逻辑世界中模拟出一个对应的逻辑对象**,“断定”该对象和现实事物是一致的。随后,观测到的对象被记录入对象集合,观测到的行为和表象被记录入对象关系模型和对象行为模型。
SA方法假定系统分析师理解问题域的全部,并且有能力正确地识别和分解问题。而OOA方法既不假定系统分析师理解问题域的全部,也不假定其能够建立正确的抽象对象,它只承诺一种可以持续“观测并理解”的方法,以及“观测后建立”的对象和现实世界的外在表象是一致的。
PDOA的特点是重新将重点定位在问题域和需求上,通过对问题域的分类,向系统分析师提供具体问题的相关指南。并且它将规格说明作为另外的任务处理,它的成果只是一份问题域的全面描述和一份需求列表而已。PDOA丰富和完善了SA和OOA方法。
4.5、需求定义与验证
- 严格定义法:需求预先定义,开发用户清晰交流,图文体现系统
也称为预先定义,需求的严格定义建立在以下的基本假设之上:
(1)前提是所有需求都能够被预先定义;
(2)开发人员与用户之间能够准确而清晰的交流;
(3)采用图形 / 文字可以充分体现最终系统。 - 原型法:并非需求所有能说明,交流困难,需要可供用户参与系统,合适开发环境,反复
是一种迭代的循环型的开发方式。
(1)并非所有的需求都能在开发前被准确的说明;
(2)项目干系人之间通常都存在交流上的困难
(3)需要实际的、可供用户参与的系统模型;
(4)有合适的系统开发环境;
(5)反复是完全需要和值得提倡的,需求一旦确定,就应遵从严格的方法。
软件需求规格说明书 SRS
编写方式:结构化文本,图形化模型,形式化规格说明
- 用好的结构化和自然语言编写文本型文档。
- 建立图形化模型,这些模型可以描述转换过程、系统状态及其变化、数据关系、逻辑流、对象类及其关系。
- 编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求。
内容:范围,引用文件,需求,合格性规定,需求可追踪性,尚未解决的问题,注解,附录。
通俗答法:系统应该提供的功能和服务;非功能需求,包括系统的特征、特点和属性;限制系统开发或者系统运行必须遵守的约束条件;系统必须连接的其他系统的信息。
作用:系统所有者和用户使用需求定义文档来确认需求以及任何可能产生的变化,并作为验收依据;系统分析人员、设计人员和构造人员使用它来理解需要什么以及处理需求变更,开发用于验证系统的测试用例;项目经理使用它作为制定项自计划、处理变更及验收的依据。
需求验证也称为需求确认,其活动是为了确定以下几个方面的内容:
(1)SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
(2)SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
(3)需求是完整的和高质量的。
(4)需求的表示在所有地方都是一致的。
(5)需求为继续进行系统设计、实现和测试提供了足够的基础。
4.6、需求评审
在软件开发的每个阶段结束前,都需要进行技术评审。所谓技术评审,是指对工作产品进行检查以发现产品中所存在的问题。
需求评审就是需求开发阶段结束前进行的技术评审,此时的产品就是SRS。SRS的评审是一项精益求精的技术,它可以发现那些二义性的或不确定性的需求,为项目干系人提供在需求问题上达成共识的方法。
根据IEEE技术评审可以分为以下三种类型:
- 评审。评审是指一次正式的会议,在会议上向用户或其他项目干系人介绍一个或一组工作产品,以征求对方的意见和批准。
- 检查。检查是一种正式的评估方法,将由非制作者本人的个人或小组详细检查工作产品,以验证是否有错误、是否违反开发标准、是否存在其他问题。
- 走查。走查是一个评审过程,由某个开发人员领导一个或多个开发团队成员对他(或她)的工作产品进行检查,由其他成员针对技术、风格、可能的错误、是否违反开发标准和其他问题提出意见。
技术评审可以分为正式评审和非正式评审。
- 正式评审是指通过召开评审会的形式,组织多个专家,将工作产品涉及到的人员集合在一起,并定义好评审人员的角色和职责,对工作产品进行正规的会议评审。
- 非正式评审并没有这种严格的组织形式,一般也不需要将人员集合在一起评审,而是通过电子邮件、文件汇签,甚至是网络聊天等多种形式对工作产品进行评审。
对于获得分散而随机的反馈是有效的,但非正式评审是非系统化的、不彻底的,它在实施过程中具有不一致性。
正式评审需要遵循预先定义好的一系列步骤和过程。正式评审的内容需要记录在案,包括确定材料,评审小组对工作产品是否完整或者是否需要进一步工作的判定,以及对所发现的错误和所提出的问题的总结。
正式评审的过程:是一种结构化的评审技术,一般通过会议的形式来进行评审
- 计划。首先要对评审制订计划,以确定评审的重点和范围,并确保所有参与者理解自己的角色和评审的目标。
- 准备。评审之前,应该收集要评审的工作产品和所有背景材料,并分发给评审参与者。
- 进行评审。要进行成功的评审,首先,评审小组人员应理解评审流程,理解自己的角色。评审流程是一个重复进行的循环过程,包括评审员提出问题,讨论问题,同时对问题进行确认,确定缺陷(确定需要解决的地方),直到没有确定的问题时再继续下一步;要注意确定问题而不要试图解决问题,要对所有问题和讨论做好记录。
- 对评审结果采取行动。评审结束时,要确定问题列表的优先顺序,并跟踪问题及其解决办法。
如何做好需求评审
- 分层次评审。用户的需求是分层次的,对不同层次的需求,其描述形式是有区别的,参与评审的人员也是不同的。
- 正式评审与非正式评审相结合。
- 分阶段评审。应该在需求形成的过程中进行分阶段的评审,而不是在需求最终形成后再进行评审。
- 精心挑选评审人员。要保证使不同类型的人员都要参与进来,在不同类型的人员中要选择那些真正和系统相关的,对系统有足够了解的人员参与进来。
- 对评审人员进行培训。以便于评审人员能够紧紧围绕评审的目标来进行,能够控制评审活动的节奏,提高评审效率。
- 充分利用需求评审检查单。
需求形式的检查,主要检查SRS的格式是否符合质量标准;
需求内容的检查,主要检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等,这是需求评审的重点。 - 建立标准的评审流程。按照流程中定义的活动进行规范的评审过程。
- 做好评审后的跟踪工作。在需求评审后,需要根据评审人员提出的问题进行评价,以确定哪些问题是必须纠正的,哪些可以不纠正,并给出充分、客观的理由和证据。
- 充分准备评审。评审质量的好坏很大程度上取决于在评审会议前的准备活动。对评审的准备工作,也应当定义一个检查单,在评审之前对照检查单落实每项准备工作。
4.7、需求管理与变更
- 正向跟踪是指检查SRS中的每个需求是否都能在后继工作成果中找到对应点;
- 反向跟踪也称为逆向跟踪,是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。
- 箭头表示需求跟踪能力联系链,它能跟踪需求使用的整个周期,即从需求建议到交付的全过程。
需求风险管理
带有风险的做法
- 无足够用户参与。
- 忽略了用户分类。
- 用户需求的不断增加。
- 模棱两可的需求。
- 不必要的特性。
- 过于精简的SRS。
- 不准确的估算。系
5、软件架构
5.1、面向服务的架构
SOA设计原则
- 明确定义的接口。一旦公布,不能随意更改;不要让请求者看到服务内部的私有数据。
- 自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和构件,完全独立自主的,独立进行部署、版本控制、自我管理和恢复。
- 粗粒度。服务数量不应该太多,依靠消息交互而不是远程过程调用。
- 松耦合。服务请求者可见的是服务的接口,其位置、实现技术、当前状态和私有数据等,对服务请求者而言是不可见的。
- 互操作性、兼容和策略声明。
统一描述、发现和集成(Universal Description Discovery and Integration, UDDI)提供了一种服务发布、查找和定位的方法,是服务的信息注册规范,以便被需要该服务的用户发现和使用它。
Web服务描述语言(Web Service Description Language, WSDL)是对服务进行描述的语言,它有一套基于XML的语法定义。
简单对象访问协议(Simple Object Access Protocol, SOAP)定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息,用HTTP来承载消息。
表述性状态转移(Representational State Transfer, REST)是一种只使用HTTP和XML进行基于Web通信的技术,可以降低开发的复杂性,提高系统的可伸缩性。
- 网络上的所有事物都被抽象为资源。
- 每个资源对应一个唯一的资源标识。
- 通过通用的连接件接口对资源进行操作
- 对资源的各种操作不会改变资源标识。
- 所有的操作都是无状态的。
5.2、软件产品线
软件产品线是一个产品集合,这些产品共享一个公共的、可管理的特征集,这个特征集能满足特定领域的特定需求。软件产品线是一个十分适合专业的开发组织的软件开发方法,能有效地提高软件生产率和质量,缩短开发时间,降低总开发成本。
软件产品线主要由两部分组成,分别是核心资源和产品集合。核心资源是领域工程的所有结果的集合,是产品线中产品构造的基础。
核心资源:包括所有产品所共用的软件架构,通用的构件、文档等。
产品集合:产品线中的各种产品。
软件产品线的建立需要企业有意识的、长期的努力才有可能成功。采用产品线方式开发软件时,开发人员可以划分为两组,分别是负责核心资源的小组和负责产品的小组。这也是产品线开发与独立系统开发的主要区别。
不管采用哪种产品线的建立方式,企业要成功实施产品线,主要取决于以下因素:
(1)对要实施产品线的领域具备长期和深厚的经验。
(2)一个用于构建产品的好的核心资源库。
(3)好的产品线架构。
(4)好的管理(包括软件资源、人员组织和过程等)支持。
个人理解:如果公司未来要进入一个全新的领域,那就选择全新产品线。
演化就是时间长,成本高;革命比较省时间省金钱。
革命方式比演化方式更节省投资,更省时间,但只适用于需求明确且变动不大,不然风险很大。
5.3、净室软件工程
净室软件工程(Cleanroom Software Engineering, CSE)是软件开发的一种形式化方法,可以开发较高质量的软件。它使用盒结构归约进行分析和建模,并且将正确性验证作为发现和排除错误的主要机制,使用统计测试来获取认证软件可靠性所需要的信息
净室软件工程强凋在规约和设计上的严格性,以及使用基于数学的正确性来证明对设计模型的每个元素进行形式化验证。
5.4、软件工程(逆向)
- 软件复用是将已有软件的各种有关知识用于建立新的软件,以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用,被复用的知识专指程序,后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。
- 逆向工程:软件的逆向工程是分析程序,力图在比源代码更高抽象层次上建立程序的表示过程逆向工程是设计的恢复过程。
逆向工程的四个级别:
-
实现级:包括程序的抽象语法树、符号表、过程的设计表示。
-
结构级:包括反映程序分量之间相互依赖关系的信息,例如调用图、结构图、程序和数据结构。
-
功能级:包括反映程序段功能及程序段之间关系的信息,例如数据和控制流型。
-
领域级:包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息,例如E-R模型。
-
领域级抽象级别最高,完备性最低,实现级抽象级别最低,完备性最高。
-
抽象级别:与具体需求无关,抽象出来的上层逻辑概念。
-
完备性:与具体系统相关,具体系统需求是否完善,与抽象级别相反。
与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。
- 重构是指在同一抽象级别上转换系统描述形式。
- 设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
- 再工程是指在逆向工程所获得信息的基础上,修改或重构已有的系统,产生系统的一个新版本。再工程是对现有系统的重新开发过程,包括逆向工程、新需求的考虑过程和正向工程三个步骤。它不仅能从已存在的程序中重新获得设计信息,而且还能使用这些信息来重构现有系统,以改进它的综合质量。在利用再工程重构现有系统的同时,一般会增加新的需求,包括增加新的功能和改善系统的性能。
- 正向工程是指不仅从现有系统中恢复设计信息,而且使用该信息去改变或重构现有系统以改善其整体质量。
6、系统运行与维护
6.1、遗留系统
遗留系统(Legacy System)是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统,它通常具有以下特点:
(1)系统虽然完成企业中许多重要的业务管理工作,但仍然不能完全满足要求。一般实现业务处理电子化及部分企业管理功能,很少涉及经营决策。
(2)系统在性能上已经落后,采用的技术已经过时。例如,多采用主机/终端形式或小型机系统,软件使用汇编语言或第三代程序设计语言的早期版本开发,使用文件系统而不是数据库。
(3)通常是大型的软件系统,已经融入企业的业务运作和决策管理机制之中,维护工作十分困难。
(4)没有使用现代信息系统建设方法进行管理和开发,现在基本上已经没有文档,很难理解。
6.2、系统转换
系统转换是指新系统开发完毕,投入运行,取代现有系统的过程,需要考虑多方面的问题,以实现与老系统的交接。
有以下三种转换计划:
- 直接转换就是在原有系统停止运行的某一时刻,新系统立即投入运行,中间没有过渡阶段。(小型)
人力和费用最省,转换代价比较大 - 并行转换就是新系统和现有系统并行工作一段时间,经过这段时间的试运行后,再用新系统正式替换下现有系统。
风险较小,人力和费用消耗较大,转换的周期长,并且难以控制新旧系统中的数据变化。 - 分段转换策略也称为逐步转换策略,这种转换方式是直接转换方式和并行转换方式的结合,采取分期分批逐步转换。
转换震动比较小,用户容易接受。转换周期过长,需要开发新旧系统之间的接口。
6.3、数据转换与迁移
将数据从旧数据库迁移到新数据库中。
要在新系统中尽可能的保存旧系统中合理的数据结构,才能降低迁移的难度。
也有三种方法:
- 系统切换前通过工具迁移、利用ETL工具
- 系统切换前采用手工录入、
- 系统切换后通过新系统生成。
转换的过程称为ETL,有三个步骤:抽取(旧数据库数据)一转换(三种转换方法)一装载(装入新数据库,并校验数据)。
转换步骤一般还要包含数据清洗的过程,数据清洗主要是针对源数据库中,对出现二义性、重复、不完整、违反业务或逻辑规则等问题的数据进行相应的清洗操作。
数据迁移前的准备工作:待详新-代码旧映射,购买测试应急
- 待迁移数据源的详细说明,包括数据的存放方式、数据量和数据的时间跨度。
- 建立新旧系统数据库的数据字典,对现有系统的历史数据进行质量分析,以及新旧系统数据结构的差异分析。
- 新旧系统代码数据的差异分析。
- 建立新旧系统数据库表的映射关系,对无法映射字段的处理方法。
- 开发或购买、部署ETL工具。
- 编写数据转换的测试计划和校验程序。
- 制定数据转换的应急措施。
数据迁移后的校验:
对迁移后的数据进行质量分析;新旧系统查询数据对比检查
6.4、可维护性的评价指标
- 易测试性:指为确认经修改软件所需努力有关的软件属性;
- 易分析性:指为诊断缺陷或失效原因,或为判定待修改的部分所需努力有关的软件属性;
- 易改变性:指与进行修改、排错或适应环境变换所需努力有关的软件属性;
- 稳定性:指与修改造成未预料效果的风险有关的软件属性。
个人理解:可维护性,就是有新功能了,要你加上去。
6.5、软件维护类型
- 正确性维护:发现了 bug而进行的修改。
- 适应性维护:由于外部环境发生了改变,被动进行的对软件的修改和升级。
- 完善性维护:基于用户主动对软件提出更多的需求,修改软件,增加更多的功能,使其比之前的软件功能、性能更高,更加完善。
- 预防性维护:对未来可能发生的bug进行预防性的修改
7、项目管理
- 关键路径:是项目的最短工期,但却是从开始到结束时间最长的路径。进度网络图中可能有多条关键路径,因为活动会变化,因此关键路径也在不断变化中。
- 关键活动:关键路径上的活动,最早开始时间=最晚开始时间。
每个节点的活动会有如下几个时间:
- 最早开始时间ES:某项活动能够开始的最早时间。
- 最早结束时间EF:某项活动能够完成的最早时间。EF=ES+工期
- 最迟结束时间LF:为了使项目按时完成,某项活动必须完成的最迟时间。
- 最迟开始时间LS:为了使项目按时完成,某项活动必须开始的最迟时间。LS=LF-工期
◆顺推:最早开始ES=所有前置活动最早完成EF的最大值;最早完成EF=最早开始ES+持续时间。
◆逆推:最晚完成LF=所有后续活动最晚开始LS的最小值;最晚开始LS=最晚完成LF-持续事件。
◆总浮动时间(总时差、松弛时差):在不延误项目完工时间且不违反进度制约因素的前提下,活动可以从最早开始时间推迟或拖延的时间量,就是该活动的进度灵活性。正常情况下,关键活动的总浮动时间为零。
总浮动时间=最迟开始LS-最早开始ES 或 最迟完成LF-最早完成EF 或 关键路径-非关键路径时长
◆自由浮动时间:是指在不延误任何紧后活动的最早开始时间且不违反进度制约因素的前提下,活动可以从最早开始时间推迟或拖延的时间量。
◆自由浮动时间=紧后活动最早开始时间的最小值-本活动的最早完成时间
8、数据库
主要考法是新技术,nosql,内存SQL,反规范化技术或者结合web一起考。
8.1、基础
需求分析:即分析数据存储的要求和边界,产出物有数据流图、数据字典、需求说明书。
概念结构设计:设计用户的数据模型,与具体DBMS无关的概念模型,一般是设计E-R图,也即实体-属性图,与物理实现无关,就是说明有哪些实体,实体有哪些属性。
逻辑结构设计:将E-R图,转换成关系模式,也即转换成实际的表和表中的列属性,这里要考虑很多规范化的东西。
物理设计:根据生成的表等概念,生成物理数据库。
数据库性能优化:硬件升级、数据库设计、索引优化、查询优化。
数据库的完整性约束:实体完整性、参照完整性、用户定义完整性、触发器。
数据库的安全性
用户标识和鉴别:最外层的安全保护措施,可以使用用户账户、口令和随机数检验等方式。
存取控制(数据授权):对用户进行授权,包括操作类型(例如,查找、更新或删除等)和数据对象的权限。
密码存储和传输:对远程终端信息用密码传输。
视图的保护:通过视图的方式进行授权。
审计:使用一个专用文件或数据库,自动将用户对数据库的所有操作记录下来。
**视图(View)**是从一个或多个表(或视图)导出的表。视图与表不同,视图是一个虚表,即视图所对应的数据不进行实际存储,数据库中只存储视图的定义,在对视图的数据进行操作时,系统根据视图的定义去操作与视图相关联的基本表。
- 视图能简化用户的操作
- 视图机制可以使用户以不同的方式查询同一数据
- 视图对数据库重构提供了一定程度的逻辑独立性
- 视图可以对机密的数据提供安全保护
什么是数据的物理独立性?
答:物理独立性是指用户的应用程序与存储在磁盘上的数据库中的数据是相互独立的,当数据的物理存储改变时,应用程序不需要改变。物理独立性存在于概念模式和内模式之间的映射转换,说明物理组织发生变化时应用程序的独立程度。
什么是数据的逻辑独立性?
答:逻辑独立性是指用户的应用程序与数据库中的逻辑结构是相互独立的,当数据的逻辑结构改变时,应用程序不需要改变。逻辑独立性存在于外模式和概念模式之间的映射转换,说明概念模式发生变化时应用程序的独立程度。
8.2、NoSQL
Not-onlySQL:是一种非关系型的数据库,海量数据问题
关系数据库模式 | NoSQL模式 | |
---|---|---|
井发支持 | 支持井发、效率低 | 并发性能高 |
存储与查询 | 关系表方式存储、SQL查询 | 海量数据存储、查询效率高 |
扩展方式 | 向上扩展(增加硬件服务器) | 向外扩展(把数据切开,放到其他库上) |
索引方式 | B树、哈希等 | 键值索引 |
应用领域 | 面向通用领域 | 特定应用领域 |
数据一致性 | 实时 | 弱 |
数据类型 | 结构化 | 非结构化 |
事务 | 高 | 弱 |
水平扩展 | 弱 | 强 |
特点:成熟度不够,大量关键特性有待实现;开源数据库产品支持力度有限;数据挖掘与商务智能支持不足,现有的产品无法直接使用 NoSQL数据库;NOSQL专家少,大部分都处于学习阶段。
代表:Redis、MongoDB、Flare、Oracle NoSQL DB……
8.3、内存数据库
内存数据库抛弃了磁盘数据管理的传统方式,基于全部数据都在内存中重新设计了体系结构,并且在数据缓存、快速算法、并行操作方面也进行了相应的改进,所以数据处理速度比传统数据库的数据处理速度要快很多,一般都在10倍以上。
特点:工作版本常驻内存,活动事务只与实时内存数据库的内存拷贝打交道。
常见的内存数据库:、:Redis、SQLite、Mircrosoft SQLserver compact 等。
8.4、数据库分类比较
-
关系型数据库:关系数据库,是建立在关系模型基础上的数据库,借助合代数等数学概念和系均用关系模型来表方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种示。简单说,关系型数据库是由多张能互相联接的二维行列表格组成的数据库。
-
NoSQL:泛指非关系型的数据库。直着互联网的兴起,传统的关系数据库在应付超大规模和高并发的纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题,包括超大规模数据的存储。
-
内存数据库:将数据库整体存储在内存中,提高性能。
8.5、缓存技术
MemCache:Memcache 是一个高性能的分布式的内存对象缓存系统,用于动态 Web 应用以减轻数据库负载。
Memcache 通过在内存里维护一个统一的巨大的 hash 表,它能够用来存储各种格式的数据,包括图像、规频、文件以及数据库检索的结果等。
Redis:Redis 是一个开源的使用 ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库,并提供多种语言的 API。
Squid: Squid 是一个高性能的代理缓存服务器,Squid 支持 FTP,gopher、HTTPS 和 HTTP 协议。和一般的代理缓存软件不同,Squid 用一个单独的、非模块化的、I/O 驱动的进程来处理所有的客户端请求。
Redis与Memcache的差异
1、Redis 和 Memcache 都是将数据存放在内存中,都是内存数据库。他们都支持 key-value 数据类型。同时 Memcache 还可用于缓存其他东西,例如图片、现频等等,Redis 还支持 list、set、hash等数据结构的存储。
2、Redis 支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用,Memcache 挂掉之后,数据就没了。
3、灾难恢复:Memcache 挂掉后,数据不可恢复;Redis 数据丢失后可以恢复。
4、在 Redis 中,并不是所有的数据部一直存储在内存中的。这是和 Memcache 相比一个最大的区别。当物理内存用完时,Redis 可以将一些很久没用到的 value 交换到磁盘。
5、Redis 在很多方面支持数据库的特性,可以这样说他就是一个数据库系统,而 Memcache 只是简单地 K/V 缓存。
所以在选择方面如果有持久方面的需求或对数据类型和处理有要求的应该选择 Redis。
如果简单的 key/value 存储应该选择 Memcache。
8.6、并发控制
事务:由一系列操作组成,这些操作,要么全做,要么全不做。
拥有四种特性,详解如下:
- 原子性:要么全做,要么全不做。
- 一致性:事务发生后数据是一致的‘
- 隔离性:任一事务的更新操作直到其成功提交的整个过程对其他事务都是不可见的,不同事务之间是隔离的,互不干涉。
- 持续性:事务操作的结果是持续性的。
事务是并发控制的前提条件,并发控制就是控制不同的事务并发执行,提高系统效率,但是并发控制中存在下面三个问题:
丢失更新:事务1对数据A进行了修改并写回,事务2也对A进行了修改并写回,此时事务2写回的数据会覆盖事务1写回的数据,就丢失了事务1对A的更新。即对数据A的更新会被覆盖。
不可重复读:事务2读A,而后事务1对数据A进行了修改并写回,此时若事务2再读A,发现数据不对。即一个事务重复读A两次,会发现数据A有误。
读脏数据:事务1对数据A进行了修改后,事务2读数据A,而后事务1回滚,数据A恢复了原来的值,那么事务2对数据A做的事是无效的,读到了脏数据。
8.6.1、封锁协议
X锁是排它锁(写锁):若事务T对数据对象A加上X锁,则只允许T读取和修改 A,其他事务都不能再对A加任何类型的锁,直到T释放A上的锁。
其他锁都不能加了,只有它自己能读改,直到这个锁被释放了。
S锁是共享锁(读锁):若事务T对数据对象A加上S锁,则只允许T读取A,但不能修改 A,其他事务只能再对A加S锁(也即能读不能修改),直到T释放A上的S锁。
加了这个锁那么就不能加排它锁,可以加共享锁,直到这个锁被释放了才可以加排它锁,能读不能改。
三级封锁协议
一级封锁协议:事务在修改数据R之前必须先对其加X锁,直到事务结束才释放。可解决丢失更新问题。
二级封锁协议:一级封锁协议的基础上加上事务T在读数据R之前必须先对其加S锁,读完后即可释放S锁。可解决丢失更新、读脏数据问题。
三级封锁协议:一级封锁协议加上事务T在读取数据R之前先对其加S锁,直到事务结束才释放。可解决丢失更新、读脏数据、数据重复读问题。
注意:解锁的时间不同,会造成预防问题的个数不同,即为不同的封锁协议。
两段锁协议。所有事务必须分两个阶段对数据项加锁和解锁。其中扩展阶段是在对任何数据进行读、写操作之前,首先要申请并获得对该数据的封锁;收缩阶段是在释放一个封锁之后,事务不能再申请和获得任何其他封锁。若并发执行的所有事务均遵守两段封锁协议,则对这些事务的任何并发调度策略都是可串行化的。
遵守两段封锁协议的事务可能发生死锁。
8.7、不规范化带来的四大问题
设有一个关系模式R(SNAME,CNAME,TNAME,TADDRESS),其属性分别表示学生姓名、选修的课程名、任课教师姓名和任课教师地址。
仔细分析一下,就会发现这个式存在下列存储异常的问题:
- 数据冗余:数据被重复存储,如某门课程有100个学生选修,那么在R的关系中就要出现100个元组,这门课程的任课教师姓名和地址也随之重复出现100次。
- 修改异常:修改导致数据不一致,如由于上述冗余问题,当需要修改这个教师的地址时,就要修改100个元组中的地址值,否则就会出现地址值不一致的现象。
- 插入异常:插入时异常,如不知道听课学生名单,这个教师的任课情况和家庭地址就无法进入数据库。
- 删除异常:删除了不该删除的数据,如当只有一条记录时,要删除这个学生选课信息,会将课程名、教师名和教师地址都给删除了。
8.8、反规范化技术
反规范化技术:规范化设计后,数据库设计者希望牺牲部分规范化来提高性能。
采用反规范化技术的益处:降低连接操作的需求、降低外码和索引的数目,还可能减少表的数目,能够提高查询效率。
可能带来的问题:数据的重复存储,浪费了磁盘空间;可能出现数据的完整性问题,为了保障数据 的一致性,增加了数据维护的复杂性,会降低修改速度。
具体方法
- 增加冗余列:在多个表中保留相同的列,通过增加数据冗余减少或避免查询时的连接操作。
- 增加派生列:在表中增加可以由本表或其它表中数据计算生成的列,减少查询时的连接操作并避免计算或使用集合函数。
- 重新组表:如果许多用户需要查看两个表连接出来的结果数据,则把这两个表重新组成一个表来减少连接而提高性能。
- 水平分割表:根据一列或多列数据的值,把数据放到多个独立的表中,主要用于表数据规模很大、表中数据相对独立或数据需要有放到多个介质上时使用。
- 垂直分割表:对表进行分割,将主键与部分列放到一个表中,主键与其它列放到另一个表中,在查询时减少I/0次数。
8.9、分布式数据库
分布式数据库是由一组数据组成的,这组数据分布在计算机网络的不同计算机上,网络中的每个节点具有独立处理的能力(称为场地自治),它可以执行局部应用,同时,每个节点也能通过网络通信子系统执行全局应用。分布式数据库系统是在集中式数据库系统技术的基础上发展起来的
具有如下特点:
- 数据独立性。在分布式数据库系统中,数据独立性这一特性更加重要,并具有更多的内容。
除了数据的逻辑独立性与物理独立性外,还有数据分布独立性(分布透明性) - 集中与自治共享结合的控制结构。各局部的DBMS 可以独立地管理局部数据库,具有自治的功能。同时,系统又设有集中控制机制,协调各局部DBMS的工作,执行全局应用。
- 适当增加数据冗余度。在不同的场地存储同一数据的多个副本,这样,可以提高系统的可靠性和可用性,同时也能提高系统性能。
- 全局的一致性、可串行性和可恢复性。
优点
- 分布式数据库可以解决企业部门分散而数据需要相互联系的问题
- 如果企业需要增加新的相对自主的部门来扩充机构,则分布式数据库系统可以在对当前机构影响最小的情况下进行扩充。
- 分布式数据库可以满足均衡负载的需要
- 当企业已存在几个数据库系统,而且实现全局应用的必要性增加时,就可以由这些数据库自下而上构成分布式数据库系统。
- 相等规模的分布式数据库系统在出现故障的概率上不会比集中式数据库系统低,但由于其故障的影响仅限于局部数据应用,因此,就整个系统来说,它的可靠性是比较高的。
数据分片将数据库整体逻辑结构分解为合适的逻辑单位(片段),然后由分布模式来定义片段及其副本在各场地的物理分布,其主要目的是提高访问的局部性,有利于按照用户的需求,组织数据的分布和控制数据的冗余度。
- 水平分片。水平分片将一个全局关系中的元组分裂成多个子集,每个子集为一个片段。分片条件由关系中的属性值表示。对于水平分片,重构全局关系可通过关系的并操作实现。
- 垂直分片。垂直分片将一个全局关系按属性分裂成多个子集,应满足不相交性(关键字除外)。对于垂直分片,重构全局关系可通过连接运算实现。
- 导出分片。导出分片又称为导出水平分片,即水平分片的条件不是本关系属性的条件,而是其他关系属性的条件。
- 混合分片。混合分片是在分片中采用水平分片和垂直分片两种形式的混合。
分布式数据库查询优化
- 全局查询树的变换:例如,在做笛卡尔积之前,先进行投影和选择运算
- 副本的选择与多副本的更新策略:多个副本存在于不同的节点,如何选择。
- 查询树的分解:对所有节点采取后续遍历法,直到所有叶节点均被成功地遍历为止。
- 半连接与直接连接等:不需要传递整个关系,只要传送连接时与对方匹配的元组即可。
8.10、数据仓库
数据仓库集成是把多种来源的数据集中在一起,建立数据仓库,所有数据都驻留在单个数据库服务器上,配置大型处理器和存储容量。
数据仓库主要用于决策支持,在数据处理过程中强调分析其特点是:
- 面向主题:按照一定的主题域进行组织的。
- 集成的:数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的,必须消除源数据中的不一致性,以保证数据仓库内的信息是关于整个企业的一致的全局信息。
- 相对稳定的:数据仓库的数据主要供企业决策分析之用,所涉及的数据操作主要是数据查询,一旦某个数据进入数据仓库以后,一般情况下将被长期保留,也就是数据仓库中一般有大量的查询操作,但修改和删除操作很少,通常只需要定期的加载、刷新。
- 反映历史变化:数据仓库中的数据通常包含历史信息,系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息,通过这些信息,可以对企业的发展历程和未来趋势做出定量分析和预测。
数据仓库的结构通常包含四个层次
- 数据源:是数据仓库系统的基础,是整系统的数据源泉。
- 数据的存储与管理:是整个数据仓库系统的核心。
- OLAP(联机分析处理)服务器:对分析需要的数据进行有效集成,按多维模型组织,以便进行多角度、多层次的分析,并发现趋势。
- 前端工具:主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以及各种基于数据仓库或数据集市的应用开发工具。
数据挖掘流程
- 问题定义。在开始数据挖掘之前最先也是最重要的要求就是熟悉背景知识,弄清用户的需求。
- 建立数据挖掘库。 要进行数据挖掘必须收集要挖掘的数据资源,一般需要将要挖掘的数据都收集到一个数据库中,而不是采用原有的数据库或数据仓库。
- 分析数据。分析数据是对数据深入调查的过程。从数据集中找出规律和趋势。
- 调整数据。通过上述步骤的操作,对数据的状态和趋势有了进一步的了解,这时,要尽可能对问题解决的要求作进一步明确化和量化。
- 模型化。在问题进一步明确、数据结构和内容进一步调整的基础上,就可以建立形成知识的模型。
- 评价和解释。所得到的模型有可能是没有实际意义或没有实用价值的,也有可能是其不能准确反映数据的真实意义,甚至在某些情况下是与事实相反的。
数据挖掘的分析方法
- 关联分析:发现不同事件之间的关联性,即一个事件发生的同时,另一个事件也经常发生。
- 序列分析:发现一定时间间隔内接连发生的事件,这些事件构成一个序列,发现的序列应该具有普遍意义。
- 分类分析:通过分析具有类别的样本特点,得到决定样本属于各种类别的规则或方法。即按标记分类记录,然后检查这些标定的记录,描述出这些记录的特征。
- 聚类分析:聚类分析是根据“物以类聚”的原理,将本身没有类别的样本聚集成不同的组,并且对每个这样的组进行描述的过程。
8.11、商业智能 BI
BI系统主要包括数据预处理、建立数据仓库、数据分析和数据展现四个主要阶段。
数据预处理是整合企业原始数据的第一步,它包括数据的抽取(Extraction)、转换(Transformation)和加载(Load)三个过程(ETL过程);
建立数据仓库则是处理海量数据的基础;
数据分析是体现系统智能的关键,一般采用联机分析处理(OLAP)和数据挖掘两大技术。
9、WEB
9.1、冗余技术
提高系统可靠性的技术可以分为避错(排错)技术和容错技术。
避错是通过技术评审、系统测试和正确性证明等技术,在系统正式运行之前避免、发现和改正错误。
容错是指系统在运行过程中发生一定的硬件故障或软件错误时,仍能保持正常工作而不影响正确结果的一种性能或措施。
容错技术主要是采用冗余方法来消除故障的影响。
冗余是指在正常系统运行所需的基础上加上一定数量的资源,包括信息、时间、硬件和软件。
冗余是容错技术的基础,通过冗余资源的加入,可以使系统的可靠性得到较大的提高。
主要的冗余技术有结构冗余(硬件冗余和软件冗余)、信息冗余、时间冗余和冗余附加4种。
1.结构冗余
静态冗余。静态冗余通过表决和比较来屏蔽系统中出现的错误。由不同的人采用不同的方法开发出的模块的运行结果进行表决,以多数结果作为系统的最终结果。
动态冗余。它是通过故障检测、故障定位及故障恢复等手段达到容错的目的。当系统检测到某工作模块出现错误时,就用一个备用的模块来顶替它并重新运行。各备用模块在其待机时,可与主模块一样工作,也可不工作。前者叫做热备份系统(双重系统),后者叫做冷备份系统(双工系统、双份系统)。
混合冗余。混合冗余技术是将静态冗余和动态冗余结合起来,它先使用静态冗余中的故障屏蔽技术,使系统免受某些可以被屏蔽的故障的影响。而对那些无法屏蔽的故障则采用主动冗余中的故障检测、故障定位和故障恢复等技术,并且对系统可以作重新配置。
2.信息冗余
信息冗余是在实现正常功能所需要的信息外,再添加一些信息,以保证运行结果正确性的方法。例如,检错码和纠错码就是信息冗余的例子。
3.时间冗余
时间冗余是以时间(即降低系统运行速度)为代价以减少硬件冗余和信息冗余的开销来达到提高可靠性的目的。在某些实际应用中,硬件冗余和信息冗余的成本、体积、功耗、重量等开销可能过高,而时间并不是太重要的因素时,可以使用时间冗余。时间冗余的基本概念是重复多次进行相同的计算,或称为重复执行(复执),以达到故障检测的目的。
4.冗余附加
冗余附加技术包括:冗余备份程序的存储及调用,实现错误检测和错误恢复的程序,实现容错软件所需的固化程序。
软件容错的主要方法是提供足够的冗余信息和算法程序,使系统在实际运行时能够及时发现程序设计错误,采取补救措施,以提高系统可靠性,保证整个系统的正常运行。
软件容错技术主要有N版本程序设计、恢复块方法和防卫式程序设计等。
N版本程序设计:是一种静态的故障屏蔽技术,其设计思想是用N个具有相同功能的程序同时执行一项计算,结果通过多数表决来选择。其中N个版本的程序必须由不同的人独立设计,使用不同的方法、设计语言、开发环境和工具来实现,目的是减少N个版本的程序在表决点上相关错误的概率。
恢复块设计(动态冗余):动态冗余又称为主动冗余,它是通过故障检测、故障定位及故障恢复等手段达到容错的目的。其主要方式是多重模块待机储备,当系统检测到某工作模块出现错误时,就用一个备用的模块来替代它并重新运行。各备用模块在其待机时,可与主模块一样工作,也可以不工作。前者叫热备份系统(双重系统),后者叫冷备份系统(双工系统、双份系统)。
防卫式程序设计:是一种不采用任何传统的容错技术就能实现软件容错的方法,对于程序中存在的错误和不一致性,防卫式程序设计的基本思想是通过在程序中包含错误检查代码和错误恢复代码,使得一旦发生错误,程序就能撤销错误状态,恢复到一个已知的正确状态中去。其实现策略包括错误检测、破坏估计和错误恢复三个方面。
双机容错技术:是一种软硬件结合的容错应用方案。该方案是由两台服务器和一个外接共享磁盘阵列及相应的双机软件组成。
双机容错系统采用“心跳”方法保证主系统与备用系统的联系。所谓心跳,是指主从系统之间相互按照一定的时间间隔发送通信信号,表明各自系统当前的运行状态。一旦心跳信号表明主机系统发生故障,或者备用系统无法收到主系统的心跳信号,则系统的高可用性管理软件认为主系统发生故障,立即将系统资源转移到备用系统上,备用系统替代主系统工作,以保证系统正常运行和网络服务不间断。
工作模式:双机热备模式;双机互备模式;双机双工模式。
9.2、负载均衡
负载均衡是由多台服务器以对称的方式组成的一个服务器集合,每台服务器具有等价的地位,能够独立的对外提供服务而无需其他服务器的辅助。通过某种负载分担技术,将外部发来的请求均匀分配到对称结构中某台服务器上,而接收请求的服务器独立回应请求。
比较常用的负载均衡技术:
基于DNS(域名解析)的负载均衡:在DNS中为多个地址配置同一个名字,查询这个名字的客户机将得到其中一个地址,从而使不同客户访问不同服务器,达到负载均衡目的。不能区分服务器的差异,也不能放映服务器当前运行状态。
代理服务器负载均衡:使用代理服务器可将请求均匀的发给多台服务器,达到负载均衡的目的。使用这种模式还可以提升静态页面的访问速度。
地址转换网关负载均衡:将一个外部IP地址映射成多个内部IP地址,对每次TCP连接请求动态使用其中一个内部地址,达到负载均衡的目的。
协议内部支持负载均衡:有的协议内部支持与负载均衡有关的功能,例如HTTP协议的重定向能力。
NAT(网络地址转换)负载均衡:一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址之间的转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构的场合。
反向代理负载均衡:让代理服务器对外表现为一个服务器,接收来自Internet的连接请求,然后再将请求均匀的转发给内部多台服务器进行处理,从而达到负载均衡的目的。
混合型负载均衡:在一些大型网络中,会考虑给每个服务器集群采用最合适的负载均衡方式,然后再在这多个服务器集群间进行负载均衡或集群起来以一个整体向外界提供服务,从未达到最佳性能。也适用于单台均衡设备性能不能满足大量连接请求的情况。
9.3、集群技术
将多台计算机组织起来进行协同工作,它是提高系统可用性和可靠性的一种技术。
在集群系统中,每台计算机均承担部分计算任务和容错任务,当其中一台计算机出现故障时,系统使用集群软件将这台计算机从系统中隔出离去,通过各计算机之间的负载转嫁机制完成新的负载分担。同时向系统管理人员发出警报。
集群系统通过功能整合和故障过渡,实现了系统的高可用性和可靠性。
高性能计算科学集群:解决复杂的科学计算问题,具有优良的性价比;
负载均衡集群:使资源尽可能平均合理的分摊处理,适合于运行同一组应用程序的大量用户。
高可用性集群:整个系统环境对用户是透明的,某个节点发生故障将有另外的节点来代替它。
9.4、微服务
微服务架构建议将大型复杂的单体架构应用划分为一组微小的服务,每个微服务根据其负责的具体业务职责提炼为单一的业务功能;每个服务可以很容易地部署并发布到生产环境里隔离和独立的进程内部,它可以很容易地扩展和变更;对于一个具体的服务来说可以采用任何适用的语言和工具来快速实现;服务之间基于基础设施互相协同工作。
一个微服务需要包含完整的业务功能,开放一种或多种接口为其他服务使用,并可能包含一个自己私有的数据库。
微服务的优势:
(1)解决了复杂性问题。它把庞大的单一模块应用分解为一系列的服务,同时保持总体功能不变。
(2)让每个服务能够独立开发,开发者够自由选择可行的技术,让服务来决定API约定。
(3)每个微服务都能独立配置,开发者不必协调对于本地服务配置上的变化,这种变化一旦测试完成就被配置了。
(4)让每个服务都可以独立调整,你可以给每个服务配置正好满足容量和可用性限制的实例数。
微服务架构带来的挑战:
(1)并非所有的系统都能转成微服务。例如一些数据库层的底层操作是不推荐服务化的。
(2)部署较以往架构更加复杂:系统由众多微服务搭建,每个微服务需要单独部署,从而增加部署的复杂度,容器技术能够解决这一问题。
(3)性能问题:由于微服务注重独立性,互相通信时只能通过标准接口,可能产生延迟或调用出错。例如一个服务需要访问另一个服务的数据,只能通过服务间接口来进行数据传输,如果是频繁访问,则可能带来较大的延迟。
(4)数据一致性问题:作为分布式部署的微服务,在保持数据一致性方面需要比传统架构更加闲难。
微服务 | SOA |
---|---|
能拆分的就拆分 | 是整体的,服务能放一起的都放一起 |
纵向业务划分 | 是水平分多层 |
由单一组织负责 | 按层级划分不同部门的组织负责 |
细粒度 | 粗粒度 |
两句话可以解释明白 | 几百字只相当于SOA的目录 |
独立的子公司 | 类似大公司里面划分了一些业务单元(BU) |
组件小 | 存在较复杂的组件 |
业务逻辑存在于每一个服务中 | 业务逻辑横跨多个业务领域 |
使用轻量级的通信方式,如HTTP | 企业服务产总线(ESB)充当了服务之间通信的角色 |
微服务架构实现 | SOA实现 |
---|---|
团队级,自底向上开展实施 | 企业级,自顶向下开展实施 |
一个系统被拆分成多个服务,粒度细 | 服务由多个子系统组成,粒度大 |
无集中式总线,松散的服务架构 | 企业服务总线,集中式的服务架构 |
集成方式简单(HTTP/REST/JSON) | 集成方式复杂(ESB/WS/SOAP) |
服务能独立部署 | 单块架构系统,相互依赖,部署复杂 |
9.5、CDN
全称是Content Delivery Network,即内容分发网络。
CDN是构建在网络之上的内容分发网络,依靠部署在各地的边缘服务器,通过中心平台的负载均衡、内容分发、调度等功能模块,使用户就近获取所需内容,降低网络拥塞,提高用户访问响应速度和命中率。
CDN的关键技术主要有内容存储和分发技术。
◆CDN的基本原理是广泛采用各种缓存服务器,将这些缓存服务器分布到用户访问相对集中的地区或网络中,在用户访问网站时,利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上,由缓存服务器直接响应用户请求。
9.6、扩展标记语言
XML(Extensible Markup Language),用于标记电子文件使其具有结构性的标记语言,可以用来标记数据、定义数据类型,是一种允许用户对自己的标记语言进行定义的源语言。
XML的优点
格式统一,符合标准;容易与其他系统选行远程交互,数据共享比较方便。
XML的缺点
XML文件庞大,文件格式复杂,传输占带宽
服务器端和客户端都需要花费大量代码来解析XML,导致服务器端和客户端代码变得异常复杂且不易维护;
客户端不同浏览器之间解析XML的方式不一致,需要重复编写很多代码;
JSON(JavaScript Object Notation)
一种轻量级的数据交换格式,具有良好的可读和便于快速编写的特性。可在不同平台之间进行数据交换。
JSON的优点
数据格式比较简单,易于读写,格式都是压缩的,占用带宽小;
易于解析,客户端JavaScript可以简单的通过eval()进行JSON数据的读取;
支持多种语言,包括ActionScript,C,C#,ColdFusion,Java,JavaScript, Perl,PHPPython,Ruby等服务器端语言,便于服务器端的解析;
因为JSON格式能直接为服务器端代码使用,大大简化了服务器端和客户端的代码开发量,旦完成任务不变,并且易于维护
JSON的缺点
没有XML格式这么推广的深入人心和使用广泛,没有XML那么通用性
9.7、web设计
无状态服务(stateless service)
对单次请求的处理,不依赖其他请求,也就是说,处理一次请求所需的全部信息,要么都包含在这个请求里,要么可以从外部获取到(比如说数据库),
服务器本身不存储任何信息。
有状态服务(stateful service)则相反,它会在自身保存一些数据,先后的请求是有关联的。
响应式web设计
是一种网络页面设计布局,其理念是:集中创建页面的图片排版大小,可以智能地根据用户行为以及使用的设备环境进行相对应的布局
方法与策略
(1)采用流式布局和弹性化设计:使用相对单位,设定百分比而非具体值的方式设置页面元素的大小。
(2)响应式图片:不仅要同比的缩放图片,还要在小设备上降低图片自身的分辨率。
9.8、web框架
MVC
用户操作 → View(负责接收用户的输入操作) → Controller(业务逻辑处理) → Model(数据持久化) → View(将结果反馈给 View)。
优点:
- 耦合性低
- 重用性高
- 可维护性高
缺点:
- 没有明确的定义
- 不适合小型,中等规模的应用程序
- 增加系统结构和实现的复杂性
- 视图与控制器间的过于紧密的连接
- 视图对模型数据的低效率访问
MVP
MVP 是把 MVC 中的 Controller 换成了 Presenter(呈现),目的就是为了完全切断 View 跟 Model之间的联系,由 Presenter 充当桥梁,做到 View-Model 之间通信的完全隔离。
优点:
- 降低耦合度
- 模块职责划分明显
- 利于测试驱动开发
- 代码复用
- 隐藏数据
- 代码灵活性
缺点:视图的渲染放在Presenter中,所以视图和Presenter的交互会过于频繁。如果Presenter过多地渲染视图,往往会使得它与特定的视图的联系过于紧密。
MVVM
如果说 MVP 是对 MVC的进一步改进,那么 MVVM 则是思想的完全变革。
它是将“数据模型数据双向绑定”的思想作为核心,因此在 View和 Model之间没有联系,通过 ViewModel 进行交互,而目 Model 和 ViewModel之间的交互是双向的,因此视图的数据的变化会同时修改数据源,而数据源数据的变化也会立即反应到 View 上。
优点:
- 双向绑定时,当Model变化时,View-Model会自动更新,View也会自动变化。
- View的功能进一步的强化,具有控制的部分功能。
- 控制器的功能大部分移动到View上处理,大大的对控制器进行了瘦身。
缺点:
- 数据绑定使得 Bug 很难被调试。
- 数据双向绑定不利于代码重用。
- 大的模块,model很大,不利于内存的释放。
9.9、主备+分库架构
主备+分库架构是一种高可用性、可扩展性的数据库架构方案。在这种架构中,主库负责处理所有的写操作,而备库则作为主库的备份,用于在主库出现故障时接管服务。同时,通过分库,将不同的业务数据分散到不同的数据库中,以实现数据量的横向扩展。
优点:
- 高可用性:备库可以自动接管主库的服务,保证业务的连续性。
- 可扩展性:通过分库,可以方便地扩展数据库的处理能力。
缺点:
- 复杂性:需要维护多个数据库实例,增加了管理的复杂性。
- 数据一致性:需要确保主备库之间的数据同步,否则可能导致数据不一致。
9.10、主从+读写分离架构
主从+读写分离架构是一种通过读写分离来提高数据库性能的架构方案。在这种架构中,主库负责处理所有的写操作,而从库则负责处理读操作。这样,就可以充分利用多个数据库实例的处理能力,提高系统的整体性能。
优点:
- 性能提升:通过读写分离,可以充分利用多个数据库实例的处理能力,提高系统的整体性能。
- 简化管理:相对于主备+分库架构,主从+读写分离架构更容易管理和维护。
缺点:
- 数据一致性:需要确保主从库之间的数据同步,否则可能导致数据不一致。
- 读写分离复杂性:读写分离可能导致复杂的业务逻辑和事务管理。
二、论文
1、需求工程:最喜欢考需求获取、需求分析,也有可能考需求验证、需求管理,都要熟悉
2、软件测试,历年反复考察。
3、信息系统开发方法、开发模型、生命周期模型、企业应用集成技术。
4、系统可靠性、安全性、容错技术等。
5、其他:项目管理、数据库等。
系分论文侧重点,熟练掌握软件工程、系统分析、系统设计、测试、系统实施与维护这些软件工程基础知识和全生命周期知识,
1、重点
子题目,题目会出3个点,你要找到核心论点,理解结合实际项目的那一个。
子题目是没办法押题的,所以你必须要背。
防止考到了哪个点,你不会,就只能干着急。
2、字数划分
摘要:300
正文:2000-2700
建议:摘要300字 + 项目背景500字 + 主体1200字 + 结尾500字。
3、项目背景
级别:某省级,市级,不能写太小的,不能写真实的省级,用某省级代替。
时间:5年内,已完成了的,持续时间8个月以上
成员:20多个
金额:当每个成员2万一月,一个月就需要40万,在看持续时间,不要写整数。
注意:不要写太大的,最好在500万左右。
选择中大型商业项目,一般金额在 200W 以上,研发周期在8个月以上的项目。
4、十段式
摘要(300)
- 模板,项目概括,内容:时间、岗位+职责(系统分析师),作用。
- 对正文概括,用3句话,概括正文的3段式。
在需求阶段通过用户访谈… …
在构建阶段通过分析对象… …
在选代阶段通过专家交流… …
背景(500)
- 模板,200字概括大背景(为什么要做这个项目),引出大项目。
- 模板,描述开发周期,我的岗位+职责,主要描述,功能组成(既要罗列也要解释,挑重要的)和技术实现(什么语言,什么架构)。
因此要高质量的完成该系统,选择一种合适的开发方法至关重要(过渡话)
子题目(300)
- 它问什么你就写什么(要背,纯理论):目前常用的开发方法主要有三种… …
结合上述分析,我们最终决定采用快速原型法与面向对象法组合应用的开发方案。
该方案把软件生命周期分为4个阶段:需求阶段、构建阶段、选代阶段和验收阶段。
本文着重从前3个阶段来展开论述。
正文(每段300)
- 需求阶段… …(获取、分析、定义、验证)理论,要理论结合实际
- 构建阶段… …原型理论,要理论结合实际
- 选代阶段… …迭代理论,要理论结合实际
结尾(400)
- 模板,套话,项目经过多长时间,上线运行,没有问题,客户满意;你的经验总结;
- 模板,2个不足之处,然后还要提出你的解决方案。
5、万能模板
论信息系统开发方法及应用
2022年3月,我参加了某市互联网医院系统项目,并有幸担任了系统分析师,负责该项目的需求分析与系统设计工作。该项目是以门诊管理系统,问诊系统,处方管理系统,互联网医院后台系统为依托并集成医院管理系统(HIS),主要实现患者在线预约,线上问诊,医保脱卡支付,药品快递到家的等功能。该项目历时15个月,于2023年6月正式交付运行至今,得到了用户的一致好评,本文结合笔者实际工作经验以该系统为例,主要论述了信息系统开发方法的实际应用,在需求阶段,采用用户访谈获取基本需求,利用联合需求会议解决需求不明确的问题,以完成系统的规划与分析;在构建阶段,通过分析该系统包含的对象、对象的属性及对象的关联来产生初始对象模型,以构造初始原型;在迭代阶段,通过和医疗专家组交流,完成功能的同时完善对象模型,直至项目最终完成。
近年,随着”互联网+“的提出,医疗行业也迎来了巨大的变革;互联网医院项目能够提供线上问诊,方便患者在家中及时获得医疗咨询和治疗。同时,它也能节省患者的时间成本。此外,互联网医院还可以促进医疗资源的均衡分布,特别是在偏远地区,能够提升医疗服务的可及性。我所在的公司是一家专注医疗业务的软件开发公司,其中互联网医院是我们的主要业务之一,于2022年3月承接了某市的互联网医院系统的建设工作,我作为系统分析师参与其中,并负责该项目的需求分析与系统设计。该项目采用了微服务架构和集成技术,覆盖各种应用终端包括电脑PC端和源生小程序。项目的主要模块有门诊管理系统,问诊系统,处方管理系统,互联网医院后台系统等,其中门诊系统的主要功能是线上挂号,线上预约,在线支付以及报告查询;诊疗系统分为图文咨询,视频问诊,线上医嘱,电子病历,电子处方,药品自提与药品到家等,主要实现患者在线问诊,医生线上看病,药品快递到家;处方管理系统包括中药和西药处方,医生CA签名,合理用药系统,处方审核,主要是为了提高处方质量,促进合理用药,保障医疗安全;互联网医院后台系统包括系统参数设置,排班管理,科室管理,人员管理等。综上所述,要高质量的完成该项目选择一种合适的开发方法尤其重要。
目前常用的开发方法主要有三种:结构法、原型法、面向对象法;
结构化方法把整个系统的开发过程分为若干阶段,然后一步一步地依次进行,前一阶段是后一阶段的工作依据。该方法比较注重开发过程的整体性和全局性,理论基础严密,但开发周期长,文档、设计说明繁琐,工作效率低,且不能很好地应对变化。
原型法与结构化方法不同,原型法的核心在于先快速开发一个原型系统,然后通过反复修改来实现用户的最终系统需求。该方法适于用户需求开始时定义不清、管理决策方法结构化程度不高的系统开发,更宜被用户接受。
面向对象方法强调从现实世界中客观存在的事物(对象)出发来认识问题,使系统开发者大大减少了对问题域的理解难度,从而使系统能更准确地反映问题域;改善了人员之间的交流和协作,对软件复用提供了强有力的支持。
根据上面的分析,该项目最终决定采用原型法与面向对象相结合的方法,根据此方法我们将项目一共划分为4个阶段:需求阶段,构建阶段,迭代阶段,验收阶段;本文以前3个阶段为主,并分为进行论述。
一:需求阶段
需求阶段的目标是完成系统的规划与分析,我们采取了一系列细致而系统的步骤来确保需求的准确性和完整性。采用用户访谈我们与医疗专家及用户深入交流,明确医院服务的核心功能点,如在线问诊、药品配送等;梳理出用户痛点,确保需求贴近实际。
由于在项目前期对医院的情况不是很清晰,我们邀请了院方领导、信息科领导以及his代表人员召开了需求联合会议,在会议中,我们了解到当前医院所使用的his系统是另外一个公司承接的,为c/s模式,我们在会议中确定了互联网医院系统如何与his系统进行互联,如:同步就诊记录、药品数据、病历与处方记录等。在这些基础上利用UML工具设计出系统基本用例图,明确系统大概范围,勾勒出大致系统边界。最后,我们组织内部评审和用户测试,确保需求合理且易于实现,为后续的开发和运营奠定坚实基础。
二:构建阶段
构建阶段的目标是构造初始原型。在基本调查的基础上,尽量完整的分析该系统包含的对象、对象的属性及对象的关联,产生一个初始对象模型,根据这些对象来产生系统数据结构的初始框架,对对象活动、驱动这些活动的事件以及对象在这些事件驱动下的前后状态变化进行分析,进而产生系统的用户界面,得到系统的一个最初始的原型,这个原型只是一个系统框架,很多操作只是空动作,目的是向用户说明系统的功能和操作方法,以后随着开发进程以及需求明确再逐步求精。
如处方开药只是简单添加和删除药品,CA签名暂不做考虑也没有对接合理用药系统。整个构建过程,让用户也参与到我的设计中来,我们通过面对面访谈,并邀请用户参与测试产品原型,收集用户对产品功能和界面的反馈,发现潜在问题并进行改进。
三:迭代阶段
迭代阶段的目标是通过反复循环最终建造出系统。在每一次迭代过程中,通过和医疗专家组交流,在完善需求的基础上,完善对象模型。同时进一步明确用户界面间关系,通过交互完成功能模型,并验证它的正确性。对要求的用例进行分析、设计、编码、测试和集成。完成一次迭代后向用户演示,并表明所要求的用例可以移到下一次迭代中去开发。每一次迭代过程都利用面向对象的技术来实现,而且都必须是增量式的:增加功能,修改缺陷,这一阶段中,面向对象技术的易维护和扩充、便于复用的优点得到充分体现。在迭代过程中,医疗专家组向我们提出一个需求 “ 在视频问诊中,医生已进入视频房间,但患者迟到,会造成医生的时间浪费;如果采用医生在接诊上一次患者时就给当前患者发送通知,那患者等待时间又过长的问题。”,为了更好的解决这个问题,我们采用了现场观摩的办法,我们发现在现实生活中,当医生接诊完上一个患者时,通常需要1-2分钟用来查看当前患者的历史病例,如是我们在医生端增加了一个立即接诊的功能,当此功能开启时,医生结束完上一个患者的就诊,就会给当前患者发送提示,患者点击提示可立即进入视频房间,并等待医生接诊;如果患者在此期间没有使用互联网医院应用终端,就采取短信提示,告知医生即将接诊。最后我们反复修改原型,完成了这一迭代需求。
通过快速原型法与面向对象方法的成功运用,使系统在较短时间内交付使用。迭代过程中医疗专家组积极参与,也间接减少了系统测试与上线培训时间。
经过15个月的开发,我们最终与2023年6月完成了该系统的验收,**交付给用户一个高质量、高可靠性、高易用性的系统,用户也给予我们较高的评价。**当然在项目过程中也不是一切顺利,在开发期间,有一些开发人员使用了未经验证的第三方控件,这确实减少了开发时间,但是在测试过程中,测试人员开发该控件在不同的手机型号会造成样式展示不全以及功能缺失的情况,后续我们不得不替换该控件,造成了该次迭代延期的问题。之后我们规定了相关开发人员只能使用公司内部的控件,从而有效避免这个问题。
经实践证明利用原型法与面向对象方法相结合的方案,能大大的降低软件开发风险也能提高软件的复用率、可维护与扩展性;通过该项目的顺利实施和验收,让我在信息系统开发方面受益良多;在后续的工作中,我还会继续学习,保持与同行交流,更好的完成需求分析和系统设计的工作。
6、目前遇到的问题
- 摘要:控制字数,记得给正文分段,不知道咋分,就分初、中、后
- 背景:先提出功能,再说解决了什么问题
- 项目功能介绍,(主要功能是什么;分为什么实现什么,包括什么为了提高什么,)
- 过渡话(综上所诉,要高质量的完成该项目选择一种合适的开发方法尤其重要)
- 正文:先说目标,记得要结尾。
- 最后:经过15个月的开发,我们最终与2023年6月完成了该系统的验收,交付给用户一个高质量、高可靠性、高易用性的系统,用户也给予我们较高的评价。
- 经实践证明了你的论题,能减少风险提高复用
- 通过验收,你学到了东西,你还会持续学习,更好的完成工作
7、关键词记忆
- 需求获取:细致而系统,准确性和完整性;核心功能点,用户痛点,需求贴合实际。需求合理且易于实现。
- 结构化:若干阶段,依次进行,整体性和全局性,理论严密,开发时长,文档繁琐,效率慢,不能应对变化。
- 面向对象:强调现实,事物皆对象,运行规律和内部状态,复杂由简单方式构成,不同组合相互作用成系统。减少问题域理解难度,复用性,普遍适用。
- 原型法:用户需求,开发工具,快速建立,用户交流,反复修改,最终实现。适用需求不明确,容易被用户接受
- 结构分析:自顶向下,逐步分解,大分小,小分更小,最低层问题简单容易解决,复杂问题也就解了
- 对象分析:对域分析理解,认识事物及关系,找出域系功所需类和对象,定义属性职责及各种联系
结构化分析方法
摘要:通过采用数据流图描述系统的功能组成;采用状态转换图对用户的状态进行判断;采用数据字典对数据进行详细和准确的描述。通过以上技术的使用,使得需求分析的质量得到了保证,对后续项目的顺利实施提供了有力的支撑。
数据流图的运用。为了向客户清楚地描述系统的由哪些功能部分组成
使得整个系统的复杂处理过程得以采用图形化的方式来描述,减少了大量篇幅的文字描述,使需求分析文档看上去非常简洁。整个需求文档看上去更清晰,尽量避免让客户去看哪些枯燥冗长的文章,让即使是不懂技术的客户看完这些图,也能理解系统的数据处理过程。
状态转换图的运用。DFD仅仅描述了系统的功能组成部分及功能间了联系,而系统运行过程中需要对用户的状态做大量的判断
通过使用STD,能清楚地描述了处方的状态转换过程。
数据字典的运用。数据字典是结构化分析方法的核心,数据字典完成了DFD对数据详细内容无法具体、准确的描述,是对DFD的强力的补充。
面向对象分析方法
构建用例模型。主要的工作是识别参与者、合并需求中获取的用例、细化用例描述、调整用例模型
通过以上的工作诊疗系统的用例横型就基本建好了,后续的工作还要对用例模型进行细化描述和调整
定义领域概念横型
这里主要的工作就是从用例模型中找到并定义出概念类。确定类之间的关系,为类添加相应的职责。概念类可以从用例模型中进行分析后获得。每一个用例对应一个类图。
最后,通过用例描述中的动词来筛选判断确定类的主要方法,。
建立交互图,交互图主要包括:顺序图、交互概览图、通信图和定时图,用来表示用例的实现过程,用例的事件流会产生一个或多个顺序图,因此,顺序图几乎可以用在任何场景。
有些场景仅仅用顺序图来描述源是不够的,还需要和其他的UML图形配合使用,才能把需求分析描述清楚。
敏捷开发
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法
更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。
主要的关注点有短平快的会议、小版本发布、较少的文档、合作为重、客户直接参与、自动化测试、适应性计划调整和结对编程。
敏捷软件开发宣言:
- 个体和交流胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
12条原则:这里仅举例3条,考试也不会要你全写
- 尽早,持续交付有价值的中间软件使用户满意
- 即使到了开发后期,也欢迎需求变化,利用响应变化创造竞争优势。
- 团队内部,最有效的沟通方式莫过于面对面的交流。
结对编程:一个程序员开发,另一个程序在一旁观察审查代码,能够有效的提高代码质量,在开发同时对代码进行初步审查,共同对代码负责。
自适应开发:强调开发方法的适应性(Adaptive)。不象其他方法那样有很多具体的实践做法,它更侧重为软件的重要性提供最根本的基础,并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
水晶方法:每一个不同的项目都需要一套不同的策略、约定和方法论。
特性驱动开发:是一套针对中小型软件开发项目的开发模式。是一个模型驱动的快速迭代开发过程,它强调的是简化、实用、 易于被开发团队接受,适用于需求经常变动的项目。
极限编程 XP:核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化,XP 无需开发人员在软件开始初期做出很多的文档。XP 提倡测试先行,为了将以后出现 bug 的几率降到最低。
并列争球法 SCRUM:是一种迭代的增量化过程,把每段时间(30天)一次的迭代称为一个“冲刺”,并按需求的优先级别来实现产品,多个自组织和自治的小组并行地递增实现产品。
Scrum是一个迭代式增量软件开发过程,用于帮助团队开发和交付产品。在Scrum中,有几个关键的角色、工件和活动:
- 角色:
- 产品负责人(Product Owner):负责确定产品的功能需求,并维护产品待办事项列表(Product Backlog)。
- 开发团队(Development Team):负责执行开发任务,创建产品增量。
- Scrum主管(Scrum Master):负责确保Scrum过程的正确执行,并帮助团队解决开发过程中的问题。
- 工件:
- 产品待办事项列表(Product Backlog):包含所有产品功能需求的列表,按优先级排序。
- 冲刺待办事项列表(Sprint Backlog):在冲刺期间需要完成的工作项列表。
- 冲刺增量(Increment):冲刺期间完成的可交付产品增量。
- 活动:
- 冲刺计划会议(Sprint Planning Meeting):确定冲刺目标,并分配任务给开发团队。
- 每日站会(Daily Scrum):团队成员每天简短地讨论各自的工作进展、问题和计划。
- 冲刺评审会议(Sprint Review Meeting):展示冲刺增量,并获取反馈。
- 冲刺回顾会议(Sprint Retrospective Meeting):反思冲刺过程,讨论改进点。
原型法
原型法的开发过程主要包括以下几个步骤:
- 需求分析:收集用户的基本需求,并明确系统的目标和功能。
- 快速设计:基于需求分析结果,快速设计并构建系统的初始原型。
- 用户试用:将原型交付给用户试用,并收集用户的反馈意见。
- 评估与反馈:分析用户的反馈,评估原型是否满足用户需求,确定需要修改或增强的部分。
- 迭代开发:根据用户的反馈,修改原型,并重复用户试用、评估与反馈的步骤,直到满足用户需求。
- 基于原型法进行互联网医院信息系统开发
在互联网医院项目中,我们采用了原型法来进行信息系统开发,具体过程如下:
- 初始需求分析:我们首先与医院各部门的管理人员和一线工作人员进行了深入的交流,明确了他们对互联网医院系统的基本需求,如在线挂号、医生咨询、药品配送、电子病历等功能。
- 原型设计与制作:基于需求分析的结果,我们使用Axure等工具快速制作了系统的初始原型。这个原型包含了主要功能界面和操作流程,但细节部分可能还不够完善。
- 用户试用与反馈:我们将原型交付给医院的管理人员和一线工作人员试用,并收集他们的反馈意见。他们提出了一些建议,如界面布局需要调整、部分功能操作不够便捷等。
- 原型迭代与优化:我们根据用户的反馈意见,对原型进行了修改和优化。例如,我们重新设计了界面布局,使其更加符合用户的操作习惯;我们改进了部分功能的操作流程,提高了用户的使用效率。
- 持续迭代与交付:在后续的开发过程中,我们不断将新的功能或模块集成到原型中,并邀请用户进行试用和反馈。通过持续的迭代和优化,我们确保了最终交付的系统能够满足用户的实际需求。
面向对象设计原则
开闭原则是指软件实体应对扩展开放,而对修改关闭,即尽量在不修改原有代码的情况下进行扩展。
对于已有的软件模块,特别是最重要的抽象层模块不能再修改,这就使变化中的系统有一定的稳定性和延续性,这样的系统同时满足了可复用性与可维护性。
里氏替换原则,其基本思想是,一个软件实体如果使用的是一个基类对象,那么一定适用于其子类对象,而且觉察不出基类对象和子类对象的区别,即把基类都替换成它的子类,程序的行为没有变化。反过来则不一定成立,如果一个软件实体使用的是一个子类对象,那么它不一定适用于基类对象。
运用:尽量将一些需要扩展的类或者存在变化的类设计为抽象类或者接口,并将其作为基类,在程序中尽量使用基类对象进行编程。由于子类继承基类并实现其中的方法,程序运行时,子类对象可以替换基类对象,如果需要对类的行为进行修改,可以扩展基类,增加新的子类,而无需修改调用该基类对象的代码。
依赖倒置原则是指抽象不应该依赖于细节,细节应当依赖于抽象。
要针对接口编程,而不是针对实现编程。
在程序代码中传递参数时或在组合(或聚合)关系中,尽量引用层次高的抽象层类,即使用接口和抽象类进行变量类型声明、参数类型声明和方法返回类型声明,以及数据类型的转换等,而不要用具体类来做这些事情。
一个具体类应当只实现接口和抽象类中声明过的方法,而不要给出多余的方法,否则,将无法调用到在子类中增加的新方法。
组合/聚合复用原则又称为合成复用原则,是在一个新的对象中通过组合关系或聚合关系来使用一些已有的对象,使之成为新对象的一部分,新对象通过委派调用已有对象的方法达到复用其已有功能的目的。
就是要尽量使用组合/聚合关系,少用继承。
首先应该考虑使用组合/聚合,组合/聚合可以使系统更加灵活,类与类之间的耦合度降低,一个类的变化对其他类造成的影响相对较少;
其次才考虑继承,在使用继承时,需要严格遵循里氏替换原则,有效使用继承会有助于对问题的理解,降低复杂度,而滥用继承反而会增加系统构建和维护的难度,以及系统的复杂度。
通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性,因为继承会将基类的实现细节暴露给子类,由于基类的内部细节通常对子类来说是透明的
组合或聚合关系可以将已有的对象(也可称为成员对象)纳入到新对象中,使之成为新对象的一部分,新对象可以调用已有对象的功能,这样做可以使得成员对象的内部实现细节对于新对象是不可见的
◉如果两个类之间是Has-A的关系,则应使用组合或聚合;
◉如果是Is-A关系,则可使用继承。
Is-A是严格的分类学意义上的定义,意思是一个类是另一个类的“一种”。
而Has-A则不同,它表示某一个角色具有某一项责任。
接口隔离原则是指使用多个专门的接口,而不使用单一的总接口。每个接口应该承担一种相对独立的角色,不多不少,不干不该干的事,该干的事都要干。
最少知识原则也称为迪米特法则(Law of Demeter),是指一个软件实体应当尽可能少地与其他实体发生相互作用。
当一个模块修改时,就会尽量少地影响其他的模块,扩展会相对容易。
在狭义原则中,如果两个类之间不必彼此直接通信,那么这两个类就不应当发生直接的相互作用;如果其中的一个类需要调用另一个类的某一个方法,可以通过第三者转发这个调用。可以降低类之间的耦合,但是会在系统中增加大量的小方法并散落在系统的各个角落。
广义原则是指对对象之间的信息流量、流向和信息的影响的控制,主要是对信息隐藏的控制。信息的隐藏可以使各个子系统之间解耦,从而允许它们独立地被开发、优化、使用和修改。
- 单一职责原则:我们将系统划分为多个模块,每个模块负责一个具体的功能领域。例如,用户管理模块负责用户的注册、登录、个人信息管理等操作;在线问诊模块负责医生与患者的在线咨询、问诊记录管理等操作。这样,每个模块都有明确的职责,降低了系统的复杂性。
- 开放封闭原则:在项目开发过程中,我们尽量避免修改已有代码,而是通过扩展已有功能来满足新的需求。例如,当需要增加新的药品类型时,我们只需要在药品管理模块中添加新的药品类,并为其实现相应的操作算法,而不需要修改已有的代码。这样,系统的可维护性和可扩展性得到了提高。
- 里氏替换原则:在项目中,我们定义了多个基类(如医生类、患者类等),并为它们定义了明确的接口和行为约定。子类(如内科医生类、外科医生类等)必须遵守这些约定,以确保它们可以替换其基类而不会影响程序的功能。这样,我们可以轻松地扩展新的医生类型或患者类型,而无需修改已有代码。同时,这也保证了系统的稳定性和可靠性。
结构化设计原则
结构化设计(Structured Design, SD)是一种面向数据流的方法,它以SRS和SA阶段所产生的数据流图和数据字典等文档为基础,是一个自顶向下、逐步求精和模块化的过程。
耦合表示模块之间联系的程度。紧密耦合表示模块之间联系非常强,松散耦合表示模块之间联系比较弱,非耦合则表示模块之间无任何联系,是完全独立的
内聚表示模块内部各成分之间的联系程度,是从功能角度来度量模块内的联系,一个好的内聚模块应当恰好做目标单一的一件事情。
高内聚低耦合:耦合低使得模块间尽可能相对独立,从而各模块可以单独开发和维护,可以提高软件质量;内聚高使得模块的可理解性和维护性大大增强。
系统设计主要目的:为系统制定蓝图,在各种技术和实施方法中权衡利弊,精心设计,合理地使用各种资源,最终勾画出新系统的详细设计方法。
系统设计方法:结构化设计方法,面向对象设计方法。
系统设计的主要内容:概要设计、详细设计。
概要设计基本任务:又称为系统总体结构设计,是将系统的功能需求分配给软件模块,确定每个模块的功能和调用关系,形成软件的模块结构图,即系统结构图。
详细设计的基本任务:模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计(代码、输入/输出格式、用户界面)、编写详细设计说明书、评审。
系统设计基本原理
抽象化;
自顶而下,逐步求精;
信息隐蔽;
模块独立(高内聚,低耦合)。
系统设计原则
保持模块的大小适中;
尽可能减少调用的深度;
多扇入,少扇出;
单入口,单出口;
模块的作用域应该在模块之内;
功能应该是可预测的。
扇入:是指直接调用该模块的上级模块的个数。扇入大表示模块的复用程序高。别的系统或者模块调用自己
扇出:是指该模块直接调用的下级模块的个数。扇出大表示模块的复杂度高,需要控制和协调过多的下级模块;自己调用别的模块或系统
单入口单出口:指为了保证开发程序的质量,要求过程中的数据流控制是必须在固定的程序段入口进入,固定的出口返回,不允许在编程中随意使用数据。
设计模式
设计模式:每一个设计模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复劳动。
设计模式的核心在于提供了相关问题的解决方案,使得人们可以更加简单方便的复用成功的的设计和体系结构。
-
单例(Singleton)模式:某个类只能生成一个实例,该类提供了一个全局访问点供外部获取该实例,其拓展是有限多例模式。记忆关键词:唯一实例
-
原型(Prototype)模式:将一个对象作为原型,通过对其进行复制而克隆出多个和原型类似的新实例。记忆关键词:原型实例,拷贝
-
工厂方法(FactoryMethod)模式:定义一个用于创建产品的接口,由子类决定生产什么产品。记忆关键词:子类决定实例化
-
抽象工厂(AbstractFactory)模式:提供一个创建产品族的接口,其每个子类可以生产一系列相关的产品。记忆关键词:抽象接口
-
建造者(Builder)模式:将一个复杂对象分解成多个相对简单的部分,然后根据不同需要分别创建它们,最后构建成该复杂对象。记忆关键词:类和构造分离
-
代理(Proxy)模式:为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象,从而限制、增强或修改该对象的一些特性。记忆关键词:代理控制
-
适配器(Adapter)模式:将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类能一起工作。记忆关键词:转换,兼容接口
-
桥接(Bridge)模式:将抽象与实现分离,使它们可以独立变化。它是用组合关系代替继承关系来实现的,从而降低了抽象和实现这两个可变维度的耦合度。记忆关键词:抽象和实现分离
-
装饰(Decorator)模式:动态地给对象增加一些职责,即增加其额外的功能。记忆关键词:附加职责
-
外观(Facade)模式:为多个复杂的子系统提供一个一致的接口,使这些子系统更加容易被访问。记忆关键词:对外统一接口
-
享元(Flyweight)模式:运用共享技术来有效地支持大量细粒度对象的复用。记忆关键词:细粒度,共享
-
组合(Composite)模式:将对象组合成树状层次结构,使用户对单个对象和组合对象具有一致的访问性。记忆关键词:整体-部分,树形结构
-
模板方法(Template Method)模式:定义一个操作中的算法骨架,将算法的一些步骤延迟到子类中,使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
-
策略(Strategy)模式:定义了一系列算法,并将每个算法封装起来,使它们可以相互替换,且算法的改变不会影响使用算法的客户。记忆关键词:算法替换
-
命令(Command)模式:将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。记忆关键词:日志记录,可撤销
-
职责链(Chain of Responsibility)模式:把请求从链中的一个对象传到下一个对象,直到请求被响应为止。通过这种方式去除对象之间的耦合。记忆关键词:传递请求,职责链接
-
状态(State)模式:允许一个对象在其内部状态发生改变时改变其行为能力。记忆关键词:状态变成类
-
观察者(Observer)模式:多个对象间存在一对多关系,当一个对象发生改变时,把这种改变通知给其他多个对象,从而影响其他对象的行为。记忆关键词:通知,自动更新
-
中介者(Mediator)模式:定义一个中介对象来简化原有对象之间的交互关系,降低系统中对象间的耦合度,使原有对象之间不必相互了解。记忆关键词:不直接引用
-
迭代器(Iterator)模式:提供一种方法来顺序访问聚合对象中的一系列数据,而不暴露聚合对象的内部表示。记忆关键词:顺序访问,不暴露内部
-
访问者(Visitor)模式:在不改变集合元素的前提下,为一个集合中的每个元素提供多种访问方式,即每个元素有多个访问者对象访问。记忆关键词:数据和操作分离
-
备忘录(Memento)模式:在不破坏封装性的前提下,获取并保存一个对象的内部状态,以便以后恢复它。记忆关键词:保存,恢复
-
解释器(Interpreter)模式:提供如何定义语言的文法,以及对语言句子的解释方法,即解释器。记忆关键词:解释器,虚拟机
软件测试
软件测试是在将软件交付给客户之前所必须完成的重要步骤。目前,软件的正确性证明尚未得到根本的解决,软件测试仍是发现软件错误(缺陷)的主要手段。
测试原则
- 应尽早并不断的进行测试;
- 测试工作应该避免由原开发软件的人或小组承担;
- 在设计测试方案时,不仅要确定输入数据,而且要根据系统功能确定预期的输出结果;
- 既包含有效、合理的测试用例,也包含不合理、失效的用例;
- 检验程序是否做了该做的事,且是否做了不该做的事;
- 严格按照测试计划进行;
- 妥善保存测试计划和测试用例;
- 测试用例可以重复使用或追加测试。
测试类型分为两大类:
动态测试:程序运行时测试,分为
黑盒测试法:功能性测试,不了解软件代码结构,根据功能设计用例,测试软件功能。
白盒测试法:结构性测试,明确代码流程,根据代码逻辑设计用例,进行用例覆盖。
灰盒测试法:既有黑盒,也有白盒。
静态测试:程序静止时,即对代码进行人工审查,分为
桌前检查:程序员检查自己编写的程序,在程序编译后,单元测试前。
代码审查:由若干个程序员和测试人员组成评审小组,通过召开程序评审会来进行审查。
代码走查:也是采用开会来对代码进行审查,但并非简单的检查代码,而是由测试人员提供测试用例,让程序员扮演计算机的角色,手动运行测试用例,检查代码逻辑。
白盒测试用例:知道程序的代码逻辑,按照程序的代码语句,来设计覆盖代码分支的测试用例。
覆盖级别从低至高分为下面六种:
- 语句覆盖:所有语句都要被执行一遍,覆盖层级最低,因为执行了所有的语句,不代表执行了所有的条件判断。
- 判定覆盖:每个判定表达式都有一真一假,你都要取到一次,这里的判定是指判定整体一真一假;
- 条件覆盖:判定表达式的所有条件都要最少取得一真一假,AND的左右条件
- 判定/条件覆盖:2,3的组合
- 条件组合覆盖:AND的左右条件,每种情况都要试一遍
- 路径覆盖:最强的,覆盖被测试程序中所有可能的路径