快捷搜索:

标准建模语言UML概述

面向工具技巧和UML的成长历程可用上图来表示,标准建模说话的呈现是其紧张成果。

在美国,截止1996年10月,UML得到了工业界、科技界和利用界的广泛支持,已有700多个公司表示支持采纳UML作为建模说话。

1996岁尾,UML已稳占面向工具技巧市场的85%,成为可视化建模说话事实上的工业标准。1997年11月17日,OMG采用UML

1.1作为基于面向工具技巧的标准建模说话。UML代表了面向工具措施的软件开拓技巧的成长偏向,具有伟大年夜的市场前景,也具有重大年夜的经济代价和国防代价。

2. 标准建模说话UML的内容首先,UML交融了Booch、OMT和OOSE措施中的基础观点,而且这些基础观点与其他面向工具技巧中的基础观点大年夜多相同,因而,UML一定成为这些措施以及其他措施的应用者乐于采纳的一种简单同等的建模说话;其次,UML不仅仅是上述措施的简单汇合,而是在这些措施的根基上广泛收罗意见,集众家之长,几经改动而完成的,UML扩展了现有措施的利用范围;第三,UML是标准的建模说话,而不是标准的开拓历程。

只管UML的利用一定以系统的开拓历程为背景,但因为不合的组织和不合的利用领域,必要采取不合的开拓历程。作为一种建模说话,UML的定义包括UML语义和UML表示法两个部分。

(1) UML语义 描述基于UML的正确元模型定义。元模型为UML的所有元素在语法和语义上供给了简单、同等、通用的定义性阐明,使开拓者能在语义上取得同等,打消了因人而异的最佳表达措施所造成的影响。此外UML还支持对元模型的扩展定义。

(2) UML表示法 定义UML符号的表示法,为开拓者或开拓对象应用这些图形符号和文本语法为系统建模供给了标准。这些图形符号和翰墨所表达的是利用级的模型,在语义上它是UML元模型的实例。

标准建模说话UML的紧张内容可以由下列五类图(共9种图形)来定义:

·第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。

·第二类是静态图(Static diagram),包括类图、工具图和包图。此中类图描述系统中类的静态布局。

不仅定义系统中的类,表示类之间的联系如关联、依附、聚合等,也包括类的内部布局(类的属性和操作)。类图描述的是一种静态关系,在系统的全部生命周期都是有效的。工具图是类图的实例,险些应用与类图完全相同的标识。他们的不合点在于工具图显示类的多个工具实例,而不是实际的类。

一个工具图是类图的一个实例。因为工具存在生命周期,是以工具图只能在系统某一光阴段存在。

包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层布局。

·第三类是行径图(Behavior diagram),描述系统的动态模型和组成工具间的交互关系。

此中状态图描述类的工具所有可能的状态以及事故发生时状态的转移前提。平日,状态图是对类图的弥补。

在实用上并不必要为所有的类画状态图,仅为那些有多个状态其行径受外界情况的影响并且发生改变的类画状态图。而活动图描述满意用例要求所要进行的活动以及活动间的约束关系,有利于识别并交活动。

·第四类是交互图(Interactive diagram),描述工具间的交互关系。

此中顺序图显示工具之间的动态相助关系,它强调工具之间消息发送的顺序,同时显示工具之间的交互;相助图描述工具间的协作关系,相助图跟顺序图相似,显示工具间的动态相助关系。

除显示信息互换外,相助图还显示工具以及它们之间的关系。假如强调光阴和顺序,则应用顺序图;假如强调高低级关系,则选择相助图。这两种图合称为交互图。

·第五类是实现图( Implementation diagram )。

此中构件图描述代码部件的物理布局及各部件之间的依附关系。

一个部件可能是一个资本代码部件、一个二进制部件或一个可履行部件。它包孕逻辑类或实现类的有关信息。部件图有助于阐发和理解部件之间的互相影响程度。

设置设置设备摆设摆设图定义系统中软硬件的物理体系布局。

它可以显示实际的谋略机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依附性。

在节点内部,放置可履行部件和工具以显示节点跟可履行软件单元的对应关系。

从利用的角度看,当采纳面向工具技巧设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的布局;第三步是描述系统的行径。

此中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包孕包)、工具图、组件图和设置设置设备摆设摆设图等五个图形,是标准建模说话UML的静态建模机制。

此中第三步中所建立的模型或者可以履行,或者表示履行时的时序状态或交互关系。它包括状态图、活动图、顺序图和相助图等四个图形,是标准建模说话UML的动态建模机制。

是以,标准建模说话UML的主要内容也可以归纳为静态建模机制和动态建模机制两大年夜类。

3. 标准建模说话UML的主要特征标准建模说话UML的主要特征可以归结为三点:

(1) UML统一了Booch、OMT和OOSE等措施中的基础观点。

(2) UML还罗致了面向工具技巧领域中其他流派的长处,此中也包括非OO措施的影响。

UML符号表示斟酌了各类措施的图形表示,删掉落了大年夜量易引起纷乱的、多余的和极少应用的符号,也添加了一些新符号。是以,在UML中汇入了面向工具领域中很多人的思惟。

这些思惟并不是UML的开拓者们发现的,而是开拓者们依据最优秀的OO措施和富厚的谋略机科学实践履历综合提炼而成的。

(3) UML在蜕变历程中还提出了一些新的观点。在UML标准中新加了模板(Stereotypes)、职责(Responsibilities)、扩展机制(Extensibility mechanisms)、线程(Threads)、历程(Processes)、散播式(Distribution)、并发(Concurrency)、模式(Patterns)、相助(Collaborations)、活动图(Activity diagram)等新观点,并清晰地区分类型(Type)、类(Class)和实例(Instance)、细化(Refinement)、接口(Interfaces)和组件(Components)等观点。

是以可以觉得,UML是一种先辈实用的标准建模说话,但此中某些观点尚待实践来验证,UML也一定存在一个进化历程。

4. 标准建模说话UML的利用领域UML的目标因此面向工具图的要领来描述任何类型的系统,具有很宽的利用领域。此中最常用的是建立软件系统的模型,但它同样可以用于描述非软件领域的系统,如机器系统、企业机构或营业历程,以及处置惩罚繁杂数据的信息系统、具有实时要求的工业系统或工业历程等。

总之,UML是一个通用的标准建模说话,可以对任何具有静态布局和动态行径的系统进行建模。此外,UML适用于系统开拓历程中从需求规格描述到系统完成后测试的不合阶段。在需求阐发阶段,可以用用例来捕获用户需求。

经由过程用例建模,描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。阐发阶段主要关心问题域中的主要观点(如抽象、类和工具等)和机制,必要识别这些类以及它们互相间的关系,并用UML类图来描述。为实现用例,类之间必要协作,这可以用UML动态模型来描述。

在阐发阶段,只对问题域的工具(现实天下的观点)建模,而不斟裁夺义软件系统中技巧细节的类(如处置惩罚用户接口、数据库、通讯和并行性等问题的类)。这些技巧细节将在设计阶段引入,是以设计阶段为构造阶段供给更具体的规格阐明。

编程(构造)是一个自力的阶段,其义务是用面向工具编程说话将来自设计阶段的类转换成实际的代码。在用UML建立阐发和设计模型时,应只管即便避免斟酌把模型转换成某种特定的编程说话。

由于在早期阶段,模型仅仅是理解和阐发系统布局的对象,过早斟酌编码问题十分晦气于建立简单精确的模型。

UML模型还可作为测试阶段的依据。系统平日必要颠末单元测试、集成测试、系统测试和验收测试。

不合的测试小组应用不合的UML图作为测试依据:单元测试应用类图和类规格阐明;集成测试应用部件图和相助图;系统测试应用用例图来验证系统的行径;验收测试由用户进行,以验证系统测试的结果是否满意在阐发阶段确定的需求。

总之,标准建模说话UML适用于以面向工具技巧来描述任何类型的系统,而且适用于系统开拓的不合阶段,从需求规格描述直至系统完成后的测试和掩护。

二、标准建模说话UML的静态建模机制

任何建模说话都以静态建模机制为根基,标准建模说话UML也不例外。

UML的静态建模 机制包括用例图(Use case diagram)、类图(Class diagram)、工具图(Object diagram )、包(Package)、构件图(Component diagram)和设置设置设备摆设摆设图(Deployment diagram)。

1. 用例图

(1) 用例模型(Use case model) 经久以来,在面向工具开拓和传统的软件开拓中,人们根据范例的应用情景来懂得需 求。

然则,这些应用情景长短正式的,虽然常常应用,却难以建立正式文挡。用例模型由I var 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则用了一百多个用例。我们觉得:任何相宜 的用例都可应用,确定用例的历程是对获取的用例进行提炼和归纳的历程,对一个十人年 的项目来说,二十个用例彷佛太少,一百多个用例则嫌太多,必要维持二者间的相对均衡。

2. 类图、工具图和包 数千年曩昔,人类就已经开始采纳分类的措施有效地简化繁杂问题,赞助人们懂得客 不雅天下。

在面向工具建模技巧中,我们应用同样的措施将客不雅天下的实体映射为工具,并 归纳成一个个类。类(Class)、工具(Object)和它们之间的关联是面向工具技巧中最基础 的元素。

对付一个想要描述的系统,其类模型和工具模型揭示了系统的布局。在UML中,类 和工具模型分手由类图和工具图表示。

类图技巧是OO措施的核心。图1显示了一个金融保 险系统的类图。

(1) 类图 类图(Class Diagram)描述类和类之间的静态关系。与数据模型不合,它不仅显示了 信息的布局,同时还描述了系统的行径。类图是定义其它图的根基。

在类图的根基上,状 态图、相助图等进一步描述了系统其他方面的特点。

(2) 类和工具 工具(Object)与我们对客不雅天下的理解相关。我们平日用工具描述客不雅天下中某个 详细的实体。

所谓类(Class)是对一类具有相同特性的工具的描述。而工具是类的实例( Instance)。建立类模型时,我们应只管即便与利用领域的观点维持同等,以使模型更相符客不雅 事实,易改动、易理解和易交流。

类描述一类工具的属性(Attribute)和行径(Behavior)。在UML中,类的可视化表示为 一个划分成三个格子的长方形(下面两个格子可省略)。

图1中,"客户"便是一个范例的类 。 类的获取和命名 最顶部的格子包孕类的名字。

类的命名应只管即便用利用领域中的术 语,应明确、无歧义,以利于开拓职员与用户之间的互相理解和交流。

类的获取是一个依 赖于人的创造力的历程,必须与领域专家相助,对钻研领域仔细地阐发,抽象出领域中的概 念,定义其含义及互相关系,阐发出系统类,并用领域中的术语为类命名。一样平常而言,类的 名字是名词。 类的属性 中心的格子包孕类的属性,用以描述该类工具的合营特征。

该项可省略。

图1中"客户"类有"客户名"、"地址"等特点。属性的拔取应斟酌以下身分: *原则上来说,类的属性应能描述并区分每个特定的工具;

*只有系统感兴趣的特性才包孕在类的属性中; *系统建模的目的也会影响到属性的拔取。 根据图的具体程度,每条属性可以包括属性的可见性、属性名称、类型、缺省值和约 束特点。

UML规定类的属性的语法为: 可见性 属性名 : 类型 = 缺省值 {约束特点} 图1"客户"类中,"客户名"属性描述为"- 客户名 : 字符串 = 缺省客户名"。

可见性 "-"表示它是私稀有据成员,其属性名为"客户名",类型为"字符串"类型,缺省值为"缺省客 户名",此处没有约束特点。

不合属性具有不合可见性。常用的可见性有Public、Private和Protected三种,在U ML平分腕表示为"+"、"-"和"#"。

类型表示该属性的种类。它可所以基础数据类型,例如整数、实数、布尔型等,也可 所以用户自定义的类型。一样平常它由所涉及的法度榜样设计说话确定。

约束特点则是用户对该属性性子一个约束的阐明。例如"{只读}"阐明该属性是只读 属性。 类的操作(Operation) 该项可省略。操感化于改动、检索类的属性或履行某些动作 。

操作平日也被称为功能,然则它们被约束在类的内部,只能感化到该类的工具上。操作 名、返回类型和参数表组成操作界面。

UML规定操作的语法为: 可见性 操作名 (参数表) : 返回类型 {约束特点} 在图1中,"客户"类中有"取客户地址"操作,此中" +"表示该操作是公有操作,调用时 必要参数"客户名",参数类型为字符串,返回类型也为字符串。 类图描述了类和类之间的静态关系。定义了类之后,就可以定义类之间的各类关系了 。

(3) 关联关系 关联(Association)表示两个类之间存在某种语义上的联系。例如,一小我为一家公 司事情,一家公司有许多办公室。我们就觉得人和公司、公司和办公室之间存在某种语义 上的联系。在阐发设计的类图模型中,则在对应人类和公司类、公司类和办公室类之间建 立关联关系。

在图1中最上部存在一个"属于"/"签定"关联:每个"保险单"属于一个"客户",而"客户 "可以签定多个"保险单"。除了这个关联外,图1中还有别的两个关联,分腕表示每个"保险 单"包孕多少个"保险单上的项目",而每个"保险单上的项目"涉及单一的"保险种别"。 关联的偏向 关联可以有偏向,表示该关联单偏向被应用。关联上加上箭头表示偏向 ,在UML中称为导航(Navigability)。我们将只在一个偏向上存在导航表示的关联,称作单 向关联 ( Uni-directional Association ),在两个偏向上都有导航表示的关联,称作双 向关联 ( Bi-directional Association )。

图1中,"保险单"到"保险单上的项目"是单向 关联。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中,有些符号仅用于特殊的场合和措施中,只有当必要时才去应用。

*根据项目开拓的不合阶段,用精确的不雅点来画类图。假如处于阐发阶段,应画观点层 类图;当开始动手软件设计时,应画阐明层类图;当考察某个特定的实现技巧时,则应画实 现层类图。

*不要为每个事物都画一个模型,应该把精力放在关键的领域。最好只画几张较为关 键的图,常常应用并赓续更新改动。 应用类图的最大年夜危险是过早地陷入实现细节。为了避免这一危险,应该将重点放在概 念层和阐明层。假如已经碰到了一些麻烦,可以从以下几个方面来反思你的模型。

*模型是否真实地反应了钻研领域的实际。 *模型和模型中的元素是否有清楚的目的和职责(在面向工具措施中,系统功能终极是 分配到每个类的操作上实现的,这个机制叫职责分配)。

*模型和模型元素的大年夜小是否适中。过于繁杂的模型和模型元素是很难生计的,应将 其分化成几个互相相助的部分。

(12) 术语对照 下表列出了最常用的四种UML术语,并与其他措施学中相对应的术语进行对照,以赞助 读者懂得UML与其他建模说话的异同。

3. 构件图和设置设置设备摆设摆设图 构件图(Component diagram)和设置设置设备摆设摆设图(Deployment diagram)显示系统实现时的一些 特点,包括源代码的静态布局和运行时候的实现布局。构件图显示代码本身的布局,设置设置设备摆设摆设 图显示系统运行时候的布局。

(1) 构件图 构件图显示软件构件之间的依附关系。一样平常来说,软件构件便是一个实 际文件,可所以源代码文件、二进制代码文件和可履行文件等。可以用来显示编译、链接 或履行时构件之间的依附关系。

(2) 设置设置设备摆设摆设图 设置设置设备摆设摆设图描述系统硬件的物理拓扑布局以及在此布局上履行的软件。设置设置设备摆设摆设 图可以显示谋略结点的拓扑布局和通信路径、结点上运行的软件构件、软件构件包孕的 逻辑单元(工具、类)等。设置设置设备摆设摆设图经常用于赞助理遣散播式系统。

(3) 结点和连接 结点(Node)代表一个物理设备以及其上运行的软件系统,如一台U nix主机、一个PC终端、一台打印机、一个传感器等。如图1所示,"客户端PC"和"保险后 台办事器"便是两个结点。结点表示为一个立方体,结点名放在左上角。 结点之间的连线表示系统之间进行交互的通信路径,在UML中被称为连接(Connectio n)。通信类型则放在连接左右的"《》"之间,表示所用的通信协议或收集类型。

(4) 构件和界面 在设置设置设备摆设摆设图中,构件代表可履行的物理代码模块,如一个可履行法度榜样 。逻辑上它可以与类图中的包或类对应。是以,设置设置设备摆设摆设图中显示运行时各个包或类在结点中 的散播环境。如在图1中,"保险后台办事器" 结点中包孕"保险系统"、"保险工具数据库 "和"保险系统设置设置设备摆设摆设"3个构件。 在面向工具措施中,类和构件等元素并不是所有的属性和操作都对外可见。

它们对外 供给了可见操作和属性,称之为类和构件的界面。界面可以表示为一头是小园圈的直线。

图1中,"保险系统"构件供给了一个"设置设置设备摆设摆设"界面。设置设置设备摆设摆设图中还显示了构件之间的依附关系 ,"保险系统设置设置设备摆设摆设"构件依附于这个"设置设置设备摆设摆设"界面。

(5) 工具(Object) 一个面向工具软件系统中可以运行很多工具。因为构件可以看 作与包或类对应的物理代码模块,是以,构件中应包孕一些运行的工具。设置设置设备摆设摆设图中的工具 与工具图中的工具表示法一样。

图1中,"保险系统设置设置设备摆设摆设"构件包孕"设置设置设备摆设摆设保险政策"和"设置设置设备摆设摆设 用户"两个工具。

标准建模说话UML的静态建模机制是采纳UML进行建模的根基。我们觉得,纯熟掌握基 本观点、区分不合抽象层次以及在实践中机动运用,是三条最值得留意的基滥觞基本则。

您可能还会对下面的文章感兴趣: