跳到主要内容

软工概念

面向对象特征​

  • 封装 Encapsulation 封装：限制对某些信息的访问
  • 交互 Interaction 交互:通过过程调用或类似的协议
  • 多态 Polymorphism 多态：在运行时选择具体的操作
  • 继承 Inheritance 继承：对共享的功能保持唯一的接口

面向对象的缺点​

  • 操作太多对象
  • 操作太多交互
  • 与表现有关的职责被严重分开，使系统难以理解
  • 难以捕捉相关设计所属的族（仅仅类型经常不足以，需要设计模式介入）
  • 纯 oo 设计导致系统巨大且扁平
  • 需要额外的 structure 和 discipline

解决方法​

利用额外的结构和准则

C/S​

  • 进程即对象
  • Asymmetric 客户端知道服务器，服务器不知道客户端

优点

  • 高效利用网络系统，硬件成本可能变低
  • 易于新增和更新现存服务器
  • 允许多个用户共享数据
  • 可扩展：增加新客户

缺点

  • 每个 sever 拥有大量管理
  • 难以找到什么服务器和服务是可用的，缺少一个中心来注册服务和服务器
  • 难以改变服务器和客户的功能，改变 cs 架构的应用逻辑很困难
  • 应用扩展被服务器和网络容量限制

两层 cs：重客户，轻服务 用户系统界面层 数据库管理服务层

限制

  • 对客户端软件和硬件要求高
  • 复杂的客户端程序设计
  • 数据安全性差，客户端能直接访问服务端数据
  • 相同的信息内容和格式
  • UI 不同而且复杂
  • 系统维护和升级复杂，所有客户端都需要维护

三层 cs 客户层的逻辑拆分到逻辑层，只保留表达层

BS 是三层 cs 的特例 但是限制了服务端资源和客户端资源的应用 安全性难以保证 在数据请求和速度上 BS 慢于 cs

分层​

  • CS 模式的扩展（Elaboration）
  • 运行时层的结合 Aggregation into run-time strata
  • 通常只有少量层

优点

  • 每一层包含相关服务，内聚高
  • 每一层对其他层隐藏了信息
  • 每一层可能只会用到比它低的层，内聚高
  • 易于复用，替换和交换

缺点

  • 可能造成性能问题
  • 清晰的层关系难以构建

框架​

  • 框架是对具体问题的可复用基础设施
  • 包括为具体问题准备的必要基础组件
  • 交互策略和组件依赖相结合
  • 被开发应用的上下文和环境基于提供的框架

通常情况下，框架代表一个类库

非功能性需求​

即质量属性（Quality Attributes）

常见的有

  • Availability 可利用性
  • Modifiability 可修改性
  • Performance 性能
  • Security 安全
  • Testability 可测试性
  • Usability 可用性

表述质量需求时，要定量而不是定性

使用这样的模版

  • 刺激源（Source of Stimulus/Source）：谁触发了刺激
  • 刺激（Stimulus）: 影响系统的 situation
  • 制品（Artifact）：被影响的那部分系统
  • 环境（Environment）：当刺激发生时，系统的状态
  • 响应（Response）：刺激的结果
  • 响应衡量指标（Response Measure）：如何衡量回应

可访问性 Availability​

当用户使用系统时，系统可用的概率（系统故障所致）

（提前确定的停机维护不计入）

常见指标​

  • 可用（不可用）时间占百分比
  • 修复错误需要的时间
  • 平均错误间隔时间

刺激源：失败的 signs 刺激:

  • 系统错误
  • 系统崩溃（重复的错误，无法回避）
  • 不准时的结果（过早或过晚）
  • 返回错误的结果

总结​

可利用性的关注核心:

  • 是否错误发生
  • 故障的后果

提示可利用性的策略

  • 错误检测

    • ping
    • 心跳包
    • throw catch handle

  • 错误修复

    • 内部测试（阿尔法测，确认修复后再发补丁）
    • 在检查点回滚，频繁保存
    • 双系统保持同步，只取其中一结果
    • 使用单系统，但是将变更通知另一系统，
      • 如果其中一个挂了，确认另一个状态是最新的，使用另一个，
      • 切换回来后需要重新同步主系统
    • Vote,各种算法都能计算同一个问题,结果少数服从多数

  • 错误避免

    • ex.进程监控，最典型的是系统任务管理器
    • ex.多个行为，整合成事务 transaction，一旦其中一个失败，另一个需要被取消
    • ex.服务下线

性能 performance​

关注点:

  • 系统对事件响应的速度
  • 事件的数量与到来模式

到来模式​

  • 随机
  • 在特定时间尺度上有规律

指标​

  • 计算事件所用时间
  • 单位时间计算的事件数
  • 计算失败率和丢失率

提升策略​

在任务对资源需求层面上控制

  • 数据量不变时提升计算效率

  • 减少数据总量

    • 控制事件到来速率
    • 仅计算请求的子集

  • 限制执行时间

    • 特定时间内只获取差不多的解

  • 限制事件队列长度

    • 直接遗弃一部分事件

在资源本身管理层面上控制

  • 优化同步策略
    • 多线程
    • 多计算
    • 多核多机
  • 提升可用资源
    • 可计算资源
    • 存储资源
    • 带宽资源

在资源仲裁层面控制

  • 先来先服务
  • 固定的优先级调度
  • 动态优先级
    • 无饥饿
    • ddl 最早先进行

可修改性 modifiability​

关注点

  • 修改的成本
  • 系统哪一部分被修改
  • 修改什么时候发生
  • 谁执行修改

计量指标

  • 完成修改所需时间
  • 修改的人力成本
  • 修改的经济成本
  • 等等

提升可修改性的策略​

  1. 限制修改范围，控制被修改影响的范围尽可能小
  • 保持高内聚低耦合，引入框架和中间件，控制在单一模块
  • 思考潜在修改，评估模块之间的指责分配，确保一点修改只会影响一个模块，避免不相关的多个修改影响相同模块
  • 模块公共化
  • 隐藏信息，面向对象的 public/private
  • 维护连续接口（保证独立的改变能发生在接口两端，而不改变接口本身）
  • 限制沟通路径（使用 facade 设计模式）
  • 使用 intermediaries，共享数据，桥模式和工厂模式等
  • 命名服务，实现 location 依赖
  • 创建定制实例，使用创建相关的设计模式
  1. 延迟绑定时间，允许程序能在运行时被灵活修改
  • 配置文件（修改配置文件而不是修改代码）
  • 发布订阅模式
  • polymorphism 使用不同子类实现不同功能

可用性 usability​

关注点

  • 减少用户使用软件等困难程度

环境

  • 运行时

指标

  • 一秒内取消操作的次数

策略​

目标：使用户轻松

方向 1: 运行时策略

  • 系统预测用户任务（如输入预测，搜索建议）
  • 系统提供合适的 feedback（如加载条，任务剩余时间）
  • 系统为用户提供连续的体验（如调整某设置能在不同场景下提供解决方案）

方向 2: 设计时策略

  • 支持撤回 undo 操作（最小化意外操作的影响）
  • 隔离 ui 和系统其他部分（利用 mvc 模式，允许用户自定义 ui）

安全性 Security​

关注点： 在合法用户能使用系统时，制止对系统的攻击

指标​

  • launching 攻击的困难度
  • 从攻击中恢复的困难度

解决方案​

制止攻击

  • authentication 用户认证（密码）
  • authorization 用户鉴权
  • 维持数据可信 confidentiality （加密程序和数据）
  • 维持数据完整性 Integrity（MD5 码校验）
  • 减少暴露 exposure （禁止非必要端口，自启动服务）
  • 访问控制（白名单，黑名单）

检测攻击

  • 人与软件结合 侵入式检测系统，安全专家
  • 恢复状态
  • 对攻击者的辨认

从攻击中恢复

安全实例​

  • 基于当前时间戳的动态密码
  • 两步验证，利用现存的通信设备，不需要额外用户成本，对多个用户共享一个账号不合适
    • 有延迟
    • 移动网络会被监控
    • 恶意软件在手机上侵入
  • 安全卡
    • 预制的一次性密码，可能会被积累攻击
    • 卡的大小被限制，需要快速更新
    • 物理卡印刷的经济成本
  • 用户名，密码
    • 单用户可推测大量密码，对大量用户推测常规密码
    • 认证数据累积
    • 假 wifi 热点

可测试性 Testability​

Software testing is conducted to discover faults

关注点​

  • 使软件 bug 易于被测试
  • 验证软件产品是否符合需求
  • 用最低的花费和努力验证软件质量

刺激源​

Unit Tester

刺激​

执行单元测试

Artifact​

系统的组件

环境​

组件完成阶段

响应​

  • 理想响应是测试能被实施而且结果能被观测
    • 如果结果不能被观测，测试成本将会很高

响应衡量指标​

  • 白盒测试覆盖率

    • Statement Coverage
    • Decision Coverage / Branch Coverage
      • 一个 decision 可能包括大量 condition
    • Condition coverage
      • 包括一个 Decision 的每个 Condition
    • Path Coverage
    • Decision Condition Coverage
    • Condition Combination Coverage
    • 等

  • 在三小时内路径覆盖率达到 85%

提升可测试性​

黑盒测试

哲学：提供输入，捕获输出

  • 记录 record/重播:replay 实现自动和半自动测试
  • 分离接口和实现:不同排序算法使用相同接口
  • 提供具体测试路径

白盒测试

  • 内部控制：IDE 打端点，winDBG 工具