面向对象之路

我的面向对象之路（一）

这是两年前开始钻研ROSE的一篇入门文章，希望能够作为登门之作。
   
                        采用ROSE分析的流程分析
1        方法论和ROSE（废话篇）
最近讨论CMM比较不多了，我是入门级水平，以前是完全面向功能的开发者和管理者。我听说ROSE是个好东西，于是就装了一个RATIONAL ROSE，心想就可以象VC++那样搞几个例子来玩一玩了，可以半天不入门。哦，原来还要知道UML，统一建摸语言！ 看了一段，好象UML是什么东西还不清楚，于是UML是OOA的大统一，看样子还得对OO，如何OO了解一下了，于是翻开了《面向对象的系统分析》（邵维忠、杨芙清）。哦，人家分析真象是切菜，一步一步，好清楚呀！于是又准备上路了，恩，好象还是云深不知处，怎么办？好象论坛最近在RUP，是不是对分析流程不清白，于是又来了个方法论补课。现在想来，我还是对RUP一知半解，下面的分析思路纯属老路。
   静下心来，想想ROSE、UML、OO        、RUP、CMM这些东西的关系其实还是有层次的，好象论坛上面对于高层讨论比较多，下面讨论比较少，但是其实这些层次的东西又不是独立的，好象相互关联。
   第一层：ROSE应该属于最上层：一种表示我们分析的工具而已，其实我认为WORD也是一种，我们以前的土办法就是，只是ROSE的方法论是UML。
   第二层：UML：比ROSE高一点，是一个OO的具体化，是OOA方法论在实践中的体现而已。
   第三层：OO：是一种分析问题的方法论，据说是好东西，读《面向对象的系统分析》感觉不错，但我觉得它不过是一个方法论，就是我们的问题域要搞清楚，好象流行的方法论就是功能分析法、数据分析、对象分析那么几种，只要选择一种适合于分析（当然OO还是最牛的）了。
   第3．5层 RUP：好象不知道怎么和OO来区分，从方法论上讲应该是平级的，可能稍微高一个小小层次，即如何运用OO的方法论的具体工具来实践出一个产品的流程是什么，直到现在我还在关心这个流程，对于我们搞项目管理的就比较关心先干什么，后干什么，什么都要经验的话，我觉得方法论就没有存在的价值了（如果谁有这方面的道道，帮忙理理）。
   第四层 CMM：我一直认为CMM是在这些里面层次最高的，它是一个超脱具体产品的方法论，我觉得该叫方法论之方法论吧，即我不管你是用什么OOA也好，还是SA，我认为只要遵照我的方法论，你就能够把握软件产品的可控制性。它主要是从管理的角度上的东西。最近我们公司在搞ISO，觉得CMM虽然高一些，但是从思想本质上两者是类似的，只是强调的方面和重点不同而已。CMM我的认识应该还是软件过程的复用的一种总结吧（其实现在好多软件的东西都是围绕复用这个目的和概念在做文章呀，只是层次不同而已罢了）
   第五层  CMM+：我想讨论一点更高的问题，我觉得CMM的东西有些管理的东西在里面，但是还是一个主要面向技术的东西，应该有比它更高的概念，即如何建立一个组织来完成一些产品，达到获利的目的，那么可能要建立制度、组织，CMM的制度目标不过是其中的一个子集而已。一个组织，建立一个理念，在此理念上建立组织文化，制度，而每个制度又来自不同领域的方法论。这些道理应该和CMM是一脉相承，只是CMM关注的是技术领域，因为到家都是技术方面的人，视野所在罢了，我以为人应该更全面的认识我们的世界，寻求突破。（好象是大堆废话，大家可以不看）。于是我总结到：
第六层  世界上只有一个东西：问题。我们的目标是发现问题（对于软件开发，现在软件开发的控制问题太多了，不用去发现，而且面向工程的东西就是要实用，也不需要去发现，所以我们避过了最难的一关），分析问题（对于软件开发，CMM过程化本身就是好的东西，牛东西总有道理的），解决问题（于是我们OO、UML、ROSE将最难的分析搞定后，OOD、OOP，大把程序员在学习这些东西呢，加工产品不就搞定），总结问题解决问题思路，上升到理论，于是从实践开始，理论结束，又开始新的实践了。何乐而不为？（好象到了哲学的层次）
2        关于ROSE的尝试（求助篇）
2.1        假设前提：
2.1.1        需求获取和系统分析是不同的人员。
但是我觉得这个前提太牵强，尤其象我们小公司，通常是从头到尾搞定的，这里主要是力图区别，至少从形式上分离，可以明确职责。
2.1.2        方法论已经OK
至少OO层次的方法论基本书看过几本好书了（要不然，建议还是先理论吧）。不要再学我摸索ROSE的过程了，当然如果对RUP、CMM从理论上熟悉在动手是最佳选择了，如果我还在学校里，我绝对会先把这些东西搞定再实践一吧的（可惜人在江湖）
至于UML、ROSE当然要在OO之后马上对号入座一把。
2.1.3        对我的摸索过程的否定思维
不要相信我的这一套东西，全是自己纸上谈兵来的，尤其需要大家批判，建议大家将理论批判文章（长一点、系统点，我老觉得论坛上面的小短篇浪费大家眼球，如鸡肋）直接发给我([e-mail]，顺便公布小名：黄坚)或到论坛。
2.1.4        我的过程的说明
先需求获取，获取到对大家要干什么有个基本印象了！
然后抽象出基本的对象
然后再利用基本对象来和用户讨论流程
流程不是目的，只是手段。
最后将流程等东西细化到类中去（服务或方法）
这个过程是反复的过程，本身在逻辑上又蕴涵了需求获取和系统分析两个相对独立的过程。
哎，怎么把握呀！好象很难呀！RUP也讲得太复杂了，半天搞不懂，老板又比RUP明了多了，明天交货！
于是我总结一点心得：目标要明确。无论我要完成哪个阶段，我只要要明确在阶段我要得到什么。
OOA的目标应该是很明确的：获取对象并且将对象特征和对象关系搞清楚。（对于ROSE的核心就是类图，所以我们的一切是以如何获取类图，如何完善类图，如何将类图转化为实现OOA到OOD）至于你是怎么从问题域搞清楚这些东西的，怎么抽象的，那叫过程，你自己去摸索吧（RUP应该有用了）。Use case 之类都是补充和辅助，不是结果的东西，是过程的，千万要明确呀！
而且这个思维一直跟踪着我去把握整个OOA、OOD、OOP，即我在考虑下一步之前我先要明白目的是什么，我的最终结果是什么，这样可能会不至于使自己为了UML而UML，或OO而OO了，达到目的，就收兵，适可而止。这也算是软件领域的度的问题把握吧
2.2        需求获取过程（终于可以开始了，不要失望）
2.2.1        需求获取的目标是什么？
    第一：向用户和公司决策层明确双方的系统责任。
即向他们用简洁的方式说明我们系统要干什么，什么是我们系统将提供的。最好采用图形形式语言。可以不考虑实现细节。但是最好考虑可能的扩展可能性，比如某个功能是合同中没有提到的，但是系统应该考虑问题域的可能情况，作为系统分析设计的一个可扩展性的考虑因素。
第二：向系统分析人员说明系统责任（当然有问题域的描述了）
需求获取本身是用户和开发方交流的，但是结果又将作为设计分析方的入口。所以自然过渡是很重要的了，没有办法的，OO的优势就在这里了，我想需求获取的途径又很多，但是为了我们的OO整体方法论和我们整个过程的连续性，我们在描述系统责任时，可能也要采用一定的OO去引导用户提出系统责任，但是应该明确我们需求人员应该有部分系统分析人员参与（主要把握总体方向，看来要分家也不是那么容易呀）。
2.2.2        如何获取需求？
在论坛上看到了一些CARD，我一直没有这方面的资料，我们现有的功能分析法就是用需求调查表搞定，所以我想还是需求调查表（好象ROSE里没有这个东西，PLAYCASE里好象有）吧，只是我们问题设计改变方法了，不再是什么某某功能的说明了。我喜欢量化问题，一步一步来：
第一步  问题起点
   目的：对我们可能要设计一个什么系统有一个朦胧的印象，知道大象有几只脚。
   我们的问题，应该有个起点，或者一个意向，或者一个合同，或者一个标书，或者一个系统初步方案。这个起点其实确定了系统的总体基调，是我们需求获取的根了。应该好好琢磨琢磨，最好了解相关的问题域概念，比如：小学教育，就应该对教育中可能的对象，相关的类型的了解。（因为抽象需要我们对问题域有一定的了解）。可以说先磨刀把。
   这个我认为可以写一个大的USE CASE，系统是个黑匣子，外面是我们的用户，然后用文字来描述我们系统要干什么。至于具体细节怎么描述，到后面再说了。

第二步 问题的范围
目的：是不是要分为几个主题来调查？如果有，如何划分主题？
先从用户交互开始，设计一个有关系统主题讨论的会议作为开题吧。这个会议应该对我们系统的基调进行定位，最好有行政参与。
调查表内容：有哪些人应该参与系统调查、干什么、什么时间、领导希望系统的定位、每个部门的职责、系统的功能总体说明，主要是用户的期待了。具体的表格应该是很明确的，与项目无关的形式（要不然怎么叫CMM）。
这一步主要是明确我们的系统的规模，主要是经验问题和公司的实际。这个在ROSE里应该可以直接用所谓包的概念来解决。
自我感觉就是先来个0层USE CASE ，然后对于每个场景用一个包来描述。当然也可以把整个系统的所有场景描述再一个0层图中。至于下面的层次，1层，2层。。无非就是包的迭代。（此处层应该是级别概念）
但是对于具体领域可能这个划分还是有讲究的，好象现在的3层（这里的层是平行概念）模型比较流行（至少微软的VM就以此为主要概念）。我觉得划分的目的其实主要是为了描述清晰，方法可以灵活。
这里有个麻烦就是主题交叉怎么办。我的感觉是尽量独立，实在不行，那就让一个主题交互的部分独立为一个主题吧，好象对于OO还是系统分析都清楚一点。

第三步 开始一个主题分析了
目的：用图形或者文字的方式描述系统要干什么？主要要明确谁用系统（ACTOR），干什么（用例）
看样子。
又要反复调查了，当然还是调查表。（看样子调查表的形式很重要）这个阶段的调查表我想和ROSE的USE CASE图是紧密结合的，哈哈，ACTOR，用例（一般描述为事件流）。反馈给用户可以整理成USECASE 图，这样是吗？希望用户回答是是是。
但是这么容易吗？其实不然，难在一：到底要调查多细， 对于复杂的流程是到分析阶段去搞清楚（还是要问用户）还是现在就问明白。我的理解是既然两个阶段明确了，就应该从流程上搞清楚。套一句话，把系统的流程黑匣子打开。
当然我的话还是有层次的，首先应该不考虑系统的内部，应该是考虑系统的外部，系统是黑匣子，我们的系统是被安装在实际流程中的一个环节。我们应该先描述清楚整个问题域中与我们有关的部分，并且标记什么是我们的责任。
打开黑匣子是在这个后面，具体我们系统责任的细化。系统里面可能的细化工作本来是系统分析人员的事情，但是好象我觉得责任定义还得问问我们用户，明确一下，要不然系统分析人员等下又来问我门需求分析人员了。对于事件流（一般是文字表述）不能够说明白的，用用顺序图和协调图吧，但是没有必要把一些分析时产生的对象弄进来，而且还可以把一些不是系统内部的对象放进来，比如实际的流程中的其他相关流程。这里可能要抽象一下对象，应该叫所谓实体对象，这里看来可能可以ER一把了。
不要忘记我们的目的。
2.2.3        劳动成果
几个主题的USE CASE VIEW中的包包（当然有个总图来导航）。
每个包包下用例图的描述，角色、用例、还有事件流图，可能还有顺序图、协调图。
    你 系统责任清楚了没有？
2.3        分析过程
2.3.1        分析的目标
从USE CASE VIEW中推出logical view \component view\deloy view.
开始的前提中应该是说明白了的。就是一个核心的类图了。
2.3.2        分析的过程
      
还是老习惯，分析量化（BTW，好象老外对分析挺重视量化和形象化的，ROSE就是一个证明，CMM也是，也我们更愿意分析神秘话，不愿意将可能的东西去量化，而是强调经验和感觉，正如扫雷游戏中不愿意去最大可能推理，而愿意去在没有要赌一吧的时候去赌一吧，所把握的大小肯定比不过人家）
第一步  还是主题划分
     目的：包来划分我们的范围。
最好是和需求时差不多，当然可以不同了。实现的时候在ROSE里还是包，包中的东西时类图。类图当然还是分层次的。

第二步  主题类图
分层次的类图。
类图应该先找可能的类，从USE CASE中、事件流中、顺序图中找。
如果发现需要抽象新的类，选择吧。最好是加入一些新的对象继续用升级顺序图或协调图。
类的细化：类的属性、方法（找事件流和交互图吧），好象可以用什么状态图、活动图来描述我们的类了，不要拘泥于类图了。
类的关系：当然还是上面的老底。其实从实现中主要是类图，但是从逻辑上顺序或协调图比较理想。但是为了OOD，还是在类图上好好描述吧，继承、聚集、联系、消息发送的关系。


第三步  可能的返工
      需求获取并非完美无缺，分析时候发现问题了，怎么办，还是和需求人员（或者成为业务分析）一起和用户交流清楚了。
第四步  该考虑实现了
      目标：组件图（可以变为代码了），构架图（工程安装、测试、开发人员心中有谱）
我觉得组件图、系统构架是水到渠成的了。没有必要细化说明了。

事后检讨：其实类图的分析是最为艰难和需要智慧的，但是因为水平无法讲很多，希望有高手从整体流程上根据自己的示例好好讲讲，重点讲讲如何通过ROSE来把握流程，如何来抽象类，把我们的讲解也量化吧。

一个需要帮助的时代，一个需要思想的人！  2000年12月22日晚于 广州！

原文地址：http://www.itpub.net/thread-70157-1-1.html#