（本文转载自软件工程专家网www.21cmm.com）
任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。UML的静态建模机制包括用例图(Use case diagram)、类图(Class diagram)、对象图(Object diagram )、包(Package)、构件图(Component diagram)和配置图(Deployment diagram)。
(1) 用例模型(Use case model) 长期以来,在面向对象开发和传统的软件开发中,人们根据典型的使用情景来了解需求。但是,这些使用情景是非正式的,虽然经常使用,却难以建立正式文挡。用例模型由Ivar Jacobson在开发AXE系统中首先使用,并加入由他所倡导的OOSE和Objectory方法中。用例方法引起了面向对象领域的极大关注。自1994年Ivar Jacobson的著作出版后,面向对象领域已广泛接纳了用例这一概念,并认为它是第二代面向对象技术的标志。 用例模型描述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。首先,它描述了待开发系统的功能需求;其次,它将系统看作黑盒,从外部执行者的角度来理解系统;第三,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。在UML中,一个用例模型由若干个用例图描述,用例图主要元素是用例和执行者。
(2) 用例(use case) 从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。以字处理软件为例,"将某些正文置为黑体"和"创建一个索引"便是两个典型的用例。在UML中,用例被定义成系统执行的一系列动作,动作执行的结果能被指定执行者察觉到。
在UML中,用例表示为一个椭圆。图1显示了一个金融贸易系统的用例图。其中,"风险分析","交易估价","进行交易","设置边界","超越边界的交易","评价贸易","更新帐目"等都是用例的实例。概括地说,用例有以下特点: ·用例捕获某些用户可见的需求,实现一个具体的用户目标。 ·用例由执行者激活,并提供确切的值给执行者。 ·用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。
(3) 执行者(Actor)
执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。图1中有四个执行者:贸易经理、营销人员、售货员和记帐系统。在某些组织中很可能有许多营销人员,但就该系统而言,他们均起着同一种作用,扮演着相同的角色,所以用一个执行者表示。一个用户也可以扮演多种角色(执行者)。例如,一个高级营销人员既可以是贸易经理,也可以是普通的营销人员;一个营销人员也可以是售货员。在处理执行者时,应考虑其作用,而不是人或工作名称,这一点是很重要的。 图1中,不带箭头的线段将执行者与用例连接到一起,表示两者之间交换信息,称之为通信联系。执行者触发用例,并与用例进行信息交换。单个执行者可与多个用例联系;反过来,一个用例可与多个执行者联系。对同一个用例而言,不同执行者有着不同的作用:他们可以从用例中取值,也可以参与到用例中。 需要注意的是执行者在用例图中是用类似人的图形来表示,尽管执行的,但执行者未必是人。例如,执行者也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。在图1中,我们可以看到,记帐系统是一个外界系统,它需要更新帐目。 通过实践,我们发现执行者对提供用例是非常有用的。面对一个大系统,要列出用例清单常常是十分困难。这时可先列出执行者清单,再对每个执行者列出它的用例,问题就会变得容易很多。
(4) 使用和扩展(Use and Extend)
图1中除了包含执行者与用例之间的连接外,还有另外两种类型的连接,用以表示用例之间的使用和扩展关系。使用和扩展是两种不同形式的继承关系。当一个用例与另一个用例相似,但所做的动作多一些,就可以用到扩展关系。例如图1中,基本的用例是"进行交易"。交易中可能一切都进行得很顺利,但也可能存在扰乱顺利进行交易的因素。其中之一便是超出某些边界值的情况。例如,贸易组织会对某个特定客户规定最大贸易量,这时不能执行给定用例提供的常规动作,而要做些改动。我们可在"进行交易"用例中做改动。但是,这将把该用例与一大堆特殊的判断和逻辑混杂在一起,使正常的流程晦涩不堪。图1中将常规的动作放在"进行交易"用例中,而将非常规的动作放置于"超越边界的交易" 用例中,这便是扩展关系的实质。当有一大块相似的动作存在于几个用例,又不想重复描述该动作时,就可以用到使用关系。例如,现实中风险分析和交易估价都需要评价贸易,为此可单独定义一个用例,即"评价贸易",而"风险分析"和"交易估价"用例将使用它。 请注意扩展与使用之间的相似点和不同点。它们两个都意味着从几个用例中抽取那些公共的行为并放入一个单独用例中,而这个用例被其他几个用例使用或扩展。但使用和扩展的目的是不同的。
(5) 用例模型的获取
几乎在任何情况下都会使用用例。用例用来获取需求,规划和控制项目。用例的获取是需求分析阶段的主要任务之一,而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生,并且随着工作的深入会发现更多的用例,这些都应及时增添到已有的用例集中。用例集中的每个用例都是一个潜在的需求。
a. 获取执行者 获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行者。以下问题可供参考: ·谁使用系统的主要功能(主要使用者)。 ·谁需要系统支持他们的日常工作。 ·谁来维护、管理使系统正常工作(辅助使用者)。 ·系统需要操纵哪些硬件。 ·系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。 ·对系统产生的结果感兴趣的人或事物。
b. 获取用例 一旦获取了执行者,就可以对每个执行者提出问题以获取用例。 以下问题可供参考: ·执行者要求系统提供哪些功能(执行者需要做什么)? ·执行者需要读、产生、删除、修改或存储的信息有哪些类型。 ·必须提醒执行者的系统事件有哪些?或者执行者必须提醒系统的事件有哪些?怎样把这些事件表示成用例中的功能? ·为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现? 还有一些不针对具体执行者问题(即针对整个系统的问题): ·系统需要何种输入输出?输入从何处来?输出到何处? ·当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?
需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意:不同的设计者对用例的利用程度也不同。例如,Ivar Jacobson说,对一个十人年的项目,他需要二十个用例。而在一个相同规模的项目中,Martin Fowler则用了一百多个用例。我们认为:任何合适的用例都可使用,确定用例的过程是对获取的用例进行提炼和归纳的过程,对一个十人年的项目来说,二十个用例似乎太少,一百多个用例则嫌太多,需要保持二者间的相对均衡。
数千年以前,人类就已经开始采用分类的方法有效地简化复杂问题,帮助人们了解客观世界。在面向对象建模技术中,我们使用同样的方法将客观世界的实体映射为对象,并归纳成一个个类。类(Class)、对象(Object)和它们之间的关联是面向对象技术中最基本的元素。对于一个想要描述的系统,其类模型和对象模型揭示了系统的结构。在UML中,类和对象模型分别由类图和对象图表示。类图技术是OO方法的核心。图1显示了一个金融保险系统的类图。
(1) 类图
类图(Class Diagram)描述类和类之间的静态关系。与数据模型不同,它不仅显示了信息的结构,同时还描述了系统的行为。类图是定义其它图的基础。在类图的基础上,状态图、合作图等进一步描述了系统其他方面的特性。
(2) 类和对象
对象(Object)与我们对客观世界的理解相关。我们通常用对象描述客观世界中某个具体的实体。所谓类(Class)是对一类具有相同特征的对象的描述。而对象是类的实例(Instance)。建立类模型时,我们应尽量与应用领域的概念保持一致,以使模型更符合客观事实,易修改、易理解和易交流。 类描述一类对象的属性(Attribute)和行为(Behavior)。在UML中,类的可视化表示为一个划分成三个格子的长方形(下面两个格子可省略)。图1中,"客户"就是一个典型的类。 类的获取和命名 最顶部的格子包含类的名字。类的命名应尽量用应用领域中的术语,应明确、无歧义,以利于开发人员与用户之间的相互理解和交流。类的获取是一个依赖于人的创造力的过程,必须与领域专家合作,对研究领域仔细地分析,抽象出领域中的概念,定义其含义及相互关系,分析出系统类,并用领域中的术语为类命名。一般而言,类的名字是名词。 类的属性 中间的格子包含类的属性,用以描述该类对象的共同特点。该项可省略。图1中"客?quot;类有"客户名"、"地址"等特性。属性的选取应考虑以下因素: *原则上来说,类的属性应能描述并区分每个特定的对象; *只有系统感兴趣的特征才包含在类的属性中; *系统建模的目的也会影响到属性的选取。根据图的详细程度,每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。UML规定类的属性的语法为: 可见性 属性名 : 类型 = 缺省值 {约束特性} 图1"客户"类中,"客户名"属性描述为"- 客户名 : 字符串 = 缺省客户名"。 可见性"-"表示它是私有数据成员,其属性名为"客户名",类型为"字符串"类型,缺省值为"缺省客户名",此处没有约束特性。 不同属性具有不同可见性。常用的可见性有Public、Private和Protected三种,在UML中分别表示为"+"、"-"和"#"。 类型表示该属性的种类。它可以是基本数据类型,例如整数、实数、布尔型等,也可以是用户自定义的类型。一般它由所涉及的程序设计语言确定。 约束特性则是用户对该属性性质一个约束的说明。例如"{只读}"说明该属性是只读属性。
类的操作(Operation) 该项可省略。操作用于修改、检索类的属性或执行某些动作。操作通常也被称为功能,但是它们被约束在类的内部,只能作用到该类的对象上。操作名、返回类型和参数表组成操作界面。UML规定操作的语法为: 可见性 操作名 (参数表) : 返回类型 {约束特性} 在图1中,"客户"类中有"取客户地址"操作,其中" +"表示该操作是公有操作,调用时需要参数"客户名",参数类型为字符串,返回类型也为字符串。 类图描述了类和类之间的静态关系。定义了类之后,就可以定义类之间的各种关系了。
(3) 关联关系
关联(Association)表示两个类之间存在某种语义上的联系。例如,一个人为一家公司工作,一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义上的联系。在分析设计的类图模型中,则在对应人类和公司类、公司类和办公室类之间建立关联关系。 在图1中最上部存在一个"属于"/"签定"关联:每个"保险单"属于一个"客户",而"客户"可以签定多个"保险单"。除了这个关联外,图1中还有另外两个关联,分别表示每个"保险单"包含若干个"保险单上的项目",而每个"保险单上的项目"涉及单一的"保险类别"。 关联的方向 关联可以有方向,表示该关联单方向被使用。关联上加上箭头表示方向,在UML中称为导航(Navigability)。我们将只在一个方向上存在导航表示的关联,称作单向关联 ( Uni-directional Association ),在两个方向上都有导航表示的关联,称作双向关联 ( Bi-directional Association )。图1中,"保险单"?quot;保险单上的项目"是单向关联。UML规定,不带箭头的关联可以意味着未知、未确定或者该关联是双向关联三种选择,因此,在图中应明确使用其中的一种选择。 关联的命名 既然关联可以是双向的,最复杂的命名方法是每个方向上给出一个名字,这样的关联有两个名字,可以用小黑三角表示名字的方向(见图1中最上部的"属于"/"签定"关联)。为关联命名有几种方法,其原则是该命名是否有助于理解该模型。 角色 关联两头的类以某种角色参与关联。例如图2中,"公司"以"雇主"的角色,"人"以"雇员"的角色参与的"工作合同"关联。"雇主"和"雇员"称为角色名。如果在关联上没有标出角色名,则隐含地用类的名称作为角色名。角色还具有多重性(Multiplicity),表示可以有多少个对象参与该关联。在图2中,雇主(公司)可以雇佣(签工作合同)多个雇员,表示为"*"; 雇员只能与一家雇主签定工作合同,表示为"1"。多重性表示参与对象的数目的上下界限制。"*"代表0～∞,即一个客户可以没有保险单,也可以有任意多的保险单。"1"是1..1的简写,即任何一个保险单仅来自于一个客户,可以用一个单个数字表示,也可以用范围或者是数字和范围不连续的组合表示。
关联类 一个关联可能要记录一些信息,可以引入一个关联类来记录。图3是在图2的基础上引入了关联类。关联类通过一根虚线与关联连接。图4是实现上述目标的另外一种方法,就是使雇用关系成为一个正式的类。聚集和组成 聚集(Aggregation)是一种特殊形式的关联。聚集表示类之间的关系是整体与部分的关系。一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘,这是聚集的一个例子。在需求分析中,"包含"、"组成"、"分为……部分"等经常设计成聚集关系。聚集可以进一步划分成共享聚集(Shared Aggregation)和组成。例如,课题组包含许多成员,但是每个成员又可以是另一个课题组的成员,即部分可以参加多个整体,我们称之为共享聚集。另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会随之消失,这称为组成(Composition)。例如,我们打开一个视窗口,它就由标题、外框和显示区所组成。一旦消亡则各部分同时消失。在UML中,聚集表示为空心菱形,组成表示为实心菱形。需要注意的是,一些面向对象大师对聚集的定义并不一样。大家应注意其他面向对象方法与UML中所定义的聚集的差别。
(4) 继承关系
人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。例如,动物可分为飞鸟和走兽,人可分为男人和女人。在面向对象方法中将前者称为一般元素、基类元素或父元素,将后者称为特殊元素或子元素。继承(Generalization)定义了一般元素和特殊元素之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。 如图1中,将客户进一步分类成个体客户和团体客户,使用的就是继承关系。 在UML定义中对继承有三个要求: *特殊元素应与一般元素完全一致,一般元素所具有的关联、属性和操作,特殊元素也都隐含性地具有; *特殊元素还应包含额外信息; *允许使用一般元素实例的地方,也应能使用特殊元素。
(5) 依赖关系
有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则称元素Y依赖(Dependency)于元素X。在类中,依赖由各种原因引起,如:一个类向另一个类发消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。如果一个类的界面改变,它发出的任何消息可能不再合法。
(6) 类图的抽象层次和细化(Refinement)关系
需要注意的是,虽然在软件开发的不同阶段都使用类图,但这些类图表示了不同层次的抽象。在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接口;而在实现阶段,类图描述软件系统中类的实现。按照Steve Cook和John Dianiels的观点,类图分为三个层次。需要说明的是,这个观点同样也适合于其他任何模型,只是在类图中显得更为突出。 概念层 概念层(Conceptual)类图描述应用领域中的概念。实现它们的类可以从这些概念中得出,但两者并没有直接的映射关系。事实上,一个概念模型应独立于实现它的软件和程序设计语言。 说明层 说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分。面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这一差异。这主要是因为OO语言中类的概念将接口与实现合在了一起。大多数方法由于受到语言的影响,也仿效了这一做法。现在这种情况正在发生变化。可以用一个类型(Type )描述一个接口,这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现。 实现层 只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部分。这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的相互理解和交流。 理解以上层次对于画类图和读懂类图都是至关重要的。但是由于各层次之间没有一个清晰的界限,所以大多数建模者在画图时没能对其加以区分。画图时,要从一个清晰的层次观念出发;而读图时,则要弄清它是根据哪种层次观念来绘制的。要正确地理解类图,首先应正确地理解上述三种层次。虽然将类图分成三个层次的观点并不是UML的组成部分,但是它们对于建模或者评价模型非常有用。尽管迄今为止人们似乎更强调实现层类图,但这三个层次都可应用于UML,而且实际上另外两个层次的类图更有用。 下面介绍细化概念。细化是UML中的术语,表示对事物更详细一层的描述。两个元素A、B描述同一件事物,它们的区别是抽象层次不同,若元素B是在元素A的基础上的更详细的描述,则称元素B细化了元素A,或称元素A细化成元素B。细化的图形表示为由元素B指向元素A的、一头为空心三角的虚线(千万不要把方向颠倒了!)。细化主要用于模型之间的合作,表示开发各阶段不同层次抽象模型的相关性,常用于跟踪模型的演变。
(7) 约束
在UML中,可以用约束(Constraint)表示规则。约束是放在括号"{}"中的一个表达式,表示一个永真的逻辑陈述。在程序设计语言中,约束可以由断言(Assertion)来实现。
(8) 对象图、对象和链
UML中对象图与类图具有相同的表示形式。对象图可以看作是类图的一个实例。对象是类的实例;对象之间的链(Link)是类之间的关联的实例。对象与类的图形表示相似,均为划分成两个格子的长方形(下面的格子可省略)。上面的格子是对象名,对象名下有下划线;下面的格子记录属性值。链的图形表示与关联相似。对象图常用于表示复杂的类图的一个实例。
(9) 包
一个最古老的软件方法问题是:怎样将大系统拆分成小系统。解决这个问题的一个思路是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。这个思路被松散地应用到许多对象技术中。UML中这种分组机制叫包(Package)(见图5)。
不仅是类,任何模型元素都运用包的机制。如果没有任何启发性原则来指导类的分组,分组方法就是任意的。在UML中,最有用的和强调最多的启发性原则就是依赖。包图主要显示类的包以及这些包之间的依赖关系。有时还显示包和包之间的继承关系和组成关系。 包的内容 在图5中,"系统内部"包由"保险单"包和"客户"包组成。这里称"保险单"包和"客户"包为"系统内部"包的内容。当不需要显示包的内容时,包的名字放入主方框内,否则包的名字放入左上角的小方框中,而将内容放入主方框内。包的内容可以是类的列表,也可以是另一个包图,还可以是一个类图。 包的依赖和继承 图5中"保险单填写界面"包依赖于"保险单"包;整个"系统内部"包依赖于"数据库界面"包。可以使用继承中通用和特例的概念来说明通用包和专用包之间的关系。例如,专用包必须符合通用包的界面,与类继承关系类似。通过"数据库界面"包,"系统内部"包既能够使用Oracle的界面也可使用Sybase的界面。通用包可标记为{abs tract},表示该包只是定义了一个界面,具体实现则由专用包来完成。
(10) 其他模型元素和表示机制
类图中用到的模型元素和表示机制较为丰富,由于篇幅的限制,这里不能一一介绍。主要还有以下模型符号和概念:类别模板(Stereotype)、界面(Interface)、参数化类(P arameterized Class)也称模板类(Template)、限定关联(Qualified Association)、多维关联(N-ary Association)、多维链(N-ary Link)、派生(Derived)、类型(Type)和注释(Note)等。
(11) 使用类图的几个建议
类图几乎是所有OO方法的支柱。采用标准建模语言UML进行建模时,必须对UML类图引入的各种要素有清晰的理解。以下对使用类图进行建模提出几点建议: *不要试图使用所有的符号。从简单的开始,例如,类、关联、属性和继承等概念。在UML中,有些符号仅用于特殊的场合和方法中,只有当需要时才去使用。 *根据项目开发的不同阶段,用正确的观点来画类图。如果处于分析阶段,应画概念层类图;当开始着手软件设计时,应画说明层类图;当考察某个特定的实现技术时,则应画实现层类图。 *不要为每个事物都画一个模型,应该把精力放在关键的领域。最好只画几张较为关键的图,经常使用并不断更新修改。使用类图的最大危险是过早地陷入实现细节。为了避免这一危险,应该将重点放在概念层和说明层。如果已经遇到了一些麻烦,可以从以下几个方面来反思你的模型。 *模型是否真实地反映了研究领域的实际。 *模型和模型中的元素是否有清楚的目的和职责(在面向对象方法中,系统功能最终是分配到每个类的操作上实现的,这个机制叫职责分配)。 *模型和模型元素的大小是否适中。过于复杂的模型和模型元素是很难生存的,应将其分解成几个相互合作的部分。
构件图(Component diagram)和配置图(Deployment diagram)显示系统实现时的一些特性,包括源代码的静态结构和运行时刻的实现结构。构件图显示代码本身的结构,配置图显示系统运行时刻的结构。
(1) 构件图构件图显示软件构件之间的依赖关系。一般来说,软件构件就是一个实际文件,可以是源代码文件、二进制代码文件和可执行文件等。可以用来显示编译、链接或执行时构件之间的依赖关系。
(2) 配置图配置图描述系统硬件的物理拓扑结构以及在此结构上执行的软件。配置图可以显示计算结点的拓扑结构和通信路径、结点上运行的软件构件、软件构件包含的逻辑单元(对象、类)等。配置图常常用于帮助理解分布式系统。
(3) 结点和连接 结点(Node)代表一个物理设备以及其上运行的软件系统,如一台Unix主机、一个PC终端、一台打印机、一个传感器等。如图1所示,"客户端PC"和"保险后台服务器"就是两个结点。结点表示为一个立方体,结点名放在左上角。 结点之间的连线表示系统之间进行交互的通信路径,在UML中被称为连接(Connectio n)。通信类型则放在连接旁边的"《》"之间,表示所用的通信协议或网络类型。
(4) 构件和界面 在配置图中,构件代表可执行的物理代码模块,如一个可执行程序。逻辑上它可以与类图中的包或类对应。因此,配置图中显示运行时各个包或类在结点中的分布情况。如在图1中,"保险后台服务器" 结点中包含"保险系统"、"保险对象数据库"和"保险系统配置"3个构件。在面向对象方法中,类和构件等元素并不是所有的属性和操作都对外可见。它们对外提供了可见操作和属性,称之为类和构件的界面。界面可以表示为一头是小园圈的直线。图1中,"保险系统"构件提供了一个"配置"界面。配置图中还显示了构件之间的依赖关系,"保险系统配置"构件依赖于这个"配置"界面。
(5) 对象(Object) 一个面向对象软件系统中可以运行很多对象。由于构件可以看作与包或类对应的物理代码模块,因此,构件中应包含一些运行的对象。配置图中的对象与对象图中的对象表示法一样。图1中,"保险系统配置"构件包含"配置保险政策"和"配置用户"两个对象。 标准建模语言UML的静态建模机制是采用UML进行建模的基础。我们认为,熟练掌握基本概念、区分不同抽象层次以及在实践中灵活运用,是三条最值得注意的基本原则。
