以前的
同事Opera说,到30岁了还要看诸如Thinking in Java之类的青少年读物,是很悲哀的, 当然,我还没到30,当然,我也感觉到了它正大步流星的朝我奔来,做好准备要给我一个措手不及.
前天拿着program leader开出的reference book的list跑去lib借书, 赫然发现list里面有一本书叫作---Object-Oriented Analysis, 有点汗, 大学都一直没有好好看过这么"重要"的学术著作, 到了现在, 始终跨不过去. 当年倒是有一门课, 叫做面相对象编程,其实就是讲C++, OO一带而过, 管院四大杀手之一执教,那六个月过得战战兢兢,可是OO却学得一知半解,因为要紧跟杀手步伐,大学的课程都是浓缩的灌汤,哪能面面俱到.
OOA借回来了, 我决定用两个星期读完它, 用太多时间读不划算, reading list太长了. 不读? 不定什么时候又要遇到呢? 这个故事告诉我们,做事要趁早,青少年读物就要青少年的时候读完.
(回头看见书架上的TIJ,有点汗颜, 得抓紧读了)
introduction很有意思:
OOA--Object-Oriented Analysis--is based upon concepts that we first learned in kindergarten: Objects and attributes, classes and members, wholes and parts. Why it has taken us so long to apply these concepts to the analysis and specification of information systems is anyone's guess--perhaps we've been too busy "following the flow" during the heyday of structured analysis to consider the alternatives.
看来这个债,欠得有点久了.
另外引用了大英百科里关于"Classification Theory"的一段话, 大致讲人类认识世界,一直使用的三种组织方法包括的思想:
1.对象和他们的属性之间的区别;
2.对象和他们的组件之间的区别;
3.不同对象间不同点的形成/构成;
基本上就是区分对象的思想.
OOA发展的初始阶段, 又是与飞机有关的项目, 一票人(DFD Team, Data Flow Diagrams)利用流程图全面的解构functions, 并作为后续规范的框架; 另一票人(the "data base team")分析系统所需的信息/数据,然后建立信息模型(就是实体关系图Entity-Relationship Diagram, 或者语义数据模型 (Semantic Data Model). 随着项目的推进,他们不断发展这种组织方法. DFD team 困扰于解决一些对空间理解的基本问题, 诸如挡一个控制器关闭了分机对另一个控制器的反应器, 到底会发生什么. 相反的, the Data Base Team进展得相当不错,深入理解了对空中运输的控制. 但是两票人的成果并不能很好的吻合; 更糟的是, 二者相互矛盾. 按照原理, 这两个模型应该在某种程度上结合. 在项目进程和预算的压力下,这两个半成品被带入到初步设计中, 项目组希望矛盾能在这一阶段得到解决.不幸的是, the "Data Base Team" 被人厌恶, 甚至被认为是麻烦的制造者; 很多人不得不为这个不成熟的解决方案买单.
看完这段历史,进一步加深了的一个印象.为什么每一门课都要从历史讲起?好像国内的许多课程都浪费在了介绍历史上面,如果都能写的哪怕像OOA这么意简言骇,也不至于每每渐入佳境的时候就得嘎然而止.
基本上, 例子告诉我们,很久以前人们就在尝试用DFD和ERD来做设计和分析, 但是过分分离的两个部分,导致了后期结合时的困难. 另外,用DFD对function分析,并不能很好的勾画出对象的轮廓,所以上面例子中DFD team的那个困扰,在我看来,就是对象中method相互间关系的分析问题. Data Base Team走得很顺畅,却给整个项目带来困扰,这倒是有点意思, 作者认为他们常常忽略了很多关键的问题.这是否来自于他们对复杂function的忽视呢 ?
当然,最后总结是作者把OOA运用于实践, 获得成功.主要是把notations 和 strategies结合, 首先帮组分析员对问题空间有足够的理解, 然后在健壮的框架下加入运作需求(processing requirements).
(to be continued)
