HIT软件构造学习笔记-1 Views and Quality Objectives of Software Construction

文章目录

• 系列文章目录
• 前言
• 一、pandas是什么/li>
• 二、使用步骤
  • 1.引入库
  • 2.读入数据
• 总结

一、多维软件视图

	时刻		周期
	代码层面	构建层面	代码层面	构建层面
构建阶段	源代码，AST，接口类属性方法	包，文件，静态链接，库，测试用例，构建脚本（组件图）	代码变化	配置项，版本
运行阶段	代码快照图，内存转储；堆栈轨迹，并发进程	包，库，动态链接，配置，数据库，中间设备，网络，硬件（部署关系图）	执行堆栈追踪，并发多线程	时间日志，多进程，分布式处理
			程序过程调用图，信息图（顺序图） 逻辑/物理实体在内存/硬件环境中的形态随时间的变化

源码组织在文件中，进而组织在目录中

文件存档在包中，并逻辑上归属于组件和子系统

可重用的模块以库的形式存在，库存储在磁盘文件中

静态链接：库被拷贝进代码形成整体，执行的时候无需提供库文件

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

分布式程序：需要多个运行程序，分别部署于多个计算机物理环境

代码快照：描述程序运行时内存里变量层面的状态

内存转储（Memory dump）：一个包含进程内存拷贝的磁盘文件，包含程序异常退出时的寄存器、调用栈、程序数据等，调试器可以加载转储文件并显示信息

执行跟踪（Execution tracing）：软件层面，用日志方式记录程序执行的调用次序

事件日志：系统层面的日志

1.构建阶段

构建阶段：观点—>需求—>设计—>代码—>可安装/可执行包

代码角度：源代码——源代码的逻辑组织方式通过基本程序块，如函数、类、方法、接口等等，以及它们之间的依赖关系（代码的逻辑组织）
成分角度：架构——源代码在物理上是如何的按文件、目录、包、库和依赖项组织 (代码的物理组织）

时刻角度：特定时刻的软件形态
阶段角度：软件形态随时间的变化

（1）构建阶段，时刻性，代码层面
源代码是如何通过基本程序块逻辑组织的，如函数、类、方法、接口等，以及它们之间的依赖关系。

三个相互关联的形式：
词汇层面：词汇导向源代码
语法层面：面向语法程序结构，例如：抽象语法树（AST）
语义层面：面向语义程序结构，例如：类图

面向语义程序结构
例如，使用类图(UML)来描述接口、类、属性、方法以及它们之间的关系
通常是图形化或形式化的。
在设计阶段建模，并转换为源代码
它是基于用户需求的面向对象分析和设计的结果

（2）构建阶段，周期性，代码层面
描述随时间变化的视图
代码变化：从一个版本到另一个版本的文件中添加、修改或删除的行。

（3）构建阶段，时刻性，构件层面
源代码被物理地组织成文件，这些文件进一步被目录组织。
文件被封装到包中，逻辑上，被封装到组件和子系统中。
可重用模块以库的形式存在。
 

库
库存储在自己的磁盘文件中，收集一组可以跨各种程序重用的代码函数。
——开发人员并不总是构建单个可执行程序文件，而是将定制开发的软件和预构建的库连接到单个程序中。

在构建时，可以将库函数视为标准语言的扩展，并以与开发人员编写的函数相同的方式使用。（开发者像使用编程语言指令一样使用库中的功能）
 

库的来源
操作系统提供的库，编程语言提供的库，第三方公司提供的库，自己积累的库

与库链接
编程时和build时，需告诉IDE和JVM在哪里寻找某些库。
如果在源代码中引用了某个函数，但是开发人员没有显式地编写它，那么将搜索库列表来定位所需的函数。

找到函数后，将相应的目标文件复制到可执行程序中。
将一个库集成到一个可执行程序的两种不同的方法:
静态链接（库被拷贝进入代码形成整体，执行的时候无需提供库文件，静态链接发生在构建阶段），动态链接

与库链接

在静态链接中，库是单个对象文件的集合。

在构建过程中，当链接器工具确定需要某个函数时，它会从库中提取适当的对象文件，并将其复制到可执行程序中

库的对象文件与开发人员自己创建的任何对象文件都相同

静态链接发生在构建阶段

（4）构建阶段，周期性，构件层面
即各项软件实体随时间如何变化。
配置项(SCI)，版本

2.运行阶段

软件系统的运行时视图

运行时：程序被载入目标机器，开始执行
代码层面：逻辑实体在内存中如何呈现br> 构件层面：物理实体在物理硬件环境中如何呈现/p>

时刻性：逻辑/物理实体在内存/硬件环境中特定时刻的形态如何br> 阶段性：逻辑/物理实体在内存/硬件环境中的形态随时间如何变化/p>

运行时软件的高级概念
可执行程序：

CPU执行的机器可读指令序列，以及相关的数据值。
——这是一个完全编译好的程序，可以加载到计算机的内存中并执行。

库：

可以被不同程序重用的常用目标代码的集合。
——大多数操作系统都包含一组标准的库，开发人员可以重用这些库，而不是要求每个程序都提供自己的库。
——不能直接在目标机器上加载和执行库;它必须首先与一个可执行程序相连接。

配置和数据文件：

这些不是可执行文件;它们提供了程序可以从磁盘加载的有用数据和配置信息

分布式程序：

这种类型的软件由多个可执行程序组成，这些可执行程序通过网络彼此通信，或者只是作为运行在同一台机器上的多个进程进行通信。
——这与更传统的软件形成了鲜明的对比，后者只有一个单一的单片程序映像

可执行程序:本机机器代码
一个程序首先加载到内存中，并且有几个机制用于执行软件具体取决于在加载程序之前进行编译，以及如何许多操作系统支持程序所需的。

可执行程序:程序完全解释执行

运行时系统将整个源代码加载到内存中，并解释

可执行程序:解释的字节码

–—字节码与本机代码类似，只是CPU不能直接理解

它首先将它们转换为本机代码或将其解释为程序执行

因此，字节码环境要求在程序旁边加载额外的解释器或编译器

Perl or Python:它们被解释而不是编译，但在运行时使用字节码。

执行Perl或Python脚本的简单动作会自动触发字节码的生成。

 动态链接

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

优点：

可以升级到库的更新版本（添加功能或修复bug），而无需重新创建可执行程序

许多操作系统可以通过只将库的一个副本加载到内存中，然后与需要该库的其他程序共享来优化其内存使用情况

配置和数据文件

任何较大的程序都使用外部数据源，例如磁盘上的文件

程序调用操作系统以请求将数据读入内存

分布式程序

分布式程序的运行态：需要多个运行程序，分别部署于多个计算机物理环境。

（5）运行阶段，时刻性，代码层面
快照图:关注目标计算机内存中的可变级别执行状态，描述程序运行时内存里变量层面的状态。

程序的细粒度状态。

内存信息转储(Memory dump )
内存转储:硬盘上的文件，包含进程内存内容的副本，当进程因某些内部错误或信号而中止时产生

（6）运行阶段，时刻性，构件层面
执行跟踪(Execution tracing )：用日志方式记录程序执行的调用次序。
——这通常由程序员用于调试目的，根据跟踪日志中包含的信息的类型和细节，由有经验的管理员或技术支持人员使用，并由软件监视工具诊断软件的常见问题。

（7）运行阶段，周期性，构件层面

（8）运行阶段，周期性，构件层面
事件日志：系统层面
为每一类事件分配一个唯一的“代码”来格式化和输出人类可读的消息。

二、软件建设：视图之间的转换

软件构造中的转换类型
从0到代码
——编程/编码
——审查,静态分析/检查

从代码到构件
——设计
——构建:编译、静态链接、打包、安装等

从构件到运行
——安装/部署
——调试、单元/集成测试

从时刻到周期
——版本控制
——加载、动态链接、执行(转储、分析、日志记录)
——并发线程

 三、软件系统的质量特性

1.外部和内部质量因素

外部质量因素：可被用户感知的因素，如软件速度、易用性；影响用户

诸如速度或易用性等品质，其在软件产品中的存在或不存在可由其用户检测到

内部质量因素：作为软件产品的质量，如代码可读性；影响软件本身和它的开发者

适用于软件产品的其他品质，如模块化或可读性，是内部因素，只有能够访问实际软件文本的开发人员才能感知到

外部质量取决于内部质量。

但实现这些外部因素的关键在于内部因素：为了让用户享受可见的质量，设计者和实施者必须应用内部技术来确保隐藏的质量

（1）外部质量因素

正确性

正确性是软件产品执行它们的准确任务的能力，这是由它们的规范定义的。
正确性是最重要的质量指标。

假设软件系统是分层开发的。
每一层都保证它的正确性，前提是它的下层也是正确的。

测试和调试：发现不正确、消除不正确
防御式编程：在写程序的时候就确保正确性如：键入和断言
形式化方法：通过形式化验证发现问题

鲁棒性（健壮性）
健壮性：针对异常情况的处理
健壮性是对正确性的补充

正确性：软件的行为要严格的符合规约中定义的行为
健壮性：出现规约定义之外情形的时候，软件要做出恰当的反应，出现异常时不要“崩溃”

鲁棒性是关于“异常情况”,这意味着正常和异常情况下的概念总是相对于某一规范“正常”和“不正常”。
——未被specification覆盖的情况即为“异常情况”            specification：规范
——所谓的“异常”，取决于spec的范畴

可扩展性

可扩展性是减轻软件产品适应变化的规范。
规模越大，扩展起来越不容易。
扩展的目的：应对变化

传统的方法没有充分考虑到变化，而是依赖于软件生命周期的理想视图，在该视图中，初始分析阶段冻结了需求，过程的其余部分用于设计和构建解决方案

提高可扩展性有两个基本原则：
简约主义设计
分离主义设计:模块的自主性越强，简单的更改只影响一个模块或少量模块的可能性就越高，而不是触发整个系统的连锁反应

可复用性

为许多不同应用程序的构造服务的软件元素， 一次开发，多次使用。

对可重用性的需求来自于这样的观察:软件系统经常遵循类似的模式;应该有可能利用这一共性，避免对以前遇到的问题重新发明解决方案。（发现共性）
可重用的软件元素将适用于许多不同的开发。

兼容性

兼容性指不同的软件系统之间相互可容易的集成。
兼容性很重要,因为我们不开发软件元素在真空：他们需要相互作用。

难点：不同软件有不同的设定/规定

兼容性的关键在于设计的同质性和就项目间通信的标准化约定达成一致

通过定义软件操作的所有重要实体的标准化访问协议，可以获得更通用的解决方案

性能

性能毫无意义，除非有足够的正确性。

对性能的关注要与其他质量属性进行折中。
过度的优化导致软件不再适应变化和复用

过早优化是万恶之源

可移植性

可移植性指软件可方便的在不同的技术环境之间移植。

可移植性不仅解决了物理硬件的变化，而且更普遍地解决了硬件-软件机器的变化，即我们真正编程的机器，它包括操作系统、Windows系统(如果适用的话)和其他基本工具。

易用性

易用性指容易学、安装、操作、监控，不同背景和资格的人可以轻松地学习使用软件产品并将其应用于解决问题。

给用户提供详细的指南。

结构简洁，知道用户的需求。

一个设计良好的系统，根据一个清晰的、经过深思熟虑的结构构建，将比一个凌乱的系统更容易学习和使用

功能性

功能性是系统提供的可能性的范围。
 Featurism（often “creeping featurism”）程序设计中一种不适宜的趋势，即软件开发者增加越来越多的功能，企图跟上竞争，其结果是程序极为复杂、不灵活、占用过多的磁盘空间。

损失的一致性；忽视整体质量，失去可持续性

从一小部分关键功能开始考虑到所有质量因素

每增加一小点功能，都确保其他质量属性不受到损失。

及时性

及时性软件系统的能力是在用户需要时释放或之前。
一个伟大的软件产品如果出现得太晚，可能会完全错过它的目标

可验证性
可验证性是易于准备验收程序,特别是测试数据,和检测故障和跟踪程序错误在验证和操作阶段。

完整性
完整性是软件系统的能力来保护他们的各种组件(程序、数据)对未经授权的访问和修改。(避免出现不一致)

可修复性
可修复性是促进缺陷的修复的能力。

经济性

从一小部分关键功能开始

考虑到所有质量因素

经济性是及时性的伴侣,是一个系统的能力或低于其完成分配的预算。

(2)内部质量因素

源代码相关的因素，例如行代码Line of Codes(LOC)、圈复杂度等；
与体系结构相关的因素，例如耦合、内聚等；
可读性；
易懂性；
清晰度；
代码体量

(3)质量属性之间的权衡

质量属性之间的权衡

经济似乎经常与功能发生冲突。

最佳效率需要完美地适应特定的硬件和软件环境，这与可移植性相反，需要完美地适应规范，在规范中，可重用性推动解决比最初给出的问题更一般的问题。

及时性压力可能会诱使我们使用“快速应用程序开发”技术，其结果可能不会有太多的可扩展性

正确的软件开发过程中，开发者应该将不同质量因素之间如何做出折中的设计决策和标准明确的写下来。

虽然在质量因素之间进行权衡是必要的，但有一个因素比其他因素突出:正确性

软件构造的关键关注点

正确性和健壮性:可靠性

软件控制的系统方法

形式化规范

开发过程中的自动检查

更好的语言机制

一致性检查工具
可扩展性和可重用性:模块化

OOP如何提高质量

正确性:封装、分散
健壮性:封装、错误处理
可扩展性:封装，信息隐藏
可重用性:模块化、组件、模型、模式
兼容性:标准化模块和接口
可移植性:信息隐藏、抽象
易用性:GUI组件、框架
效率:可重用的组件
及时性:建模、重用
经济性:重复利用
功能性:可扩展性

四、软件建设的五大质量目标

本课程的质量考量

优雅优美的代码——>容易理解，易懂
设计/重用——>廉价的开发
低复杂度——>易于更改，易于扩展
鲁棒性和正确性——>安全无bug，不容易出错
性能和效率——>运行高效

总结：5个核心质量因素

 

 

 

文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览209242 人正在系统学习中

来源：NatsuyaZ