系统架构设计师：
第一部分 企业信息化战略与实施
第二部分 软件工程
第三部分 软件架构设计
文章目录
- 系列文章目录
- 前言
- 一、软件开发方法
- 1.软件开发模型
- 二、需求工程
- 1.需求获取
- 2.需求分析
- 3.UML4+1视图（案例分析）
- 三、软件系统建模
- 四、系统设计
- 1.界面设计
- 2.结构化设计
- 3.面向对象设计
- 五、测试与评审
- 1.软件测试
- 2.测试类型
- 3.测试用例设计
- 4.测试阶段
- 5.面向对象的测试
- 6.软件调试
- 六、系统运行与软件维护
- 1.系统转换计划
- 2.软件维护
- 总结
前言
软件工程
提示：以下是本篇文章正文内容，下面案例可供参考
一、软件开发方法结构化法：
- 用户至上
- 严格区分工作阶段，每阶段有任务和成果
- 强调系统开发过程的整体性与全局性
- 系统开发过程工程化，文档资料标准化
- 自顶向下，逐步分解（求精）
原型法：
- 适用于需求不明确的开发
- 包括抛弃型原型和进化型原型
面向对象方法：
- 更好的复用性
- 关键在于建立一个全面、合理、统一的模型
- 分析、设计、实现三个阶段，界限不明确
面向服务的方法：
- SO方法有三个主要的抽象级别：操作、服务、业务流程
- SOAD分为三个层次：基础设计层（底层服务构件）、应用结构层（服务之间的接口和服务级协定）和业务组织层（业务流程建模和服务流程编排）
- 服务建模：分为服务发现、服务规约和服务实现三个阶段
敏捷开发方法：
- XP（Extreme Programming,极限编程）在所有的敏捷型方法中，XP是最引人瞩目的。它源于Smalltalk圈子，特别是Kent Beck和Ward Cunningham在20世纪80年代末的密切合作。XP在一些对费用控制严格的公司中使用，已经被证实是非常有效的。
- Cockburn的水晶系列方法，水晶系列方法是由Alistair Cockburn提出的。它与XP方法一样，都有以人为中心的理念，但在实践上有所不同。Alistair考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度纪律性不同，Alistair探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。也就是说，虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。
- 开放式源码，这里提到的开放式源码指的是开放源码所用的一种运作方式。开发式源码项目有一个特别之处，就是程序开发人员在地域上分布很广，这使得它和其他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一个地点工作。开放源码的一个突出特点就是查错排障的高度并行性，任何人发现了错误都可以将改正源码的“补丁”文件发给维护者。然后由维护者将这些“补丁”或是新增的代码并入源码库。
- SCRUM。SCRUM已经出现很久了，像前面所论及的方法一样，该方法强调这样一个事实，即明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决明确定义了的可重复的问题。
- Goad的功用驱动开发方法（FDD-Feature Driven Development）FDD是由Jeff De Luca和大师Peter Gpad提出来的。像其他方法一样，它致力于短时的迭代阶段和可见可用的功能。在FDD中，一个迭代周期一般是两周。在FDD中，编程开发人员分成两类：首席程序员和“类”程序员（class owner）。首席程序员是最富有经验的开发人员，他们是项目的协调者、设计者和指导者，而“类”程序员则主要做源码编写。
- ASD方法：ASD（Adaptive Software Development）方法由Jim Highsmith提出，其核心是三个非线性的、重叠的开发阶段：测测、合作与学习。
净室软件工程： - 净室即无尘室、洁净室。也就是一个受控污染级别的环境
- 使用盒结构规约（或形式化方法）进行分析和设计建模，并且强调将正确性验证，而不是测试，作为发现和消除错误的主要机制。
- 使用统计的测试来获取认证被交付的软件的可靠性所必需的出错率信息
概述：
- 软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
- 软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
面向对象分析（OOA）：
3. 对象
4. 类（实体类、边界类、控制类）
实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息。例如：在线教育平台系统可以提取出学员类和课程类，他们都属于实体类。
控制类是用于控制用户工作的类，一般是由动宾结构的短语（“动词+名词”或“名词+动词”）转化来的名词，例如：用例“身份验证”可以对应于一个控制类“身份验证器”，他提供了与身份验证相关的所有操作。
边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。
5. 抽象
6. 封装
7. 继承与泛化
8. 多态
9. 接口
10. 消息
11. 组件
12. 模式和复用
- 结构化建模方法：是以过程为中心的技术，可用于分析一个现有的系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图（DFD）。对于流程较为稳定的系统可考虑结构化建模方法。
- 信息工程建模方法（或数据库建模方法）是一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。信息工程建模方法所创建的模型被称为实体联系图（ERD）。主要用于数据建模。
- 面向对象建模方法将“数据”和“过程”集成到被称为“对象”的结构中，消除了数据和过程的人为分离现象。面向对象建模方法所创建的模型被称为对象模型。随着面向对象技术的不断发展和应用，形成了面向对象的建模标准，即UML（统一建模语言）。UML定义了几种不同类型的模型图，这些模型图以对象的形式共建一个信息系统或应用系统。目前比较常用的建模方法。
- 尽早、不断的进行测试
- 程序员避免测试自己设计的程序
- 既要选择有效、合理的数据，也要选择无效、不合理的数据
- 修改后应进行回归测试
- 尚未发现的错误数量与该程序已发现错误数成正比
- 算法层（单元测试）：包括等价类划分测试、组合功能测试（基于判定表的测试）、递归函数测试和多态消息测试
- 类层（模块测试）：包括不变式边界测试、模态类测试和非模态类测试
- 模板层/类树层（集成测试）：包括多态服务测试和展平测试
- 系统层（系统测试）
软件调试方法：
- 蛮力法：主要思想是“通过计算机找错”，低效，耗时
- 回溯法：从出错处人工沿控制流程往回追踪，直至发现出错的根源。复杂程序由于回溯路径多，难以实施
- 原因排除法：主要思想是演绎和归纳，用二分法实现
软件调试与测试的区别：
- 测试的目的是找出存在的错误，而调试的目的是定位错误并修改程序以修正错误
- 调试时测试之后的活动，测试和调试在目标、方法和思路上都有所不同
- 测试从一个已知的条件开始，使用预先定义的过程，有预知的结果；调试从一个未知的条件开始，结束的过程不可预计
- 测试过程可以事先设计，进度可以事先确定；调试不能描述过程或持续时间
遗留系统演化策略：
- 淘汰策略：遗留系统的技术含量较低，且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费，系统分析师应该善于“变废为宝”，通过对遗留系统功能的理解与借鉴，可以帮助新系统的设计，降低新系统开发的风险。
- 继承策略：遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。
- 改造策略：遗留系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需求。这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧数据模型向新的数据模型的转化。
- 集成策略：遗留系统的技术含量高，但其业务价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略的集成。
新旧系统的转换策略：
数据转换与迁移：
- 正确性维护：指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
- 适应性维护：指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业的外部市场环境和管理需求的不断变化也使得各级管理人寰不断提出新的信息需求。
- 完善性维护：扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
- 预防性维护：为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰。如将专用报表功能改成通用报表生成功能，以适应将来吧奥比奥格式的变化。
总结
系统架构设计师 软件工程内容
