构造用例过程

xulin168

虽然强烈地建议使用用例，但正如在上一期中所指出的那样，用例经常被滥用了。这次我将阐述一下误解和滥用最常发生的部分，即用例的构造（Configuration）过程。 我曾经为一家跨国公司开发一个分布式的，多币种和多语言的核心财务系统。该项目在许多方面都可作为当今面向对象软件开发的最佳应用范例。 通过和公司的注册会计师，核数员，出纳员，管理员以及其它财会人员进行广泛的接触，我用六周时间开发了一个全面的领域模型。这个模型包括一套完整的标准建模语言(UML)类图，共17张，存放在一个商用的计算机辅助软件工程(CASE)工具中。为了验证模型，还制做了一个遍历类图的视频，并分发给公司在世界各地的数百名担任重要职务的财会人员。制作视频需要一张放大的领域模型类图，这张图后来被贴在项目开发地点的墙上，而且经常被开发组用作参考，当然，有时也会修改。 整个软件的体系结构建立在基本的面向对象(OO)原则上(见图一)，并且重用了Peter Heinckiens 在它的新书（Peter M. Heinckiens. BUILDING SCALABLE DATABASE APPLICATIONS, Addison-Wesley, MA, 1998）中详细描述的一个数据库的体系结构。这种结构在使商务逻辑完全独立于数据库技术的前提下，实现了由关系表到对象的映射。这使得移植到其它数据库相当容易。进行实际开发时使用了一个专业的Java集成开发环境，商业类库的使用也对开发成本得降低起了重要作用。在作重要的设计决定时我们会咨询领域问题专家，并且维护了一个技术问题解决方案的数据库，详细记录了正反不同方案的争论以及选择不同设计所依据的基本原理。 在项目计划中定义了17个系统增量。每一个增量完成时，都会在多个平台的多个数据库管理系统上进行测试。一个共同指导委员会被建立起来，以检查和协助项目开发。我们选择了一个开发人员和系统最终用户之间有着良好关系的地点进行b测试。当领域知识或应用需求中不明确的问题增加时，会有一个财务问题专家与开发组交流一两个小时。这一切都非常理想。财务人员对项目有着特定的兴趣，并且在作出决定之前他们可以发现所有的问题。 在进入系统开发后情况非常好，即使到最终我们也只定义了18个用例，它们之中没有任何一个被详细描述到完整的交互对话框，也没有使用标准的UML详细用例模板。 我的许多同事认为这种缺少详细用例的方式是一种异端行为。我同意在大多数情况下应当付出更多的努力来开发用例，但是并非所有的项目都需要相同的用例构造过程。