《编写有效用例》阅读笔记三

　　在20世纪60年代后期，Ivar Jacobson在爱立信公司电话系统工作时提出了后来成为众所周知的”用例“。在20世纪80年代后期，他将用例引入了面向对象编程领域，在这里人们认识到用例可以填补需求分析过程中一个明显的空白。我在20世纪90年代初参加了Jacobson的课程，他和他的小组没用我所使用的目标（goal）和目标失败（goal failure）这两个词，但最后我终于知道他们曾经使用过类似的概念。经过几次比较，他和我都发现我们两个模型之间没有显著的区别。我慢慢地根据最近的想法扩展了他的模型。
　　从1994到1999年，尽管在理论上还有几个松散的分支，但用例模型的概念基本保持稳定。在教授和指导过程中，我终于明白了人们为什么在简单的概念上花费了大量时间（我竟然从来没想到，我第一次尝试时也犯过很多同样的错误！）。这些想法，加上”执行者和目标“模型中一些不合理之处，产生了本书及项目相关人员（stakeholder）和利益（interest）模型，该模型是本书提出的一个新概念。
　　统一建模语言（UML）对这些概念没什么影响，反之亦然。Jacobson以前的一位同事Gunnar Overgaard编写了大量UML用例的资料，并且保持了Jacobson的风格。然而UML标准开发组受画图工具的影响很大，以至于用例的文本特征在标准中消失了。Gunnar Overgaard 和Ivar Jacobson讨论了我提出的概念，并向我保证这些关于用例的大部分概念都适合放在UML的一个椭圆图中，因此既不会影响UML，也不会被UML标准所提出的概念影响。这意味着你可以使用本书的概念，并与UML1.3用例标准兼容。另一方面，如果你只读了UML标准，由于它根本没有讨论用例的内容及如何去编写，那么你也不知道用例到底是什么、如何使用，并且还可能产生一个危险的想法，即用例由图形而不是文本构成的。本书的目的是告诉你如何编写有效的用例，而标准很少谈及这些，因此我把对UML的评述单独放在附录A中。
　　本书所用的实例
　　本书编写的实例尽可能取自实际项目，并且有些实例看起来可能不太完美。我所要说明的是，这些实例对项目组的需求来说已经足够了，并且用例编写过程中的那些不完美之处是在误差和经济允许的范围内。
　　Addison-Wesley的编辑们说服我把这些实例从原有形式中整理出来，以强调它们正确的形式，而不是它们实际的和可用的形式。希望你通过阅读这些实例发现一些有用之处，并了解项目中的实际编写过程。你可以应用我在这些实例中采用的一些原则，并找到改进它们的方法。这种事情经常发生，因为改进一个人编写的实例是一件永无止境的事情，所以我接受这个挑战和任何批评意见。
　　《软件专业人员集锦》中的用例
　　《软件专业人员集锦》（The Crystal Collection for Software Professionals）只是图书选集之一，强调了一直被忽略的、发挥人能动性的软件开发技术。其中一些书讨论了某种技术，一些书讨论了项目中的角色，一些书讨论了开发组协作的观点。
　　“集锦”遵循下面两个原则。
　　软件开发是创造和交流相互作用的游戏。当我们提高开发人员的个人技术和开发组协作效率时，它得到了改进。
　　不同的项目有不同的需求。系统有不同的特征，由大小不同的开发组研制，并且开发组成员有着不同的价值观，优先考虑的事情也不同。因此不可能定义一个最好的软件开发方法。
　　“集锦”中的基础读物--Software Development as a Cooperative Game，详细描述了这样一些观点：软件开发是一种合作游戏，方法学是一种合作文化，以及方法学系列化。该书分别对方法学的不同侧面、技术与活动、工作产品和标准进行了讨论。用例所需要讨论的精髓出现在本书的1.2节“你的用例不能作为我的用例”。
　　本书是一本技术指南，描述了用例编写过程。尽管你可以在几乎所有项目中使用这些技术，但是必须根据每个项目的实际需要选择模板和编写标准。