一、系统建模过程
二、系统设计系统设计过程 - 概要设计包括
总体设计
总体布局设计
网络拓扑设计
资源配置设计
模块化结构设计
功能块分割
模块的功能和责任
模块之间的调用关系
模块之间的信息传递
系统设计过程 - 详细设计
代码设计:是一项信息分类和编码的工作，是将系统中具有某些共同属性和特征的信息汇总起来，用便于计算机和人员识别和处理的符号表示这些信息的设计工作。
数据库设计:适当的存储结构和存储方法，用于建立人脑易于识别的概念模型，在此基础上对数据进行建模，并将其转换为数据库管理系统支持的数据模型，客观准确地反映外部世界
输入/输出设计:输入输出设计主要是以记录为单位的各种输入输出报告格式的描述。 此外，人机交互格式的设计和输入输出装置的选择也在此步骤中完成。
用户界面设计:用户界面设计是指用户与系统之间的桥梁，主要内容包括界面格式的定义、基本交互控制形成的定义、图形和符号的定义、通用功能键和组
处理过程设计:定义每个模块的内部运行进程。 其中包括数据组织、控制流、每个步骤的具体加工要求以及实现细节。
三、人机界面设计用户界面设计是指用户与系统之间的桥梁，主要内容包括： 界面格式的定义、基本交互控制形成的定义、图形和符号的定义、通用功能键和键组合的含义及其操作内容的定义、帮助策略的定义等。
四.结构化设计 特点
抽象化、自顶而下、逐步求精、信息隐蔽、模块独立（高内聚、低耦合）
结构化编程的三个基本控制结构是顺序、分支和循环
功能模块设计的原则
模块的大小为50~100行，最多不超过500行。
适合将调用深度降至最低的系统深度和宽度比例。
适度控制模块的扇入(扇出3~4通常在7以下，扇入越大越好。
一个入口，一个出口。
模块的范围必须位于模块中。
功能应该是可预测的。
高凝聚低偶联。
系统分解有层次。
小数据冗馀。
模块独立性的度量
（1）聚合：衡量模块内部各元素结合的紧密程度
偶然聚合:与模块执行的动作没有任何关系，或者只是非常松散的关系。
逻辑聚合:模块内部的各结构在逻辑上具有相似的处理动作，但在功能用途上相互无关。
时间聚合:模块内部每个组件中包含的处理操作必须同时执行。
过程聚合:模块内部的各个组件执行的操作无关紧要，但必须按特定顺序执行。
通信聚合:模块的各构成要素所进行的动作都使用相同的数据或生成相同的输出数据。
顺序聚合:模块内部各部分，前一处理动作的最终输出为后一处理动作的输入。
功能聚合:模块内部的每个部分都属于一个，执行相同的功能，每个部分是实现此功能所不可缺少的
（2）耦合：度量不同模块间互相依赖的程度
33558www.Sina.com/:2:两个模块之间没有直接的关系，它们的联系完全通过主模块的控制和调用实现。
33558www.Sina.com/:2:在两个模块之间通过数据参数交换信息。
非直接耦合:一组模块通过参数表传递记录信息。 该记录不是简单的变量，而是数据结构的子结构。
33558www.Sina.com/:2:两个模块相互传递的信息有控制信息。
数据耦合:一组模块访问同一全局简单变量(而不是同一全局数据结构)，而不是通过参数表传递全局变量的信息。
33558www.Sina.com/:2:在两个模块之间通过公共数据区传递信息。
标记耦合:一个模块需要有关另一个模块的内部信息。
五.面向对象设计
控制耦合
>单一职责原则：设计目的单一的类开放-封闭原则：对扩展开放，对修改封闭
李氏(Liskov)替换原则：子类可以替换父类
依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程接口隔离原则：使用多个专门的接口比使用单一的总接口要好组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
迪米特(Demeter)原则(最少知识法则)：一个对象应当对其他对象有尽可能少的了解
六、面向对象设计 - 设计模式概念
架构模式：软件设计中的高层决策，例如 C/S 结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策
设计模式：主要关注软件系统的设计，与具体的实现语言无关
惯用法：是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用-计数就是 C++语言中的一种惯用法。
设计模式分类
创建型模式：与对象的创建有关，抽象了实例化过程，它们帮助一个系统独立于如何创建、组合和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类，而一个对象创建型模式将实例化委托给另一个对象。
结构型模式：处理类或对象的组合，结构型设计模式涉及如何组合类和对象以获得更大的结构。结构型类模式采用继承机制来组合接口或实现。结构型对象模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合，从而实现新功能的一些方法。
行为型模式：涉及算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述它们之间的通信模式。行为型类模式使用继承机制在类间分配行为，这里包括模板类模式和解释器类模式。行为对象模式使用对象复合而不是继承。一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任一对象都无法单独完成的任务。
创建型模式
结构型模式
行为型模式
实体类
实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息，例如，在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。
实体类是对用户来说最有意义的类，通常采用业务领域术语命名，一般来说是一个名词，在用例模型向领域模型的转化中，一个参与者一般对应于实体类。通常可以从SRS中的那些与数据库表（需要持久存储）对应的名词着手来找寻实体类。通常情况下，实体类一定有属性，但不一定有操作。
控制类
控制类是用于控制用例工作的类，一般是由动宾结构的短语（“动词+名词”或“名词+动词”）转化来的名词，例如，用例“身份验证”可以对应于一个控制类“身份验证器”，它提供了与身份验证相关的所有操作。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象（控制类的实例）通常控制其他对象，因此，它们的行为具有协调性。
控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关，当系统执行用例的时候，就产生了一个控制对象，控制对象经常在其对应的用例执行完毕后消亡。通常情况下，控制类没有属性，但一定有方法。
边界类
边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。要寻找和定义边界类，可以检查用例模型，每个参与者和用例交互至少要有一个边界类，边界类使参与者能与系统交互。边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。常见的边界类有窗口、通信协议、打印机接口、传感器和终端等。实际上，在系统设计时，产生的报表都可以作为边界类来处理。
边界类用于系统接口与系统外部进行交互，边界对象将系统与其外部环境的变更（例如，与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响。通常情况下，边界类可以既有属性也有方法。
软件设计包括了四个即独立又相互联系的活动：高质量的数据设计将改善程序结构和模块划分，降低过程复杂度；软件结构设计的主要目标是开发一个模块化的程序结构，并表示出模块间的控制关系；人机界面设计描述了软件与用户之间的交互关系。