UESTC系统架构课程期末复习

这里是系统架构课程期末复习嗷！

1. 系统分析与设计概述

1.1 信息系统概述

• 信息系统是啥？
  • 信息系统是一种能够完成对业务数据进行采集、转换、加工、计算、分析、传 输、维护等信息处理。
  • 并能就某个方面问题给用户提供信息服务的计算机应用系统。
• 组成？
  • 基础设施（Server , CN , System Software）
  • 应用软件
  • 数据库系统
  • 业务数据
  • Client
• 类型：
  1. 业务处理系统（TPS），对于 业务活动 进行信息处理，实现业务自动化。
  2. 管理信息系统（MIS），以 管理信息 为主导，对于机构整体信息化管理。
  3. 决策支持系统（DSS），分析数据，模型评估和知识推理，提供 决策支持 的信息系统。
  4. 专家系统（ES），获取，存储与利用 专家指挥解决某类问题的信息系统。
  5. 办公自动化系统（OA），实现 办公业务流程 信息化，自动化处理。
  6. 知识工作支持系统（KWS），强大的数据，图形和图像以及多媒体处理能力。为知识工作和提供设计创造，技术创新等服务工具的信息系统
• 利益相关者：
  • 客户
  • 用户
  • 开发团队
• 用户：
  • 内部用户
    • 业务人员
    • 主管，经理等
  • 外部用户：
    • 客户
    • 供应商
    • 合作伙伴

项目人员构成和职务：

• 开发人员：

1. 系统分析人员：分析业务用户需求，明确信息系统目标，定义信息系统需求规格（产品经理）。
2. 系统设计人员：将信息系统需求转化为系统设计方案。
3. 系统构造人员：根据系统设计方案开发实现信息系统。
4. 系统测试人员：对信息系统的应用软件进行测试，尽力消除软件中的缺陷。
5. 质量保证人员：监督系统构造人员按照工程标准和质量规范开发信息系统。

• 管理人员：

1. 项目经理：负责项目进度计划、人员安排、经费预算等项目管理工作。
2. 客户经理：负责与客户联系、交流与沟通。

• 不同职务：
  1. 项目经理：
     • 项目计划：范围，质量，成本
     • 项目领导：培训，领导合作
     • 项目组织：人员安排，资源安排
     • 项目控制：控制进度
  2. 系统分析师：
     • 需求调研，需求分析，需求管理
     • 进行业务需求建模，系统需求建模
     • 建模转化为《系统需求规格说明书》
     • 协助架构设计师进行系统架构设计，并指导其完成《系统架构说明书》
     • 协助数据库工程师进行数据库逻辑设计和物理设计，并指导其完成《数据库设计说明书》。
     • 协助软件工程师进行系统详细设计，并指导其完成《系统详细设计说明书》
     • 指导程序员按《系统详细设计说明书》进行代码实现。
     • 协助项目经理进行配置管理，并提供优化改进建议。
     • 协助测试经理完成对系统测试，并进行系统实现的需求确认。
  3. 系统架构师：
     • 总体设计师
     • 负责对于 整个系统架构，关键构建，接口的设计
     • 《系统概要设计说明书》
  4. 软件工程师：
     • 负责系统功能模块的软件设计与实现
     • 《系统详细设计说明书》
  5. 界面工程师
  6. 数据库管理员：
     • 架构师，分析师一起 数据库建模
     • 创建数据库逻辑数据模型与物理数据模型
  7. 测试经理
  8. 测试工程师
  9. 实施经理
  10. 产品经理
  11. 客户经理

1.2 信息系统软件

• 软件系统类型：
  • 应用软件
  • 支撑软件（中间件）
  • 系统软件
• 其他分类：
  • 通用软件产品
  • 定制软件系统
• 软件特性：
  • 不会损耗，但会过时
  • 不能生产线制造
  • 未能标准化
  • 非有形物体
• 开发解决的问题：
  • 复杂性 - 领域区别大
  • 一致性 - 兼容一致
  • 可变性 - 版本升级
  • 确保本质问题不会失去控制
  • 成功三要素：
    • 利益相关者
    • 软件过程
    • 软件建模
• 软件质量属性：
  • 功能性
  • 可靠性
  • 易用性
  • 效率
  • 移植性，维护性，兼容性，拓展性等

1.3 开发过程

• 规划 -> 开发 -> 运维 -> 终止
• 开发：需求分析 -> 系统设计 -> 系统构造 -> 系统测试
• 规划：
  • 问题
  • 解决方案
  • 可行性分析
  • 启动项目
• 需求分析：
  • 信息采集
  • 定义需求
  • 原型验证
  • 划分优先级
  • 《需求规格说明书》
• 系统设计：
  • 数据库
  • 六册灰姑娘
  • 架构
  • 构建
  • 接口
  • 网络
  • 完全
• 系统构造：
  • 编写
  • 继承
  • 安装
  • 搭建
  • 部署
• 系统测试：
  • V型之类的嗷！
• 运行和维护：
  • 支持用户，维护系统，进化系统
• 系统项目过程：
  • 工程项目方式来管理信息系统的 开发过程，支持过程，组织过程，运行过程 等流程活动。
• 开发过程框架：开发过程钟的公共过程框架以及流程模式。

1.4 开发过程模型：

1. 瀑布：

   • 线性
   • 大量文档
   • 简单，明确，文档多，反馈慢，需求难以完整。
   • 适用于需求十分明确，规模小的系统项目

2. 原型：

   • 解决 需求变更 的快速响应问题，原型开发过程模型来解决瀑布开发的局限。
   • 较快迭代，很快反馈，难以标记里程碑，管理复杂
   • 不健壮，需要具有系统快速开发能力的工具支持
   • 需要较多人机交互界面的系统项目，适合那些 需求初期不太明确的系统项目

3. 螺旋式开发：

   • 进化迭代的系统开发过程模型
   • 原型的迭代特征 + 瀑布的系统化
   • 引入了 风险分析，按照螺线进行 若干次迭代
   • 适用于大型复杂系统

4. 统一开发过程模型：

   • RUP

   • 用例驱动，增量迭代，以体系架构为中心

   • 面向对象方法学，使用UML

   • 最佳实践：

     • 迭代开发
     • 需求管理
     • 基于构建的体系架构
     • 可视化建模
     • 验证质量
     • 控制软件变更

   • 三个视角：

     • 动态
     • 静态
     • 实践

   • 面向对象，用例驱动，架构中心

   • 增量迭代，控制质量，风险管理

   • UML配套，定制流程框架

5. 敏捷开发：

   • 精简，快速，增量迭代
   • 轻量级，紧密合作，面对面沟通，适应需求变化。
   • 人很重要
   • 迭代周期短，成本低，快速适应需求变更
   • 注重系统快速开发，适用于早期需求模糊或需求变更频繁的系统开发项目

1.5 系统开发方法与工具

• 类型
  • 定制开发
  • 产品开发
• 集成开发：
  • 门户集成
  • 数据集成
  • 接口集成
  • 过程集成
• 系统开发策略：
  • 自行开发
    • 优缺点：
      • 满足自身需求的信息系统
      • 组织专业规范的系统开发与实施严格的质量保证比较困难。
      • 存在局限（通用性，稳定性，完整性等）
  • 委托开发
    • 优缺点：
      • 技术优势和经验
      • 节省人力资源，专心于业务优化改进
      • 交流和沟通成本
      • 依赖于专业IT公司的技术支持，后期维护困难
  • 购买商品软件
    • 优缺点：
      • 省时省力
      • 个性化不易
      • 局限，难以变化
  • 联合开发：
    • 与专业IT公司合作开发
    • 优缺点：
      • 发挥两边优势，培养自身技术力量。
      • 依赖于两方合作，自身要有一定系统分析与设计能力。
• 开发方法：
  • 结构化方法：
    • 自顶向下
    • 逐步求精
    • 系统模块分解
    • 过程为中心
    • 典型技术：
      • 数据流图
      • 数据字典
      • 阶层结构图
      • E-R关系图
      • 程序流程图
      • 伪代码
      • 结构化编程
    • 简单，成熟，但是难维护
    • 现状：
      • 功能复杂
      • 规模较大
  • 面向对象：
    • 分析
    • 设计
    • 编程
    • 客观世界由各种对象组成，类是模板，对象之间通过消息实现行为交互。
    • 优缺点：
      • 稳定性好
      • 可重用性好
      • 可维护性好
      • 掌握需要更多实践
    • 适用于功能复杂，规模较大的软件系统项目
  • 基于构件的开发方法：
    • 通过可复用构建构造软件系统
    • 开发效率，重用度 up up up
    • 接口不容易统一，不同开发语言难以互操作
  • 面向服务：
    • 松耦合，粗粒度软件功能宠用
    • 关注点是业务，以服务为核心元素来封装业务功能或者已有应用系统
    • 跨平台的功能复用，可以复用现有应用系统。开发技术复杂，解决较多分布式应用难点技术问题。
• 开发工具和环境：
  • 开发环境：系统开发与维护所用工具和环境。
  • 运行环境：系统运行所依赖的平台环境，操作系统哇，运行时软件等环境，以及服务器等

2. 面向对象建模基础

2.1 面向对象基础

• 对象： 属性 + 行为

• 类：一组具有相同属性和行为的对象集合， 物以类聚

• 类之间的关系：

  • 关联
  • 聚合
  • 泛化

• 面向对象思想：

  1. 抽象
  2. 封装
  3. 继承
  4. 多态

• 面向对象的需求分析：

  • 利益相关者有哪些?
  • 利益相关者要通过系统干什么？
  • 系统有哪些对象?
  • 对象之间的关系是什么？

• 面向对象的需求分析：

  • 利用面向对象的思想与技术去描述目标软件系统的需求。
  • 三个视图：
    • 功能视图（利益相关者功能，利益相关者与功能关系）
    • 静态视图（类对象，类关系）
    • 动态视图（对象之间的交互与活动）
  • 特征：
    • 与开发技术和平台无关
    • 需求分析人员与业务人员进行沟通的过程与结果
    • 清楚，准确描述软件系统的需求是面向对象分析的任务

• 面向对象的系统设计：

  • 架构设计 -> 详细设计

2.2 UML建模语言

• 一种对软件系统进行规范化，可视化，模型化，文档化的标准语言

• 使用多种不同的建模图形来表达系统。

• UML简介：

  • 视图（View）
  • 图（Diagram）
  • 模型元素

• 用例图：

  • 参与者，用例，以及它们之间的关系构成的用于描述系统功能的用例图。
  • 用例模型是一种描述系统功能性需求的方法，是对于系统功能需求的建模

• 活动图：

  • 用于对于工作流程和用例流程建模
  • 业务单元的级别上，对于高级别的业务流程及逆行建模，或者低级别的内部类操作进行建模

• 类图：

  • 类图对于应用领域 各种概念 以及与系统实现相关的各种 内部概念 的建模。
  • 不描述与时间有关的系统行为，属于静态视图。
  • 类图主要由 类 与 类之间的关系 构成
  • 关系有：关联，泛化，聚合

• 顺序图：

  • 描述角色与对象间的 交互 ， 是交互图的一种
  • 顺序图显示 业务，用例 或者 用例一部分的交互流程
  • 由一组 角色/对象 以及它们之间的 消息 组成，强调消息时间顺序

• 通信图：

  • 描述交互
  • 由角色/对象，以及它们之间的关联组成，强调对象之间的连接关系
  • 通信图与顺序图语义等价，与顺序图可以相互转换
  • 通信图的组成：对象，链，消息

• 状态机图：

  • 状态机图对于系统动态方面进行建模
  • 类对象随时间变化的行为
  • 通常一个状态机图依附于一个类
  • 从状态到状态的控制流

• 构件图：

  • 提供系统的物理视图，根据系统的代码构件显示系统的整个物理结构
  • 构件图为系统架构师提供一个为解决方案进行建模的自然形式

• 部署图：

  • 系统软件如何部署到 硬件环境 中
  • 部署图对于系统的 物理运行情况 进行建模

• 包图：

  • 包图提供对于 模型自身组织 进行的建模，是由自身的一系列模型元素（例如：类，状态机和用例）构成的包所构成的模型
  • 由包以及包与包之间的关系组成，一个包可以包含其他的包

• UML通用机制：

  • 规格说明
  • 修饰
  • 通用划分：
    • 保证不同抽象概念层次的机制
    • 分为：
      • 类与对象的划分
      • 接口与实现的分离

• UML拓展机制：

  • 构造型：
    • 对于现有的UML元素进行拓展，使语义多样化，例如<<Actor>> , <<Interface>>
  • 注释：
    • 从属于一组元素的文本解释
  • 约束：
    • 约束使用“{}”内的字符串表达式表示
  • 标签

2.3 BPMN建模语言

• BPMN为企业提供以图形符号理解其内部业务流程的能力
• 图形符号有利于理解组织之间业务协同的效果
• 由 设计人员，管理人员和业务流程实现人员共同使用，为 业务流程设计和实现之间搭建一个标准 桥梁。
• 确保 基于XML的业务流程执行语言可以使用业务表示符号进行可视化，以便将 BPMN图转换为软件流程组件。
• 基本建模元素：
  • 流对象
  • 流
  • 数据
  • 泳道
  • 人工制品
• BPMN的核心元素是流对象，流对象可以细分为3类流对象：
  • 活动（Activity） -> 流程中执行的任何工作
  • 事件（Event） -> 流程中发生的任何事情
  • 网关（Gateway） -> 用于控制流程的分支和聚合
• 流（Flow）用于连接流对象，与流对象一起定义业务流程的过程。
• 数据（Data）是表示业务流程中的数据表示，具体分为数据对象。。。
• 人工制品 -> 给流程附加一些额外的信息
• 泳道 -> 说明不同功能与职责

3. 系统规划

3.1 系统规划概述

• 系统规划 是指组织机构在进行信息化建设之前，为支撑组织机构未来发展提供 信息系统建设方案和计划 。
• 意义：机构信息化建设的基本纲领和总体指向，也是信息系统工程项目实施的 前提和依据。
• 系统规划目标：做出 可行的信息系统方案
• 任务：
  • 指定信息系统建设 总体目标与愿景
  • 确定信息系统 总体框架，技术路线与实施方案
  • 指定组织机构的信息系统 实施建设计划，分析评估信息系统建设方案 可行性

3.2 业务系统规划法

• BSP（业务系统规划法）：
  • BSP是IBM在20世纪70年代提出的一种指定信息系统规划方法。
  • 满足各个管理层次的信息化要求，提供一致的，全面的，可靠的，有价值的信息服务。
  • 应用原则：“自上而下”分析与“自下而上”设计相结合
  • 优缺点：
    • 保证 信息系统独立于组织机构的管理体制
    • 通常需要进行 大量工作活动，花费大量时间
• BPR（业务流程重组法）：
  • 围绕 业务流程改造 的系统规划方法
  • 对于现有业务流程进行不断地优化或重新设计
  • 应用原则： 以过程管理代替职能管理
  • 优缺点：
    • 解决纵向条块管理所带来的局限。
    • 弱没有考虑机构实际情况，完全打破机构现有业务流程，存在较大的风险，遭到多方面的阻力，最终可能导致项目失败。
• 价值链分析法（VCA）：
  • 寻却 企业竞争优势 的方法
  • 分析业务活动链，进行评估。
  • 对于 关键业务技术 的改进提供技术支持
  • 应用：
    • 仓储系统
    • 计算机制造系统
    • 配送与调度系统
    • 订购与发票系统
    • 产品质保维护系统
  • 优缺点：
    • 价值链分析方法来确定自身价值链环节，关注和培养价值链环节上的核心竞争力，利用IT技术支撑。
    • 涉及面复杂，了解内部业务互动价值，同时掌握外部业务活动影响因素，才能够有效完成系统规划工作。
    • 局限在企业信息规划中的应用。
• SST（战略目标集转移法）：
  • 将 组织机构战略目标集 转变为 信息系统战略目标 的规划方法。
  • 应用：为组织机构战略目标服务，根据组织机构战略战略目标确定信息系统目标。
  • 优缺点：
    • 保证系统规划得到全面的信息系统目标。
    • 局限在策略层面进行规划，缺少业务流程规划。
• KSF（关键成功因素法）：
  • 关键因素为依据来确定信息需求的规划方法。
  • 可以根据机构目标确定 关键成功因素， 指定描述相应关键成功因素的 关键绩效指标。
  • 优缺点：
    • 针对性强，快速明确提出支撑组织机构的战略目标的IT解决方案。
    • 一些组织机构战略目标在一定时期后会有一定调整，factors出现变化，需要重新确定信息系统目标方案。

3.3 系统项目计划

• 项目计划是根据信息系统建设目标要求，对于信息系统所涉及项目任务进行总体工作安排。

• 要素：

  • 计划阶段任务：
    • 项目工作分解
    • 活动排序
    • 资源，工期，成本估算
  • 计划阶段输出：
    • 网络图，甘特图
    • 进度计划
    • 成本计划
    • 质量计划
  • 计划阶段技术方法：
    • 活动排序：前导图方法
    • 工期估算：三点估算法，专家判断法
    • 成本估算：自下而上法，专家判断法，类比估算法，参数成本法
    • 进度计划：甘特图，里程碑图，关键路径法

• 项目分解结构（WBS）：

  • 项目工作按照交付成功的方式，定义项目的详细任务过程，指定进度计划，资源需求，成本预算，风险管理计划和采购计划等的重要基础。
  • 分解方式：
    • 按产品的物理结构
    • 系统的功能分解
    • 项目实施过程分解
    • 各个目标分解
    • 。。。
  • 项目计划中作用：
    • 只管说明项目任务范围
    • 方便进行分工，规定人员相应职责
    • 有助于对于工期时间，资源用量和成本的估算
    • 项目计划，成本预算，质量控制，风险管理奠定共同基础

• 项目活动排序：

  • 客观规律
  • 项目目标的要求
  • 轻重缓急
  • 项目本身的内在关系

• 工期估算：

  1. 三点估计法：

  

  2. 德尔菲法：

  

• 项目进度安排：

  • 根据项目 任务活动分解，任务活动顺序，各任务 活动估计时间 和 所需资源 分析，制定出项目起止日期和任务活动开展时间的工作安排。
  • 最长的路径叫做关键路径，路径上的任务叫做关键任务

• 项目成本估算和预算：

  • 项目成本估算：完成项目工作所需要的 费用估计
  • 项目成本估算方法：
    • 类比估算法：利用信息和专家判断
    • 自底向上估算方法：根据任务分解结构的最小任务活动市场成本
    • 德尔菲法：多个领域专家或有经验的项目经理估算，最后达成一致
  • 项目成本预算：
    • 将项目估算结果在任务活动中进行 经费分配 的过程。
    • 目的是提前确定各活动的成本金额，确定项目意外开支准备金的标准和使用规则。
  • 估算和预算区别：
    • 估算用于项目立项，sum(每项任务成本) -> 项目总体费用。
    • 预算用于项目计划，成本总经费的更加精确的分配，以便后期作为项目成本控制管理的基准。

3.4 项目可行性分析

• 细分为：
  • 技术可行性分析
  • 进度可行性分析
  • 经济可行性分析
  • 社会可行性分析
  • 可行性报告方法
• what is 可行性研究：
  • 采用一定的技术和标准，从技术，进度，社会等方面对于项目的必要性，可行性，合理性等进行分析和评估，得出系统建设方案是否可行的评估结论。
• 技术可行性分析：
  • 评估项目解决方案所用 技术方案的可行性和合理性
• 进度可行性分析：
  • 评估系统建设计划 时间长度的合理性和可行性
• 经济可行性分析：
  • 进行初步的 投资回报率分析
  • 从项目成本角度考虑，有足够预算支持该系统建设吗？项目成本？等
• 社会可行性分析：
  • 从国家政策等社会因素，评估信息系统建设的 可行性和合规性
• 可行性分析报告：
  • 在可行性研究基础上，对于可行性分析进行总结，给出可行性研究结论，提供科学依据，并作为进一步开展工作的基础。

4. 系统需求分析：

4.1 需求采集

1. 研究现有文档与系统：
   • 已有的单据和报表，数据库或者纸质文档
   • 这些文档与系统资料真实反映了组织业务过程中数据表现与流转的机制。
   • 数据类似于：
     • 组织结构图
     • 组织的规划与宏观决策相关文档
     • 工作规范文档
     • 业务单据
     • 报表
     • 描述问题的文档
     • 组织业务相关的专业知识
     • 现存相关软件系统
   • 还要思考：
     • 有什么问题，可能的原因？
     • 什么岗位对于问题有所理解？
     • 开发系统如何解决问题？
     • 其他需求采集方法采集其他需求？
2. 与客户以及相关人员进行面谈：
   • 多样性：
     • 客户：周期，预算，质量要求，预期收益
     • 用户：功能需求，非功能需求
     • 领域专家：领域知识
     • 客户的上下游合作伙伴：对系统的合作期望
   • 面谈形式：
     • 正式：提前预约，特定对象，准备问题（可能还有预设答案）。
     • 非正式：正式的补充，没有预设的问题和目的。轻松，更容易获取到真实想法，提到问题和事实。
   • 优缺点：
     • 优点：深入了解面谈者的看法，动态调整面谈内容
     • 缺点：不一定能够及时安排，过程延长
3. 调查表法：
   • 预先设计表格，填写后限时返回。
   • 目标清晰，类型熟悉，业务简单，有效并且低成本
   • 调查很多人，人不在一起，经济
   • 问题分类：
     • 封闭式问题（有备选答案）
     • 开放式问题（无备选答案）
   • 问题种类：
     • 单选 /多选
     • 评价
     • 排序
     • 判断
   • 不同类型：
     • 传统方法（纸质，效率低，难以异地）
     • 新型渠道方法（网页，电子邮件，社交系统）
4. 观察法：
   • 分类：
     • 旁观式观察：不打扰，如果允许可以录像，自己看。
     • 解释式观察：不仅可以观察，还可以得到业务人员的解释。
     • 参与式观察：甚至可以加入到其中，成为团队的一份子。 参与式观察是三种观察中最深入的一种。
   • 多样性：
     • 观察时间的多样性
     • 观察地点的多样性
     • 观察人员的多样性
5. 头脑风暴法：
   • 一群人坐一起自由思考
   • 多个利益相关者对于具体的需求不能达成一致的意见
   • 优点：
     • 无拘无束
     • 共同讨论
     • 高强度的思想碰撞
   • 要求：
     • 有特定讨论主题
     • 有主持人
     • 人数8-15
     • 时间1-2
     • 不消极，不摸鱼，开门见山
     • 后序冷静分析和决策
   • 常见问题：
     • IO
     • 特性
     • 类
     • 调查表中的问题
     • 风险
6. 原型法：
   • 构造一个软件原型对于待开发的系统进行可视化模拟，获得用户反馈
   • 现代且广泛采用
   • 本质是一个演示系统
   • 适用场景：
     • 用户无法准确描述需求
     • 基于原型的软件工程过程模拟的一部分
   • 不适用场景：界面没啥用，大量运算，逻辑性强的系统。
   • 分类：
     • 丢弃型原型：需求引导完成就丢了。
     • 进化型原型：后序仍被用于系统设计和开发。相当于产品的一部分。
7. 快速应用开发：
   • 快速生成系统的开发方法，需求抽取方法
   • RAD -> 快速生成系统的开发方法，也是一种 需求抽取 的方法。
   • 快速交付系统解决方案
   • RAD融合了 进化型原型 + 头脑风暴
   • 技术：
     • 进化原型
     • CASE工具
     • 使用工具的人
     • 交互式联合应用开发活动（头脑风暴）
     • 项目进度表，时间盒的项目管理方法
   • 不足：
     • 足够的人力资源，相当的经历
     • 很短时间内进行分析，可能失败
     • 风险高
     • 难以维护和拓展软件
     • 文档不足

4.2 需求可视化建模

4.2.1 业务流程建模（BPMN）：

• 可以划分为：

  • 普通流程
  • 合作流程
  • 编排流程

  组合利用，可以表达更为复杂的业务流程

• 普通流程建模：

  • 私有业务流程（属于某个特定组织内部的流程），被称为工作流或业务流程：
    • 不可执行的私有业务流程（用于过程和文档），不要求可以自动执行
    • 可执行的私有业务流程：可以根据语义定义自动执行
    • 一个私有流程必须在一个泳池内。
  • 公开业务流程（一个私有业务流程与其他流程或参与者之间的交互）：
    • 包含活动和活动的次序
    • 显示 交互的信息 以及 消息之间的次序

• 合作流程建模：

  • 两个参与者的合作，两个或者更多泳池。
  • 通过 消息流 表示两个参与者之间交换的信息。
  • 可以是空泳池，消息在泳池边上。
  • 如果有内容，消息连接在泳池中的流程活动上
  • 可以用对话来表示一组具有顺序逻辑关联的交互消息

• 编排流程建模：

  • 编排流程也是描述多个参与者之间的交互，但编排流程取消掉了池的概念，由编排活动直接表现多个参与者之间的消息交互，提供了一种基于流程图的视图。
  • 白的是初识消息，脏的不是初识消息。
  • 与合作图类似，但是省略掉了交互细节，只关心和谁交互了，交互了啥，有啥内容，不管！！！

4.2.2 用例图建模：

• 由参与者，用例和它们之间的关系构成，用于描述系统功能的图

• 描述系统功能性需求的方法，对于系统的功能需求建模。

• 用例图构成：

  • 参与者，用例，关系
  • 可选：
    • 系统边界
    • 包
    • 注释

• 参与者：

  • 系统外部和系统 直接交互 的 人或事务
  • 参与者是角色而不是具体的人
  • 典型：人，外部系统，设备

• 用例：

  • 外部可见的功能单元
  • 使用 动词短语 或者 动名词词组
  • 任何用例都不能在缺少参与者的情况 下独立存在。

• 发现用例角度：参与者（职责要求），系统功能（需求文档，功能描述，自带的类似于备份，自动执行的功能）。

• 关联关系：

  • 包含：1. 多个用例用到同一段行为，2. 把某一段事件流抽象成为一个被包含的用例，以达到
    简化描述的目的。
  • 拓展：在一定条件下才会执行，并且其执行会改变基用例的行为。
  • 泛化：是一般与特殊的关系。

  

• 用例规约：

  • 名称
  • 描述
  • 参与者
  • 事件流（基本事件流（正常） 和 备选事件流（异常））
  • 前置条件
  • 后置条件
  • 补充说明

4.2.3 活动图建模：

• 用于描述 系统行为 的模型图，用于描述 过程 哄 活动及其迁移

• 一个活动图对应一个过程

• 应用：

  • 工作流程
  • 用例的行为
  • 复杂过程的算法

• 动作与活动：

  • 
  • 核心元素，可执行的基本单元，圆角矩形。
  • 动作有原子性，不可进一步被分解。活动是工作或工作流，非原子性。
  • 活动状态：入口动作，出口动作，内部活动，内部转换。

• 从用例规约中发现动作。

• 控制流：

  • 一个活动到下一个活动
  • 实现箭头
  • 三种常见的控制流：
    • 顺序
    • 并发：
      • 分叉和回合
      • 分叉：一个分成两个或多个并发运行的分支，回合：并行在这里同步
    • 分支：
      • 条件行为，决策
      • 只有一条路径被激发
      • 合并：两个或多个合并成一个

• 组合活动：

  • 简单活动：没有内嵌活动或者动作
  • 组合活动：嵌套了若干活动或者动作
  • 组合活动不具有原子性，可以执行中被中断。

  

• 泳道：

  • 如果需要确定活动的　负责人，则可以通过　泳道来实现嗷！！！

4.2.4 类图：

• 组成部分：

  • 类名 / 属性
  • 类关系
  • 类数据操作

• 一组具有相同数据结构和相同操作的对象集合，类包括一组数据属性和对于数据属性的一组合法操作。

• 类名通常是 名词 ， 首字母大写，唯一。

• 类属性为名词或者名词短语，首字母小写

• 类的属性分类：

  • 自然属性
  • 管理属性
  • 类关系之间的属性

• 类的操作：

  • 动名词，第一个单词首字母小写

• 发现类操作：

  • 分析每一个类的属性
  • 分析对象的状态
  • 分析用例规约描述中的动作
  • 分析活动图的活动
  • 分析顺序图/通信图中两个对象间的消息

• 典型识别类的方法：

  • 名词短语法：

    • 需求描述文档中抽取出名词短语

  • 公共类模式法：

    • 使用通用的对象分类理论来识别类
    • 实体类，业务类，组织类。。。

  • 用例驱动法：

    • 通过用例发现类，用例图和用例规约
    • 例如：
      • 参与者可以作为类处理，一个参与者对应一个类
      • 名词短语从用例规约中抽取类
      • 公共类模式法分析用例规约描述中的内容，提取相应类

  • CRC（类-职责-协作者）法：

    • 分析对象之间为了完成业务功能而进行的协作来识别类
    • 适合验证其它方法发现的类，并且能够根据类的职责和协作者确定类的属性

    

• 类关系：

  • 关联关系：

    • 发现关联：属性就是和其它类关联，是类发现过程的副产品
    • 说明关联：命名关联，角色，多重性
    • 可以与自身关联嗷！！！（类的一个实例与类的另外一个实例关联）

  • 聚合关系和复合关系：

    • 聚合关系描述的是部分与整体的关 系，删除整体不一定会删除部分。（有点像SpringBoot里面的@Autowired那种感觉）
    • 复合关系也是部分和整体的关系，但部 分的生命周期取决于整体的生命周期，删除整体一定会删除部分（更强的聚合关系，有点像内部自带的，例如人有两条腿，在Java中就是不是独立的，是自己的成员变量嗷！！！）

    

  • 泛化关系：

    • 描述类的 一般和具体 之间的关系，表示 是一种 关系。

    

    • 泛化的目的：
      • 继承
      • 可替换性
      • 多态性

4.3 需求文档化与需求管理

• 一般通过 需求规格说明书 来表示

• 需求规格说明书含有以下的三个主要部分：

  • 功能性需求
  • 非功能性需求
  • 接口需求

• 功能性需求：

  • 功能性需求：用 逻辑功能结构图 来表达
  • 逻辑功能结构图：表达整个系统的所有待开发的功能，和相互之间的关系

  

• 非功能性需求：

  • 性能
  • 适应性
  • 易用性
  • 安全性
  • 可靠性

• 接口需求：

  • 用户接口
  • 软件接口
  • 硬件接口
  • 通信接口

• 需求管理：

  • 理清需求之间是否存在 重复，相似，矛盾等现象
  • 可以构造需求依赖矩阵

• 需求变更：

  • 不可避免，必须有一套规范的变更管理过程

  • 主要有：

    • 建立变更请求文档
    • 评估变更的影响
    • 实现变更
    • 配置管理工具存储和跟踪

    

4.4 需求分析案例

• 建议看PPT嗷！！！

5. 系统架构设计

5.1 设计概述

• 系统设计是指在系统需求分析的基础上，运用软件工程的思想与方法，设计出能满足系统需求目标的新系统构造方案的活动。

• 系统设计活动：
  • 基础设施平台设计：考虑信息系统的运行环境设计
    • 除了考虑系统的 网络 结构， 硬件计算能力 ， 还需要考虑运行 软件 环境设计嗷！！！
  • 系统架构设计：总体架构，拓扑架构，软件架构，数据架构和应用架构
  • 界面：交互界面
  • 数据库设计：合理的 数据库结构
  • 系统构件设计： 构件功能逻辑，构件接口
  • 程序流程设计： 构件内部
  • 安全机制设计： 安全访问，隐私保护等
• 系统设计方法：
  1. 抽象化：降低复杂性，特殊到一般
  2. 逐步求精：从上往下，每一步更比上一步细化
  3. 模块化：按照规则划分
  4. 信息隐藏：实现细节屏蔽其他模块，只能通过接口访问。
  5. 模块独立：完成独立的功能，与其他模块接口关联，便于功能被划分，易于开发和维护。
• 设计原则：
  • 可靠性，安全性，可伸缩性，可维护性等非功能特性需求。
  • 模型抽象，模块化设计，分解为子系统以及其构件进行开发。
  • 采用标准建模语言。
• 设计方法分类：结构化，面向对象
• 建模过程：需求建模，分析建模，总体设计建模，详细设计建模

5.2 架构基础

• 系统架构 又称为 系统体系架构 ， 指的是系统组成的 结构模式

• 架构设计 针对系统需求，不同层面，不同视角，给出总体框架的设计蓝图。

• 作用：反应系统设计总体框架，有利于交流。决定了系统非功能特性，可用性，安全性，可伸缩性以及系统性能。

• 系统总体架构是从全局层面给出系统各种组成要素之间的结构关系。

  • 包括：基础设施，运行平台，应用软件，业务部分，信息数据以及用户等。

• 系统拓扑架构：

  • 节点与节点之间的通信连接关系
  • 节点对应处理逻辑相对独立的物理实体
  • 系统拓扑架构设计是指针对系统基础设施平台设计 节点之间 的 通信连接关系。从 系统网络层面 ， 给出 系统节点在网络环境中的结构关系 ， 包括 节点分布，节点类型，节点运行环境以及 节点之间的通信联系
  • 类型：
    • 总线型
    • 树型
    • 星型
    • 网状型
    • 混合型

  

• 系统数据架构：

  • 数据架构是指在一个机构的信息系统中，各类 数据资源 的组织和存储结构。
  • 需要反应机构的数据节点分布关系。
  • 考虑 数据资源的存储结构和方式
  • 多种数据结构：
    • 分层架构：按照数据资源不同处理要求，可以将它们组织到不同层次的数据管理系统中
    • 系统数据这里架构： 数据资源节点要 部署到不同业务部分服务器 ， 与 数据管理职能有直接关系
    • 数据存储架构：文件系统，数据库系统，数据仓库系统，
      • 文件存储文件，文档，非结构化数据。数据库存储结构化数据。数据仓库存储海量的，历史的分析型数据。
      • 考虑 性能需求
      • 读写分离
      • 按照业务的分库管理
      • 分区（分片）存储

• 软件体系架构：

  • 软件架构，是系统的一个或多个结构，包括软件构件，构件的外部属性，以及关系。
  • 组件：构件，连接件，配置，端口，角色。
  • 软件架构设计是基于一定的 设计原则 和 系统需求 ， 从 软件角度对组成系统的各部分进行组织划分，包括，各个构件，构件的外部可见属性，构件之间的相互关系。

  

  • 设计目标：功能需求+非功能需求：可靠性，安全性，可拓展性，性能等。

• 系统应用架构：

  • 从应用功能视角描述的系统架构（系统要什么功能，怎么组织）：

  

  • 关注 应用功能划分，应用功能集成和应用功能部署。

  • 层次：

    • 企业级应用架构
    • 单个系统应用架构

    

5.3 架构风格

• 针对不同系统 共性问题 提供一般可重用的 软件架构解决方案
• 从组织结构角度定义了一个软件系统族，描绘了组件以及关系嗷！！！
• 应用意义：促进软件系统设计的 复用，使得方案可以可靠解决新问题。
• 软件架构风格描述了特定应用领域中的软件系统组织构件的 惯用模式
• 架构风格分类：

• 分层体系架构：

  • 分层体系架构 采用 层次化 方式组织功能构件，每一层都是为上一层提供服务，使用下一层功能
  • 水平层，清晰的功能处理分工
  • 对软件系统的访问依次通过各层处理嗷！
  • 优点：
    • 分层，简洁清晰
    • 改一层，最多影响相邻层
    • 重用，功能复用
  • 缺点：
    • 划分不一定ok
    • 层次太多，性能低
    • 用户增加，每一层都增加

• 数据共享体系架构：

  • 以数据为中心，仓库体系结构

  

  • 优点：
    • 大量数据共享
    • 共享数据访问接口
  • 缺点：
    • 一个改，每个变
    • 客户增加，性能压力
    • 高可用没考虑

• 事件驱动体系架构：

  • 基于事件机制实现软件构件之间通信的软件架构
  • 并不直接交互，触发事件交互
  • 各个构件需要注册事件，处理函数，事件发生要处理，并返回结果。
  • 优点：
    • 注册引入新的构件，不影响现有构件。
    • 维护简单，可以换
    • 耦合低
  • 缺点：
    • 削弱了自身对于系统控制能力，多个构件比较混乱。
    • 不能很好解决数据交互问题。

• C/S架构：

  • 分布系统体系架构

  

  • 客户机，服务器，多台节点机，用网络连接进行通信，也可以部署在同一物理机器内部。
  • 优点：
    • 分布式计算处理，有利于系统负载分担
    • 交互性强，安全的存取模式，相应速度快，有利于处理大量出局
  • 缺点：
    • 缺少通用性，维护和管理成本高
    • 只限于小型局域网应用。

• B/S架构：

  • Browser / Server
  • 优点：
    • 分布性强，服务器可以在任何地点。
    • 访问方便，只要有网络、浏览器，就可以对系统应用进行访问。
    • 系统处理负载能力强，可以将负载分布Web服务器、应用服务器、数据库服务器处理。通过负载均衡、集群技术可以支持更大负载处理。
    • 系统运维方便，只需要在服务器进行功能修改与发布，即可实现所有用户的同步更新。
    • 用户共享性强，可以支持不同地点用户共享访问系统。
  • 缺点：
    • 个性化处理、人机交互性能不如C/S架构软件。
    • 在系统安全性设计需要考虑更多内容。

• 微核体系架构：

  • 又称为 插件架构，系统内核相对较小
  • 待开发的目标软件分为：软件内核（平台）和 插件两个部分。
  • 优点：
    • 良好的功能拓展性，需要功能就开发插件就行
    • 功能之间隔离的，插件可以被独立加载和卸载，容易部署。
    • 可定制性高，适应不同开发需要。
    • 可以渐进式开发，逐步增加功能。
  • 缺点：
    • 伸缩性差，内核通常是一个独立单元，不容易做分布式。
    • 开发难度相对较高，设计到插件和内核的通信，以及内部的插件登记机制。

• 微服务架构：

  • 面向服务架构（SOA）的升级，一个服务就是一个独立的部署单元，这些单元都是分布式的。
  • 将应用划分为一组小型服务，相互协调配合，为用户提供功能服务。
  • 分布式，解耦，远程通信交互。
  • 优点：
    • 拓展性好，各个服务之间低耦合
    • 容易部署，单一可部署单元，被拆成了多个服务，每个服务都是可部署单元。
    • 容易开发，每个组件可以进行持续集成式开发，实施部署，不间断升级
    • 容易测试
  • 缺点：
    • 强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微 服务，变得很凌乱和笨重，性能也会不佳。
    • 分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难。

5.4 架构模式

• 软件架构模式就是针对特定需求问题及其环境，所给出通用的软件架构设计解决方案。
• 软件架构模式描述了在特定设计情形下反复出现的问题，并提供了已经得到充分证明的 通用解决方案摘要。
• 软件架构模式是软件架构的模板。
• 架构模式和架构风格区别：
  • 架构模式和架构风格都是在软件架构设计中施加的规则和语义约束。
  • 架构风格描绘总体结构框架。
  • 架构模式规模各异,更多集中在体系结构的某一方面。
  • 架构风格描绘设计手法，架构模式针对特定问题描绘解决方案。
  • 每种架构风格都用一个架构模式来描述。
  • 架构风格描绘设计手法，架构模式针对特定问题描绘解决方案。
  • 架构风格之间彼此独立，架构模式可依赖于其他模式。
• 架构模式意义：
  • 软件工程成熟的架构设计方案可以被复用，避免重复“发明车轮”的工作。
  • 基于架构模式方法设计软件系统，可以节省开发成本，提高软件开发效率。
• 结构模式：
  • 代理者模式：
    • 使用代理者扮演客户端和服务端的中介角色。
    • 服务端向代理者注册服务，客户端发送服务请 求给代理者。
    • 统一描述、发现、集成 框架（UDDI）为客户端提供一种在Web上动态发现服务的机制
  • 集中式控制模式：
    • 在集中式控制模式的软件架构中，中央控制构件按照特定对象状态机逻辑对系统全局行为进行控制操作。
    • 中央控制构件根据输入事件引发的系统状态变迁，对相关部件实施操作控制，从而实现系统功能控制。
  • 分布式控制模式：
    • 在分布式控制模式的软件架构中，系统控制分布在多个控制构件之中，不存在总控全局的单一构件。
    • 每个控制构件按照特定对象状态机逻辑对系统特定部分的行为进行控制操作。
    • 多个控制构件通过消息通信协作完成整个系统的控制处理。
  • 多层控制模式：
    • 在多层控制模式的软件架构中，系统控制分布在多个控制构件之中，此外，通过协调者构件控制所 有控制构件实现整个系统的控制。
    • 协调者构件提供全局控制
    • 协调者控件发布命令到各个控制构件执行控制操作，同时协调者控件也从控制构件接收状态消息。
  • 抽象分层模式：
    • 在抽象分层模式的软件架构中，复杂的软件构件关系被抽象到不同的功能层次。
    • 每个层次构件只能访问它的相邻下层服务，同时也只对 相邻的上层提供服务。
    • 层次之间通过请求调用、返回响应消息方式进行交互。
    • 优缺点：简化系统，提高伸缩性。可能导致系统效率降低。
  • 多客户/单服务：
    • 在多客户/单服务模式的软件架 构中，软件构件被部署到多个客户端节点和一个服务端节点。
    • 该模式支持多个客户端构件向一个服务端构件提出服务请求，服 务端构件将处理结果返回给请求的客户端构件。
  • 多客户/多服务：
    • 软件构件被部署到多个客户端节点和多个服务端节点上运行。
    • 客户端构件通过网络连接访问多个服务器节点上运行的服务。
  • 多层客户/服务模式：
    • 在多层客户/服务模式的软件架构中，除 了基本的客户端层次和服务端层次外，还有一个同时扮演客户端角色和服务端角色的中间层。
• 通信模式：
  • 调用/返回模式:
    • 一个客户构件对象的操作方法去调用服务构件对象的操作方法。
    • 当服务构件对象的操作方法执行后，将处理结果返回客户构件对象。
  • 异步消息通信模式：
    • 一个构件中对象发送一个消息给另一个构件的对象，其发送者不需要等待对方回复，可以继续执行其他操作。
  • 同步消息通信模式：
    • 一个构件对象发送一个消息给另一 个构件对象，需要等待对方回复，才可继续执行其他操作。
  • 服务注册、转发、发现通信模式：
    • 服务注册、转发、发现通信模式应用于面向服务的软件架 构中，各个服务构件能够分布在多个节点上运行。
    • 通信模式：
      • 服务注册通信模式：
        • 服务提供者为了让服务可以被客户端定位和访问，首先需要向服务代理注册服 务信息。
      • 服务代理转发通信模式：
        • 客户端向服务代理发出服务请求之 后，服务代理将消息转发给服务。
      • 服务句柄代理转发通信模式：
        • 在客户端向服务代理发出请求后，服务代理返回一个用于客户端与服务之间直接通信的服务句柄。
      • 服务发现通信模式：
        • 问题：客户端不知道服务名称 ，只知道服务类型。
        • 解决方案：客户端可以从服务代理处获得所请求类型服务的列表。从中选取一个特定服务。服务代理返回该服务句柄用于 客户端与服务之间直接通信。或者采用代理转发。
      • 广播/组播通信模式：
        • 广播：服务构件向所有客户端构件发送同一消息，客户端构件自行决定是否处理该消息。
        • 组播：客户端向服务提供者订阅服务消息，服务端发送该类消息时向所有订阅客户端发送。
• 事务模式：
  • 两阶段提交协议模式：
    • 两阶段提交协议模式/原子事务模式用于分布式系统中原子事务处理，即确保事务所封装的服务请求操作是不可分割的，它们要么都完成，要么都取消。
    • 在两阶段提交协议模式中，通过一个提交协调者构件（commitCoordinator）与多个服 务构件进行通信协调，实现事务处理。
  • 复合事务模式：
    • 在复杂业务处理中，当一个事务可以被分解为若干更小的、独立的处理单元时， 这种事务就是复合事务。
  • 长事务模式：
    • 在业务处理中，若需要用户参与决策操作，则会出现较长时间的数据资源锁定处理，这样的事务称为长事务。
    • 为解决长事务对数据资源长时间锁定问题，可以将长事务分解为多个独立的事务，用户决策安排在事务之间。

5.5 UML建模设计

• 软件架构的静态结构模型用于描述软件系统的静态逻辑结构。
• 可以用UML类图可视化呈现出来
• 将复杂系统划分为相互联系的若干子系统，并在高层设计中采用UML包图对系统的软件静态结构进行抽象设计。
• 包用来对模型元素进行分组，简化UML图，使其更容易理解。
• 包采用类似文件夹的包符号，可以应用在任何一种UML图上。
• 包图用来描述包与包之间的关系，表示模型元素的组织结构的模型图。
• 包图可用于描述软件的逻辑模型

• 交互行为模型：
  • UML通信图描述软件对象之间的协作通信。
  • 通信图是表现对象间直接交互关系的模型图。
  • 在高层抽象的软件架构设计中，可以采用UML通信图描述子系统之间的消息通信。

• 物理结构模型：

  • 反应 系统结构的实现方案
  • 采用 UML构件图 和 UML部署图
  • 构件图是描述系统的构件结构及其关系的模型图。
  • 部署图是表示系统构件在环境节点中的部署方案。

  

  

• ATM机实例看PPT嗷！！！

6. 软件模块详细设计

6.1 软件建模设计概述

• 目标：
  • 详细设计对于系统中的每个构件进行详细建模描述
  • 在 分析模型 和 架构模型 的基础上，对系统中构件的内部工作进行描述，为每个构件设计完整的 数据结构，处理逻辑，接口和通信机制。
  • 构件包括一组协作的类和构件
  • 好的构件设计：
    • 包含所有明确需求
    • 满足用户隐含要求
    • 可读可理解
    • 提供完整视图
• 原则：
  • 设计在发生变更时能够适应变更并且减少副作用的传播
  • 基本原则：
    • 开闭原则：
      • 对于拓展开放，对于修改封闭
    • 里氏替换原则：
      • 子类可以替换基类
    • 依赖导致原则：
      • 依赖于抽象而不是具体实现
    • 接口分离原则：
      • 多个客户专用接口比一个通用接口要好
    • 高内聚：
      • 功能内聚，分层内聚，通信内聚
      • 一般来说：内聚性越高，构件越容易实现，测试和维护
    • 低耦合：
      • 构件设计尽可能保持低耦合
      • 通过类的公共接口实现耦合
    • 可重用：
      • 尽量使用已有的类
      • 设计新类的时候考虑将来的可重用性
• 内容：
  • 构建级设计关注类的定义和细化
  • 包括：
    • 定义和细化类，对软件的 静态结构 建模。
    • 分析类之间的交互，对软件的 动态交互 建模
    • 对于软件 动态交互 建模
    • 对于软件的 实现 进行细化和建模
  • 静态结构建模：
    • 使用 类图 对于静态结构建模
    • 类建模集成和包含了其他所有建模活动
  • 动态交互建模：
    • 展现 交互与协作
    • 使用 顺序图 或 通信图 细化交互
    • 上面的分析建模能够 发现类的操作
  • 软件状态机建模：
    • 对于系统中 重要的类，还会为其建立并细化 状态机图
    • 通常一个状态机图依附于一个类
  • 软件实现建模：
    • 构件图进行细化，对于系统的实现结构进行建模和细化。
    • 部署图进行细化，对于系统运行时物理配置资源进行详细建模。
    • 包图进行细化，对于自身组织情况进行详细建模。
• 软件建模设计活动：
  • 随着信息收集来精炼方案的迭代过程
  • 分析和设计的界限是模糊的，从分析到设计是一个逐步扩充和细化模型的过程。
  • 主要内容：
    1. 确定与问题域相关的设计类
    2. 确定于系统实现相关的设计类
    3. 细化设计类，详细描述每个设计类的属性，操作和接口
    4. 详细设计与数据管理相关的类
    5. 建模并细化类或构件的行为表示
    6. 细化部署图
    7. 详细设计是一个迭代过程，设计过程中可能会改进方案或采用其他方案，进行系统重构。

6.2 UML静态结构视图建模

• 结构视图建模主要使用类图来表示

• 类建模集成和包含了所有其他建模活动。

• 类：

  • 实体类：存储和管理永久信息和行为
  • 边界类：表示外部参与者和系统之间的交互
  • 控制类：业务控制逻辑，协调边界类和实体类。
  • 类建模不是一个确定的过程，是高度迭代增量式。

• 关联：

  • 类与类之间最常见的一种关系
  • 具有关联名，角色和关联重数
  • 关联度：连接的类的个数，当一个类关联本身时，不是类的实例与类关联，而是这个类的两个实例相互关联
  • 关联类：如果关联关系具有属性，则可以使用关联类表示关联关系。

• 聚合：

  • 聚合：部分与整体的关系
  • 复合：部分与整体的关系，部分的 生命周期 取决于整体的生命周期。
  • 专属聚合（ExclusiveOwns）：
    • 部分对整体具有存在依赖性，删除整体时，部分也被删除。
    • 传递性
    • 非对称性
    • 固定性
  • 从属聚合（Owns）：
    • 部分对整体具有存在依赖性，删除整体时，部分也被删除。
    • 传递性
    • 非对称性
  • 拥有聚合（Has）:
    • 传递性
    • 非对称性
  • 成员聚合（Member）：
    • 不具有存在依赖性、传递性、非对称性、固定性。
    • 具有有目的的组合独立对象的特征
    • 一个对象可以同时属于一个以上的复合对象
  • 委托（Delegation）：
    • 聚合将对象组织成聚合层次
    • 当复合对象自身不能完成一项任务时，它能够访问它的构件对象中的方法，这称为委托
    • 委托作为一种代码复用技术，是继承的良好替代。

• 泛化：

  • 一般与具体的关系，表示 是一种 的关系
  • 将 一般类（超类，父类） 与 具体类（子类） 连接起来。
  • 泛化与继承：
    • 泛化是类之间的语义关系 ， 描述类的一般和具体之间的关系。
    • 继承是一种机制 ，通过继承，子类可以合并超类中定义的结构和行为。
    • 泛化的目的：
      • 继承：允许共享部分只被声明一次而可以被许多类共享，从而减小模型的规模，便于复用。
      • 可替换性：子类对象是超类变量的合法值。代码中任何访问超类对象的地方，都可以用子类对象来访问。
      • 多态性：同样的操作在不同类中可以有不同实现。
    • 实现继承：
      • 子类extends父类
      • 拓展继承：
        • 继承作为类的 增量式 定义
        • 子类具有比超类更多的特性，子类是超类的一种
      • 限制继承：
        • 继承来的一些特性在子类中被重载。
        • 问题：子类没有包括超类的所有特征，会带来维护上的问题
      • 方便继承：
        • 实现继承的不恰当使用
        • 两个或多个类具有相似的实现，但概念之间没有分类关系
        • 问题：子类没有包括超类的所有特征，语义不正确，可替换性原则无效

• 关联，聚合，泛化：

  • 泛化是：超类-子类的概念，基于 类 的概念。
  • 聚合是：超集-子集的关系，以 对象 为中心
  • 继承是：基于 类 的，继承层次
  • 聚合是：基于对象的，将对象组织成聚合层次

• 高级类建模：

  • 可见性与封装：

    • 通过设置可见性可以确定类内部的封装程度，决定其他类能否访问该类的元素。
    • 

  • 可见性：

    • 保护可见性：保护可见性指类的属性或操作对本 类及其子类可见。应用于继承的情况。
    • 包可见性：具有包可见性的属性和操作能够被处于同一包中的其他类的对象访问。（Java）
    • 友元可见性：当一个类需要访问另一个类的私有属性或操作时，可以采用友元可见性。（C++）

  • 导出信息：

    • 导出信息是指从其他元素计算得到的信息，是一种冗余信息，目的是为了增加可读性和信息存取的最优化问题。
    • 导出信息包括导出属性和导出关联。

  • 限定关联：

    • 限定符

  • 关联类与具体化类：

    • 要求对于每一对链接起来的类的实例，只能存在关联类的一个实例
    • 如果不能满足这个约束的话，就需要将关联具体化，使用一个普通类来代替关联 类，这个具体化类与之前的两个类均具有二元关联

    

• 接口与抽象类：

  • 接口：描述类或者和构件的一个服务的 操作集
    • 接口定义一组操作，但不定义操作的实现。
    • 构造型为<<interface>>的类
    • 
  • 抽象类：
    • 抽象类指不具有实例的类，通常作为父类，没有直接的实例对象，抽象类的子类 可以实例化。
  • 区别：
    • 抽象类是对一组具有相同属性和方法的逻辑上有关系的事物的一种抽象。
    • 接口是对一组具有相同属性和方法的逻辑上不相关的事物的一种抽象。
    • 抽象类能提供一些操作的部分实现，而接口不实现任何操作。
    • 抽象类体现一种泛化关系，即“是一种”的关系，而接口仅仅是契约关系。
    • Java不支持多重实现继承。接口继承提供了一种达到多重实现继承的方法。
    • 接口不是在对问题域的分析中发现的，而是基于设计发现的。
    • 尽管接口没有实现，但它们却提供了强大的建模能力。通过区分使用接口的类和实现接口的类，接口使系统更容易理解、维护和演进。

• 类内聚与类耦合：

  • 类内部与之间
  • 达到良好的平衡
  • 迪米特法则：
    • 层内耦合，耦合应该最小化
    • 采用了 最少知识原则

  

  • Demeter增强法则：将第3条法则限制在类本身定义的属性上，而不允许继承来的属性作为消息目标，从而约束因继承引入的耦合。

6.3 UML动态交互视图建模

• 交互视图可以使用顺序图或通信图来表示。
• 语法格式： 对象名：类名

• 顺序图：
  • 描述 交互
  • 描述系统中 各个对象按照时间顺序交互 的过程。
  • 对象和生命线
  • 激活：激活是对象操作的执行，表示一个对象直接地或通过从属操作完成操作的过程。
  • 消息：消息表示一个对象向其他对象发送信号，或者 一个对象调用其他对象的操作。
  • 过程：
    1. 确定对象
    2. 创建顺序图
• 通信图：
  • 交互的建模，交互图的一种
  • 表现了 对象之间协作关系
  • 强调对象间的连接关系
  • 通信图和顺序图语义等价
  • 对象：对象名：类名
  • 链：存在交互的对象
  • 消息：动态交互的消息。
• 类操作：
  • 类所能提供的服务或可执行的操作，描述了类所代表的对象具备的动态部分的公共特征抽象。
  • 通过公共接口，对象才能相互合作执行用例和活动。
  • 发现操作：
    • 考察交互能够发现类中的方法（操作）。
    • 顺序图和通信图中的每一条消息，都必须有目标对象的一个操作为其服务。
    • 根据类职责确定操作，包括CRUD操作
    • 操作名称、参数表和返回类型一起被称为操作签名。说明操作：操作名称是动词或动词短语
• 高级交互设计：
  • 创建和销毁对象：
    • 顺序图中可以在交互过程中创建和销毁对象。
    • 创建一个对象是发送者发送一个实例化消息后实例 化对象的结果。
    • 销毁对象是将对象销毁并回收其拥有的资源，它通 常是一个明确的动作，也可以是其他动作、约束或
      垃圾回收机制的结果。
  • 片段（交互操作符）：
    • 展示条件和循环
    • 使用交互操作符来展示这种高层控制
    • 交互片段：一段交互序列
    • 
    • 
    • 交互引用：
      • 太复杂的顺序图难以理解。
      • 为了简化和复用可以采用交互引用

6.4 UML状态机视图建模

• UML中的状态机图由表示状态的节点和表示状态之间转换的带箭头的直线组成。
• 状态：对象在其生命周期中的各种状态
• 状态名：名称
• 入口/出口动作：内部初始化，退出一个状态时执行的操作
• 内部活动：状态可以包含内部活动。当对象进入一个状态后，活动在入口动作完成后开始执行。如果活动结束，状态就完成，然后一个从这个状态出发的转换被触发。
• 内部转换：状态可能包含一系列的内部转换，内部转换的结果并不改变状态本身。
• 状态类型：
  • 初始
  • 终止
  • 嵌套
  • 历史
• 转换：在这个状态的变化中，转换被称作激发。
• 触发器事件，监护条件，动作，判定与合并（条件行为），分叉与汇合（并发行为）

6.5 软件实现视图建模

• 实现视图：

  • 构件图
  • 部署图
  • 包图

• 构件：

  • 系统的一个独立的部署单元，不能被部分部署
  • 组装单元
  • 是系统可被替换的一部分，复合同样的接口就能替换
  • 源代码、可执行文件、库、数据库、文档等都是构件。

• 构件图：

  • 构件图（Component diagram）根据系统的代码构件显示系统代码的整个物 理结构。
  • 依赖关系：

  

• 构件与接口之间的关系：

  • 接口进行协作
  • 接口和构件表现为 依赖关系 和 实现关系
  • 提供接口
  • 请求接口

• 部署图：

  • 部署图用于对系统的物理运行情况进行建模。
  • 部署图中包含两种基本模型元素：结点和结点之间的连接。
  • 结点是构件或人工制品运行的位置，构件和人工制品部署于结点上。

  

• 包图：

  • 在面向对象系统中，类是构建整个系统的基本构造块。
  • 包是具有指定名称的建模元素的分组，表示一组相关的模型元素，如类、 用例等。
  • 包的可见性：

  

  • 包的嵌套：描述包与包之间的关系，用于描述软件系统的逻辑模型。
  • 包与包之间可以存在依赖关系。两个包之间存在着依赖关系通常是指这两个包 所包含的模型元素之间存在着一个或多个依赖关系。
  • 包的依赖关系使用一根虚线箭线表示，箭头指向被依赖的包。
  • 包图的应用：
    • 最常见的应用是类包图
    • 法则：
      • 将具有继承关系的类分到一个包里
      • 将具有聚合关系的类分到一个包里；
      • 将协作较多的类分到一个包里。
  • 包图中的每个包都可以用一个类图来描述，或者用另一个包图来描述。

6.6 软件建模设计实践

• 看PPT

7. 设计模式

7.1 软件设计模式概述

• 结构良好的面向对象软件体系结构中都包含了许多 模式。
• 为开发人员提供一种使用 专家设计经验 的有效途径
• 设计模式提供了精化软件系统元素或元素间关系的方案。
• 基本元素：
  • 模式名
  • 问题
  • 解决方案
  • 效果
• 典型模式：
  • 23种嗷！！！
• 分类：

7.2 创建型模式：

• 概述：
  • 和对象的创建相关
  • 抽象了对象实例化过程
  • 帮助系统独立于如何创建，组合和表示它的对象
• 含有：

单例模式：

• 对于系统中的某些类来说，只有一个实例很重要。
• 如何保证一个类只有一个实例并且易于被访问？：
  • 定义一个全局变量，但是不能防止实例化多个对象
  • 更好的解决方法：让类自身负责保存它的唯一实例，保证没有其他实例被创建，并且可以提供一个 访问该实例的方法
• 单例模式(Singleton Pattern)：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。
• 三个要点：
  • 某个类只能有一个实例
  • 自行创建这个实例
  • 向整个系统提供这个实例
• 对象创建型模式，又名为 单件模式 或 单态模式。

public class Singleton {
    private static Singleton instance = null;
    
    private Singleton() {
        
    }
    
    //静态公有工厂方法，返回唯一实例
    public static Singleton getInstance() {
        if(instance == null) {
            // 关于这个类的初始化操作都可以在这里嗷！！！
            instance = new Singleton();
        }
        
        return instance;
    }
}

• 优点：
  • 提供了对于唯一实例的受控访问
  • 可以节约系统资源
  • 允许可变数目的实例
• 缺点：
  • 单例类的拓展有很大的困难
  • 单例类职责过重
  • 滥用单例将带来一些负面问题
• 适用环境：
  • 系统只需要一个实例对象
  • 调用类的单个实例只允许使用一个公共访问点

7.3 结构型模式

• 如何将类或者对象结合在一起形成更大的结构
• 类结构型模式和对象结构型模式：
  • 类结构型模式关心类的组合
  • 对象结构型模式关心类与对象的组合
  • 大部分结构型模式都是对象结构型模式。

适配器模式：

• 现有的接口需要转化为客户类期望的接口，这样保证了对现有类的重用。适配器模式可以完成这样的转化。
• 适配器把客户类的请求转化为对适配者的相应接口的调用。
• 适配器可以使由于接口不兼容而不能交互的类可以一起工作。这就是适配器模式的模式动机。
• 适配器模式是两个不兼容的接口之间的桥梁。
• 适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。
• 类适配器模式实现：

public class Adapter extends Target {
    private Adaptee adaptee;
    
    public Adapter(Adaptee adaptee) {
        this.adaptee = adaptee;
    }
    
    public void request() {
        adaptee.specificRequest();
    }
}

public interface Robot {
    public void cry();
    public void move();
}

class Dog {
    public void wang() {
        System.out.println("Dog wang wang");
    }
    
    public void run() {
        System.out.println("Dog run run");
    }
}

class DogAdapter extends Dog implements Robot {
    public void cry() {
        System.out.println("I am robot");
        super.wang();
    }
    
    public void move() {
        System.out.println("I am robot");
        super.run();
    }
}

• 优点：
  • 接口不兼容的可以一起工作，提高了类的复用，增加了类的透明度。
• 缺点：
  • 过多会乱，不容易整体把握。
  • 不是很有必要可以不适用，直接重构orz。
• 适用环境：
  • 现有的类，而类的接口不符合系统需要
  • 想要建立一个可以重复使用的类

桥接模式：

• 对于有两个变化维度（即两个变化原因）的系统，采用桥接模式来进行设计,系统中类的个数更少，且系统
  扩展更为方便。
• 桥接模式将继承关系转换为关联关系，从而降低了类与类之间的耦合，减少了代码编写量。
• 将抽象部分与它的实现部分分离，使它们都可以独立地变化。
• 桥接模式中的脱耦，是指在一个软件系统的抽象化和实现化之间，使用关联关系（组合或者聚合关系）而不是继承关系
• 对象结构型模式，又被称为柄体模式或者接口模式。

public abstract class Abstraction {
    protected Implementor impl;
    
    public void setImpl(Implementor impl) {
        this.impl = impl;
    }
    
    public abstract void operation();
}

public interface Implementor {
	public void operationImpl();
}

• 模拟毛笔：

//第一个维度
public abstract class Pen
{
    // 第二个维度
    protected Color color;
    public void setCOlor(Color color) {
        this.color = color;
    }
    
    public abstract void draw(String name);
}

public interface Color
{
    void bepaint(String penType , String name)
}

public class Black implements Color
{
    public void bepaint(String penType , String name) {
        System.out.println(penType + "黑色的" + name + ".");
    }
}

public class Blue implements Color
{
    public void bepaint(String penType , String name) {
        System.out.println(penType + "蓝色的" + name + ".");
    }
}

public class BigPen extends Pen
{
    public void draw(String name)
    {
        String penType = "大号画笔绘制";
        this.color.bepaint(penType,name);
    }
}

public class SmallPen extends Pen
{
    public void draw(String name)
    {
        String penType = "小号画笔绘制";
        this.color.bepaint(penType,name);
    }
}

• 优点：
  • 分离抽象和实现部分
  • 可扩充性，可以拓展任意一个维度，不需要改变原有系统嗷！！
  • 比多继承好，多继承违背了类的单一职责原则
• 缺点：
  • 理解和设计难度高
  • 抽象出两个独立变化的维度。

7.4 行为型模式

• 内容：
  • 类行为模式使用继承机制在类间分配行为。
  • 对象行为模式使用对象组合。

责任链模式：

• 职责链可以是一条直线、一个环或者一个树形结构，最常见的职责链是直线型，即沿着一条单 向的链来传递请求。
• 职责链模式可以将请求的处理者组织成一条链，并使请求 沿着链传递，由链上的处理者对请求进行相应的处理，客户端无须关心请求的处理细节以及请求的传递，只需将请求发送到链上即可，将请求的发送者和请求的处理者解耦。
• 模式定义：
  • 让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
  • 职责链模式又称为责任链模式，它是一种对象行为型模式。
• 很多对象由每一个对象对其下家的引用而连接起来形成一条链。
• 系统可以在不影响客户端的情况下动态地重新组织链和分配责任

public abstract class Handler{
    protected Handler successor; 
    
    public void setSuccessor(Handler successor) 
    {
		this.successor=successor; 
    }
    
	public abstract void handleRequest(String request);
}

public class ConcreteHandler extends Handler {
    public void handleRequest(String request) {
        if(request满足条件) {
            //我来处理请求嗷！！！
        }else {
            this.successor.handleRequest(request);
            // 转发对象嗷！！！
        }
    }
}

• 看一下PPT上的例子嗷！！！

• 优点：

  • 降低耦合度
  • 增强拓展性，增加新的请求处理类很方便
  • 灵活性up
  • 相互连接

• 缺点：

  • 不能保证请求一定被接收
  • 较长的责任链，性能会收到一定影响。

中介者模式：

• 出现原因：模块由多个对象构成，复杂upupup。为了减少对象之间复杂的引用关系，使之成为一个松耦合的系统，我们需要使用中介者模式。
• 封装一系列的对象交互，从而耦合松散，可以独立改变它们之间的交互，此外，中介者模式又被称为 调停者模式 ， 它是一种对象行为型模式。
• 中介者职责：
  • 中转作用（结构型）：在结构上的支持
  • 协调作用（行为性）：在行为上的支持

public abstract class Mediator {
    protected ArrayList colleagues;
    
    public void register(Colleague colleague) {
        colleagues.add(colleague);
    }
    
    public abstract void relay();
}

public class ConcreteMediator extends Mediator {
    public void relay()
    {
        //.......
        colleagues.get(0).method1();
        //.......
    }
}

public abstract class Colleague {
	protected Mediator mediator;
    
	public Colleague(Mediator mediator) {
		this.mediator=mediator; 
    }
    
	public abstract void method1(); //自有方法		public abstract void method2(); //依赖方法
}

public class ConcreteColleague extends Colleague {
	public ConcreteColleague(Mediator mediator) {
		super(mediator); 
    }
    
    // 自有方法
	public void method1() {
        // ......
    }
    
    // 依赖方法
    public void method2() {
        // ......
        mediator.relay();
    }
}

• 优点：
  • 简化了对象之间的交互。
  • 各个类解耦
  • 减少子类生成
  • 简化各同事类的设计和实现
• 缺点：
  • 交互细节，具体中介者类非常复杂，使得系统难以维护。

8. 用户界面设计

8.1 概述：

• 用户界面（User Interface）泛指用户与系统之间进行交互所采用的方式、途径、内容、布局及结构的总称。

• 作用：

  • 表示层构件，控制I/O。并且传递用户和系统之间的双向的消息，表现信息表达与展示功能。

• 类型：

  • GUI
  • 命令行

• 特性：

  • 易用性
  • 灵活性
  • 安全性
  • 艺术性

• 用户界面设计：

  • 人机交互，操作逻辑，页面布局等方面的整体设计
  • 设计要素：
    • 软件操作界面
    • 输入媒介设计
    • 输出媒介设计
    • 系统接口设计
  • 目标：功能+非功能（友好，舒适，简单，方便）

• 用户界面设计原则：

  1. 用户能有效控制系统

  2. 减少用户的记忆负担

  3. 保持界面一致性

  4. 界面实用和美观

  5. 界面客户化和个性化

• 用户界面设计规范：

  • 一致性规范：风格，布局，交互方式，设计规范。色彩，文字，图片，图标前后一致，符合主题。
  • 准确性规范：含义明确，避免歧义，出错有意义，备注说明
  • 页面布局规范：从上到下，从左到右，功能键紧凑，简介。
  • 系统操作规范：回车自动出发操作，不可逆的操作要通知用户，热键的映射。
  • 系统响应时间规范：处理请求时间控制。3s以内，立刻给出结果。3s以上，给出进度条。消息提示。

• 设计内容：

  • 界面结构设计是对用户界面系统的组成结构与控制关系进行设计。
  • 界面交互设计是对用户实现功能操作的交互过程进行设计。
  • 界面导航设计中，需要采用导航机制来帮 助用户定位，告诉用户“从哪里来”、“现在在哪里”、“可以去哪”。
  • 界面视觉设计是指在用户界面中通过使用恰 当的视觉要素（如色彩、文字、图标、图片、空间）满足用户功能需求和心理需求。
  • 界面布局设计是指对界面内各元素的位置安排与分布。

• 设计流程：

8.2 Web的GUI设计：

• 总体页面结构：总体页面结构是指连接Web系统所有页面的整体结构模型，它决定了系统功能模块组织、 页面导航路径、人机交互关系。
• 总体页面结构设计要素：系统目标、功能结构、展示内容、导航机制、用户体验等 因素，并反映系统功能页面组成、信息结构、交互关系，以及页面链接等要素。
• 结构类型：线性结构，分层结构，网络结构等
• 线性：

• 分层：

• 网络：

• 页面布局设计：
  • 页面板块以及元素的结构分布
  • 规划页面中各板块的内容呈现，方便用户操作
• 一栏式：

• 两栏式：

• 三栏式：

页面导航设计：

• 导航结构作用：告诉用户这个系统有哪些方式可以实现页面跳转。
• 导航结构类型：

上面这个就是Chrome的书签栏orz

也是？？？

• 导航机制：
  • 导航机制是指Web系统提供的页面导航元素及使能方式。
  • 导航元素：
    • NavMen导航菜单
    • Breadcrumb（面包屑）导航链接
    • Tab标签导航
    • 超文本导航链接
    • 导航面板
  • 导航使能方式通常为用户在导航元素上触发事件，如鼠标点击或快捷按键，然后进行导 航页面跳转。

页面输入设计：

• 在Web系统中，数据输入是通过页面表单输入来实现的。

• Web表单是页面中一种用于组织数据输入到服务器的控件容器，它可以包含文本输入 框、复选框、单选按钮、列表框、文件域、按钮等控件。

• 类型：

  1. 文本输入框：文本输入框是一种用于在表单中输入文本内容的控件。在文本输入框控件属性中，可以定 义输入文本为固定长度的字符串，也可不限制文本长度。

  

  2. 复选框在表单中用于呈现多个输入选项列表。用户可以在复选框中选择多个选项，作 为表单的输入数据：

  

  3. 在表单中，单选按钮控件用于输入单个选项值。单选按钮呈现一个完整的、互斥的选项 列表，每个选项前都有一个小圆圈：

  

  4. 列表框在表单中用于列表选项输入。在列表框中可以选择单个选项或多个选项。使用列表 数据输入，可以方便用户快速输入，并防止错误数据输入。

  

  5. 文件域在表单中用于文件上传输入。文件域控件允许用户从操作系统文件目录中选取 文件上传。

  

  6. 在表单中，按钮控件用于产生动作，执行表单的脚本程序，实现数据输入处理：

  

  7. 表单输入数据校验：为了确保表单输入到信息系统中的数据是有效的，通常需要在页面表单中编写脚本程序， 对输入数据进行校验检查。

  

• 页面输出设计：

1. 数据列表输出：

2. 数据统计图输出：

3. 数据报表输出：

8.3 Web系统GUI设计案例

• 看PPT

8.4 移动APP软件GUI设计

• 移动App软件与传统的电脑软件有较大不同，它基于有限软硬件资源的移动终端运行，并 且需要面对多种终端屏幕、多种终端操作系统、多种使用场景、移动通信网络、大量用户访问的复杂应用情况。
• 挑战：
  • 多种尺寸
  • 设计挑战
  • CPU，内存有限
  • 市场变化
• 原则：
  • 环境贴近原则
  • 易取原则
  • 优美简约原则
  • 人性化帮助原则
  • 用户可控原则
  • 灵活高效原则
  • 防错原则
  • 容错原则
  • 系统状态可见原则
  • 界面风格一致原则
• 总体界面结构：
  • 在移动App软件GUI开发中，首先需要设计系统总体界面结构，将系统各个界面按照一定 结构组织起来，让用户了解系统功能界面结构。
• 界面布局设计：移动App界面布局设计是指在App界面中对内容文字、表格、图形、图像、视频等元素进行版面排布设计。

界面导航设计：

• 交互设计：

• 界面交互设计：

看PPT嗷！！！