(第2章用例图.docVIP

第2章　用例图 2.1　概述 在第1章中，分析师学到了使用类图来表达系统内部的静态结构；在本章的用例图中，分析师将学到通过用例图来表达系统对外提供的服务。 从类图的视角来看，系统内部是由一个个的类所组成；从用例图的视角来看，系统外部是由一个个的用例所组成。也就是说，类是系统的“里子”，用例是系统的“面子”，有了类图和用例图之后，系统分析师就能够兼顾系统的面子和里子了。 温故才能知新，所以我们一边学习新的用例图观念，一边要懂得应用并复习前面学到的类图概念。因此，我们列出了表2-1来对照一下类图与用例图的概念。 表2-1　类图与用例图 ? 由于类图是系统内部的结构，所以应该要能稳定成长。换言之，类的结构应该要稳定，所以我们才会采用比较稳定的领域术语以及事务模式；但是，稳定并非保守、僵化，我们希望稳定中透着灵活性，这样系统内部结构才能够在稳定中求成长。 至于用例图就不同了，因为它表达系统对外提供给用户的服务，就像树上的杜鹃花一样，能开多少就开多少，花开花谢，用户有很多新功能可以用，开发人员有很多钱可以赚。 如同第1章的类图概念，我们对用例图（use case diagram）的概念会分为两个部分来谈：分析师必学的元素比较少，而诸如用例之间的包含关系（include relationship）、扩展关系（extend relationship）我们就不谈，也希望分析师少用，让分析阶段生成的用例图越易懂，才能越容易地跟客户沟通需求。 2.2　分析师必学元素 2.2.1　用例与参与者 既然用例图是表示系统对外提供的服务或功能，分析师大概就能合理地推测到，用例图上会有代表系统服务的“用例（use case）”，以及代表用户的“参与者（actor）”，如图2-1所示。 ? 由于用例与参与者分别位于系统的内外，所以两者之间隐含了系统范围。分析师也可以在用例图面上，明显标示出系统方框。请看图2-2，用例放置在大方框内部，参与者列在大方框外边，大方框正式名称为“主体（subject）”，代表分析师必须细究的对象，也代表用例应用的环境。 此外，再看图2-2中，参与者与用例之间有个关联，带箭头的实线表示单向的关联。不过，此处的关联只是单纯为了指出参与者可以使用哪个用例，分析师倒是不需要用太复杂的视角去解读它。 ? 2.2.2　启动者与支持者 事实上，并非只有用户才算得上是参与者，只要是会与系统（主体）互动的外部对象都算是参与者，无论是一般的人类用户、其他系统、硬件设备、外部服务和外部数据库都可能是参与者。 实际上，我们经常将参与者分为两大类：一类是用例的主要服务对象，通常也是用例的启动者；另一类是扮演支持角色的参与者。以自动柜员机（ATM）为例，一般的储户是启动者，ATM背后联机的银行主机则是支持者，如图2-3所示。 ? 再者，我会建议分析师可以采用关联的方向性，来指出启动者或支持者。请看图2-4，从会员指向订房，代表会员是订房用例的启动者；然后，再从订房指向酒店经营者，代表酒店经营者是订房用例的支持者。而且，我还在订房用例与酒店经营者的关联上标出“发送电子邮件或短信”，用来提醒开发人员需要发送订房通知给酒店经营者。 ? 2.2.3　时间代理人 用例一定需要启动者吗？有些用例是定时启动的，设定的时间一到，就会自动执行用例。在这种情况下，建议分析师设置一个“时间代理人（time agent）”，它是一个虚拟的参与者，用来指向定时启动的用例。 别忘了，可以将启动的时间标示在关联旁，这样就更为一目了然了，如图2-5所示。订房系统在月底时，会自动发送电子报给所有订阅访客。所有还未加入会员的匿名用户，都是我们的访客。当然，会员也可以订阅电子报，但是我们要强调的重点在于，不具备会员身份的匿名用户，也可以订阅电子报。 ? 2.3　用例描述 虽说用例图有画龙点睛的价值，但我们仍需要把整只“龙”描述出来，所以除了用例图之外，分析师还得使用文字描述用例的流程细节，这样的文字说明，又称为“用例描述（use case description）”　。 UML是一套标准的图形语言，其中只提出了14种图，没有将用例描述考虑在内，也当然没有任何标准的用例描述格式了。例如，我在《系统分析师UML实务手册》和《系统分析师UML用例实战》这两本书中，所设计的用例描述格式，就跟本书所使用的用例描述格式不相同。 最简单的用例描述，至少会包含一条“主要流程（basic course）”，用来描述正常的使用过程。再者，有时会包含数条“替代流程（alternative course）”，用来描述错误的、异常的状况。除此之外，用例描述到底要记录哪些内容，其格式百花齐放，可自由制定。 而且，主要流程的编写风格，要采用散文式的整块叙述，还是逐条的步骤叙述，或者是两栏式的对话叙述，也