1.1 Multi-Dimensional Views of Software Construction

1. 软件构造过程中的多维度视图

多维度视图¹

	Moment		Period
	Code-level	Component-level	Code-level	Component-level
Build-time	Source code, AST, Interface-Class-Attribute-Method (Class Diagram)	Package, File, Static Linking, Library, Test Case, Build Script (Component Diagram)	Code Churn	Configuration Item, Version
Run-time	Code Snapshot, Memory dump	Package, Library, Dynamic linking, Configuration, Database, Middleware, Network, Hardware (Deployment Diagram)	Execution stack trace, Concurrent multi-threads	Event log, Multi-processes, Distributed processes
			Procedure Call Graph, Message Graph (Sequence Diagram)

• Moment维度关注于程序在某一个时刻的表现，而Period维度更关注于程序在一段时间内的表现；
• Build-time维度关注程序还未被投入运行，编码阶段的表现，而Run-time维度更关注于程序运行时的表现；
• Code-level维度关注程序的语句层面，Component-level维度更关注于一段代码，当作一个块观察比如一个包、一个库。

(1) Build-time, moment, and code-level view 关注的是源码的组织情况，可在词汇（源码）、语法（抽象语法树）、语义（类图）三个层面分别分析。

(2) Build-time, period, and code-level view 关注的是代码的变化（Code churn代码变化）

(3) Build-time, moment, and component-level view 关注的是包/库，而且是静态链接库

(4) Build-time, period, and component-level view 关注代码的更迭，与(2)中不同的是，这个维度下更关注文件版本的变化，而不是具体语句的变化（2中关注的是哪一行代码被修改了）----VCS的引出

(5) Run-time, moment, and code-level view 关注的是程序在某个时间点内存中的情况，如代码快照图(Code Snapshot)、内存信息转储(Memory dump)。

(6) Run-time, period and code-level view 关注的是代码的执行情况，执行跟踪

(7) Run-time, moment, and component-level view 关注的也是包/库，但却是在代码执行过程中的情况，如动态链接库

(8) Run-time, period, and component-level view 关注的是系统的使用情况，使用日志查看

2. 视图之间的联系

从无到有，写出了代码，就进入了Build-time维度，开始只是单个的没有任何联系的代码文件，所以是在moment+Code-level维度，此时随着时间的推移，代码删删改改，就属于Period+Code-level了，而代码越写越多成为了一个包，甚至形成了一个库，于是就属于moment+Component-level维度了，但是随着时间的推移，你的库文件由于需求的变化发生了变化，所以就属于Period+Component-level。代码写好了，投入运行，进入Run-time维度，观察的如果是某一句代码的执行后结果，那就是moment+Code-level维度，但如果看的是代码执行的轨迹，那就是Period+Code-level维度，而如果看的是一个库文件的连接情况等，那就是moment+Component-level维度了，如果看的是线程或进程的执行过程，也就是通过日志等手段查看一段时间内系统都做了什么事情，那么就是Period+Component-level了。

1.2 Quality Objectives of Software Construction

1. 软件系统的质量

外部质量因素

External 1: Correctness（正确性），正确就是满足spec，这是软件开发最重要的因素，一个可用的软件一定是正确的，所以首要保证软件的正确性，其他的都可以做妥协、让步，但只有这一项不可妥协。

External 2: Robustness（鲁棒性），通过抛出异常然后处理异常等方式让出错的程序恢复到正常的执行流程上。

External 3: Extendibility（易扩展性），要便于软件功能的增加/扩展（ADT、OOP、留下一个Visitor），降低未来修改软件时的成本。

External 4: Reusability（复用性），在异性之间尽可能地寻找共性，以便于未来可以直接使用现在写的这段代码。这样可以降低软件地开发成本。

External 5: Compatibility（兼容性），在不同的环境下都是可用的，不同的软件系统之间相互可容易的集成。

External 6: Efficiency（效率），不要过早的优化，性能在没有正确性保障的条件下是没有意义的。

External 7: Portability（可移植性），软件可方便的在不同的技术环境之间移植。

External 8: Ease of use（易用性），学习成本低，结构简单、清晰，易于使用。

External 9: Functionality（功能性），功能过多会导致易用性的降低。主要功能要首要提升质量。

External 10: Timeliness（时效性），软件要能够在交付时间之前完成开发交给使用者。

External 10++: Other qualities，Verifiability (可验证性)，Integrity (完整性)，Repairability (可修复性)，Economy (经济性)。

内部质量因素

代码行数(LOC)、圈复杂度、结构：高内聚低耦合、可读性、可理解性、整洁度、大小

折中、妥协

Integrity vs. ease of use、Economy vs. functionality、Efficiency vs. portability、Efficiency vs. reusability、Economy vs. reusability、Timeliness vs. extendibility

这些质量属性之间往往不能兼得，当某一项满足的足够好的时候有可能其他项的表现极差，因而需要做权衡，使得各部分的表现都较好，在某些特定要求下也可以放弃优化其他项而做到某一项的极致，这需要靠开发者的经验积累来判断。

正确性是绝不能与其他质量因素折中的！！！

在OOP开发中，通过封装、模块化、组件、抽象、分散、错误处理、信息隐藏、框架、接口等技术来尽可能地满足上述地质量因素，提高软件的开发质量。

2. 五个关键的质量指标

• Elegant and beautiful code：代码要容易理解，通过统一变量/方法的命名标准、代码的风格、注释、包组织结构、必要时重构代码等方式让代码尽可能的容易理解。
• Design for/with reuse：ADT/OOP、接口、继承(Overload、Override)、多态、泛型、框架等技术可用于提高代码的可复用性。
• Low complexity：当复杂度较低的时候，代码就容易被扩展新的功能，所以要高内聚低耦合，遵从SOLID原则、OO设计模式、使用VCS控制代码版本
• Robustness and correctness：使用测试驱动的开发、异常处理、Assertion机制、防御式编程等技术保证程序的健壮性和正确性。
• Robustness and correctness：使用测试驱动的开发、异常处理、Assertion机制、防御式编程等技术保证程序的健壮性和正确性。
• Performance and efficiency：使用设计模式、并行/多线程等技术提升性能。

---

1. 加粗项的为本课程所关注的 ↩︎