UESTC软件系统架构

软件系统架构课程学习

第一章：系统分析与设计概述

1.1 什么是信息系统

• 信息系统：对于业务进行采集，转换，加工，计算，分析，传输，维护等信息处理，并能就某个方面问题给用户提供信息服务的计算机应用系统。

• 信息系统组成：

  • 信息化基础设施
  • 应用软件
  • 数据库系统
  • 业务数据
  • 客户端

• 信息系统类型：

  1. 业务处理系统：TPS（Transaction Process System），运用IT技术对于机构 业务活动 进行信息处理嗷！！！

  

  2. 信息管理系统：MIS（Manage Information System），以机构 信息管理 作为主导。

  

  3. 支持决策系统：DSS（Decision Support System），为解决特定策略提供 决策支持 的信息系统。

  

  4. 专家系统：ES（Expert System），获取，存储与利用 专家智慧解决某类问题 的信息系统

  

  5. 办公自动化系统：OA（Office Automation），实现办公业务流程自动化。

  

  6. 知识工作支持系统：KWS（Knowledge Work System），为知识工作者提供设计创造，技术创新等服务的信息系统

  

• 信息系统利益相关者：

  • 客户：系统拥有者
  • 用户：系统使用者或服务对象
  • 开发团队：系统构建者

• 信息系统用户：

  • 内部用户：
    • 业务人员
    • 经理等
  • 外部用户：
    • 客户
    • 供应商
    • 合作伙伴

• 信息系统开发人员：

  • 开发人员：
    • 系统分析人员
    • 系统设计人员
    • 系统构造人员
    • 系统测试人员
    • 质量保证人员
  • 管理人员：
    • 项目经理
    • 客户经理

1. 项目经理：

   • 项目计划
   • 项目组织
   • 项目领导
   • 项目控制

2. 系统分析师：

   • 对于机构业务进行调查和分析，利用信息系统分析技术解决问题。
   • 负责信息系统的需求调研，需求分析，需求管理，完成《系统需求规格说明书》
   • 对于信息系统进行业务需求建模，系统需求建模，讲建模成果转化到《系统需求规格说明书》

   

3. 系统架构师：

   • 系统项目的总体设计师
   • 负责对于整个系统架构，关键构建，接口的设计，完成《系统概要设计说明书》

4. 软件工程师：

   • 编写《系统详细设计说明书》

   • 负责对于系统功能模块的软件设计和实施。

5. 界面工程师：

   • 功能界面设计，色彩调配等

6. 数据库管理员：

   • 数据库建模
   • 根据数据库建模结果，创建数据库的LDM和PDM

7. 测试经理：

   • 按照项目经理制定的系统质量计划要求，编写测试计划和测试方案。
   • 协调接口，完成项目系统测试。

8. 测试工程师

   • 编写测试用例，进行测试工作

9. 实施经理

   • 协调资源，完成相关工作，监控检查工作进展，编写验收测试报告等。

10. 产品经理

    • 负责推广的软件产品进行策划和管理
    • 对于所负责的产品进行市场调研和分析，提出相应对策。
    • 负责对外宣传和推广，开拓市场，提高品牌知名度等。

11. 客户经理

    • 策划并且独立完成客户的拜访和沟通
    • Py客户，参与产品定位研讨

• 配合 is very important

1.2 信息系统软件

• 软件类型：

  • 应用软件
  • 支撑软件（中间件）
  • 系统软件

• 其他分类：

  • 开发方式分类：
    • 通用
    • 定制
  • 授权许可分类：
    • 产品软件
    • 自由软件
    • 免费软件等

• 软件特性：

  • 不会损耗，但会过时
  • 脑力劳动开发

• 开发软件的问题：

  • 复杂性 - 应用场景千差万别
  • 一致性 - 软件要求运行平台软硬件一致
  • 可变性 - 版本省级等

• 开发任务：确保本质问题不会失去控制

• 成功三要素：

  • 利益相关者
  • 软件过程
  • 软件建模

• 软件质量属性：

  • 一堆：功能性，可靠性，易用性等等等等orz
  • ISO建议：
    • 高层：软件质量需求评价准则
    • 中层：软件质量设计评价准则
    • 底层：软件质量度量贫家准则

1.3 信息系统开发过程

1.3.1 信息系统生命周期

• 三大步：
  1. 系统规划
  2. 系统开发
  3. 系统运行和维护

• 系统项目过程：
  • 以工程项目方式来管理信息系统的开发过程，支持过程，组织过程，运行过程等流程活动
• 系统开发过程框架：
  • 组织活动和公共过程框架以及流程模式

1.4 系统开发过程模型

1. 瀑布开发过程模型：

• 按照生命周期阶段线性顺序开展
• 每个阶段都会创建和提交大量文档
• 特点：简单，难以获得用户完整需求，前期的bug后期裂开。
• 应用场景：需求十分明确，需求较小

2. 原型开发模型：

• 解决需求变更的快速响应问题。
• 含有：探索式原型开发，抛弃式原型开发
• 特点：牛啊！快速开发迭代，但是同时，稳定性会收到挑战。难以标记里程碑，项目管理复杂。
• 应用场景：较多人机交互界面的项目，适合于需求初期不太明确的系统项目。

3. 螺旋式开发：

• 进化迭代，原型开发特征+瀑布开发过程的系统化，每一轮都是一个小瀑布。
• 映入了风险分析，且由内到外进行若干次迭代，直到开发处满足需求的版本。

第三章：系统规划

3.1 系统规划概述：

• 什么是系统规划？
  • 为支撑组织机构未来发展提供 信息系统建设方案与计划

• 系统规划意义：

项目成本估算：

• 完成项目工作所需要的费用估计

项目成本估算方法：

1. 类比估算法：利用历史信息和专家判断进行估计
2. 自底向上估算方法：最小任务活动市场成本，计算整体
3. 德尔菲法：多个领域专家，最终达成一致性结果

• 立项前进行估算

项目成本预算：

• 项目开始做的时候，才细分下来预算嗷！！！

• 项目估算成功在各具体的任务活动上进行经费分配的过程

3.1 项目可行性研究：

• 可行性研究

• 技术可行性分析：

• 评估项目解决方案所采用 技术方案的可行性和合理性

• 进度可行性分析：

  • 时间长度的合理性和可行性

• 经济可行性分析：

  • 投资回报率分析
  • 从项目成本角度考虑，项目成本和投资收益合理吗？

• 社会可行性分析：

  • 信息系统建设的可行性和合规性，评估信息系统建设的可操作性。
  • 法律，法规等

• 可行性分析报告：

  • 可行性研究报告给出了可行性研究结论，为组织机构提供科学依据，进一步开展工作的基础。

  

  我们写报告一样的，需要突出我们的可行性和需求嗷！！！

第四章：系统需求分析

• 需求不是一成不变的，需求的变更需要我们严格的分析。

4.1 需求采集：

• 系统开发的最少技术阶段。需要社交，沟通等技巧。同时交付一个用户需求的定义。

• 需求采集方法：

• 具体如下：

1. 研究现有文档和系统：

   1. 开发目标软件系统之前，一会有一些订单等数据。这些文档和系统资料真实反映了组织业务过程中数据表现与流转的机制。

   2. 组织结构图：

      

   3. 组织的规划和宏观决策相关文档：

      

   4. 工作规范文档

      

   5. 业务单据

      

   6. 报表

      

   7. 描述问题的文档

      

   8. 组织业务相关的专业知识

      

   9. 现存相关软件系统

      

2. 与客户以及相关人员进行面谈：

• 概念：面谈是指需求调查分析人员与客户以及项目相关人员进行面对面的谈话。

  • 访谈对象的多样性：
    1. 客户：周期，预算，质量要求，预期收益
    2. 用户：功能需求，非功能需求
    3. 领域专家：领域知识
    4. 客户的上下游合作伙伴：对系统的合作期望

• 面谈形式：

  • 正式面谈
  • 非正式面谈

• 优缺点：

  • 优点：深入了解面谈者对于问题的看法和回答，动态地调整面谈内容。
  • 缺点：不一定能及时安排，而且需要书面确认，导致过程延长。
  3. 调查表法：
  • 传统方法：纸质文档，人工填写，成本高，难以异地。
  • 新型渠道方法：网页，H5页面，电子邮件，即时通信软件等。

• 问题分类：

  • 封闭式问题（有备选答案）
  • 开放式问题（没有备选答案）
  4. 观察法：

• 旁观式观察：观察特定的业务活动，不打扰。条件允许还可以拍摄，便于回访分析。

  • 解释式观察：不仅观察，还可以得到业务人员解释，说明所做业务的要素和关键点。
  • 参与式观察：参与业务活动，成为一份子，承担业务功能，三种观察中最深入的一种！！！
  • 观察法特点：
    • 时间多样性
    • 地点多样性
    • 观察人员多样性

5. 头脑风暴

• 自由思考，自由讨论。对于一个观点共同讨论，高强度的思想碰撞。
• 会议要求：
  • 特定讨论主题
  • 主持人
  • 人数限制
  • 有限时间
  • 消极旁观打咩
  • 私下议论打咩
  • 相互尊重
  • 开门见山，不要客套等
• 风暴问题：
  • 输入输出数据是啥等
  • 安全风险是啥等
  • 接口关系等
• 优点：
  • 没有拘束的规则，人们更加能够自由思考。
  • 对一个观点共同讨论
  • 高强度的思想碰撞。

6. 原型法

• 概念：构建原型进行可视化模拟，获得用户对于需求反馈的方法。

• 主要目的：明确需求嗷！！！

• 现代且广泛采用的需求采集和确定的方法

• 本质：一个演示系统

• 使用场景：用户无法准确描述需求。

• 原型需求采集法是基于原型的软件工程过程模型的一部分。

• 不适用于难以界面模拟，存在大量运算和逻辑性强的系统。

• 分类：

  • 丢弃型原型
  • 进化型原型

7. 快速应用开发（RAD）

• 快速生成系统的开发方法，也是一种 需求抽取方法。

• 目标是快速交付系统解决方案

• RAD融合了进化型原型和头脑风暴。

• 结合了五个方面的技术：

  1. 进化原型
  2. CASE工具
  3. 拥有能够使用先进工具的专门人员
  4. 交互式联合应用开发活动（头脑风暴）
  5. 项目进度表，时间盒的项目管理方法

• 不足：

  • 需要人力多，投入精力多。
  • 很短的时间内需要一系列的需求分析，开发和客户任何一边出了问题就会导致RAD项目失败。
  • 不适合技术风险很高的情况。
  • 可能产生难以维护和拓展的软件。

4.2 需求可视化建模：

• 业务流程图建模，用例图建模，活动图建模，类图建模

4.2.1 业务流程建模：

• 可以使用BPMN，或者是UML

• 三种业务流程：

  • 普通流程（Process）
  • 合作流程（Collaboration Process）
  • 编排流程（Choreography Process或者Choreography）

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

普通流程建模：

• 私有业务流程建立某个特定组织内部的流程，被称为工作流或者业务流程。
  • 不可执行的私有业务流程：不要求自动执行，用于业务流程描述和文档化的流程。
  • 可执行的私有业务流程：可以根据语义定义而自动执行的流程。一个私有流程必须限制在一个泳池之内。
• 公开业务流程：一个私有业务流程与其他流程或参与者之间的交互，向外部世界显示交互的信息以及信息之间的次序。
  • 私有业务流程和其他流程或参与者之间的交互。
  • 仅仅包含这些参与活动和活动之间的次序，不显示其他非交互的活动。
  • 向外部世界显示 交互的信息 以及 *消息之间的次序

合作流程建模：

• 合作指的是组织中两个参与者在业务流程中的合作。

• 两个泳池之间通过消息流是表示两个相应参与者之间交换的消息。
• 合作流程中的泳池可以是空泳池，泳池之间的消息流连接在泳池边界上。
• 把信息流直接加入到泳池中，消息流直接连接在流程活动上，也可以的嗷！！！

• 也可以使用对话来表示一组具有顺序逻辑关联的交互消息。

编排流程建模：

• 也是描述多个参与者的交互，强调交互，取消掉了池的概念，由编排活动直接表现多个参与者之间的消息交互，提供了一种基于流程图的视图。

• 没有阴影的参与者的是交互的发起者，其他的都是参与者。

• 这个是从交互的角度来建模，上面两个是从活动的角度来建模。
• 分为：
  • 合作图
  • 编排图

4.2.2 用例图建模（功能建模）：

• 用例图以及其构成：

  • 参与者，用例和他们之间的关系构成的用于描述系统功能的图称为用例图。
  • 用例模型由若干用例组成。
  • 描述系统 功能性需求 的方法，是对于系统功能需求的建模。

• 用例图构成：

  • 参与者
  • 用例
  • 关系

• 可选元素：

  • 系统边界
  • 包
  • 注释

• 建模角度：

  • 功能
  • 数据
  • 行为

• 功能一般就是使用用例图进行建模的嗷！！！

参与者：

• 系统外部与系统直接交互的人或事务
• 角色不是具体的人，代表了扮演的角色。
• 参与者作为外部用户与系统发生交互作用
• 典型三类参与者：
  1. 人
  2. 外部系统
  3. 设备

用例：

• 外部可见的一个系统功能单元
• 用例名称通常使用动词短语或者动名词组
• 系统功能由系统单元提供，通过一系列功能系统单元与一个或多个参与者之间交换的信息所表达。
• 任何用例都不能够在缺少参与者的情况下独立存在。
• 发现用例的方法：
  1. 从参与者角度：
     • 根据参与者的职责要求，参与者完成了什么任务？
     • 参与者任务怎么触发呢？
     • 需要多个参与者的配合吗？
     • 参与者需要完成多个任务如何进行拆解和合并，映射到不同的系统功能。
  2. 从系统功能角度：
     • 需求采集文档描述了若干系统应该实现的功能。功能是否能够被用例覆盖？
     • 有些功能容易被忽略，系统自动执行的，例如备份等，参与者不明显嗷！！！
• 箭头加不加都行，箭头指向代表参与者使用某个用例的功能嗷！！！
• 用例之间的关系：
  1. 泛化关系：若干拓展用例以不同的方式实现了基用例，这个就是泛化关系
     • 例如：支付，微信支付，支付宝支付嗷！！！
  2. 包含关系：基用例执行过程中，一定要执行其中的包含用例，这个就是包含关系
     • 具有共同行为，多个行为都要做的事情，本质上是一种复用嗷！！！
     • 用例功能过多，我们对于用例中的具体功能进行拆解。达到简化描述的目的。
  3. 扩展关系：基用例执行过程中，其中的某个用例在某些条件下才会执行，不是一定会执行嗷！！！
     • 注意是反过来的嗷，拓展用例指向基用例。拓展用例的执行会改变基用例的行为。
• 用例规约：
  • 对于每一个用例进行详细的描述，用例规约应该包含以下内容：
    • 简要描述
    • 参与者
    • 事件流
    • 前置条件
    • 后置条件
    • 补充说明

4.2.3 活动图建模（行为建模）：

• 用于描述系统行为的模型图，可以用来描述过程（业务过程，工作流，事件流等）中的活动以及其迁移。
• 一个活动图对应一个过程。通常一个活动就对应一个过程，一般可以为一个用例画一个活动图，表示用例的详细执行过程。
• 用例+其对应的活动图，就十分完整了嗷！！！
• 过程：
  1. 建立用例模型
  2. 对于用例模型进行用例规约
  3. 对于用例画出活动图
• 但凡是要描述过程，就可以使用活动图嗷！！！
• 动作和活动：
  • 动作具有原子性，不可以被进一步分解，一旦开始执行，这个动作就需要被完成嗷！！！
  • 活动则不具有原子性，活动状态可以有入口动作，出口动作，内部活动，内部转换。
• 三种常见的控制流：
  1. 顺序控制流（顺序行为建模）：
     • 触发条件不能省略，默认就是上一个活动结束进行下一个活动。
     • 如果有触发条件，触发条件 & 上一个活动结束才能够进入下一个活动嗷！！！
  2. 分支控制流（条件行为建模）：
     • 分支与合并
     • 监控条件（最好是加到括号里面去嗷！！！）的是否满足嗷！！！
  3. 并发控制流（并发行为建模）：
     • 分叉和回合：一个控制流变成多个并发的控制流或者反过来
     • 也被称为同步嗷！！！

组合活动：

• 简单活动：不包含内嵌活动或者动作

• 组合活动：嵌套了若干活动或者动作

• 组合活动不具有原子性，可以在执行中被中断

• 可以体现层次感嗷！！！

泳道：

• 将活动划分为不同的道，每一条道代表不同的活动者。

• 泳道图（带泳道的活动图），并且比普通的活动图表达的信息更多嗷！！！可以把类的行为给找出来嗷！！！

• 假如我们有建模输入输出的需求，我们还可以对于数据流状态进行建模哦，这里不讲了嗷！！！

4.2.4 类图建模（数据建模）：

• 类和类之间的关系：

  • 关联：虚线
  • 依赖：视线
  • 泛化
  • 实现

• 接口使用🍭表示法比较fashion嗷！！！

• 类图建模的方面：

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

• 类名：

  • 见名知意
  • 类名通常是名词，首字母大写。

• 类属性：

  • 名词或名词短语

  • 第一个首字母小写，其他单词首字母大写

  • 可以有多个属性也可以没有属性

  • [可见性] 属性名称: [属性类型] [=初始值]

  • 分类：

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

• 发现类的操作：

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

• 识别类的方法：

  • 名词短语法：
    • 需求描述中抽取出名词短语
    • 可以分为三类：
      • 相关类
      • 无关类
      • 模糊类
  • 公共类模式法
  • 用例驱动法
  • CRC法

• 发现关联：

  • 关联名
  • 关联关系：
    • 类可以与自身关联。
    • 当一个类关联到本身时，不是类的实例与本身关联，而是类的一个实例与类的另外一个实例关联。
  • 关联关系之间的

类与类之间的关系：

• 聚合关系：

  • 菱形在大头的那一边嗷！！！

• 泛化关系：

  • 继承

4.3 需求文档化

4.4 需求管理

需求依赖矩阵

需求变更

第五章：系统架构设计

5.1 系统设计概述

1. 基础信息平台设计
   • 系统设计是指在系统需求分析的基础上，设计出能够满足系统需求目标的新系统的构造方案的活动
2. 系统架构设计
   • 这里补上
3. 系统界面设计
   • 这里补上
4. 系统数据库设计
   • 数据库结构
5. 系统构件设计
   • 构件功能逻辑，构件接口

• 系统设计方法：
  • 抽象化：在系统规模大，逻辑复杂的情况下，通过抽象实现系统设计建模，降低系统设计复杂性的基本策略。
  • 逐步求精：把问题的求解分解为若干步骤或阶段，抽象使得设计者能够描述过程和数据而忽略低层的细节。
  • 模块化：把一个大系统按照特定规则，划分为若干较小的，又相互关联的部件，把复杂问题简单化。
  • 信息隐藏：
  • 模块独立：便于功能被划分，更易于开发和维护。一般可以由两项指标来衡量：内聚性和耦合性。

5.2 系统架构基础

• 系统架构是指系统组成的结构模式，它由反应系统部件组成的关联性，交互性和约束机制进行描述。
• 系统架构类型：
  1. 系统总体架构
  2. 系统架构模式：
     • 应用架构
     • 软件架构

5.3 软件架构风格

5.3.1

5.3.2 软件机构风格应用

5.3.3 软件架构风格要素

5.3.4 软件架构风格分类

5.3.5 分层体系结构

5.3.6 数据共享体系架构

5.4 软件架构模式

5.5 软件架构UML建模设计

第六章：软件模块详细设计

6.1 软件建模设计概述：

6.1.1 软件建模设计的目标：

• 详细设计对于系统各种的每个构件进行详细建模描述。
• 软件详细建模设计在分析模型和架构模型上，对于系统中的构件的内部工作进行建模描述，为每个构件设计完整的数据结构，处理逻辑，接口和通信机制。
• 构件包括一组协作的类或者构件。
• 好的构件设计：
  • 满足分析模型中的所有明确要求。
  • 满足客户期望的所有隐含要求。
  • 必须对于编码人员，测试人员和维护人员是可读可理解的。
  • 应提供软件的完整视图，从实现的角度解决数据，功能和行为等各方面的问题。

6.1.2 软件设计的原则：

• 设计在发生变更的时能够适应变更并且减少副作用的传播，构件级设计应该遵循设计的基本原则：

1. 开闭原则（OCP）：对于拓展具有开放性，对于修改具有封闭性：
   • 对于构件的拓展不需要改变原来构件的代码，内部的封闭性无法保证。
   • 常见情况：使用Interface，Interface不需要进行改变，但是接口的实现可以动态拓展嗷！！！
2. 里氏替换原则（LSP）：子类可以替换它们的基类：
   • 从基类导出的子类传递给该基类的其他构件的时候，使用该基类的构件仍然能够正常工作。
   • 要求：基类的子类必须遵循基类与使用该基类的构件之间的隐含约定。
3. 依赖倒置原则（DIP）：依赖于抽象，而非具体实现
   • 抽象比较容易对于设计进行拓展
4. 接口分离原则（ISP）：多个客户专用接口比一个通用接口要好
   • 提供者构件应该为每个主要的客户构件类型提供一个特定的接口
   • 只有和特定客户构件类型相关的操作才会出现在该接口中
5. 内聚性：构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作
   • 内聚性分为：
     • 功能内聚：所有元素配合完成同一个功能。
     • 分层内聚：高层访问低层，低层不能访问高层。
     • 通信内聚：模块内的所有元素都访问相同的数据。用于数据的查询，访问和存储。
   • 从上往下，强度由强到弱。
   • 内聚性越强，越容易实现，测试和维护。
6. 耦合性：指不同对象之间相互关联的程度
   • 构件设计要尽可能保持低耦合
   • 通过类的公共系统实现耦合
7. 可重用性：尽量使用已有的类
   • 确实需要构件新类的时候，在这几这些新类的时候考虑将来的可重用性。

6.1.3 软件建模设计内容：

• 软件静态交互建模：

• 软件动态交互建模：

  • 展现对象之间的交互和协作
  • 使用顺序图或者通信图建模并细化对象之间的交互

• 软件状态机建模：

  • 通常一个状态机依附于一个类。

6.1.4 软件建模设计活动：

6.2 UML软件静态结构视图建模：

6.2.1 软件静态结构视图

• 主要使用 类图 来表示
• 类：
  • 对于一组具有相同属性，操作，关系和语义的对象的描述。
  • 常见的分类包括：
    • 实体类
    • 边界类
    • 控制类
  • 类建模不是一个确定的过程，是 高度迭代增量式