系统架构师(软考)—-系统开发基础知识

软件工程概述

软件危机

价格贵、质量差、不符合用户需求、文档不完整、可维护性差
1946-1956 程序设计时代 1956-1968 程序系统时代 1968-至今 软件工程时代

软件工程

1、需求分析阶段(系统分析师:用例图捕获需求)
2、软件设计(类图、活动图、状态图)
3、软件实现
4、软件交付:按照软件开发规范对软件系统进行质量控制、测试、交付与运行、维护
按照某种方法，使用一些相关的工具进行开发的过程

软件生命周期

定义(系统分析师)

确定总目标: 定义问题、可行性研究、需求分析

开发

设计与实现: 概要设计、详细设计、编码、测试

运维

交付用户: 更正性维护、适应性维护、预防性维护、完善性维护

消亡

退役: 报废、遗留系统

软件开发方法

分类

按照开发风范

自顶向下: 将大问题分成多个可以解决的小问题，然后逐一进行解决(结构化方法)
自底向上: 根据系统功能要求，从具体的器件、逻辑部件或者相似系统开始，凭借设计者熟练的技巧和丰富的经验，通过对其进行相互连接、修改和扩大，构成所要求的系统。(从一个一个部件组装成一个整体)

按照性质

形式化: 基于严密的、数学上的形式机制的计算机系统研究方法(用于一致性检查、类型检查、有效性验证、行为预测、设计求精验证)
非形式化: 各种开发模型(结构化、面向对象、面向服务、原型法、敏捷)

适用范围

整体性方法、局部性方法

结构化方法

以过程为中心
典型的自顶向下的方法，由结构化分析、结构化设计、结构化程序设计组成。开发目标清晰化、开发工作阶段化(每个阶段完成后要进行评审)、开发文档规范化、设计方法结构化(自顶向下分解，进行分析与设计。根据设计要求先编写各个功能模块，自底向上实现)
缺点: 开发周期长、难以适应需求变化、很少考虑数据结构

结构化分析(Structured Analysis SA)

自顶向下，逐层分解 经过逐层分解，每个最底层的问题都是足够简单、容易解决的，于是复杂的问题也就迎刃而解了。
面向过程的开发方法，主要考虑数据流，面向数据流进行需求分析，适合数据处理类型的软件

数据流图

数据流、加工、数据存储、外部实体

数据流:

(1)从一个加工流向另一个加工
(2)从加工流向数据存储(写)
(3)从数据存储流向加工(读)
(4)从外部实体流向加工(输入)
(5)从加工流向外部实体(输出)
注意: 实体不能直接连接存储，必须经过加工

加工:

要有输入输出
(1)有输入没有输出—黑洞
(2)有输出没有输入—奇迹
(3)输入不足以产生输出—灰洞

外部实体:

可以是人、物品、其他系统。名词
状态转换图(State Transform Diagram STD)
通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为。展示数据处理过程。

数据字典

数据流、数据项、数据存储和基本加工

加工

常用方法有: 结构化语言、判定表、判定树
结构化语言和判定树适用于加工的输入数据和输出数据之间的逻辑关系比较简单的加工描述
判定表适用于加工的输入数据和输出数据之间的逻辑关系比较复杂的加工描述
表格形式为:

条件类别	条件组合
操作	操作执行

面向对象的方法

以对象为中心
现实世界，对象可以被看成是一个个具有某种功能的个体
软件系统，对象可以被看成是一个个可执行某种程序的个体

对象特征

1、对象具有唯一对象标识
2、对象拥有一组数据来描述自身状态信息，对象的属性
3、每个对象都有自己可以执行的程序或叫对象的方法
4、对象在接收到需服务的请求时候，可以为其他对象提供服务
5、每个对象都有可以处理的对象消息，而响应消息的是对象的方法

消息

是对象之间的传递内容，是对象之间交互的唯一内容，是对象.函数()的调用和执行

类

有些对象具有相似的特征描述，这些对象组成一个类

面向对象方法的类别

面向对象的分析(OOA)
面向对象的设计(OOD)
面向对象的程序设计(OOP)

Coad/Yourdon方法

强调OOA和OOD采用完全一致的概念和表示法

Booch方法

开发模型包括静态模型和动态模型，静态模型分为逻辑模型(类图、对象图)和物理模型(模块图、进程图)，用来描述系统的构成和结构。动态模型包括状态图和顺序图，用来描述对象的状态变化和交互过程

OMT方法

使用了建模思想，采用对象模型(对象图)、动态模型(状态图)和功能模型(DFD)来建立一个实际的应用模型

OOSE

使用用例(use case)取代了DFD来进行需求分析和建立功能模型

面向对象分析

功能模型: 描述系统功能 用例图 DFD数据流图(结构化方法)
数据模型(对象模型): 描述系统数据结构的对象模型 类图(面向对象方法) E-R(结构化方法)
行为模型(动态模型): 描述系统控制结构 活动图、顺序图、状态图 状态转换图(结构化方法)

用例建模

参与者、用例、通信关联

用例(加工)

由系统执行的一系列动作，为相关的参与者提供其所希望的服务
动宾短语组成

参与者(外部实体)

指存在于系统外部并与系统进行交互的任何事务
内部、外部,可分为人、物、其他系统、时钟

步骤

1、识别参与者
2、合并需求获得用例
3、细化用例描述
4、调整用例模型(可有可无)

细化用例描述

1、用例名称
2、简要说明
3、事件流
主事件流: 必执行的过程
备选事件流: 主事件流执行过程中可能发生的分支
4、非功能需求(质量属性)
5、前置条件
6、后置条件
7、扩展点
8、优先级

调整用例模型

建立了初步用例模型后，还可以利用用例间的关系调整用例模型
包含、扩展、泛化

包含关系

两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享

扩展关系

对基用例扩展，基用例是一个完整的用例，即使没有子用例的参与也可以完成一个完整的功能

数据模型

步骤

1、定义概念类: 名词短语法(从用例中找到一些相关的名词，筛选有意义的) 发现用例(动词短语+名词短语)
2、确定类之间的关系:
(1)关联关系
(2)聚合关系
(3)组合关系
(4)泛化关系
(5)依赖关系
(6)实现关系
3、为类添加职责
4、建立交互图

领域模型

又称为概念模型或域模型，也就是找到那些代表事务域概念的对象，即概念类

面向对象设计

1、利用用例与用例图表示需求
2、从用例模型中提炼形成领域模型，用例的实现可以用交互图表示
3、从领域模型和用例图形成类图
4、用包图和类图形成体系结构图

分析模型

用例模型、领域模型、顶层架构图

设计模型

架构图(包图表示)、用例实现图(交互图表示)、类图(完整、精确)、其他(状态图、活动图)

构件化开发方法概述

构件通过连接件连接在一起，共同构成一个建筑物

构件与对象关系

构件

独立部署单元
作为第三方的组装单元
没有(外部可见)状态

对象

一个实例单元，具有唯一标志
可能具有状态，此状态外部可见
封装了自己的状态和行为
构件并非一定包含类，一个类元素只能属于一个构件

构件的获取

1、从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可复用的构件
2、通过遗留工程，将具有潜在复用价值的构件提取出来，得到可复用构件
3、从市场上购买现成的商业构件
4、开发新的符合要求的构件

构件的分类(检索)

关键字分类/检索法: 树形结构/有向无回路图
刻面分类/检索法: 描述构件能够执行哪些功能，被操作的数据，构件应用的语境或其他特征
超文本分类/检索方法

构件复用的方法

检索与提取构件
理解与评价构件
修改构件
构件组装

面向服务的方法

将构件的接口进一步解耦

服务总线ESB

Enterprise Service Bus 注册、部署、管理、执行服务

抽象级别

操作: 最低层，代表单个逻辑单元的事务，包含特定的结构化接口，并且返回结构化的响应
服务: 代表操作的逻辑分组
业务流程: 最高层

原型方法(快速原型法)

在系统开发初期，必须明确系统的功能要求，确定系统边界
根据用户初步需求利用系统工具快速建立一个系统模型，与用户交流

分类

实现功能划分

水平原型: 行为原型，用于界面。细化需求但并未实现功能
垂直原型: 结构化原型，用于复杂算法的实现，实现了部分功能

按照最终结果划分

抛弃式: 探索式原型，解决需求不确定性、二义性、不完整性、含糊性等。
演化式: 逐步演化为最终系统，用于易于升级和优化的场合，适用于Web项目。

敏捷开发(小和快)

以人为本、与用户紧密协作、面对面沟通、尽早发布增量、小而自主的开发团队、适用于规模小的项目

极限编程(XP)

在更短的周期内，更早的提供具体、持续的反馈信息
迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断发展它
依赖于自动测试程序来监控开发进度，并及早的捕获缺陷(测试先行，先测试再编码)
依赖于开发团队内部的紧密协作
尽可能达到程序员短期利益和项目长期利益的平衡

SCRUM并列争求法

Product Backlog(用户故事) -> sprint Backlog(冲刺周期) -> Daily meeting(战例会议) -> Sprint burn down(燃尽图) sprint review meeting -> Release

开发模型

瀑布模型(结构化方法)

评审靠文档
计划->需求分析(需求明确)->设计->编码->测试->运维
需求: 现实中软件的需求很难确定，甚至是不可能和不现实的
交付时间: 需要很长时间才会得到软件的初始版本，如果需求改变可能损失巨大

原型模型(演化模型)

交流->快速计划->快速设计方式建模->构件原型->部署交付和反馈->交流(周期)
优点: 任何功能一经开发就能进入测试，以便验证是否符合产品需求，可以帮助引导出高质量的产品要求
缺点: 如果不加控制地让用户解除开发中尚未稳定的功能，可能对开发人员及用户都会产生负面的影响。

螺旋模型(原型+瀑布)

每转一圈都有一个原型
适用于有风险的项目(大项目、复杂项目)，风险分析
喷泉模型(面向对象法)
分析->设计->实现->维护->演化

特点

无间隙、迭代

V模型(测试模型)

需求分析->概要设计->详细设计->编码->单元测试->集成测试->系统测试->验收测试

RAD快速开发(基于构件、瀑布模型基础之上)

规划->设计&实现->运行
不适用于新技术(构件比较少)
RUP统一过程模型(面向对象方法 重型)
用例驱动、架构为中心、迭代、增量
X(时间组织):初始->细化->构建->交付
Y(内容组织):商业建模->需求->分析和设计->实现->测试->部署->配置和变更管理->项目管理->环境
4+1视图(逻辑、实现、进程、物理、用例)系统架构设计时使用
用例视图: 从外部世界的角度描述正在建模的系统的功能，所有其他视图都依靠用例图来指导
逻辑视图: 描述系统各部分的抽象描述。包括类图、对象图、状态图和协作图。用于建模系统的组成部分以及各组成部分之间的交互方式
过程视图: 描述系统中的进程。当可视化系统中一定会发生的事情时，此视图特别有用，该视图通常包含活动图。
开发视图: 描述系统的各部分如何被组织为模块和组件。管理系统体系结构中的层非常有用。通常包含包图、组件图。
物理视图: 描述如何将前三个视图中所述的系统设计实现为一组现实世界的实体。该视图中的图表展示了抽象部分如何映射到最终部署的系统中。该视图通常包含部署图。

阶段

初始阶段: 明确项目规模、评估项目风险、制定项目计划、阶段技术评审
细化阶段: 确定架构、制定构建阶段计划、建立支持环境、选择构件、阶段技术评审
构建阶段: 对系统进行详细设计，并进行编码、测试、集成等。
移交阶段: 对系统进行全面测试，补充各种文档，并把产品移交用户等。

软件过程管理

能力成熟度模型CMM

从低到高初始级->可重复级->已定义级->已管理级->优化级
初始级: 随意、无秩序、混乱
可重复级: 基本的项目管理过程，成本、进度和功能特性进行跟踪
已定义级: 文档化、标准化、标准软件过程
已管理级: 可预测、有详细的度量标准
优化及: 持续改进

能力成熟度模型集成CMMI

级别	连续式表示法能力等级	阶段式表示法成熟度级别
0	未完成级
1	已执行级	初始级
2	已管理级	已管理级
3	已定义级	已定义级
4	定量管理级	已量化级
5	优化级	持续优化级

来源：雨随落花