面向过程设计和面向对象设计之间区别的实例

转载请标明出处： http://blog.csdn.net/xx326664162/article/details/49815921 文章出自：薛瑄的博客

你也可以查看我的其他同类文章，也会让你有一定的收货！

参考：http://blog.sina.com.cn/s/blog_46552dd90100eg5l.html
问题：我在一个新的项目中使用UML中的用例分析和概念模型。但是老板坚持要用传统的需求说明书（使用面对过程的方法）。传统方法使用系统结构图表达功能间关系，使用数据流图表达功能与数据间关系，使用ER图表达数据间关系。老板说我可以使用UML，但必须能够清晰的表达这几种关系。

我不知道应该使用UML中的哪些图表达这些关系。我觉得Use_Case图可以部份表达功能间关系（通过用例的Include和Extant关系），概念模型可以替代ER模型。但IPO（数据流）图的表达如何用UML来替代？？

方案：我决不会教你如何做设个移植手术，因为这样做的结果只能出来一个驴不象驴，马不象马的怪物，也许还没拉车，就会死掉。

我只能告诉你一些原来结构化模型中表达的信息，现在在UML的OO方法中都跑到哪里去了。也就是驴子使出的力气，马是如何使的。你解释给你们老板听，希望这样能让你们的老板心里对你是用OO踏实一些。我猜你是一个硕士生，老板是你导师，所以你会坚持用马。如果你不是学生，我这是在害你。

面向对象的主要思想是将数据和处理合理的结合在一起，即类图和相应的动态图

模型 面向过程（结构化方法) 面向对象（UML建模） 动态模型 表达功能间关系(系统结构图) 表示消息对类状态产生的影响（状态图） 功能模型 表达功能与数据间关系(数据流图) 表示变化的系统的功能性质，指出系统应该做什么（用例图，活动图） 对象模型 表达数据间关系(ER图) 表达数据间的关系（类图）

通常，

1. 表达需求的系统结构图会按照业务功能领域逐层分解一个大的组织机构的业务功能到小的组织机构和个人的功能。
2. 为每个分解下来了的业务功能后面加一个“管理”的后缀，就成了“系统功能模块”或“子系统划分”的需求了。

3. 接下来会为每个模块或子系统进行功能实现的设计，

   • 画IPO图，把模块之间的数据接口和内部处理逻辑表达出来。

   • 画数据流图，用模块的功能及其对数据的使用关系的链来表达对外部请求的响应过程和给外界的反馈信息。

   • ER图则把重点放在对持久数据的存储结构方面，以便用关系型数据库保存和查找信息，实现功能运行与数据存储的结构无关性。

面向过程和面向对象表达的信息对比：

• 在结构化方法中，用户使用软件的目的和过程的信息，都被直接抽象为了输入数据和得到反馈的数据。你只会看到用户做出输入什么数据然后得到什么数据输出的现象，至于用户在做出一件有什么业务意义的行为的信息在结构化模型中基本被抛弃。
  这些信息在面向对象的方法中得到保留并作为外部封装的信息。
  用例是用来描述在系统的边界上看到的对外服务的窗口，并不是用来直接描述系统功能的分解结构的，使用用例模型代替结构化方法的功能分解是一个顽固的误用。

• IPO图表达的功能数据接口信息则封装到顺序图或协作图中对象之间传递的消息中去了。
  
  简单地说：原来结构化方法中功能结构分解的信息已经完全封装在对象方法的协作关系中去了。
  用例是对外的服务，内部靠对象的协作来满足这些服务。
  原来功能分解的形式已经完全被对象在协作中的职责划分的方式所取代。不仅这些信息没有丢失，而且保存得更加完整和从用户角度更加易于理解。

• 数据流图在OMT方法中是被沿用了的。
  
  在UML中被舍弃的原因大概是因为大师认为：“从结构化方法向面向对象方法的过渡期”已经过去。带有实现类的活动图（带泳道）在表达动态处理过程更有优势，不仅能表达处理的流程，还能看清对象的职责。

• 关于ER图和静态模型的对比问题，我前些时候有过讨论。
  
  我认为关于数据存储的问题在面向对象方法中已经可以从概念层降低到实现层了。在面向对象的概念模型中，只有对象协作，数据关系的信息也被重新组织和划分到对象属性和关联的信息之中。

  只有在考虑对象需要持久存储其某些信息的时候，由于现有数据存储的主要机制还是关系型数据库，所以，才会带来重新按存储的要求来组织数据的工作。
  一个明显的趋势当然是直接存储对象的信息，这样，ER模型就可以彻底退出历史舞台了。

总之，从结构化到面向对象，不仅仅是模型形式上的变化，而且有哲学思想上的变化，试图从形式上进行嫁接的努力一定得不到好结果。