设计的总体原则
软件架构设计
反映系统整体的组织结构和基本特征
• 软件的层次结构
• 模块相互作用的方式
• 全局的、重要的数据变量和数据结构
• 数据库的逻辑结构
• 接口
详细设计
• 模块逻辑的详细设计
• 系统数据结构的设计
• 系统数据库结构的设计
• 系统-人机接口的设计
分治
架构设计->将系统分解为一组子系统或模块，以及子系统或模块之间的接口。
详细设计->子系统或模块被再次细分为子模块
抽象
基于抽象的设计原则
里氏替换原则
子类可以替换父类，可以出现在父类能出现的任何地方
开闭原则
一个软件实体应当对扩展开放，对修改关闭
拓展时不对模块的源码更改，只对拓展出去的部分编写新的代码
依赖倒转原则
要依赖于抽象，不要依赖于具体类
高级业务逻辑 依赖于 抽象类
具体类 从 抽象类 泛化而来
传统软件工程的中的抽象
信息屏蔽
数据局部化
只是对模块细节的封装，没有继承的概念
面对对象软件工程中的抽象
抽象类
接口
只有方法的特征，没有方法的实现
接口隔离原则：使用多个专门接口比使用单一的总接口要好很多
内聚
度量模块内部各部件间紧密程度
分解时将相关的内容放到一起
确定模块是否合理（部件联系越紧密越好）
内聚的分类
功能内聚（Functional Cohesion）
所有部件处理同一组数据，共同完成单一的功能
最理想的内聚-1
顺序内聚（Sequential Cohesion）
各部件之间既有数据联系又有控制联系
较为理想-2
通信内聚（Communicational Cohesion）
所有的部件都访问同一组数据，各部件之间只有数据关系，没有控制关系
较为理想-3
过程内聚（Procedural Cohesion）
各部件之间只有控制联系，而没有数据联系
较弱的内聚-4
时间内聚（Temporal Cohesion）
具有时间关系，无数据联系，也无控制联系
内聚更弱-5
实用程序内聚（Utility Cohesion）
部件常常是一些相关的、可重用的实用程序
内聚很弱-6
偶然内聚（Coincidental Cohesion）
各部件之间没有任何关系
最差的内聚-7
层内聚（Layer Cohesion）
将相关服务的功能放到一起，成为一层
应用在软件的分层架构上
耦合
度量模块间相互相互联系的强弱
耦合越松散越好
耦合的分类
内容耦合（Content coupling）
一个模块直接进入另一个模块中存取其数据或使用其服务
（直接在一个类中创建另一个类的对象）
最差的耦合-7
公共耦合（Common coupling）
两个模块间通过一个公共环境进行数据交换
较差的耦合-5
外部耦合（External coupling）
模块对外部系统有依赖关系
尽量减少使用-6
控制耦合（Control coupling）
两个模块之间通过接口的参数表交换开关数据， 旨在控制另一个模块的执行逻辑
较差的耦合-4
印记耦合（Stamp coupling）
指两个模块之间通过参数交换方式产生耦合，并且交换的是数据结构而不是数据元素
（调用另一个模块的公共方法和变量）
允许使用-3
数据耦合（Data coupling）
两个模块之间通过接口的参数表交换信息数据，并且这些信息数据的类型是基本数据类型
需要传递的参数较少时，数据耦合较好
需要传递的参数较多时，印记耦合要更好
-2
复用
软件复用：重复使用为了复用目的而设计的软件的过程
黑盒复用：不用修改直接复用（无须知道源码直接能使用）
白盒复用：修改后才能使用
代码复制
共享公共函数和子例程
面向对象复用
基于组件复用
组件(Component)是指有定义完备接口的、明确规定了上下文依赖关系的合成单元
基于Web服务的功能复用
传统的设计描述方法
层次图
即组成系统的程序模块及其调用关系
结构图
表明模块之间的相互作用关系
程序流程图
盒式图
PDL伪码
E-R图
面对对象的设计建模方法
+表示public
#表示protect
包
类图
类+类间关系
构件图
构件是系统中遵从一组接口且提供其实现的物理的、可替换的部分
输出接口：构件实现的接口
引入接口：构件使用的接口
类是逻辑抽象，构件是物理抽象
部署图
表示系统中的计算节点的拓扑结构和通信路径与节点上运行的软构件
两个节点之间的直线表示两个硬件间的关联关系
人机交互界面设计
人机交互(HCI)
以用户为中心的设计(UCD)
设计模式
对某特定环境下某类问题的解决方法 是在特定上下文中遇到的一般性问题的可重用解决方案的概要
门面模式Facade
玩家角色模式Player-Role
观察者模式Observer