电信业务与网络第08讲.ppt

电信业务与网络,第八讲 电信业务开发及相关软件技术,Q.65（06/2000）,Series Q:Switching and SignallingFunctions and information flows for services in the ISDN MethodologyThe unified functional methodology for the characterization of services and network capabilities including alternative object-oriented techniques,简介,本ITU-T建议取代了97年版本的Q.65建议，描述了为了业务实现在提供业务和解决信令需求时使用的一个通用的功能体系结构。2000年版本Q.65描述了新版本的统一功能方法（UFM：Unified Functional Methodology），此新版本的UFM结合了Q.65 1988年版本中的方法、智能网描述方法中使用的一些方法、以及UFM中使用的一些方法。UFM使得从一个单一的统一功能体系结构出发，有两种方法可以到业务的功能描述。一种是使用基于SIB的技术，得到信息流（IF）、功能实体动作（FEA）、SDL描述；另一种是使用面向对象的技术，得到接口类描述、通用IDL描述和SDL描述。此统一的模型使得可以用类似的手段描述所有的网络体系结构（例如ISDN、B-ISDN、IN、IMT-2000，以及TMN）ITU-T 1.130中描述了导出ISDN业务的交换和信令方面的需求的整个方法。,UFM的原则,在确定UFM时采用的原则包括:UFM允许在已有第1阶段业务描述的情况下、或是为了业务生成（service creation）已经描述了网络能力（network capability）描述的情况下，可产生功能描述（functional description）UFM主要基于使用以下方法所获得的经验：ISDN第2阶段方法（ITU-T Q.65（1988）、IN方法（ITU-T Q.1210,（1995）、由Rumbaugh,Booch等提出并在UML中得以提炼的分布式计算技术ITU-T Q.65（1997版本）提出了使用功能模型（functional model）、功能实体（functional entities）、功能实体动作（functional entity actions）进行业务描述IN方法提供了业务描述时所希望的灵活性（flexibility）、业务无关（service independence）、重用（re-use）等特性。利用UML这一工具，可得到接口类、以及接口类之间的关系的详尽描述。通过使用其它工具，可以得到接口的IDL描述（这些IDL形成API）。UFM基于一个统一功能模型（The method is based on a unified functional model）（对统一功能模型，请参见附录II）.统一功能体系结构（unified functional architecture）经过扩展包括新的需求，并可进一步扩展以满足用户的需要。对每一个业务描述，选择一个适当的功能实体集合来构成模型这样利于保持信息流、和/或API、SDL描述的一致性。,UFM的原则,维护一个SIB库（包括相应的信息流和SDL描述），这个库可用于确定分布功能平面中的功能体系结构 创建相应的SIB集以支持IN建议定义的能力集将SIB映射到功能体系结构，体现为映射到预定义的功能实体动作、预定义的SDL描述、和预定义的信息流。维护一个包（Packages）、接口类（interface classes）和IDL描述库。IDL定义了一个特定的接口处的API。这些（包、接口类和IDL描述）也可用于确定分布功能平面中的功能体系结构UFM要 解决当前的需要，但是也必须能够演进以容纳新的进展和新技术。在UFM的演进过程中仍能使用UFM在ITU-T内部，对统一功能体系结构的使用，采取分阶段使用方法（Phased approach for use across the ITU-T,using the unified architecture.）需要开发新的SIB需要开发新的API需要定义新的关系（relationships）必须考虑新的业务（例如多方呼叫）虽然UFM不是一个自动化过程，但重用（re-use）将在其中起主要作用。必须开发通过SIB来描述业务的新技术（New expertise must be developed for describing services from SIBs）,Application 1,Application 3,Application 2,Application/,Service plane,Package 2,Application/,Service Plane,Service package,requirements,Distributed,Functional,Physical,Plane,Plane,Plane,Package 1,Package 3,Package 4,IClass,IClass,IClass,IClass,IClass,IClass,GF/SIB1,GF/SIB2,GF/SIB3,CCAF,CCF,CCF,CCF,CCAF,SSF,SSF,SCF,SDF,SRF,IAF,SDP,SCP,Inter-networkGateway,SCP,SSPLE,LE,LE,LE,SRP,Figure 1/Q.65 Conceptual methodology model showing relationships between services,global functions/service-independent building blocks,service packages,interface classes,functional entities and physical entities,UFM的原则,对于第2阶段描述，UFM应该包括以下内容：标识业务或网络能力（identification of service or network capability）;功能模型和功能实体定义（即统一功能模型）（functional model and functional entity definition(Unified Functional Model)）标识SIB和/或包（可选）功能实体动作和/或IDL定义（functional entity actions and/or IDL-definition）信息流和/API（information flows and/or APIs）SDL（动态描述）（可选）场景（功能实体到物理地点的分配）（scenarios(physical allocation of functional entities)）定义物理场景（Define physical scenarios at an appropriate time.）需要确定推荐的网络实现对IN、B-ISDN、IMT-2000及其它网络的的扩展，物理实体的类别将增加。对工具改善和功能描述过程自动化提出有关建议可以更加有效地利用ITU-T Z.100(SDL)和Z.120(Message Sequence Chart information flows)工具可用来验证SDL及信息流,业务描述的3阶段方法,对于需要标准化的业务和网络能力，方法的第2阶段将第1阶段对基本业务、补充业务和网络能力的描述作为输入。第2阶段定义所需的功能以及这些功能在网络中的分布。,第2阶段的输出用于：第3阶段的协议设计人员来描述分离的物理实体之间使用的协议；交换机（和其它节点）设计人员来描述这些节点的功能需求；网络规划人员,第2阶段采用了一些提供下列性质的技术：功能描述（functional specification）可有不同的物理实现；对支持基本业务、补充业务以及网络能力所需功能的精确定义，以及这些功能在网络（在某些情况下，在用户设备）中可能的分配;对所提供的功能、信息流和API调用的详细描述，但并不说明这些是怎样实现的;将对协议和交换能力的需求作为方法的第3阶段的输入,Step 2,AltStep 2,Step 3,AltStep 3,Step 4,AltStep 4,Step 5,Step 6,Step 1,Using SIB,Methodology,Using O-O,Methodology,Figure 2/Q.65 Use of Step 1 to 6,UFM的步骤,Step 1-Functional model,Step 2 Applications to Package(optional),Step 3 Interface Classes and Class Diagrams,Step 4 API descriptions in IDL,Step 2 SIB description of service features,Step 3 Information flow diagrams,Step 4 Functional entity actions,Step 5 SDL diagrams for functional entity(optional),Step 6 Allocation of functional entities to physical location(scenarios),步骤1功能模型（Functional Model）,为每个基本业务、补充业务、或网络能力到处一个功能模型在每种情况下，功能模型需与所考虑的业务的需求及特性匹配。业务的第2阶段描述中使用的功能模型包括功能实体（functional entities）以及功能实体之间的关系（relationship）对初始的功能模型的求精（refinement）可通过下面要讲到的步骤2到步骤6的反复而完成，最终得到的功能模型代表第2阶段完整的工作结果。,1.1 统一功能模型（Unified functional model）,第2阶段方法中使用的统一功能模型（unified functional model）考虑了ISDN、IN、B-ISDN、IMT-2000以及TMN中共有的功能实体、实体间的关系、信息流。下图给出了一个统一功能模型的实例，此模型由UFM描述的功能实体集中得到。基于此模型，可构建一个支持特定业务或网络能力的特定的第2阶段功能模型,CCAF,CUSF,SSF,CCF,SRF,SDF,SCF,SMF,SCEF,SMAF,SCUAF,To other SMFs,To other CCFs,To other SDFs,To other SCFs,To other IAFs,To other SDFs,To other SCFs,Network,boundary,To other SDFs,To other,SCFs,Figure 3/Q.65 Unified functional model,SSF：Service Switching Function,IAF：Intelligent Access Function,CCF：Call Control Function,CCAF：Call Control Agent Function,SCF：Service Control Function,SDF：Service Data Function,SRF：Specialized Resource Function,SCUAF：Service Control User Access Function,CUSF：Call-unrelated Service Function,CUSF：CUSF是与一个与呼叫无关（call-unrelated）的业务功能，此功能实体与CCF和SSF相连，提供与SCUAF交互所需的与呼叫无关的业务功能。CUSF还提供SCUAF与 SCF交互所需的功能。CUSF：扩展CCF的逻辑，以识别业务控制触发，并与SCF交互;管理CCF与SCF间的信令在SCF的控制下修改（CCF中的）关联/连接处理功能在SCF的控制下修改（CUSF中的）与呼叫无关的交互处理功能支持与呼叫无关的用户交互，这些交互可以是用户发起的，也可以是SCF发起的。与SSF接口，处理与呼叫相关的交互SCUAF：SCUAF是业务控制用户代理功能，为用户提供接入。SCUAF是用户与CUSF间的接口。SCUAF：为用户提供接入，与用户交互，按要求建立、维护、释放一个与呼叫无关的业务实例；使用用于建立、操作和释放一个业务关联（association）或实例（instance）的业务请求（例如，set-up，位置注册（location registration）访问CCF中的业务提供能力接收来自CCF的与呼叫无关的业务指示（indications），并按照要求将这些指示传给用户维护此功能实体所能掌握的业务状态信息,1.2 功能实体（Functional entities）,业务通过功能实体之间的相互配合的动作来实现。功能实体之间的配合需要在它们之间建立通信关系（communication relationship）：在一个特定的业务功能模型中，每一对相互通信的功能实体称为在一个关系（relationship）中相互通信的功能实体间的每一个交互（interaction）称为一个信息流（information）或API调用（API call）（API调用是针对使用UML来描述参考点（reference point）而言的）。任何一对功能实体间的关系是它们之间的信息流或API调用的集合（API调用是指参考点的API）。如果一对相互通信的功能实体驻留在物理上分离的设备上，它们之间的信息流或API就定义了设备之间的信令协议（signalling protocol）的信息传送需求。不同的相互通信的功能实体对（pair）可以有不同类型的关系。关系的类型（type）通过两个功能实体之间的信息流或API调用的集合来刻画。,1.3功能实体关系（Functional entity relationships）,基于上述定义，可使用以下准则和指导原则得到针对特定业务的功能模型：基于对所希望的网络实现的多样性的了解，选择恰当的功能实体。需要考虑所有可能的功能分布，这样就使得管理人员（administration）在实际提供业务时有选择的余地。关系的类型在最初始的时候可根据对功能实体之间交互的性质的评估来确定。根据更详细的功能实体动作、信息流或API调用的定义，以及功能实体分布的物理地点的范围，有可能需要对初始功能模型进行修改。一些业务的模型需要一个功能实体被复制多次（例如，汇接功能）。功能模型在描述这种复制时，仅需描述到不会由于进一步的复制而增加新的外部关系（relationship）组合这种程度为止。这样，一个单一的功能实体可以代表提供同一功能的多个物理汇接实体。统一功能模型应覆盖尽可能多的网络体系结构,1.4 导出功能模型（Derivation of the functional model）,一个补充业务的功能模型应该与一个基本业务的模型相关在确定与补充业务相关的功能是否应与现有的基本业务的功能实体驻留在一起，还是以新的独立的功能实体出现时，应遵循下列指导原则：附加业务功能模型中的一组功能，如果它修改一个由基本业务控制的对象（例如，呼叫连接），应该将其与一个基本业务的功能实体合在一起不与一个基本业务的功能实体合在一起的一个功能实体，不需要详细的呼叫/连接状态信息。独立的功能实体也可以通过与一个补充业务的功能实体（此功能实体与基本业务的功能实体驻留在一起）有事务关系来刻画。当且仅当补充业务的功能实体需要通信，并且基本业务中已定义的信息流并不能满足这些通信需求时，才定义补充业务的功能实体之间的关系,1.5 基本业务模型与补充业务模型间的关系（Relationship between basic and supplementary service models）,步骤2业务属性的SIB描述（SIB description of service features）,鼓励使用SIB和HLSIB来描述业务属性和网络能力。因为SIB的使用促进了已定义的SDL、信息流、功能实体动作的重用下面的指导原则适用于第2阶段方法：提供业务属性（service feature）的全局业务逻辑图，包括POI和POR全局业务逻辑（GSL）将SIB串接起来，定义了SIB操作的串接次序，从而构建了实现业务属性的业务处理流程在描述中提供SIB到同一功能模型中的功能实体的映射。另外，提供对所使用的SIB的定义的应用（reference）。提供业务所需的SIB数据参数，标识在业务的上下文中这些参数的数据取值,步骤3信息流（Information flow diagrams）,3.1 标识信息流：功能的分布要求功能实体之间进行交互。这样一个交互称为一个“信息流”，需要为信息流取个能够说明此信息流目的的名字需要绘制信息流图（information flow diagrams）来描述成功的业务操作所必需的所有信息流，同样也需要为其它情况绘制信息流图。3.2 定义每一个信息流：确定每个信息流的语义和信息内容。一个信息流可以是需要证实的，如果是需要证实的，需要一个具有相同名字的返回信息流当交互的功能实体在物理上分离的地点实现，信息流通常通过信令系统协议传送使用表来说明信息流中的每一项，并应该指出每一项是否是必需的，或者是可选的，并且指出信息流通过哪个关系传递,步骤4功能实体动作（Functional entity actions）,对接收到每一信息流，标识并列出来从接收到此信息流到发出由此而产生的结果信息流（next resulting information flow）这一段，功能实体中执行的动作每一功能实体动作通过一个参考号码（reference number）来标识,步骤5功能实体的SDL图（可选）（SDL diagrams for functional entities（optional）,根据提供业务时功能实体执行的动作、由于动作而产生的信息流以及引起动作触发的信息流，可用SDL图形表示形式地描述一个给定的业务基于第3步中产生的信息流图，SDL图详细地描述了正常、不成功和异常的业务操作，并与信息流图一致SDL由ITU-T Z.100定义。,步骤6将功能实体映射到物理位置（Allocation of functional entities to physical locations（scenarios）,在步骤1，对每个基本和补充业务都有一个功能模型步骤6是将这些功能实体分配到物理地点并定义所有相关的物理实现，我们把这种分配称为场景（scenario）对一个功能模型可以有不止一个场景，这样，管理机构（Administrations）可以选择实际上如何提供业务。对于功能实体的分配，应该注意：一个功能实体原则上可分配到任何物理地点一些功能实体可被分配到同一物理地点对于每一补充业务，应该定义包括其基本业务的功能实体的网络场景（network scenarios）功能实体分配在不同的物理地点可能表明节点在能力上有细微的不同对于所使用的功能模型，功能实体对之间的关系应该对所有推荐的场景保持不变在第3阶段定义信令协议、交换能力和业务能力时应被考虑所有的场景,面向对象方法中的步骤（Alternative steps utilizing Object Oriented techniques）,在描述IN接口时，可使用面向对象（O-O）的技术，也可使用非O-O技术，要么对同一接口使用O-O方法，要么使用非O-O方法。其结果要么是一个API调用的集合（使用O-O技术）和要么是一个信息流的集合（使用非O-O技术）虽然上述这两种结果均可映射到INAP协议，但这显得有点凌乱利用UML来描述UFM的步骤2-4,步骤2应用到包的映射（Applications to Packages（Optional）,在UML中，包（package）是一种将建模元素（modelling element）组织成组的通用机制。在我们的方法中，应用或业务由一些包构成。包用于将建模元素组织成一个可被作为一个组进行操作的更大的块。包将语义上等价的元素成组，并且这些元素趋向于作为一个组而变化。有的应用包括许多包，有的可能仅有一个包。使用包可对为得到必需的接口类（Interface Class）而需做进一步分析的内容进行描述；另一方面，使用包可将在一个特定接口处所需要的接口类成组,Call Control,Figure 20/Q.65 Example of a Package,Figure 21/Q.65 Mapping Packages to Applications,Call Control,Authentication:a:b:c:d,Messaging,Application X,Application Y,Requires,sub-element,a,b,c,步骤3接口类和类图（Interface Classes and Class Diagrams）,接口有名字，一个接口是一个操作的集合，这些操作用于描述一个类（class）或一个构件（component）提供的服务（service）。不同于类（class）和类型（type），接口 并不描述结构（这样，接口不包括属性），接口也不描述实现（这样，接口不包括任何方法，方法提供一个操作的实现）象类一样，接口可以有任意多个操作。这些操作可以有不同的可见特性（visibility properties）、并发特性（concurrency properties）、构造型（stereotype）、标记值（tagged value）和约束（constraint）画操作时可以只显示它们的名字，也可以将它们的迹（signature）和其它特性显示出来,Figure 22/Q.65 Operations in an Interface Class,3.1 接口类（Interface Classes）,接口类可成对地描述，分为“接口类”（Interface Class）和“应用接口类”(Application Interface Class)“基本接口类”驻留在接口一侧的系统中，“应用”驻留在接口的另一侧通常，由“应用”调用的方法需要一个由“基本接口类”实现的结果在描述一个系统时，可使用两中非常有用的接口类：接口类“框架”（Framework）和接口类“通用业务”（Generic Service）“框架”是一些类，这些类为一个域（domain）中的应用描述一个可扩展的模板。“通用业务”是一些类，这些类满足所考虑的接口的业务需求使用这两种接口类时，需要进一步地详细定义，即需要对这两种接口类充实各自的方法调用（method invocation）,3.2 类图（Class Diagrams）,每个接口类之间的关系通过使用“类图”（Class diagram）来描述一个类图是一个图，此图包括一些类、接口、协作（collaborations）以及它们之间的关系可以使用类图为系统的静态特性建模。类图通常包括以下内容：类（Classes）:一个类是具有相同属性、操作、关系和语义的对象的集合。一个类实现一个或多个接口。接口（Interfaces）:一个接口是操作的集合，这些操作用于描述一个类或构件（component）提供的服务（service）协作（Collaborations）:一个协作包括一些类、接口和其它一些元素，这些元素协同工作，提供比这些元素的总和都要大的协作行为。依赖（Dependency）、泛化（generalization）和关联（association）关系:依赖是一种关系，依赖描述了一个东西的改变将影响另一件东西，但反过来不成立泛化是一种一个普通的东西（称为超类或父亲）与另一种更特定的东西（称为子类或孩子）之间的关系关联是一种结构性的关系,3.3 接口顺序图（可选）（Interface sequence diagram（Optional）,接口顺序图的使用是可选的接口顺序图本质上与“信息流图”（information flow diagram）是相似的。然而，接口顺序图还指示API调用流（API call flows）因为每个系统内部的API调用很可能是专有的，在一个建议中使用接口顺序图是受限或可略去。,:Iapp Call,IcallControlManager,Party A:ICallLeg,ICall,1:new(),:Iapp Logic,Party BICallLeg,2:createCall(),3:new(),4:setCallbackl(),5:routeCallToOrigination_Req(),6:new(),7:routeCallToOrigination_res(),8:“forward event”,9:routeCallToDestination_Req(),11:routeCallToDestination_res(),12:“forward event”,10:new(),Figure 25/Q.65 Example Interface Sequence diagram,步骤4用IDL描述API（API descriptions in IDL）,通过上述两个步骤，得到了在接口处的接口类，下一步就是详细描述方法调用（method invocation）本建议推荐使用通用的IDL（Interface Description Language）来描述API使用IDL语言的好处是可以将接口描述转换到特定的实现方案，如CORBA、INAP或JAVA使用IDL可详细地描述每一方法调用、以及所携带的参数,routeCallToDestination_Req(callSessionID:in TSessionId,responseRequested:in TCallResponseRequest,targetAddress:in Taddress,originatingAddress:in Taddress,originalDestinationAddress:in Taddress,redirectingAddress:in Taddress,appInfo:in TCallAppInfoArr):TResult,1Scope2Normative references3Definitions4Symbols and abbreviations 5Description6Derivation of the functional model6.1Functional model description and relationship with the basic service6.2Description of functional entities7SIB-based service feature definitions8Information flows8.1Information flow diagrams8.2Definition of individual information flows8.2.1Relationship r1 8.2.1.1Contents of information flow8.2.1.xContents of information flow 9Functional entity actions10SDL diagrams for functional entities11Allocation of functional entities to physical locations(scenarios),APPENDIX IFormat and outline of a Stage 2 description using the unified functional methodology,APPENDIX IIFunctional architecture Q.65 evolution,APPENDIX IIIExamples of Interface Classes formed from Service/Application requirements,Series QSupplement 29(12/1999)Service modelling:Evolution to the use of object oriented techniques,Unified Modeling Language统一建模语言,参考资料,张龙祥编著，UML与系统分析设计，人民邮电出版社，2001年8月第1版周伯生等译，统一软件开发过程，机械工业出版社，2002年1月第1版OMG Unified Modeling Language Specification，Version 1.4,Sep.2001,面向对象的主要概念,对象（Object）类（Class）封装（Encapsulation）继承（Inheritance）消息（Message）分类（Classification）分类（Classification）表现的是事物的一般与特殊的关系，即“a-kind-of”或“is-a”的关系。在面向对象的术语中常把一般与特殊的关系称为泛化（Generalization）和特化（Specialization）联系组合（Composition）组合结构（Composition Structure）表示对象类之间的组成关系，即部分与整体的关系部分对于整体是“a-part-of”关系，整体对于部分是“has-a”关系。关联（Association）实例连接（Instance Connection）表现对象之间的静态关系，它是通过对象的属性来表现的对象之间的依赖关系。在面向对象的术语中，常把对象之间的实例连接称为链接（Link），而把存在实例连接的对象类之间的联系称为关联（Assocaition）多态性（Ploymorphism）,UML概述,UML是一种标准的软件建模语言，它是一种用于对一个软件系统的制品进行可视化描述、详细描述、构造以及文档化的语言。最主要的是，UML使得开发者能够用标准化的蓝图或者图表的方式对他们所加工的产品进行可视化描述。,UML概述,UML包括3个方面的内容：模型的概念和表示法语言的公共机制对象约束语言,UML简史,UML模型有关概念和表示法,UML提供了3类基本的标准模型构建块：事物、关系和图形事物是一个模型的一级抽象成员，即构成模型的元素“事物”代表任何可以定义的东西事物共有4类：结构类的事物、行为类事物、分组类的事物、注释类的事物。其中，结构类的事物指模型的静态部分，如对象类、Use Case、接口（Interface）、构件（Component）、节点（Node）等；行为类的事物指模型的动态部分，如交互、状态机等；成组类的事物指模型的组织部分，如包（Package）；注释类的事物指模型的解释说明部分，如注释（Note）UML提供的模型构建块之间的基本关系有：依赖（Dependency）、关联（Association）、泛化（Generalization）、实现（Realization）等依赖是指模型构建块之间的一种语义联系，其中一个（独立事物）发生改变将影响另一个（依赖事物）的语义。关联是指模型构建块之间的结构关系，两者存在结构性的链接（Link）聚合（Aggregation）是一种特殊的关联，表示结构的整体与部分的关系。泛化（Generalization）是指模型构建块之间的一般与特殊的联系实现（Realization）是指模型构建块之间的一种语义联系，其中一个规定了一组约定（协议），另一个负责实现它们。,UML模型有关概念和表示法,UML图形是模型元素集合的可视化表示。UML定义了9类图形，用于建立系统模型：类图、对象图、Use Case图、顺序图、协作图、状态图、活动图、构件图、配置图。通过绘制UML图形，可以从不同的抽象角度使系统可视化。UML提供了对各个模型构建块进行说明的语法和语义规定。在建立模型时，可以用UML的图形表示法使系统可视化，同时用UML的说明描述系统的细节具体地说，UML提供了以下的系统模型化功能：Use Case建模：Use Case抽取系统的功能需求对象类建模和对象建模：UML支持基本的和高级的对象类和对象建模。可以使用UML中的对象类定义一系列业务对象（类）和应用结构，并且建立对象作为这些类的实例。对象建模定义对象的行为、保证Use Case和业务规则得到正确的支持。构件建模：构件是指源代码的物理单元和可执行单元，它们组成应用系统。对象类分别组织在构件中，成为应用系统中的可复用的模块。配置建模：配置建模是把软件系统在计算机网络上的配置方式进行模型化。,UML语言的公共机制,UML规定了语言的四种公共机制：说明、装饰、通用划分、扩展机制说明（Specification）：UML不只是一个图形语言，还规定了对于每一个UML图形的文字说明的语法和语义。装饰（Adornment）：大多数的UML元素有唯一的直接的图形表示法，表达该元素的最重要的特征。除此之外，还可以对该元素加上各种装饰，说明其它方面的细节特征。通用划分（Common Division）：对UML的事物规定了两种类型的划分。一种是如类与对象的划分，另一种是如接口与接口的实现的划分。对于大多数的UML元素都可以做这样的划分。扩展机制（Extension Mechanism）：UML语言的扩展机制，允许UML的使用人员根据需要自定义一些构造型等语言成分，扩展UML和把UML客户化，更便于完成自己的软件系统的开发工作。UML规定可以自定义3种语言成分：构造型（Stereotype）、标记值（Tagged Value）和约束（Constraint）UML规定了许多标准的预定义的构造型、标记值和约束，但是允许自行扩充。,结构类的事物,Window,类（Class）,接口（Interface）,图例,图例,结构类的事物主要有7种：用况（use case）、类（class）、主动类（active class）、接口（interface）、构件（component）、协作（collaboration）及节点（node）,注：除特别说明外，图例均摘自OMG Unified Modeling Language Specification，Version 1.4,下同,结构类的事物,用况（Use Case）,Place Order,用况图（Use Case Diagram）举例,Place order,Check status,Fill orders,Establish credit,Supervisor,Telephone catalog,Shipping Clerk,Salesperson,Customer,图例,结构类的事物,用况间的关系举例：,SupplyCustomer Data,OrderProduct,Arrange Payment,Place Order,Extension points,additional request:,after creation of the order,Request Catalog,The salesperson asks for catalog,Salesperson,1,*,结构类的事物,协作（Collaboration）,Observer,协作的使用（Use of a collaboration）举例：,Observer,Call Queue,queue:List of Call sou