HIT 软件构造第一章总结

m0_73489481

于 2024-06-14 20:26:56 发布

阅读量805

点赞数 26

分类专栏： hit软件构造博客文章标签：课程设计 java

本文链接：https://blog.csdn.net/m0_73489481/article/details/139688766

版权

hit软件构造博客专栏收录该内容

5 篇文章 0 订阅

订阅专栏

一、软件多维度视图

1.1 Constituents of a software system: one more step

Constituents of a software system: one more step

1.2 Constituents of a software system: tow more step

Constituents of a software system: tow more step
软件开发周期：规划->分析->设计->实施->测试和集成->维护->规划

1.3 Multi-dimensional software views

Multi-dimensional software views

1.3.1 从三个维度看软件系统的构成

按阶段划分：build-time（构造阶段）和run-time（运行阶段）
按动态划分：moment（时刻）和period（时期）
按层次划分：code（代码层面）和component（组件，文件层面）

1.3.2 软件构造的阶段划分、各阶段的构造活动

build-time(构造阶段)
构造阶段，有如下视角：

Code-level view：
代码的逻辑组织（函数、类、方法、接口等）。
这个阶段主要关注词汇、词法、语义三个层面，也就是源代码。上有AST作为分析的工具。

Component-level view：
代码的物理组织（文件、目录、包、程序库等）。
这个阶段关注Code churn，即代码随时间的变化，某一行的添加、修改或删除，版本变化。

Moment view：
特定时刻的软件形态源代码如何组织成文件——通过类库。
文件被压缩进package，逻辑上进入components（组件）and sub-systems（子系统）链接技术（动态 / 静态） Library：操作系统提供的库；编程语言提供的库；第三方公司提供的库；自己编写的库链接：编程时和build时，需告诉IDE和JVM在哪里寻找某些库。静态链接库被拷贝进入代码形成整体，执行的时候无需提供库文件。静态链接发生在构造阶段。

Period view：
软件形态随时间的变化。
关注SCI 配置项的更改 VCS 版本控制系统各项软件实体随时间如何变化软件随时间变化的版本版本控制（通过Git，SVN等等）
run-time (运行阶段)
程序被载入目标机器，开始执行。

Code-level view：
逻辑实体在内存中的呈现方式。
Code SnapShot（代码快照）描述程序运行时内存里变量层面的状态，即某一时间点内存中对象及对象的值。
Memory dump（内存信息转储）常发生在异常退出时，把内存中信息写到文件中（常用来调试）。
view UML运行时图，描述程序运行时间各个种类间的依赖关系。 Execution tracing（执行跟踪）用日志方式记录程序执行的调用次序。

Component-level view：
物理实体在物理硬件环境中的呈现方式。
UML部署图
执行跟踪：根据跟踪日志里的信息进行调试或诊断软件问题。
事件日志（系统层面）

Moment view：
在内存/硬件环境中特定时刻的形态。

Period view：
硬件环境中的形态随时间的变化。

动态链接
库文件不会在build阶段被加入可执行软件，仅仅做出标记。程序运行时，根据标记装载库至内存。发布软件时，记得将程序所依赖的所有动态库都复制给用户。分布式程序需要多个运行程序，分别部署于多个计算机物理环境。需要多端口或者多线程。

1.4 视图之间的转换

在这里插入图片描述

二、软件系统的质量特性

2.1 外部和内部的质量因素

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

2.1.1 External quality factors（外部质量因素）

Correctness（正确性）

按照预先定义的“规约”执行正确性是至高无上的质量指标每一层保证自己的正确性，同时假设其下层是正确的测试和调试：发现不正确、消除不正确防御式编程：在写程序的时候就确保正确性形式化方法：通过形式化验证发现问题
Robustness（健壮性）

针对异常情况的处理 – 健壮性是对正确性的补充 – 正确性：软件的行为要严格的符合规约中定义的行为 – 出现规约定义之外的情形的时候，软件要做出恰当的反应出现异常时不要“崩溃” 健壮性是主观而非客观 – 未被specification覆盖的情况即为“异常情况” – 所谓的“异常”，取决于spec的范畴
Extendibility（可扩展性）
定义：对软件的规约进行修改，是否足够容易的程度。规模越大，扩展起来越不容易。目的是为了变化。两个准则（为了可扩展性）：简约主义设计，分离主义设计
Reusability（可复用性）
一次开发，多次使用找到不同问题之间的共性
Compatibility（兼容性）
不同的软件系统之间相互可容易的集成兼容性很重要因为开发设计不在真空中，所以需要相互联系方法：保持设计的同构性并标准化
Efficiency（性能）
性能包括很多内容，最常见的就是时间复杂度和空间复杂度。性能毫无意义，除非有足够的正确性。 – 对性能的关注要与其他质量属性进行折中 – 过度的优化导致软件不再适应变化和复用过早优化是万恶之源
Portability（可移植性）
软件可方便的在不同的技术环境之间移植硬件、操作系统中的移植
Ease of use（易用性）
容易学、安装、操作、监控给用户提供详细的指南
Functionality（功能性）
每增加一小点功能，都确保其他质量属性不受到损失。程序设计中一种不适宜的趋势，即软件开发者增加越来越多的功能，企图跟上竞争，其结果是程序极为复杂、不灵活、占用过多的磁盘空间。
Timeliness（及时性）
当用户需要的时候，要能及时地设计出来。
Other qualities：
Verifiability（可验证性） Integrity（完整性） Repair ability（可修复性） Economy（经济性）