我发现，在OO和UML几乎一统天下的今天，仍有很多系统分析员对OO和UML一知半解，甚至包括很多已经使用了很久UML的系统分析员。
于是打算写一个系列文章，将多年来的工作经验做一个总结。对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。
这个系列文章将以我对OO和系统分析的理解为主，从UML基础开始，阐述面向对象的需求分析方法，过程，并以RUP为例，阐述如何将OO过程与软件过程有机结合在一起，做一个真正OO应用。
好了，今天是第一篇。想得很远，真希望我能坚持下去，呵呵
用例是什么？其原始英文是usecase，直译过来就成了用例。这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。
这个定义还是比较费解的，笔者在众多应聘者中发现很多使用用例来做需求的系统分析员，有的已经使用了两年以上，但仍不能把握用例的本质，虽然他们号称精通UML。
最
具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能点。在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人
用用例来划分子系统，功能模块和功能点。如果这样，用例根本没有存在的必要。有意思的是，造成这种理解错误的相当一部分原因却是因为对OO思想的理解不够
深入，本质上说，把用例当成功能点的系统分析员脑子里还是面向过程的那一套思想，虽然他们在使用OO的工具，OO的语言，号称在做面向对象的开发，但过程
的影子还没有从他们脑子里彻底抹去。
如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？
我的回答是：错！功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。功能实际描述的是输入-->计算-->输出。这让你想到了什
么？DFD图？这可是典型的面向过程分析模式。因此我说把用例当做功能点的分析员实际在做面向过程的分析。
而用例则不是计算机术语，UML除了在
计算机行业中应用，它也经常被应用在其它行业中。用例是一种需求方法学，虽然软件危机和OO的发展促成了它的诞生并被完美的融合进了OO体系，形成了
UML，但它实际上并不是软件行业的专用品。如果非要从功能的角度解释，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场
景，这些“功能”体现不同的组合方式。实际上，把用例解释为某个参与者(actor)要做的一件事可能更为合适。这样的一件事有以下几个特征：
一、
这件事是相对独立的。这意味着它不需要与其它用例交互而独自完成参与者的目的。也就是说这件事从“功能”上说是完备的。读者可能会想到，用例之间不是也有
关联关系吗？比如扩展，比如实现，比如继承，它看上去并不是独立的嘛。关于这个问题，笔者会在后续的文章里详细说明。这里稍微解释一下，用例之间的关系是
分析过程的产物，而且这种关系一般的产生在概念层用例阶段和系统层用例阶段。对于业务用例，这个特征是很明显的。
二、这件事的执行结果对参与者来
说是可观测的和有意义的。例如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该
作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。又比如说，登录系统是一个有效的用例，但输入密码却不
是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？
三、这件事必须
由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。用例总是由一个参与者发起，并且满足特征二。例如从ATM
取钱是一个有效的用例，ATM吐钞却不是。因为ATM是不会无缘无故吐钞的，否则，我从此天天守在ATM旁，生活无忧矣。
四、这件事必然是以动宾
短语形式出现的。即，这件事必须有一个动作和动作的受体。例如，喝水是一个有效的用例，而“喝”和“水”却不是。虽然生活常识告诉我们，在没有水的情况下
人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的，但是笔者所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的
并不在少数。
除去以上的特征，笔者觉得用例的含义还要更深些。首先，用例的背后是一种需求方法论。其核心是以参与者为中心（区别于以计算机
系统为中心），从参与者的角度来描述他要做的日常工作（区别于以业务流程描述的方式），并分析这些日常工作之间是如何交互的（区别于数据流的描述方式）。
换句话说，用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的，而是要弄清楚有多少参与者？每个参与者都做什么？业务流程分析则是后续的工作
了。其次，用例简直就是为OO而生的，其思想完美的符合OO。用例分析方法试图找到问题领域内所有相对独立的参与者和事件，并把业务流程当成是这些参与者
和事件之间的交互结果（在UML用活动图或序列图来描述）。因此，用例方法被吸纳到OO之后，UML得以以完备的形式出现，用例成为了真正的OO核心。在
RUP里，这种核心作用被发挥到极致，产生了用例驱动（usecase
driven）的软件过程方法，在RUP里，软件生产的所有过程和产物都是围绕着用例形成的。
可以说，用例分析是OO的第一步。如果用例分
析本身出了问题，对业务架构，软件架构的影响是很大的，将大大削弱OO的优势--复用、扩展。笔者认为软件复用可以分为三个层次，最低层次的复用是代码级
复用，这是由OO语言特性提供支持的，例如继承，聚合，多态；较高层次的复用是组件级复用，这是由设计模式提供支持的，例如Factory模式,
Builder模式；最高层次的复用则是服务级复用，这在很大程度上是由应用服务器和通讯协议来提供支持的，例如最近炒得火热的SOA（面向服务的应用）
架构。用例分析的好坏也许对代码级和组件级的复用影响不太大，但对服务级的复用影响却是巨大的。笔者认为服务级复用是OO的最高境界，而结构良好的用例分
析则是达到这一境界的基础。
闲话：
今天你OO了吗？
如果你的分析习惯是在调研需求时最先弄清楚有多少业务流程，先画出业
务流程图，然后顺藤摸瓜，找出业务流程中每一步骤的参与部门或岗位，弄清楚在这一步参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给到
下一个环节的。那么很不幸，你还在做面向过程的事情。
如果你的分析习惯是在调研需求时最先弄清楚有多少部门，多少岗位，然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？....那么恭喜你，你已经OO啦！
预告：
下一篇文章将讨论如何获取用例
********************************************************* 作者coffeewoo 欢迎您访问文章原始出处 : http://blog.csdn.net/coffeewoo 以及 http://coffeewoo.itpub.net ，阅读中有任何问题可以在BLOG上留言或发邮件到 coffeewoo@gmail.com，我将尽力为您解答。具有代表性的问题我会以 Q &A的形式收录到对应的文章之后。希望本系列文章对您有帮助。欢迎转载，敬请注明，谢谢 ^_^
原博客里与网友的讨论及回复：
好文章，为什么不坚持写下去了呢！！！
我在学习UML，觉得很难把握一个度，而且很多时候没有办法，也没有什么可以评判自己所划分的用例如何，有你们这样的高手，又不惜赐教的，很好！！！
写吧？？？
最好以后可以写一些案例，这样就更完美了，
我以后会经常来看的，也会介绍在学习建模的朋友来看的，
有点八婆，哈，
最后一句：继续吧！！！
评论于: 2006.07.12 15:18
写到第四篇开始疑惑了。一是好象没人喜欢这类文章。二是再展开下去有点开枝散叶的意思，一时不知从何入手了。加上工作，就耽误下来了。
以后会继续更新的。谢谢你喜欢。
评论于: 2006.07.12 15:57
今日，拜读您的佳作，深感自己学的肤浅。
作为一个即将加入IT领域的我，您的文章让我见识了您独到的思想，和广博的知识结构与实践经验。对正在学习和实践的年轻人，其很有借鉴价值。希望您能多写写这么好的文章！坚持！我会把您的思想传给更多的人！
评论于: 2006.07.18 00:11
我是一个面向过程的设计者，想向OO设计转，你的文章对我很有帮助
评论于: 2006.08.08 14:47
不错！学习UML有一段时间了，但是不系统！
通过您的文章系统学习一下！！！
评论于: 2006.08.14 16:28
以前也在网上也阅读过讲用例分析的文章，但好像对于具体的项目没有实践的指导作用
你写的不同，
评论于: 2006.08.15 09:54
楼主能给不能根据一个具体而微的小项目,阐述一下oo分析的全过程,嘿嘿...这样更能贴近实际的感受oo分析....8过要有劳楼主了,呵呵
评论于: 2006.09.03 10:50
楼主辛苦了，还是希望你能好好写下去。
小弟我正在学习建模，不知道你有什么好的建议？
也可以给我们大家讲一下。
评论于: 2006.09.08 15:36
正在学习建模技术;没什么好说的,只有四个字,"感谢楼主!"
评论于: 2006.09.08 19:23
楼主能不能以一个具体实际的小应用为例阐述一下面向对象分析的全过程。毕竟OO是一种方法学，纯从理论上理解对于大多数的初学者来说还是有些困难的。
评论于: 2006.09.10 15:43
你
的文章思路清晰，讲解细致入理，读时偶有同感不甚欢喜，深深佩服你的OO思想之深邃，偶的梦想是成为一名伟大的系统分析师，站在软件过程的金字塔顶，按胸
中的丘壑勾勒软件蓝图。以后会多多向你学习，你是我的榜样！我的qq 15387970，非常希望你能加我为好友！谢谢！
评论于: 2006.09.10 20:33
学无止境，我无非多做了几年而已。QQ我是不用的，如果要联系的话我的MSN就是文章中公布的邮箱。有什么问题可以到以武会友去留言。谢谢光临。
评论于: 2006.09.10 20:45
评论于: 2006.09.12 20:27
顶,读后有感触
评论于: 2006.09.15 16:32
顶,读后有感触
评论于: 2006.09.15 16:32
看完＇今天你ＯＯ了吗＇，才知道．我是个完完全全的面过过程开发者．．．
非常感谢楼主．继续拜读其他文章...
评论于: 2006.10.31 11:26
不用灰心，其实OO和过程的转换只在一念之间，同一件事情你是从完整流程逻辑角度去看的？还是从人的角度去看的？流程还是要搞清楚的，无非是把流程看作是人做事以后交互的结果，而不是系统的本源，就这么一点差别：）
评论于: 2006.10.31 11:49
虽然学过面向对象分析与设计，但似乎一直理解不透。读了这篇文章感觉受益匪浅。大虾，加油哦。
评论于: 2006.11.02 10:46
赞美之言就省略了，非常仔细的看了《什么是用例》一文。条分缕析，字字珠玑，看的直呼过瘾。
不过，在看“二、这件事的执行结果对参与者来说是可观测的和有意义的。例如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它
是系统的一个必需组
成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。…”这段的时候，我一直
疑惑着，系统备份删除前的数据，这个极其重要的功能需求，不在需求阶段列出来，何时列出来呢？我还没看到后续的文章，也许后续解决了，但是这个问题我不搞
清楚，我会一直认为通过获取用例的方式，并不能将系统的所有功能都得到。很多用户不参与的事情，系统会悄悄的做了。用例不列出来，系统功能不就不完全了
吗？
评论于: 2006.11.10 13:56
“系统备份删除前的数据”这样的语句其实很模糊。
有两种情况：
1.语意：逻辑删除
2.语意：客户提出的需求
假设是1的语意，那很简单，在业务用例阶段完全不需要出现“系统做什么”，只有在系统用例和之后的分析模型阶段再出现
假设是2的语意，那你就要考虑这样的语句本身对你的需求有什么样的影响？也即“备份删除前的数据”究竟是为了做什么？这也要分两种情况：
1.客户假设说我是想为了保存以前的历史数据以备不时之需
2.客户假设说我是可能想在某个报表中可以看到版本比较的信息
好，如果是1的需求，那很简单，你只是记录下这句客户的话，然后作为一个“非功能性需求”列在你最终生成的《需求规格说明书上》
如果是2的需求，那你就有必要在“备份删除前的数据”和“查看版本报表”这两个动作所处的某两个（或一个）业务用例中加上这样的“用例描述”：客户删除数据->生成历史数据->。。。->客户查看历史数据
评论于: 2006.11.10 23:35
搂主这么辛苦，看你的东西不回，有点对不住你，更何况真是受益非浅！！以后我会常来的。谢谢了！
评论于: 2006.11.15 11:37
万分感谢搂主，我是一个刚刚开始转型的程序员，您的这篇文章对我的作用实在是太重要了。
谢谢了
评论于: 2006.11.24 16:18
好东西 我刚刚要学OO 谢谢楼主了
不回复真的不是我的个性
评论于: 2006.12.04 14:36
楼主能不能结合这个图书例子用你的风格讲解一下系统分析员和架构师的区别。看了一些文章，总不得要领。感激涕零！
评论于: 2006.12.18 03:23
用例分析系列中所有的工作，都是系统分析员做的，架构师不做这些工作。但这些工作的成果是架构师工作最主要的输入之一。
夸张一点说，系统分析员可以完全不懂计算机知识。他是领域专家，是行业顾问，或者有着对陌生问题领域敏锐的视角和极强的总结，归纳能力。能够把客户分散的，杂乱的，矛盾的需求整理成为完备的，自洽的，有弹性的结构，并且能够与客户共同探讨。
架构师是计算机专家，软件的行家里手。需要深入了解各种各样的软件结构，应用模式，中间件，服务器，甚至硬件知识...具备这么全面的知识目的是为接下来
的开发工作定下基调。根据需求规模，应用环境要求，客户特殊要求，应用程序特性等，再根据公司的基本情况，来选择或决定技术路线，中间件，开发工具等。为
开发定下基调，大的架构。小公司，中，小型项目我个人意见是根本用不到架构师这个角色的，顶多一个高级设计师把握整体框架就行了。架构师还要高于高级设计
师，只有当一个项目或产品大到需要很多个开发组，产品由很多个可独立的组件组成的时候，架构师才有意义。
评论于: 2006.12.18 11:09
一锤定音！
报以雷鸣般的掌声！
评论于: 2006.12.18 18:40
我
是一个刚来公司实习的实习生，有个项目需求已经做完，而恰恰中了楼主点出的要害，按功能点划分系统。要开始建模了，自己胡乱看了两天，有点不得要领，以前
也没什么经验，第一次使用Rose,今天偶然搜到楼主的主页，感觉很好，呵呵，收藏了慢慢看，只是觉得时间很紧迫，需求又跟我的建模思想不太一致，不知怎
么下手
评论于: 2006.12.21 10:59
谢谢楼主,您所讲的太好了,学习!会常来的!
评论于: 2006.12.28 16:02
好文章，一定要顶。
恳请继续！
评论于: 2006.12.29 11:26
感谢楼主的话就不用小弟重复了,只是有一件事想请教楼主,我是一个刚刚转行到IT业不到一年时间的,现在做程序员,但我已经决定软件开发作为我的职业生涯,请问楼主能给我一点建议吗???谢谢:
评论于: 2006.12.30 12:19
IT
是个挺累人的工作，活到老学到老这句话在这个行业里再适合不过。就我个人经验来说我觉得基本功是很重要的。这些基本功包括第一个就是程序功底，不必在意掌
握多少种语言，而是深入研究某一种。如果你也是用java的就很幸福了，java的开源软件，开源框架非常之多，尽管下载下来研究源码，把学习所得应用到
实际工作中去，进步会非常之快的。
IT也有很多工种的，程序员，系统分析员，设计师，架构师，项目管理，硬件工程师。各类行业所采用的技术也有很大不同。不过如果你基本功过硬，转什么工种什么技术都会很容易。
重要的一点是在打基本功的同时考虑自己适合，喜欢什么方面的工作，再多加些努力在那个方向上。
祝你在IT大展鸿图
评论于: 2006.12.30 12:57
真
心感谢楼主的建议,我会努力做到更好的,因为我以前没有什么基础知识,听说C#语言入门比较容易,所以就选择了它,据网上以及一些书中介绍,C#是
Java的翻版,所以我想先学学C#,然后有机会再向Java转,听一些前辈说写程序要成功,就必须要做到多看多写多想;我希望楼主的文章能一直继续,陪
伴我不断的成长.
评论于: 2006.12.31 14:36
一直在oo和面向过程之间徘徊,今天的会议,也一直难以在功能点和用例的关系上困惑,看完你的文章,才觉得uml还得深入学习啊.
评论于: 2007.01.11 22:01
受益颇深，谢搂主
评论于: 2007.01.18 16:26
IT业进来不是一天两天了但觉得想做，有想法去做却是最近的事。看到你的文章忍不住回贴，其实我是个很懒的人，对不起从前各位大虾了。 楼主文章如醍醐灌顶，看了几本有关的书一直不太得要领，希望楼主继续传道解惑，有劳了！
评论于: 2007.01.29 17:45
谢谢分享
支持
评论于: 2007.02.05 13:37
新手请教：之前在网上看到“用例分析需要从用户的角度去分析，也可以把系统本身看成一个用户，那“系统备份删除前的数据”是不是也可以在用例列出呢？
或者把系统本身看成用户是错误的？
评论于: 2007.02.05 21:41
把
什么作为一个用例，前提是你事先划定了一个边界。站在边界外的是actor，边界内的是用例。边界是很重要的。它决定了你的视角和能够得出的结果。例如，
对于站在笼子外的你来看，笼子里的猴子是用例，而如果笼子里的猴子来看，用例就是你了。这是视角不同。边界同时可以决定粒度。比如，你站在汽车外时，你看
到的东西是车体大小，颜色。你在汽车里时，你看到的是仪表盘，方向盘。当把仪表盘拆开，你看到的是电路，显示版...
用例获得也是同样道理，哪些是actor，哪些是用例，粒度如何，取决于你对于边界的认定
评论于: 2007.02.06 09:27
谢谢！偶就喜欢这种通俗易懂的解释～可在书上怎么也看不到～看书上分析的例子总感觉自己已经明白，是那么回事了。但自己分析建模一个系统时，又总感觉好多东西都不确定上不了手。
评论于: 2007.02.06 19:37
好文章
评论于: 2007.03.18 21:14
好
文章,不回对不起楼主了，不过我现在很忙,看了一篇.明天中午再看第二篇,uml以前也学过,不过自我感觉没学好,现在用jsp等技术做一个小项目,考勤
系统.在确定用例时,很迷惑,不知道哪种才算用例,本来自以为自己理解了,原来还是习惯于面向过程的思想.在re:qcsoft
[回复中提到,小公司，中，小型项目我个人意见是根本用不到架构师这个角色的，顶多一个高级设计师把握整体框架就行了,那么象考勤系统这种小的项目也需要
分析用例,希望楼主指点下,如果要分析用例,那么考勤登记里的登记上班时间和登记下班时间算两个用例吗,还是考勤登记就是一个用例,根据楼主说明的用例的
第一个特征:这件事是相对独立的,我想应该是分为两个用例吧.
评论于: 2007.03.23 13:12
用例分为业务用例和系统用例。业务用例描述业务需求，系统用例描述系统需求。业务用例最重要的一点是能否完整表述actor主角的期望。所以你先要弄清楚谁在驱动考勤登记，他的目的是什么。
我觉得只登记上班和只登记下班应该都是目的的一部分，所以应该登记考勤是业务用例。至于上班和下班是否在系统用例阶段要分开，取决于你打算在系统层面将它分成两个逻辑功能还是一个。
评论于: 2007.03.23 23:04
这么好的文章怎么才发现哦，相见恨晚！
楼主，请教一个问题：
我现在在做一个项目，把所有的涉及到的业务都细分成添加、删除、浏览等等类似的一个个小的用例，这应该都是业务用例了，那请问我的系统用例是哪些呢？应该怎么写？或者说有必要写吗？（你可以拿一个电子商务的系统作例子指导一下，多谢了！）
评论于: 2007.04.03 16:19
你
列举出的那些用例实际上都是系统用例了，你还怎么再细分呢？业务用例是指的业务目标，例如说维护人员档案，这是一个完整的业务目标，也是一个业务用例。至
于维护办法，有手工的，有自动的，有的只能加不能删，有的只能修改，有的只能看....这些，是实现业务目标的方法。在这些方法中，打算纳入软件开发范围
的，才叫做系统用例。
评论于: 2007.04.03 17:36
楼主，多谢你的指教
那我是不是可以这样理解呢，如果把业务用例进行功能上的细分的话，分成若干个小的用例，那么这些小的用例是不是就是系统用例？
就象维护人员档案，如果细分成添加档案，修改档案，删除档案，查看档案等等。。。
如果你的答案是肯定的话，那我是不是可以继续这样理解：一般情况下，业务用例实际上是在一个比较高的层面上来看业务逻辑，更接近于用户的直接需求，而系统用例则是业务逻辑的详细的划分，更接近与程序的设计了？
多谢你的赐教！！！！！
评论于: 2007.04.03 23:16
不大对喔。系统用例和业务用例的区别并非是细分。
请注意理解：业务用例是用来捕获功能性需求的，功能性需求是由actor的业务目标来体现的。也就是对于actor来说，他所负责的业务需要由一系列的业
务目标组成。比如一个档案管理员，他的业务目标就是维护档案。比如论坛管理员，他的业务目标有维护用户，维护帖子等..这些业务目标构成actor职责的
全部。业务用例体现了需求。
而需求的实现有多种方式。如何实现它，是由系统用例来体现的，它们并不是一个简单的细分关系，虽然看上去象。就说维护档案吧，这样一个业务目标，会有多种
不同的用例场景去完成它，这些场景包括如何增加档案，如何修改档案，如何删除档案....对于系统用例来说，就是通过分析这些场景，来决定哪些场景中的哪
些部分是要纳入系统建设范围的。比如维护档案业务用例中，假设由于某个原因，修改档案很困难，只能通过先删除，再全部重建的方式来实现，那么系统用例就增
加档案，删除档案，而没有修改档案。
业务用例和系统用例是分别站在客户的业务视角和系统建设视角来规划的。业务用例不是接近，而是完全的直接需求，系统用例也不是业务逻辑的详细划分，而是系统对需求的实现方式，但不是与程序设计无关，它只是说，要建设的系统功能性需求由这些系统用例构成。
所以业务用例和系统用例都是需求范畴，它们分别代表了业务范围和系统范围。
评论于: 2007.04.04 09:54
大哥，多谢赐教，你这么一解释清楚多了，我现在在用例，写了好多，可是老觉得不清晰，我已经加了你的MSN，希望有机会即时请教！！
PS：很想跳槽做你的手下哦！
评论于: 2007.04.04 10:36
我想知道这些在大学时要学习吗，我们有软件工程课但是可是这些好象太深奥了，在大学时有必要学这些吗？
评论于: 2007.04.06 11:28
实际工作中大部分软件公司至少在名义上要用UML，并且事实上UML是面向对象方法的最佳实践。不论是.net技术还是j2ee技术，不论是什么项目，面向对象都是必须的知识。你觉得在大学有必要学吗？
评论于: 2007.04.06 14:02
谢谢楼主回复,感觉清晰多了
评论于: 2007.04.18 19:01
刚刚开始oo学习。
评论于: 2007.04.25 09:51
谢
谢楼主，这个blog确实好，解答了我好多的疑问。真的谢谢了。楼主的系统分析员之路第一篇讨论的是什么是用例，第三篇讨论了涉众。这里一直有一个疑问怎
么从涉众中找出系统的actor？
就拿网上图书借阅系统来说，图书馆的一些领导希望查询系统获得他们想知道的信息，这里要不要把作为一个actor，如果是actor的话，有没有必要有
“综合查询”用例
评论于: 2007.05.30 09:46
谢
谢楼主，这个blog确实好，解答了我好多的疑问。真的谢谢了。楼主的系统分析员之路第一篇讨论的是什么是用例，第三篇讨论了涉众