标签：参与者 通过 2.3 目的 包含 特化 提取 系统管理 管理员
用例图
1 构成
用例图从用户角度来描述系统功能，描述系统的参与者与系统用例之间的关系。需求分析时使用。
用例图由以下四个组成用例、参与者、系统、关系。
1.1 系统
系统是软件工程的最终结果，用于执行特定功能。用长方框表示，方框内包含了系统中具体用例。
1.2 参与者
参与者是系统外的一个实体，代表了与系统交互的用户、设备或另一个系统。
参与者是系统服务的对象，通过向系统输入信息或者系统为参与者提供信息来进行交互。
参与者代表的是一类用户。参与者不一定是人。
参与者分为主要参与者和次要参与者。主要参与者是使用系统较频繁的用户，次要参与者用来给用例提供某些服务，次要参与者与用例交互的目的是为了给其他的参与者提供某些服务。即，次要参与者使用系统的次要功能。（次要功能是指完成系统维护的一般功能）。例如，图书管理系统，主要参与者为图书管理员，次要参与者为系统管理员。
1.3 用例
用例是用户期望系统具备的功能。定义了系统的行为特征。
用例的定义包含他所拥有的所有功能，描述了系统的使用过程。与实现无关，值描述系统功能性方向的需求。
命名一个用例时尽量使用动词加可以描述系统功能的名词。例如，提取货款、验证身份等用例，侧重点是目标，不是处理过程。
参与者是“谁来做”，用例是“做什么”。
1.4 关系
四种关系：泛化、关联、包含、拓展。
参与者与用例间的关系，即关联关系。
2 用例间的关系
2.1 泛化关系
泛化是指一个用例（一般为子用例）和另一个用例（父用例）之间的关系。子用例继承了父用例。
泛化可用于用例和参与者。如信息添加管理员和信息删除管理员都属于管理员中的特例。
子用例是父用例的特化，具有自己的另外特性。
2.2 包含关系
包含关系指：一个用例可以简单地包含其他用例具有的行为，并把他所包含的用例行为作为自身行为的一部分。
包含关系可以让人很容易看出哪些功能可以实现代码的重用。
2.3 拓展关系
拓展关系是中依赖关系，指定了一个用例可以增强另一个用例的功能。
包图
1 包
包（Package）是UML中的主要结构。
包是一个概念性的模型管理的图形工具，只在软件的开发过程中存在。他的功能类似于Windows中的文件夹。
高内聚，低耦合。
1.1 包的名称
1.2 包具有的元素
包可放置3种类型的元素，1.包自身拥有的元素，如类、接口、组件、节点、用例。2.从另一个包合并或导入的元素。3.另外一个包所访问的元素。
1.3 包的可见性
可见性就是外界对包内元素的访问权限。有三种，"+"对所有的包都可见、"-"只对该包的子包可见、"#"对外包是不可视的。
1.4 包的嵌套
1.5 划分和组织包
识别低层包：具有泛化关系和聚合关系的元素一个包；关系密集的类一个包；独立的类一个包；
合并或组织包：
标签：参与者 通过 2.3 目的 包含 特化 提取 系统管理 管理员
原文地址：http://www.cnblogs.com/betterluo/p/6067657.html
