目录
0 前言
软件视图是一种用来描述软件在构造时和运行时各个代码模块状态的工具。软件视图不仅仅包括代码程序,也包括外部文件组织形式,了解并合理运用软件视图这个强有力的工具,可以使我们更好更有效的阅读程序,理解程序,构造软件。同时,还涉及了一些软件质量的判断因素。本篇博客根据上课的内容以及个人扩展知识原创编写,作用于对学习过的内容总结和补充。
1 视图分类
软件视图可以按照以下规则进行分类:
按阶段划分:构造时视图(Build-time Views)/ 运行时视图(Run-time Views)
按动态性划分:时刻图(Moment Views) / 阶段图(Period Views)
按组织形式划分:代码图(Code Views) / 组件图(Component Views)
一些解释:
- 几种视图之间并不是孤立的,个人认为,可以将构造视图和运行视图作为两个大前提条件,在这两种视图中,又包括了时刻图和时期图,其中时刻图和时期图又包括了代码级视图和组件级视图。具体图表示可见尾部知识框图。
- 代码级视图——源代码的逻辑组织方式 ,通过基本程序块,如函数,类,方法,接口等,以及它们之间的依赖关系。
- 组件级视图——源代码如何按文件、目录、包、库以及它们之间的依赖关系进行物理组织。
- 时期视图是指在软件开发过程中,版本更新的阶段视图,并不是单个版本在运行时的时期图。
2 构造时视图
2.1 时刻图
2.1.1 代码级视图
在这种情况下,代码级视图(Code-level)主要包括三个主要角度,三者大致呈递进关系:
- 词汇层面Lexical-oriented source code:基于词法的半结构化源码
- 语法层面Syntax-oriented program structure:面向语法的程序结构
- 语义层面Semantics-oriented program structure:面向语义的程序结构,用于表达“需求” 和“设计”思想, 再转化成code 。
2.1.2 组件级视图
在这种情况下,组件级视图(Component-level)主要包括三个角度:packeges,directories以及libraries。其组织结构大致如下:
图1 构造时-运行时-组件级视图关系图
directories,file,source是从上到下的真实物理组织,而packages更像是文件的逻辑组织,可以将一些相关的文件(不论他们是不是在相同的物理目录下)组织在一起。lib库则是包含一些经常复用的代码模块。可复用模块会在以后的文章中进行详细阐述。
2.2 时期图
2.2.1 代码级视图
在这种情况下的代码级视图涉及到的最重要的一个概念就是代码变化(Code Churn),这是用来描述从一个版本到另一个版本时,软件进行的行添加、修改或删除文件的行为。
2.2.2 组件级视图
在这种情况下组件级视图主要包括两个重要角度:Version/Version Control System (VCS),即版本控制系统,和配置文件Software Configuration Item(SCI),用来记录存储与合同、过程、计划和产品有关的文档和资料,源代码、目标代码和可执行代码以及相关产品,包括软件工具、库内的可重用软件、外购软件及顾客提供的软件等。
3 运行时视图
3.1 时刻图
3.1.1 代码级视图
在这种情况下的代码级视图涉及到的重点:
代码快照(Code Snapshot):快照图表示程序运行时的内部状态——它的堆栈(正在进行的方法及其本地变量)和堆(当前存在的对象)。如图:
图2 代码快照
具体表示方法会在数据类型与类型校验中详细介绍。
内存转储(Memory dump):硬盘上的文件,其中包含进程内存内容的副本,当进程被某些进程中止时生成内部错误或信号的种类。
3.1.2 组件级视图
在这种情况下组件级视图大致与构建时组件视图相同,包括packages,lib等等。
3.2 时期图
3.2.1 代码级视图
在这种情况下的代码级视图主要包括:
执行跟踪(Execution trace):跟踪涉及专门使用日志记录来记录有关程序执行的信息。跟踪涉及专门使用日志记录来记录有关程序执行的信息。
3.2.2 组件级视图
在这种情况下的组件级视图主要包括:
事件日志(Event log):事件日志记录为系统管理员提供信息,可用于诊断和审核。
4 软件质量
4.1 外部因素
主要包括了:
正确性Correctness,健壮性Robustness,可扩展性Extendibility,可复用性Reusability,兼容性Compatibility,性能Efficiency,可移植性Portability,易用性Ease of use,功能性Functionality,及时性Timeliness等等
其中正确性和健壮性组合形成了可靠性reliability,可扩展性和可复用性组合成了模块化modularity。
4.2内部因素
内部质量因素影响软件本身和其开发者,如模块化,可读性。虽然内部质量并不是最终标准,最重要的事,但是他决定着外部质量。
4.3 质量权衡
正确的软件开发过程中,开发者应该将不同质量因素之间如何做出折中的设 计决策和标准明确的写下来 。
虽然需要折中,但“正确性”绝不能与其他质量因素折中
4.4 五大关键质量因素
- Easy to understand:understandability
- Ready for change: maintainability and adaptability
- Cheap for develop: design for/with reuse: reusability
- Safe from bugs: robustness
- Efficient to run: performance