2023系统分析师---需求工程

一、需求工程

一、需求工程概述：

1. 需求开发活动：需求获取、需求分析、需求定义、需求验证
2. 需求管理活动：变更控制、版本控制、需求跟踪、需求状态跟踪

二、需求分类：

1. 需求的层次：

1. 1. 业务需求：是指反应企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，为以后的开发工作奠定了基础。
   2. 用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么
   3. 系统需求：是从系统的角度来说明软件的需求，包括功能需求，非功能需求和设计约束等。功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务要求。非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性和其他非功能需求。设计约束也称为限制条件或补充规约，通常是对系统的一些约束说明。

1. QFD

1. 1. 质量功能部署QFD是一种将用户要求转化为软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度，QFD将软件需求分为三类：

1. 1. 1. 常规需求（基本需求）：用户认为系统应该做到的功能或性能，实现越多用户会越满意。
      2. 期望需求：用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能的需求。如果期望需求没有得到实现，会让用户感到不满意
      3. 兴奋需求（意外需求）：是用户要求范围外的功能或性能，实现这些需求用户会更高兴，但不实现也不影响其购买的决策

1. PLECES框架：

1. 1. 性能（Preformance）：性能用于描述企业当前的运行效率，可以分析当前业务的处理速度；比如：响应时间、吞吐量
   2. 信息（Information）：信息和数据指标用于描述业务数据的输入、输出以及处理方面存在的各种问题；比如：无法捕获数据、数据不精确
   3. 经济（Economics）：经济指标主要从成本和收益的角度分析企业当前存在的问题；比如：订单数减少
   4. 控制（Control）：提高信息系统的安全和控制水平；比如：身份鉴别
   5. 效率（Efficiency）：提高企业的人、财、物等的使用效率；比如：浪费时间、材料、资源
   6. 服务（Service）：提高企业对客户、供应商、合作伙伴、顾客等的服务商的服务质量；比如：系统结果不准，使用困难，与其他系统不兼容等

三、需求开发---需求获取方法

1. 收集资料：把与系统

二、面向对象需求分析

一、面向对象的概念：

1. 1. 对象：属性（数据）+方法（操作）+对象Id

类（实体、控制、边界）

1. 实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息，例如，在线教育平台系统可以提取出学员类和课程类，他们都属于实体类。
2. 控制类是用于控制用例工作的类，一般是由动宾结构的短语（动词+名词或名词+动词）转化来名词，例如：用例：“身份验证”可以对应于一个控制类“身份验证器”，它提供了与身份验证相关的所有操作。
3. 边界类用于封装在用例内，外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有的窗体、报表、打印机和扫描等硬件的接口，以及与其他系统的接口
4. 继承与泛化：复用机制
5. 封装：隐藏对象的属性和实现细节，仅对外公开接口
6. 多态：不同对象收到同样的消息产生不同的结果
7. 接口：一种特殊的类，它只有方法定义没有实现
8. 重载：一个类可以有多个同名而参数类型不同的方法
9. 消息和消息通信：消息是异步通信的

二、UML图概念

1. 结构事务：最静态的部分：包括：类、接口、协作、用例、活动类、构件和节点
2. 行为事务：代表时间和空间上的动作，包括：消息、动作次序、连接
3. 分组事务：看成是合资，如：包、构件
4. 注释事务：UML模型的解释部分。描述、说明和标注模型的元素

三、UML图分类：

1. 类图（class diagram）：类图描述一组类、接口、协作和他们之间的关系
2. 对象图（object diagram）：对象图描述一组对象以及他们之间的关系。对象图描述了在类图中所建立的事物实例和静态快照。
3. 构件图（component diagram）：构件图描述了一个封装的类和他的接口、端口、以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体（一个封装的类和他的接口）
4. 部署图（deployment diagram）：部署图描述对运行时的处理节点以及其中生存的构件的配置。部署图给出了架构的静态部署视图。通常一个节点包含一个或 多个部署图（软、硬件之间的映射）
5. 制品图：系统的物理结构
6. 包图：由模型本身分解而成组织单元，以及他们之间的依赖关系
7. 组合结构图
8. 用例图：系统与外部参与者的交互。
9. 顺序图（sequence diagram，序列图）：顺序图是一种交互图（Interaction diagram），它强调对象之间消息发送的顺序，同时显示对象之间的交互。
10. 通信图（communication diagram）协作图，通信图是一种交互图，它强调收发消息的对象或参与者的结构组织。
11. 定时图：强调实际时间
12. 交互概览图
13. 状态图（state diagram）。状态图描述一个状态机，它由状态、转移、事件和活动组成，状态图给出了对象的动态实体图。它对接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这个非常有助于对反应式系统建模。状态转换变迁。
14. 活动图（activity diagram）：活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并且强调对象间的控制流程。类似程序流程图，活动图能够支持活动的并性行为。

四、UML图关系：

1. 用例关系包括：包含关系、扩展关系、泛化关系

1. 1. 包含关系：其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例；当可以从两个或两个以上的用例中提取出来公共行为时，应该使用包含关系来表示它们。
   2. 扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。
   3. 泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将他们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构，行为和关系。

1. 类图、对象图关系。

1. 1. 依赖关系：一个事物发生变化影响另一个事物。
   2. 泛化关系，特殊、一般关系
   3. 关联关系：描述了一组链，链是对象之间的连接
   4. 聚合关系，整体与部分生命周期不同
   5. 组合关系：整体与部分生命周期相同
   6. 实现关系：接口与类之间的关系

三、系统设计

一、结构化设计

1、功能模块设计的原则

模块大小适中：50---10行，最多不超过500行

适宜的系统深度和宽度比例，尽可能减少调度的深度

湿度控制模块的扇入扇出：扇出3--4，一般不超过7，扇入越大越好

单入口、单出口

模块的作用域应该在模块之内

功能应该是可预测的

高内聚低耦合

系统分解有层次

较小的数据冗余

2、模块独立性的度量

1. 聚合：衡量模块内部个元素结合的紧密程度

偶然聚合：模块完成的动作之间没有任何关系，或者仅仅是一种非常松散的关系

逻辑聚合：模块内部的各个组成在逻辑上具有相似的处理动作，但是功能用途上彼此无关

时间聚合：模块内部的各个组成部分所包含的处理动作必然在同一时间内执行

过程聚合：模块内部各个组成部分所要完成的动作虽然没有关系，但是必须按特定的次序执行

通信聚合：模块的各个组成部分所完成的动作都使用了同一个数据或产生同一个输出数据

顺序聚合：模块内部的各个部分，前一部分处理的动作的最后输出是后一部分处理动作的输入

功能聚合：模块的内部各个部分全部属于一个整体，并且执行了同一功能，且各个部分对实现该功能都必不可少。

1. 耦合：度量不同模块间互相依赖的程度

1. 1. 非直接耦合：两个模块之间没有直接关系，他们的联系完全是通过主模块的控制和调用来实现的
   2. 数据耦合：两个模块彼此间通过数据参数交换信息
   3. 标记耦合：一组模块通过参数表传递记录信息，这个记录是某一个数据结构的子结构，而不是简单的变量
   4. 控制耦合：两个模块彼此间传递的信息中有控制信息
   5. 外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表来传递该全局变量的信息。
   6. 公共耦合：两个模块之间通过一个公共的数据区域传递信息
   7. 内容耦合：一个模块需要涉及另一个模块内部信息

1. 模块的四个要素：

1. 1. 输入和输出：模块的输入来源和输出去向都是同一个调用者，即一个模块从调用者哪儿取得输入，进行加工后再把输出返回调用者。
   2. 处理功能：指模块把输入转换成输出所做的工作
   3. 内部数据：指仅供该模块本身引用的数据
   4. 程序代码：指用来实现模块功能的程序

3、系统结构图

系统结构图（Structure Chart，SC）又称为模块结构图，它是软件概要设计阶段的工具，反映的功能实现和模块之间的联系与通信，包括各个模块之间的层次结构，即反映了系统的总体结构。在系统分析阶段，系统分析师可以采用SA方法获取由DFD、数据字典和加工说明等组成的系统的逻辑模型；在系统设计阶段，系统设计师可以根据一些规则，从DFD中导出系统初始化的SC。常用的SC 主要有变换型，事务型和混合型三种。

SC包括模块、模块之间的调用关系、模块之间的通信和辅助控制符号等四个部分。

二、面向对象设计

1. 设计原则：

1. 1. 系统设计---面向对象设计---设计原则
   2. 单一职责原则：设计目的单一的类
   3. 开发--封闭原则：对扩展开放，对修改封闭
   4. 里式替换原则：子类可以替换父类
   5. 依赖倒置原则：要依赖于抽象，而不是具体的实现；针对接口编程，不要针对实现编程
   6. 接口隔离原则：使用多个专门的接口比使用单一的总接口摇号
   7. 组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
   8. 迪米特原则（最少知道原则）：一个对象应当对其他对象有尽可能少的了解

1. 设计模式：

1. 1. 概念：软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作所为的基本设计决策
   2. 设计模式：主要关注软件系统设计，与具体的实现语言无关
   3. 惯用法：是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法，例如引用计数就是c++语言中的一种惯用法。

1. 设计模式分类：

1. 1. 创建型：与对象的创建有关，抽象了实例化过程，它们帮助一个系统建立与如何创建、组合和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类，而一个对象创建型模式将实例化委托给另一个对象。

1. 1. 1. 工厂方法模式
      2. 抽象工厂方法模式
      3. 原型模式
      4. 单例模式
      5. 构建器模式

1. 1. 结构型模式处理类或对象的组合，结构型设计模式涉及如何组合类和对象以获得更大的结构，结构型模式采用继承机制来组合接口或实现。结构型对象模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合，从而实现新功能的一些方法

1. 1. 1. 适配器模式
      2. 桥接模式
      3. 组合模式
      4. 装饰模式
      5. 外观模式
      6. 享元模式
      7. 代理模式

1. 1. 行为型模式涉及算法和对象间职责的分配，行为型模式不仅描述对象或类的模式，还描述他们之间的通信模式，行为型模式使用继承机制在类间分配行为，这里包括模块类模式和解释器模式。行为对象模式使用对象复合而不是继承。一些行为对象模式模式了一组对等的对象怎样相互协作以完成其中任一对象都无法单独完成的任务；

1. 1. 1. 职责链模式
      2. 命令模式
      3. 解释器模式
      4. 迭代器模式
      5. 中介者模式
      6. 备忘录模式
      7. 观察者模式
      8. 状态模式
      9. 策略模式
      10. 模板方法模式
      11. 访问者模式

四、WEB开发

一、维度

1. 1. 从架构上来看：MVC、MVP、MVVM、REST、WebService、微服务
   2. 从并发分流：集群（负载均衡）、CDN
   3. 从缓存：MemCache、Redis、Squid
   4. 从数据：主从库（主从复制）、内存数据库、反规范化技术、NoSql、分区分表技术、视图与物化视图
   5. 从持久化来看：Hibernate，MyBatis
   6. 分布式存储：Hadoop、FastDFS、区块链
   7. 数据编码：XML、JSON
   8. Web应用服务器：Apache、WebSphere、Tomcat、Jboss、IIS
   9. 安全：Sql注入
   10. 其他：静态化、有状态无状态、响应式Web设计、中台

二、负载均衡

1. 1. 应用层负载均衡，

1. 1. 1. http重定向，HTTP重定向就是应用层的请求转发。用户的请求其实已经到了HTTP重定向负载均衡服务器，服务器根据算法要求重定向，用户收到重定向请求后，再次请求真正的集群。特点：部署简单，但是性能较差
      2. 反向代理服务器，用户的请求到达反向代理服务器时（已经到达网站机房），由反向代理服务器根据算法转发到具体的服务器。常用的apache、nginx都可以充当反向代理服务器；特点：部署简单，但是代理服务器可能成为性能的瓶颈。

1. 1. 传输层负载均衡；

1. 1. 1. DNS域名解析负载均衡，DNS域名解析负载均衡就是在用户请求DNS服务器，获取域名对应的IP地址，DNS服务器直接给出负载均衡后的服务器IP；
      2. 特点：效率比HTTP重定向高，减少维护负载均衡服务器成本，但是一个应用服务器故障，不能及时通知DNS，而且DNS负载均衡的控制权在域名服务商哪里，网站无法做更多的改善和更强大的管理
      3. 基于NAT的负载均衡，基于NAT的负载均衡将一个外部IP地址映射为多个IP地址，对每次连接请求动态转换为一个内部节点的地址。
      4. 特点：技术较为成熟，一般在网关位置，可以通过硬件实现。像四层交换机一般就采用这种技术。

1. 1. 硬件负载均衡：F5
   2. 软件负载均衡：LVS、Nginx、HAproxy
   3. 静态算法

1. 1. 1. 轮转算法：轮流将服务器请求调用给不同的节点（服务器）
      2. 加权轮转算法：考虑不同节点处理能力的差异
      3. 源地址哈希散列算法：根据请求的源IP地址，作为散列键从静态分配的散列表找出对应的节点
      4. 目标地址哈希散列算法：根据请求目标IP做散列找出对应节点
      5. 随机算法：随机分配、简单、但是不可控

1. 1. 动态算法（动态负载）

1. 1. 1. 最小连接数算法：每个节点处理能力相同的情况下，新请求分配给当前活动请求数量最少的节点
      2. 加权最小连接数算法：考虑节点处理能力不同，按最小连接数分配
      3. 加权百分比算法：考虑了节点的利用率、硬盘速率、进程个数等，使用利用率来表现剩余处理能力

1. 有状态和无状态问题：

1. 1. 无状态服务（stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次强强所需的全部信息，要么都包含在这个请求里面，要么可以从外部获取到（比如说数据库），服务器本身不存储任务信息。
   2. 有状态服务（stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的

1. CDN内容分发网络

1. 1. CND的全称是Content Delivery NetWork，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定

1. 持久化技术：ORM（Object Relational Mapping）：对象与关系数据之间的映射

1. 1. 类：数据库的表
   2. 对象：数据库里面的记录，行数据
   3. 对象的属性：字段

1. 缓存

1. 1. MemCache：是一个高性能的分布式的内存对象缓存系统，用于动态Web应用以减轻数据库负载。Memcache通过在内存里维护一个统一的巨大的Hash表，它能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。
   2. Redis：是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-value数据库，并且提供多种语言API
   3. 常见集群切片方式：

1. 1. 1. 客户端分片：在客户端通过Key的hash值对应到不同的服务器
      2. 中间件实现分片：在应用软件和Redis中间，例如Codis等，中间件实现服务到后台Redis节点的路由分派
      3. 客户端服务端协作分片：客户端与服务端协作完成分片处理

1. 1. 分布式存储方式

1. 1. 1. 主从模式（Master、Slave）模式：一主多从，故障时手动切换
      2. 哨兵模式（Sentinel）：有哨兵的一主多从，主节点故障自动选择新的主节点
      3. 集群模式（Cluster）：分节点对等集群，分slots，不同slots的信息存储到不同节点