标签:参与者 通过 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