Revision Chapter1

最新推荐文章于 2025-11-10 22:41:45 发布

原创最新推荐文章于 2025-11-10 22:41:45 发布 · 240 阅读

0 ·

CC 4.0 BY-SA版权

软件构造专栏收录该内容

12 篇文章

订阅专栏

本文总结了软件构造的三维视图概念，包括构造和运行阶段的代码与组件视角，以及软件质量的内外部参数，如正确性、鲁棒性和可扩展性等关键指标。

快要期末了，顺带总结一下各章的重要内容。

1 软件构造的三维视图

这是贯穿整个课程的内容，也是重点中的重点。把握这个三维视图对于宏观把握软件构造很有必要。

我们分成这样的三个维度：
Moment（时刻）——Period（阶段）
Code（代码）——Component（模块）
Build-time（构造）——Run-time（运行）

1.1 三维视图表格

在这里插入图片描述
我们需要知道哪些内容对应的是哪一个维度。

1.2 Build-time 构造阶段

1.2.1 Code

包含了
代码（code）->方法（method）->类（class）

1.2.1.1 Moment

source code ：源代码
AST：软件执行的流程树（语法结构树）
->语法结构
Class-dia：有哪些类，以及类与类之间的关系
->语义结构
UML语言就是一个例子

1.2.1.2 Period

code churn：代码变化，版本控制工具

1.2.2 Component

包含了
package、file、lib、test case

1.2.2.1 Moment

反映代码的组织情况：这些类和文件是如何组织起来的？

Library 库：编写、构造、测试阶段都会用到
1. 找lib：javac -classpath ./lib/*.jar
2. 将lib链接到程序中：
  static linking 静态链接：将lib拷贝到代码中（执行时就不用提供了）
Component dia：多个类如何组成package

1.2.2.2 Period

Component层面的东西是如何变化的

SCI
针对Component层面的版本控制工具

1.3 Run-time运行阶段

1.3.1 Code

1.3.1.1 Moment

在某个时刻有什么对象？值是什么？

snapshot diagram※ 描述上述的问题
memory dump：内存信息转储——看当前内存的使用情况

1.3.1.2 Period

Sequence dia 时序图：类和方法的调用顺序与规划
.exe tracing 执行跟踪：在某个时间点执行的是哪个类哪个方法

1.3.2 Component

1.3.2.1 Moment

deployment dia：在不同的运行位置的配置情况

1.3.2.2 Period

event log：事件日志

2 软件构造的质量标准

2.1 主要目标：

易于理解
易适应变化
开发成本低：考虑代码的复用
健壮性：非法输入软件不至于崩溃
运行效率：特别是对于有大量数据需要处理时

2.2 外部质量参数

这部分参数影响用户的使用

2.2.1 ※正确性

首要因素！！！！

正确形式有条件的：即符合软件规格说明书。
对于分层的软件系统来说，应当保证本层及以下都是正确的。
保证手段：测试

2.2.2 鲁棒性

即健壮性，针对的是规格说明书之外的情况。
也就是说软件应当有一定的面对异常时做出适当反应的能力。

2.2.3 易扩展性

易于调整和适应变化

同软件规模紧密相关，理论上规模越大越难以扩展
两个原则
- 体系结构尽量简单
- 体系模块尽量自治（即对其他模块的影响和牵连尽量小）

2.2.4 复用性

2.2.5 兼容性

某个软件在A环境下可用，在B环境下依旧可用的能力。
这个性质主要在于设计的“一致”和“标准化”，要首先明确一个可以适应于很多情况的标准

2.2.6 效率

对于硬件资源尽可能少的需求

2.2.7 可移植性

将软件移到各种硬件和软件环境，比如从Mac OS到Win，从iOS到Android等。

2.2.8 易用性

便于用户使用，使用户有良好的使用感。
以“容易掌握”作为评价标准。
这就要求要做到结构简洁，并站在用户的角度去设计软件。

2.2.9 功能性

质量优先！尤其是要保证主要功能的质量，再去考虑其他功能的附加。
功能不是越多越好，过于复杂的功能也会导致软件使用起来比较复杂。

2.2.10 时效性

即在ddl之前完成软件开发

2.2.11 其他

此外软件还应做到：
易于验证、未经授权保证完整的能力、可修复、在预算内完成等等

2.3 内部质量参数

内部质量参数影响软件本身和开发人员。
！内部质量参数影响和控制外部质量参数！

2.3.1 LOC

代码行数和复杂性

2.3.2 耦合度

2.3.3 内聚度

我们应当尽量做到高内聚，低耦合。

2.3.4 可读性

2.3.5 复杂度

2.3.6 大小

2.4 面对质量因素应当做的

质量因素之间可能存在矛盾的情况，面对这样的情况，我们应当在质量因素之间权衡、折中、妥协。
- 给出标准，并根据标准和实际情况做出选择。
- 正确性永远是首要的！！！
强调模块化编程。