UML 用例图 Use Case Diagram.docVIP

A、Use Case Model Use Case Diagram（用例模型和用例图） A.1、Use Case Model（用例模型） 用例建模的最主要功能就是用来表达系统的功能性需求或行为。（对于正在构造的新系统，用例描述系统应该做什么；对于已经构造完毕的系统，用例则反映系统能做什么）。用例建模是通过开发者和用户共同协商完成的。用例模型基本组成部件是Use Case（用例）、Actor（参与者）和System Boundary（系统边界）。用例模型可以由若干用例图组成。 A.2、Use Case Diagram（用例图） 用例模型由用例图构成。用例图中显示用例、参与者和用例之间的关系。用例图在宏观上给出模型的总体轮廓，而用例真正实现细节则以文本的方式书写。用例图所表示的图形化的用例模型本身不能提供用例模型必须的所有信息。每个功能的含义和实现步骤必须用用例图和文本描述。用例图既要画出三中模型元素，也要画出元素之间的各种关系（关联Association、概括Generalization、依赖）。 B、模型元素 B.1、Use Case（用例） 用例用于描述系统的功能，也就是从外部用户的角度观察，系统应该支持哪些功能。用例内容通常用普通文字书写。 B.2、Actor（参与者） 也可以翻译为角色。参与者是与系统进行交互的外部实体。它可以是系统用户也可以是其它系统或硬件设备，和系统进行交互的任何实体都是参与者。参与者是一个群体概念，代表的是一类使用某个功能的人或事物，不是指个体。 B.3、System Boundary（系统边界） 系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。（在myeclipse的UML组件中就未找到System Boundary） C、模型元素间关系 C.1、Associate、Association（关联） 用例和参与者之间的关系属于关联，又称通信关联（communication association）。这种关联表明那种参与者可以和用例通信。关联关系是双向一对一关系，即参与者可以和用例通信，用例也可和参与者通信。 C.2、Generalize、Generalization（概括） 有些UML工具使用Generalize(myeclipse)，有些使用Generalization(EA)。翻译为：概括、通用化或范化。也可以理解为继承。在用例图中，用例和参与者都可以使用概括。把某些参与者或用例的共同行为抽象出来表示成通用行为，且把他们描述为超类（superclass）。角色的泛化/继承很容易理解，因为角色本来就是类（Class），它是一种版型（stereotype）为Actor的类，所以角色的继承直观而自然。但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展（extended）和包含（include）两种泛化的特例。 C.3、Extended（扩展） 一个用例中加入一些新的动作构成了另一个用例，这两个用例之间的关系就是扩展关系。后者通过继承前者一些行为得来，前者成为概括用例，后者称为扩展用例。扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。 扩展用例对基用例不可见。 C.4、Include（包含） 包含关系表明源用例包括目的用例的功能。使用包含关系是为了避免在很多用例中有很多行为相同的子集。 用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。 包含关系是一个有向关系。 C.5、Use、Usage（使用） 使用关系表明一个元素(Actor)需要另一个元素(Use Case)来执行一些互动。使用关系不用具体指定目的元素(Use Case)如何使用，只表明源端(Actor)在使用它的定义和实现。也可以所使用关系是依赖关系(Denpendency)的子类型。 在用例图中你通常使用使用关系(Use)来为参与者(Actor)如何使用系统函数(Use Case)来建模。(在类图和组件图中使用Usage dependency)。 C.6、Realize（实现） 源对象(Use Case)实现目的对象(Use Case)。实现连接在Use Case, Component , Requirements d图中使用表达模型的可追溯性和完整性。业务过程或需求通过一个或多个用例来实现，而用例通过一些类来实现，而类通过组件来实现，等等。系