Reasoning on UML class diagrams

《软件工程》习题汇锦一、单项选择题提示：在每小题列出的四个备选项中只有一个是符合题目要求的，请将其代码填写在下表中。

错选、多选或未选均无分.1. ( ）If a system is being developed where the customers are not sure of what theywant, the requirements are often poorly defined。

Which of the following would be an appropriate process model for this type of development?（A）prototyping（B）waterfall（C)V-model（D）spiral2. （)The project team developing a new system is experienced in the domain.Although the new project is fairly large, it is not expected to vary much from applications that have been developed by this team in the past. Which process model would be appropriate for this type of development？（A）prototyping（B）waterfall（C）V-model（D）spiral3. （）Which of the items listed below is not one of the software engineering layers?(A）Process（B）Manufacturing（C）Methods（D)T ools4. （)Which of these are the 5 generic software engineering framework activities？（A）communication，planning，modeling，construction，deployment（B) communication, risk management, measurement，production, reviewing(C）analysis，designing，programming, debugging, maintenance（D）analysis, planning，designing，programming，testing5. （）The incremental model of software development is（A）A reasonable approach when requirements are well defined.(B）A good approach when a working core product is required quickly。

UMl期末考试题一、选择题(30) 选择题( ) 1.模型的特征是什么? ( ABCD ) (多选) A. 反映性 B. 简化性 C. 直观性 D. 抽象性 2.从抽象角度看，模型分为哪几种, ( ABC ) (多选) A.概念模型 B. 逻辑模型 C. 物理模型 D. 工程模型 3.下面说法错误的是: ( C ) A 参与者是与所建立系统交互的人或物 B 参与者可以是人,也可以是其他系统 C 参与者是系统的一部分,是用例图的重要组成部分 D 参与者之间存在泛化关系 4.下面正确的说法是: (D) A 对象表示客观中存在的实物 B 类是对象的实例 C 类是具有相同属性和操作的对象的集合 D 对象也就是类 5.下面不属于类的关系的是: (D) A 泛化 B 聚集 C 关联 D 传递 6.下面 4 种图中,( A )可以描述一个用例中多个对象之间的相互协作关系以及协作过程中的行为次序关系.A 交互图B 状态图C 对象图D 用例图 7.下面( C? )建模元素不能在协作图中表示出来。

(多选) A 状态 B 消息 C 活动 D 多对象 RUP 迭代开发模型包括( ABCE )四个阶段 A 初始 B 精化 C 构建 D 部署 E 交付 8.从严格意义上讲，下列四个选项中不属于顺序图的内容是( B ) A 对象 B 参与者 C 消息 D 控制焦点 9.在状态图中可以表示的概念有( A B C )(多选). A 动作 B 事件 C 转移 D 用例 10.如果要对一个企业的工作流程建模，下面四个图中( B )是最有用的。

A 交互图 B 活动图 C 状态图 D 类图 11.在顺序图中消息的类型有哪些( ABCDE ) (多选) A 同步消息 B 异步消息 C 返回消息 D 阻止消息 E.超时消息 12.Three items of interest in use case diagrams are: A. Objects, activities, and communications C. Objects, use cases, and activities 13.Every student at CSUFT (D) B. Actors, messages, and activities D. Actors, use cases, and communications will be advised by one teacher. Some teachers advise many students, and some advise none. Which of the following class diagrams most clearly represents that student-teacher relationship? (D) A. B.C. D. (D) 14.Which of the following pseudo code implements the activity diagram blow? What is the symbol for a component in a deployment diagram? (D) A. There is no symbol because components are not allowed in deployment diagrams. B. A rounded rectangle, just like a state in a state diagram. C. A 3-dimensional rectangular solid (like a box). D. A rectangle with tabs on its left side. 二、填空题( 20 分 ) 1.模型的三要素包括过程、工具、表示法 ) ( 2.对象是( 系统中用来描述客观事物 )的一个实体，它用来表示( 客观存在 )中的事物，和人主观构造中的( 抽象观念 )。

继承、实现、依赖、关联、聚合、组合的联系与区别分别介绍这几种关系：继承实现指的是一个class 类实现interface 接口（可以是多个）的功能；实现是类与接口之间最常 见的关系；在Java 中此类关系通过关键字implements 明确标识，在设计时一般没有争 议性；依赖可以简单的理解，就是一个类A 使用到了另一个类B ，而这种使用关系是具有偶然性的、、 临时性的、非常弱的，但是B 类的变化会影响到A ；比如某人要过河，需要借用一条船， 此时人与船之间的关系就是依赖;表现在代码层面，为类B 作为参数被类A 在某个method 方法中使用；Inte rfare指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可 以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java 中此类关系通过关键字extends 明确标识，在设计时一般没有争议性；b lnterface_BQlass_A ClaSs_B关联他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这 种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而 且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B 以类属性的形式出现在关联类A 中，也可能是关联类A 引用了一个类型为被关联类B 的全 局变量；聚合聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a 的关系，此 时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象， 也可以为多个整体对象共享；比如计算机与CPU 、公司与员工的关系等；表现在代码层面， 和关联关系是一致的，只能从语义级别来区分；组合组合也是关联关系的一种特例，他体现的是一种contains-a 的关系，这种关系比聚合更强， 也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生 命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；表现在代码层面，和关联 关系是一致的，只能从语义级别来区分；对于继承、实现这两种关系没多少疑问，他们体现的是一种类与类、或者类与接口间的纵向 关系；其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系，是比较难区 分的，有很多事物间的关系要想准备定位是很难的，前面也提到，这几种关系都是语义级别Cl3ss A 十 depend<Qlass.B classBJ ；:；；VoidClass_B的，所以从代码层面并不能完全区分各种关系；但总的来说，后几种关系所表现的强弱程度依次为：组合＞聚合＞关联》依赖；聚合跟组合其实都属于关联只不过它们是两种特殊的关联因为本是同根生所以它们之间难 免会有相似之处下面让我们一起来看一下它们之间有何不同聚合与组合的概念相信不用我在此赘述大家就已经了解了下面直接上例子 程老师的《大话》里举大那个大雁的例子很贴切在此我就借用一下大雁喜欢热闹害怕孤独所 以它们一直过着群居的生活这样就有了雁群每一只大雁都有自己的雁群每个雁群都有好多 大雁大雁与雁群的这种关系就可以称之为聚合另外每只大雁都有两只翅膀大雁与雁翅的关 系就叫做组合有此可见聚合的关系明显没有组合紧密大雁不会因为它们的群主将雁群解散 而无法生存而雁翅就无法脱离大雁而单独生存一一组合关系的类具有相同的生命周期聚合关系图：构造函数不同雁群类:[csharp] view plaincopypublic class GooseGroup { public Goose goose; public GooseGroup(Goose goose) { this .goose = goose;} 10. }[csharp] view plaincopy1. 2. 3.4.5. 6.7. 8.9. 组合关系图:从从代码上看这两种关系的区别在于:1.public class GooseGroup2.{3.public Goose goose;4.5.6.public GooseGroup(Goose goose)7.{8.this.goose = goose;9.}10.}大雁类：[csharp] view plaincopy1.public class Goose2.{3.public Wings wings;4.5.public Goose()6.{7.wings=new Wings();8.}9.}[csharp] view plaincopy1.public class Goose2.{3.public Wings wings;4.5.public Goose()6.{7.wings=new Wings();8.}9.}聚合关系的类里含有另一个类作为参数雁群类（GooseGroup）的构造函数中要用到大雁（Goose）作为参数把值传进来大雁类（Goose）可以脱离雁群类而独立存在组合关系的类里含有另一个类的实例化大雁类（Goose）在实例化之前一定要先实例化翅膀类（Wings）两个类紧密耦合在一起它们有相同的生命周期翅膀类(Wings)不可以脱离大雁类(Goose)而独立存在信息的封装性不同在聚合关系中，客户端可以同时了解雁群类和大雁类，因为他们都是独立的而在组合关系中，客户端只认识大雁类，根本就不知道翅膀类的存在，因为翅膀类被严密的封装在大雁类中。

ISSN 1000-9825, CODEN RUXUEW E-mail: jos@Journal of Software, Vol.20, No.6, June 2009, pp.1487−1498 doi: 10.3724/SP.J.1001.2009.03417 Tel/Fax: +86-10-62562563© by Institute of Software, the Chinese Academy of Sciences. All rights reserved.UML类图层次化自动布图算法∗王晓博+, 王欢, 刘超(北京航空航天大学软件工程研究所,北京 100191)Automatic Hierarchical Layout Algorithm for UML Class DiagramWANG Xiao-Bo+, WANG Huan, LIU Chao(Software Engineering Institute, BeiHang University, Beijing 100191, China)+ Corresponding author: E-mail: boby@, Wang XB, Wang H, Liu C. Automatic hierarchical layout algorithm for UML class diagram. Journal ofSoftware, 2009,20(6):1487−1498. /1000-9825/3417.htmAbstract: UML class diagrams are helpful for understanding complicated object-oriented software systems. Thereasonable placement of diagram elements can make class diagrams more readable and understandable. Asinheritance is regarded as a hierarchical relation, the hierarchical layout method is usually adopted to draw UMLclass diagrams. Because the domain specific knowledge and drawing criteria related to class diagrams must beconsidered in the layout of diagrams, general hierarchical layout algorithms for nested digraphs should be extendedaccording to these criteria. But existing hierarchical layout algorithms for class diagrams cannot handle the nestedrelations among packages, classes, and interfaces, and existing compound layout methods for digraphs cannot beused directly to draw class diagrams. Layout criteria are selected based on the knowledge of graph drawingaesthetics, UML class diagram semantics and software visualization. In addition, the nested constraints in rankassignment, edge crossing, and coordinate assignment of hierarchical layout method were also analyzed in thispaper. Then, existing hierarchical layout algorithm was extended to cope with nested graphs according to nestedcriteria. Experiment results show that the drawings of the reversed class diagrams are more readable andunderstandable with proper hierarchies, nested relations, less crossings and optimal drawing area.Key words: layout algorithm; software visualization; UML class diagram; reverse engineering摘要: UML类图能够有效地帮助软件工程师理解大规模的软件系统,而优化图元的空间布局可以增强类图的可读性和可理解性.由于类图中继承关系具有明显的层次特性,因此类图自动布局大多采用层次化的布图算法.此外,类图布局需要考虑相关的领域知识以及绘制准则,因而通用嵌套有向图层次化布局算法不能直接用于类图的绘制,它们必须加以扩展.但是,已有的类图层次化方法并没有考虑类图中图元的嵌套关系,这将导致自动布局方法不能处理类图中包与类、接口之间的包含关系.在考虑图绘制美学、UML类图绘制以及软件可视化等相关知识的基础上,选取了一组布图准则并分析了嵌套关系在层次分配、层内排序和坐标分配中引入的约束,通过在层次化方法的主要步骤中引入嵌套约束,提出了嵌套有向图层次化布图算法.实验结果表明,扩展的布图算法能够适应于逆向类∗ Supported by the National Natural Science Foundation of China under Grant No.90718018 (国家自然科学基金); the NationalHigh-Tech Research and Development Plan of China under Grant No.2006AA01Z176 (国家高技术研究发展计划(863))Received 2008-04-03; Accepted 2008-07-021488 Journal of Software软件学报 V ol.20, No.6, June 2009图的绘制,它具有层次清晰、支持图元嵌套、交叉数目少以及占用面积小等优点.关键词: 布图算法;软件可视化;UML类图;逆向工程中图法分类号: TP311文献标识码: AUML类图是一种描述软件静态结构的有效方法,它在软件正向建模、逆向工程和程序理解等领域都发挥着重要的作用.Tilley[1]通过实验指出,UML类图可以帮助软件工程师理解大规模的软件系统,但其有效性主要取决于UML的语法和语义、图元的空间布局和领域知识等方面,其中空间布局在增强类图的可读性以及可理解性方面显得尤为关键.现有的可视化建模工具(如IBM RSA,rational rose,borland together,eclipse GMF等)都提供了类图自动布局以及从程序中逆向绘制类图的功能,而目前UML类图自动布局所采用的布图算法主要分为拓扑-形状-度量[2,3]、层次化[4−6]、力学制导[7]和遗传算法[8]等方法.由于类图中的继承关系具有明显的层次特征,为了使布局结果的层次更为清晰,在设计类图布图算法时,通常将聚集关系和实现关系也作为具有层次特征的边来处理[4,9,10],所以,基于层次化的类图布局方法应用较广.然而,目前的类图层次化方法没有考虑类图中包(package)之间的嵌套关系,从而导致布图算法不能处理类图中包与类、接口之间的包含关系.已有的支持嵌套图布局算法[11,12]并没有考虑到嵌套类图的特点,而且它们都根据不同领域的需求进行了扩展和改造,因此不能直接用于类图的自动布局.本文将主要讨论如何扩展层次化布图算法以支持含有嵌套图元的逆向类图绘制.类图的可读性与可理解性主要通过布局约束来限定,而这些约束来自于通用的图绘制(graph drawing)美学、人机交互、软件可视化以及软件工程等方面.约束之间很容易产生冲突,如图的高度最小化与图纵横比调整、边的长度优化与边交叉最小化等.因此,如何选择合适的布图约束对于布图算法的设计非常重要.Sun[13]对类图布局约束进行了系统的分类和整理,本文依据逆向绘制类图的特点从中选取了一组布局约束,并在Gansner[14]层次化算法的基础上提出了支持图元包含的嵌套有向图层次化算法.层次化布图主要分为层次分配、层内排序和坐标分配3个步骤,如何将图元之间的嵌套关系转化为布图约束并应用到层次化布图的关键步骤中,是本文要解决的核心问题.本文第1节描述逆向绘制类图的布局约束.第2节分析图元嵌套关系对层次化类图布局所产生的影响.第3节介绍嵌套有向图布图算法.第4节是实验结果分析及讨论.第5节给出结论.1 逆向绘制类图的布局约束在逆向绘制的类图中,节点类型分为包、类和接口,边的类型分为继承、聚集、实现和关联.Sun[13]整理的约束分为9类,共14条,本文根据类图可读性与可理解性从中选取最主要的约束并将其归纳为以下5条规则: A1. 具有明显的层次化结构并能展示图元之间的嵌套关系,所有层次边(具有层次特性的边,如继承、聚集、有向关联)的方向尽可能地一致.文中默认层次方向为自下而上,即类图为上行图(upward graph).A2. 减少边交叉的数目和边中拐点的数目,提高边的连贯性.A3. 最小化边的长度,尽量缩短相连节点之间的距离.A4. 避免边与包图元之间的交叉以及包图元之间的重叠,这将会导致一条边与多个包内的子图元交叉.A5. 减小结果图所占用的面积,具有合理的纵横比.对于满足规则A2~A5,目前已有行之有效的布图算法[7,14],但是规则A1的引入对规则A2~A5都造成了直接影响,因为传统的基于Sugiyama[15]层次化算法都不能处理图元嵌套的情况.Sugiyama[12]给出了一种绘制普通复合图的方法,但是它所处理的普通复合图与类图不同,算法中并不区分节点和边的类型,而且在层次化和边交叉最小化时不能处理UML类图特有的节点顺序有效性.为了深入讨论具有嵌套图元特性的布局约束,本文首先定义了支持嵌套图元的类图以及布图算法中用到的基本概念,进而把规则A1~A5转化为数学语言描述的约束.1.1 类图定义定义1(有向图). G=〈V,E,φ〉为有序三元组,其中,V为节点集(非空),E为边集,而φ是E到V中元素有序对簇王晓博 等:UML 类图层次化自动布图算法 1489 V ×V 的函数,称为关联函数.V 中元素称为节点(vertex),E 中元素称为边(edge),φ刻画了边与节点之间的关联关系.令v ∈V 为G 中的节点,记d (v )为v 的度数,d +(v )为v 的出度,d −(v )为v 的入度.类图中除了具有方向性的继承边、聚集边和实现边之外,还存在无方向性的关联边,为了应用有向图层次布图算法,本文通过比较关联边两个端点的度数指定了它的方向(e =(u ,v ),如d (u )≥d (v ),指定u →v 为e 的方向,否则指定v →u 为其方向).下面通过在有向图的基础上添加节点包含关系树来定义嵌套有向图.定义2(嵌套有向图). G ′=〈V ,E ,φ,T 〉,节点包含关系树T =〈V T ,E T 〉,其中,V =V T ,E T ⊆V T ×V T .E T 中的每一条边e =(u ,v )都在嵌套有向图G ′中定义了一个包含关系,它表示u 包含于v ,v 称为u 的父节点,而u 称为v 的孩子节点.定义3(类图). 类图是一个嵌套有向图C =〈V ,E ,φ,T 〉,其中,V 中节点的类型有包、类和接口,E 中边的类型有继承关系、聚集关系、实现关系和关联关系,图中节点根据嵌套约束分为两类,即包含节点(包节点)和普通节点(类节点和接口节点).包含关系树T 中的边e =(u ,v )表示包节点之间或者包节点与普通节点之间的包含关系,这里,u 只能是包节点,而v 可以是包节点或者普通节点.1.2 类图布局约束定义为了描述布局约束,首先要对布图算法的中间过程加以定义.层次化布图算法主要包括层次分配、层内排序和坐标分配3个步骤.下面分别给出每个步骤的具体定义.定义4(层次分配). G =〈V ,E ,φ,T ,R 〉为分层有向图,其中,R 为V 到有限自然数集{1,…,k }的映射,即把集合V 分成k 个节点集合V 1,…,V k .定义R (v )为节点v 的层号,length (e =(u ,v )∈E )=R (v )−R (u )表示边的长度.为了保证边的长度的有效性,规定length (e )≥δ,δ为边的最短长度,本文默认为 1.这里引入的层号将在坐标分配时决定节点的纵 坐标.定义5(层内排序). G =〈V ,E ,φ,T ,R ,O 〉为排序后的分层有向图,V i (1≤i ≤k )为G 中第i 层节点的集合,其中,O 为V i 中节点v 到有限自然数集{1,…,|V i |}的映射,O (v ,i )为节点v 在第i 层内的层内序号,它将在坐标分配中决定节点的横坐标.定义6(坐标分配). G =〈V ,E ,φ,T ,L 〉为分配坐标后的类图,其中,L 为V 到自然数对集N ×N 的映射,即为每一个节点分配横、纵坐标.令v 是图中的节点,记x (v )为v 的横坐标,y (v )为v 的纵坐标,width (v )为v 的宽度,height (v )为v 的高度.类图中普通节点的宽度和高度是根据其内容预先计算的,而包节点需要在确定其子节点的位置布局后才能计算其尺寸.接下来,本文将根据以上的基本定义给出布局约束的数学描述.规则A1要保证所有的包节点必须位于其所包含的节点上方,且所有被包含的节点不能超出该包节点的左右边界和下边界.文中设定坐标原点为左上角,横轴方向为从左到右,而纵轴方向为从上到下.令p 为一个包节点,C =child *(p )⊆V T 为包含关系树T 中p 的所有子孙节点,则对于集合C 中每一个节点c 都有:()(),()(),()(),()()R p R c left p left c right p right c bottom p bottom c <<>>.同时,规则A1还要求结果图为上行图,即尽量使具有层次性的边e =(u ,v )都满足约束R (v )>R (u ).层次化布图算法大多采用逐层最小化方法将层次图转化为一组两层图(两层图,即只由相邻层节点组成).为了应用两层有向图边交叉最小化算法,图中所有边的长度必须为1,常用的方法是在跨越多层的边中引入拐点来分解它,即对于e =(u ,v ),R (v )−R (u )>1这样的边中引入R (v )−R (u )−1个拐点.规则A2中,边交叉最小化是通过层内排序来达到的.边交叉是由相邻层之间的边起点和终点的相对顺序不同所引起的[7].如图1所示,边(u ,x )与边(v ,y )相交,当且仅当 ((,1)(,1))((,2)(,2))0,,O u O v O x O y u v x y −−<≠≠,因此,规则A2要求布图算法尽可能地减少这种交叉.根据定义4,length (e )=R (v )−R (u ),则拐点的数目等价于length (e )−1,因此,规则A2中拐点数目最小化与规则A3中边的长度最小化可以统一表述为 Min ()e E length e ∈⎛⎞⎜⎟⎝⎠∑.规则A4可以通过添加边界边转化为边交叉最小化的问题,具体将在第3.2节中加以介绍.而规则A5对绘图结果所占用面积的约束可以表述为图的宽度与其高度乘积的最小化. y 12u v x Fig.1 Crossing example 图1 边交叉示例1490Journal of Software 软件学报 V ol.20, No.6, June 2009令Max(())Min(())v V v V Width x v x v ∈∈=−为图的宽度,Max(())Min(())v Vv V Height y v y v ∈∈=−为图的高度,则结果所占的最小面积为Min()Width Height ×.2 图元嵌套引入的问题在给出类图和层次化布图主要步骤的具体定义后,下面将进一步讨论图元嵌套给传统层次化类图布局带来的问题,并给出相应的解决方法.根据定义3的描述,类图是一种嵌套有向图,因此我们可以对它应用层次化有向图布图算法.本文主要在Gansner [14]有向图层次化布图算法的基础上讨论如何支持嵌套有向图的布局.图元之间的嵌套关系直接影响了节点的层次分配,包节点必须位于它所包含节点的上方.此外,由于没有包含关系的包节点之间不能相互重叠,边交叉最小化时经常用的交换节点顺序操作就可能导致包节点相互重叠.第 2.1节和第3.1节将从层次分配和节点排序两个方面分别讨论这些问题.2.1 确定嵌套图元的层次层次分配的目的是在遵循布图约束的前提下把节点划分到不同的层中去,除了边长度最小化的约束外,层次分配时还要考虑类图中的嵌套约束.通过观察任意两个节点在垂直方向的相对位置与它们的层号之间的关系,可得定理1.定理1. 如R (u )>R (v ),则u 位于v 的上方;反之,u 位于v 的下方.u 和v 的垂直位置相同当且仅当R (u )=R (v ). 根据规则A1,所有的包节点必须位于其子孙节点的上方,同时要尽可能地使具有层次特性的边的方向向上.由于在层次化布局方法中层次性边起主导作用,因此在层次分配时只需考虑具有层次特性的边即可.定义4给出了边长度的定义,并且规定length (e ∈E )≥δ=1,由此限定可得定理2.定理2. 在分层有向图中,如果有层次边e =(u ,v ),那么v 在u 的上方.证明:由边长定义可知,length (e =(u ,v ))=R (v )−R (u )且length (e )≥1,因此R (v )−R (u )≥1⇒R (v )>R (u ).根据定理1可得,v 位于u 的上方. □根据定理2,如果在包节点及其子节点之间添加一条表示包含关系的层次辅助边,就可以保证包节点位于其子节点的上方.具体方法如图2所示,把类图C =〈V ,E ,φ,T 〉包含关系树中的每一条边都作为层次辅助边添加到层次分配图中去,图2(b)为图2(a)所对应的嵌套有向图,其中虚线边表示包含关系的层次辅助边.图2所示的方法能够处理所有节点之间的嵌套关系.如果两个包节点之间没有嵌套关系,而它们的子孙节点却存在层次关系(如图3(a)、图3(b)为图3(a)对应的嵌套有向图),那么分层时为了减小整图的高度,会把它们分配到相邻层中(如图3(c)所示).当包含关系树上某一层中包节点的数目过多时,图3(c)的分配策略就会导致结果图的纵横比失调,而且包节点之间的依赖关系也不能通过层次化的方法表现出来(如图3中,p 2对p 1的依赖关系,p 2的最佳摆放位置应位于p 1及其所有子孙节点的下方).类似于前面确定包节点位置的方法,可以通过在两个相互依赖的包节点之间添加层次辅助边来修正它们的垂直位置.以图3为例,p 2和p 1的辅助边只能保证p 2位于p 1的下方(如图3(c)所示);为了能够达到图3(a)的效果,可以在p 1中添加一个底部节点p 1b (如图3(d)所示),并在p 1b 和p 1及其所有子节点之间添加层次辅助边,同时在p 1b 与p 2之间也添加包依赖辅助边.(a) (b)Fig.2 Add inclusion edge图2 添加包含辅助边p 1p 2p 1p 2A A B B王晓博 等:UML 类图层次化自动布图算法1491(a) (b) (c) (d)Fig.3 Add package dependence edges图3 添加包依赖辅助边2.2 保证节点顺序有效性为了在分层嵌套有向图中应用逐层边交叉最小化算法,所有跨越多层的边(即length (e )>1)都将通过插入辅助节点转化为长度为1的边.同时还要删除在层次分配中添加的包含辅助边和包依赖辅助边,因为它们只在层次分配中用于限定节点的垂直位置.层次有向图中的边交叉只存在于相邻层之间(如图1所示),而且整个图中只存在边与边之间的交叉;但在嵌套层次有向图中,由于节点之间存在包含关系,图中的边可能与包含节点的两个边界同时相交(如图4中边EF 与p 2的左、右边界同时交叉).边交叉最小化算法的主要思想是交换存在交叉的节点顺序,然而,嵌套关系却对这种交换添加了新的约束,即两个没有包含关系的包含节点在任意一层的相对位置都是相同的.如图4中边BC 与AD 之间的交叉,如果第1层中节点的顺序确定,那么p 1位于p 2的左边,但是它不能通过交换第2层中A 与C 的顺序来消除,因为交换A ,C 则意味着在第2层中p 1位于p 2的右边.为了尽量避免边与包含节点之间的交叉以及保证包含节点在不同层次间相对顺序的一致性,下面给出层内有效、层间有效以及边与包含节点相交的详细定义.定义7(层内有效). 令G =〈V ,E ,φ,T ,R ,O 〉为排序后的分层嵌套有向图,c 是图中的包含节点,V i 为第i 层的节点 集合,{|()}c V v v child c ∗=∈为c 的所有子孙节点,而(,){|()}c i i c V v v V V =∈∩为c 在第i 层中的所有子孙节点,则Min (,)Max (,)(,)[(,),(,)]c i c i c i O V i O V i ℜ=为V (c ,i )层内序号的范围.图G 是层内有效的当且仅当对于图G 中每一个包含节点c 都有((,())(,()))c v V v O v R v c R v ℜ∉∀∉.层内有效保证了一层中每个包含节点的排他性.比如,在图4中,如果F位于p 2的内部,则违反了层内有效的规则.定义8(层间有效). 令G =〈V ,E ,φ,T ,R ,O 〉满足层内有效,c 为包含节点Min Max (){|()()}c i R c i R c Ω=≤≤为c 的子 孙节点分配的层号范围.图G 是层间有效的,当且仅当G 中任意两个包含节点c 1和c 2,如果它们之间不存在嵌套 关系(即**1221(),()c child c c child c ∉∉),则有12(()())Max 1Min 2((,)(,))i c c i O c i O c i ΩΩ∈∩∀<(即c 1位于c 2的左边)或者12(()())Max 2Min 1((,)(,))i c c i O c i O c i ΩΩ∈∩∀<(即c 1位于c 2的右边).层间有效性保证了任意两个不存在嵌套关系的包含 节点的相对位置在任意一层都是一致的.定义9(边与包节点的交叉). 令G =〈V ,E ,φ,T ,R ,O 〉满足层间有效,边e =(u ,v )与包节点c 交叉当且仅当 Min Max Max Min ()(),()(),(,())(,()),(,())(,())R v R c R u R c O u R u O c R u O v R v O c R v ≥≤><(这里假定u 在c 的右边,v 在c 的 左边,反之,定义u 在c 的左边,v 在c 的右边).Fig.4 Crossing in nested DAG图4 嵌套有向图中的交叉p 1 p 2p 1p 2 A AB B p 1 A AB Bp 1p 1b p 2p 21p 1p 2A B C D E F21492Journal of Software 软件学报 V ol.20, No.6, June 2009不同于传统的两层最小化问题,嵌套有向图两层最小化在求解中添加了层内有效和层间有效的约束.具体表现为,当同层两个节点之间发生交换时,需要在交换时判断是否违反这两个有效性.如果两个节点的父节点相同,那么交换它们后仍然满足层内有效性.因此,可以根据这一特点通过同层节点在包含关系树中的相对位置来确定需要被排序的层.Foster [11]在绘制生化路径(biochemical pathway)时提出了聚类图(cluster graph)两层交叉最小化算法框架.本文中的分层嵌套有向图也可以看作是一个聚类图,即所有包含节点的子孙节点组成一簇.根据Foster [11]的方法,下面将给出两层嵌套有向图的定义,其中,边与包节点之间的交叉对应于聚类图中边与簇的交叉.定义10(两层嵌套有向图). 令G =〈V ,E ,φ,T ,R 〉为分层嵌套有向图,1,,,i i c GC V V EC TC φ+=〈∪〉为两层嵌套有向 图,其中,V i 与V i +1分别为第i 层与第i +1的节点集合,EC 为V i 与V i +1中节点之间的边集合,TC 为V i +1中节点及其在T 中所有祖先节点组成的包含关系树.3 嵌套有向图布图算法通过第2节中对图元嵌套关系所引入问题的深入分析,本文分别在第2.1节和第2.2节中给出了层次分配和层内排序的解决方法,下面将给出具体的算法.为了方便叙述,算法1给出了Gansner [14]布图算法的主要步骤.算法1. 有向图布图算法.(1) procedure draw _directed _graph ();(2) rank (); //为图中的节点分配层号(3) ordering (); //层内节点排序,减小边交叉数目(4) positioning ();//根据节点的层号和层内序号分配纵坐标与横坐标 (5) make _splines (); //用曲线绘制含有拐点的边(6) end.由于类图中边通常表示为直线或者折线,因此文中不考虑第(5)行绘制曲线边的这一步.接下来,本文按照有向图层次化布局的算法框架分3个步骤讨论嵌套有向图布图算法.3.1 层次分配层次分配首先根据第2.1节中的方法将图元嵌套转换为表示包含关系的层次辅助边,然后在定理2的基础上修正具有依赖关系的包图元的相对位置,算法2给出了添加包依赖关系的详细步骤.算法2. 添加包依赖关系.输入:类图C =〈V ,E ,φ,T 〉;输出:C =〈V ,E ∪E ′,φ,T 〉,其中,E ′为包节点与被依赖包的底部节点之间的依赖辅助边. (1) procedure add _package _dependency ();(2) for each ((,)&.true)e u v E e isHierarchical =∈= //遍历E 中具有层次特性的边(3) (,,)c getCommonParent u v T = //得到u 和v 在T 中最近的公共包节点(4) (,,)uc findNearestContainer u c T = //在T 中寻找距离c 最近且包含u 的节点(5) (,,)vc findNearestContainer v c T = //在T 中寻找距离c 最近且包含v 的节点(6) .(,)DG addEdge vc uc //DG =〈VD ,ED ,φd 〉为临时构造的依赖图,把辅助边添加到DG 中去(7) end for(8) acyclic _and _simplify (DG ) //消除DG 中的对称边、多重边以及循环依赖(9) {|()0,}leafnodes v out v v VD ==∈ //从DG 中出度为0的节点出发,把依赖关系插入到C 中(10) while (||0leafnodes ≠);(11) for each (s leafnodes ∈);(12) .(())C addEdgeSet inEdges s //把终点为s 的依赖边添加到G 中去(13) end for王晓博 等:UML 类图层次化自动布图算法1493 (14) /{};()VD s update leafnodes//从DG 中删除节点s 并更新集合leafnodes(15) end while(16) end. 算法2中,acyclic _and _simplify (DG )的目的是把包依赖图DG 转化为有向无环简单图.如果节点u 和v 之间存在多条依赖边(UV ={e =(u ,v )∈ED },VU ={e =(v ,u )∈ED }),那么u 和v 的依赖方向将由|UV |和|VU |决定.如果|UV |≥|VU |,则确定u →v 为其方向,否则确定v →u 为依赖方向.由于层号决定了节点的纵坐标,因此,边的长度会受到层次分配的影响.规则A2和A3要求图中边的长度总和最小,即Min ()e E length e ∈⎛⎞⎜⎟⎝⎠∑.因为图中的边具有不同的类型,而且具有层次特性的继承边、聚集边和实现边构 成了类图布局的整体层次框架,所以算法需要优先缩短这些边.本文参照Eichelberger [9]的方法为图中的边设定了不同权值,包含边为1,依赖边为2,聚集边为4,继承和实现边为8.引入边权值后,层次分配中的约束就转化为一个线性规划问题Min (()()),()1e E length e weight e length e δ∈⎛⎞×≥=⎜⎟⎝⎠∑.文中采用网络单纯形(network simplex)的方 法进行求解,实验结果表明,这种方法迭代次数少而且收敛速度较快[9,14].由于类图中可能存在自环、多重边以及环路,而层次分配要求输入的是有向无环简单图,因此首先要对输入的类图进行去环、合并多重边等预处理步骤,本文在实现中采用深度优先遍历的方法去除图中的环路[9].3.2 层内排序算法3给出了两层嵌套有向图交叉最小化的步骤.由于交换父节点相同的节点不会违反层内有效性,因此,从TC (包含关系树)的根节点出发,每次只处理当前节点的直接孩子节点之间的交叉,当TC 中所有的包含节点都被处理后,算法终止.由于TC 中每个节点都可能为父节点,在每个父节点处都会产生新的递归遍历,因此算法的时间复杂度为O (V 2).算法3通过逐层处理包含关系树将两层嵌套有向图转化为一组两层有向图,而两层有向图最小化常用的求解方法有邻位交换法[7]、Median [16]方法以及BaryCenter [17]方法等.ApplyCrossingResult (GC x )选用了Median 方法,因为它在最坏情况下的边交叉数目也不会超过最优结果的3倍[7].为了保证每一个GC x 最小化结果与GC 的映射之间不会相互影响,本文通过后续遍历包含关系树TC 来保证所有的包含节点按照嵌套层次的深度自底向上被处理.算法3. 两层嵌套有向图交叉最小化算法.输入:两层嵌套有向图1,,,i i c GC V V EC TC φ+=〈∪〉;输出:对于TC 中所有的包含节点都生成一个两层有向图,1,,,x TC i x i x x c GC V V EC φ∈+=〈∪〉,其中,x 为包含节点.(1) procedure two _level _cross _reduction ();(2) for each (&())x TC types x CLUSTER ∈=;(3) ,,,x x x x GC VC EC weight φ=〈〉;//构造两层有向图 (4) ,()x i x VC V child x =∪; //VC x 由第i 层节点和第i +1层中x 的直接孩子节点组成(5) ,{(,)()|(,)0}x i x EC u v V child x weight u v =∈×>; //*1(,)|{()|(,)}|i weight u y v V child x u v EC +=∈∩∈(6) TwoLevelCrossingReduction (GC x );//应用两层最小化算法 (7) ApplyCrossingResult (GC x ); //将GC x 最小化的结果映射到原两层有向图GC 上 (8) end for(9) end.层间有效性要求所有的包含节点在每一层的相对顺序都是相同的,而算法3并不能保证层间的有效性.本文通过在每一个生成的两层有向图中添加高权值边界边来保证层间有效性.图5(a)中的节点分为4层,第3层、第4层需要进行边交叉最小化,图5(b)是包p 1对应的两层有向图,其中,p 2,p 3的子孙节点与第3层节点之间的边都将转化为p 2,p 3与第3层节点之间的边.由于p 3在第3层、第4层中都有子孙节点,为了保证层间的有效性,需要对p 3添加边界边(如图5(c)中与p 3相连的虚线边).在确保层间有效性时,设定边界边的权值为|EC x |2,即两层1494 Journal of Software 软件学报 V ol.20, No.6, June 2009 有向图边数目的平方.因为交换之前已经确定相对位置的包含节点会导致边交叉数目超过交叉的上限(边总数的平方),所以高权值边界边能够保证层间有效性.添加边界边不但可以保证层间有效性,而且还能用于减少包含节点与边之间的交叉,区别在于这时边界边的权值设定为1/2,因为这种交叉不是必须减少的,而且当一条边与左右两条边界边都交叉时,才记为一个交叉.Fig.5 Crossing reduction in nested DAG图5 嵌套有向图中的边交叉最小化3.3 坐标分配节点的层号和层内序号确定后,布局结果的基本框架就已经确定了.一般有向图可以采用在垂直方向或者水平方向按序号递增的方式分别分配纵坐标和横坐标,但是根据第 1.2节中的分析,所有包含节点的子孙节点 都不能超过它们的边界,同时还要缩短边的长度((,),()e u v DISTANCE e ==).由于 纵坐标由层号唯一确定,而且分层时已经根据规则A2和A3进行了优化,因此,分配坐标只需要优化每一条边两个端点的横坐标间距即可.与层次分配类似,规则A 3中边长度最短的要求在分配横坐标时定义为(,)Min ()|()()|,|()()|1e u v E weight e x v x u x v x u =∈⎛⎞×−−≥⎜⎟⎜⎟⎝⎠∑.A5要求在限定同层节点之间的最小水平间距(NODE_SEP) 下尽可能缩小所有节点之间的水平距离,本文在Gansner [14]的基础上同时考虑A1,A3和A5,给出了嵌套有向图横坐标优化分配算法.算法4. 嵌套有向图横坐标优化分配算法.输入:层内排序后的嵌套有向图G =〈V ,E ,φ,T ,R ,O 〉;输出:分配横坐标后的嵌套有向图GL =〈LV ,LE ,φ,TL ,L 〉.(1) procedure x _coordinate _assignment ();(2) 构造坐标分配图GL ,LV =V ,TL =T ;(3) 为GL 中所有的包添加左、右边界节点,并添加边界水平约束;(4) for each (,[0,Max ])i V i Rank ∈; //遍历所有的层(5) for (0;||1;)i j j V j =<−++;(6) GL .addEdge ([],[1]i i V j V j +); //添加水平限定关系(7) end for(8) end for(9) for each (e =(u ,v )∈E ); //遍历G 中所有的边(10) (,,)c getCommonParent u v TL =; //得到u 和v 在TL 中最近的公共包节点p 1p 2p 3d 1p 2 p 3p 2p 3111222323334344445(a)55(b) f e b a d c c c d (c)。

uml表达逻辑模型
UML（统一建模语言）是一种可视化的面向对象建模语言，提供了丰富的图形化表示法，使得开发人员能够更加直观地理解和描述软件系统的结构和行为。

在UML中，逻辑模型主要通过以下几种方式来表达：
1. 类图（Class Diagram）：类图是UML中最基本的图之一，用于描述系统中的类、接口以及它们之间的关系。

类图可以展示类的静态结构，包括属性、方法和关系等，从而帮助开发人员理解系统的逻辑结构。

2. 对象图（Object Diagram）：对象图是类图的一个实例，它展示了在某一特定时间点上系统中对象的快照。

对象图可以帮助开发人员理解系统在运行时的状态和行为。

3. 包图（Package Diagram）：包图用于描述系统中的包以及包之间的关系。

包是一种组织类、接口和其他元素的方式，可以帮助开发人员将系统划分为更小、更易于管理的部分。

4. 组件图（Component Diagram）：组件图用于描述系统中的组件以及它们之间的关系。

组件是系统中的可替换部分，可以执行特定的功能。

组件图可以帮助开发人员理解系统的物理结构和部署方式。

除了以上几种图之外，UML还提供了其他类型的图，如
用例图、顺序图、活动图等，这些图也可以用于描述系统的逻辑模型，但侧重点可能有所不同。

例如，用例图主要用于描述系统的功能需求，而顺序图则用于描述系统中对象之间的交互行为。

总的来说，UML提供了多种图形化表示法来描述系统的逻辑模型，开发人员可以根据需要选择合适的图来描述系统的不同方面。

Software Development MethodologyData Modeling and Review Lecture 10Lecturer：罗铁坚 Email： tjluo@ Phone： 88256308 ----------------------------------------------------------------Class Time： Mon / Wed 10:00am – 11:40am Office Hour：Friday Morning 10:00 – 12:00 Office Place：玉泉路教学园区科研楼东5层511SDM 2012Conceptual Data Modeling 1. Requirement Determination 2. Structure System Requirement 3. Conceptual Data Modeling 4. Object-Rational Modeling 5. Analysis ClassesSDM 20122Objectives• After studying this part you should be able to:– Determine how to develop conceptual data models from use cases. – Understand UML notations for conceptual data modeling. – Explain relationship characteristics such as degree and multiplicity.SDM 20123Objectives (Continued)• After studying this part you should be able to:– Describe data relationships such as association, aggregation, and generalization. – Describe different kinds of attributes such as identifier, multivalued, and derived.SDM 20124There are three prominent parts of a system's model • Functional model– Showcases the functionality of the system from the user's point of view. – Includes use case diagrams.• Object model– Showcases the structure and substructure of the system using objects, attributes, operations, and relationships. – Includes class diagrams.• Dynamic model– Showcases the internal behavior of the system. – Includes sequence diagrams, activity diagrams and state machine diagrams.SDM 20125UML 2.0 DiagramsSDM 20126SDM 20127SDM 20128Concepts • For structure– Actor, attribute, class, component, interface, object, package.• For behavior– Activity, event, message, method, operation, state, use case.• For relationships– Aggregation, association, composition, depends, generalization (or inheritance).• Other concepts– Stereotype. It qualifies the symbol it is attached to. – Multiplicity notation which corresponds to Database modeling cardinality, e.g., 1, 0..1, 1..* 9 SDM 2012 – RoleWhat Is a Conceptual Data Model?• A detailed model that shows the overall structure of organizational data; it is independent of any database management system or other implementation considerations. • Represented by UML class diagramsSDM 201210Use cases are key inputs to conceptual data modeling.Conceptual Data Model Elements •Classes•Attributes•Identifiers•Associations, aggregations, compositions •Generalizations•Time dimensions•Integrity rules•Security controlsWhat Is an Object?•An entity that encapsulates data and behavior•Examples: product, employee, order, line item•Class–a set of objects that share the same attributes, operations, relationships, and semantics (abstract)•Instance–a single object (concrete)ClassInstancesUML Class symbol has three parts:1)Name2)List of attributes3)List of operationsTypes of Attributes •Simple attributes –contain single data item •Identifiers –connect unique key value •Multivalued attributes –contain multiple values simultaneously•Composite attributes –group of related attributesStereotypes in Class Diagrams •Stereotype –a construct that extends the UML vocabulary•<<PK>>for Identifier stereotypeprimary key•Multivalued stereotype<<multivalued>>Primary key is a unique identifier; no two Student instances will have the same studentId value.Multivalued attribute can contain multiple values; a student may have several phone numbersWhat Is a Relationship?•A semantic connection between objects of one or more classes•In UML, represented as a line connecting two or more class boxes (or connecting one class to itself)They are treated as separate classes in conceptual data models.This is a binary relationship, which indicates that an employee works in a department.Roles identify the purpose of each class in the relationship.What Is Relationship Degree?•The number of classes that participate in a relationship•Main degrees:–Unary –a relationship between objects of thesame class–Binary –a relationship between objects of twodifferent classes–Ternary –a relationship between objects of threedifferent classesWhat Is Relationship Multiplicity?•The range of the number of objects in Class A that can or must be associated with each object of Class B.•A multiplicity is made up of:–A minimum cardinality –the minimum number ofClass A objects possible–A maximum cardinality –the maximum number ofClass A objects possibleRelationship Multiply •Relationships can be:–One –to –one–One –to –many–Many –to –manyMultiplicity notation is: min..maxRoles make it clearer to see which should be on the one side and which should be on the many side of the relationship.What Is an Associative Class?•A special purpose class that represents an association (relationship) between classes and contains attributes and/or relationships in its own right•Represented as a class connected to an association with a dotted lineA Certificate represents a relationship between an employee and a course, and has an attribute pertaining to that relationshipSometimes associative classes have their own relationships with other classes.Types of Associations Association–no object is subordinate to any other.Aggregation–one class represents the whole, and the other represents the part, but it is a loose coupling.Composition–an aggregation with a tight coupling. The whole and the part cannot exist without each other.What Is Generalization?•A superclass –subclass relationship in which one class forms a broader category in which the other class is a sub-category•Inheritance–A subclass will inherit all the attributes and operations of its superclass; an instance of the subclass contains all the same information (plus more) as an instance of the superclass.Multiple inheritance is complicated and not supported by all object-oriented programming languages.Reviewe Case2.Data models(Your Project)3.Class diagramyer architecture (Your Project)5.Project EvaluationLayered Architecture ExampleArchitecturally Significant Use cases Reserve Room Check-In Customer Check-Out Customer Etc.Etc.More ApplicationSpecificApplication LayerCustomer ApplicationCounter ApplicationWaiting List ServiceMore ApplicationDomain LayerInfrastructureLayerReservation ManagementRoom ManagementAuthorizationPresentation Distribution PersistenceUse Cases Provides Means To Evaluate ArchitectureApplication LayerCustomer ApplicationCounter ApplicationWaiting List ServiceReserve RoomCheck-In Customer Check-Out CustomerMore ApplicationSpecificDomain LayerReservation ManagementRoom ManagementAuthorizationPresentation Distribution PersistenceMore ApplicationInfrastructureLayerConsider a simple part of a POS system as shown in the following class diagramCreate a Shopping Cart---Item Class public class Item : IFormattable{// ...public override bool Equals(object obj){if (obj == null) return false;if (Object.ReferenceEquals(this,obj))return true;if (this.GetType() != obj.GetType())return false;Item objItem = (Item)obj;if (_productID == objItem._productID)return true;return false;}// ...。

Finite Satisfiability of UML class diagrams byConstraint ProgrammingMarco Cadoli1,Diego Calvanese2,Giuseppe De Giacomo1,Toni Mancini11Dipartimento di Informatica e SistemisticaUniversit`a di Roma“La Sapienza”Via Salaria113,I-00198Roma,Italycadoli|degiacomo|tmancini@dis.uniroma1.itwww.dis.uniroma1.it/~cadoli|~degiacomo|~tmancini2Faculty of Computer ScienceFree University of Bolzano/BozenPiazza Domenicani3,I-39100Bolzano,Italycalvanese@inf.unibz.itAbstract.Finite model reasoning in UML class diagrams,e.g.,check-ing whether a class is forced to have either zero or infinitely many objects,is of crucial importance for assessing quality of the analysis phase in soft-ware development.Despite the fact thatfinite model reasoning is oftenconsidered more important than unrestricted reasoning,no implementa-tion of the former task has been attempted so far.The main result of thispaper is that it is possible to use off-the-shelf tools for constraint model-ing and programming for obtaining afinite model reasoner.In particular,exploiting appropriate reasoning techniques,we propose an encoding asa CSP of UML class diagram satisfiability.Moreover,we show also howCP can be used to actually return afinite model of a class diagram.Adescription of our system,which accepts as input class diagrams in theMOF syntax,and the results of the experimentation performed on theCIM knowledge base are given.1IntroductionThe Unified Modelling Language(UML,[13],)is probably the most used modelling language in the context of software development,and has been proven to be very effective for the analysis and design phases of the software life cycle.UML offers a number of diagrams for representing various aspects of the requirements for a software application.Probably the most important diagram is the class diagram,which represents all main structural aspects of an application.A typical class diagram shows:–classes,i.e.,homogeneous collections of objects,i.e.,instances;–associations,i.e.,relations between classes;–ISA hierarchies between classes,i.e.,relations establishing that each object of a class is also an object of another class;1..1Curriculum20..∗enrolled Student Fig.1.A UML class diagram.1..1Curriculum1..11..120..∗enrolled Studentlikes Fig.2.A UML class diagram with finitely inconsistent classes.–multiplicity constraints on associations,i.e.,restrictions on the number of links between objects related by an association.Actually,a UML class diagram represents also other aspects,e.g.,the attributes and the operations of a class,the attributes of an association,and the special-ization of an association.Such aspects,for the sake of simplicity,will not be considered in this paper.An example of a class diagram is shown in Figure 1,which refers to an application concerning management of administrative data of a university,and exhibits two classes (Student and Curriculum )and an association (enrolled )between them.The multiplicity constraints state that:–Each student must be enrolled in at least one and at most one curriculum;–Each curriculum must have at least twenty enrolled students,and there is no maximum on the number of enrolled students per curriculum.It is interesting to note that a class diagram induces restrictions on the number of objects.As an example,referring to the situation of Figure 1,it is possible to have zero,twenty,or more students,but it is impossible to have any number of students between one and nineteen.The reason is that if we had,e.g.,five students,then we would need at least one curriculum,which in turn requires at least twenty students.In some cases the number of objects of a class is forced to be zero.As an example,if we add to the class diagram of Figure 1a further likes association,with the constraints that each student likes exactly one curriculum,and that each curriculum is liked by exactly one student (cf.Figure 2),then it is impos-sible to have any finite non-zero number of students and curricula.In fact,the new association and its multiplicity constraints force the students to be the ex-actly as many as the curricula,which is impossible.Observe that,with a logical formalization the UML class diagram,one can actually perform such form of reasoning making use of automated reasoning tools 1.1..1Curriculum T eachingAssist 1..∗0..620..∗1..10..3Studentassigned enrolled worksFig.3.Another finitely inconsistent class diagram.Referring to Figure 2,note that the multiplicity constraints do not rule out the possibility of having infinitely many students and curricula.When a class is forced to have either zero or infinitely many instances,it is said to be finitely inconsistent or finitely unsatisfiable .For the sake of completeness,we mention that in some situations involving ISA hierarchies (not shown for brevity),classes may be forced to have zero objects,and are thus said to be inconsistent or unsatisfiable in the unrestricted sense.Unsatisfiability,either finite or unrestricted,of a class is a symptom of a bug in the analysis phase,since such a class is clearly superfluous.In particular,finite unsatisfiability is especially relevant in the context of applications,e.g.,databases,in which the number of instances is intrinsically finite.Obviously the situation described by Figure 2(in particular,the fact that a curriculum is liked by exactly one student)is not realistic.Anyway,finite incon-sistency may arise in more complex situations,cf.e.g.Figure 3.Here,for budget reasons,each curriculum has at most six teaching assistants,and,for enforcing effectiveness of service,each TA is assigned to at most three students.The rea-son why there must be zero (or infinitely many)students is that eighteen,i.e.,three times six,is less than twenty.Global reasoning on the whole class diagram is needed to show finite inconsistency.For large,industrial class diagrams,such reasoning is clearly not doable by hand.If,in our application we have that the UML class diagram will always be instantiated by a finite number of objects (as often is the case),then,for assess-ing quality of the analysis phase in software development,we must take fully into account such an assumption.This is reflected in focusing on finite model reasoning.In this paper we address the implementation of finite model reasoning on UML class diagrams,a task that has not been attempted so far.This is done by exploiting an encoding of UML class diagrams in terms of Description Logics (DLs)[6,4].DLs [1]are logics for representing and reasoning on domains of interest in terms of classes and relationships among classes.They are extensively used to formalize conceptual models and object-oriented models in databases and soft-ware engineering,and lay the foundations for ontology languages used in the Semantic Web.From a technical point of view,DLs can be seen as multi-modallogics[16]specifically tailored to capture the typical constructs of class-based formalisms.Alternatively,they can be seen as well-behaved fragments offirst-order logic.Indeed,reasoning in such logics has been studied extensively,both from a theoretical point of view,establishing EXPTIME-completeness of various DL variants[9],and from a practical point of view,developing practical reason-ing systems.State-of-the-art DL reasoning systems,such as F act2and Racer3, are highly optimized and result among the best reasoners for modal logics.The correspondence between UML class diagrams and DLs allows one to use the current state-of-the-art DL reasoning systems to reason on UML class diagrams.However,the kind of reasoning that such systems support is unre-stricted(as infirst-order logic),and notfinite model reasoning.That is,the fact that models(i.e.,instantiations of the UML class diagram)must befinite is not taken into account.Interestingly,in DLs,finite model reasoning has been studied from a the-oretical perspective,and its computational complexity has been characterized for various cases[14,10,7,15].However,no implementations of such techniques have been attempted till now.In this paper we reconsider such work,and on the basis of it we present,to the best of our knowledge,thefirst implementation of finite model reasoning in UML class diagrams.The main result of this paper is that it is possible to use off-the-shelf tools for constraint modelling and programming for obtaining afinite model reasoner.In particular,exploiting thefinite model reasoning technique for DLs presented in[10,7],we propose an encoding of UML class diagram satisfiability as a Constraint Satisfaction Problem(CSP).Moreover,we show also how constraint programming can be used to actually return afinite model of the UML class diagram.We built a system that accepts as input a class diagram written in the MOF syntax,and translates it into afile suitable for ILOG’s oplstudio,which checks satisfiability and returns afinite model,if there is one.The system allowed us to test the technique on the industrial knowledge base CIM,obtaining encouraging results.The rest of the paper is organized as follows:in Section2we briefly de-scribe the main constructs of UML class diagrams in terms offirst-order logic. In Sections3and4we then show how to encode the UML class diagramfinite satisfiability problem as a CSP,and,in Section5we show how tofind,if possi-ble,afinite model of a class diagram,with non-empty classes and associations. Section6is devoted to some observations on complexity issues,while our system is described in Section7.Finally,Section8concludes the paper.2Formalization of UML Class DiagramsUML class diagrams allow for modelling,in a declarative way,the static struc-ture of an application domain,in terms of concepts and relations between them.m1..n1 C1A C2m2..n2Fig.4.Binary association in UML with multiplicity constraints.C1A ···C2C nFig.5.n-ary association in UML.We briefly describe UML class diagrams,and specify the semantics of the main constructs in terms offirst-order logic(FOL).A class in a UML class diagram denotes a set of objects with common s of classes are unique in a UML class diagram.Formally,a class C corresponds to a FOL unary predicate C.Classes may have attributes and operations,but for simplicity we do not describe them here,since they have only minor impact on the reasoning process.An association in UML is a relation between the instances of two or more s of associations are unique in a UML class diagram.A binary as-sociation A between two classes C1and C2is graphically rendered as in Figure4. The multiplicity m1..n1on the binary association specifies that each instance of the class C1can participate at least m1times and at most n1times to A,simi-larly for C2.When the multiplicity is omitted,it is intended to be0..∗.Observe that an association can also relate several classes C1,C2,...,C n,as depicted in Figure54.An association A between the instances of classes C1,...,C n,can be formal-ized as an n-ary predicate A that satisfies the following FOL assertion:∀x1,...,x n.A(x1,...,x n)→C1(x1)∧...∧C n(x n)For binary associations(see Figure4),multiplicities are formalized by the FOL assertions:∀x.C1(x)→(m1≤♯{y|A(x,y)}≤n1)∀y.C2(y)→(m2≤♯{x|A(x,y)}≤n2)where we have abbreviated FOL formulas expressing cardinality restrictions.Aggregations,which are a particular kind of binary associations are modeled similarly.Fig.6.A class hierarchy in UML.In UML one can use a generalization between a parent class and a child class to specify that each instance of the child class is also an instance of the parent class.Hence,the instances of the child class inherit the properties of the parent class,but typically they satisfy additional properties that in general do not hold for the parent class.Several generalizations can be grouped together to form a class hierarchy(also called ISA hierarchy),as shown in Figure6.Disjointness and completeness constraints can also be enforced on a class hierarchy(graph-ically,by adding suitable labels).A class hierarchy is said to be disjoint if no instance can belong to more than one derived class,and complete if any instance of the base class belongs also to some of the derived classes.A UML class C generalizing a class C1can be formally captured by means of the FOL assertion:∀x.C1(x)→C(x)A class hierarchy as the one in Figure6is formally captured by means of the FOL assertions:∀x.C i(x)→C(x),for i=1,...,nDisjointness among C1,...,C n is expressed by the FOL assertions∀x.C i(x)→ n j=i+1¬C j(x),for i=1,...,n−1 The completeness constraint expressing that each instance of C is an instance of at least one of C1,...,C n is expressed by:∀x.C(x)→ n i=1C i(x)In UML class diagrams,it is typically assumed that all classes not in the same hierarchy are a priori disjoint.Similarly,it is typically assumed that objects in a hierarchy must belong to a single most specific class.Hence,two classes in a hierarchy may have common instances only if they have a common subclass.3Finite Model Reasoning on UML Class DiagramsAs mentioned before,a technique forfinite model reasoning in UML class dia-grams can be derived from techniques developed in the context of Description Logics(DLs)[1].Such techniques are based on translating a DL knowledge baseinto a set of linear inequalities[10,7].Thefirst-order formalization of UML class diagrams shown in the previous section can be rephrased in terms of DLs.Hence, thefinite model reasoning techniques for DLs can be used also for UML class diagrams.Intuitively,consider a simple UML class diagram D with only binary as-sociations,and in which we do not make use of generalization and hierarchies. Further,for each association,between two classes multiplicities are specified. Figure4shows a fragment of such a diagram,in which we have two classes C1 and C2and an association A between them.The multiplicities in thefigure ex-press that each instance of C1is associated with at least m1and at most n1 instances of C2through the association A,similarly for C2.It is easy to see that such a class diagram D is always satisfiable(assuming m i≤n i)if we admit infinite models.Hence,onlyfinite model reasoning is of interest.We observe that,if D isfinitely satisfiable,then it admits afinite model in which all classes are pairwise disjoint.Exploiting this property,we can encodefinite satisfiability of D in a constraint system as follows.We introduce one variable for each class and one for each association,representing the number of instances of the class (resp.,association)in a possible model of D.Then,for each association A we introduce the constraints:m1∗c1≤a≤n1∗c1m2∗c2≤a≤n2∗c2c1∗c2≥awhere c1,c2,and a are the variables corresponding to C1,C2,and A,respectively.It is possible to show that,from a solution of such a constraint system we can construct afinite model of D in which the cardinality of the extension of each class and association is equal to the value assigned to the corresponding variable5[14].The above approach can be extended to deal also with generalizations,dis-jointness,and covering between classes.Intuitively,one needs to introduce one variable for each combination of classes;similarly,for associations one needs to distinguish how,among the possible combinations of classes,the association is typed in itsfirst and second component.This leads,in general,to the introduc-tion of an exponential number of variables and constraints[10,7].We illustrate this in the next section.4Finite Model Reasoning via CSPWe address the problem offinite satisfiability of UML class diagrams,and show how it is possible to encode two problems as constraint satisfaction problems (CSPs),namely:1.deciding whether all classes in the diagram are simultaneouslyfinitely satis-fiable,andFig.7.The“restaurant”UML class diagram.2.finding–if possible–afinite model with non-empty classes and associations. We use the“restaurant”class diagram,shown in Figure7,as our running ex-ample.First we address the problem of decidingfinite satisfiability.As mentioned before,we use the technique proposed in[7],which is based on the idea of translating the multiplicity constraints of the UML class diagram into a set of inequalities among integer variables.The variables and the inequalities of the CSP are modularly described con-sidering in turn each association of the class diagram.Let a be an association between classes c1and c2such that the following multiplicity constraints are stated:–There are at least min c1links of type a(instances of the association a)for each object of the class c1;–There are at least min c2links of type a for each object of the class c2.Referring to Figure7,if a stands for servedc1is1,max c2is1,and maxinassociations of Figure7.The CSP is defined as follows:–There are three non-negative variables c1,c2,and a,which stand for the number of objects of the classes and the number of links,respectively(in practice,upper bounds for these variables can be set to a huge constant,e.g., maxint);–There are the following constraints(we use the syntax of the constraint programming language opl[18]):1.min_c1*c1<=a;2.max_c1*c1>=a;3.min_c2*c2<=a;4.max_c2*c2>=a;5.a<=c1*c2;6.a>=1;7.c1>=1;8.c2>=1;Constraints1–4account for the multiplicity of the association;they can be omit-ted if either min=∞(symbol‘*’in the class diagram).Constraint5 sets an upper bound for the number of links of type a with respect to the number of objects.Constraints6–8define the satisfiability problem we are interested in: we want at least one object for each class and at least one link for each associa-tion.The latter constraints can be omitted by declaring the variables as strictly positive.Finally,to avoid the system returning an ineffectively large solution,an objective function that,e.g.,minimizes the overall number of objects and links, may be added.However,the addition of such or other objective functions is out of the scope of this paper.When either c1or c2are involved in ISA hierarchies,the constraints are more complicated,because the meaning of the multiplicity constraints changes. As an example,the multiplicity1..*of the order association in Figure7states that a client order s at least one banquet,but the client can be a person,afirm, both,or neither(assuming the generalization is neither disjoint nor complete).In general,for an ISA hierarchy involving n classes,O(2n)non-negative variables corresponding to all possible combinations must be considered.For the same reason,we must consider four distinct specializations of the order association, i.e.,one for each possible combination.Summing up,we have the following non-negative variables:–person,orderf,for clients who arefirms and not persons;–person pf,for clients who are bothfirms and persons;–client,order/*1*/client<=order_c;/*2*/firm<=order_f;/*3*/person<=order_p;/*4*/person_firm<=order_pf;/*5*/banquet=order_c+order_f+order_p+order_pf;/*6*/order_c<=client*banquet;/*7*/order_f<=firm*banquet;/*8*/order_p<=person*banquet;/*9*/order_pf<=person_firm*banquet;/*10*/client+firm+person+person_firm>=1;/*11*/order_c+order_f+order_p+order_pf>=1;Constraints1–4account for the‘1’in the1..*multiplicity;Constraint5trans-lates the1..1multiplicity;Constraints6–9set an upper bound for the number of links of type order with respect to the number of objects;Constraints10–11 define the satisfiability problem(banquet is already strictly positive).We refer the reader to[7,8]for formal details of the translation,and in partic-ular for the proof of its correctness.As for the implementation,the“restaurant”example has been encoded in opl as a CSP with24variables and40constraints. The solution has been found by the underlying constraint programming solver, i.e.,ILOG’s Solver[12,11],in less than0.01seconds.5Constructing a Finite ModelWe now turn to the second problem,i.e.,finding–if possible–afinite model with non-empty classes and associations.The basic idea is to encode in the constraint modelling language of opl the semantics of the UML class diagram(see Section2 and[4,3]).In particular we use arrays of boolean variables representing the extensions of predicates,where the size of the arrays is determined by the output of thefirst problem.Since in thefirst problem we have enforced the multiplicity constraints,and obtained an admissible number of objects for each class,we know that afinite model of the class diagram exists,and we also know the size of the universe of such afinite model,which is the sum of the objects of the classes.Referring to our“restaurant”example,we have the following declarations describing the size of our universe and two sorts:int size=client+person+firm+person_firm+restaurant+menu+ characteristic_restaurant+dish+specialty+banquet+celebration; range Bool0..1;range Universe 1..size;where client,person etc.are the number of objects for each class,obtained as the output of thefirst problem.The arrays corresponding,e.g.,to the client and banquet classes,and to the ordervar Bool Banquet[Universe];var Bool Order_C[Universe,Universe];Now,we have to enforce some constraints to reflect the semantics of the UML class diagram[4,3],namely that:1.Each object belongs to exactly one most specific class;2.The number of objects(resp.,links)in each class(resp.,association)is co-herent with the solution of thefirst problem;3.The associations are typed,e.g.,that a link of type orderlower bound,due to the program complexity of modelling languages such as opl.Indeed,in[5]it is shown that the program complexity of boolean linear programming is NEXPTIME-hard.7ImplementationIn this section we describe a system realized in order to automatically produce, given a UML class diagram as input,a constraint-based specification that de-cides itsfinite satisfiability(full handling of ISA hierarchies among classes and associations is currently under development).Two important choices have to be made in order to design such a system: the input language for UML class diagrams,and the output constraint language. As for the former,we decided to use a textual representation of UML class diagrams.To this end,we relied on the standard language“Managed Object Format”(MOF)6.To give the intuition of the language,a MOF description of the class diagram depicted in Figure7is shown in Figure8.For what concerns the output language,instead,in order to use state-of-the-art solvers,we opted for the constraint programming language opl.However,in order to have a strong decoupling between the two front-ends of the system,we realized it in two,strongly decoupled modules:thefirst one acts as a server,receiving a MOFfile as input and returning a high-level,object-oriented complete internal representation of the described class diagram.A client module, then,traverses the internal model in order to produce the opl specification.In this way,we are able to change the language for the input(resp.,output)by modifying only the MOF parser(resp.,the opl encoder)module of the system. Moreover,by decoupling the parsing module from the encoder into opl,we are able to realize new tools to make additional forms of reasoning at a very low cost.As for the handling of ISA hierarchies,as described in Section4,an expo-nential blow-up of the number of variables(one for each combination of classes involved in the hierarchy)cannot be avoided in general.However,in case the hierarchy is disjoint or complete,it is possible to reduce the number of generated variables.It can be observed that,if an ISA is complete,the variable relative to its base class can be avoided;even more interestingly,if an ISA is disjoint,all variables that model instances that belong to any combination of two or more derived classes can be ignored,thus reducing the overall number of variables to the number of classes in the hierarchy.The MOF language provides the“abstract”qualifier that,when applied to a class C imposes that no instance may exist that belongs to class C and does not belong to any of its subclasses.This is implicitly used to assert completeness of the ISA hierarchy.Also,in MOF,the most specific class assumption is implicitly enforced.Hence,in all experiments reflect such an assumption.In order to test whether using off-the-shelf tools for constraint programming is effective to decidefinite satisfiability of real-world UML class diagrams,weused our system to produce opl specifications for several class diagrams of the “Common Information Model”(CIM)7,a standard model used for describing overall management information in a network/enterprise environment.We don’t describe the model into details,since this is out of the scope of the paper.We just observe that the class diagrams we used were composed of about1000classes and associations,and so can be considered good benchmarks to test whether current constraint programming solvers can be effectively used to make the kind of reasoning shown so far.Constraint specifications obtained by giving large class diagrams in the CIM collection,were solved very efficiently by opl.As an example,when the largest diagram,consisting of980classes and associations,has been given as input to our system,we obtained an opl specification consisting of a comparable number of variables and862constraints.Nonetheless,opl solved it in less than0.03seconds of CPU time,by invoking ILOG Solver.This high efficiency is achieved also because generated constraints are often easily satisfiable(cardinality constraints for associations often have“0”or“1”as lower bounds,or“∗”as upper bounds). This is encouraging evidence that current CP technology can be effectively used in order to makefinite model reasoning on real-world class diagrams.8ConclusionsFinite model reasoning in UML class diagrams,e.g.,checking whether a class is forced to have either zero or infinitely many objects,is of crucial importance for assessing quality of the analysis phase in software development.Despite the fact thatfinite model reasoning is often considered more important than unrestricted reasoning,no implementation of this task has been attempted so far.In this paper we showed that it is possible to use off-the-shelf tools for con-straint modelling and programming for obtaining afinite model reasoner.In particular,exploitingfinite model reasoning techniques published previously,we proposed an encoding as a CSP of UML class diagram satisfiability.Moreover, we showed also how constraint programming can be used to actually return a finite model of a class diagram.We implemented a system which parses class diagrams written in the MOF language and uses ILOG’s Solver for solving thefinite satisfiability problem. The results of the experimentation performed on the CIM class diagram,a large industrial knowledge base,are encouraging,since determining satisfiability is done in just few hundredths of second for a class diagram with980classes and associations.References1. F.Baader,D.Calvanese,D.McGuinness,D.Nardi,and P.F.Patel-Schneider,ed-itors.The Description Logic Handbook:Theory,Implementation and Applications.Cambridge University Press,2003.2. C.Batini,S.Ceri,and S.B.Navathe.Conceptual Database Design,an Entity-Relationship Approach.Benjamin and Cummings Publ.Co.,Menlo Park,Califor-nia,1992.3. D.Berardi,A.Cal`ı,D.Calvanese,and G.De Giacomo.Reasoning on UML classdiagrams.Technical Report11-03,Dipartimento di Informatica e Sistemistica, Universit`a di Roma“La Sapienza”,2003.4. D.Berardi,D.Calvanese,and G.De Giacomo.Reasoning on UML class dia-grams is EXPTIME-hard.In Proceedings of the2003Description Logic Work-shop(DL2003),pages28–37.CEUR Electronic Workshop Proceedings,http: ///Vol-81/,2003.5.M.Cadoli.The expressive power of binary linear programming.In Proc.of the7th Int.Conf.on Principles and Practice of Constraint Programming(CP2001), volume2239of Lecture Notes in Computer Science,2001.6. A.Cal`ı,D.Calvanese,G.De Giacomo,and M.Lenzerini.A formal framework forreasoning on UML class diagrams.In Proceedings of the Thirteenth International Symposium on Methodologies for Intelligent Systems(ISMIS2002),volume2366 of Lecture Notes in Computer Science,pages503–513.Springer,2002.7. D.Calvanese.Finite model reasoning in description logics.In Proceedings of theFifth International Conference on the Principles of Knowledge Representation and Reasoning(KR’96),pages292–303,1996.8. D.Calvanese.Unrestricted and Finite Model Reasoning in Class-Based Represen-tation Formalisms.PhD thesis,Dipartimento di Informatica e Sistemistica,Uni-versit`a di Roma“La Sapienza”,1996.Available at http://www.dis.uniroma1.it/pub/calvanes/thesis.ps.gz.9. D.Calvanese,G.De Giacomo,M.Lenzerini,and D.Nardi.Reasoning in expres-sive description logics.In A.Robinson and A.Voronkov,editors,Handbook of Automated Reasoning,chapter23,pages1581–1634.Elsevier Science Publishers (North-Holland),Amsterdam,2001.10. D.Calvanese and M.Lenzerini.On the interaction between ISA and cardinal-ity constraints.In Proceedings of the Tenth IEEE International Conference on Data Engineering(ICDE’94),pages204–213,Houston(Texas,USA),1994.IEEE Computer Society Press.11.ILOG Solver system version5.1user’s manual,2001.12.ILOG OPL Studio system version3.6.1user’s manual,2002.13.I.Jacobson,G.Booch,and J.Rumbaugh.The Unified Modeling Language UserGuide.Addison Wesley Publ.Co.,Reading,Massachussetts,1998.14.M.Lenzerini and P.Nobili.On the satisfiability of dependency constraints inentity-relationship rmation Systems,15(4):453–461,1990.15. C.Lutz,U.Sattler,and L.Tendera.The complexity offinite model reasoning indescription logics.In Proceedings of the Nineteenth International Conference on Automated Deduction(CADE2003),pages60–74,2003.16.K.Schild.A correspondence theory for terminological logics:Preliminary report.InProceedings of the Twelfth International Joint Conference on Artificial Intelligence (IJCAI’91),pages466–471,1991.17. B.Thalheim.Fundamentals of cardinality constraints.In G.Pernoul and A.M.Tjoa,editors,Proceedings of the Eleventh International Conference on the Entity-Relationship Approach(ER’92),pages7–23.Springer,1992.18.P.Van Hentenryck.The OPL Optimization Programming Language.The MITPress,1999.。

The Elements of UML 2.0 style作者 : Scott W.Ambler（1）General Diagramming Guidelines1. Avoid Crossing Lines2. Depict Crossing Lines as a Jump3. Avoid Diagonal or Curved Lines4. Apply Consistently Sized Symbols5. Attach Lines to the Middle of Bubbles6. Align Labels Horizontally7. Arrange Symbols Symmetrically8. Don’t Indicate “Exploding” Bubbles9. Minimize the Number of Bubble Types10. Include White Space in Diagrams11. Organize Diagrams Left to Right, Top to Bottom12. Avoid Many Close Lines13. Provide a Notation Legend14. Show Only What You Have to Show15. Prefer Well-Known Notation over Esoteric Notation16. Reorganize Large Diagrams into Several17. Prefer Single-Page Diagrams18. Focus on Content First, Appearance Second19. Apply Consistent, Readable Fonts20. Set and Follow Effective Naming Conventions21. Apply Common Domain Terminology in Names22. Apply Language Naming Conventions on Design Diagrams23. Name Common Elements Consistently Across Diagrams24. Indicate Unknowns with a Question Mark25. Consider Applying Color to Your Diagrams26. Apply Color or Different Fonts Sparingly（2）Guidelines for Common UML Modeling Elements 27. Describe Diagrams with Notes28. Set a Convention for Placement of Diagram Legends29. Left-Justify Text in Notes30. Prefer Notes over OCL or ASL to Indicate Constraints31. Follow Common Coding Conventions for OCL and ASL32. Name Stereotypes in <<user interface>>and <<UI>> Format33. List Stereotypes Last34. Don’t Indicate Assumed Stereotypes35. Prefer Naming Conventions over Stereotypes36. Tagged Values Follow Stereotypes37. Align Classifier Stereotypes with Names38. Introduce New Stereotypes Sparingly39. Apply Stereotypes Consistently40. Apply Visual Stereotypes Sparingly41. Deemphasize Frame Borders42. Avoid Diagram Frames43. Apply Standard Labels to Descriptors44. Use Interaction Occurrences over Part Decompositions45. Fully Specify Operation Names in References46. Depict One Interface per Port47. Depict One Port per Realizing Class48. Provided Interfaces on the Left49. Required Interfaces on the Right50. Apply Realizes Relationships for Ports51. Reflect Implementation Language Constraints in Interface Definitions52. Name Interfaces According to Language-Naming Conventions53. Prefer “Lollipop” Notation to Indicate Realization of an Interface54. Define Interfaces Separately from Your Classifiers55. Do Not Depict the Operations and Attributes of Interfaces in Your Classes56. One Label per Interface Connection57. Place Interface Labels above the Interface（3）UML Use-Case Diagrams58. Begin Use-Case Names with a Strong Verb以“强动词”作为用例名称的开头59. Name Use Cases Using Domain Terminology使用领域术语作为用例名称60. Imply Timing Considerations by Stacking Use Cases以用例的堆放顺序“暗示”其发生时间61. Place Your Primary Actor(s) in the Top Left Corner of the Diagram把主要参与者放置于图标的左上角62. Draw Actors on the Outside Edges of a Use-Case Diagram将参与者放置于用例图的边框外63. Name Actors with Singular, Domain-Relevant Nouns用单数的、领域相关的名称来为参与者命名64. Associate Each Actor with One or More Use Cases每个参与者关联到一个或者多个用例65. Name Actors to Model Roles, Not Job Titles以角色命名参与者，不以职务头衔命名66. Use <<system>> to indicate System Actors使用<<system>>表示系统参与者67. Don’t Allow Actors to Interact with One Another不允许参与者之间有互动68. Introduce an Actor Called “Time” to Initiate Scheduled Events用“时间”参与者标示预定事件69. Indicate an Association between an Actor and a Use Case if the Actor Appears Within The Use-Case Logic如果参与者出现在用例中，则可以在参与者和用例之间放置关联70. Avoid Arrowheads on Actor–Use-Case Relationships在参与者与用例之间的关联中，避免出现箭头71. Apply <<include>> When You Know Exactly When to Invoke the Use Case用例“一定”会启动，适用包含关系72. Apply <<extend>> When a Use Case May Be Invoked Across Several Use Case Steps用例“可能”会启动，适用扩展关系73. Apply Extend Associations Sparingly谨慎地使用扩展关系74. Generalize Use Cases When a Single Condition Results in Significantly New Business Logic描述相似的业务逻辑时，适用泛化关系75. Do Not Apply <<uses>>, <<includes>>, or <<extends>>不要使用<<uses>>, <<includes>>,或<<extends>>76. Avoid More Than Two Levels of Use-Case Associations用例之间的包含关系或扩展关系，避免达到两层以上77. Place an Included Use Case to the Right of the Invoking Use Case把被包含用例放置于基础用例的右方78. Place an Extending Use Case below the Parent Use Case把扩展用例放置于基础用例的下方79. Apply the “Is Like” Rule to Use-Case Generalization应用“就像是”规则来判断用例之间的泛化关系80. Place an Inheriting Use Case below the Base Use Case把子用例放置于父用例的下方81. Apply the “Is Like” Rule to Actor Inheritance应用“就像是”规则来判断参与者之间的泛化关系82. Place an Inheriting Actor below the Parent Actor把子参与者放置于父参与者的下方83. Avoid Modeling Extension Points避免使用扩展点84. Model Extension Conditions Only When They Aren’t Clear只有在不清楚的情况下，才使用扩展条件85. Indicate Release Scope with a System Boundary Box在系统范围方框内指出发布范围86. Avoid Meaningless System Boundary Boxes避免无意义的系统范围方框（4）UML Class Diagrams87. Identify Responsibilities on Domain Class Models88. Indicate Visibility Only on Design Models89. Indicate Language-Dependent Visibility with Property Strings90. Indicate Types on Analysis Models Only When the Type Is an Actual Requirement91. Be Consistent with Attribute Names and Types92. Model Association Classes on Analysis Diagrams93. Do Not Name Associations That Have Association Classes94. Center the Dashed Line of an Association Class95. Use Common Terminology for Class Names96. Prefer Complete Singular Nouns for Class Names97. Name Operations with Strong Verbs98. Name Attributes with Domain-Based Nouns99. Do Not Model Scaffolding Code100. Center Class Names101. Left-Justify Attribute Operation and Names102. Do Not Model Keys103. Never Show Classes with Just Two Compartments104. Label Uncommon Class Compartments105. Include an Ellipsis (. . .) at the End of an Incomplete List106. List Static Operations/Attributes before Instance Operations/Attributes107. List Operations/Attributes in Order of Decreasing Visibility108. For Parameters That Are Objects, List Only Their Types109. Develop Consistent Operation and Attribute Signatures110. Avoid Stereotypes Implied by Language Naming Conventions111. Indicate Exceptions in an Operation’s Property String112. Model Relationships Horizontally113. Draw Qualifier Rectangles Smaller than Classes114. Model Collaboration between Two Elements Only When They Have a Relationship 115. Model a Dependency When the Relationship Is Transitory116. Tree-Route Similar Relationships to a Common Class117. Always Indicate the Multiplicity118. Avoid a Multiplicity of “*”119. Replace Relationship Lines with Attribute Types120. Do Not Model Implied Relationships121. Do Not Model Every Dependency122. Center Names on Associations123. Write Concise Association Names in Active Voice124. Indicate Directionality to Clarify an Association Name125. Name Unidirectional Associations in the Same Direction126. Word Association Names Left to Right127. Indicate Role Names When Multiple Associations between Two Classes Exist128. Indicate Role Names on Recursive Associations129. Make Associations Bidirectional Only When Collaboration Occurs in Both Directions 130. Indicate Direction Only on Unidirectional Associations131. Avoid Indicating Non-Navigability132. Redraw Inherited Associations Only When Something Changes133. Question Multiplicities Involving Minimums and Maximums134. Apply the Sentence Rule for Inheritance135. Place Subclasses below Superclasses136. Beware of Data-Based Inheritance137. A Subclass Should Inherit Everything138. Differentiate Generalizations between Associations139. Indicate Power Types on Shared Generalization140. Apply the Sentence Rule for Aggregation141. Be Interested in Both the Whole and the Part142. Place the Whole to the Left of the Part143. Apply Composition to Aggregates of Physical Items144. Apply Composition When the Parts Share Their Persistence Life Cycle with the Whole 145. Don’t Worry About the Diamonds（5）UML Package Diagrams146. Create Class Package Diagrams to Logically Organize Your Design147. Create UML Component Diagrams to Physically Organize Your Design148. Place Inheriting Packages below Base Packages149. Vertically Layer Class Package Diagrams150. Create Use-Case Package Diagrams to Organize Your Requirements151. Include Actors on Use-Case Package Diagrams152. Arrange Use-Case Package Diagrams Horizontally153. Give Packages Simple, Descriptive Names154. Make Packages Cohesive155. Indicate Architectural Layers with Stereotypes on Packages156. Avoid Cyclic Dependencies between Packages157. Reflect Internal Relationships in Package Dependencies（6）UML Sequence Diagrams158. Strive for Left-to-Right Ordering of Messages159. Layer Object Lifelines160. Give an Actor the Same Name as a Class, If Necessary161. Include a Prose Description of the Logic162. Place Proactive System Actors on the Leftmost Side of Your Diagram163. Place Reactive System Actors on the Rightmost Side of Your Diagram164. Avoid Modeling Object Destruction165. Avoid Activation Boxes166. Name Objects Only When You Reference Them in Messages167. Name Objects When Several of the Same Type Exist168. Apply Textual Stereotypes to Lifelines Consistently169. Focus on Critical Interactions170. Justify Message Names beside the Arrowhead171. Create Objects Directly172. Apply Operation Signatures for Software Messages173. Apply Prose to Messages Involving Human and Organization Actors174. Prefer Names over Types for Parameters175. Indicate Types as Parameter Placeholders176. Apply the <<include>> Stereotype for Use Case Invocations177. Do Not Model Obvious Return Values178. Model a Return Value Only When You Need to Refer to It Elsewhere in a Diagram 179. Justify Return Values beside the Arrowheads180. Model Return Values as Part of a Method Invocation181. Indicate Types as Return-Value Placeholders182. Indicate the Actual Value for Simple Return Values（7）UML Communication Diagrams183. Create Instance-Level Diagrams to Explore Object Design Issues184. Create Specification-Level Diagrams to Explore Roles185. Apply Robustness Diagram Visual Stereotypes186. Do Not Use Communication Diagrams to Model Process Flow187. Create a Sequence Diagram When Sequence Is Important188. Apply Sequence Diagram Guidelines to Instance-Level Communication Diagrams 189. Indicate Parameters Only When They Aren’t Clear190. Depict an Arrow for Each Message191. Consolidate Getter Invocations192. Indicate Concurrent Threads with Letters193. Model “Bare” Links on Instance-Level Communication Diagrams194. Show Role-Pertinent Information in Specification-Level Diagrams195. Prefer Roles on Links Instead of Within Classes196. Indicate Navigability Sparingly197. Use Links to Reflect Consistent Static Relationships（8）UML State Machine Diagrams198. Create a State Machine Diagram When Behavior Differs Based on State199. Place the Initial State in the Top Left Corner200. Place the Final State in the Bottom Right Corner201. State Names Should Be Simple but Descriptive202. Question “Black-Hole” States203. Question “Miracle” States204. Model Substates for Targeted Complexity205. Aggregate Common Substate Transitions206. Create a Hierarchy of State Machine Diagrams for Very Complex Entities 207. Always Include Initial and Final States in Top-Level State Machine Diagrams 208. Name Software Actions Using Implementation-Language Naming Conventions 209. Name Actor Actions Using Prose210. Indicate Entry Actions Only When Applicable to All Entry Transitions211. Indicate Exit Actions Only When Applicable to All Exit Transitions212. Model Recursive Transitions Only When You Want to Exit and Reenter the State 213. Name Transition Events in Past Tense214. Place Transition Labels near the Source States215. Place Transition Labels on the Basis of Transition Direction216. Do Not Overlap Guards217. Introduce Junctions to Visually Localize Guards218. Use Guards Even If They Do Not Form a Complete Set219. Never Place a Guard on an Initial Transition220. Use Consistent Language for Naming Guards（9）UML Activity Diagrams221. Place the Starting Point in the Top Left Corner222. Include an Ending Point223. Simplify Operations Requiring Flow Charts224. Apply Connectors to Avoid Unwieldy Activity Edges225. Connectors Should Match226. Label Connectors with Numbers227. Question “Black-Hole” Activities228. Question “Miracle” Activities229. Reflect the Previous Activity by Using Decision Points230. Avoid Superfluous Decision Points231. Ensure That Each Activity Edge Leaving a Decision Point Has a Guard232. Do Not Overlap Guards233. Ensure That Guards on Decision Points Form a Complete Set234. Ensure That Exit Guards and Activity Invariants Form a Complete Set235. Apply an [Otherwise] Guard for “Fall-Through” Logic236. Model Guards Only If They Add Value237. Indicate Decision Logic over Complex Guards238. Simplify Guards By Indicating Decisions Within Diamonds239. Ensure That Forks Have Corresponding Joins240. Ensure That a Fork Has Only One Entry241. Ensure That a Join Has Only One Exit242. Avoid Superfluous Forks243. Activity Edges Should Enter Joins and Forks from the Same Side244. Model Joinspecs Only When the Join Isn’t Clear245. Align Fork and Join Bars246. Order Swim Lanes in a Logical Manner247. Apply Swim Lanes to Linear Processes248. Have Fewer than Five Swim Lanes249. Replace Swim Lanes with Swim Areas in Complex Diagrams250. Reorganize into Smaller Activity Diagrams When Swim Areas Include Several Activities 251. Consider Horizontal Swim Lanes for Business Processes252. Model the Key Activities in the Primary Swim Lane253. Model Action Objects as Names on Activity Edges254. Depict Input Pins on the Left255. Depict Output Pins on the Right256. Pins Should Have Names Describing the Parameter(s)257. Avoid Superfluous Pins258. Model Action Objects only when they are not obvious259. Place Shared Action Objects on Swim Lane Separators260. Apply State Names When an Object Appears Several Times261. Reflect the Life-Cycle Stage of an Action Object in Its State Name262. Show Only Critical Inputs and Outputs263. Depict Action Objects as Smaller than Activities（10）UML Component Diagrams264. Apply Descriptive Names to Architectural Components265. Apply Environment-Specific Naming Conventions to Detailed Design Components 266. Apply Consistent Textual Stereotypes267. Avoid Modeling Data and User Interface Components268. Apply One Component Stereotype Consistently269. Show Only Relevant Interfaces270. Model Dependencies from Left to Right271. Place Inheriting Components below Base Components272. Make Components Dependent Only on Interfaces273. Avoid Modeling Compilation Dependencies（11）UML Deployment Diagrams274. Indicate Software Components on Project-Specific Diagrams275. Assume That Nodes Are Devices276. Use Concise Notation277. Apply Drum Notation for Data Stores278. Focus on Nodes and Communication Associations in Enterprise-Level Diagrams 279. Group Common Nodes280. Put Detail into Installation Scripts281. Use Descriptive Terms to Name Nodes282. Model Only Vital Software Components283. Apply Consistent Stereotypes to Components284. Apply Visual Stereotypes to Nodes285. Indicate Communication Protocols via Stereotypes286. Model Only Critical Dependencies between Components（12）UML Object Diagrams287. Indicate Attribute Values to Clarify Instances288. Prefer Object Names over Attribute Values289. Indicate Roles to Distinguish Different Relationships（13）UML Composite Structure Diagrams290. Focus on Object Roles in Collaboration-Style Composite Structure Diagrams 291. Focus on Collaborations in Detailed-Style Composite Structure Diagrams 292. Create Detailed-Style Composite Structure Diagrams over Collaboration Style 293. Create UML Object Diagrams Instead of Composite Structure Diagrams（14）UML Interaction Overview Diagrams294. Reference Other Diagrams, Don’t Depict Them295. Don’t List Lifelines（15）UML Timing Diagrams296. Draw a Continuous Timing Diagram for Analog Values297. Draw a Value Change Timing Diagram to Explore High-Level Life Cycles 298. Draw State Machine Diagrams to Explore Detailed Life Cycles299. Order the States Intelligently300. Model Time along the X Axis301. Don’t Label the Time Axis “Time”302. Center the X Axis Heading303. Place the Y Axis Heading at the Top Left304. Use Time Observations to Depict Specific Times305. Use Timing Marks to Depict a Time Series306. You Don’t Need to Label All Timing Marks307. Use Time Durations to Depict a Specific Period of Time308. Use Time Constraints to Bound a Specific Period of Time。