HIT-软件构造-blog1

---

碎碎念

第一篇博客这么晚，还是有原因的，作为CSDN小白，因为合并账号把之前的账号注销了，啥都没了，现在重头再来吧。（我恨啊~）

还是从第一章《软件构造的多维度视图和质量目标》开始吧

---

以下正文内容

一、Views of Software Construction

软件构造的多维度视图，这里是考试重点内容，每次考试都会考的！

1.1 经典的图

1.2 六个角度的概念解释

1. Build-time: 关注软件的构造阶段。
2. Run-time： 关注代码的运行阶段。程序在目标机器内部运行时是什么样子，磁盘文件是什么需要加载到内存中吗？在运行时段程序的状态，分析内存占用量、运行素的等等，这里的将会用到Code Snapshot 来进行分析。
3. Code-level: 关注源码，相对于关注模块层次属于微观层面。这一维度关注代码的逻辑组织，也就是源代码是如何被方法、函数、类和接口等底层模块组织起来的，以及内存中代码之间的逻辑关系，如何进行交互。
4. Component-level： 构件维度，关注模块，相对属于宏观层面，源代码如何物理构成或依赖结构（如文件、目录、包、库 等等） 。各个文件或者包如何在物理环境下配置、运行与交互是这个维度下的重点
5. Moment view: 某一特定时刻的软件状态。
6. Period view: 软件形态随时间的变化。

1.3 八种角度下的简要区分

（1）Build-time,moment, and code-level view

这个维度侧重的是源代码在某一时间点的逻辑结构

关键词：Source code，Interface-Class-Attribute-Method（Class Diagram）

有三个层次可以分析：

• 词汇层面： Lexical-oriented source code （面向词法的源码）

半结构化：近乎自然语言的风格（方便程序员）+遵循特定的编程语法（方便编译器）

• 语法层面： Syntax-oriented program structure: e.g., Abstract Syntax Tree (AST)

AST：结构化树， 半结构化，将源代码变成一棵树，对树做操作就是对源代码的修改。

• 语义层面： Semantics-oriented program structure: e.g., Class Diagram（类图 UML ）

类图概念：用以描述接口、类、属性，方法，以及它们之间的关系。

这一部分通常是图形化或形式化表达“需求”和“设计”思想，在设计阶段建模，并转化为源代码。它根据用户要求面向对象分析和设计的结果。

（2）Build-time, period, and code-level view

这个维度关注代码在构建期间的变化，在period角度下，突出变化二字，比如从一个版本到另一个版本时，对向文件添加、修改或删除代码行。

关键词：Code Churn

（3）Build-time, moment, and component-level view

这个维度讲的是：
源代码在物理上被组织成文件，而这些文件进一步被组织为目录；
文件被封装成包，在逻辑上，组成组件和子系统；
其中可重用模块采用库 的形式。

关键词：Package，File，Static Linking，Library，Test Case，Build Script（Component Diagram 组件图）

库的概念

这里我们提一下库（这里指静态链接库）的概念：

1. 概念解释： 库被存储在自己的磁盘文件中，收集可以在各种程序中重用功能的一组代码
2. 来源： 操作系统提供的库、编程语言提供的库、第三方公司提供的库以及自己积累的库。
3. 在build-time时 开发者可以像使用编程语言指令一样使用库中的功能

静态链接与动态链接的概念

链接库文件时分为静态链接（Static linking）和动态链接（Dynamic linking）两种。

静态链接概念： 发生在 构造阶段！！！ 库被拷贝进入代码形成整体，执行的时候无需提供库文件。 库的目标文件看起来与任何目标文件相同，开发者自己创建的。

动态链接概念： 发生在 运行阶段！！！ 库文件不会在build阶段被加入可执行软件，仅仅做出标记；程序运行时，根据标记装载库至内存。发布软件时，记得将程序所依赖的所有动态库都复制给用户。

动态链接的优势：

1. 可以升级到更新版本的库（添加功能或修复错误），而无需重新创建 可执行程序。
2. 许多操作系统可以通过仅将库的单个副本加载到内存中以优化其内存使用，但共享它与需要相同库的其他程序一起使用。
   
   

（4） Build-time, period, and component-level view

这个维度主要关注的是：各项软件实体随时间如何变化？与（2）不同，它更关注文件整体变化而非单单代码行的修改，比如版本的变化

关键词：Software Configuration Item (SCI，配置项)，Version（版本）

这里还介绍了一个版本记录工具：Version Control System(VCS)

（5）Run-time, moment, and code-level view

关键词：Code Snapshot（代码快闪照），Memory dump（内存信息转储）

代码快闪照： 关注程序在某个瞬间内存中的情况。

内存转储： 硬盘上包含内容副本的文件进程的内存，当进程被某个进程由各种内部错误或信号终止时产生。
–Debuggers 可以加载转储文件并显示它包含关于正在运行的程序的状态的信息。
– Information 包括以下内容寄存器，调用堆栈和所有其他程序数据（计数器、变量、开关、标志等）。
– 它是为了分析状态程序和程序员查看内存缓冲区以查看正在处理哪些数据项故障时开启。

（6）Run-time, period and code-level view

这个维度看重看代码的执行跟踪情况，用日志方式记录程序执行的调用次序。

关键词：Execution stack trace，Concurrent multi-threads（并发多线程）

UML 中的序列图：程序单元之间的交互（对象）

（7）Run-time, moment, and component-level view

这个维度和（3）一样都关注的是库、包层面的构件，但更多是程序运行时的库，比如动态链接库。

关键词：Package，Library，Dynamic linking，Configuration，Database，Middleware，Network， Deployment diagram in UML（
UML中的部署图）

（8）Run-time, period, and component-level view

关键词：Event log，Multi-processes，Distributed processes
使用日志查看系统使用情况。

1.4 Transformation between views

这里我们谈一谈这八个维度的联系，和软件构造需要的过程

1. 空 -> Code

– Programming / Coding (ADT/OOP)（编程）
– Review, static analysis/checking (静态检查)

代码是一个从无到有的过程

2. Code -> Component

– Design (ADT/OOP; Reusability; Maintainability)
– Build: compile, static link, package, install, etc（构建，静态链接）

完成源代码之后程序逐步完善，最后被封装，

3. Build-time -> Run-time

– Install / deploy
– Debug, unit/integration testing (Robustness and Correctness)

当程序构建成功后需要运行，测试其正确性以及鲁棒性

4. Moment -> Period

– Version control （版本控制）
– Loading, dynamic linking, execution (dumping, profiling, logging)
– Concurrent threads

最后我们还可能需要多次修改调整程序，或者记录程序版本变化，也就需要Moment->Period维度的转变。

二、Quality Objectives of Software Construction

什么是软件系统的质量

• 外部质量取决于内部质量
• 外部质量因素影响用户
• 内部质量因素影响软件本身和它的开发者

2.1 外部质量因素

1. External1：Correctness（正确性）

正确性是最重要的指标
需要按照预先定义的“规约”执行
我们要做的：

• .测试和调试中发现不正确、消除不正确。
• 采取防御式编程，即写程序时就保证正确性
• 最后也可以通过形式化验证发现问题。

2. External 2: Robustness（健壮性）

• 健壮性概念： 健壮性是对异常情况的处理，是对正确性的补充。
• 解释：：出现规约定义之外的情形的时候，软件要做出恰当的反应，出现异常时不要“崩溃”
• 异常概念： “normal”和“abnormal”是主观而非客观。未被specification覆盖的情况即为“异常情况”，这其实取决于spec的范畴
  
  

3. External 3: Extendibility（可扩展性）

• 可扩展性概念： 一旦程序规约需要修改，是否成本过高？为了应对变化，我们需要设计易修改的程序。
• 我们能做的： 简约主义设计和分离主义设计
  
  

4. External 4: Reusability（可复用性）

• 可复用性概念： 程序可以一次开发多次使用。尽可能发现程序的共性以便重复利用已有代码。
  
  

5. External 5: Compatibility（兼容性）

• 兼容性概念： 指程序在不同环境下是否可用，不同的软件系统之间相互可容易的集成。开发时要注意保持设计的同构性。
  
  

6. External 6: Efficiency（效率）

• 效率概念： 对于性能，要与其他质量属性进行折中，并且注意性能的前提是保持正确性，否则没有意义。
• 注意： 过度优化会导致软件不能适应变化和复用。
  
  

7. External 7: Portability （可移植性）

可移植性概念： 指软件可以方便的在不同的技术环境（硬件、操作系统）之间移植。

8. External 8: Ease of use（易用性）

易用性概念： 程序员写的代码尽量要易学、便于安装操作和监控，尽量给用户提供详细指南。

9.External 9: Functionality（功能性）

• 功能性概念： 功能性是指系统提供的可能性范围。但开发者给软件增加越来越多的功能，结果会导致程序极为复杂、不灵活、占用过多的磁盘空间。

• 我们要做的： 每增加一点小功能，都要保证其他质量属性不受到损失。
  
  

10.External 10: Timeliness（及时性）

**及时性概念：**确保在使用者需要之前完成开发。

11.External 10++: Other qualities

Verifiability （可验证性）、Integrity （完整性）、 Repairability （可修复性）、Economy （经济性）

2.2 内部质量因素

代码行数、圈复杂度（Cyclomatic Complexity）、高内聚低耦合（coupling，cohesion）。
可读性、可理解性、简洁度、规模大小。

2.3 多因素折中

即：

完整性与易用性
经济与功能
效率与便携性
效率与可重用性
经济与可重用性
及时性与可扩展性

2.4 Five key quality objectives

• Specification（规范，说明书）： easy to understand, understandability
• Reusability(可重用性)： cheap for develop
• Maintainability（可维护性）： ready for changes, easy to extend
• Robustness/Correctness（稳健型与正确性） ： safe from bug, not error-prone
• Chapter ADT and OOP: efficient to run

小小总结

第一章的内容还是概念性比较多，对后续的课程有一个学习框架，如有不对的地方还希望大家指正批评