元建模技術(shù)1課件

1、北京大學(xué)軟件與微電子學(xué)院課程模型驅(qū)動的軟件開發(fā)技術(shù)Model-driven Software Development Technology 元建模技術(shù)（上）蔣嚴冰提綱引例（GMF建模實例）元模型與元建模MOF元模型簡介UML體系結(jié)構(gòu)UML擴展機制MOF的實現(xiàn)ECore基于GMF的元建模工具的開發(fā)技術(shù)元模型與元建模什么是語言？語言是人類特有的一種符號系統(tǒng)。喬姆斯基：語言是承載信息的表示符語言的形式表示：語言=語法+語義語法：是一套將語言元素（字）組織成表達式（詞、短語）規(guī)則。語義：是一套將語法的表達式賦予某種意義的規(guī)則。UML的體系結(jié)構(gòu)語法 語法定義了該語言中存在什么結(jié)構(gòu)，以及這些結(jié)構(gòu)是怎樣由其

2、他的結(jié)構(gòu)組成的。 抽象語法當(dāng)語言具有圖形語法的時候，以獨立于表示法的方式定義語法就變得重要了，這就是抽象語法。 具體語法通過將表示法映射到抽象的語法，可以定義具體的語法。 語義靜態(tài)語義靜態(tài)的語義定義了一個結(jié)構(gòu)的實例應(yīng)該怎樣與其他實例連接才有意義 X/y y0動態(tài)語義而動態(tài)語義定義了這種良構(gòu)結(jié)構(gòu)的意義。 文本語言(3 + 2) * 7times(plus(3,2),7)35具體語法抽象語法語義StringExpTreeNumberparse“Semantic function”E: ExpTree - NumberE (plus (e1, e2) = E (e1) + E (e2)E (time

3、s (e1, e2) = E (e1) * E (e2)E (3) = 3, etc “語義域”UMLClass, Association, Class?具體語法抽象語法語義圖形XMI元模型的實例?mapUML的語義域是什么?map模型與元模型(Model and Metamodel)元元模型Meta-metamodel用MOF (Meta Object Facility)描述元模型Metamodel語言的定義:模型元素約束規(guī)則模型Model 根據(jù)語言中的描述規(guī)則 描述應(yīng)用系統(tǒng)User objects 模型的實例meta metamodel M3metamodel M2model M1User

4、 objects M0OMG的四層結(jié)構(gòu)M3M2M1M0Meta-Object FacilityUML, CWM,SPEMy modelWhat ImmodellingMetametamodelMetamodelModelUser objectsClassAssociationObjectsModelMeta-Model(M0)(M1)(M2)CustomerOrderitemquantityCustomeridUML元模型UML元模型是 UML模型的語法和語義的規(guī)約GeneralizableElementisRoot : BooleanisLeaf : BooleanisAbstract :

5、BooleanClassisActive : BooleanClassifierFeaturevisibility : public, private,protected*not self.isAbstract implies self.allOperations-forAll(op | self.allMethods-exists(m | m.specification includes (op)Well-formedness constraint (OCL)Meta-Class元建模元建模的意義求同存異手工為不同的建模語言開發(fā)建模工具代價高昂,所以人們需要某種技術(shù)以降低建模工具的開發(fā)成本.

6、元建模技術(shù)是解決這個問題的方法之一,其核心思想是由領(lǐng)域?qū)＜野葱瓒ㄖ祁I(lǐng)域建模語言,然后通過代碼生成技術(shù)自動獲得支持該領(lǐng)域建模語言的建模工具.大量的工程實踐表明,基于元建模的領(lǐng)域建模要比基于統(tǒng)一建模語言UML 的效率高出10 倍.采用DSL 也使得軟件的維護變得更為簡單.基于元建模的MDA 比基于單一建模語言UML 的MDA 更有潛力.元建模的內(nèi)容與定義元建模主要包含兩個要素: 建立元模型以刻畫某種建模語言; 提供(通過配置或直接生成)支持該建模語言的建模工具. 定義:元建模. 建立用以刻畫某種建模語言的元模型,并提供支持該建模語言的建模工具.元建模工具則是支持元建模的輔助開發(fā)工具.它可以用于設(shè)計

7、建模語言,同時還可以輔助實現(xiàn)支持該建模語言的建模工具.元元模型描述元模型(MetaModel)需要元語言的支持,而元語言是通過元元模型(Meta-MetaModel)刻畫的.所以,要建立元模型構(gòu)造元建模工具,首先必須確定元元模型.MOF 是OMG 推出的標準元元模型。MOF 主要考慮的是元模型的構(gòu)造以及數(shù)據(jù)集成(模型交換),而不是元建模工具,所以,元建模工具實現(xiàn)上的許多問題它都沒有考慮. MOF 沒有對建模語言表示法建模的能力;MOF 也無法刻畫建模語言的語義OMG Unified Modeling LanguageTM (OMG UML), Infrastructure Version 2.

8、2When metamodeling, we primarily distinguish between metamodels and models. A model that is instantiated from a metamodel can in turn be used as a metamodel of another model in a recursive manner. A model typically contains model elements. These are created by instantiating model elements from a met

9、amodel, i.e., metamodel elements. The typical role of a metamodel is to define the semantics for how model elements in a model get instantiated.the metaclasses Association and Class are both defined as part of the UML metamodel. These are instantiated in a user model in such a way that the classes P

10、erson and Car are both instances of the metaclass Class, and the association Person.car between the classes is an instance of the metaclass Association. The semantics of UML defines what happens when the user defined model elements are instantiated at M0, and we get an instance of Person, an instanc

11、e of Car, and a link (i.e., an instance of the association) between them. OMG Unified Modeling LanguageTM (OMG UML), Infrastructure Version 2.2The instances, which are sometimes referred to as “run-time” instances, that are created at M0 from for example Person should not be confused with instances

12、of the metaclass InstanceSpecification that are also defined as part of the UML metamodel. An instance of an InstanceSpecification is defined in a model at the same level as the model elements that it illustrates, as is depicted in Figure, where the instance specification Mike is an illustration (or

13、 a snapshot) of an instance of class Person. OMG Unified Modeling LanguageTM (OMG UML), Infrastructure Version 2.2MOF元模型簡介Partly refers the Richard Paiges slidesUniversity of York, UKJuly 2006 Context of this workThe present courseware has been elaborated in the context of the MODELWARE European IST

14、 FP6 project (/).Co-funded by the European Commission, the MODELWARE project involves 19 partners from 8 European countries. MODELWARE aims to improve software productivity by capitalizing on techniques known as Model-Driven Development (MDD).To achieve the goal of large-scale adoption of these MDD

15、techniques, MODELWARE promotes the idea of a collaborative development of courseware dedicated to this domain. RefresherRecall the OMG metamodel architecture.metamodelmodel“the real worldmetametamodelMeta-Object Facility (MOF)The UML metamodel and other MMsUML models and other MsVarious usages of th

16、ese modelsM0M1M2M3MOFMOF = Meta-Object FacilityA metadata management framework.A language to be used for defining languages.i.e., it is an OMG-standard metamodelling language.The UML metamodel is defined in MOF.MOF 2.0 shares a common core with UML 2.0.Simpler rules for modelling metadata.Easier to

17、map from/to MOF.Broader tool support for metamodelling (i.e., any UML 2.0 tool can be used).How has MOF come to be?Fragments of a UML metamodelUMLStages in the Evolution of Languages at the OMG. UMLMOFUMLaModelaModelMOFUMLUML_for_CORBAaModelSPEMWorkflowetc.Common Warehouse MetadataAction language (a

18、)(b)(c)The MDA meta-model stackOne unique Meta-Meta-model (the MOF)An important library of compatible Meta-modelsEach of the modelsis defined in the language of its unique meta-modelMOF Evolution MOF has evolved through several versions. MOF 1.x is the most widely supported by tools. MOF 2.0 is the

19、current standard, and it has been substantially influenced by UML 2.0. MOF 2.0 is also critical in supporting transformations, e.g., QVT and Model-to-text. We will carefully clarify which version of MOF we are presenting.Important lessons can be learned by considering each version.Principal Diagram

20、- MOF 1.x.NamespaceClassifierMOFContainsModelModelElement.0.*0.1ClassbasedOnmeta-entity10.*entityinstanceOfPackage10.*modelmeta-modelcontainedElementcontainerMOF 1.xMOF 1.x Key Abstract ClassesModelElement is the common base Class of all M3-level Classes.Every ModelElement has a nameNamespace is the

21、 base Class for all M3-level Classes that need to act as containersGeneralizableElement is the base Class for all M3-level Classes that support generalization (i.e., inheritance in OOP)TypedElement is the base Class for M3-level Classes such as Attribute, Parameter, and Constant Their definition req

22、uires a type specificationClassifier is the base Class for all M3-level Classes that (notionally) define types. Examples of Classifier include Class and DataTypeThe MOF 1.x Model -Main Concrete ClassesThe key concrete classes (or meta-metaclasses) of MOF are as follows:ClassAssociationException (for

23、 defining abnormal behaviours)AttributeConstantConstraintThe MOF 1.x Model: Key associationsContains: relates a ModelElement to the Namespace that contains itGeneralizes: relates a GeneralizableElement to its ancestors (superclass and subclass)IsOfType: relates a TypedElement to the Classifier that

24、defines its typeAn object is an instance of a classDependsOn: relates a ModelElement to others that its definition depends onE.g. a package depends on another packageMOF 2.0 RelationshipsMOF 2.0 Relationships (II)MOF 2.0 StructureMOF is separated into Essential MOF (EMOF) and Complete MOF (CMOF).EMO

25、F corresponds to facilities found in OOP and XML.Easy to map EMOF models to JMI, XMI, etc.CMOF is what is used to specify metamodels for languages such as UML 2.0.It is built from EMOF and the core constructs of UML 2.0.Really, both EMOF and CMOF are based on variants of UML 2.0.EMOF Core ClassesCMO

26、F Core ConstructsMOF ImplementationsMost widely known/used is EMF/ECore within Eclipse.It is mostly compatible with MOF 1.x, and allows importing EMOF metamodels via XMI.The XMF-Mosaic tool from Xactium implements ExMOF (Executable MOF) which subsets and extends MOF 1.x.UML2MOF from Sun is a transfo

27、rmation from UML metamodels to MOF 1.x metamodels (with some bugs).Sun MDR implementation.Commercial implementations from Adaptive, Compuware, possibly MetaMatrix, MEGA, Unicorn.UML體系結(jié)構(gòu)目錄UML規(guī)范的文檔結(jié)構(gòu)UML Infrastructure UML規(guī)范的文檔結(jié)構(gòu)UML Infrastructure OMG Unified Modeling LanguageTM (OMG UML), Infrastructu

28、re Version 2.2UML Superstructure OMG Unified Modeling LanguageTM (OMG UML), Infrastructure Version 2.2 UML Infrastructure UML Infrastructure的兩大功能Level 0 (L0) - This contains a single language unit that provides for modeling the kinds of class-based structures encountered in most popular object-orien

29、ted programming languages. As such, it provides an entry-level modeling capability. More importantly, it represents a low-cost common denominator that can serve as a basis for interoperability between different categories of modeling tools. 作為基礎(chǔ)結(jié)構(gòu)Metamodel Constructs (LM) - This adds an extra langua

30、ge unit for more advanced class-based structures used for building metamodels (using CMOF) such as UML itself. 作為元模型UML Infrastructure的結(jié)構(gòu)Infrastructure is represented by the package InfrastructureLibrary, which consists of the packages Core and ProfilesProfiles defines the mechanisms that are used t

31、o customize metamodelsCore contains core concepts used when metamodeling. coreProfilesUML Infrastructure Corethe Core package is a complete metamodel particularly designed for high reusability, where other metamodels at the same metalevel either import or specialize its specified metaclasses. UML In

32、frastructure CoreCore的分解: PrimitiveTypes, Abstractions, Basic, and Constructs PrimitiveTypes simply contains a few predefined types that are commonly used when metamodelingAbstractions mostly contains abstract metaclasses that are intended to be further specialized or that are expected to be commonl

33、y reused by many metamodels. Constructs, on the other hand, mostly contains concrete metaclasses that lend themselves primarily to object-oriented modeling; Basic represents a few constructs that are used as the basis for the produced XMI for UML, MOF, and other metamodels based on the Infrastructur

34、eLibrary. UML Infrastructure ProfilesThe Profiles package depends on the Core package, and defines the mechanisms used to tailor existing metamodels towards specific platforms, such as C+, CORBA, or EJB; or domains such as real-time, business objects, or software process modeling.The primary target

35、for profiles is UML, but it is possible to use profiles together with any metamodel that is based on (i.e., instantiated from) the common core. A profile must be based on a metamodel such as the UML that it extends, and is not very useful standalone UML Infrastructure Specification, v2.2 Profiles ha

36、ve been aligned with the extension mechanism offered by MOF, but provide a more light-weight approach with restrictions that are enforced to ensure that the implementation and usage of profiles should be straightforward and more easily supported by tool vendorsPackageMerge A package merge defines ho

37、w the contents of one package are extended by the contents of another package. A package merge is a directed relationship between two packages, that indicates that the contents of the two packages are to be combined. It is very similar to Generalization in the sense that the source element conceptua

38、lly adds the characteristics of the target element to its own characteristics resulting in an element that combines the characteristics of both. PackageMergepackage P1 and package P2 both define different increments of the same class A (identified as P1:A and P2:A respectively). Package P2 merges th

39、e contents of package P1, which implies the merging of increment P1:A into increment P2:A. Package P3 imports the contents of P2 so that it can define a subclass of A called SubA. In this case, element A in package P3 (P3:A) represents the result of the merge of P1:A into P2:A and not just the incre

40、ment P2:A.if another package were to import P1, then a reference to A in the importing package would represent the increment P1:A rather than the A resulting from merge. UML Superstructure ArchitectureThe UML Superstructure metamodel is specified by the UML package, which is divided into a number of

41、 packages that deal with structural and behavioral modeling UML Superstructure Architecture UML Superstructure ArchitectureusecasesUML Superstructure ArchitectureclassesUML Superstructure Architecture Kernel & CoreThe InfrastructureLibrary is primarily reused in the Kernel package of Classes in UML

42、2.1.2: Superstructure; this is done by bringing together the different packages of the Infrastructure using package merge. The Kernel package is at the very heart of UML, and the metaclasses of every other package are directly or indirectly dependent on it. The Kernel package is very similar to the

43、Constructs package of the InfrastructureLibrary, but adds more capabilities to the modeling constructs that were not necessary to include for purposes of reuse or alignment with MOF. UML Superstructure Architectureclasses(Kernel )UML Superstructure Architectureclasses(Kernel )UML的擴展機制目錄UML的體系結(jié)構(gòu)UML擴展

44、機制的必要性UML的擴展機制UML擴展機制的過程策略實例基本擴展機制UML1.XStereotypesConstraintsTagged ValuesUML2.0ProfileMeta model對象約束語言O(shè)bject Constraint Language (OCL)OCL是對象建模的表達式語言,用于:約束 / 不變式UML定義及建模中良構(gòu)規(guī)則(well-formedness rules) in UML definition前置后置條件訪問路徑OCL的簡單的例子Personage: IntegerCompanyemployersemployees0.*0.*Company self.emp

45、loyees.forAll(Person p | p.age = 18 and p.age select (v | v.oclType = Pseudostate)- select(p : Pseudostate | p.kind = #initial)- size select (v | v.oclType = Pseudostate)- select(p : Pseudostate | p.kind = #deepHistory)- size select(v | v.oclType = Pseudostate)- select(p : Pseudostate | p.kind = #sh

46、allowHistory)- size select (v|v.oclIsKindOf(CompositeState)- size select(f | f.oclIsKindOf(Operation)- forAll(o | o.elementOwnership.visibility = #protected)TagStereotypeTypeMultiplicitylanguagecapsuleString0.11.4衍型的表示法三種形式capsuleaCapsuleClassaCapsuleClass衍型圖標(a) 文本衍型(b) 圖形衍型(c) 圖標擴展方法在 M1層描述擴展，但應(yīng)用于

47、M2層避免 元建模工具可在模型間交換Capsule(M1)(M2)ClassAssociationCustomerOrderitemquantityCustomeridcapsuleaCapsuleClass圖形化定義是對表格方式的替代定義在 M1層metaclassClassstereotypecapsuleTagslanguage : Stringstereotype1.4衍型的合并通過多重繼承:stereotypecapsuleTagslanguage : StringmetaclassPackagestereotypePackageCapsulestereotype1.4使用衍型的場合

48、與一般的子類區(qū)分使用衍型的場合:附加的語義約束不能通過M1層的建模方式刻畫“所有的特征是受保護的”附加的語義超出了UML的范圍對代碼生成器的指令 “debugOn = true”UML 外廓Profiles相關(guān)擴展元素的包，捕獲特定領(lǐng)域的變化和使用模式是一種特定領(lǐng)域的UML解釋OMG定義的Profiles :EDOCReal-TimeCORBA.衍型對元模型元模型與衍型擴展機制之間并沒有不可逾越的鴻溝。就表達能力而言，二者有很大的重合。 首選衍型（外擴）擴展機制來描述擴展方案。選用衍型的情況可以有如下幾種：獲得的元模型與規(guī)范中原有的元模型片段結(jié)構(gòu)相同，其差別主要在于圖形表示或意義時，應(yīng)采用衍型

49、來描述擴展方案。獲得的元模型與規(guī)范中原有的元模型片段結(jié)構(gòu)相似，在對擴展方案的模型描述準確性要求不高的情況下，可以通過近似的方法忽略二者結(jié)構(gòu)上的差異。獲得的元模型與規(guī)范中原有的元模型片段結(jié)構(gòu)存在差異，但通過增加新的簡單結(jié)構(gòu)就可以彌補。 衍型對元模型當(dāng)時使用衍形擴展機制不易表達擴展方案時，應(yīng)采取元模型的方法。較之衍型方法，元模型能更清晰準確地反映抽象的語法結(jié)構(gòu)，但由于元模型方法要求建模者具有一定的元模型理論知識，因此在可理解性和普及性不如衍型。選用的情況：獲得的元模型與規(guī)范中原有的元模型片段結(jié)構(gòu)存在較大差異。獲得的元模型中的元類之間的關(guān)系復(fù)雜。對擴展方案的模型描述準確性要求較高，不能忽略獲得的元類

50、與原有元類的微小差異。UML2.0中的擴展機制外廓擴展機制外廓擴展機制不允許隨意修改已經(jīng)存在的元模型。引入外廓的目的是給出一種調(diào)整已經(jīng)存在的元模型的簡單機制，使之適合特定的領(lǐng)域、平臺或方法的建模。外廓擴展機制僅允許建模者在已經(jīng)存在的元模型構(gòu)造物的基礎(chǔ)上添加新的結(jié)構(gòu)和約束，而不能刪除已經(jīng)存在的結(jié)構(gòu)和約束。 一個簡單的EJB外廓 UML2.0中的衍型UML2.0中，在元模型中衍型是一種類，它與類之間存在一種特殊的關(guān)聯(lián)擴展。由于衍型是一種類，所以可以通過向衍型中加入屬性來對基類進行結(jié)構(gòu)上的擴展。也可以通過加注釋的形式進行靜態(tài)語義的擴展。外廓包外廓對其他包的引入，以及模型包對外廓包的應(yīng)用UML擴展機制

51、的過程策略獲取擴展需求擴展需求獲取者通過已有的模型基于UML創(chuàng)建新的模型擴展方案生成者生成擴展方案圖形模型分析抽象為元模型融入建模語言的元模型擴展方案優(yōu)化者優(yōu)化擴展方案include圖形模型分析過程識別建模元素識別建模元素之間的關(guān)系 考察每個建模元素的子結(jié)構(gòu) 識別建模元素子結(jié)構(gòu)之間的關(guān)系舉例：分析web應(yīng)用的導(dǎo)航結(jié)構(gòu)圖（Hubert Baumeister ）LibraryNewssearchVisitedArticlessearchArticlessearchAutherspublicationsPublicationarticlesauthors?AuthorarticlesArticle?

52、SearchAuthorByNameAuthorByNameAuthorByNameByPublicationPublicationMenuLibraryMenuPublicationByTitleArticleByTitleByPublicationArticleByTitleByAuthorByPublicationAuthorMenuArticleByTitleSearchArticleByTitleSearchVisitedArticleByTitleVisitedArticleByTitleNewArticleByTitle識別建模元素圖形表示名稱意義導(dǎo)航類Web應(yīng)用中對信息實體的模

53、型，代表現(xiàn)實世界中的實體，可以借助一些機制實現(xiàn)從一個導(dǎo)航對象到另一導(dǎo)航對象的導(dǎo)航。菜單顯示一個導(dǎo)航類所提供的服務(wù)種類。索引是對導(dǎo)航對象的信息的摘要列表，借助它可以快速地找到需要的導(dǎo)航對象。查詢輸入查詢條件可以找到滿足條件的導(dǎo)航對象或其索引。制導(dǎo)（guided tour）導(dǎo)出一組對象的首個對象，之后可以逐一地順序?qū)С銎渌麑ο?。?dǎo)航關(guān)聯(lián)用來表示各種對象之間的導(dǎo)航關(guān)系。包含關(guān)系用來表示導(dǎo)航類所包含的結(jié)構(gòu)。識別建模元素之間的關(guān)系圖形表示建模元素接觸點導(dǎo)航類與導(dǎo)航關(guān)聯(lián)導(dǎo)航類的外邊界與導(dǎo)航關(guān)聯(lián)的箭頭端接觸導(dǎo)航類與包含關(guān)系導(dǎo)航類的外邊界與包含關(guān)系的大頭接觸。菜單與包含關(guān)系菜單的上下邊界與包含關(guān)系的小頭接觸菜

54、單與導(dǎo)航關(guān)聯(lián)菜單中的子結(jié)構(gòu)菜單項與導(dǎo)航關(guān)聯(lián)的箭頭接觸索引與導(dǎo)航關(guān)聯(lián)索引的外邊界與導(dǎo)航關(guān)聯(lián)的箭頭端接觸索引與導(dǎo)航關(guān)聯(lián)索引的外邊界與導(dǎo)航關(guān)聯(lián)的非箭頭端接觸查詢與導(dǎo)航關(guān)聯(lián)查詢的外邊界與導(dǎo)航關(guān)聯(lián)的箭頭端接觸查詢與導(dǎo)航關(guān)聯(lián)索引的外邊界與導(dǎo)航關(guān)聯(lián)的非箭頭端接觸制導(dǎo)與導(dǎo)航關(guān)聯(lián)制導(dǎo)的外邊界與導(dǎo)航關(guān)聯(lián)的箭頭端接觸制導(dǎo)與導(dǎo)航關(guān)聯(lián)制導(dǎo)的外邊界與導(dǎo)航關(guān)聯(lián)的非箭頭端接觸考察每個建模元素的子結(jié)構(gòu)圖形表示名稱內(nèi)部結(jié)構(gòu)及其所在位置導(dǎo)航類導(dǎo)航類內(nèi)部結(jié)構(gòu)是類名，類名位于導(dǎo)航類的中央。菜單菜單的內(nèi)部結(jié)構(gòu)是菜單項和菜單名，菜單項可由一到多個，豎直排列在菜單框內(nèi)，并有橫線分割。菜單名位于菜單框外部附近。索引索引的內(nèi)部結(jié)構(gòu)是索引名，位于

55、索引框外部附近。查詢查詢的內(nèi)部結(jié)構(gòu)是查詢名，位于查詢框外部附近。制導(dǎo)索引的內(nèi)部結(jié)構(gòu)是索引名，位于索引框外部附近。導(dǎo)航關(guān)聯(lián)導(dǎo)航關(guān)系具有兩端，一端有箭頭，一端無箭頭。包含關(guān)系導(dǎo)航關(guān)系具有兩端，一端為大頭，一端為小頭。研究要點：將圖形模型抽象為元模型 Tom建模元素的類型為m1建模元素名m1Namehandm具有子結(jié)構(gòu)，類型為h子結(jié)構(gòu)名hNameSmith建模元素的類型為m2建模元素的類型為m3建模元素名m2Namem3role2role1role3role4peter建模元素的類型為m4m4Namerole2role1role3role4圖形模型分析正規(guī)的元模型舉例：分析web應(yīng)用的導(dǎo)航結(jié)構(gòu)圖的初

56、始元模型Navigational classNameincludeNamemenuNamemenuitemNameNavigational assosiationGuided tourNameindexNamequeryNameclassincludeincludedmenuitem1.*container1toinoutfromtoinfromoutintooutfromintooutfrom將元模型融入標準的元模型體系（UML/MOF）ModelElementNameRelationShipClassifierFeatureownerScopevisibilityNavigational

57、classmenuGuided tourindexqueryNavigational assosiationincludemenuitemNavigationintooutfromintoclassincludeincludedmenufeature*ower0.1Web領(lǐng)域的Use case模型以及對web應(yīng)用的驅(qū)動必要性盡管UML致力于定義越來越精確的Use Case定義，但UML并沒有對Use Case的演化做出多大的貢獻(I.Jacobson) 。 MDA的提出，要求實現(xiàn)模型之間的轉(zhuǎn)化。按照UML現(xiàn)有的Use Case圖的語義，遠遠不能達到支持從Use Case圖到其他模型自動轉(zhuǎn)化的程度。 在web應(yīng)用領(lǐng)域，許多的功能都是同用戶界面密切相關(guān)的。若采取傳統(tǒng)的Us