(一)概要设计的任务和步骤1、整体设计的必要性)从抽象的层面分析站在全球角度、控制成本、对比多种可能性的系统实现方案和软件结构，从中选择最佳方案和最合理的软件结构，以低成本高质量的软件
2、总体设计两个阶段：
(1)系统设计阶段：确定系统的具体实现方案
(2)结构设计阶段)确定软件结构。
3、总体设计九个步骤：
(1)设想选项
)2)选择合理方案
(3)最佳做法建议
(4)功能分解
)5)软件结构的设计
(6)数据库的设计
(7)制定测试计划
(8)写文件
(九)审查和复审
(二)软件设计的基本原则、抽象和渐进方法传统的软件工程方法学采用结构化设计方法(SD )
1、从工程管理角度看结构化设计分为两个阶段：
概要设计：将软件需求转化为数据结构和软件系统结构
详细设计)通过对流程设计、结构进行细分，得到软件的详细数据结构和算法
2、设计原理
)模块化)可以将程序划分为独立名称的独立可访问模块，每个模块完成一个子功能，将这些模块集成在一起组成一个整体，完成指定功能满足用户的需求。
模块定义：也称为“构件”，是指通常以一个名称调用的相邻程序元素序列。
模块化设计(根据适当原则，将软件划分为一个个小、相关且相对独立的模块。
但是，无线的划分模块会导致接口成本的上升。
)2)抽象)提取事物的本质特性，不考虑细节
(3)精益求精：集中精力解决主要问题，尽量延缓细节问题的关注，实际上细分过程和抽象是相辅相成的概念
)4)信息隐藏：每个模块的实现细节对其他模块来说是隐藏的。 模块中包含的所有信息不允许不需要这些信息的其他模块访问。 每个客户只能通过接口知道模块，所有实现都是隐藏的。
)5)局部化)使关系密切的软件要素的物理地址相互接近
)模块化独立)是模块化、抽象、信息隐藏、局部化概念的直接结果。 具有独立的功能，与其他模块不太起作用
为什么模块是独立的？ 两个原因：分工协作容易测试和维护，修正工作量少，错误传播范围小，功能扩展容易。
3、两种定性测定标准：偶联、聚集
(1)结合)软件结构中间不同模块之间互连度的测量
决定：模块接口的复杂性通过接口数据。 尽量追求松散耦合系统。
联轴器三大类：无联轴器、松散耦合、紧密耦合(避免)。
常见：
非直接绑定：两个模块各自独立运行，因此不需要存在其他模块
数据合并：两模块通过参数交换数据信息
控制耦合：两个模块通过参数交换控制信息(包括数字格式)。 例如，根据控制信息来决定执行顺序
公用联轴器：
两种可能性：(松散)一个模块发送数据，一个模块获取数据，等效数据
(密集)两个模块来自或取自过去的公共环境，介于数据耦合和控件耦合之间
内容结合(相当紧密) :
一个模块访问另一个模块的内部数据
一个模块不通过通常的入口移动到另一个模块内部
两模块有部分程序代码重叠(汇编器) )。
1模块有多个入口
原则：尽量使用数据联接，减少控制联接，限制公共环境联接的使用，完全不使用内容联接。
)凝聚)模块内各元素之间的结合程度
功能凝聚(10分)模块内的各部分是完成某种功能不可缺少的组成部分
顺序凝聚(9分)模块内处理要素的功能密切相关，按顺序执行。 例如，修改学生信息，先找再修改
通信凝聚(中7点) 1模块内的各功能部分全部使用相同的输入数据，或生成相同的输出数据。 例如，根据以编号取得的部件单价和库存数输出"库存数"、"单价"
过程聚集(中5点)模块中的处理元件相关联，并按特定顺序执行。 例如，将流程图中循环部分、判定部分、计算部分分为三个模块，这三个模块凝聚成为过程凝聚
时间聚集(3点尽量不出现) :多为多个功能模块，要求所有功能在同一时间内运行。 例如，初始化模块
逻辑凝聚(1点尽量不出现) )一模块的完成功能在逻辑上属于相同的类似类别。
偶然凝聚(0点尽量不出现) )模块内各部分没有联系，即使有也很松
4、启发规则
(1)改进软件结构提高模块独立性
)2)模块规模应适中。 通常，句子的行数为50~100行(1页)，最多为500行
>（3）深度、宽度、扇出和扇入都应适当深度：软件结构控制层数，标志一系统大小和复杂程度
宽度：软件结构同一层模块最大值，越大系统越复杂
扇出：一模块直接控制（调用）模块数3~9
扇入：有多少上级模块直接调用它，越大共享该模块上级模块越多（能直接调用该模块的数目）
（4）模块作用域应在控制域内
作用域：受该模块内判定影响的所有模块
控制域：模块本身及所有直接或间接从属它的模块集合
改善一：判定点上移
改善二：将在作用域不在控制域内的模块下移
（5）降低模块接口复杂程度
（6）设计单接口，单出口模块
（7）模块功能可预测：输入数据相同，产生同样输出；模块功能防止过分受限。
（三） 详细设计的任务1、任务：确定模块算法；确定模块使用数据结构；确定接口（系统外部接口、用户界面、内部模块间接口细节、输入数据和输出数据）
2、人机界面设计
①系统响应时间：长度0.1~1秒正常；处理1-10秒鼠标显示成沙漏；处理10~18秒由为帮助显示成处理进度；18秒以上显示处理窗口或显示进度条
②用户帮助措施：手册和联机帮助两种
③出错信息处理：以用户可以理解的术语；提供清楚，易理解报错信息；从错误中恢复的建设性意见；可造成负面后果。
④命令交互：建议保留命令形式交互方式（控制序列、功能键、控制宏机制、键入命令）
3、程序流程图
优点：对控制流出层的描述很直观，便于初学者
缺点：①程序流程图本质上不是逐步求精的好工具，它诱使程序员过早的考虑程序的控制流程，而不考虑程序的全局结构
②程序流程图中箭头代表控制流，因此程序有不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制
③程序流程图不易表示数据结构
4、盒图（N-S图）
特点：
①功能域明确
②不可能任意转移控制
③很容易确定局部和全程数据的作用域
④很容易表现嵌套关系，也可以表示模块的层次
5、PAD图
特点：
①设计出的程序必然是结构化程序
②描绘的程序结构十分清晰
③表示程序逻辑，易读、易懂、易记
④容易将PAD图转换成高级语言源程序
⑤可用于表示程序逻辑，也可用于描绘数据结构
⑥支持自顶向下、逐步求精方法的使用
6、判定表：能够清晰表示复杂条件组合与应做动作间对应关系
四部分
左上：列出所有条件
左下：所有可能的动作
右上：表示各种条件组合的矩阵
右下：和每种条件组合相对应的动作
例：
7、判定树
优点：形式简单，易看出含义，易于掌握和使用
缺点：简介性不如判定表，相同数据重复写多遍，越接近叶端重复次数越多
8、PDL：伪码，用正文形式表示数据和处理过程设计工具
PDL具有严格关键字外部语法，定义控制结构和数据结构
PDL表示实际操作和条件的内部语法灵活自由，适应各种工程项目需要。
9、程序复杂度（小于等于10）
使用比较广泛的cCabe方法
根据过程设计结果画出相应的流图
流图描述程序控制流，基本图形符号
计算环形复杂度：
三种方法：V(G)=区域数；V(G)=E-N+2（E为流图边数，N为流图节点数）；V(G)=P+1（P为判定点数）
（四） 结构化程序设计的概念和思想1、结构化程序设计
（1）经典定义：如果一个程序的代码块仅仅通过顺序、选择、和循环3种基本控制结构进行连接，并每个代码块只有一个入口和一个出口，则称这个程序是结构化的。
（2）扩展定义：可限制使用GOTO语句，DO_UNTIL、DO_CASE
（3）修正定义：leave和break，可从循环中转移出来。
（五） 面向对象程序设计的概念和思想数据结构既是影响程序的结构也是影响程序处理过程，可以数据结构导出程序的处理过程，适合详细设计
两种面向数据结构设计方法：mmdlz和Warnier方法
1、mmdlz图
优点：
①便于表示层次结构，是对结构进行自顶向下分解的有力工具
②形象直观可读性好
③既能表示数据结构也能表示程序结构
步骤：
①确定输入数据和输出数据逻辑结构，用mmdlz图表达
②确定输入结构和输入结构中有对应关系（因果）的单元
③描绘数据结构的Jason图导出描绘程序结构的Jason图
④列出所有操作和条件，分配到Jason图中
⑤用伪码表示
描述数据结构图形符号：顺序、选择、重复
改进：变成直线
（六） 程序流程图 （七） 模型-视图-控制器框架（MVC） 本节参考《百度百科》MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。
通常模型对象负责在数据库中存取数据。
View（视图）是应用程序中处理数据显示的部分。
通常视图是依据模型数据创建的。
Controller（控制器）是应用程序中处理用户交互的部分。
通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
耦合性低
视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
模型是自包含的，并且与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。如果把数据库从MySQL移植到Oracle，或者改变基于RDBMS数据源到LADP，只需改变模型即可。一旦正确的实现了模型，不管数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互独立，改变其中一个不会影响其它两个，所以依据这种设计思想能构造良好的松耦合的构件。
重用性高
随着技术的不断进步，需要用越来越多的方式来访问应用程序。MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码，因为多个视图能共享一个模型，它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。例如，很多数据可能用HTML来表示，但是也有可能用WAP来表示，而这些表示所需要的命令是改变视图层的实现方式，而控制层和模型层无需做任何改变。由于已经将数据和业务规则从表示层分开，所以可以最大化的重用代码了。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。
生命周期成本低
MVC使开发和维护用户接口的技术含量降低。
部署快
使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。
可维护性高
分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。
有利软件工程化管理
由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。
缺点没有明确的定义
完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。
不适合小型，中等规模的应用程序
花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
增加系统结构和实现的复杂性
对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
视图与控制器间的过于紧密的连接
视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
视图对模型数据的低效率访问
依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
一般高级的界面工具或构造器不支持模式
改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，会造成MVC使用的困难。