UML、OO、软件测试.pptVIP

从概念模型到设计模型 对应设计时间 * * * * * * * * * * * * * * * * * * * * * 思考一下，如何理解这句话？ 大家发言，在不假思索的情况，当我们提到面向对象时我们首先会想到哪些与之间相关的词语？（之前博士和小王都跟我讲过面向对象的思维） 很多IT人员一提到面向对象便会不由自主想到【继承】、【多态】、【复用】。其实面向对象和面向过程一样都是一种认识论，都是为了描述客观世界；面向对象方法之所以会兴起，是因为这种认识论能够帮助我们构造更为复杂的系统来解释起来越复杂的现实世界。如果单单为了复用而使用面向对象，那就远远背离了面向对象的本义，公共函数一样可以实现复用，还有一种方法干脆Ctrl C + Ctrl V好了。面向对象的思维不仅仅适用于IT，同样适用于其它领域，正如过程控制理论源自于工程学一样。 * 数据流动 如图,计算机通过数据来记录过程的变迁。过程中每一步都会产生、修改或读取一部分数据。每一个环节完成后，数据将顺着过程链传递到下一部分。为了能很好分析这样的过程，DFD图被广泛应用。DFD图表达了“(从上一步)输入数据→(在这一步)功能计算→(向下一步)输出数据”这样一个基础单元。 数据重要-数据库 由此可以看出数据对面向过程来说是非常重要的，因此数据的正确性和完备性对系统成功与否至关重要。为了更好地管理数据，人们用数据库范式来保证它们的完备性和一致性。在面向过程成为主要的软件方法之后，关系数据库也得到了极大的发展，针对数据的分析方法ER模型也深入人心，被极为广泛地使用。 需求越来越复杂，数据共享——IBM提出使用UC矩阵 随着需求越来复杂，系统越来越庞大，功能点越来越多，一份数据经常被多个过程共享，这些过程对同一份数据的创建和读取要求越来越趋于复杂各多样，经常出现矛盾的数据需求，因此分析和设计变得越来越困难。IBM在20世纪70年代提出了UC矩阵的方法来求解功能和数据之间的依赖问题。但UC矩阵也只是使得困难得以缓解，并没从根本上解决问题。 * * 过程化的，一个紧密相连的小系统，构成这个系统的各个部分之间有密不可分的因果关系 这便是所谓的耦合度太高 构成一个系统的因素太多，要把所有可能的因素考虑到，把所有因素的因果关系分析清楚，太困难 举个简单点的例子： 以人的眼、耳、口、鼻和手为例，如果以面向过程的方法来分析它们之间的关系，大家可以得出多少种可能的过程？当我们列举出这么多的可能的过程后，这些过程是否能覆盖它们之间全部的关系？ * 如何理解外部力量的驱动 以口和鼻为例：通常口是用来吃饭、讲话的，但是口在特定的情况下也可以用来呼吸，这个特定情况是鼻子罢工了，这对口来说就是外部力量，片子为什么罢工呢，可能是感冒了也可能是其它原因，反正只要能导致鼻子失去呼吸功能就行。 * * * * * 可视化， 这是一个奇怪的词，什么东西不都是可见的吗？UML是可视化的，用文字定的文文件 不也是可视化吗？在这里可视化的含义不是指UML的图形是可以用眼睛看到的，可视化的含义是指，UML通过它的元素模型和表示 法，把那些通过文字或其他表达方法很难表达清楚的，隐晦的潜台词用简单直观的图形表达和暴露出来，准确而直观地描述繁杂的含义。把“隐晦”的变成“可视”的，也就是把文字变成图形，这才是UML可视化的真正含义。 * 从现实世界到业务模型 对应需求分析阶段 * * 从业务模型到概念模型 对应分析阶段 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 关于软件之间的冲突，我记得之前会计系统和工贸系统之间就因为一个同名的ZIP的DLL文件而发生冲突。 * * * * * * * * * * * * * * * * * UML与软件测试 面向过程 数据流动 数据重要-数据库 需求越来越复杂，数据共享——IBM提出使用UC矩阵 有用，但困难没有根本解决 问题在哪里？ UML与软件测试 面向过程 本质问题出在认识方法上：将世界视为过程的方法蕴含了一个前提假设——这个过程是稳定的 这样我们才有分析的基础，所有的工作成果都依赖于这个过程的步步分析 这种步步分析地过程方法导致——过程中的每一步都是预设好的，有严谨的因果关系 UML与软件测试 面向过程 面向过程的困难：本质上是因为面向过程的方法将世界看作是过程化的，一个紧密相连的小系统，构成这个系统的各个部