燃烧的烟

当前，在产品的功能分析中，遇到难题：虽然让大家统一使用UML规范来建模，设计用例图，但是图中的用例老是感觉不到位，不是多了，就是少了。

为了帮助大家更好的找出系统中的用例，特别引入了一组词“生、见、变、灭”。世界万物都是遵循这一规律：生、见、变、灭。

生：事物的产生，由无到有的过程。
见：事物被看到、被其他观察者查询、查看到。是展示于自然界中的形态。
变：事物的变化，有小到大、由弱变强等变化的过程。
灭：事物的消亡，从有到无。

正好，也在InfoQ中看到《理解REST软件架构》一文，也说到了这一点。

在编写用例图的过程中要做到以下几点，就能从很大程度上避免丢失用例的情况：

1、找到一个业务实体（事物），验证其是否有“生、见、变、灭”相关用例。
2、对于“生、见、变、灭”的用例，其是否有相关的扩展。如：‘修改信息’的相关扩展可能为‘推荐’、‘审核’等影响其变化的用例。
3、基于各扩展，其是否又产生了新的实体。如：‘审核’发生时，就会出现‘审核信息’这一实体。那么这一实体的细分又产生了‘申请审核（生）’、‘批准审核（变）’、‘撤回审核（灭）’等。

一句话：即要通过实体的整个生命周期来考虑。

这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。 －－我们正是基于对“CRUD”这一基本操作的重复构造，来完成对用例的完整性检验的。

对于用例图中用例精度（粒度）的思考：
基于对　某一实体的相关用例的扩展而引起的新实体的用例，其可以做细分，也可以概括论之。其把握点在于这“新实体”对“某一实体”的影响有多大，以及怎么样能给读者恰好说清楚。

大家在使用中Fck中肯定会遇到不问题，同样都从网上找到解决方法，我也一样。我也来说说的寻找与解决。

另，我搜索到的文章不少，但基本上都与http://www.ie521.com/blog/article.asp?id=437 FCKeditor 2.6 安装配置使用指南(asp) 相同。但可以发现不少问题－－－本篇不是一个挑错的文章，所以不细谈。

另外又参照了Fckeditor软件包的demo。

一，下载，从官网http://www.fckeditor.net/上下载最新的正式版吧，现在是2.6.4版，3.0版是测试版。

二、安装文件：在网站根目录下建立FCKeditor这样一个文件夹，然后把下载下来的文件包释放到该文件夹中（一般在网站的根目录中，使用“解压到当前目录”就可以搞定了，她的压缩包就是直接以FCKeditor目录压缩的）。

三、删除不必要的文件（现在是以ASP以例）：

• 在FCKeditor目录中仅保留editor、fckeditor.asp、fckconfig.js、fckeditor.js、fckpackager.xml、fckstyles.xml、fcktemplates.xml文件，其余的都删除。
• 删除语言包editor\lang中除中文(zh-cn.js、zh.js)和英文(en.js)以外的语言。
• 删除editor\skins目录下除默认皮肤（default）以外的文件夹 。其实我更喜欢使用silver样式。要注意喜欢那一个就留下那个，其他的删除掉，并且记得在fckconfig.js修改皮肤的路径。
• 删除editor\filemanager\connectors目录下除asp以外的文件 
• 删除editor目录下_source目录（这是源相关的源文件目录，不需要） 

四、在ASP源程序中引用FCKeditor编辑器

1. 首先在asp页面顶端插入服务器端包含语句：<!--#include file="FCKeditor/fckeditor.asp" –>。注意在GB2312编码的页面最上部一定要有<%@ codepage=936%>，这是因为fckeditor的文件编码是UTF－8的，不加入会发生乱码。
2. 然后在表单里面添加以下代码：
3. Dim oFCKeditor' 定义变量
   Set oFCKeditor = New FCKeditor' 类的初始化
   oFCKeditor.BasePath    = "/fckeditor/"' 定义路径（这是根路径：/FCKeditor/）
   oFCKeditor.ToolbarSet="Basic"' 定义工具条（默认为：Default）
   oFCKeditor.Width="100%" ' 定义宽度（默认宽度：100%）
   oFCKeditor.Height=350 ' 定义高度（默认高度：200）
   oFCKeditor.Value="这是示例文本。" '输入框的初始值
   oFCKeditor.Create "FCKeditor1" '在表单里面创建了一个隐藏的名称为FCKeditor1的输入框
4. 使用request.Form("FCKeditor1")，就可以读取FCKeditor1的输入框的值。

五、对于fckconfig.js的配置请见相关的资料吧，网上有很多。

六、对于上传的设置，也请见网上的相关资料

什么是用例
    用例是什么？其原始英文是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的最高境界，而结构良好的用例分析则是达到这一境界的基础。

系统用例和业务用例
    业务用例是用来捕获功能性需求的，功能性需求是由actor的业务目标来体现的。也就是对于actor来说，他所负责的业务需要由一系列的业务目标组成。比如一个档案管理员，他的业务目标就是维护档案。比如论坛管理员，他的业务目标有维护用户，维护帖子等..这些业务目标构成actor职责的全部。业务用例体现了需求。
    而需求的实现有多种方式。如何实现它，是由系统用例来体现的，它们并不是一个简单的细分关系，虽然看上去象。就说维护档案吧，这样一个业务目标，会有多种不同的用例场景去完成它，这些场景包括如何增加档案，如何修改档案，如何删除档案....对于系统用例来说，就是通过分析这些场景，来决定哪些场景中的哪些部分是要纳入系统建设范围的。比如维护档案业务用例中，假设由于某个原因，修改档案很困难，只能通过先删除，再全部重建的方式来实现，那么系统用例就增加档案，删除档案，而没有修改档案。
    业务用例和系统用例是分别站在客户的业务视角和系统建设视角来规划的。业务用例不是接近，而是完全的直接需求，系统用例也不是业务逻辑的详细划分，而是系统对需求的实现方式，但不是与程序设计无关，它只是说，要建设的系统功能性需求由这些系统用例构成。
所以业务用例和系统用例都是需求范畴，它们分别代表了业务范围和系统范围。

用例的粒度
     粒度是令人迷惑的。比如在ATM取钱的场景中，取钱，读卡，验证账号，打印回执单等都是可能的用例，显然，取钱包含了后续的其它用例，取钱粒度更大一些，其它用例的粒度则要小一些。到底是一个大的用例合适还是分解成多个小用例合适呢？这个问题并没有一个标准的规则，笔者可以给大家分享的经验是根据阶段不同，使用不同的粒度。在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。例如取钱，报装电话，借书等表达完整业务的用例，而不要细到验证密码，填写申请单，查找书目等业务中的一个步骤。在用例分析阶段，用例的的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是，这个阶段需要采用OO方法，归纳，抽象业务用例中的概念模型。例如，宽带业务需求中有申请报装，申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料，受理业务，现场安装等多个业务流程中都会使用的概念用例。在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。例如，填写申请单，审核申请单，派发任务单等。可理解为一个操作界面，或一个页面流。在RUP中，项目计划要依据系统模型编写，因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。
    上述的粒度划分方法笔者是用相对比较具体化的一些依据来说明。实际上，用例粒度的划分依据（尤其是业务用例）最标准的方法是一个用例的粒度是否合适，是以该用例是否完成了参与者的某个目的为依据的。这个说法比较笼统，也比较难以掌握。，举个例子，某人去图书馆，查询了书目，出示了借书证，图书管理员查询了该人以前借阅记录以确保没有未归还的书，最后借到了书。从这段话中能得出多少用例呢？请记住一点，用例分析是以参与者为中心的，因此用例的粒度以能完成参与者目的为依据。这样，实际上适合用例是：借书。只有一个，其它都只是完成这个目的过程--这里讨论的用例指的是业务用例--这个例子是比较明显的能够区分出参与者完整目的的，在很多情况下可能并没有那么明显，甚至会有冲突。
    但是上述的粒度选择并不是一个标准，只是在大多数情况下这样的粒度选择是比较合适的。笔者的意思也不是告诉读者上述哪一种是最好的，而只是把一些常用的比较，划分方法告诉读者，期望的是帮助读者在工作实践中自己总结出一套适合自己的方法来。现实情况中，一个大型系统和一个很小的系统用例粒度选择会有较大差异。这种差异是为了适应不同的需求范围。比如， 针对一个50人年的大型项目应该选择更大的粒度，如果用例粒度选择过小，可能出现上百甚至几百个业务用例，造成的后果是需求因为过于细碎和太多而无法控制，较少的用例有助于把握需求范围，不容易遗漏。而针对一个10人月的小项目应该选择小一些的粒度，如果用例粒度选择过大，可能只有几个业务用例，造成的后果是需求因为过于模糊而容易忽略细节。一般来说，一个系统的业务用例定义在多于10个，少于50个之间，否则就应该考虑一下粒度选择是否合适了。
    不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。这应该很好理解，在描述一栋建筑时，我们总是把高度，层数，单元数等合在一起介绍，而把下水道位置，插座数量等合在一起介绍。如果你这样介绍一栋楼：这栋楼有10层，下水道在厨房东南角，预留了15个插座，共有5个单元，听众一定会觉得云山雾罩，很难在脑子里形成一个清晰的影像。

闲话：
今天你OO了吗？
    如果你的分析习惯是在调研需求时最先弄清楚有多少业务流程，先画出业务流程图，然后顺藤摸瓜，找出业务流程中每一步骤的参与部门或岗位，弄清楚在这一步参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给到下一个环节的。那么很不幸，你还在做面向过程的事情。
    如果你的分析习惯是在调研需求时最先弄清楚有多少部门，多少岗位，然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？....那么恭喜你，你已经OO啦！

系统分析员和架构师
    用例分析系列中所有的工作，都是系统分析员做的，架构师不做这些工作。但这些工作的成果是架构师工作最主要的输入之一。
夸张一点说，系统分析员可以完全不懂计算机知识。他是领域专家，是行业顾问，或者有着对陌生问题领域敏锐的视角和极强的总结，归纳能力。能够把客户分散的，杂乱的，矛盾的需求整理成为完备的，自洽的，有弹性的结构，并且能够与客户共同探讨。
    架构师是计算机专家，软件的行家里手。需要深入了解各种各样的软件结构，应用模式，中间件，服务器，甚至硬件知识...具备这么全面的知目的是为接下来的开发工作定下基调。根据需求规模，应用环境要求，客户特殊要求，应用程序特性等，再根据公司的基本情况，来选择或决定技术路线，中间件，开发工具等。为开发定下基调，大的架构。小公司，中，小型项目我个人意见是根本用不到架构师这个角色的，顶多一个高级设计师把握整体框架就行了。架构师还要高于高级设计师，只有当一个项目或产品大到需要很多个开发组，产品由很多个可独立的组件组成的时候，架构师才有意义。

Q&A
Q：由 pushboy 发布
    在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。"在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。"
那么，这样一个场景 —— 用户管理，有增删改查。这里，是把 用户管理 作为一个用例，还是把增删改查分别作为用例呢？他们每一个都是一个完整的业务流程和一次完整交互，而且也都是一个actor发起的动作；怎么来确认呢？我们的前提是一个普通的比如说财务系统，而不是一个用户管理系统

A：这个问题很好，用例的粒度总是在这样左也可右也可之间难以决定。对这个问题来说，我的观点是业务用例应当用“管理用户”或“维护用户”作为合适的粒度，而增，删，改，查则在作为系统用例。我的理由是：
增删改查不能做为一个完整的业务来理解。作为一个管理业务，数据只有先增，才会有改，才会有删。增删改查结合起来才能完成actor的管理目的，只删或只增加都不是业务的全部。这篇文章后来我又补充了一条粒度的判断标准，可以到http://coffeewoo.itpub.net/去看，是否是一项完整业务，要看actor的目标，而不是事情是否完整。这个例子中，actor的目标是为了增加一个用户吗？是为了删除一个用户吗？都不是，而是为了管理用户，这个目标包括了用户这个实体的整个生命周期。
    再讨论深一些，如果业务要求对用户除了增删改查，还有别的要求，例如权限升级，用户在组织机构中复杂的关系变更，用户与外部系统的交互....实际的情况可能会更多，那么，如果将每个都作为一个业务用例，很容易造成一个结果，这些原本与用户这个实体紧密关联，共同组成用户实体生命周期的业务，被割裂成多个独立的业务，因为定义了多个用例（请参看本人第一篇中的用例特征第一条）。要知道，在RUP中，用例驱动的含义是，一个用例就是一个分析单元，设计单元，开发单元，测试单元甚至部署单元。相信读者都知道，把紧密关联的业务分成多个独立部分去实施是高成本的，高风险的。
    另外，为什么我要说在系统用例阶段要把增，删，改，查又分出来呢？原因在于，系统用例的目的是为了将actor的业务用计算机模拟出来。我们都知道，一般情况下，增，删，改，查对一个actor来说是不会同时发生的，每次actor只会完成其中的一个行为。分开来，有利于详细分析模拟这一行为的细节而不至于混淆。另一方面，对WEB应用来说，针对数据的增，删，改，查等，很容易形成所谓的“模板”，增加用户用这个模板，增加其它基础数据可能也用同一个模板，无非是操作的数据（实体）不同而已。因此，在很多情况下，这些模板是可以复用的。对这个例子来说，在系统用例阶段，我们可以用“管理用户” include “增加用户”来表示这个实现关系，同时，让“增加用户”，“增加XX数据”等等用例来继承自一个抽象出来的“增加数据”用例，这样，可复用的模板体现在“增加数据”用例上，而具体业务，则体现在“增加XX数据”上。实际上，这也是一种OO思想的体现。
    只有一个查询是比较特殊的，查询一般不一定只局限于一个actor，也不一定局限这个用例，一般都是所谓的综合查询，是可能跨用例的。所以根据实际情况，查询可以作为一个业务用例出现