SoftEng 版 (精华区)

发信人: really (跨越2000), 信区: SoftEng
标  题: ROSE介绍 （二. UML的建模思想）(转寄)
发信站: 紫 丁 香 (Wed Apr  5 10:28:15 2000), 站内信件

发信人: HansB (Beanie豆子), 信区: SoftEng
标  题: ROSE介绍 （二. UML的建模思想）
发信站: BBS 水木清华站 (Thu Nov 20 21:38:44 1997)

******** 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交换一系列消息来使用系统的功能。  
   二者从语义上来讲并无二至，但是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只是一种将关系比较紧密的成分组织起来的一种方    
老幺：在UML中，Package只是一种将关系比较紧密的成分组织起来的一种方
      式。ROSE的Logical View中的包是用来组织类的，它在Booch的方法中
      被称为Class Catalog，而Component View中的包是用来组织部件的，
      二者基本没什么关系，不过可以把逻辑包映射到部件包上，这就是说
      ，这个逻辑包中的类是由这个实现包中的部件实现的。
小灵：ActiveX和Java现在都有一种称为CAB文件柜的文件，其中打包了若干
      个Control或者Applet，是不是有些象实现包？
老幺：我想是的。
小灵：那实施图呢？
老幺：实施图描述了软件系统将要运行的环境，包括各种计算资源、设备和
      这些设备之间的连接。实施图还描述软件系统的各个进程在这些资源
      和设备上的分布情况。
小灵：这又是赶网络和分布式计算的时髦喽！
老幺：嗨，我们搞计算机的，就是一辈子赶时髦，做一辈子花花公子。
小灵（伸了个懒腰）：啊…… UML还挺全的嘛，除了测试，它都包了！
老幺：测试可以用Rational的黑盒测试工具SQA、白盒测试工具Purify呀！
小灵：得啦，你少来为Rational做广告啦！
老幺：不过说实话，人那东西做的确实不错。
小灵：老幺哥，谢谢你给我讲了这么多，真是让我茅塞顿开呀！
老幺：别客气。
小灵：我要回家了。下次我们再侃ROSE。
老幺：Bye-bye！                  

--
※ 来源:．紫 丁 香 bbs.hit.edu.cn．[FROM: 202.118.227.122]