Patent Publication Number: US-6711734-B1

Title: Method for translating MOF metamodels to UML models

Description:
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark office patent files or records, but otherwise reserves all copyright rights whatsoever. 
     FIELD OF THE INVENTION 
     The present invention generally relates to object-oriented programming and in particular to a computer-implemented method for translating metamodel elements defined using a Metaobject Facility (MOF) into elements expressed using the Unified Modeling Language (UML) . 
     BACKGROUND OF THE INVENTION 
     MOF metamodels are used to define metadata structures for a variety of application domains such as software modeling, data warehousing, component management, versioning, and so on. MOF defines the semantics and content structure of metamodels, but it does not define a way to graphically view a metamodel. On the other hand, UML provides a graphical language for displaying models. A metamodel is a special case of a model, so a metamodel can be viewed as a UML model. Hence there is a need for an automated method for creating a UML model from a MOF metamodel such that the UML model provides a graphical picture of the MOF metamodel. 
     UML provides a well-known modeling language supported by an ever-growing set of tools. Naturally, UML may be used to view metamodels. There is a need for a set of rules for making such a transformation from MOF to UML. There are two major challenges to creating a UML model from a MOF metamodel: 
     1) MOF has concepts, such as Reference, that are not supported by UML, yet these concepts need to be captured in a UML model so that complete metamodels can be viewed; 
     2) UML has much more diverse uses than metamodeling, so rules are needed that confine translation of a metamodel into UML to use appropriate UML concepts. 
     Therefore, there is a need for a method for creating a UML model from a MOF metamodel that captures all MOF concepts for display using appropriate UML constructs. 
     A co-pending patent application, Ser. No. 09/322,137 provides a method for converting a UML model to a MOF metamodel, but this method does not teach a reverse translation. For example, said method does not address MOF Import objects. 
     Also, said method fails to teach a way to adequately represent References in UML. If a reference is only implied by a navigational association end (as in the method disclosed in this co-pending application) then there is no way to show a navigable association end without a reference. But MOF allows for a navigable association end to exist without a reference. Further, MOF allows multiple references to be defined for a single association end. Hence, there is a need for rules for translating a MOF metamodel to UML that allow for the full flexibility of MOF with respect to References. 
     The method disclosed in the co-pending application also fails to imply a means for converting a MOF Constant to UML. A MOF metamodel can contain Constant objects, and a proper UML rendering of a metamodel must show its Constants. There is therefore a need for a method to translate MOF Constants for viewing in UML. 
     SUMMARY OF THE INVENTION 
     It is an object of the present invention to provide a reliable system and method that automatically converts a MOP metamodel to a UML model. 
     Another object of the present invention is to provide a set of rules for making a transformation from a MOF metamodel to a UML model. 
     Yet another object of the present invention is to provide a system and method that presents an entire metamodel in UML including each Reference, Import, and Constant. 
     Still another object of the present invention is to provide a system and method that provides predictable mapping from an original MOF metamodel to a UML model. This is possible because a UML model can contain Tagged Values that can contain MOF information not directly supported by UML. 
     These and other objects, which will become apparent as the invention is described in detail below, are provided by a computer-implemented method for translating a MOF metamodel into a UML Model. The method comprises the steps of reading each element of the MOF metamodel and determining the type of each MOF element read in the preceding step. After this, a translation process is selected for the type determined in the preceding step; and, the process selected in the preceding step is executed. 
     Still other objects, features and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein is shown and described only the preferred embodiment of the invention, simply by way of illustration of the best mode contemplated of carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive, and what is intended to be protected by Letters Patent is set forth in the appended claims. The present invention will become apparent when taken in conjunction with the following description and attached drawings, wherein like characters indicate like parts, and which drawings form a part of this application. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram of a computer system that may employ the method of the present invention. 
     FIG. 2 is an overall flow chart of the method of the present invention. 
     FIG. 3 is flow chart of the process for translating a MOF package into a UML model. 
     FIG. 4 is a flow chart of the process for translating a MOF Import to a UML Element Import. 
     FIG. 5 is a flow chart of the process for translating a MOF Class to a UML Class. 
     FIGS. 6A and 6B combined form a flow chart of the process for translating a MOF Attribute to a UML Attribute. 
     FIG. 7 is a flow chart of the process for translating a MOF Reference into a UML &lt;&lt;reference&gt;&gt; Attribute. 
     FIG. 8 is a flow chart of the process for translating a MOF Operation into a UML Operation. 
     FIGS. 9A and 9B combined form a flow chart of the process for translating a MOF Operation Parameter into a UML Parameter. 
     FIG. 10 is a flow chart of the process for translating a MOF Exception to a UML Exception. 
     FIG. 11 is a flow chart of the process for translating a MOF Exception&#39;s Parameter to a UML Attribute. 
     FIG. 12 is a flow chart of the process for translating a MOF Association to a UML Association. 
     FIGS. 13A and 13B combined form a flow chart of the process for translating a MOF Association End to a UML Association. 
     FIG. 14 is a flow chart of the process for translating a MOF Data Type to a UML Data Type. 
     FIG. 15 is a flow chart of the process for translating a MOF Constant to a UML Data Value. 
     FIG. 16 is a flow chart of the process for translating a MOF Constraint to a UML Constraint. 
     FIG. 17 is a flow chart of the process for translating a MOF Tag to a UML Tagged Value. 
     FIG. 18 is a flow chart of the process for setting generalizable properties. 
     FIG. 19 is a flow chart of the process for setting Feature properties. 
     FIG. 20 is a flow chart of the process for setting element properties. 
    
    
     DETAILED DESCRIPTION OF ONE EMBODIMENT 
     Before proceeding with a description of the system and method of the present invention, a summary of Terminology used herein is provided, which may be helpful in understanding the disclosed embodiment. 
     An object is an abstract representation of a real-world concept or thing. For example, an object can be used to represent a customer account in a banking application. An object has features, which can be either an operation or a property. An operation defines an action that an object can perform, or an action that can be performed on the object. For example, “make withdrawal” could be defined as an operation on a customer account object. Properties indicate the state of an object. Every property of an object has a value, and it is the property values that define the state of the object. A property can be either an attribute or a reference. An attribute defines a value that is stored within the object. For example, “current account balance” could be an attribute of the customer account object. The numeric value for the customer&#39;s account balance would be stored in the customer account object. A reference is a link or pointer to another object, and implies a relationship to that other object. A reference is typically used when it is desired not to duplicate data. For example, the customer account object could store the customer&#39;s name and address as attributes. However, if the customer opened multiple accounts, the customer&#39;s name and address would appear in multiple account objects. Therefore, it is desirable to define a separate customer object and place the name and address as attributes of the customer object. The customer account object would then contain a reference to the customer object. 
     The prefix “meta” as used herein shall describe a relationship. For example, “metadata” describes data. In a similar fashion, a metaobject is an object that represents “metadata”; and, “metamodel” means a model that defines an abstract language for expressing other models. A “meta-metamodel” means a model that defines an abstract language for expressing metamodels. The relationship between a meta-metamodel and a metamodel is analogous to the relationship between a metamodel and a model. The term model is generally used herein to denote a description of something in the real world. The concept of a model is highly fluid, and depends upon one&#39;s point of view. For example, where one is building an entire system, a model may include all of the metadata for the system. On the other hand, others are only concerned with certain components (e.g. programs A and B) or certain kinds of detail (e.g. wiring diagrams) of the system. 
     Referring now to the drawings and FIG. 1 in particular, a block diagram of a computer system which may implement the method of the present invention is shown. A computer  12 , such as a PC, includes a memory  14  for storing such things as a UML Modeling Tool  16 . A MOF Server  18  may also be stored in the memory  14  and executed by the computer  12 . Within the MOF Server a MOF metamodel  19  is stored. By use of the present invention the MOF metamodel is translated to a UML model  20  for display by the UML Modeling Tool  16 . 
     Referring now to FIG. 2, a flow chart of the overall process of the present invention is shown. The process begins with a start bubble  22 , followed by a step of reading each element of the MOF metamodel  19  (block  23 ). Next, a determination is made of the type of each MOF element within the metamodel (block  24 ) and a process is selected for the type determined in the preceding step (block  25 ). After this, the process selected is executed for each element (block  26 ) and the process ends (bubble  27 ). 
     Referring now to FIG. 3, the process for translating a MOF Package into a UML Model is shown. The process begins with a start bubble  30  followed by a step of creating a UML Model with a stereotype of &lt;&lt;metamodel&gt;&gt; (block  31 ). Next, generalizable properties are set (block  32 ), which process is illustrated in FIG.  18  and amplified hereinbelow. After this, a determination is made as to whether or not the MOF Package contains clustered imports (diamond  33 ). If the answer to this inquiry is yes, then a “clusteredImport” Tagged Value is created on the UML Model naming each clustered import (block  34 ). On the other hand, if the answer to the inquiry depicted by the diamond  33  is no, or upon completion of the step depicted by the block  34 , a “hasImplicitReferences” Tagged Value is created with a value of FALSE on the UML model (block  35 ), and then the process ends (bubble  36 ). 
     Referring now to FIG. 4, a flow chart of the process for translating a MOF Import into a UML Element Import is shown. The process begins with a start bubble  40  followed by a step of creating a UML Element Import (block  41 ). Next, an inquiry is made as to whether or not the Import&#39;s name is the same as the imported element&#39;s name (diamond  42 ). If the answer to this inquiry is no, then the Element Import&#39;s alias is set to Import&#39;s name (block  43 ). On the other hand, if the answer to this inquiry is yes, or upon completion of the step depicted by the block  43 , the Element Import&#39;s visibility is set to the Import&#39;s visibility (block  44 ). After this, the Element Import&#39;s imported element is set to correspond to Import&#39;s imported (block  45 ). The Element Import&#39;s package is then set to correspond to the Import&#39;s container (block  46 ) and the process ends (bubble  47 ). 
     Referring now to FIG. 5, the process for translating a MOF Class to a UML Class is shown. The process begins with a start bubble  50  followed by a step of creating a UML class (block  51 ). Next, generalizable properties are set (block  52 ), which step is illustrated in FIG.  18  and amplified hereinbelow. After this, an inquiry is made as to whether or not MOF class has isSingleton=TRUE (diamond  53 ). If the answer to this inquiry is yes, then an “isSingleton” Tagged Value is created with a value of TRUE on the UML class (block  54 ). On the other hand, if the answer to the inquiry is no, or upon completion of the step depicted by the block  54 , the process ends (bubble  55 ). 
     Referring now to FIG. 6A, the first of a two-sheet drawing of the process for translating a MOF Attribute to a UML Attribute is shown. The process begins with a start bubble  57  followed by a step of creating a UML Attribute (block  58 ). Next, Feature properties are set (block  59 ), which is illustrated in FIG.  19  and will be amplified hereinbelow. After this, UML Attribute&#39;s type is set to correspond to MOF Attribute&#39;s type (block  60 ) and UML Attribute&#39;s multiplicity range is set from MOF Attribute&#39;s multiplicity (block  61 ). An inquiry is next made as to whether or not MOP Attribute&#39;s multiplicity has isUnique=TRUE (diamond  62 ). If the answer to this inquiry is yes, then an “isUnique” Tagged Value is created on the UML Attribute with a value of TRUE (block  63 ). On the other hand, if the answer to this inquiry is no, or upon completion of the step depicted by the block  63 , a branch is made to FIG. 6B as denoted by a connector A. 
     Referring now to FIG. 6B at the connector A, an inquiry is made as to whether or not MOF attribute&#39;s multiplicity has isOrdered=TRUE (diamond  64 ). If the answer to this inquiry is yes, then an “isOrdered” Tagged Value is created on the UML Attribute with a value of TRUE (block  65 ). On the other hand, if the answer to this inquiry is no, or upon completion of the step depicted by the block  65 , another inquiry is made as to whether or not the MOF Attribute has isChangeable=TRUE (diamond  66 ). If the answer to this inquiry is yes, then the UML Attribute&#39;s changeability is set to changeable (block  67 ). On the other hand, if the answer to the inquiry depicted by the diamond  66  is no, then the UML Attribute&#39;s changeability is set to frozen (block  68 ). Upon completion of this step, or the step depicted by the block  67 , yet another inquiry is made as to whether or not the MOF Attribute has isDerived=TRUE (diamond  69 ). If the answer to this inquiry is yes, then an “isDerived” Tagged Value is created on the UML Attribute with a value of TRUE (block  70 ). If the answer to the inquiry depicted by the diamond  69  is no, or upon completion of the step depicted by the block  70 , the process ends (bubble  71 ). 
     Referring now to FIG. 7, a flow chart of the process for translating a MOF Reference into a UML &lt;&lt;reference&gt;&gt; Attribute is shown. The process begins with a start bubble  75  followed by a step of creating a UML Attribute with stereotype of &lt;&lt;reference&gt;&gt; (block  76 ). Next, Feature properties are set (block  77 ), which is illustrated in FIG.  19  and will be amplified hereinbelow. After this, the UML Attribute&#39;s type is set to correspond to the MOF Reference&#39;s type (block  78 ). An inquiry is then made as to whether or not the MOF Attribute&#39;s ischangeable equals TRUE (diamond  79 ). If the answer to this inquiry is yes, the UML Attribute&#39;s changeability is set to changeable (block  80 ). On the other hand, if the answer to this inquiry is no, then the UML Attribute&#39;s changeability is set to frozen (block  81 ). Upon completion of the step depicted by the block  80  or block  81 , another inquiry is made as to whether or not the Reference&#39;s name is the same as its referencedEnd&#39;s name (diamond  82 ). If the answer to this inquiry is no, a “referencedEnd” Tagged Value is created on the UML Attribute with its value set to the referencedEnd&#39;s name (block  83 ). On the other hand, if the answer to this latter inquiry is yes, or upon completion of the step depicted by the block  83 , the process ends (bubble  84 ). 
     Referring now to FIG. 8, a flow chart of the process for translating a MOF Operation into a UML Operation is shown. The process begins with a start bubble  86  followed by a step of creating a UML Operation (block  87 ). Next, Feature properties are set (block  88 ), which is illustrated in FIG.  19  and will be amplified hereinbelow. After this, the UML Operation&#39;s isQuery is set to the MOF Operation&#39;s isQuery (block  89 ) and the UML Operation&#39;s raisedSignal is set to correspond to the MOF Operation&#39;s exceptions (block  90 ); and the process ends (bubble  91 ). 
     Referring now to FIG. 9A, the first of a two-sheet illustration of the flow chart of the process for translating a MOF Operation&#39;s Parameter into a UML Parameter. The process begins with a start bubble  94  followed by a step of creating a UML Parameter (block  95 ). Next, Element properties are set (block  96 ), which is illustrated in FIG.  20  and will be amplified hereinbelow. After this, the UML Parameter&#39;s behavioralFeature is set to correspond to the MOF Parameter&#39;s container (block  97 ); and, the UML Parameter&#39;s type is set to correspond to the MOF Parameter&#39;s type (block  98 ). Then, the UML Parameter&#39;s kind is set to match the MOF Parameter&#39;s direction (block  99 ). The process illustration continues in FIG. 9B as denoted by a connector B. 
     Referring now to FIG. 9B at the connector B, an inquiry is made as to whether or not the MOF Parameter&#39;s multiplicity range is other than “1 . . . 1” (diamond  100 ). If the answer to this inquiry is yes, then a “multiplicity” Tagged Value is created on the UML Parameter showing the MOF Parameter&#39;s multiplicity (block  101 ). On the other hand, if the answer to this inquiry is no, or upon completion of the step depicted by the block  101 , another inquiry is made as to whether or not the MOF Parameter&#39;s multiplicity has isUnique set to TRUE (diamond  102 ). If the answer to this inquiry is yes, then an “isUnique” Tagged Value is created on the UML -Parameter with a value of TRUE (block  103 ). On the other hand, if the answer to this inquiry is no, or upon completion of the step depicted by the block  103 , yet another inquiry is made as to whether not the MOF Parameter&#39;s multiplicity has isordered set equal to TRUE (diamond  104 ). If the answer to this inquiry is yes, then an “isordered” Tagged Value is created on the UML Parameter with a value of TRUE (block  105 ). On the other hand, if the answer to this latter inquiry is no, or upon completion of the step depicted by the block  105 , the process ends (bubble  106 ). 
     Referring now to FIG. 10, the process for translating a MOF Exception to a UML Exception is shown the process begins with a start bubble  110  followed by a step of creating a UML Exception (block  111 ). Next, the Element properties are set (block  112 ), which is illustrated in FIG.  20  and further amplified hereinbelow. After this the process ends (bubble  113 ). 
     Referring now to FIG. 11, a flow chart of the process for translating a MOF Exception&#39;s Parameter to a UML Exception&#39;s Attribute is shown. The process begins with a start bubble  115 , followed by a step of creating a UML Attribute (block  116 ). Next, the Element properties are set (block  117 ), which is illustrated in FIG.  20  and will be amplified hereinbelow. After this, the Attribute&#39;s owner is set to be the UML Exception (block  118 ); and, the Attribute&#39;s type is set to correspond to the MOF Parameter&#39;s type (block  119 ). The Attribute&#39;s multiplicity range is then set from the MOF Parameter&#39;s multiplicity (block  120 ). An inquiry is next made as to whether or not the MOF Parameter&#39;s multiplicity has isUnique set equal to TRUE (diamond  121 ). If the answer to this inquiry is yes, then an “isUnique” Tagged Value is created on the Attribute with a value of TRUE (block  122 ). 
     If the answer to the inquiry depicted by the diamond  121  is no, or upon completion of the step depicted by the block  122 , another inquiry is made as to whether or not the MOF Parameter&#39;s multiplicity has isOrdered set equal to TRUE (diamond  123 ). If the answer to this inquiry is yes, then an “isOrdered” Tagged Value is crated on the Attribute with a value equal to TRUE (block  124 ). On the other hand, if the answer to this latter inquiry is no, or upon completion of the step depicted by the block  124 , the process ends (bubble  125 ). 
     Referring now to FIG. 12, the flow chart of the process of translating a MOF Association to a UML Association is shown. The process begins with a start bubble  128  followed by a step of creating a UML Association (block  129 ). Next, generalizable properties are set (block  130 ), which is illustrated in FIG.  18  and will be amplified hereinbelow. After this the process ends (bubble  131 ). 
     Referring now to FIG. 13A, the first sheet of a two-sheet flow chart of the process for translating a MOF Association End to a UML Association End is shown. The process begins with a start bubble  133  followed by a step of creating a UML AssociationEnd (block  134 ). Next, Element properties are set (block  135 ), which is illustrated in FIG.  20  and will be amplified hereinbelow. After this, the UML Association End&#39;s association is set to MOF Association End&#39;s container (block  136 ); and, the UML Association End&#39;s type is set to correspond to the MOF Association End&#39;s type (block  137 ). The UML Association End&#39;s multiplicity range is then set from the MOF Association End&#39;s multiplicity (block  138 ). An inquiry is next made as to whether or not the MOF Association End&#39;s multiplicity has isOrdered set equal to TRUE (diamond  139 ). If the answer to this inquiry is yes, then the UML Association End&#39;s ordering is set to ordered (block  140 ). On the other hand, if the answer to the inquiry depicted by the diamond  139  is no, or upon completion of the step depicted by the block  140 , the process illustration continues in FIG. 13B as denoted by a connector C. 
     Referring now to FIG. 13B at the connector C, the UML Association End&#39;s aggregation is set to the MOF Association End&#39;s aggregation (block  141 ). Next, the UML Association End&#39;s isNavigable is set to the MOF Association End&#39;s isNavigable (block  142 ). After this, an inquiry is made as to whether or not the MOF Association End has ischangeable set equal to TRUE (diamond  143 ). If the answer to this inquiry is yes, then the UML Association End&#39;s changeability is set to changeable (block  144 ). On the other hand, if the answer to this inquiry is no, then the UML Association End&#39;s changeability is set to frozen (block  145 ). Upon completion of the step depicted by the block  144  or the block  145  the process ends (bubble  146 ). 
     Referring now to FIG. 14, a flow chart of the process for translating a MOF Data Type to a UML Data Type is shown. The process begins with a start bubble  148  followed by a step of creating a UML Data Type (block  149 ). Next, the generalizable properties are set (block  150 ), which is illustrated in FIG.  20  and will be amplified hereinbelow. After this, an inquiry is made as to whether or not the MOF Datatype&#39;s typeCode is a predefined CORBA type (diamond  151 ). If the answer to this inquiry is yes, then a “corbaType” Tagged Value is created on the UML Data Type with its value set to the name of the CORBA type (block  152 ). 
     If the answer to the inquiry depicted by the diamond  151  is no, then a “corbaType” Tagged Value is created on the UML Data type with its value set to a CORBA IDL type declaration (block  153 ). Next, another inquiry is made as to whether or not typecode contains a repository identifier (diamond  154 ). If the answer to this inquiry is yes, then a “repositoryId” Tagged Value is created on the UML Data Type with its value set to the identifier (block  155 ). Upon completion of the step depicted by the block  152  or the block  155 , or if the answer to the inquiry depicted by the diamond  154  is no, the process ends (bubble  156 ). 
     Referring now to FIG. 15, a flow chart of the process for translating a MOF Constant to a UML Data Value is shown. The process begins with a start bubble  158  followed by a step of creating a UML Data Value (block  159 ). The Element properties are then set (block  160 ), which is illustrated in FIG.  20  and will be amplified hereinbelow. Next, the Data Value&#39;s classifier is set to correspond to the MOF Constant&#39;s type (block  161 ); and, a “constantvalue” Tagged Value is created with its value set to the MOF Constant&#39;s value (block  162 ). Finally, the process ends (bubble  163 ). 
     Referring now to  16 , a flow chart of the process for translating a MOF Constraint to a UML Constraint is shown. The process begins with a start bubble  165  followed by a step of creating a UML Constraint (block  166 ). Next, the Element properties are set (block  167 ), which is illustrated in FIG.  20  and will be amplified hereinbelow. After this, the UML Constraint&#39;s body is set to the MOF Constraint&#39;s expression and language (block  168 ); and, an “evaluationpolicy” Tagged Value is created with its value set to the MOF Constraint&#39;s evaluationpolicy (either “immediate” or “deferred”) (block  169 ). The UML Constraint&#39;s constrainedElement is then set to correspond to the MOF&#39;s Constraint&#39;s constrainedElement (block  170 ) and the process ends (bubble  171 ). 
     Referring now to FIG. 17, a flow chart of the process for translating a MOF Tag to a UML Tagged Value is shown. The process begins with a start bubble  174  followed by a step of creating one UML Tagged Value for each of the MOF Tag&#39;s elements (block  175 ). Next, each Tagged Value&#39;s modelElement is set to correspond to a different one of the MOF Tag&#39;s elements (block  176 ). After this, each Tagged Value&#39;s tag is set to the MOF Tag&#39;s tagId (block  177 ). Each Tagged Value&#39;s value is set to the MOF Tag&#39;s value (converting to type string if needed) (block  178 ) and the process ends (bubble  179 ). 
     Referring now to FIG. 18, the flow chart of the process for setting generalizable properties is shown. The process begins with a start bubble  182  followed by a step of setting element properties, which is illustrated in FIG.  20  and will be amplified hereinbelow. Next, the UML element&#39;s isAbstract, isRoot, and isLeaf are set from the MOF element (block  184 ). After this, an inquiry is made as to whether or not the MOF element has supertypes (diamond  185 ). If the answer to this inquiry is yes, then a UML generalization is created for each MOF supertype (block  186 ). Each UML generalization is next made for each MOF supertype (block  186 ; and, each UML generalization is made an ownedElement of the containing UML model (block  187 ). On the other hand, if the answer to the inquiry depicted by the diamond  185  is no, or upon completion of the step depicted by the block  187 , the UML element&#39;s namespace is set to correspond to the MOF element&#39;s container (block  188 ) and the process ends (bubble  189 ). 
     Referring now to FIG. 19, a flow chart of the process for setting Feature properties is shown. The process begins with a start bubble  192  followed by a step of setting element properties (block  193 ), which is illustrated in FIG.  20  and will be amplified hereinbelow. Next, the UML Feature&#39;s ownerScope is set to match the MOP Feature&#39;s scope (block  194 ); and, the UML feature&#39;s owner is set to correspond to the MOF feature&#39;s container (block  195 ); after which the process ends (bubble  196 ). 
     Referring now to FIG. 20, a flow chart of the process for setting element properties is shown. The process begins with a start bubble  200  followed by a step of setting the UML element&#39;s name from the MOF element&#39;s name (block  201 ). Next, an inquiry is made as to whether or not the MOF element has an annotation (diamond  202 ). If the answer to this inquiry is yes, then a “documentation” Tagged Value is created on the UML element with the MOF element&#39;s annotation as its value (block  203 ). On the other hand, if the answer to this inquiry is no, or upon completion of the step depicted by the block  203 , another inquiry is made as to whether or not the MOF element has a visibility attribute (diamond  204 ). If the answer to this inquiry is yes, then the UML element&#39;s visibility is set to the MOF element&#39;s visibility (block  205 ). On the other hand, if the answer to this latter inquiry is no, then the UML element&#39;s visibility is set to public (block  206 ). Upon completion of the step depicted by the block  205  or the block  206 , the process ends (bubble  207 ). 
     The methods and apparatus of the present invention, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMS, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. The methods and apparatus of the present invention may also be embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates analogously to specific logic circuits. 
     Although the invention has been described with reference to a specific embodiment, this description is not meant to be construed in a limiting sense. Various modifications of the disclosed embodiment as well as alternative embodiments of the invention will become apparent to one skilled in the art upon reference to the description of the invention. It is therefore contemplated that the appended claims will cover any such modifications of embodiments that fall within the true scope of the invention.