用好UML&ROSE
前言的前言
此文是为我们项目组写的，因为在需求分析阶段的不确定因素，将一些需求的人为分块，最重要的是我们这几个分析员的经验缺乏，导致得到的分析文档又长又臭，相当混乱。又鉴于OOA、OOD的趋势，所以项目组决定在下阶段引入UML，我也是现学现卖的写了下文，可能会有些问题（因为有特殊的前提，很多都是针对项目组下阶段工作的，而且项目组成员对UML都有粗略了解，所以有些地方看起来会有些凌乱），希望读者能多批评指正，在下先谢谢了。
前言
为什么要引入UML……，为了把产品作好。就这么简单，我认为我们做任何选择的时候都应该把这句话重新考虑一下。
那位问了：奥，引入UML就能把产品做好了？
问的好，答案是不尽然，引入UML只是我们作好产品的必要条件，而不是充分条件。
那位又问了：既然都不尽然了，还引入个屁啊！
一针见血，特别是这个屁字……，好！凡事没有必然，我们也只能是逐渐的向正确方向无限的接近。我们现在离正确方向还有多远，我想很远，甚至有些偏离，我们是在为了用OO而用OO，而不是用OO来实现OO。很绕嘴吧，我来解释一下。我们从需求调查到需求分析一直在沿用过去的做法，就是一直在确定“怎么做”这个问题。可恨的是现在几乎所有的开发工具都要求准确提出“谁来做”、“用什么做”、“做什么”这些问题，没办法，于是就绞尽脑汁的把些“怎么做”，跟“谁来做”、“用什么做”、“做什么”活生生的搅和到了一起，给“谁来做”起了个名字叫作类，管“做什么”称为类属性，“用什么做”称为类操作，把“怎么做”捣烂，一部分塞到类操作里，一部分用于类和类之间的粘合剂。这样也成了个产品。问题很多，例如健壮性，可维护性。你想，给你个所有部件都是粘合起来的东西好维护，还是一个自然扣合的好维护啊？我们更希望一开始就找到各个主要部件，而且把这些部件造的形状整齐，然后制造部件之间的扣合部件，实在造不出扣合部件，咱找颗钉子也不错吗。把这些东西装到一起容易，拆开也方便，而且还可以把钉子给别人用，多好啊。我们使用UML其实是想用它来配合我们OO设计方法（当然UML不是唯一的工具）。而现在支持UML比较流行的工具就要数ROSE了，这毕竟是个趋势，此处就不多说了。
那位接着问：我们都不会啊，学起来肯定很麻烦，会影响进度吧？
回答是肯定的，UML不是万能的，还是需要有一定经验来配合的。就想双节棍一样，在李小龙手里可以虎虎生威，在我手里就只能打到我的头了，但我不去尝试的练习，那可能一直都不会生威了。现在不去用，那就永远都别去用了。当然我们用UML不是为了虎虎生威。
这人真是没完没了：学会UML就学会OOA，OOD了吗？
答案是否定的，UML就象C或C＋＋一样，只是一门语言，而你想要编程的时候游刃有余，还必须学好数据结构和算法设计。OOA和OOD还是要另外去学的。在这里我还是要多唠叨两句，希望大家不要把精力都用到UML上，多看看有关面向对象设计的软件工程书籍才是主要的。
这人烦不烦啊：你讲UML和ROSE，讲不讲OOA和OOD啊？
嘿嘿，不好意思，俺也不会，现在的设计方案也大多借鉴RUP的内容，所以，大家自己研究玩去先。
好，就让我们高举OOA、OOD软件工程思想的伟大旗帜，紧密团结在以项目经理为核心的项目组周围，沿着金融领域的生财之道，把建设有中国特色的UML的伟大事业全面推向21世纪。
1、补充工作
刚一开始就作补充，有点太离谱了吧。这补充是指补充上阶段应该有，并且对我们非常有用的东东――USE CASE DIGRAM，即：用例图。有什么用处？大了去了，不过我认为有三点对我们来说是重要的：
一、通过现有的找未知的，找出用例间更深层的联系，确定是否添加非功能性用例，以及是否将已知的用例拆分。
二、通过绘制用例图，可以使我们从更宏观的角度来了解整个系统的内部联系，确定哪些重要，哪些次要，以便以后对系统的自然划分，方便工作的开展。
三、方便以后与用户的沟通，以及用户对产品功能的修改。我想，我们的需求今后肯定是要改的，只是不知道会改成什么样子，所以现在就作好准备，尽量将不怎么会改的东西放到一起，免的到时候抓瞎。当然我们由衷的不希望会有大的改动。
好，咱们现在围绕用例这玩意儿来进一步的探讨。大家注意了啊，喂，那位睡觉的同学，别看别人，就是说你，注意了啊。
1.1用例图都有哪些玩意儿
咱先看看下面这个图，这个就是用例图，就是USE CASE DIGRAM。
这里面的玩意儿，我想我不说，大家也能猜个八九不离十。总结起来，也就才4种主要的图形，其它都是演变来的。
椭圆 ：就是常说的用例。什么是用例啊，“是系统执行的一系列动作，这些动作将生成特定主角可观测的结果值。”这是RUP里的定义，有点含糊吧，说白了就是“做什么”（这个“做什么”可不要跟上面提到的“做什么”混了，这里主要是说客户做什么，或客户的其它系统做什么，是对本系统宏观的解释。而不是指系统的某个功能做什么。但我们可以通过这个发现，整个系统也可以定义为一个类，类的操作就是用例，类的属性就是角色，很有趣吧。）
小人 ：也就是角色了，“定义系统用户在与系统交互时可扮演的一组相关角色。用户可以是个人，也可以是外部系统。”，这又是RUP的定义，到与我们系统中“角色管理”的角色很有些相似。是具有相同能动性的抽象的东西，说白了就是“谁”（准确的说是“哪类东西”）。角色在以后也可以被定义成类，我们的“角色管理”就可以从这里来出。
直线 ：叫做关联，…………，我找了半天也没找到关联的具体定义，那就说说我的理解吧。关联是链接角色和用例的通道。如果角色和用例之间存在关联关系，就可以连成一句话“谁做什么”。关联可以有方向，表示角色和用例之间的主要信息流向谁，这样那就话就可以变成“谁<通过>做什么<得到什么结果>”。例如图1中的预警监控子系统与行长的关联，也就是说“行长通过预警监控了解到事态严重”。
虚线 ：叫做依赖，是用于链接用例和用例之间的关系。ROSE中提供了3种基本的用例依赖关系（类，包等也存在依赖关系），分别是《include》、《extend》和《refine》。大家可以看图1中，客户管理子系统、业务管理子系统和信用分析子系统都《include》查询。当然，这些关系可以任意扩展，比如你可以添加《love》关系，让两个用例之间产生爱情，而且还是单相思。
《include》如果基本用例中有一部分功能，该功能的执行与否由它的结果唯一决定，而不是由产生该结果的方法来决定，则可以将这一部分功能分离出来，放到一个附加用例中。采用包含关系，可以将附加用例显式插入基本用例中。
《extend》如果基本用例的一部分是可选的，或对于理解该用例的主要目的来说不是必需的，那么您可以将这部分分离出来，形成一个附加用例，以简化基本用例的结构。利用扩展关系，可以将附加用例隐式插入基本用例中。
没画出来的线 ：就是泛化，我觉的可以理解为继承，注意，没有箭头的一方继承有箭头的一方。这是出现在角色和角色之间或用例和用例之间的关系。如果用例在行为和结构上具有共同点而且在目的上又很相似，则可以将它们的共同部分分离出来，形成一个基本用例（父用例）。而附加用例（子用例）可以继承该父用例。
1.2让我们用ROSE画用例图吧
有关用例图的元素大概上就这么多，当然还可能会用到象聚集、组合这样浑涩的关系后面再说。下面我们来看看这些东西都是怎么画出来的。下面是ROSE的相关界面的左半面，右半面为什么没有啊，因为右半面显示都是图1的东西了。
|
图3 |
|
图2 |
其中1表示用鼠标选择，2表示直接输入文字，自不多说。
3表示注释，往往用4跟其它的图形链接。
绘制用例图，可以在图1中的USE CASE VIEW中点右键如图2所示，NEW一个USE CASE DIAGRAM，ROSE就可以建立图1中的11，双击11就可以在上面任意的涂鸦了。怎么画法，大家自己试试吧。另外，可以在工具栏上点右键添加一些图形元素，界面友好，自不多说。需要强调一点的是在Main中删除图形有两种形式，一是直接使用DEL键删除，那样只是删除Main中的图形，在图2的目录中还可以看到；二是用Ctrl＋D删除，这样就会直接将整个图形从系统中删除了，由于ROSE回退功能甚差，所以大家在使用Ctrl＋D的时候要特别小心啊！
绘制完图形可以通过双击图形（包括各种的线段）就可以打开图形的属性表单，请看下面的两张图，怎么样，够复杂的吧，这是两个比较常用到的属性，其中图4为关联的属性，图5为类的属性。
|
图4 |
|
图5 |
图4显示的页面是关联线段鼠标拖动的停止段的描述属性，当然Role B Detail与此类似。Role中填写A端在此关联关系中所处的角色（一般不填，特别在用例图中）。Constraints中当然是填约束条件了，一些用数字符号无法很好说明的意思，您就都写这儿吧，不过最好别写的太多了。Multiplic中可以选择多重性，也就是那些1..n什么的，也可以手工输入。其它复选框、单选框可以相互配合使用的，主要使用Navigable、Aggregate、Unspecified和By Value，至于是什么图形，大家都选着看看就知道了。Keys/Qualifie中可以点击右键可以添加限定条件，也就是B端通过A端的什么与A端关联，添加成功后，会在B端显示一个有变量的方框。其实图4中的东西在绘制用例图时一般不会有太大变动，往往是变动Navigable是否被选中（说明一点，A、B的Navigable都选，和都不选，线段都不显示箭头）。
图5的页面比较普遍，几乎所有的图形都会有此页面，其它的自不多说了，见文如见意，只是那Stereotype颇有些蹊跷，可以任意改变现有图形的样式。ROSE提供了很多图形表现形式（当然，这些样式也可以通过定制工具条自由添加），但如果您老才思敏捷，想像力丰富，认为那些图形不能很好的表现出您脑子中的东东，没关系，您可以自己输入类型名称，ROSE将会在图形中用《》将这个名称框起来，表示一个类型。
1.3怎样画好用例图
其实这个问题我也想知道，这里面涉及到很多问题。
首先是客户需要什么，这是主要问题，因为我们缺少前面的业务建模的过程，而且已经作了很多的工作，我们认为的客户需求已经基本定下来了，只是在设计的时候应该尽量的留出以后修改的余地才好。
其次是设计人员的经验，哪些用例需要合并，哪些用例需要提炼，哪些用例需要拆离，哪些用例我们还没找到（包括非功能需求），以及用例和用例之间的关系，用例和角色之间的关系。很复杂吧，别急，我想按照现有的用例规约划分用例，然后再总结用例，将公共部分、无关紧要的部分提取出来，在提示栏里（左下角的框中）多进行文字描述，尽量详细的描述各种关系，多用注释，就差不多了。只是我怕到时候画的用例太多，大家看不过来啊！
大家还是一头雾水的话，建议看看RUP中关于用例、用例模型的指南部分。
2、唉，那样做太累
你唉什么唉啊，哪样做太累了！你不累吗，奇怪，总共写了30多万的文档，你不累啊，我们做的重复工作太多了，把太多的时间用到了输入文档，啃啜兮、啃啜喂。怎么去解决这个问题应该是我们现在好好讨论的时候了。我认为我们缺少一个宏观的考虑，如果把系统能够自然横向的分系统：采数据的采数据，预警的预警，管理的管理。把系统纵向的分层次：操作数据库，数据管理，预警监控，用户界面也可以。各层，各子系统之间定义好接口，给大家一发，大家互不相干，干活喽。不过以上只是最理想化的假设，因为很有可能由于层次之间存在的千丝万缕的联系，真是剪不断，理还乱，导致模块的划分不是那么明确，因此大家还是会有些累。这子系统和包当然要由把握全局的人来完成了，我们能明白那是什么意思就行了。
闲言碎语不多讲，表一表子系统和包。
2.1子系统和包都是些什么
别急，来看图6这玩意儿
|
图6 |
文件夹 ：这就是包，子系统也一样，其实都是为了将整个系统进行自然的划分。子系统与包的不同就是子系统都提供接口与其它包或类进行交互。“子系统是一种模型元素，它具有包（其中可包含其他模型元素）和类（其具有行为）的语义。子系统的行为由它所包含的类或其他子系统提供。子系统实现一个或多个接口，而这些接口又定义子系统的行为。”，这是RUP中对子系统的定义。“设计包是类、关系、用例实现、图和其他包的集合。它通过将设计模型分为较小部分，来建立设计模型。”，这是对包的定义。包/子系统是设计的结果，而不是过程，往往由程序的设计方法、使用的模式、系统的体系结构和设计人员的经验所决定，包/子系统的划分将直接影响到类的设计。
圈圈 ：这是接口，用它来抽象子系统或类，这其实是面向对象设计的一个最大的特点，体现了很强的封装性。RUP中的定义为“定义行为集（即操作集）的模型元素，该行为集由分类符模型元素（即类、子系统或构件）提供。分类符可以实现一个或多个接口。一个接口可由一个或多个分类符实现。实现相同接口的那些分类符在系统中可以互换。每个接口应该提供唯一且明确定义的操作集”。接口与子系统或类的链接要使用泛化关系（在前面已经提到了），注意，箭头一定要指向接口啊，ROSE会自动消除箭头的！
虚线 ：还是依赖，在前面已经提到了，但这里针对包/子系统再说一边。包与包之间的依赖关系由包中的类与另一个包中的类是否存在关联关系决定。不允许包与包之间发生相互依赖，如果发现有这样的依赖存在，那说明包/子系统设计的有问题，需要考虑将两个包合并或重新分配包中的类了。如果有A包和B包，A包包含了B包，那就不允许有B包依赖A包的情况出现。
2.2谁来画，谁来看
在ROSE中画包/子系统图是很简单的图2中的5看到了吧，就是它了，每画一个就会在树型目录中增加一个文件夹。当然也可以在目录中用右键添加，其它的就不多说了，用用就知道了（其实是实在没什么可说了）。当然各种图形的解释、注释也是必不可少的。
关于如何设计包/子系统，我的建议可以先横向划分，再对横向部分进行纵向划分，也就是先分成采数据、预警、管理3块。再把各块纵向分为：数据库基本操作，数据维护，数据控制，用户界面。然后把功能相同的部分融合的融合，抛弃的抛弃。我认为这里的设计工作应该充分的利用好前面产生的用例图，同时，也可以对用例图进行进一步的修改。嘿嘿，OK，大家分工开始工作了，轻松加愉快。
3、重中之重
别看上面啰哩八索的讲了一大堆，其实这才刚刚进入正题儿，画类图和用例实现图，估计把类图和用例实现图都整明白了，直接编码都可以了，不信啊，拿来我试试看。
其中使用类图来代替过去输入输出的描述，这样就更容易向程序转化，另外类图相对文字来说要直观的多，不过也不要完全的抛弃文字描述的东西，我们要时刻记住，我们画类图是为了编码，是为了让别人看明白，可千万别画了半天最后，一个描述的文字都没有，我想那样的东西只能去参加幼儿园图画展了（那个小人画的不错，蛮威猛的）。类画完了，关于类的其它图也应该有，主要的有状态图，别到时候忘了啊。
用例实现图是对用例图的延续，是将一个用例如何实现具体到几个类的对象，主要由时序图（或协作图）来表述。等这些图出来，那程序流程就有了。当然一个用例实现可能有几个事件流组成，也就对应了几个时序图了。为了能更一目了然，最好把用例实现中涉及到的类也描述进来。
怎么样，这样是不是可以编码了啊！
好，我们现在来着重将将类、用例实现的具体画法，这位同学，请你把旁边的同学摇醒，谢谢，什么？要请吃饭才摇，什么玩意儿。
3.1类图都是些什么东西，画好类图能拿奖吗？
我们来看看图7吧。这里基本上变现了各种类的图形。另外，画好类图不能拿奖，但如果类图画的明白，节省了开发时间，能拿到奖金也说不定啊。
|
图7 |
夹心砖头 ：标准类，类的定义什么乱七八糟的东西，我想我就不多说了，免的大家朝我丢鸡蛋（如果丢也可以，最好再丢2个西红柿，番茄炒蛋，饱了）。这里主要从OO的视角谈谈类的设计，其实类的出现主要是为了提高代码的重用性，其精华就表现在继承上和接口上，这是它与一般函数最大的不同，继承可以使你很方便的得到别人写的代码，而接口则可以使你对同类但不同形式的事物采用相同的操作（这有什么好处？废话，你就可以对不同事物的连续操作使用循环了）。其实对于类的设计来说，如果没有继承和接口，那还不如使用函数，至少比较轻车熟路。但设计继承和接口，还是需要有较丰富的经验才好啊，否则设计出来的东西恐怕很难接起口来，到时候来个驴唇不对马嘴才热闹呐。
棒槌头 ：边界类，《boundary》，类的一种，主要涉及角色和用例间的接口，包括界面、文档等一切可能的东西。咱再来看看RUP的解释吧“是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。这种交互包括转换事件，并记录系统表示方式（例如接口）中的变更”，怎么样，跟我说的差不多吧，还是我说的比较简洁。在我们的系统中可能主要体现为用户界面和与其它（可能有本系统）系统间传输信息的格式。奥，怪不得叫边界啊，果然是系统的边界。边界类按理说在需求分析阶段就应该出了，因为在很多地方，它将制约用例实现，甚至其它类的设计。例如在页面上打钩删除和选择进入后再删除，在用例实现上显然是不同的两种表述。我们来看看这句话“如果该类是边界类，则主角的所有需求均已满足（包括输入错误）”，也就是说边界类的设计中应该有出错处理。另外，“您只需为系统中的一些现象或者在用例实现的事件流中提及的一些事物确定边界类”，也就是说有些不确定的边界类（包括类操作），可以在用例实现时修改，当然ROSE也提供这样的方便。
天边的太阳 ：实体类，《entity》，就是现实事物在系统中的映射，例如：人，狗之类的。RUP的解释“实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用于保存和更新一些现象的有关信息，例如：事件、人员或者一些现实生活中的对象。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要”，看出外国人的总结能力差了吧。如果建模的对象，在系统中没被直接使用，可以把它当成某个类的属性来建模，或者当成类之间的关系来建模；相反，如果它被直接使用，那就义无反顾的建成类吧。其它就没什么可说的了。
咬住尾巴的蛇 ：控制类，《control》，首先是一组操作的集合，用它来协调边界对象、实体对象等，说白了就是一堆让谁（实体对象）做，和不让谁做的程序。但对于主要是为了输入、检索、显示或修改信息的简单事件流，不一定需要控制类，可以由边界类负责协调用例。控制类有效地将边界对象与实体对象分开，让系统更能适应其边界内发生的变更。这些控制类还将用例所特有的行为与实体对象分开，使实体对象在用例和系统中具有更高的复用性。在实体类的内部结构或行为发生变更的情况下，控制类几乎不会变更。好，让我们再看看RUP中对它的定义“控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通常控制其他对象，因此它们的行为具有协调性质。控制类将用例的特有行为进行封装”。可以首先为每个用例实现确定一个控制类，接着，在确定了更多的用例实现并发现更多的共性后，再对其进行改进。虽然我们的系统中，很多地方都是修改检索信息的简单时间流，但在边界类和实体类之间添加控制类，方便了权限的控制，有利于以后的维护和修改，所以使用控制类还是很有必要的。
老朋友了 ：关联，在用例图一节中已经作了相关的叙述，但对于类的关联，相对来说要复杂些个。先说这箭头，如何确定是否要箭头，方向如何表示，这都是些头疼的问题（什么？你不疼，我知道了，你肯定是木瓜脑袋）。这里的箭头可以这样理解；如果可以通过A类，沿着关联关系，直接识别B类，那就可以从A到B画个箭头，两个都能互相识别的话，那就两头都画（可以在属性页里修改），但在ROSE中将会隐藏两头都画的箭头，就这么简单，哈哈。另外关联的多重性（Multiplicity，几个A类会对应几个B类？）、关联的名称（A类和B类是怎么关联的，是亲戚，还是夫妻，如果说不明白，还可以使用关联类，就是在关联上用虚线连一个类）、接口说明（Role，A类和B类分别是以什么形象关联的，例如：一个人对其丈夫来说是妻子，对其情人来说是情人，其实也就是描述两个类是通过什么实体联系的）、限定（key/Qualifier，这个地方不同的书竟有不同的解释，不过有一点是肯定的，限定方框中的属性是关联的属性，如果限定画在A端，则往往表示1个A通过这个限定，与1个或0个B对应，）都要尽量的明确。
没画的关系， 组成； 聚集。是关联的特殊形式，这是两个容易混淆的关系。可以这样理解，组成，表示了整体与部分的关系，我们可以想想汽车与发动机的关系，汽车有且仅有一个发动机；聚集表示了群体与个体的关系，我们可以想想客户资料和帐号的关系，客户资料存在有多个帐号。
又一个老朋友 ：依赖，为什么又提到它啊，因为在这里的语意又有所不同。类之间的直接依赖往往表现为调用关系，也就是说A类的类操作用了B类的实体做参数。还有一些复杂的依赖，例如友元，不过JAVA好像没有这个概念。
关于继承什么的在前面已经说了，不过有个变体 ，专门表示对接口的实现，也是一种继承关系。
别忙咱们好像漏了点东西，状态图，来咱先看一下状态图
|
图8 |
这个图可以说已经一目了然了。圆角方框表示状态（什么状态？当然是你要描述的事物的状态了）。带箭头的线表示状态之间转换，当然转换也有转换的名字，表示在什么条件下转换的。方框中的##/****表示“当##时做****”，例如当“entry”这个属性时“更新与用户级别有关的属性”。还有很多更复杂的描述，甚至是状态图中嵌套，状态中子状态的并发，天呐，太复杂了，我想我们还不会用到这么复杂的东西，等用到的时候再研究吧。
3.2用ROSE画类注意的问题
类在ROSE中的现实可以进行设置，不同的图形、样式应该使用于不同的环境。我们来看一下类的不同样式
|
图12 |
|
图11 |
|
图10 |
|
图9 |
其实这4个图都是说“客户”这个实体类，只是采用了不同的显示方式，其中图8为Icon方式，建议在这个类被定义以后，其它地方需要调用时使用，使用时屏蔽掉类的操作和属性，给人一目了然的感觉。
图9为Decoration方式，建议在类开始定义的时候使用，使用时显示其所有的属性和操作，方便维护。
其它的图我认为可有可无，看大家喜好了。大家可以通过在类图上点击右键，在菜单中选择显示样式。图12为右键菜单。
|
图13 |
3.3怎么画好类
好，对以上的类来个小结。系统是由一系列类的对象组成的，类设计的成功与否将直接影响系统的可维护和修改性（为什么总提这两方面呐，废话，这肯定是我们今后最大的障碍了）。而往往以上几个类的设计顺序是：边界类－>实体类<－>控制类－>边界类。其中各类的属性在开始设计的时候可以不写全了，等在用例实现的时候根据实际情况进行补充修改。至于类与类之间的关系，要尽量说明问题，因为更详细的关系可以使我们发现可能未发现的类或关系，千万不要为画类而画类啊。其它就是你设计者本人的事了，仁者见仁，智者见智吧！
3.4实现用例实现
用例实现在这里是个泛泛的概念，其实只要你使用任何手段，实现了用例，那这些手段的过程就成了用例实现了。当然，如果你把它都用程序写出来，我也不反对。这里建议，用例实现由时序图和时序图中设计的类图组成，然后用活动图来表示各事件流之间的顺序关系。图13为顺序图。
|
图14 |
最顶上的一排，大家都很熟悉了吧，只是有一点不同，就是名称前面加了冒号，并后下划线。其实这里并不表示类，而是类的一个对象，冒号前面应该是对象名，只是这里采用了默认值，没有写出。可以在这里直接添加对象，不过要与已有的类联系起来（只要把类拖到对象上就产生联系了），当然也可以直接把类拖过来产生对象。
棒棒 ：生命线，表示对象生存的时间。我觉的非实时系统，并且不设计到线程进程的时序图，对生命线的长度不需要太在意的。
不会又是关联吧 ：调用，不是关联，是指前一个对象对后一个对象的调用，箭头上方的文字是被调用对象（箭头指向的一方）的操作。所以在这里可以补充设计不完整的类操作。另外调用还有一些变形，都可以在它的属性页里进行设置，大家可以自己去设置，这里就不多说了。
这里的类图，可以把顺序图中对象所设计到的类归结到一起，个人一目了然的感觉。
活动图，是我临时想到的，因为一个用例可能有几个事件流，而往往几个事件流通过控制是有先后顺序的，例如需要先查询，后删除。这就需要有个总的流程来控制几个事件流的处理。象这样：
|
图15 |
裂开的蛋 ；用例实现，所谓的用例实现就是怎样从某个角度实现用例。哪个角度？当然是设计人员的角度了。也就意味着一个用例可能会对应不同的用例实现。来看看RUP的解释：“用例实现描述如何在设计模型内部使用协作对象来实现一个特定用例。”另外还需要将用例实现与用例用 链接起来，表示谁实现谁。
3.5再小结一下
把上面的东西都画好了是不是就可以编码了吗，前提是在设计类时，包括设计它们的参数和返回值。另外，这里面提到哪里使用什么图，只是给个建议，因为会根据设计内容的不同而不同，比如大多数的类可能不会有状态图，而有些简单的用例不需要控制类等。好有，就是再强调一边，不要为了画图而画图，如果有写图内容基本相似，只是参数不同，就应该想一下设计是否合理了，而不是闭着眼再把它画一边，只改一下参数了事，我们应该把更多的时间用在设计的思考上，而不是辛勤的耕耘上。
4关于数据模型，这里就不多说了
ROSE里的数据模型就是特殊的类，只要画好了类，将它的Stereotype改为Table就是数据模型了。并且可以通过在Logic View中建Data Modeler，对建的Table的数据库属性进行修改，还可以把Table导成数据库，安逸呦。
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
