【SE赋能培训系列】【纪要】003期软件设计

pkyy_xp

已于 2024-01-09 10:17:48 修改

阅读量259

点赞数

文章标签：职场和发展课程设计笔记

于 2023-05-08 19:41:01 首次发布

本文链接：https://blog.csdn.net/pkyy_xp/article/details/130565636

版权

1、关于软件设计

1.1 软件设计所处的位置

1.1.1 软件设计之前是需求分析，需求分析给出产品的业务模型；软件设计给出产品的计算模型；软件设计之后是编码实现
1.1.2 软件设计是需求到实现的中间环节，负责业务和技术的融合
1.1.3 软件设计是软件质量保证的重要环节，设计不好软件质量肯定不行

1.2 软件设计经验总结

1.2.1 深入理解需求场景
1.2.2 充分讨论：广泛听取各方意见，大声建模，一起讨论，串讲和反串讲
1.2.3 充分参考已有的成功方案、历史问题
1.2.4 在动手实现之前验证设计方案的正确性

2、架构设计方法

2.1 架构设计经典4+1视图

2.1.1 Scenarios：用户视图，关注用户需求功能场景
2.1.2 Logic View：逻辑视图，关注用户可见的功能以及一些必需的 “辅助功能模块”，它们可能是逻辑层、功能模块、数据模型等。
2.1.3 Development View：开发视图，关注开发环境的程序包：源程序、通用组件（CBB）、编译环境、第三方组件、框架容器等。
2.1.4 Process View：运行视图，关注程序运行起来之后的对象：状态、线程、进程、消息队列、数据流转等。
2.1.5 Physical View：物理视图，关注目标程序的静态位置：部署的服务器、硬件依赖、网络拓扑、网口等。

2.2 架构设计要点

2.2.1 0层设计，关注系统和外界的交互
2.2.2 1层设计，关注系统内部子系统和模块的划分、数据接口、依赖关系和数据流转过程
2.2.3 关键技术选型，找出关键的高风险、高难度的技术点，做预研和方案选型，确保架构方案合理可行

2.3 架构设计方法

2.3.1 划清系统范围
2.3.1.1 把系统作为一个整体看待
2.3.1.2 架构设计首先要明确需求范围，除了要明确需要做什么，更需要明确不做什么
2.3.1.3 需要充分了解项目背景，做好假设，明确约束
2.3.2 纵向分层
2.3.2.1 减少耦合：保证架构清晰且易于扩展
2.3.2.2 保证单向依赖：上层调用/依赖下层
2.3.2.3 网络设备典型分层设计：管理面、控制面、转发面三面隔离
2.3.2.4 应用系统典型分层设计：MVC/ 展示层、业务层、数据层

2.3.2.5 TCP/IP 四层网络模型

2.3.3 横向隔离
2.3.3.1 基于业务拆分封装子系统或业务模块，模块内高内聚
2.3.3.2 不同业务子系统或模块互相隔离，明确接口，模块间松耦合
2.3.3.3 注意提取公共业务进行独立封装

3、特性设计方法

3.1 特性设计和概要设计的概念对比

3.1.1 概要设计更宽泛，将一个复杂系统按功能进行模块划分、确定模块的层次结构、调用关系、接口和数据结构等
3.1.2 特性设计更具体，针对用户可感知的某功能特性进行概要设计，一般基于1个成熟的平台或产品，在已有子系统或模块的基础上增加功能点，完成完整的功能特性
3.1.3 具体实践中使用概要设计模版进行设计

3.2 概要/特性设计目标

3.2.1 概要设计阶段，需要从客户价值视角（关注价值体现和问题分解）切换到组织开发和构建系统的视角（强调逻辑框架）
3.2.2 功能需要分解到模块
3.2.3 流程需要分解到算法

3.3 概要/特性设计的前提

3.3.1 概念统一：包括在设计开发的各个阶段，对于概念的统一，对于需求功能术语的命名应该统一；也包括在各个产品间对于同1个需求功能术语的命名应该统一
3.3.2 需求明确：在架构设计阶段就需要明确需求范围
3.3.3 理解特性在系统中的位置
3.3.3.1 理解本特性在全局架构所处的位置
3.3.3.2 理解本特性和其他业务特性的相关性
3.3.3.3 理解本特性对架构分层的依赖性

3.4 概要/特性设计方法

3.4.1 模块和接口

3.4.1.1 基于业务功能划分模块，提取公共功能、基础功能成为独立模块，每一个模块设计时就要考虑公用
3.4.1.2 分析接口和依赖关系，确定接口内容、格式、调用方式、消息序列和数据流转方向。首选无状态设计（接口之间无依赖），描述清楚状态和依赖关系
3.4.1.3 接口体现功能、面向接口编程。接口越少越好、参数越少越好、参数传值优先——减少模块间耦合
3.4.1.4 不好的例子
3.4.1.4.1 Syslog信息的拼装发送散布在各个模块内，遇到定制日志的需求，需要修改各个模块的日志生成和发送代码
3.4.1.4.2 策略接口和日志接口使用同一个连接，日志风暴时导致策略无法下发，心跳丢失导致设备离线

3.4.2 数据处理

3.4.2.1 基于业务流分析数据流和状态转换
3.4.2.2 利用成熟的处理模型：生产者消费者模型、多线程并发处理、异步同步机制、批量处理机制、多级缓存机制、有限状态机模型
3.4.2.3 注意事项：数据总量控制、删除机制，数据处理能闭环、不死循环；大数据必须考虑分级汇总统计机制，比如原始数据、5分钟汇总、小时汇总、天汇总
3.4.2.4 不好的例子
3.4.2.4.1 首页的总日志量、总告警数直接从原始ES索引查询，大数据量时界面卡死
3.4.2.4.2 分页查询时，界面仅需要展示1页，仍从所有数据中进行查询，大数据量时界面卡死
3.4.2.4.3 策略管理缺少状态划分，配置完不知道策略是否下发成功、成功多少

3.4.3 数据结构

3.4.3.1 识别数据唯一标识，明确重复数据判别条件
3.4.3.2 识别关键字段建立数据索引，考虑关联查询
3.4.3.3 根据数据量、增长频率和数据操作场景，确定存储方式（内存/数据库/数据文件，分区分表分文件）
3.4.3.4 不好的例子
3.4.3.4.1 数据库存储索引分区不合理，导致长期运行后随着数据量越来越大，系统性能越来越差

3.4.4 DFX-可扩展性（产品交付后增加/修改功能或性能）

3.4.4.1 功能扩展：增加新功能，或者功能修改
3.4.4.1.1 分层设计、层次清晰
3.4.4.1.2 业务建模、功能独立
3.4.4.1.3 隔离变化、适应变化
3.4.4.2 性能扩展：提高并发量、吞吐量，缩短响应时间
3.4.4.2.1 多线程、多进程
3.4.4.2.2 分布式
3.4.4.2.3 无状态

3.4.5 DFX-可靠性（产品稳定运行，不出问题，出问题能及时恢复）

3.4.5.1 校验 & 容错
3.4.5.1.1 外部数据都需要做严格的后台校验，再进入处理逻辑，避免各种注入、畸形数据破坏系统
3.4.5.1.2 对错误做隔离，避免错误扩散影响整个系统
3.4.5.2 限制使用：各个用户或模块都有自己的资源使用限制（CPU、内存、硬盘、文件数、连接数…），防止滥用影响其他业务
3.4.5.3 冗余设计：关键组件（硬件和软件）有冗余设计，避免单点故障
3.4.5.4 备份和恢复
3.4.5.4.1 支持自动或手动备份，故障发生后能及时恢复工作
3.4.5.4.2 支持自身监控，故障发生后能自动恢复

3.4.6 DFX-可维护性（产品使用时方便发现、定位和处理问题）

3.4.6.1 方便问题发现
3.4.6.1.1 界面实时多维度监控
3.4.6.1.2 后台发现问题及时告警
3.4.6.2 方便问题定位
3.4.6.2.1 后台日志记录各种异常
3.4.6.2.2 界面定位、获取日志
3.4.6.3 方便问题处理
3.4.6.3.1 通过配置修改、调优可规避
3.4.6.3.2 垃圾数据可清理
3.4.6.3.3 异常状态可恢复
3.4.6.3.4 自动化应急方案，比如bypass等
3.4.6.3.5 自动化和人工方案，人工优先