软件构造复习笔记

由于在之前的夏季小学期选择的课程并非java，因此在java方面投放了部分精力自学。博客整理的开始时间较晚，请见谅。现在开始对软件构造课程进行复习和整理。（主要基于对课件的阅读以及课堂知识的整理）

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

Moment维度是指程序在某一个时刻的表现，而Period维度指程序在一段时间内的表现；
Build-time维度是指程序在编码阶段的表现，而Run-time维度关注程序在运行时的表现；
Code-level维度在程序代码的语句层面，Component-level维度指程序一段代码：一个包，一个库

Build-time views：
code-level view 关注源代码的逻辑组织情况，结构，方法等
component-level view 关注源代码的物理组织，如库，包，文件等等是如何链接组织起来的
(1) Build-time, moment, and code-level view 关注的是源码的组织情况，可在词汇层面（源码）、语法层面（抽象语法树）、语义层面（类图）三个层面分别分析。
AST：抽象语法树（abstract syntax code，AST）是源代码的抽象语法结构的树状表示，树上的每个节点都表示源代码中的一种结构，这所以说是抽象的，是因为抽象语法树并不会表示出真实语法出现的每一个细节，比如说，嵌套括号被隐含在树的结构中，并没有以节点的形式呈现。抽象语法树并不依赖于源语言的语法，也就是说语法分析阶段所采用的上下文无文文法，因为在写文法时，经常会对文法进行等价的转换（消除左递归，回溯，二义性等），这样会给文法分析引入一些多余的成分，对后续阶段造成不利影响，甚至会使合个阶段变得混乱。因些，很多编译器经常要独立地构造语法分析树，为前端，后端建立一个清晰的接口。（初始理解就是关于将源代码结构表示为树）
AST：彻底结构化，将源代码变为一棵树，对树做各种操作==对源代码的修改
(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不同
Run-time views
区分了动态链接和静态链接
(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。

3.软件系统的质量

外部质量因素（影响用户）
External 1: Correctness（正确性），正确就是按照预先定义的“规约”执行，这是软件开发最重要质量指标，一个可用的软件一定是正确的，所以首要保证软件的正确性，其他的都可以做妥协、让步，但只有这一项不可妥协。
通过测试和调试可以发现和消除不正确。
防御式编程可以在写程序时就保证正确性。
形式化方法：通过形式化验证发现问题。
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 (经济性)。

内部质量因素（影响软件本身以及开发者）
代码行数、圈复杂度、结构：高内聚低耦合、可读性、可理解性、整洁度、大小

折中、妥协

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

正确性决不能折中。

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

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