作者：牧山道人
原文地址：https://www.seeksunslowly.com/case-tools-usage
转载请注明出处，谢谢。
_____________________________________

版本：v1.02，始建于：2007/11/06，最后更新：2007/12/07。

一、释义
首先，概括说明一下笔者对“CASE”及“CASE工具”的理解，以便就此展开讨论。
CASE（Computer Aided Software Engineering）即“计算机辅助软件工程”，
这是官方定义。通俗地讲，CASE是在电脑软件生产的各阶段（包括市场调研、可行性析、需求分析、各类设计、编码实现、测试修改、功能性能优化、联机文档编写与嵌入、发布或交付最终用户使用等，下文将之概括为“软件生产”）起辅助作用以使软件企业/部门开发出各质量指标更高的软件，并明显缩短开发周期、降低开发成本的一门学问。如此 “CASE工具”即可理解为“做CASE这门学问”的具体电脑工具软件。

二、CASE工具运用优势、应用方法及使用误区
1．广义 vs 狭义
有些IT从业人员认为CASE工具须得是大名鼎鼎的公司出品的知名软件或已成为行业标准的通用产品（如Rational Rose，Sybase PowerDesigner，MS Project, MS Visio等），此即“狭义”理解。上述产品毫无疑问是优秀的CASE工具，但是，我们可推而广之：既然CASE工具是对软件生产起辅助作用的工具，则但凡能起此作用、达此目的者，皆为CASE工具，此即“广义”认识。如MS Word（以文字为主的多媒体表现工具），MS Excel（以表格为主的多媒体表现工具），甚至MS Paint（简易的图片编辑处理工具），只要运用得当，使之最大限度地发挥辅助软件生产的作用，就是您得心应手的CASE工具。
当然，我们并不排斥掌握一些复杂的CASE工具，关键是看它是否真正能提高工作效率、提高软件质量、更好地帮助我们思考分析问题。有了这些认识，有助于我们更好地选用、慎用CASE工具。

2．帮助思考分析问题
这是CASE工具一个重要作用，没有认识到这点，基本不会产生主动使用它的动机（很可能是迫于制度或公司要求而被动或被迫使用，长此以往，会对其产生排斥心理）。不妨信笔举一例权作阐释：战争中，指挥官进行战略讨论与部署、研究敌我路线进度时，会指着地图进行讲解，这样缩短了讨论时间、加深了参与人员的印象，减少了对结论的歧义、并可快速发现不妥之处以使战略部署更合理。这里地图（当然现在有更好的工具代替之）在战争中的作用与CASE工具对软件生产所起作用类似，如我们的PDM，VSD，BPM等都有类似作用，它们可使软件生产活动之参与人员对产品的各环节有个形象的认识，并能从各环节CASE工具作品中很快把握产品及业务的要点。

3．提高工作效率，节省人工成本
此处我们以编码实现环节作说明：当业务复杂到我们很难用顺序执行或简单的分支、循环编码解决时，可能部分同事体验过层层圈转或/及多个条件组合判断代码让人看着头晕、望而生畏的感觉，甚至有时圈进去很难出来，出来后再圈回去也很困难（因为中断工作并重新开始时，一般需要将这些复杂业务逻辑再于脑中整理一遍才能继续先前的思路，而这些多层条件或循环很容易在你脑里打死结）。自己的一例：某业务牵涉到的条件甚多，且需分别组合甚至不断跳转，起初，不管3721，拿着就开干，每次进入到复杂的地方总会停下来回顾前面已处理好的部分，重复数次，便对此段代码产生强烈的厌恶感，遂暂搁，改为作其他相对较简单之部分。次日，续之，其苦更甚，未果，遂罢，另思他法。待心绪平静之后，花了40分钟作出模拟业务逻辑的VSD，审视无误后，开始重写代码（遇到难处仅需简单看一下VSD便能往下写），仅花了40分钟完成编码，对各种输入条件进行测试，结果无误。80分钟 vs 2日未果，差异十分明显，且如果没有此VSD之帮助，就算2日完成，其中定有不少Bugs, 这样又会增加测试工时。当然，在编码中有两种情况作业务逻辑模拟是徒劳的、浪费时间的：a. 业务相当简单；b. 天才：可于脑中有条不紊地模拟出业务逻辑并迅速转换为代码实现。

4．逆向CASE
逆向CASE指将软件生产各环节实际作品还原为CASE作品，这是CASE工具使用中的严重误区。如将代码实现还原为流程图、将建立好的Db还原为物理数据模型、将部署好的设备Top结构还原为Top图，这些都是逆向CASE的表现。产生逆向CASE的原因包括但不限于：在事前无准备的情况下，公司制度要求提交部分CASE文档、编写文档需要（如引用业务模型）、对外宣传需要、自己归档需要。这些原因其实都是合理且必要的，但若以逆向CASE完成，便与初衷相悖甚至适得其反。在已完成的产品上作逆向CASE有以下弊病：增加人工成本（额外的工作）、质量不高（交差）、增加系统维护人员的工作量（同时看两份不一致的资料，需要勘误、版本升级，并常为以何为准而困惑）。弊病大家都能认识到，如何避免产生这些弊病是我们亟待解决之问题。首先，软件生产参与者，应结合上述2、3节认识到CASE的价值，主动使用CASE工具，以帮助自己思考、提高工作效率。这样去想去做，便会于实际“生产”之前，主动形成一些必要分析结果（CASE作品），对于上述任何逆向CASE产生的原因，皆能轻松应对，更重要的是让自己工作变得轻松、高效。另外，作为管理人员或流程制度制定者，需要对各阶段CASE作品悉心规划，尽量使须提交的作品都是十分有用的（优秀而有用的CASE作品会让人反复阅读参考，并切实指导软件生产）；卡好实际软件生产与分析活动的时间点，这样CASE作品产生与软件生产活动能形成一条正确的流水线，在一定程度上实现名副其实软件生产，这样想作逆向CASE都不行。如：需求分析作品没完成，相关人员不能进行概要设计；概要设计作品没完成，详细设计（包括但不限于界面设计、数据结构设计、关键业务流程分析、数据模型建立等）便不得（实际上是无法）进行……，如此层层流转，步步把关，初看费时费力，但若按此做肯定会缩短产品生产时间，特别是大型项目/软件；此外，明确各阶段生产活动的决策者、辅助者、参与者，也能在一定程度上提高各阶段CASE作品及实际产品的质量并保证其版本的唯一与准确，从而提高整条“生产线”的效率与质量。补充说明：由于自己的需要，对前人的软件产品作逆向CASE以方便自己及以后的维护人员工作是应鼓励的。

5．缓解用眼疲劳
本节承2、3节，并加以引伸，介绍CASE工具及其方法对身体健康的一点帮助。作为IT工作者，大部分工作时间几乎是在敲击键盘、摆弄鼠标的同时一直盯着屏幕中度过的，这样肉眼极易疲劳，长此以往，视力便不断下降。笔者使用电脑时间不算太短，目前也仅在需要的场合才戴100度的近视眼镜，其中CASE工具及其延伸出的方法功不可没（当然也有所谓的“天生”成份）。
应用原理及方法：我们使用电脑工作时虽一直盯住屏幕，但细思之，某些情况并不至如此，因我们在思考时主要用大脑而非电脑（一般情况仅需借助部分屏幕信息或根本不用），此时应作“离线”（视线移开屏幕甚至廊间踱步）思考。当需要其他方式或媒介来辅助“离线”思考时，此时写、印、身边小物等便是极佳的辅助方式或媒介。“印”即将某CASE作品（如业务模型、数据模型、流程图等）打印在纸质媒介上，并携之摩挲翻阅帮助思考，愉快地完成“离线”思考过程。8H的日工时，至少有1H需要思考（其他必要的交流、查阅资料、休息等不在此列），然后才在电脑上操作并实现，有兴趣的同事不妨一试。

6．讨论交流的利器
此处仍举一例说明。曾在某制造企业资讯部工作时，所有新功能模块或子系统在需求分析阶段会形成一个重要的CASE作品：二维业务流程图。其纵标为子系统，横标为各生产或职能部门，其内容则为模拟各项业务活动在部门及子系统间流转运作情况之流程图，各流程块由谁执行、谁审核、反馈给哪个部门、由哪个子系统实现等都清楚呈现，一目了然。在开始进行各项设计工作前，召开业务流程讨论会并组织软件生产相关人员、相关部门管理及系统操作人员参加。会中，看此投影，各部门相关人员只需找到本部门所在“行”，便可清晰快速地检查各项业务活动是否有遗漏或冗余以及与其他部门的接口是否正确（即与实际生产活动是否一致），有误便及时提出，讨论修改并升级CASE作品版本且作版本变更登记，无误，于所在部门行末签字确认，各部门签字认可后，各生产部门留存副本，资讯部持正本。经过讨论交流并签字确认的二维业务流程图是后续设计与开发的权威指导与最高纲领，后续一切软件生产活动以此为准，这样便保证了软件产品与实际业务是一致的（不一致便是软件的Bugs）。以后随业务逻辑的变更会重复讨论升级该流程，并修改后续软件生产各环节相关作品，由此形成一个闭环软件生产过程。

7．全局统筹
引用上节实例中“……是后续设计与开发的权威指导与最高纲领”字样，可以看出某些CASE作品在软件生产过程中起着全局统筹之作用，如业务处理模型、业务流程图等。此处单列一节，旨在说明这类CASE作品的重要性以引起重视：必须确保其准确无误（与实际业务逻辑一致）并与业务逻辑保持同步更新才能对软件生产的其他环节的正确性进行有力保障。因为最终软件产品就是要模拟实际业务，将大量复杂的运算、管理工作交由电脑完成，模拟出的结果（起全局统筹作用之CASE作品）已不正确，所有后续过程都会被枪毙。同时可以看出，此步错并继续软件生产，将带来无法估量的工作量，最坏的情况甚至需要全部推翻重来。

8．业务/系统优化
随着企业规模的扩大、商业利润的增加，其业务逻辑势必越来越复杂、多样，如大型制造、商业集团企业皆有此现象。这时，很难有人能全面地理清此错综复杂的业务逻辑，对其进行优化更是望尘莫及，部分业务的清理与优化也仅限于某个点、线、面，因为实际业务是人、财、物复杂的交叉活动与流转。而透过全局或局部模拟并与业务逻辑严格一致的CASE作品，能将这种人、财、物的复杂活动变成几页纸、几幕投影，资深的系统分析者、业务/生产部门领导者，便有可能从这些CASE作品中找出业务逻辑的弊病并对其进行优化，如脱节或遗漏的财物流转、多余的生产工序或审核流程、环节间人力资源分配的不合理致使人工成本的提高……
对软件生产而言，会有同样的尴尬，可以上述思路优化之（其实优化了软件生产某些环节也同时优化了业务逻辑），此处不赘述。
当然，并不是有这些东西，便人人可优化，CASE作品仅为此优化提供了可能条件，这属于软件产品反向优化业务的范畴，须得是对业务及系统十分精擅的资深人员方可为之。以前某主管在某制造企业生产现场工作10年，再转同企业开发部工作8年，对其所在企业业务及系统都很精通，便能常指出生产部门存在的问题，并得到相关主管、经理的采纳（题外话：不能光看别人本事，20年磨一剑需要的毅力与所经历的艰辛没亲历过是很难想象的）。

9. 与软件产品脱节
这也是CASE工具使用的重大误区，前文略有提节，此处单列再次重点说明。逆向CASE质已变，不在讨论之列，我们只说正常CASE与产品脱节的情况。与产品脱节的情况表现为修改软件而没有修改相关CASE作品（其实本就不该先修改软件）及修改了CASE作品而未对软件进行更新。一旦发生这种情况，很多CASE工作都白做了，失去了其本身意义。避免这种情况可采取如下措施：
a、制定CASE作品及软件修改流程（大原则为先CASE后软件）并指定负责人，严格执行。
b、制定各类软件生产过程输出之作品版本管理方法，确保最新版本的唯一性，修改时以此为准，旧版适当保留以作参考。
c、修改/升级活动参与人员，参照前文所述利弊及方法，在心理上认识到按正确流程修改的重要性，并有主动按此执行的欲望。
其中第c点最重要，否则一切制度流程都没用，因为人是活的。

三、结束语
以上是笔者在近10年IT从业生涯中对CASE工具使用的一些浅显认识，其中必有纰漏谬误之处，欢迎各位同行批评指正、讨论交流。另，作此文旨在抛砖引玉，希望大家能将自己的工作、学习甚至生活经验分享出来（这同时也是对自己进行总结的较好方式）。

【赞赏 / Reward】