2.1用例图

用例图包括：参与者、用例、依赖泛化和关联关系；
参与者(actor ，有些书翻译成“角色”)是一种特殊的类，是系统外部的一个实体，这个实体可以是任何的人或物，它以某种方式参与了用例的执行过程。参与者用一个人形的图案表示 。具体是：人、外部设备、外部系统。
注意：参与者是一个集合概念。一个具体的外部实体仅代表同一类参与者的一个实例 ：在一个银行业务系统中，可能会有以下参与者
客户：在银行业务系统中办理了账户的居民。他们通过银行业务系统进行金融交易
管理人员：负责银行业务系统具体操作事务的办事人员。他们为客户办理存款、取款等金融交易
Mail系统：负责银行业务系统向个人发送电子邮件的软件系统
例如：

1. 寻呼台系统。用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑。
2. 商品销售系统。顾客通过网络下单之后，系统计算出总计金额，税金，运费，并将数目传递给一个外挂的会计系统，该系统是另外购买的。

概念
UseCase：　用例（UseCase）是对一组序列动作的描述，系统执行这些动作将对用例的参与者产生可以观察的结果。是参与者可以感受到的系统服务或功能单元。在图形上，用例用实线的椭圆表示。

用例应描述系统该做什么，而不是如何做
用例应采取参与者的视点 
用例应对参与者有价值 
用例描述的时间流应是一个完整场景 
所有的参与者、用例都应有相应的关联用例或关联参与者 
计算用例的数量，控制用例的数目 

用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系
泛化关系(generalization)

包含关系(include)

在进行用例A、B时必须先进性用例C；
扩展关系(extend)

包含用例与扩展用例的区别
相对于基础用例，扩展用例是可选的；包含用例则不是。
如果缺少扩展用例，基础用例还是完整的；缺少包含用例，则基础用例就不完整了。
扩展用例的执行需要满足某种条件；包含用例不需要。
扩展用例的执行会改变基础用例的行为；包含用例不会。
性质：因为基本用例的行为被包含用例或扩展用例的行为延伸了，所以基本用例的行为依赖于包含用例或扩展用例的行为。所以，包含关系和扩展关系都是依赖关系的特例

分析题 某在线会议审稿系统：
用户在初始使用系统时，必须在系统中注册，称为作者。
作者登录后提交稿件和浏览稿件审阅结果。

答案：
A1是用户，A2是作者子类指向父类
U1是注册，U2是登录，U3是提交稿件（或浏览稿件审阅结果），U4是浏览稿件审阅结果（或提交稿件）
R1是<>，R2是<>或<>，R3是<>
用户注册成为作者、作者有可能会登录，注册和登录之间存在着扩展关系； 作者浏览稿件，浏览稿件的前提必须是登录，浏览稿件和登录之间存在扩展关系； 作者浏览稿件审阅结果，提交稿件是作者可以登录也可以不登陆，因此登录和提交稿件之间是扩展或者包含关系
泛化关系：一般参与者与特殊参与者之间的关系
作用：有效地减少了参与者与用例之间的关联关系的个数，简化了用例模型