概要设计报告与高可信软件设计
概要设计报告的编写结构,以及高可信软件设计:可依赖性概念与属性、可依赖性度量、冗余与多样性、容错体系结构、信息安全工程。
🎯学习目标
- 掌握概要设计报告的结构与各部分编写要点;
- 掌握可依赖性(dependability)的概念与五个属性;
- 掌握可依赖性度量(POFOD、ROCOF、AVAIL)与提高可依赖性的策略;
- 理解三类容错体系结构:保护性系统、自监控体系结构、N 版本编程;
- 掌握信息安全的三个维度、术语、需求与分层/分布式安全体系结构。
1概要设计报告结构
概要设计报告(概要设计说明书)是概要设计阶段的核心产出,把软件需求转化为接近源程序的软件表示。报告通常以文件状态(草稿/正式发布/正在修改)、文件标识、版本、拟稿人/审核人等封面信息开头。
1. 引言
| 小节 | 内容 |
|---|---|
| 1.1 编写目的 | 进一步细化软件总体概貌,加工成接近源程序的软件表示 |
| 1.2 项目背景 | 软件系统名称、设计输入(《XX 系统需求规格说明书》)、使用的用户角色 |
| 1.3 相关术语 | 体系结构设计、接口设计、数据库设计等任务内容说明 |
| 1.4 参考文献 | 萨默维尔《软件工程》、张海藩《软件工程导论》、孙家广《软件工程》等 |
2体系结构、接口与数据库设计
2. 系统体系结构设计
包括系统特点分析、体系结构模式选择与设计。例:某系统为典型的基于事务交互的信息系统,综合应用分层体系结构和 B/S 多层体系结构——用户交互基于浏览器部署,业务逻辑、数据实体基于 Web 服务器运行,数据库基于数据库服务器运行(3 层体系结构)。
| 视图 | 表示方式 |
|---|---|
| 逻辑视图设计 | 用简化的类图表示系统构成及关系,并文字描述 |
| 开发及运行视图设计 | 用分层体系结构表示,注意各个类在分层结构中的体现(与类图对应) |
| 部署视图设计 | 用部署图表示,并文字说明 |
3. 接口设计
外部接口:与其他系统、硬件的接口。需与需求分析的上下文模型保持一致。例:AGV 状态信息用 JSON 格式以 100ms/次发送给系统。
{ "agvID":"agv的ID编号",
"stateInfo":[{ "agvState":"状态", "agvX":"X坐标", "agvY":"Y坐标",
"taskState":"任务状态", "electric":"电池电量", "workTime":"工作时间" }] }
| 接口要素 | 说明(示例:零件仓库交互接口) |
|---|---|
| 交互机制 | 异步请求,备料完成后回调本接口 |
| 接口技术 | RestfulAPI,采用 Java 开发 |
| 访问地址 | http://localhost:8081/material |
| 参数类型 / 输入 / 输出 | String / 零件 Id、零件坐标 / 返回提示信息 |
内部接口:采用面向对象方法设计,详见体系结构逻辑视图和开发视图设计。
4. 系统数据库设计
概念数据库设计:用 PowerDesigner 等工具进行逻辑建模,导出 SQL 创建数据库;逻辑数据库设计:用 ER 图完成概念设计,描述实体、联系。
3系统出错处理设计
5.1 出错信息:用一览表方式说明每种可能出错或故障出现时,系统输出信息的形式、含义,并设计友好的出错提醒界面。
5.2 补救措施:
后备技术
数据库每周全备份 + 每天增量备份;或冷备机制(副本存移动硬盘);或增加备份服务器,通过数据发布订阅方式与数据库服务器同步数据。
恢复技术
磁盘故障时:从移动硬盘取全数据库+增量恢复,取程序架包重新部署启动;或切换到备份服务器运行。
4可依赖系统的概念与属性 ⭐
可依赖性(dependability)由 Jean-Claude Laprie 于 1995 年提出,目的是覆盖系统的可用性、可靠性、安全性和信息安全性。一个有用的系统不一定总具有很高的可依赖性。
可依赖性的五个属性
可用性
Availability可靠性
Reliability安全性
Safety信息安全性
Security韧性
Resilience可依赖性需求分两种:① 功能性需求——定义检查和修复措施、防止失效和外部攻击的保护错误;② 非功能性需求——定义系统需要的可靠性和可用性。(1993 年华沙机场空难案例说明:软件按规格说明正常工作、程序无错误,但需求规格说明不完备导致系统失效。)
5可依赖性度量与提高策略
可依赖性度量
| 度量 | 含义 | 示例 |
|---|---|---|
| POFOD 请求失效概率 | 系统服务请求将导致失效的可能性 | POFOD=0.001 即每 1000 次请求可能 1 次失效 |
| ROCOF 失效发生率 | 一段时间或一定执行次数内观测到的失效次数;其倒数是 MTTF(平均失效间隔时间) | 1000 次事务有 1 次失效,ROCOF=1/1000 |
| AVAIL 可用性 | 请求服务时系统可使用的概率 | AVAIL=0.9999 即运行时间 99.99% 可用 |
提高可依赖性的策略
改善可靠性的三个辅助方法(基于错误、故障、失效的差别):
故障避免
用软件开发方法减少编程故障、投入使用前发现故障。如使用强类型语言以允许全面编译器检查、避免易出错元素(如指针)。
故障检测和修复
部署前通过验证和确认发现并去除故障。如系统测试、调试、静态分析。
容错
系统设计成具备容错能力,故障及无法预期的行为在执行时能被检测和管理,避免系统失效。
6容错体系结构 ⭐
容错机制确保运行时可靠性,即使发生软硬件故障也能保证系统正常工作,可检测并纠正错误状态。为提供容错,系统体系结构必须具有一定的冗余性以及多样化的硬件和软件。容错设计分硬件容错(关键硬件备份)和软件容错(备份软件逻辑和数据)。常见三类容错体系结构:
6.1 保护性系统
一种与其他系统相关的专用系统,通常是对某些过程的控制系统。它独立地监视系统环境,若传感器指示控制系统未正常工作,则保护系统被激活并指挥设备运行。只包含最紧要的功能,能把系统从危险状态转换到安全状态。
6.2 自监控体系结构
系统设计成监视自身操作,在不同通道计算并比较输出:输出一致且同时可用则判定正常;输出不同则假设发生失效,在状态输出线上输出失效异常,控制转移到另一系统。要求:① 每个通道使用不一样的硬件;② 不同通道使用不同的软件。
适用情形:计算正确性非常重要、但可用性并不很重要(如医疗诊断系统,可靠性比可用性更重要)。高可用时需并行使用多个自监控系统 + 切换单元(如空中客车飞行控制系统用 5 个自检查计算机并行计算,主/次系统用不同处理器、不同生产商芯片组、不同语言、不同团队开发以获得多样性)。
6.3 N 版本编程
使用相同的规格说明,同一软件由多个小组实现,各版本在不同计算机上执行,用投票系统比较输出,不一致或未及时产生的输出被拒绝。至少需 3 个版本,单个失效时两个版本应一致。Hatton(1997) 总结:三通道系统约比单通道系统可靠性高 5-9 倍。
7信息安全工程
20 世纪 90 年代互联网广泛使用带来设计实现安全系统的挑战。攻击者可能滥用系统硬件、盗窃机密数据或破坏正常服务。
信息安全的三个维度
机密性
系统中机密信息可能被泄露、被未授权的人或程序访问。例:从电商系统窃取信用卡数据。
完整性
系统中完整性信息可能被损坏或引起错误,使其异常或不可靠。例:删除数据的蠕虫。
可用性
系统或数据有时可能无法访问。例:使服务器过载的拒绝服务(DoS)攻击。
组织角度的三个层次:① 基础设施信息安全(系统和网络的安全维护,是系统管理问题:用户和权限管理、系统软件部署维护、攻击监控检测和恢复);② 应用信息安全(个人应用系统或相关系统群);③ 操作信息安全(系统的安全运行和使用)。
信息安全术语
| 术语 | 定义 |
|---|---|
| 资产 Asset | 必须保护的有价值的东西(软件系统本身或使用的数据) |
| 攻击 Attack | 利用漏洞,有目的地对系统资产或财物造成损坏(外部/内部攻击) |
| 控制 Control | 减少系统漏洞的保护措施(如加密、密码校验系统) |
| 暴露 Exposure | 可能对系统造成的损失或损坏(数据损失或修复所花的时间精力) |
| 威胁 Threat | 有可能造成损失或损坏的情况(受到攻击的系统漏洞) |
| 漏洞 Vulnerability | 基于计算机的系统弱点(如不要求强口令的密码系统) |
信息安全需求
Firesmith(2003) 找出 10 类信息安全需求:身份验证、认证、授权、免疫(防病毒蠕虫)、完整性、入侵保护、不可抵赖性、隐私、信息安全审计、系统维护的信息安全需求。信息安全需求的初步风险评估过程:资产识别→资产价值评估→威胁识别→攻击评估→暴露评估→控制识别→可行性评估→信息安全需求定义。
信息安全体系结构
⭐重点例题
🎯自测(点击展开)
可依赖性包含哪五个属性?
可用性和可靠性有什么区别?
提高可依赖性为什么需要冗余加多样性?
三类容错体系结构是什么?
信息安全的三个维度是什么?
设计信息安全体系结构需考虑哪两个基本问题?
📝强化题库
选择题点选即时判分;填空题输入后"检查"或"显示答案"。