NET企业级开发第二章摘要.pptVIP

什么是软件架构？ 软件架构的过程？ 软件架构应该澄清的误区？ 软件开发中的UML 用例图 类图 * Thank you! * UML中的图表 类图中的类关系： 依赖（实现上的依赖）： * UML中的图表 顺序图 顺序图能够给出实现某个场景中的一系列对象的交互顺序。顺序图主要用于描述系统中某个流程的详细步骤。一般一个顺序图对应用例图中的一个用例，是对此用例的详细描述。 * UML中的图表 顺序图 对象的创建和销毁 * UML中的图表 顺序图 异步调用 * UML中的图表 顺序图示例 在处理订单之前要查看客户是否是现有客户。若是现有客户，则要进行折扣计算。随后系统会给出折扣率，并设定至Order对象中。随后系统再处理该订单，并保存回存储介质中。 交互框在顺序图中划出一个区域，并标记一个操作符合布尔条件。 * UML中的图表 顺序图示例 * 2.3.1 基本设计原则 2.3.2 面向对象设计 * 2.3.1 基本设计原则 正常工作的代码 = 良好的代码 良好的代码要求：更加全面的看待系统（通用性接口、可扩展接口）；更加重视代码的可维护性。 思考一下：为什么软件维护的代价如此高？ 1、Bug可能从源头就被引入； 2、代码可读性问题； 3、兼容性、可扩展性较差： …… * ？ 根本原因是什么？ 差设计?弱沟通 多次迭代?XP编程 2.3.1 基本设计原则 冰冻三尺非一日之寒，一个差的设计通常是一个缓慢的过程，需要较长的时间，我们需要在设计走下坡路的时候，抓住这些信号进行纠正。 差设计的警告信号： 1、坚硬，因此易碎； 2、使用要比重用简单； 3、临时修补要比彻底解决简单。 * 坚硬是指对修改有较大的抵触，类似于一次成型的产品；易碎是指在修改或者扩展一处要求时不得不打破整个设计。 要引入一个小的插件，不得不像拔花生一样，间接引用大量的无用插件，这种情况下，你会选择重用还是重新设计？（顽固性） 惰性或者时间、成本限制，使得我们用修补来掩盖错误或漏洞，这种情况下积少成多，想象一下维护工作是否会乱成一团？（粘性） 2.3.1 基本设计原则 结构化设计 读一下你以前写的代码或者将这些代码拿给你的朋友看，可能只会得到这样的答案“物是人非，今不识故”。实际上从整个软件发展来看和我们自己的编程演变是一样的。 从意大利面代码到千层饼代码： 杂乱无章到功能提取，结构化最先让人联想到的就是子程序，虽然我们现在已经有了更为贴近现实参照系的设计原则，但是有两个原则仍然适用。 高内聚、低耦合 * 模块：又称构件,是能够单独命名并独立地完成一定功能的程序语句的集合（即程序代码和数据结构的集合体）。它具有两个基本的特征：外部特征和内部特征。外部特征是指模块跟外部环境联系的接口（即其他模块或程序调用该模块的方式，包括有输入输出参数、引用的全局变量）和模块的功能；内部特征是指模块的内部环境具有的特点（即该模块的局部数据和程序代码）。 在面向对象程序设计中，一个对象就是一个模块，对象中的一个方法也是一个模块。 当每个模块内部存在最大关联而在模块之间存在最小关联时，不论是纠错性、完善性还是适应性维护，其维护工作量都会下降，这也是产品模块划分的原则。 内聚：即一个模块内部的交互程度； 耦合：即模块间的交互程度。 偶然内聚 逻辑性内聚 时间性内聚 过程性内聚 通信性内聚 功能性内聚 信息性内聚 低 高 偶然内聚 如果一个模块的各成分之间毫无关系，则称为偶然内聚，也就是说模块完成一组任务，这些任务之间的关系松散，实际上没有什么联系。 缺陷： 这些模块使得产品的可维护性下降； 这些模块不可复用。 解决方法： 拆分操作。 逻辑性内聚 几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚。如一个模块读取各种不同类型外设的输入。尽管逻辑内聚比偶然内聚合理一些，但逻辑内聚的模块各成分在功能上并无关系，即使局部功能的修改有时也会影响全局，因此这类模块的修改也比较困难。 缺陷： 接口不易理解（逻辑性内聚的方法）； 完成多个操作的代码可能会发生纠结，导致严重的维护问题。 1、处理所有输入输出的代码 2、只处理输出的代码 3、只处理输入的代码 4、处理磁盘/磁带的输入和输出的代码 5、处理磁盘输入/输出的代码 6、处理磁带输入/输出的代码 7、处理磁盘输入的代码 8、处理磁盘输出的代码 9、处理磁带输出的代码 10、处理磁带输入的代码 ……………………………… 时间性内聚 如果一个