软件构造中的多维度视图

按阶段划分：构造时/运行时视图
按动态性划分：时刻/阶段视图
按构造对象的层次划分：代码/构件视图

• Software=Modules(Components)+Data/Control Flows

• 软件的质量目标评价不能脱离外部环境

• 开发软件的流程
  计划-分析-设计-完善-测试&融合-维护

Built-time 构造阶段

代码层——代码的逻辑组织
模块层——代码的物理组织

时刻性——特定时刻的软件形态
周期性——软件形态随时间的变化

1）构造阶段+时刻+代码层（词汇、语法、语句）

• 词汇：程序中所使用的语句、变量形式（？）
  半结构化：近乎自然语言的风格+遵循特定的编程语法
  方便程序员+方便编译器
• 语法：程序->树形结构/流程图
  AST：彻底结构化，将源代码变为一棵树，对树的各种操作==对源代码进行的修改
• 语句：图形化或形式化表达需求和设计思想，再转化成Code

2）构造阶段+周期+代码层
记录代码改变的“过程”——版本控制工具

3）构造阶段+时刻+模块层（代码的组织情况）

• 模块化地组织源代码文件，Files->packages

如何组织？

• 使用库文件，可以使开发者像使用编程语言指令一样使用库中的功能
• 操作系统提供的库、编程语言提供的库、第三方提供的库、自己累积的库
• 如何利用库文件需要进行链接（静态/动态）
  javac -classpath ./lib/*.jar
  静态链接发生在构造阶段，库被拷贝进入代码形成整体，执行的时候无需提供库文件（也就是执行的时候不依赖于库文件？缺点：难以升级）

4）构造阶段+周期+模块层（代码的版本Version）

Run-time 运行阶段

• 运行时：程序被载入目标机器，开始执行

代码层：逻辑实体在内存中如何呈现
构件层：物理实体再硬件环境中如何呈现

时刻性：略
周期性：略

1）可执行程序（直接编译，一次性，找到起始位置执行，存在缺点：不同机器码编译结果不同，可移植性差）
2）解释性可执行程序（java，根据不同操作系统的运行情况编译成机器能够理解的执行程序）
3）库文件（动态链接；java）

• 程序的源文件和库的源文件转化成两部分，再链接在一起
• 库文件不会再built阶段被加入可执行软件，仅仅做出标记
• 程序运行时，根据标记装载至内存库
• 发布软件时，需要发送所有动态库文件（因为是分离的）
• 易于升级

4）配置文件（对程序执行进行限定）
5）分布式程序：需要多个运行程序，分别部署于多个计算机物理环境

6.1）运行阶段+时刻+代码层

内存转储信息（Debuggers、Information、Analyze）

6.2）运行阶段+周期+代码层（时序图UML）
执行跟踪（用日志方式记录程序执行的调用次序）

6.3）运行阶段+时刻+模块层
在某一时刻，不同机器/同一机器不同单元->程序的不同模块

6.4）运行阶段+周期+模块层（事件日志：系统层面）

SUMMURY
Ø => Code
Code => Component
Build-time => Run-time
Moment => Period

软件构造的质量目标

外部质量->用户
内部质量->软件本身和开发者

1）正确性（相对的）

• 分层。上层的正确性需要下层正确性的保障

2）鲁棒性/健壮性

• 对异常情况（取决于程序的规格说明）做出反应的能力

3）易扩展性

• 适应变化的能力，软件越大越难以扩展。
• 模块自治性越强，变化对其余模块的影响越小
• 【ADT and OOP】【Modularity and Adaptability】

4）复用性

• 利用共性避免重复实现
• 【Design for/with reuse】

5）兼容性（设计的一致性、标准性）

• 标准的变量/数据结构/用户接口

6）效率（对资源尽可能少的需求）

• 硬件资源、空间资源、时间资源、etc…
• 【Performance】

7）可移植性（各种硬件和软件环境）

8）易用性（用户->安装、运行、监控的容易度）

• 【GUI】

9）功能性

• 一致性易缺失，影响易用性
• （用户追求功能的多样性还是质量？）
• 【Agile, SCM】

10）时效性

• 是否易于验证
• 软件系统 保护 程序和数据 免受 未经授权的访问和修改 的 能力
• 按照预算或好于预算

其他）

• 圈复杂度
• 高内聚与低耦合（耦合度：模块之间的交互；内聚性：模块本身的独立性）
• 大小
• 复杂性（是否易于理解）

Tradeoff

• 某些性质之间的权衡，比如复用性和功能性
• 正确性一定是最重要的因素