前言
总结自老师的PPT，不只有知识点，还有一些相关内容的介绍顺便复制进来了，自己感兴趣就想多了解一些。 如有问题请多指教
设计的定义
软件设计解决的是“怎么做”的问题。软件设计是将需求描述的“做什么”的问题变为一个实施方案的创造性的过程。
概要设计模式
体系结构设计
主要的体系结构
主机结构
C/S(客户机/服务器)
B/S
分层架构：MVC模式的登录
多层架构-SSH
云架构
模块设计
希望是低耦合、高内聚
(类比教学楼工程项目：模块设计相当于教学楼的各个单元设计。)
- 模块化：就是把程序划分成命名且可访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。
- 设计遵循的原则之一：模块。
- 耦合: 如果改变程序中的一个模块，要求另一个模块也同时发生改变，就认为这两个模块发生了耦合。衡量不同模块彼此间互相依赖(连接)的紧密程度。
- 内聚：是衡量一个模块内部各个元素彼此结合的紧密程度。内聚要高，每个模块完成一个相对的特定子功能。
例
数据设计
数据库设计的基本步骤
概念结构设计转换为逻辑结构设计
转换原则
- 在“一对多”关系中，无论“多”端是强制存在的还是可选存在，都不会影响其转化形式，外键必须出现在“多”端，即“多”端转化为从表。当“一”端实体是可选存在时，“多”端实体表中的外键列允许为NULL。
- 在“多对多”关系中，需要一张新关系表包含两个实体的主键。无论两边实体是否为可选存在的，其转化形式一致，关系表中的外键列不能为NULL。
数据依赖
函数依赖
比如描述一个学生的关系，学号Sno、姓名Sname、系名Sdept等几个属性，由于一个学号只对应一个学生，一个学生只在一个系。因而学号值确定之后，学生的姓名和所在系的值也就被唯一地确定了。
属性间的这种依赖关系类似于数学中的函数y=f(x)，自变量x确定之后，相应的函数值y也就唯一确定了。
Sno函数决定Sname，Sno函数决定Sdept，或者说Sname、Sdept函数依赖Sno，记作Sno → Sname，Sno → Sdept。
例
[例1]建立一个描述学校教务的数据库：
学生的学号（Sno）、所在系（Sdept）
系主任姓名（Mname）、课程名（Cname）
成绩（Grade）
单一的关系模式 ： Student <U、F>
U ＝｛ Sno, Sdept, Mname, Cname, Grade ｝
关系模式Student<U, F>中存在的问题
- 数据冗余太大
- 更新异常（Update Anomalies）
- 插入异常（Insertion Anomalies）
- 删除异常（Deletion Anomalies）
数据依赖对关系模式的影响
结论：
- Student关系模式不是一个好的模式。
- “好”的模式：
不会发生插入异常、删除异常、更新异常，
数据冗余应尽可能少
原因：由存在于模式中的某些数据依赖引起的
解决方法：通过分解关系模式来消除其中不合适
的数据依赖
分解关系模式
把这个单一模式分成3个关系模式：
S（Sno，Sdept，Sno → Sdept）;
SC（Sno，Cno，Grade，（Sno，Cno） → Grade）;
DEPT（Sdept，Mname，Sdept→ Mname）
范式
- 第一范式（1NF，每一列都是不可分割的基本数据项）
- 第二范式（2NF，消除部分子函数依赖，即属性完全依赖于主键）
- 要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体。
- 第三范式（3NF，消除传递依赖，即属性不依赖于其它非主属性] ）
- 要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
E-R图与类图
- 完全可以用类图的语法来表示实体以及实体之间的关系。即：实体－联系(Entity-RelationShip,简称E-R)
- 事实上，设计程序时，数据库中的每张表都将对应于一个实体类。
- 实体-联系如何向数据库表转换，下面针对关系中的1:1，1:M和M:N的这几种情况进行分析
两实体
一对多关系：
在“一对多”关系中，无论“多”端是强制存在的还是可选存在的都不会影响其转化形式，外键必须出现在“多”端，即“多”端转化为从表。
当“一”端实体是可选存在时，“多”端实体表中的外键列允许为NULL。
多对多关系：
在“多对多”关系中，需要一张新关系表包含两个实体的主键。
无论两边实体是否为可选存在的，其转化形式一致，关系表中的外键列不能为NULL。实体可选存在，在关系表中表现为是否存在对应记录，而与外键是否允许NULL值无关。
转换小结
转化过程中对于NULL值的处理规则
- 当实体之间的关系是可选的，SQL表中的外键列允许为NULL。
- 当实体之间的关系是强制的，SQL表中的外键列不允许为NULL。
- 由“多对多”关系转化得到的SQL表，其中的任意外键列都不允许为NULL。
界面设计
用户界面是软件与用户交互的最直接的层，是应用程序中重要的部分和最直接的体现者，界面的好坏决定用户对软件的第一印象。
设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。
提升用户体验。
1.用户界面容易出现的设计缺陷
（1）措辞含糊，某个术语表述的不清楚或不一致，导致用户非常迷惑甚至产生操作失误。
（2）布局混乱，缺乏逻辑，让用户不知从何下手。
（3）没有防错处理，不对用户输入的数据进行检验，不根据用户的权限自动隐藏或者禁用某些功能。在用户执行执行破坏性的操作之前，不提醒用户确认。
（4）不提供进度条、动画来反映正在进行的比较耗时间的过程，对于重要的操作也不返回结果。
2.用户界面设计过程
（1）先设计和实现用户界面原型。
（2）用户试用该原型，向设计者提出对界面的评价。
（3）设计者根据用户的意见修改设计并实现下一级原型。
（4）不断进行下去，直到用户满意为止。
界面流—采用Axure RP工具
界面设计原则
面向对象和面向过程设计
结构化的设计方法
层次图
矩形框代表模块，连线表示调用关系。
带编号的层次图（H图）
编号便于追踪了解这个模块在软件结构中的位置
层次图和IPO表
和H图中每个方框相对应，应该有一张IPO图描绘这个方框代表的模块的处理过程。
结构图
结构图和层次图类似，也是描绘软件结构的图形工具。
产生最佳解的结构图
结构图中的元素
方框代表一个模块；
方框之间的直线表示模块的调用关系；
尾部是空心圆箭头表示传递的是数据；
尾部实心圆箭头表示传递的是控制信息。
4种类型的模块：
- 1.传入模块：从下属模块取得数据，经过某些处理，再将其送给上级模块。它传送的数据叫做逻辑输入数据流。
- 2.传出模块：从上级模块取得数据，进行某些处理后，传送给下属模块。它传送的数据流叫做逻辑输出数据流。
- 3.变换模块：从上级模块取得数据，进行特定处理后，送回原上级模块。它加工的数据流叫做变换数据流。
- 4.协调模块：对其下属模块进行控制和管理的模块。在一个好的系统结构图中，协调模块应在较高层出现。
结构图由数据流图导出
数据流图导出结构图，基于变换分析。
变换分析（步骤）
确定输入流和输出流的边界，从而孤立出变换中心。即划分出数据流图的输入、主加工和输出
套用固定格式生成顶层和第一层结构图。
对第一层模块进一步分解，构造完整的结构图。
举例
“第一级分解”：位于软件结构最顶层的控制模块Cm协调下述从属的控制功能：
- 输入信息处理控制模块Ca,协调对所有输入数据的接收；
- 变换中心控制模块Ct,管理对内部形式的数据的所有操作；
- 输出信息处理控制模块Ce，协调输出信息的产生过程。
“第二级分解”
处理映射成软件结构中一个适当的模块。完成第二级分解：
- 从变换中心的边界开始沿着输入通路向外移动，把输入通路中每个处理映射成软件结构中受Ca控制的一个低层模块；
- 然后沿输出通路向外移动，把输出通路中每个处理映射成直接或间接受模块Ce控制的一个低层模块；
- 最后把变换中心内的每个处理映射成受Ct控制的一个模块。
面向对象的设计方法
面向对象的设计(OOD)是将面向对象分析方法建立的(需求)分析模型转化为构造软件的设计模型。
具体应包括识别对象（类）、确定属性、定义操作、确定对象之间的通信