例解基于UML的面向对象分析与设计

摘要
      本文以实例的方式，展示了如何使用UML进行面向对象的分析与设计。本文将假设读者对UML、面向对象等领域的基本内容已了然于胸，所以将不会过多阐述，而将重点放在应用过程上。本文的目的是通过一个完整的实例，展现基于UML的OOA&D过程的一个简化模式，帮助朋友们更好的认识UML在OOA&D中起的作用。

前言
      经常听到有朋友抱怨，说学了UML不知该怎么用，或者画了UML却觉得没什么作用。其实，就UML本身来说，它只是一种交流工具，它作为一种标准化交流符号，在OOA&D过程中开发人员间甚至开发人员与客户之间传递信息。另外，UML也可以看做是OO思想的一种表现形式，可以说“OO是神，而UML是型”。所以，想用好UML，扎实的OO思想基础是必不可少的。然而，在UML应用到开发过程中时，还是有一定的模式可以遵循的。（注意，是模式而不是教条，我下面给出的流程只是一个启发式过程，而不是说一定要遵循这个流程。）下面，我们通过一个CMS系统的分析设计实例，看看如何将UML应用到实际的开发中。

1.从需求到业务用例图
      OOA&D的第一步，就是了解用户需求，并将其转换为业务用例图。我们的CMS系统需求非常简单，大致课做如下描述：这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。
      通过以上需求描述，我们画出如下的业务用例图：

      这里要注意三点：
      1.业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。它描述的是“该实现什么业务”，而不是“系统该提供什么操作”。例如，在实际系统中，“登录”肯定要作为一个用例，但是这是软件系统中的操作，而用户所关注的业务是不包含“登录”的。
      2.业务用例仅包含客户“感兴趣”的内容。
      3.业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例。

2.从业务用例图到活动图
      完成了业务用例图后，我们要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中，用户可能会进行的操作序列。活动图有个很重要的使命：从业务用例分析出系统用例。例如，下面是“新闻管理”的活动图：

      可以看到，一个“新闻管理”这个业务用例，分解出N多系统操作。这里要特别注意这些操作，其中很多“活动”都很可能是一个系统用例（当然，不是每个都是）。例如，由这个活动图可以看出，系统中至少要包含以下备选系统用例：登录、注销登录、查看新闻列表、修改新闻、删除新闻。
      这样，将每个业务用例都绘制出相应的活动图，再将其中的“活动”整合，就得出所有备选系统用例。

3.从活动图到系统用例图
      找出所有的备选系统用例后，我们要对他们进行合并和筛选。合并就是将相同的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。
      一个系统用例应该是实际使用系统的用户所进行的一个操作，例如，“查看新闻列表”就不能算一个系统用例，因为他只是某系统用例的一个序列项。
      最终我们得出的系统用例图如下：

4.从系统用例图到用例规约
      得出系统用例图后，我们应该对每一个系统用例给出用例规约。关于用例规约，没有一个通用的格式，大家可以按照习惯的格式进行编写。对用例规约唯一的要求就是“清晰易懂”。
      下面给出“登录”这个系统用例的一个规约：

5.绘制业务领域类图
      完成了上面几步，下面应该是绘制业务领域类图了。所谓业务领域类图要描述一下三点：
      1.系统中有哪些实体。
      2.这些实体能做什么操作。
      3.实体间的关系。

      这里要特别强调：这里的实体不是Actor，而是Actor使用系统时使用的所调用的实体，是处在系统边界之内的实体。例如，管理员就没有作为一个实体出现在这里，因为管理员处在系统边界之外，它所有的工作都可以通过调用这三个类的方法完成。并且，这里的“注册会员”实体也不是刚才用例图中注册会员这个Actor，而是作为一个系统内的业务实体，供Actor们使用的。例如，其中的注册功能是给注册会员这个Actor使用，而移除则是给管理员这个Actor使用的。
      理解以上这段话非常重要，我经常看到由于混淆了实体和Actor的关系而导致画出的领域类图不准确或职责分配不准确。
      大家可能还注意到，我们这里没有给出每个实体的属性。其实，在领域分析阶段，实体的属性并不重要，重要的是找出实体的操作。 

6.绘制实现类图
      以上这几步，就是分析的过程。而下面的步骤就是设计了。
      设计没有分析那么好描述，因为分析是“客户面”，它只关心系统本身的功能和业务，而不关心任何和计算机有关的东西。但是，设计和平台、语言、开发模型等内容关系紧密，因而很难找出一个一致的过程。但是，一般在设计过程中实现类图是要绘制的。
      实现类图和领域类图不一样，它描述的是真正系统的静态结构，是和最后的代码完全一致的。因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。因此，实现类图是很复杂的，而且是平台技术有关的。所以，我在这里不可能给出一个准确的实现类图，不过为了描述，我还是给出一个简化了的实现类图，当然，它是不准确的，而只是从形式上给出实现类图的样子。
      我们假设这个系统建构于.NET 3.5平台上，并且使用ASP.NET MVC作为表示层，整体使用三层架构。那么，用户模块体系的实现类图大体是这样子（不准确）：

7.绘制序列图
      有了静态结构，我们还要给出动态结构，这样，才能看清系统间的类是如何交互的，从而有效帮助程序员进行编码工作。

      上图给出的是用户登录的序列图。首先注册会员作为Actor，调用UserController的Login方法启动序列，然后序列按图示步骤执行。其中UserServices作为业务组件，首先调用数据访问组件的GetByName确定用户是否存在，如果存在，再调用GetByNameAndPassword确定输入密码是否是此用户的密码。从而完成业务功能。
      要注意，序列图在实际中是很多的，几乎每个类方法都配有相应的序列图。

8.后面的步骤
      在完成了上面的过程后，就可以进行编码、调试、测试等工作了。但这些已经超出了本文讨论的范围。

总结
      本文简要给出了使用UML进行OOA&D的过程。当然，由于示例较小，而且本人水平有限，所以给出的相关内容可能不是很准确。而且软件分析设计本来就不是一个固定模式的过程，随着系统的不同整个过程会有变化。本文只是想起到一个抛砖引玉的作用，让朋友们大致了解UML的使用流程。至于实际的分析设计，还需要深入的学习和实践的积累。

作者：T2噬菌体
出处：http://leoo2sk.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。Tag标签: 软件工程,面向对象,UML,OO,OOA,OOD,用例posted @ 2008-11-08 11:16 EricZhang(T2噬菌体) 阅读(4582) 评论(36)  编辑 收藏 网摘 所属分类: UML
发表评论  回复  引用  查看     #1楼 2008-11-08 11:20 | 小灰       很好，学习
  回复  引用  查看     #2楼 2008-11-08 11:26 | joylee       真的很好,简单易懂,园子的老师越来越多了
  回复  引用  查看     #3楼 2008-11-08 12:25 | 小狼壮壮       很希望楼主能来个uml系列就好了
  回复  引用     #4楼 2008-11-08 12:28 | hook [未注册用户] 为什么要多做一次数据库操作呢？为什么不直接用GetByNameAndPassword,这样可以避免用户猜测用户名，且不是更好。
还有方法好像没有写上参数吧？
  回复  引用  查看     #5楼 [楼主]2008-11-08 12:40 | T2噬菌体       @hook
那个是业务设计问题，不是本文的主题。不过我可以解释一下：有的实现确实是这样的，因为要求可以给出提示是用户不存在还是密码不正确。

序列图的方法是不需要写参数的...它不代表方法执行，而只代表一个消息
  回复  引用     #6楼 2008-11-08 12:58 | hook [未注册用户] @T2噬菌体
序列图中的方法代表消息，这个我不反对，但你说序列图中的方法是不需要写参数的，我就不敢苟同了。序列图中的方法如果有参数，就应该把参数标识出来，我觉得是很有必要的，难道就因为它是消息，就不需要参数了？那且不是带参数的消息就有问题了？既然序列图是用来表示类之间的交互的，而方法不过是类向外暴露的接口，当其他类要调用这个方法时，参数很多时候就变成了消息的一部分。当从静态的类图到动态的序列图时，你不仅要确定调用那些方法，还要确定传递那些参数，这样才能指导程序员更快的编码，这样才能更好地通过工具生成代码。
  回复  引用  查看     #7楼 [楼主]2008-11-08 13:07 | T2噬菌体       @hook
我仔细翻阅了相关文献，得到的答案是这样的：
为了更好的指导编码，类图是应该有参数和返回值类型的，这一点我确实忽略了。不过序列图确实是不应该有参数的，因为序列图只表示传递消息的名称，而不表示具体传递的数据。因为类图中已经有参数和返回值了，所以程序员在编码时，关于参数和返回值是参考类图的，而序列图只表示出一种交互关系。
  回复  引用     #8楼 2008-11-08 14:50 | zhang123 [未注册用户] 很好！
  回复  引用  查看     #9楼 2008-11-08 20:06 | Steven Chen       Good job.


Applying UML and Patterns
  回复  引用  查看     #10楼 2008-11-08 20:08 | Geerry       学习了
  回复  引用  查看     #11楼 2008-11-08 23:12 | JustForKim       通俗易懂，感谢楼主的文章，提个建议：
从业务用例图到活动图，这一步骤最好使用带泳道的活动图，带泳道的活动图能够很好的表现出各参与者之间的关系。
  回复  引用  查看     #12楼 [楼主]2008-11-08 23:38 | T2噬菌体       @JustForKim
呵呵，谢谢你的建议，我确实忽略了这一点。以后如果再写类似的文章，一定会在活动图上加上泳道。
  回复  引用  查看     #13楼 2008-11-09 00:27 | 德仔--脚踏实地 用心努力       不错，用的是star UML吧。

转载了哈 谢谢
  回复  引用  查看     #14楼 2008-11-09 00:31 | 德仔--脚踏实地 用心努力       应该说明一下可以直接转化在c# 或java的功能
  回复  引用  查看     #15楼 2008-11-09 01:03 | 牛牛x       写得很好啊，简单易懂，期待lz后续的文章！
  回复  引用  查看     #16楼 2008-11-09 01:25 | 老农       请问图是用什么画的?
  回复  引用  查看     #17楼 2008-11-09 10:23 | 冰の酷龙       很清晰，希望能继续.
  回复  引用  查看     #18楼 [楼主]2008-11-09 11:22 | T2噬菌体       @老农
用的StarUML
  回复  引用  查看     #19楼 [楼主]2008-11-09 11:22 | T2噬菌体       @德仔--脚踏实地 用心努力
呵呵，我还没用过这种功能呢
  回复  引用     #20楼 2008-11-09 17:08 | Jeffrey Null [未注册用户] Trivial
  回复  引用  查看     #21楼 2008-11-10 08:18 | net1234       写得不错,谢谢

-------展示了如果使用UML进行面向对象的分析与设计

指出个错别字，应该是如何吧，不是如果

  回复  引用  查看     #22楼 2008-11-10 08:41 | JustDI       收藏，UML的表现方式让需求变得很清晰。
  回复  引用  查看     #23楼 2008-11-10 09:24 | 球球       要为每一个业务用例绘制一幅活动图
-------------------------
个人感觉，活动图主要是为了描述跨用例或者线程的行为，大多数单个用例最好的描述方式还是用文本而不是活动图（虽然我有时也用），用例图那东西可有可无，重要的是描述，顺序图也不是什么必要的东西，开会的时候画个用来向同事解释类之间的交互或者自己画个用来分析就够了，真正需要形成文档的顺序图恐怕很少。
对UML图不太感冒，类图比较常用，用例通常都是文档，活动不太多，顺序更少，包图看上去也有些用，但无奈工程都不大，没那个必要去做。

  回复  引用  查看     #24楼 [楼主]2008-11-10 10:29 | T2噬菌体       @net1234
已修改。谢谢！
  回复  引用  查看     #25楼 [楼主]2008-11-10 10:30 | T2噬菌体       @球球
呵呵。其实画多少UML、画哪些图这样的问题本身就没有一个确定的说法。是可以随具体情况而定的。
我个人的习惯是：对业务用例画活动图，对系统用例写用例规约。至于序列图嘛，貌似画的也不多，呵呵。
  回复  引用  查看     #26楼 2008-11-10 10:31 | 胖胖鱼       很不错，写的很简洁清晰，非常适合新手及需要改变思路的读者。
  回复  引用     #27楼 2008-11-10 13:08 | Mqsuper [未注册用户] good
  回复  引用     #28楼 2008-11-10 17:51 | wangxu [未注册用户] 写的真是太棒了，非常感谢，让我对UML有了大致的概念，太谢谢了，希望楼主继续写出这样的好文章！谢了
  回复  引用  查看     #29楼 2008-11-11 09:37 | 姜敏       买了本UML的书,但一直没有系统去学习,看了这篇文章后,觉的有学习的必要了.
  回复  引用  查看     #30楼 2008-11-12 10:44 | Buyee       写的不错。上次看了一半，今天发现没有在首页了，还好能搜索到，收藏了。
  回复  引用     #31楼 2008-11-12 11:42 | 吃不饱的虾 [未注册用户] 老兄， 你的《基于.NET平台的分层架构实战》的源码什么时候能公布啊。 好像等了4个月左右了，还没收尾啊。其实我很喜欢你这个系列的文章，只可惜没有源码。 看过你的BBS系统源码，但还是希望能读读这个系列的源码。 谢谢！
  回复  引用  查看     #32楼 2008-12-09 12:30 | 极地雪狼       写的不错。不过业务类图这个层面是不是有些多余。
  回复  引用     #33楼 2009-03-24 12:25 | csmcykl [未注册用户] 确实写的很不错啊
收藏了
  回复  引用     #34楼 2009-04-03 09:24 | Freeman.Xie [未注册用户] 很棒的文章.学习了!
  回复  引用     #35楼 2009-04-24 20:32 | lolita [未注册用户] 拜读了楼主的大作后有几个小小的疑问——

1.业务用例和系统用例是存在交集的吗？您给出的图示中，发表评论是一个业务用例，同时也出现在系统用例之中。

2.用例规约只针对系统用例吗？业务用例不需要吗？为何？
  回复  引用  查看     #36楼 [楼主]2009-04-25 14:19 | T2噬菌体       @lolita
1.业务用例和系统用例严格说不存在交集，视角不同。
业务用例是站在业务角度，你可以想象如果没有计算机系统的参与，这些用例也要存在。而系统用例时站在系统使用的角度，是使用计算机系统能完成的功能。那个“发表评论”虽然名称一样，但代表不同意义。前一个指在业务上需要有发表评论的功能，后一个指这个CMS系统可以供用户发表评论。

2.业务用例也可以有用例规约，只不过这里我没给出。