UML静态建模

任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。

    UML的静态建模机制包括：用例图(Use case diagram)、类图(Class diagram)、对象图(Object diagram )、包(Package)、构件图(Component diagram)和配置图(Deployment diagram)。

    1. 用例图

    (1) 用例模型(Use case model)
    用例模型描述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。首先,它描述了待开发系统的功能需求;其次,它将系统看作黑盒,从外部执行者的角度来理解系统;第三,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。在UML中,一个用例模型由若干个用例图描述,用例图主要元素是用例和执行者。

    (2) 用例(use case)
    从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作,动作执行的结果能被指定执行者察觉到。在UML中,用例表示为一个椭圆。概括地说,用例有以下特点:
    ·用例捕获某些用户可见的需求,实现一个具体的用户目标。
    ·用例由执行者激活,并提供确切的值给执行者。
    ·用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。

    (3) 执行者(Actor)
    执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。不带箭头的线段将执行者与用例连接到一起,表示两者之间交换信息,称之为通信联系。执行者触发用例,并与用例进行信息交换。单个执行者可与多个用例联系;反过来,一个用例可与多个执行者联系。对同一个用例而言,不同执行者有着不同的作用:他们可以从用例中取值,也可以参与到用例中。

    需要注意的是执行者在用例图中是用类似人的图形来表示,尽管执行的,但执行者未必是人。例如,执行者也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。

    通过实践,我们发现执行者对提供用例是非常有用的。面对一个大系统,要列出用例清单常常是十分困难。这时可先列出执行者清单,再对每个执行者列出它的用例,问题就会变得容易很多。

    (4) 使用和扩展(Use and Extend)
    使用和扩展是两种不同形式的继承关系。

    当一个用例与另一个用例相似,但所做的动作多一些,就可以用到扩展关系。

    当有一大块相似的动作存在于几个用例,又不想重复描述该动作时,就可以用到使用关系。

    (5) 用例模型的获取
    几乎在任何情况下都会使用用例。用例用来获取需求,规划和控制项目。用例的获取是需求分析阶段的主要任务之一,
而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生