HIT-SC-Chapter One

目录

HIT-SC-Chapter One

1.Multi-dimensional software views

image-20220604182512811

(1)Build-time Views

  • constituents
    • planning
    • analysis
    • design
    • implementation
    • testing & integration
    • maintenance
  • Build-time:
    • idea $\rightarrow$ requirement $\rightarrow$ design $\rightarrow$ code $\rightarrow$ installable / executable package
    • Code-level view:
      • source code are logically organized by basic program blocks such as functions,classes,methods,interfaces(,and the dependencies among them)
    • Component-level view:
      • source code are physically organized by files,directories,packages,libraries(~)
    • Moment view
      • what do source code and component look like in a specific time
      • 特定时刻的软件形态
    • Period view
      • how do they evolve/change along with time
      • 软件形态随时间的变化

1.1 Build-time, moment, and code-level view

  • 词汇层面：源代码
  • 语法层面：语法程序结构--抽象语法树
  • 语义层面：语义程序结构--类图

（1）源代码

  • 半结构化：
    • 近乎自然语言风格+遵循特定的编程语法
    • 前者方便程序员；后者方便编译器。

（2）语法数据结构

  • 将半结构化的源代码表示为结构化的树
    • AST

image-20220605214657441

  • 利用AST处理java源文件
    • 将源代码变成一棵树，彻底结构化；对树的各种操作--即对源代码的修改

（3）语义程序结构

  • 源代码具体想实现什么目标
  • 通常是图形化或者形式化的
  • 在设计阶段建模，并转换为源代码
  • 它是根据用户需求进行面向对象分析与设计的结果：用于表达“需求”和“设计”思想，再转化为code

例如，用uml图来描述各种源代码结构及其相互关系

image-20220605215110765

1.2Build-time, period, and code-level view

  • code churn: Lines added, modified or deleted to a file from one version to another.

image-20220605215639212

1.3 Build-time, moment, and component-level view

  • source code 被物理地组织为 file，而 file又被组织为 directories；
  • Files 被封装为 packages, 逻辑上视作组件和子系统；
  • Reusable modules 采用 库（libraries）的形式

image-20220605220130946

  • 库（library）
    • stored in disk files
    • can be reused across a variety of programs
    • 开发者只需像使用编程语言指令一样使用库中的功能
    • 库的来源：
      • 操作系统的库
      • 编程语言的
      • 第三方公司的
      • 自己编写的
  • Linking with a library:
    • 静态链接:
      • 库直接再build阶段被拷贝进入代码形成整体，执行时无需提供库文件
      • 发生在构造阶段
    • 动态链接：
      • 动态链接方法不会将目标文件复制到可执行映像中;相反，它指出成功执行程序需要哪些库。(库文件不会在build阶段被加入可执行软件，仅仅做出标记)
      • 当程序开始运行时，库作为单独的实体加载到内存中，然后与主程序连接。(程序运行时，根据标记装载库至内存)
      • 动态库是通过连接对象文件来构造的磁盘文件。然后，该库被收集到发布包中，并安装在目标计算机上。只有这样，它才能加载到机器的内存中。(发布软件时，记得将程序所依赖的所有动态库都复制给用户)
      • image-20220606085150004

1.4 Build-time, period, and component-level view

  • 各项软件实体随时间的变化
  • SCI：软件配置项
  • Version：版本

image-20220605224859044

  • Version Control System (VSC)
  • Evolution Graph(进化图) of a SCI or a Software
    • Evaluation graph describes the development process and phases of a software.
  • Software versioning
    • 为软件分配版本号

image-20220605225238150

（2） Runtime Views

​ 程序运行时是什么样子？需要加载的磁盘文件是什么？

  • Code-level:可执行程序的内存状态；程序单元间的相互作用
  • Component-level:架构----软件包如何部署到物理环境(操作系统，网络，硬件等)及如何交互
  • Moment view:逻辑/物理实体在内存/硬件环境中特定时刻的形态如何？
  • Period view: 逻辑/物理实体在内存/硬件环境中的形态随时间如何变化？
  • 高级概念
    • 可执行程序：
    • 库：
    • 配置信息和数据文件
      • 这些不是可执行文件;它们提供程序可以从磁盘加载的有用数据和配置信息。
    • 分布式系统
      • 这种类型的软件由多个可执行程序组成，这些程序通过网络相互通信，或者简单地称为运行在同一台机器上的多个进程。
      • 这与拥有单一单一程序映像的传统软件形成了对比。
  • 可执行程序：
    • 原生机器码
      • 完全将可执行程序转换为CPU的原生机器码。
      • CPU只是简单地“跳转”到程序的开始位置，所有的执行都纯粹使用CPU的硬件来执行。
      • 当它执行时，程序有选择地调用操作系统来访问文件和其他系统资源。
      • 这是执行代码最快的方式，因为程序可以完全访问CPU的特性。
      • image-20220605231324233
    • 程序完全解释执行：
      • 运行时系统将整个源代码加载到内存中并对其进行解释(如BASIC、UNIX shell等)。
      • image-20220605231826330
    • 解释型字节码：
      • 字节码类似于原生机器码，只是CPU不能直接理解它们。
      • 首先将它们翻译成本机代码或在程序执行时解释它们。
      • 字节码环境需要在程序旁边加载一个附加的解释器或编译器。（例如Java Virtual Machine–JVM）
      • 例如：Perl or Python—它们被解释而不是编译，但在运行时使用字节码。执行Perl或Python脚本的简单操作会自动触发字节码的生成。
      • image-20220606084809719
  • 配置信息和数据文件
    • 任何较大的程序都使用外部数据源，例如磁盘上的文件。
    • 程序对操作系统进行调用，请求将数据读入内存。
    • 例如：
      • 显示在屏幕上的位图图形图像
      • 以数字化波形形式存储的声音
  • 分布式系统
    • 例如，软件系统可能使用客户机/服务器模型，在一台计算机上运行单个服务器程序，而在许多其他计算机上运行大量客户机程序。
    • 运行态：需要多个运行程序，分别部署于多个计算机物理环境。

2.1 Run-time, moment, and code-level view

  • 代码快照图：描述程序运行时内存里变量层面的状态（关注目标计算机内存中的可变级执行状态）
  • image-20220606085650777
  • 内存信息转储存（Memory Dump）
    • 硬盘上的一种文件，包含进程内存内容的副本，当进程因某种内部错误或信号而中止时产生。
    • 调试器(Debugger)可以加载转储文件并显示其中包含的关于运行程序状态的信息。
    • 包括寄存器、调用堆栈和所有其他程序数据(计数器、变量、开关、标志等)的内容。
    • 使用它是为了分析程序的状态，程序员查看内存缓冲区，以查看在发生故障时正在处理哪些数据项。

2.2 Run-time, period and code-level view

  • UML的序列图：程序单元(对象)之间的交互
    • image-20220606090133206
  • 执行跟踪（Execution tracing）
    • 跟踪涉及到专门使用日志记录程序执行的信息
    • 这通常由程序员用于调试目的，并根据跟踪日志中包含的信息的类型和细节，由经验丰富的管理员或技术支持人员，以及由软件监控工具用于诊断软件常见问题。

2.3 Run-time, moment, and component-level view

  • development diagram in UML(部署图)
  • image-20220606090413177

2.4 Run-time, period, and component-level view

  • 事件日志：系统层面
    • 将被记录的事件的不同类别，以及将出现在事件消息中的详细信息，都将在开发周期中考虑。
  • 每一类事件被分配一个唯一的“代码”来格式化和输出人类可读的消息。
    • 这有助于本地化，并允许系统管理员更容易地获取有关发生的问题的信息。
  • 执行跟踪和事件日志记录
    • image-20220606090841103

What we are focused on in this semester！

image-20220606090939227

2 Software construction: Transformation between views

image-20220606091113066

  • 软件构造中转换的类型
    • $\empty \rightarrow Code$
    • Programming / Coding (ADT/OOP)
    • Review, static analysis/checking
    • $Code \rightarrow Component$
      • Design (ADT/OOP; Reusability; Maintainability)
      • Build: compile, static link, package, install, etc
    • $Build-time \rightarrow Run-time$
      • Install / deploy
      • Debug, unit/integration testing (Robustness and Correctness)
    • $Moment \rightarrow Period$
      • Version control
      • Loading, dynamic linking, execution (dumping, profiling, logging)(加载、动态链接、执行(转储、分析、日志记录))
      • Concurrent threads(并发线程)

3 Quality properties(属性) of software systems

  • 外部质量因素
    • 外部质量因素 影响 用户
    • 诸如速度或易用性这样的品质，在软件产品中是否存在，用户可能会发现。
  • 内部质量因素
    • 内部质量因素 影响 软件本身和它的开发者
    • 适用于软件产品的其他品质，如模块化或可读性，都是内部因素，只有访问实际软件文本的开发人员才能察觉。
  • 最终，只有外部因素起作用。
  • 外部质量取决于内部质量
    • 为了让用户享受可见的品质，设计师和实施者必须应用内部技术来确保隐藏的品质。

(1)External quality factors

  • 正确性

    • 测试和调试
      • 确保正确性的方法
      • 测试发现不正确，调试消除不正确
      • 鲁棒性(第六章)
    • 防御性编程
      • 在写程序时就确保正确性
      • 如输入和断言，旨在帮助构建从一开始就是正确的软件——而不是调试到正确。
      • 鲁棒性(第六章)
    • 形式化方法
      • check\guarantee\ensure
      • 正式程序说明和验证的数学技术
      • 形式化语言，研究生课程

  • 鲁棒性（健壮性）

    • 指软件系统对异常情况作出适当反应的能力
      • 补充正确性（正确性是指软件的行为要严格地符合规约中定义的行为）
      • 健壮性描述了在该规约之外发生的事情。
    • 出现异常时不要“崩溃”
    • 正常和异常情况的概念总是相对于一定的规格
      • “normal”和“abnormal”是主观而不是客观
      • 未被spec覆盖的情况则视为“异常情况”
      • 异常情况取决于spec的范畴
      • 在这个意义上，“正常”并不意味着“令人满意”，而仅仅是“在软件设计中计划的”。
      • 把错误的输入称为正常情况，乍一看似乎是矛盾的，但其他任何方法都必须依赖主观标准，因此是无用的。
      • 异常处理(第六章)
    • image-20220606093523814

  • 可扩展性

    • 即修改该软件的规约是否足够容易
    • 可扩展性的问题是规模问题
      • 规模越大，扩展越来越不容易
      • 一个大型软件系统常常把它的维护者看作是一个巨大的纸牌房子，其中任何一个元素的拔出都可能导致整个建筑的倒塌。
    • 为什么要扩展：应对变化
      • 传统方法没有充分考虑变更，而是依赖于软件生命周期的理想视图，其中初始分析阶段冻结需求，过程的其余部分致力于设计和构建解决方案。
    • 两个原则对于提高可扩展性至关重要:
      • 设计的简单性:（简约主义设计）
        • 简单的体系结构总是比复杂的体系结构更容易适应变化。
      • 去中心化:（分离主义设计）
        • 模块越自治，一个简单的更改只影响一个模块或少数模块的可能性就越高，而不是触发整个系统中变化的连锁反应。
    • 第3章(ADT和OOP)
    • 第4/5章(模块化和适应性

  • 可重用性

    • 一次开发，多次使用
    • 需要发现共性：一个可重用的软件元素将适用于许多不同的开发。
      • 不要重复你自己(DRY)
      • 不要重新发明轮子（造轮子）
    • 第四章(重复使用设计)

  • 兼容性

    • 不同软件系统之间相互可容易的集成
    • 许多操作系统支持的各种不兼容的文件格式就是一个例子。只有在文件格式兼容的情况下，程序才能直接使用其他程序的结果作为输入。（文件格式的兼容性）
    • 关键在于设计的同构性、系统间的标准化
    • 方法：
      • 标准化的文件格式，如在Unix系统中，每个文本文件只是一个字符序列。
      • 标准化的数据结构，如在Lisp系统中，所有的数据和程序都用二叉树(在Lisp中称为列表)表示。
      • 标准化的用户界面，如不同版本的Windows、OS/2和MacOS，其中所有工具都依赖于单一的范式与用户通信，基于标准组件，如窗口、图标等。

  • 性能

    • 软件系统对硬件资源的需求尽可能少的能力，如处理器时间、内部和外部存储器占用的空间、通信设备使用的带宽。
    • 性能毫无意义，除非有足够的正确性
      • 对性能的关注必须与其他目标(如可扩展性和可重用性)进行平衡;
      • 极端的优化会使软件过于专业化，以至于不适合更改和重用。
    • 算法、I/O、内存管理等。
    • 计算正确性的抽象概念和通过优化具体实现性能
    • 过早优化是万恶之源

  • 可移植性

    • 软件产品轻松地转移到各种硬件和软件环境。
    • 硬件、操作系统

  • 易用性

    • 容易学、安装、操作和监控
    • 给用户提供详细的指南
      • 一个设计良好的系统，根据一个清晰、深思熟虑的结构构建起来的系统，往往比一个混乱的系统更容易学习和使用。
      • 优秀的设计师必须努力理解系统的预期用户群体。

  • 功能性

    • 系统提供的可能性的范围
    • 特征主义(通常称为“爬行特征主义”)
      • 由于添加了新特性，可能会导致一致性的丧失，从而影响其易用性。用户们确实都知道抱怨产品的新版本的所有“花哨的东西”让它变得可怕的复杂。
      • 更困难的问题是避免过于关注特性而忘记其他品质(忽略整体品质)。

  • Functionality

    • 您不会在可靠性、可扩展性等方面做出妥协:在您对现有特性感到满意之前，您拒绝继续开发新特性。

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

    • 第二章(敏捷，SCM)

  • 及时性

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

  • 其他品质

    • Verifiability (可验证性)
      • 易于准备验收程序，特别是测试数据，以及在验证和操作阶段检测失败和追踪错误的程序。
    • Integrity (完整性)
      • 软件系统保护其各种组件(程序、数据)不受未经授权的访问和修改的能力。
    • Repairability (可修复性)
      • 便于缺陷修复的能力。
    • Economy (经济性)
      • 与时效性相伴的是系统在指定预算或预算以下完成的能力。

(2)Internal quality factors

  • 与源代码相关
    • LOC（Lines of Code）
    • Cyclomatic Complexity(圈复杂度)
    • etc
  • 体系结构
    • 耦合度
    • 内聚度
    • etc
  • 可读性
  • 可理解性
  • Clearness
  • Size
  • 内部质量因素通常被用作外部质量因素的部分测量
  • 复杂性几乎是任何外部质量因素的敌人!

(3) Tradeoff (折中)between quality properties

  • 如果不引入各种各样的保护措施，如何获得完整性，因为这些措施不可避免地会妨碍使用的方便。
    • 经济性似乎经常与功能性相冲突。
    • 完整性vs易用性
    • 经济vs功能
    • 性能vs可移植性
    • 性能vs可重用
    • 经济vs可重用
    • 时效性vs可扩展性
  • 开发人员需要做出折中
    • 通常情况下，开发人员会隐式地做出这些权衡，而没有花时间检查所涉及的问题和各种可用的选择;在这种沉默的决定中，性能往往是主导因素。
    • 正确的软件开发过程中，开发者应该将不同质量因素之间如何做出折中的设计决策和标准明确的写下来
  • 尽管在质量因素之间进行折中可能是必要的，但有一个因素是最突出的:正确性。
    • 虽然需要折中，但“正确性”绝不能与其他质量因素折中
  • 通常，最重要的质量因素：
    • 正确性和健壮性:可靠性
      • 软件构建的系统化方法
      • 形式化规范
      • 开发过程中的自动检查
      • 更好的语言机制
      • 一致性检查工具
    • 可扩展性和可重用性:模块化
  • OOP提高质量
    • image-20220606125830226

4 Five key quality objectives of software construction

  • Quality considerations

    • 优雅漂亮的代码
    • 设计/与重用
    • Low complexity
    • Robustness and correctness
    • 性能和效率

  • Reusability/Maintainability(可维护性)/Robustness/Correctness

  • ADT and OOP

  • Understandability

    • image-20220606131512425

  • Reusability

    • image-20220606131555311

  • Robustness

    • image-20220606131623270

  • Performance

    • image-20220606131642536

Summary

  • Three dimensions of describing a software system:

    • By phases: build- and run-time views
    • By dynamics: moment and period views
    • By levels: code and component views

  • Elements, relations, and models of each view

  • Software construction: transformation between views

  • Quality properties of software systems

    • External vs. internal quality factors
    • Important external quality factors
    • Tradeoff between quality factors

  • Five key quality objectives of software construction

    • Easy to understand: elegant and beautiful code / understandability
    • Ready for change: maintainability and adaptability
    • Cheap for develop: design for/with reuse: reusability
    • Safe from bugs: robustness
    • Efficient to run: performance

  • Construction techniques to be studied in this course (classified by the orientation of five key quality objectives)（按定位分类了五个关键质量目标）

posted @   三金同志  阅读(33)  评论(0)  编辑  收藏  举报
相关博文：
· HIT-SC-Chapter Three
· HIT-SC-Chapter Two
· HITSC_1_Views and Quality Objectives of Software Construction
· 软件构造的多维度视图和质量目标
· 软件构造第一章复习
阅读排行：
· 全程不用写代码，我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· 记一次.NET内存居高不下排查解决与启示
· MongoDB 8.0这个新功能碉堡了，比商业数据库还牛
· .NET10 - 预览版1新功能体验（一）
点击右上角即可分享
微信分享提示
AI FOR CODE 大赛