UML用例的描述及建模、常见问题分析.pptVIP

第4章建立用例模型4.6用例的粒度4.7用例间的关系4.8用例描述4.9用例建模4.6用例的粒度对于一个系统来说，不同的人进行用例分析后得到的用例数目有多有少。如果用例粒度很大，那么得到的用例数就会很少，如果用例粒度很小，那么得到的用例数就会很多。那么到底多大的粒度才是比较合适的？4.6用例的粒度用例就是客户付钱给我们，要我们帮助解决的问题。这些问题是软件系统的重心所在，也是客户的价值所在。当客户来找我们解决问题时，如同一个病人去找医生看病。这个病可能是大病，也可能是小病。正如医生无法决定病人得什么病一样，我们也无法决定客户所遇到的问题，我们所能选择的只是解决这些问题的方案。所以用例（大小）粒度的决定在于客户，用例的关键在于准确反映客户需求。4.6用例的粒度用例是一种用来探索需求的技术需求和设计之间的区别在于需求解决的是系统“做什么”的问题；而设计则是针对需求中提出的问题，解决系统该“怎么做”的问题。需求调研的过程是发现和界定问题的过程，设计的过程是寻找解决方案的过程。需求分析的思维方式是总结和抽象，系统设计的思维方式是分解和细化。4.6用例的粒度在确定用例过程中，主要有两个方面的问题1.当分析人员面对具有业务流程的用例时该如何处理；2.面对具有功能分解的用例时如何处理。4.7用例间的关系用例之间本来是独立的、并行的，但是某些时候用例之间确实是具有一定的业务关系，例如客户在浏览Web站点时可以选择是否在线购买商品，“浏览Web站点”用例与“购买商品”用例之间就存在一定的关系。需要有一种方法来清楚地描述这样的需求。4.7用例间的关系这种需求可以通过描述用例间的关系来表达。客户在浏览Web站点时可以选择是否在线购买商品，“浏览Web站点”用例与“购买商品”用例之间可以通过扩展关系来描述：“购买商品”用例是“浏览Web站点”用例的扩展。用例与用例之间的关系有三种：包含、扩展和泛化。4.7用例间的关系用例描述的是系统外部可见的行为，是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含（include）、扩展（extend）和泛化（generalization）这几种关系。这几种关系都是从现有的用例中抽取出部分信息，然后通过不同的方法来重用这部分信息，以减少模型维护的工作量。4.7用例间的关系包含（include）关系包含关系是把几个用例的公共行为分离成一个单独的用例，使这几个用例与该单独的用例之间所建立的关系。被抽取出来的单独的用例叫做被包含用例（Inclusion），而抽取出公共用例的几个用例称为基础用例（Base）。具体地讲，就是将被包含用例的业务插入到基础用例的业务中。UML中，用例之间的包含关系是由基础用例指向被包含用例的一条虚线箭头来表示的，线上加构造型include。4.7用例间的关系在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例“打印回执”，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。4.7用例间的关系4.7用例间的关系扩展（extend）关系扩展（extend）关系是指基础用例（Base）中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例（Extension）的业务过程在一定的条件下按照相应的扩展点插入到基础用例（Base）中。对于包含关系而言，子用例中的业务过程是一定要插入到基础用例中去的，并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的业务过程插入基础用例业务过程，并且插入点可以有多个。UML中，用例之间的扩展关系是由扩展用例指向基础用例的一条带箭头的虚线表示的，线上加构造型extend。4.7用例间的关系例如对于电话业务，可以在基本通话（Call）业务上扩展出一些增值业务，如：呼叫等待（CallWaiting）和呼叫转移（CallTransfer）。在这个例子中，呼叫等待和呼叫转移都是对基本通话用例的扩展，但是这两个用例只有在一定的条件下（如应答方正忙或应答方无应答）才会将被扩展用例的事件流嵌入基本通话用例的扩展点，并重用基本通话用例中的事件流。4.7用例间的关系4.7用例间的关系泛化（generalization）关系当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用