关于Rose的对话

核心提示：* ROSE介绍 （一. 面向对象建模） * 面向对象建模的概念是理解ROSE这个面向对象的CASE工具（嗨嗨，等等，关于Rose的对话，什么是CASE？-- CASE就是Computer Aide-d Software Engineering，即用计算机帮助人们来创建软件，让大家下载好了， 老幺：太好了，使软件生成过

　　***** ROSE介绍 （一. 面向对象建模） *****

面向对象建模的概念是理解ROSE这个面向对象的CASE工具（嗨嗨，等等，什么是CASE？-- CASE就是Computer Aide
-d Software Engineering，即用计算机帮助人们来创建软件，使软件生成过程尽量自动化）的基础。我们做软件，不过是用软件来刻画客观事物及其联系。人脑中形成了对客观世界的正确熟悉之后，假如能正确的映射到软件成分上，那么软件就一定是对客观事物的正确描述和映射，因而是正确的。假如这个过程中出现了问题，无论是在人脑熟悉阶段（这不就是需求分析吗？）还是在人的熟悉到软件成分的映射阶段（这不就是软件设计吗？），都会使软件失败。 面向对象的思想为这种建模提供了强有力和直观的支持（唔？--客观世界有子程序吗？但是客观世界有“学生”这个对象，也有“课程”这个对象。瞧，面向对象对客观世界的描述是不是比结构化方法更直观，更好理解呀？--那当然啦！）。长期以来人们一直在试图创造一种面向对象的可视化的语言和方法，使建模人员能更加直观和严格的描述客观世界，并产生了一些流派，如Yourdan和Coad的OOA、OOD，Booch的方法、Rumbaugh的OMT、Jacobson的OOSE方法等。历史发展到今天，Booch、Rumbaugh和Jacobson一起合作，吸收了各种流派的优点和其他一相关领域的成果，终于创造出一种较成熟全面的面向对象建模语言--UML（话说天下大势，合久必分，分久必合）。并把UML融入Rational公司的CASE工具ROSE之中。ROSE试图用UML语言支持软件开发的大部分过程（测试除外）的建模。在ROSE中，只要你用UML描述了软件的各个成分（也就是为软件建立了一个面向对象的模型），ROSE就为你生成所需的大部分源代码（呀！这不是可以省很多时间吗？可以多玩会儿Quake啦！

--更重要的是，从此以后你就可以充分利用OO的诸多优点啦--象模型稳定性、重用等等，这将大大降低软件维护和升级的成本，别忘了，维护和升级成本往往会占总成本的百分之七、八十呢！）。

下一篇文章我将向大家介绍UML的建模思想。

*****ROSE介绍 （二. UML的建模思想）*****

看到大家对ROSE和UML这么感爱好，豆子真是好激动啊！接下来我想为大家介绍一下UML的建模思想.正好我的两个朋友--老幺(1)和小灵(0)也正在学ROSE和UML,我们一起来学好了.Let´s go!

小灵：老幺哥，现在你在捣鼓什么呢？
老幺：小灵弟，我刚刚从清华BBS的虫虫那搞到了ROSE 4.0和UML 1.1，正在闭门修炼呢!
小灵：嗨，这真是芝麻掉到针眼里--巧极了！我也从那搞到了一套。（小灵和老幺亲热的握手。）
小灵：UML里面的概念太多了，真让人头大！还有那么多花花绿绿的图 图，我现在是狗咬刺猬--无从下口了。老幺哥，能不能帮我一下？
老幺（大搔其头）：确实，我也有同感。可是，我从哪开始讲呢？
小灵：呃…… 最好是从需求分析开始顺序侃下去。
老幺：好吧。小灵弟，假如你拿到了一个项目,想用OO建模的方法来建造,第一步要做什么呢？
小灵：我以前看过Youdan和Coad的OOA、OOD的书，我想应该先分析问题域的 对象吧？我从问题域的特点和自己的经验出发，分析问题域都有哪些对象，它们的关系如何，and so on。但是这总是给人一种“玄而又玄”的感觉，全凭经验和感觉了。而且把这些图图拿给用户看，他们是丈二的和尚--摸不着头脑了。
老幺：着啊！这就是USE CASE的用武之地了。
小灵（兴奋的）：对了对了，快给我讲讲这个USE CASE是个什么东东.我连怎么翻译都不知道。
老幺：我也不知道怎么翻译，所以干脆就不翻了。本来就是人洋人的东西，还是入乡随俗吧，唉。USE CASE最早是由Rational三剑客之一的Jacobson在他的OOSE方法中提出的，由于其非常有用，现在遗传给了 UML。OO思想曾经遭到过一些人的批评，理由是用户关心的和理解的只是系统的功能，他不可能去学习你的OO模型，所以虽然OO建模减小了分析设计和编码的鸿沟，但是却和用户的距离拉远了。
小灵：批评的很中肯呀！
老幺：是啊。我觉得传统的OO建模在用户交流方面还不如功能分析做的好呢 ！不过，有了USE CASE，情况就大大改观了。一个USE CASE是系统体现给外界的一个连贯的功能单元，系统外部的人员或者其他系统（就是Actor啦！）通过和USE CASE交换一系列消息来使用系统的功能。
小灵：唔…… 这和功能分析没什么两样啊？
老幺：别急。注重USE CASE是由系统中的对象相互发消息、相互作用来完成的，而不是和功能分析一样是由子功能之间的调用实现的，这样，就 弥补了OO建模和用户之间的裂痕。
小灵：纯粹是让用户逼出来的。
老幺：用户就是上帝么！不过USE CASE的作用也不光是和用户交流、做需求分析，它还可以指导测试用例的选择、用户界面的设计甚至用户手册的编写等等工作。
小灵：呀！用处这么大呀！
老幺：除了USE CASE分析，第一步要做的工作也包括你刚才提到的问题域对象分析，其实是类分析。USE CASE分析和类分析可以相互支持、补充。
老幺：USE CASE和初步的类分析做完之后，我们就可以用得到的Actors和类的对想来描述USE CASE的实例了。这样就产生了交互图Interaction Diagram。
小灵：老幺哥，这次你怎么会翻译了？
老幺：尽力而为（主要是中文输入和英文输入换来换去太麻烦，嘻嘻）。交互图分两种--顺序图Sequence Diagram和协作图Colaboration
Diagram。它们一起来描述系统的动态行为，就是对象之间的交互。
小灵（哭丧着脸）：这两个图图没什么区别嘛！反正我是看不出来。
老幺：sequence diagram和colaboration diagram都是描述系统动态行为的图。二者从语义上来讲并无二至，但是sequencediagram强调时间，时间在其 中作为一个轴显式的存在，所以sequence diagram用来描述实时行为最为合适。而colabrationdiagram在描述了系统中对象及其关联的情况下对象之间的消息传递，突出的是动态行为发生的语境，时间在其中是隐式描述的（用1、2等消息标号）。二者是对同一系统动态行为的不同视角的描述，可以加深建模人员对系统动态行为的理解。
小灵：原来如此。那么，我可以画多个交互图啦？
老幺：是呀！原则是说，Actors有多少行为，就要画多少交互图来描述系统 内的对象是怎样配合工作完成Actors所要求的功能。
小灵：我的老妈呀！那要画多少图图呀？
老幺：不过，实际上不需要画这么多的。只需要把最重要的和最难理解的USE CASE实例，唔，对了，USE CASE的实例叫做剧情Scenario，描述清楚就行了。
小灵：Siiiiii... 这个词儿怎么发音？
老幺：/si´na:riou/。
小灵：/si´na:riou/、/si´na:riou/、/si´na:riou/。那没画的图图怎么办呢？
老幺：我们只需为每个类做一张状态图State Diagram就可以了。类的状态图描述这个类的对象在外界事件发生时状态发生怎样的变化，产生哪些 动作等。外界的事件包括其他对象发来的消息、各种异步事件等，产生的动作包括向其他对象发送消息、产生异步事件等等。这样，把状态图和交互图综合起来看，就可以对系统的动态行为有一个较全面深刻的理解。
小灵：分析基本上可以了，现在接着讲设计吧。
老幺：我们早已经开始讲设计啦！
小灵：唔？
老幺：OO建模的好处就是不用在分析和设计之间划一到鸿沟，设计只需要在分析的基础上进一步根据实现系统的限制不断进行各种成分的扩充和细化。
老幺：具体的设计完成之后，我们就可以对系统的实现进行建模了。在UML中，这是用实现图Implementation Diagram来完成的。实现图分部件图 Component Diagram和实施图Deployment
Diagram两种。
小灵：这个部件Component和时下流行的软件部件，象java Applet啦、ActiveX部件啦，有什么关系？
老幺：这个概念在Booch的方法中就有，不过那时叫模块Module。象某个子程序啦、某个任务啦等等都是Module。我猜UML为了适应软件部件的发展 ，用Component来扩充了Module的概念，使UML和软件部件的思想结合的更加紧密。
小灵：部件图和实施图有什么关系？
老幺：部件图描述了软件实现的组成和结构。它把软件的实现分成一个个的部件，把部件组织成包。分析设计时用来组织类的逻辑包可以映射到实现的部件包上，而类可以映射到部件上。
小灵：对了，学ROSE时,老是搞不清Logical View中的包和Component View中的包有什么区别。
老幺：在UML中,Package只是一种将关系比较紧密的成分组织起来的一种方式。ROSE的Logical
View中的包是用来组织类的，它在Booch的方法中被称为Class Catalog，而Component View中的包是用来组织部件的，二者基本没什么关系，不过可以把逻辑包映射到部件包上，这就是说，这个逻辑包中的类是由这个实现包中的部件实现的。
小灵：ActiveX和Java现在都有一种称为CAB文件柜的文件，其中打包了若干个Control或者Applet，是不是有些象实现包？
老幺：我想是的。
小灵：那实施图呢？
老幺：实施图描述了软件系统将要运行的环境，包括各种计算资源、设备和这些设备之间的连接。实施图还描述软件系统的各个进程在这些资源和设备上的分布情况。
小灵：这又是赶网络和分布式计算的时髦喽！
老幺：嗨，我们搞计算机的，就是一辈子赶时髦，做一辈子花花公子。
小灵（伸了个懒腰）：啊…… UML还挺全的嘛，除了测试，它都包了！
老幺：测试可以用Rational的黑盒测试工具SQA、白盒测试工具Purify呀！
小灵：得啦，你少来为Rational做广告啦！
老幺：不过说实话，人那东西做的确实不错。
小灵：老幺哥，谢谢你给我讲了这么多，真是让我茅塞顿开呀！
老幺：别客气。
小灵：我要回家了。下次我们再侃ROSE。
老幺：Bye-bye！

***** ROSE介绍 （三. ROSE的使用）*****

这些天来，小灵和老幺都在认真学习ROSE和UML。这一天，老幺来到小灵家来做客，看到小灵正在玩ROSE。
老幺：小灵，ROSE玩得怎么样啊？
小灵：嘿，老幺哥，你来啦。请坐。（小灵给老幺让座、倒茶）
小灵：老幺哥，我发现假如UML的基本概念把握好了,再加上一些例子，ROSE其实并不难学嘛。
老幺：那好啊，我们来切磋切磋。你来给我介绍一下你的成果吧！
小灵（清了清嗓子）：OK！我们先来看一看ROSE的界面吧。（老幺和小灵坐到电脑前）
小灵：ROSE的界面基本分成三个窗口：浏览窗口browser window、图形窗口 diagram window和文档窗口document diagram。它们共同来创建和操作模型。浏览窗口主要是来创建各种模型元素，并在模型中遍历和漫游。图形窗口主要是用来绘制和显示模型中的各种图，而文档窗口用来书写和显示模型元素的描述。
老幺：对.我觉得,很重要的一点是要搞清楚我们所建的模型和我们所见的模型之间的关系。UML中的各种图不过是从不同的角度来把模型可视化而已.同一个模型元素,可以出现在多个图中。
小灵：这就好象同一个意象，诗人用诗歌的形式表现它，画家用绘画的形式表现它，而作曲家用音乐的形式来表现它一样。
老幺：ROSE中的浏览窗口、图形窗口和文档窗口都是同一模型的不同表现形式而已，它们用不同的方法组织和表现模型的元素，使我们能更好的构造和理解模型。
小灵：好，我们拿到一个项目时，首先应该考虑什么呢？
老幺：当然是考察用户需求，烹制一些USE CASE喽！
小灵：在分析USE CASE之前，要先分析ACTOR。就是分析我们系统的用户和将与我们的系统交互的外部系统。因为真是它们的需求，才让我们确定 我们的系统要具有什么样的功能。
老幺：在ROSE里，怎么创建ACTOR？
小灵：一般来说，创建模型元素应该在浏览窗口中进行。就是在浏览窗口中选中Use case view
、Logical view、Component view或Deploymentview文件夹，单击右键，选择New菜单，创建所需的模型元素。
老幺：我在USE CASE图里不是也能建ACTOR吗？
小灵：不错。但是我更习惯先在浏览窗口中把模型元素建好，然后再把它们拖到相应的图中。这样更能体现图是模型的可视化表现这个思想。
老幺：我觉得那种方法都可以。
小灵：有了ACTOR之后，我们就可以为每个ACTOR分析它们所要求的系统应该具有的功能，也就是USE CASE。在创建了USE CASE之后，我们需要把 ACTOR和USE CASE拖到USE CASE图中，并用箭头表示它们之间的交互关系。
老幺：画完了USE CASE图之后呢？
小灵：USE CASE分析之后，我们要考虑USE CASE的实例senario的事件流程，这通常使用交互图（包括顺序图和协作图）来描述。在这些图中，我 们用对象和对象之间的消息流来描述senar-io，从而发现要完成USE CASE，系统必须具有哪些对象，以及这些对象应该响应哪些消息。
老幺：这比Coad方法中发现对象的方式更具操作性。
小灵：当我们把这些senario分析完了之后，我们发现了许多对象，下一步，我们就要为这些对象定义相应的类了。
老幺：这些类是在Logical View中定义和显示的喽！
小灵：对，我们在Logical view中定义这些类，然后把它们组织成包。创建类图，把包、类之间的关系绘制在图上，建立起系统的静态模型。这些类将是系统中最稳定的元素。
老幺：go on.
小灵：我们可以为每一个类创建一张（也只能创建一张）状态图。
老幺：怎么操作？
小灵：在浏览窗口中选中一个类，选右键菜单上的state diagram，就可以创建这个类的状态图。状态图描述了这个类的对象在外部事件的影响下的状态改变。
老幺：我们不停的细化和修改这些元素，直到我们可以很轻易的实现它们。
小灵：在实现阶段，我们在ROSE的Component view中定义一些实现包。这些包的定义要综合考虑逻辑包的结构和实现环境。在实现包中我们定义一些模块module，模块可以是子系统、子程序、任务等等实现上的划分。然后，我们把逻辑包映射到实现包上，把类映射到模块上。这样就把系统的逻辑结构和实现结构挂上了钩。
小灵：最后，我们还可以为软件系统将要运行的环境定义一张实施图deployment diagram。
老幺：我们把模型建立完了之后，可以使用ROSE的代码自动生成功能为我们自动生成大部分的代码。并且ROSE的双向工程Round-Trip Engineering功能，可以保持代码和模型的一致性。
小灵：怎么样，我学得很快吧？
老幺：不错不错。
小灵：主要是要一步步过一个例子。我觉得有Demo1.mdl、Demo2.mdl、Rosemode.mdl和Wlkthr
_r.htm的例子不错。按照Wlkthr_r.htm的说明 ，一步步做下去，很快就能把握ROSE的基本操作。我已经把 Wlkthr_r.htm文件翻译成中文了。
老幺：那你还不把它贴到BBS上，让大家共享？
小灵：太大了，而且还是Html格式的，挺不方便。
老幺：没关系，只要有用就行。
小灵：这样吧，我在BBS上贴一个，再把HTML文档上载到202.197.12.252的目录/incoming/ro-
se_cpp下，名字叫CWlkthr.htm，让大家下载好了。
老幺：太好了。
小灵：我这就做。