大家好，我是讯享网，很高兴认识大家。

目录

一、结构化设计

二、面向对象设计

1. 面向对象设计概述

2. 系统设计

3. 包的设计

4. 对象设计

5. 面向对象设计总结

三、数据库设计

1. 数据库系统及关系数据库简介

2. 数据库逻辑模型设计

3. ERD模型及质量评估

4. 物理数据库的设计与建立

5. 物理数据库提高效率的方法

6. 描述分布式数据库的不同的体系结构模型

7. OO分析类图映射到ERD

四、用户界面设计

1. 用户界面设计的基本概念

2. 用户界面形式及设计原则

3. WIMP用户界面设计

4. 缺省设计问题

5. 输入验证设计问题

6. 系统响应及信息反馈问题

---

一、结构化设计

结构化设计采用自顶向下的方法进行设计

• 具有系统自动化边界的DFD
• 结构图

自动化系统边界划分：将数据流图划分为手工处理部分和系统能自动完成的部分。程序的处理过程可以在系统边界内部或外部，数据流可以在系统边界内部或外部。穿过系统界线的数据流代表了系统的输入和输出。在最终的系统中，数据流将成为用户界面中的表单、报表、供其他系统使用的数据文件等

讯享网

结构图定义：以模块为基础、以模块间的调用为关联所构成的图称模块结构图，简称结构图
结构图的作用：

• 通过层次的方法来描述系统每部分的功能和子功能
• 展示计算机程序模块间的联系

从DFD片段建立结构图

• 确定主要的信息流
• 找出能代表输入和输出间最基本变化的过程
• 重画数据流图并把输入放在左边，输出放在右边
• 初步建立一个结构图草图
• 加入其它模块实现下列功能
  • 数据输入、数据处理、数据输出
• 使用结构化语言或决策树添加模块间逻辑
• 进一步求精

二、面向对象设计

1. 面向对象设计概述

传统的结构化方法：分析阶段与设计阶段分得特别清楚，分别使用两套完全不同的建模符号和建模方法
面向对象的设计(OOD)：OO各阶段均采用统一的“对象”概念，各阶段之间的区分变得不明显，形成“无缝”连接。因此，OOD中仍然使用“类、属性、操作”等概念，是在OOA基础上的进一步细化，更加接近底层的技术实现

OOD中基本元素：设计类，对应OOA中的分析类

为了系统实现与维护过程中的方便性，将多个设计类按照彼此关联的紧密程度聚合到一起，形成大粒度的“包”(package)。一个或多个包聚集在一起，形成“子系统”(sub-system)；多个子系统，构成完整的“系统”(system)。

OOD中的两个阶段

• 系统设计(System Design)
  • 相当于概要设计（即设计系统的体系结构）
  • 选择解决问题的基本途径（框架、平台、工具…)
  • 决策整个系统的结构与风格(拓扑结构、软件体系结构…)
• 对象设计(Object Design)
  • 相当于详细设计（即设计对象内部的具体实现）
  • 细化需求分析模型
  • 识别新的对象

2. 系统设计

• 设计系统的体系结构——选择合适的分层体系结构策略，建立系统的总体结构：分几层？每层的功能分别是什么？
• 识别设计元素——识别“设计类”(design class)、“包”(package)、“子系统”(sub-system)
• 部署子系统——选择硬件配置和系统平台，将子系统分配到相应的物理节点，绘制部署图(deployment diagram)
• 定义数据的存储策略
• 检查系统设计

3. 包的设计

• 如果一个“分析类”比较简单，代表着单一的逻辑抽象，那么可以将其一对一的映射为“设计类”。通常，主动参与者对应的边界类、控制类和一般的实体类都可以直接映射成设计类
• 如果“分析类”的职责比较复杂，很难由单个“设计类”承担，则应该将其分解为多个“设计类”，并映射成“包”或“子系统”

绘制包图——把在语义上接近且倾向于一起变化的类组织在一起形成“包”。结构良好的包是松耦合、高内聚的，而且对其内容的访问具有严密的控制

包与包之间的关系

• 类与类之间存在的“聚合、组合、关联、依赖”关系导致包与包之间存在依赖关系，即“包的依赖”(dependency)
• 类与类之间的存在的“继承”关系导致包与包之间存在继承关系，即“包的泛化”(generalization)

4. 对象设计

• 1. 创建初始的设计类  （分析类 → 设计类）
• 2. 细化属性：具体说明属性的名称、类型、缺省值、可见性。
  • 尽可能将所有属性的可见性设置为private。
  • 从一个状态值到另一个状态值的变迁，一定是由该实体类的某个操作所导致的。
  • 两个类之间有association关系，意味着需要永久管理对方的信息，需要在程序中能够从类1的object“导航”(navigate)到类2的object。关联属性不只是一个ID，而是一个或多个完整的对方类的对象。务必与数据库中的“外键”区分开：例如：订单table中有一个外键（只是一个ID值）：买家ID(字符串类型)，靠它与买家table联系起来。不要用关系数据模式的设计思想来构造类的属性。关联属性的目标：在程序运行空间内实现object之间的导航，而无需经过数据库层存取
• 3. 细化操作：找出满足基本逻辑要求的操作。
  • 从actor出发，分别思考需要类的哪些操作。
    • 初始化类的实例、销毁类的实例  — Student(…)、~Student( )
    • 验证两个实例是否等同                 — equals( )
    • 获取属性值(get操作)                     — getXXX( )
    • 设定属性值(set操作)                     — setXXX(…)
    • 将对象转换为字符串                     — toString( )
    • 复制对象实例                                 — clone( )
    • 用于测试类的内部代码的操作        — main( )
    • 支持对象进行状态转换的操作
  • 细化操作时，要充分考虑类的“属性”与“状态”是否被充分利用：对属性进行CRUD、对状态进行各种变更
• 4. 定义状态
  • 设计一个对象的状态是如何影响其行为的
  • 绘制对象状态图
• 5. 细化依赖关系
• 6. 细化关联关系：根据“多重性”进行设计(multiplicity-oriented design)
  • Multiplicity = 1 或 Multiplicity = 0..1
    • 可以直接用一个单一属性/指针加以实现，无需再作设计
    • 若是双向关联：
      • Department类中有一个属性：+Mgr: Manager
      • Manager类中有一个属性：+Dept: Department
    • 若是单向关联：
      • 只在关联关系发出的类中增加关联属性
  • Multiplicity > 1
    • 无法用单一属性/指针来实现，需要引入新的设计类或能够存储多个对象的复杂数据结构(例如链表、数组等)
    • 将1:n转化为若干个1:1
  • 有些情况下，关联关系本身也可能具有属性，可以使用“关联类”将这种关系建模
• 7. 细化泛化关系

引入“辅助类”简化类的内部结构

辅助实体类，是对从用例中识别出的核心实体的补充描述，目的是使每个实体类的属性均为简单数据类型。这两个实体类之间形成聚合关系

5. 面向对象设计总结

系统设计

• *包图(package diagram) → 逻辑设计
• 部署图(deployment diagram) → 物理设计

对象设计

• 类图(class diagram) → 更新分析阶段的类图，对各个类给出详细的设计说明
• *状态图(statechart diagram)
• *时序图(sequence diagram) → 使用设计类来更新分析阶段的次序图
• 关系数据库设计方案(RDBMS design)
• 用户界面设计方案(UI design)

三、数据库设计

1. 数据库系统及关系数据库简介

数据库系统=数据库(DB)＋数据库管理系统(DBMS)

• 数据库(DB) ：被集中控制和管理的存储数据的完整集合。用ER模型来描述
• 数据库管理系统(DBMS) ：对数据库的访问进行管理和控制的软件
• 数据库设计的主要任务：
  • 逻辑设计：设计ER模型
  • 物理设计：在具体的数据库系统中实现ER模型

DBMS功能：

• 允许多个用户或应用程序同时访问数据库
• 无需应用程序就可以访问数据库(SQL语句)
• 管理已存储数据

关系数据库管理系统将数据存储成表(关系)的结构

• 表:    
  • 元组: 表中的行或称为一条数据记录 
  • 域: 表中的列或称为属性
• 表包含关键字(关键属性，key fields)，用来唯一的标识一条记录
• 关键字是表示表间关系的基础

2. 数据库逻辑模型设计

ERD——数据库逻辑模型设计

• 识别所有“自然”数据实体（Entity）
  • 来自DFD中的全部“数据存储”
  • 来自“分析类图”中的部分“类”
• 为数据实体命名
• 给出实体的属性
• 识别实体之间的关联关系及关联重数
  • 关联关系需命名
  • 关联重数需判别（1:1、1:M、M:N）
• 建立关联实体（“人造”实体）来消除M:N重关系
• 实体规范化（一般需满足3NF）
• 评价ERD质量并做必要的改进

3. ERD模型及质量评估

好的ERD标准：

• 结构清晰
• 关联简洁
• 实体个数适中
• 属性分配合理
• 没有低级冗余（重复性冗余）

至少符合3NF
数据库的规范化（Normalization）

• 通过最小化数据冗余来确保数据库模型的质量
• 范式（Normal Form）的分类
  • 1NF – 没有重复的属性或属性组
  • 2NF – 是1NF且每个非主属性均函数依赖于主属性(主键)
  • 3NF – 是2NF且非主属性间均不存在函数依赖
• 范式的通俗、易懂的解释：
  • 1NF：同样的东西不能重复拥有！
  • 2NF：领导在，他就在，找到领导就能找到他！
  • 3NF：领导只有一个，不能搞宗派，不能有多级领导！

4. 物理数据库的设计与建立

根据ERD建立物理数据库：

• 为每个实体创建一个二维表
• 为每个字段选择适当的数据类型和取值范围
• 定义每个表的主键(PK-Primary Key)
• 针对1:M关联关系的子表添加外键(FK-Foreign Key，即对应主表主键)
• 定义完整性约束
  • 定义3个方面的完整性约束
    • 域的完整性：设定字段的取值范围
    • 参照完整性：用PK、FK、表级触发器来实现
    • 用户定义完整性：定义一些业务规则，用存储过程和触发器来实现
  • 参照完整性的自动执行
    • 当建立一个包含外键的记录时, DBMS 确保该外键同时作为主键出现在另一个相关表的记录中
    • 当删除一个记录时, DBMS 确保在其它相关的表中不会出现和该记录主键值相同的外键
    • 当主键值改变时，DBMS保证相关表中没有外键与该主键具有相同的值

5. 物理数据库提高效率的方法

• 降低范式、增加冗余；少用触发器、多用存储过程
•  “体外运算”
  • 当计算非常复杂、记录数巨大时，则以文件系统方式用
  • C++等语言计算处理完成之后，最后才入库追加到表中去（电信计费系统设计的经验）
• 水平/垂直分割表
  • 当表中记录太多时则水平分割：以该表主键PK的某个值为界线，将该表的记录水平分割为两个表
  • 当表中字段太多时则垂直分割：将原来的字段分为二组，分别建立二个1：1的表
• 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数
• 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法

6. 描述分布式数据库的不同的体系结构模型

• 单数据库服务器体系结构
• 带备份的数据库服务器体系结构
• 将数据库模式划分为多个客户访问子集
• 分区数据库服务器体系结构
• 联合数据库服务体系结构

7. OO分析类图映射到ERD

类和关系数据表的关系

• OOP以class为基本单位，所有的object都是运行在内存空间当中
• 若某些object的信息需要持久化存储，那么就需要用到database，将object的属性信息写入关系数据表
• 在系统执行某些功能的时候，需要首先从database中将信息取出，使用各实体类的new操作构造相应的object，在程序运行空间中使用(充分利用继承/组合/聚合/关联/依赖关系在各object之间相互导航)
• 在进行OO分析和设计时完全可以将database忘掉，后续再加以考虑

数据存储策略

• 数据文件：由操作系统提供的存储形式，应用系统将数据按字节顺序存储，并定义如何以及何时检索数据
  • 存储大容量数据、临时数据、低信息密度数据
• 关系数据库：数据是以表的形式存储在预先定义好的成为Schema的类型中
  • 并发访问要求高、系统跨平台、多个应用程序使用相同数据
  • 复杂的数据查询
  • 数据集规模大
  • 如果使用关系数据库，那么需要一个子系统来完成应用系统中的对象和数据库中数据的映射与转换
• 面向对象数据库：将对象和关系作为数据一起存储
  • 并发访问要求高、系统跨平台、多个应用程序使用相同数据
  • 数据集处于中等规模
  • 频繁使用对象间联系来读取数据
  • 如果使用OO数据库，那么数据库系统应提供一个接口供应用系统访问数据
• 存储策略的选择：取决于非功能性的需求

OO设计中的数据库设计

核心问题：对那些需要永久性存储的数据，如何将UML类图映射为数据库模型
本质：把每一个类、类之间的关系分别映射到一张表或多张表
UML class diagram → Relation DataBase (RDB)
两个方面：

• 将类(class)映射到表(table)
• 将关联关系(association)映射到表(table)

对象关系映射(Object Relational Mapping, ORM)：为了解决面向对象与关系数据库存在的互不匹配的现象。通过使用描述对象和数据库之间映射的元数据，将OO系统中的对象自动持久化到关系数据库中

将对象映射到关系数据库

• 最简单的映射策略—— “一类一表”：表中的字段对应于类的属性，表中的每一行数据记录对应类的实例(即对象)

将关联映射到关系数据库(统一的、简单的途径)

• A与B分别映射为独立的数据表，然后再加入一张新表来存储二者之间的关联

将组合/聚合关系映射到关系数据库

• 实现方法：类似于1:n的关联关系
  • 建立“整体”表
  • 建立“部分”表，其关键字是两个表关键字的组合

OO到DB的映射

• 策略1：分别建立父类和子类的三张数据表
• 策略2：将子类的属性上移到父类所对应的数据表中，该表包括父类的属性、各子类的全部属性

• 策略3：将父类的属性下移到各个子类所对应的数据表中

四、用户界面设计

1. 用户界面设计的基本概念

• 用户界面的内容
  • 软件用户界面一般包含：
    • 界面元素的样式、大小、布局
    • 界面的美观效果（色彩、风格、图像）
    • 操作序列（或功能）的隐喻
    • 交互信息（输入、输出、提示）
• 什么是用户界面设计
  • 运用认知心理学、人机工程学、语言学等基础知识对用户界面完成结构设计、交互设计和视觉设计，从而使软件达到易学、易用、美观、高效的目的
• 用户界面设计的基本过程
  • 研究用户，分析软件的需求
  • 用户界面结构设计（采用低保真的原型）
  • 用户界面的交互设计（采用高保真的原型）
  • 用户界面设计方案评审
  • 迭代修改
• 美术设计师、UI设计师、软件设计师的区别
  •   美术设计师：关注界面的美观、修饰
  •   UI设 计 师：关注界面的可用性和用户体验
  •   软件设计师：关注软件界面的实现
• 用户界面设计理念：以用户为中心、方便用户、易用高效
• 用户界面设计标准
  • 可学性:  简单易学，用户能很快开始工作
  • 效率性:  使用效率高，用户能高效率工作
  • 记忆性:  使用方法容易记忆，减少学习时间
  • 容错性:  错误率低，避免灾难性操作错误发生
  • 满意度:  用户能带着愉悦的心情去工作

2. 用户界面形式及设计原则

用户界面分类

• 第一代：CUI－字符用户界面
  • 以字符为基础的简单交互界面，如常见的命令行，字符菜单等。
  • 以键盘为主
  • 分类：1.问答式界面 2.命令式界面 3.菜单式界面
• 第二代：GUI－图形用户界面
  • 以图形为基础的直接操纵用户界面，最新称为WIMP界面
  • 以鼠标为主，键盘为辅
• 第三代：MUI－多通道用户界面
  • 以多媒体为基础的智能的多通道用户界面
  • 麦克风、手写板、摄像头、音箱等

从应用软件功能角度分类：

•   操作系统用户界面
•   文字处理软件用户界面
•   工业控制系统用户界面
•   管理信息系统用户界面
•   网页用户界面
•   移动工具用户界面
•   游戏软件用户界面

用户界面风格

• 一致性风格
• 个性化风格
• 传统式风格
• 古典式风格
• 现代派风格
• 高科技风格
• 卡通式风格
• 插画式风格

形式与原则

• 命令语言界面设计
• 菜单界面设计
• 数据输入界面设计
• 直接操纵和WIMP界面设计
• 提示、帮助和出错界面设计

3. WIMP用户界面设计

• 窗口设计
• 菜单设计
• 填表输入界面设计——编辑框、缺省值、信息验证
• 操作控制元素设计
• 声音输出界面设计
• 图标设计
• 个性化界面设计
• UnDo/ReDo设计——数据结构是个环形栈(栈底不固定)；

4. 缺省设计问题

缺省或缺省值可能用到的场合:

• 文本编辑框；
• 输入选择框：列表框、组合框、单选框、多选框；
• 功能按钮：其上的焦点

缺省或缺省值设计的目的:

• 减少用户输入数据量，提高系统使用效率

缺省或缺省值采用原则:

• 缺省值的设定一定要考虑使用的效率，即从统计结果看，每次输入平均输入量（含清除缺省值的输入量） ＜ 无缺省值情况下的平均输入量。

5. 输入验证设计问题

输入验证设计可能用到的场合:

• 文本编辑框
• 功能菜单或按钮

输入验证设计设计的目的:

• 在可能的情况下，保证输入数据的有效性、合理性，减少错误，提高效率、保证安全

6. 系统响应及信息反馈问题

系统响应的目标:

• 及时响应
• 适时响应（不能过快/过慢）

信息反馈的目标:

• 反馈信息具体、准确
• 人性化反馈