下图是上图分包的明细。

怎么没人回复呢？

顶。

库房管理人员所做的事情，不是管理入库单，而是入库记账，入库单仅仅是入库记账这个use case的产物或者工具；
所有include/extend的use case其实不必要，它只是入库记账这个use case的main success scenario 或 extensions的过程步骤。
最重要的，不是在图上画个圈圈就完事了，还要用文字把所有的问题描述清楚。
参见Writing effective use cases一书

谢谢。

我说的入库记账，就是你的维护入库单
入库单是入库记账的产物。管理员的行为，就是入库，入库的过程，需要记账。所以，不要用维护入库单这样的词汇来作为use case的名称，最好用能够描述实际行为的词汇，比如入库记账。
另外，尽量不要用维护...这样的字眼，比如维护目录，可以用注册目录这样的词汇来作为use case的名称，在描述这个use case的时候，把删除、修改等行为作为扩展来描述

http://www.uml.org.cn/rational/dispbbs.asp?boardid=31&id=203&star=#737

请教关于用例的表示方法。
入库，可以把入库记帐作为一个用例，当录入某一种商品时，这是一种新商品，商品目录库中没有这商品，那么就要新建一个商品目录，把它做为一个用例，命名为维护商品目录。
现在问题有了。把“入库记帐”和“维护商品目录”做为两个普通用例好呢，还是把“维护商品目录”做为“入库记帐”的扩展用例好。因为只有在”入库记帐时”才执行后一个用例，并且只有是新商品时才执行。

说实话，光看图看不出来，“分书”到底要做什么？

另外，维护商品目录，和入库记帐最好是分开的。“商品”并不需要依赖入库的行为产生，是个独立的基本资源。入库等行为产生的表单在业务活动中会随时改变状态，但商品只要建立了就永远存在，不会在一个业务活动中改变其状态。

千万不要认为他们之间有关系！
目录可以作为一个独立的用例，也可以不作为用例，只是作为入库记账的前提条件

分书就是当新书到货后，确定这些书是由哪些客户预订的，好给他们分发。

在你继续提问之前，你应该问自己几个问题：
1、现在正在做的项目是一个什么状态？
A：刚开始，要做调研。
B: 已经调研了一个轮次，要整理需求和客户讨论。
C：已经完成了一次高层用例迭代开发。

2、我做用例图的目的是什么？
A: 给老师交作业
B: 给老板交差
C: 和客户交流，研究需求

3、用例图和用例是什么关系？
A: 我只需要用例图，用例就是用例图
B: 我有完整的用例，用例图只是一个提纲一样的东西
C: 我打算做一个完美的用例图，然后再往里面填内容

4、用例图对于开发团队来说究竟起什么作用？
A: 我把用例图拿给大家看，所有人就都明白要干什么了
B: 用例图只表达需求的边界和框架，作为用例文档的提纲
C: 我需要使用用例图做需求分析，所以要把它做的尽量精确

问题1的回答：
如果是C，那么你做一些扩展是可以接受的，否则没意义。

问题2的回答：
如果是1，那老师说什么就做成什么，无所谓对错；
如果是2，那就尽量画复杂些，让他觉得你工作很饱满，用例图本身很难说清对错，特别是只有一张图的情况。
如果是3，抱歉，一大堆关系，我相信绝大部分客户都会觉得头大，无论图本身对还是错，反正是起不了什么好作用。

问题3的回答：
如果是1，建议你看<编写有效用例>，或任何一本你找得到的、大家有推荐的UML教材。
如果是2，想法是对的，可惜你并没有提供过用例文档，或者还没写，那就赶紧写。
如果是3，抱歉，用例图无所谓完美，甚至好坏也很难定出严格的标准，追求这个纯粹是浪费时间。

问题4的回答：
如果是1，建议你读一读〈UML和模式应用>或类似教材。
如果是2，同上一问题答案2。
如果是3，同上一问题答案1。


用例图的作用，就是作为整个用例文档的提纲（这么说可能定义不准确，但大家都理解这个意思），用例文档是用来描述需求的：和客户之间可以用用例文档讨论需求，另外，用例文档也可以帮助你分析概念模型。

用例本身无所谓对错，因为客户需求本身很难定义对错，当然要假设你是做软件开发而不是企业顾问咨询。所以用例图也就没有什么绝对正确一说，只要你的用例图确实可以起到提纲的作用，用例能正确表达需求，就足够了。

在用例图上画大量的复杂关系，并不是一个好习惯，实际上，就象写代码一样，“让别人能读懂”代表“好”，而复杂晦涩，通常被算作一种坏毛病。

我看过你之前发的图，感觉上现在画的要好多了，虽然仍有滥用的习惯，但至少不会象八卦图一样让人昏迷了。

不要总想着把从手册上看到的每一种技术都展现在客户面前：客户关心的是需求是否能被满足，而不是他面对的这个人是否会背诵UML手册。