软件工程5-系统设计概述
系统设计概述
概述
软件设计：软件系统或组件的架构，构件，接口和其他特性的定义过程以及过程的结果
- 软件工程生命周期的一个活动
- 进行软件编码的基础
- 需求分析被转化成软件的内部结构
- 是连接用户需求和软件技术的桥梁
设计工程的活动包括以下：
- 顶层设计（架构设计）：描述软件的顶层架构和组织，划分不同的组件
- 详细设计：描述各个组件以便编码实现
软件设计主要为分解设计（将软甲映射为各个组件），可以包括系列模式设计
设计过程和质量
好的设计特点
- 设计必须实现在分析模型中包含的所有明确要求，必须满足客户所期望的所有隐含要求；
- 设计必须对编码人员、测试人员及后续的维护人员是可读可理解的；
- 设计应提供该软件的完整视图，从实现的角度解决数据、功能及行为等各领域方面的问题
设计指导原则
- 设计应该是一种架构
- 设计应该是模块化的
- 设计应该包含数据、体系结构、接口和组件各个方面
- 应该设计出系统所用的数据结构
- 应该设计出展现独立功能特性的各组件
- 应该设计出各组件与外部环境连接的各接口
- 设计由软件需求分析过程中获得信息驱动，采用可重复使用的方法导出
- 设计应该采用正确清楚的表示法
设计质量属性
- 功能性
- 易用性
- 可靠性
- 性能
- 可支持性：扩展性，适应性，可维护性
设计模型
模型输入：软件需求的数据模型，功能模型和行为模型
分类：数据设计，架构设计，接口设计，组件设计
分析模型到设计模型的转化
抽象
含义：忽略具体的信息，将不同事物看作相同事物的过程
抽象机制：参数化，规范化
规范化抽象：
- 数据抽象：描述数据对象的冠名数据集合
- 过程抽象：具有明确和有限功能的指令序列
体系结构
定义：软件整体结构和这种结构为系统提供概念上完整性的方式，可以通过以下模型表达
- 结构模型
- 框架模型
- 动态模型
- 过程模型
- 功能模型
设计模式
在给定上下文环境中一类共同问题的共同解决方案
微观结构：
- 实体模式
- 结构模式
- 行为模式
例如抽象工厂：提供一个创建一系列相关或仙湖依赖对象的接口，而无需制定他们具体的类
模块化
含义：软件被划分命名和功能相对对的多个组件，通过这些组件的集成来满足问题的需求
软件模块性：程序可悲之能管理的单一属性
模块化的理论依据：基于人类解决问题的观测数据
模块化的设计标准：
- 分解性：可分解为子问题
- 组合性：组装成可重用的组件
- 可理解性：可作为独立单元理解
- 连续性：需求小变化只影响单个模块
- 保护：模块内异常只影响自身
模块化和软件成本存在最小代价区间
信息隐藏
原则：模块应该具有彼此相互隐藏的特性，模块定义和设计时应当保证模块内信息不可以被不需要这些信息的模块访问
特点：抽象有助于定义构成软件的过程实体，信息隐藏原则定义和隐藏了模块内的过程细节和模块内的本地数据结构；
功能独立
含义：每个模块只负责特定的子功能，并且从程序结构的其他部分看，该模块具有简单的接口
好处：易于开发和维护
标准：模块独立性强=高内聚低耦合
- 内聚性：模块的功能相对强度
- 耦合性：模块之间的依赖程度
精化
含义：逐步求精的过程
与抽象的关系：抽象使设计使设计师确定过程和数据，精化有主语设计者在设计过程中揭示底层细节
重构
含义：不改变组件功能和行为条件下，简化组件设计的一种重组技术
方法：检查现有设计的冗余情况，未使用的设计元素，无效的算法，较差的构件方式或不恰当的数据结构，或者任何其他可优化设计的问题
设计技术
数据设计
含义：数据设计构建高层抽象的数据模型和信息模型
概念：
- 数据建模：数据字典，ER图，类图
- 数据结构：计算机存储和组织数据的方式
- 数据库：按照数据结构来组织，存储和管理数据的仓库
- 数据仓库
数据设计原则：
- 应用于功能和行为系统分析的原则也应适用于数据设计
- 所有的数据结构及其对应的操作都应该确定
- 建立数据字典并在数据定义和程序设计中应用
- 低层次的数据设计应该推迟到设计的后期过程
- 数据结构的表示应该只对直接使用数据结构中数据的模块可见
- 开发有用的数据结构及其对应操作的程序库
- 软件设计和编程语言应该支持抽象数据类型的定义与实现
概念数据模型
ER模型，描述实体，联系和属性；
物理数据模型
类图
体系结构设计
含义
- 系统需要执行的函数功能组件集（如数据库、计算模块）
- 组件之间通信、协同和合作的连接器
- 组件集成构成系统的约束
- 设计人员通过分析系统组成部分的已知特性，理解其整体特性的语义模型分析
风格和模式
数据中心架构
数据流系统架构
调用和返回架构
面向对象架构
层次架构
界面设计
原则
- 允许用户操作控制
- 减少用户记忆负担
- 保持界面一致
部署设计
含义
- 以部署环境创建开始，在整个生命周期阶段中处于逻辑设计和技术需求阶段
- 部署环境包含整个解决方案的逻辑架构和服务质量（QoS）需求
- 部署架构设计是一个反复迭代的过程，通常需要多次查看QoS要求和多次检查先前的设计，需要考虑了服务质量QoS需求的相互关系，平衡取舍相关问题成本以实现最佳解决方案，最终满足项目的业务目标
输出 - 部署架构
- 实施规范
- 实施计划：迁移计划，安装计划，用户管理计划，测试计划，滚动淘汰计划，灾难恢复计划，操作计划（运行书），培训计划
部署设计方法： - 一般方法：估计处理器需求，估计安全传输的处理器需求，可用性和可拓展性的备份服务
- 设计分析：识别瓶颈，优化资源，管理风险