ادامه 13.1.5 Package - از Profiles

Associations

• profileApplication: ProfileApplication[*] - ProfileApplicationهایی را ارجاع می‌دهد که نشان می‌دهند چه Profileهایی روی Package اعمال شده‌اند. زیرمجموعه Element::ownedElement است.

Constraints

Constraint اضافی ندارد.

Semantics

Association به نام appliedProfile میان Package و Profile از meta-levelها عبور می‌کند: یک Element از Model - نوعی Package - را به Elementی از metamodel آن متصل می‌کند و مجموعه Profileهایی را نمایش می‌دهد که Extensionهای قابل اعمال بر Package را تعریف می‌کنند. هرچند چنین وضعیتی در UML metamodel نادر است، صرفاً نشان می‌دهد Model و metamodel می‌توانند در یک space هم‌زیستی داشته باشند و بین آن‌ها Link برقرار شود.

Notation

نمادگذاری اضافی ندارد.

Changes from previous UML

در UML 1.4 امکان نشان‌دادن اینکه چه Profileهایی روی یک Package اعمال شده‌اند وجود نداشت.

13.1.6 Profile - از Profiles

Profile Extensionهای محدودی برای یک reference metamodel تعریف می‌کند تا آن metamodel با platform یا domain مشخصی تطبیق داده شود.

Generalizations

• InfrastructureLibrary::Constructs::Package

Description

Profile نوعی Package است که reference metamodel را توسعه می‌دهد. Construct اصلی Extension، Stereotype است که به‌عنوان بخشی از Profiles تعریف می‌شود.

Profile از طریق metaclassهای تعریف‌شده در این Package چند Constraint یا restriction بر metamodeling عادی وارد می‌کند.

Profile شکل محدودشده‌ای از metamodel است که باید همیشه با یک reference metamodel مانند UML مرتبط باشد. Profile بدون reference metamodel خود قابل استفاده نیست و قابلیت محدودی برای توسعه metaclassهای reference metamodel تعریف می‌کند. Extensionها به‌صورت Stereotypeهایی تعریف می‌شوند که روی metaclassهای موجود اعمال می‌شوند.

Attributes

Attribute اضافی ندارد.

Associations

• metaclassReference: ElementImport[*] - metaclassای را ارجاع می‌دهد که ممکن است توسعه یابد. زیرمجموعه Package::elementImport است.
• metamodelReference: PackageImport[*] - Packageای را ارجاع می‌دهد که مستقیم یا غیرمستقیم metaclassهای قابل توسعه را دربر دارد. زیرمجموعه Package::packageImport است.
• /ownedStereotype: Stereotype[*] - Stereotypeهایی را ارجاع می‌دهد که Profile مالک آن‌هاست. زیرمجموعه Package::packagedElement است.

Constraints

[1] Elementی که به‌عنوان metaclassReference import شده در Profile specialization یا generalization نمی‌شود.

self.metaclassReference.importedElement->
    select(c | c.oclIsKindOf(Classifier) and
    (c.generalization.namespace = self or
    (c.specialization.namespace = self) )->isEmpty()

[2] همه Elementهایی که به‌عنوان metaclassReference یا از طریق metamodelReference import شده‌اند memberهای همان base reference metamodel هستند.

self.metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages())->
    union(self.metaclassReference.importedElement.allOwningPackages() )->notEmpty()

Additional Operations

[1] Query allOwningPackages() همه Packageهای مالک مستقیم یا غیرمستقیم را برمی‌گرداند.

NamedElement::allOwningPackages(): Set(Package)
allOwningPackages = self.namespace->select(p | p.oclIsKindOf(Package))->
    union(p.allOwningPackages())

Semantics

Profile طبق تعریف یک reference metamodel را توسعه می‌دهد. تعریف Profile مستقل که مستقیماً یا غیرمستقیم metamodel موجودی را توسعه ندهد ممکن نیست. Profile mechanism را می‌توان با هر metamodel ساخته‌شده از MOF، از جمله UML و CWM، استفاده کرد.

Reference metamodel معمولاً از metaclassهایی تشکیل می‌شود که یا import شده‌اند یا به‌صورت محلی owned هستند. همه metaclassهایی که Profile توسعه می‌دهد باید memberهای همان reference metamodel باشند. ElementImportهای metaclassReference و PackageImportهای metamodelReference دو هدف دارند: نخست، Elementهای reference metamodel را که Profile import می‌کند مشخص می‌کنند؛ دوم، filtering ruleهای Profile را تعیین می‌کنند. Filtering ruleها مشخص می‌کنند هنگام اعمال Profile کدام Elementهای metamodel visible و کدام hidden هستند. اعمال Profile به هیچ شکل underlying Model را تغییر نمی‌دهد؛ فقط viewای از آن Model تعریف می‌کند.

به‌طور کلی هنگام اعمال Profile فقط ModelElementهایی visible هستند که instance metaclassهای importشده reference باشند. سایر metaclassها hidden می‌شوند. به‌طور پیش‌فرض ModelElementهایی که metaclass آن‌ها public و تحت مالکیت reference metamodel است visible هستند. طبق قواعد پیش‌فرض PackageImport این قاعده به‌صورت transitive بر Subpackageهای reference metamodel نیز اعمال می‌شود. اگر metaclassای با ElementImport مربوط به metaclassReference import شود، ModelElementهایی که metaclass آن‌ها همان metaclass است visible خواهند بود.

بااین‌حال metaclassReference هرگاه Element یا Packageای از metamodel referenced هم‌زمان توسط metaclassReference نیز reference شود، بر metamodelReference override دارد. در این موارد فقط Elementهایی که صریحاً توسط metaclassReference reference شده‌اند visible خواهند بود و همه Elementهای دیگر آن metamodel Package hidden خواهند شد.

برای تعیین visible یا hidden بودن ModelElement هنگام اعمال Profile قواعد زیر استفاده می‌شوند. ModelElementها زمانی visible هستند که instance metaclassهایی باشند که:

1. توسط یک MetaclassReference صریح reference شده‌اند؛ یا
2. به‌طور مستقیم یا transitive در Packageای قرار دارند که یک MetamodelReference صریح به آن reference دارد، مگر اینکه Elementهای دیگری از Subpackageهای آن Package به‌طور صریح توسط MetaclassReference reference شده باشند؛ یا
3. توسط Stereotype تحت مالکیت Profile اعمال‌شده توسعه یافته‌اند، حتی اگر خود metaclass توسعه‌یافته visible نباشد.

همه ModelElementهای دیگر هنگام اعمال Profile hidden هستند.

رایج‌ترین حالت این است که Profile کل metamodel را با یک MetamodelReference import کند. در این حالت همه Elementهای metamodel visible هستند.

در مثال شکل 13.8، MyMetamodel شامل دو metaclass به نام‌های Metaclass1 و Metaclass2 است. MyProfile Profileای است که MyMetamodel و Metaclass2 را reference می‌کند. MetaclassReference صریح به Metaclass2 بر metamodelReference override دارد. اعمال MyProfile روی Model مبتنی بر MyMetamodel، instanceهای Metaclass2 را visible می‌کند، زیرا متaclassReference صریح دارد. همچنین instanceهای Metaclass1 که با instance از MyStereotype توسعه یافته‌اند visible خواهند بود، اما instanceهای Metaclass1 که MyStereotype آن‌ها را توسعه نداده hidden می‌مانند.

اگر Profile P1، Profile دیگری به نام P2 را import کند، همه Associationهای metaclassReference و metamodelReference در level مربوط به P2 ترکیب می‌شوند و filtering ruleها روی union آن‌ها اعمال می‌شوند.

Filtering ruleهایی که در level Profile تعریف می‌شوند در اصل پیشنهادهایی برای modeling toolها درباره رفتار هنگام اعمال Profile روی Model هستند.

Attribute isStrict روی ProfileApplication مشخص می‌کند filtering ruleها باید به‌صورت strict اعمال شوند. اگر isStrict=true باشد، هنگام اعمال Profile روی Model هیچ metaclass دیگری جز metaclassهای accessible تعریف‌شده توسط Profile نباید قابل دسترسی باشد. این وضعیت ترکیب applied profileهایی را که accessible metaclassهای متفاوت مشخص می‌کنند ممنوع می‌کند.

افزون بر import و filtering mechanismها، طراح Profile می‌تواند metamodel مناسب را با انتخاب Subpackageهای مناسب و استفاده از PackageMerge مشخص کند. برای مثال می‌توان با merge کردن Packageها و Classهای UML2 Superstructure یا import کردن Packageها از یکی از UML2 compliance packageهای L0 تا L4 یک reference metamodel خاص ساخت.

Stereotypeها می‌توانند در Association شرکت کنند. Class مقابل می‌تواند Stereotype دیگری، Class غیرStereotype تحت مالکیت Profile یا metaclassای از reference metamodel باشد. در چنین Associationهایی باید Propertyای تحت مالکیت Stereotype وجود داشته باشد که به Class مقابل navigable باشد. Property مقابل باید تحت مالکیت خود Association باشد، نه Class یا metaclass دیگر.

مستقیم‌ترین implementation از Profile mechanism، implementation مبتنی بر metamodel و مشابه Profile metamodel است. بااین‌حال استاندارد فعلی چنین implementationی را الزام نمی‌کند و فقط پشتیبانی از مفاهیم مشخص‌شده و قابلیت interchange استاندارد مبتنی بر XMI را لازم می‌داند. Profile mechanism طوری طراحی شده که ابزارهای بدون implementation مبتنی بر metamodel نیز بتوانند آن را پیاده‌سازی کنند. عملاً هر سازوکاری برای اتصال valueهای جدید به ModelElementها می‌تواند implementation معتبر Profile باشد. برای مثال UML 1.4 Profile metamodel می‌تواند مبنای implementation ابزاری سازگار با UML 2.0 Profile باشد.

استفاده از XMI برای exchange Profileها

Profile یک instance از UML2 metamodel است، نه CMOF metamodel. بنابراین قواعد mapping از MOF به XMI مستقیماً بر instanceهای Profile اعمال نمی‌شوند. شکل 13.4 در صفحه 183 نمونه mapping میان UML2 Profile و CMOF Model معادل را نشان می‌دهد. این mapping برای توضیح و رسمی‌کردن روش serialization و exchange Profileها با XMI استفاده می‌شود. با استفاده از Profile-to-CMOF mapping می‌توان قواعد CMOF-to-XMI را به‌طور غیرمستقیم برای مشخص‌کردن mapping از Profile به XMI به‌کار گرفت.

در این mapping:

• Profile به CMOF Package map می‌شود.
• metaclass یعنی Extension::Class یک instance از MOF Class است؛ Extension::Class به خودش map می‌شود، یعنی Class در Profile همان Class در CMOF Model متناظر است و mapping یک identity transformation است.
• Stereotype به MOF Class با همان نام و Propertyها map می‌شود.
• Extension به Association مطابق بخش Semantics مربوط به Profile::Class در صفحه 181 map می‌شود.

Profile-to-CMOF mapping باید valueهایی برای CMOF Tagها روی CMOF Package متناظر با Profile نیز داشته باشد تا XMI generation کنترل شود. Specification دقیق این Tagها یک semantic variation point است. Convention پیشنهادی:

nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

که در آن:

• <profileParentQualifiedName> qualified name مربوط به Package شامل Profile - در صورت وجود - است؛ :: با dot جایگزین و سایر characterهای غیرمجاز XML QName حذف می‌شوند.
• <profileName> نام Profile است.
• nsPrefix = <profileName>
• همه موارد دیگر از defaultهای XMI استفاده می‌کنند.

Profile می‌تواند مانند هر Model دیگری به‌صورت XMI schema definition exchange شود و Modelهایی که توسط Profile توسعه یافته‌اند نیز قابل interchange هستند.

شکل 13.6 در صفحه 184 Stereotype Home را نشان می‌دهد که UML2 metaclass Interface را توسعه می‌دهد. شکل 13.4 در صفحه 183 correspondence آن در MOF را با معرفی Association از MOF Class مربوط به Home به MOF Class مربوط به Interface نشان می‌دهد. برای نمونه، Propertyای به نام magic:String - معادل tagged value definition در UML1.4 - به Stereotype Home افزوده می‌شود.

Serialization اول در منبع نشان می‌دهد Model مربوط به شکل 13.5 - که instance Profile و UML2 metamodel است - چگونه exchange می‌شود. کد منبع بدون ترجمه و تغییر حفظ شده است:

<?xml version="1.0" encoding="UTF-8"?>
<uml:Profile xmi:version="2.1"
  nsURI="http://HomeExample.xml"
  nsPrefix="HomeExample"
  xmlns:uml="http://schema.omg.org/spec/UML/2.0/uml.xml"
  xmi:id="id0" name="HomeExample" metamodelReference="id2">

 <packageImport xmi:id="id2">
  <importedPackage href="http://schema.omg.org/spec/UML/2.0/uml.xml"/>
 </packageImport>

 <ownedMember xmi:type="uml:Stereotype" xmi:id="id3" name="Home">
  <ownedAttribute xmi:type="uml:Property" xmi:id="id5" name="base_Interface" association="id6">
   <type href="http://schema.omg.org/spec/UML/2.0/uml.xml#Interface"/>
  </ownedAttribute>
  <ownedAttribute xmi:type="uml:Property" xmi:id="id4" name="magic">
   <type href="http://schema.omg.org/spec/UML/2.0/uml.xml#String"/>
  </ownedAttribute>
 </ownedMember>

 <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home"
  memberEnd="id4 id5">
  <ownedEnd
          xmi:type="uml:ExtensionEnd"
          xmi:id="id7"
          name="extension_Home" type="id3"
          isComposite="true" lower="0" upper="1">
  </ownedEnd>
 </ownedMember>
</uml:Profile>

در ادامه منبع یک XMI definition از Profile «HomeExample» شرح می‌دهد. این XMI description در XML تعیین می‌کند Modelهای توسعه‌یافته توسط HomeExample چگونه در XMI exchange شوند. XMI schemaای جدا از UML2 schema استاندارد حاصل می‌شود و در فایلی به نام HomeExample.xmi ذخیره می‌گردد. کد منبع حفظ شده است:

<?xml version=”1.0” encoding=”UTF-8”?>
<xsd:schema targetNamespace =
           “http://www.mycompany.com/schemas/HomeExample.xmi”
           xmlns:xmi=”http://schema.omg.org/spec/XMI/2.1”
           xmlns:uml=”http://schema.omg.org/spec/UML/2.1.1”
           xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

           <xsd:import namespace=”http://schema.omg.org/spec/XMI/2.1” schemaLocation=”XMI.xsd”/>
           <xsd:import namespace=”http://schema.omg.org/spec/UML/2.0” schemaLocation=”UML21.xsd”/>
           <xsd:complexType name=”Home”>
               <xsd:choice minOccurs=”0” maxOccurs =”unbounded”>
                      <xsd:element name=”base_Interface” type=”xmi:Any”/>
                      <xsd:element name=”magic” type=”xsd:string”/>
                      <xsd:element ref=”xmi:Extension”/>
               </xsd:choice>
               <xsd:attribute ref=”xmi:id”/>
               <xsd:attributeGroup ref=”xmi:ObjectAttribs”/>
               <xsd:attribute name=”base_Interface” type=”uml:Interface”
               <xsd:attribute name=”magic” type=”xsd:string” use=”optional”/>
               use=”optional”/>
           </xsd:complexType>
           <xsd:element name=”Home” type=”Home”/>
</xsd:schema>

شکل 13.9 یک Model نمونه را نشان می‌دهد که شامل instance از Interface به نام Client است و با Stereotype Home توسعه یافته است.

کد XMI بعدی نحوه serialization این Model توسعه‌یافته با Profile را نشان می‌دهد. ابزاری که XMI file را import می‌کند اگر definition مربوط به schema یا Profile HomeExample را نداشته باشد می‌تواند Elementهای مربوط به آن را filter کند. کد منبع حفظ شده است:

<?xml version=”1.0” encoding=”UTF-8”?>
<xmi xmi:version=”2.1”
  xmlns:xmi=”http://schema.omg.org/spec/XMI/2.1”
  xmlns:uml=”http://schema.omg.org/spec/UML/2.1.1”
  xmlns:HomeExample=”http://www.mycompany.com/schemas/HomeExample.xmi”>

 <uml:Package xmi:id=”id1” name=”ClientPackage”>
  <profileApplication xmi:id=”id3”>
     <appliedProfile href=”HomeExample.xmi#id0”/>
  </profileApplication>

  <ownedMember xmi:type=”uml:Interface” xmi:id=”id2” name=”Client”/>
 </uml:Package>

 <!-- applied stereotypes -->
 <HomeExample:Home xmi:id= “id4” base_Interface=”id2” magic=”1234”/>
</xmi>

Notation

Profile همان نمادگذاری Package را دارد، با این افزوده که keyword «profile» پیش یا بالای نام Package نمایش داده می‌شود. Profile::metaclassReference و Profile::metamodelReference به‌ترتیب همان نمادگذاری Package::elementImport و Package::packageImport را استفاده می‌کنند.

Examples

شکل 13.10 نمونه ساده‌ای از EJB Profile را نشان می‌دهد.

Profile مشخص می‌کند Stereotype انتزاعی Bean باید به‌صورت required روی metaclass Component اعمال شود؛ یعنی instance یکی از Subclassهای عینی Entity یا Session از Bean باید به هر instance Component link باشد. Constraintهایی که بخشی از Profile هستند پس از اعمال Profile روی Package ارزیابی می‌شوند و برای well-formed بودن Model باید برقرار باشند.

شکل 13.11 import شدن Package Types از Profile Manufacturer را نشان می‌دهد. DataType Color به‌عنوان Type یکی از Propertyهای Stereotype Device استفاده می‌شود، همان‌طور که Type ازپیش‌تعریف‌شده String نیز استفاده شده است. Class JavaInteger نیز می‌تواند Type یک Property باشد.

اگر Profile Manufacturer بعداً روی Packageای اعمال شود، Typeهای Package Types نیز برای استفاده در آن Package در دسترس می‌شوند، زیرا Profile application نوعی import است. بنابراین برای مثال JavaInteger می‌تواند هم به‌عنوان metaproperty - بخشی از Stereotype Device - و هم Property معمولی - بخشی از Class TV - استفاده شود. شکل نشان می‌دهد هنگام اعمال Stereotype Device روی Class TV برای metaproperty مقدار تعیین می‌شود.

13.1.7 ProfileApplication - از Profiles

ProfileApplication برای نشان‌دادن این استفاده می‌شود که چه Profileهایی روی Package اعمال شده‌اند.

Generalizations

• InfrastructureLibrary::Constructs::Core::DirectedRelationship

Description

ProfileApplication نوعی DirectedRelationship است که قابلیت بیان اعمال‌شدن یک Profile روی Package را اضافه می‌کند.

Attributes

• isStrict: Boolean[1] = false - مشخص می‌کند آیا filtering ruleهای Profile برای metaclassهای reference metamodel باید به‌صورت strict اعمال شوند یا خیر. برای جزئیات بیشتر زیربخش Semantics از بخش Profile (from Profiles) در صفحه 187 را ببینید.

Associations

• importedProfile: Profile[1] - Profileهایی را ارجاع می‌دهد که از طریق این ProfileApplication روی Package اعمال شده‌اند. زیرمجموعه PackageImport::importedPackage است.
• applyingPackage: Package[1] - Packageای که ProfileApplication را در مالکیت دارد. {Subsets Element::owner and DirectedRelationship::source}.

Constraints

Constraint اضافی ندارد.

Semantics

یک یا چند Profile می‌توانند به‌دلخواه روی Packageای اعمال شوند که از همان metamodel توسعه‌یافته توسط Profile ساخته شده است. اعمال Profile یعنی استفاده از Stereotypeهای تعریف‌شده در Profile مجاز است، اما الزاماً required نیست. چند Profile را می‌توان هم‌زمان روی Package اعمال کرد، مشروط بر اینکه Constraintهای متعارض نداشته باشند. اگر Profile در حال اعمال به Profileهای دیگر وابسته باشد، آن Profileها باید ابتدا اعمال شوند.

هنگام اعمال Profile، برای Elementهایی که instance metaclassهای دارای required Extension هستند باید instance Stereotype مناسب ایجاد شود. بدون این instanceها Model well-formed نیست.

پس از اعمال Profile روی Package، می‌توان Profile اعمال‌شده را به‌دلخواه حذف کرد. حذف Profile ایجاب می‌کند همه Elementهایی که instance Elementهای تعریف‌شده در آن Profile هستند حذف شوند. Profile اعمال‌شده تا زمانی که Applied Profileهای وابسته به آن ابتدا حذف نشده باشند قابل حذف نیست.

یادداشت: حذف Applied Profile، instanceهای Elementهای reference metamodel را دست‌نخورده باقی می‌گذارد. فقط instanceهای Elementهای متعلق به Profile حذف می‌شوند. بنابراین برای مثال UML Model دارای Profile را همیشه می‌توان با ابزار دیگری که Profile را پشتیبانی نمی‌کند exchange کرد و آن ابزار همچنان می‌تواند Model را به‌عنوان UML Model خالص تفسیر کند.

Notation

نام Profileهای اعمال‌شده با پیکان dashed دارای open arrowhead از Package به Profile اعمال‌شده نشان داده می‌شود. Keyword «apply» نزدیک پیکان قرار می‌گیرد.

اگر چند Applied Profile دارای Stereotypeهای هم‌نام باشند، ممکن است لازم باشد نام Stereotype با نام Profile qualify شود.

Examples

با فرض وجود Profileهای Java و EJB، شکل 13.12 نشان می‌دهد هر دو روی Package WebShopping اعمال شده‌اند.

13.1.8 Stereotype - از Profiles

Stereotype تعریف می‌کند metaclass موجود چگونه می‌تواند توسعه یابد و اجازه می‌دهد terminology یا notation خاص platform یا domain به‌جای terminology/notation مربوط به metaclass توسعه‌یافته یا در کنار آن استفاده شود.

Generalizations

• InfrastructureLibrary::Constructs::Class

Description

Stereotype نوعی Class است که Classها را از طریق Extensionها توسعه می‌دهد.

مانند Class، Stereotype می‌تواند Property داشته باشد که ممکن است tag definition نامیده شوند. وقتی Stereotype روی ModelElement اعمال می‌شود، valueهای Propertyها ممکن است tagged value نامیده شوند.

Attributes

Attribute اضافی ندارد.

Associations

• icon: Image[*] - Stereotype می‌تواند با استفاده از Iconهای attached ظاهر گرافیکی ModelElement توسعه‌یافته را تغییر دهد. وقتی این Association خالی نباشد، location محتوای Icon را که باید در diagramهای نمایش‌دهنده ModelElementهای توسعه‌یافته نشان داده شود ارجاع می‌دهد.

Constraints

[1] Stereotype فقط می‌تواند Stereotype دیگری را generalize یا specialize کند.

generalization.general->forAll(e | e.oclIsKindOf(Stereotype)) and
generalization.specific->forAll(e | e.oclIsKindOf(Stereotype))

[2] نام Stereotype نباید با keyword name مربوط به ModelElement توسعه‌یافته clash داشته باشد.

Semantics

Stereotype نوع محدودی از metaclass است که به‌تنهایی قابل استفاده نیست و باید همیشه همراه یکی از metaclassهایی که توسعه می‌دهد استفاده شود. هر Stereotype می‌تواند درون Profile یک یا چند Class را از طریق Extension توسعه دهد. به همین ترتیب یک Class می‌تواند توسط یک یا چند Stereotype توسعه یابد.

Instance S از Stereotype نوعی meta-Class است. مرتبط‌کردن آن با metaclass C از reference metamodel - معمولاً UML - با یک Extension که نوع خاصی از Association است، نشان می‌دهد ModelElementهای Type C می‌توانند توسط instance از S توسعه داده شوند؛ شکل 13.13 را ببینید. در Model level، مانند شکل 13.18، instanceهای S با linkهایی به ModelElementهای C - یعنی instanceهای C - مرتبط می‌شوند. این linkها occurrenceهای Association/Extension از S به C هستند.

هر ModelElement از reference metamodel - هر UML ModelElement - می‌تواند توسط Stereotype توسعه یابد. برای مثال در UML، State، Transition، Activity، Use Case، Component، Attribute، Dependency و غیره همگی می‌توانند با Stereotype توسعه یابند.

Notation

Stereotype از همان نمادگذاری Class استفاده می‌کند، با این افزوده که keyword «stereotype» پیش یا بالای نام Class قرار می‌گیرد.

وقتی Stereotype روی ModelElement اعمال می‌شود - یعنی instance از Stereotype به instance از metaclass link می‌شود - نام Stereotype داخل یک جفت guillemet در بالا یا پیش از نام ModelElement نمایش داده می‌شود. اگر چند Stereotype اعمال شوند، نام Stereotypeهای اعمال‌شده به‌صورت فهرست comma-separated داخل یک جفت guillemet نشان داده می‌شود. اگر ModelElement توسعه‌یافته keyword داشته باشد، نام Stereotype نزدیک keyword و در guillemet جداگانه نشان داده می‌شود؛ برای مثال «interface» «Clock».

Presentation Options

اگر چند Stereotype روی Element اعمال شده باشند، می‌توان نام هر Stereotype را داخل guillemet جداگانه قرار داد و آن‌ها را پشت سر هم نمایش داد. ابزار می‌تواند تصمیم بگیرد Stereotypeها را نمایش دهد یا خیر. به‌ویژه برخی ابزارها ممکن است required stereotype را نمایش ندهند و فقط Attributeهای آن - یعنی tagged valueها - را در صورت وجود نشان دهند.

Valueهای Element دارای Stereotype را می‌توان به یکی از سه روش زیر نمایش داد:

• به‌عنوان بخشی از Comment symbol متصل به node گرافیکی نمایش‌دهنده ModelElement؛
• در compartmentهای جداگانه node گرافیکی مربوط به ModelElement؛
• بالای name string داخل node گرافیکی یا پیش از name string.

در حالتی که از compartment یا Comment symbol استفاده شود، علاوه بر درج نام Stereotype در compartment یا Comment، می‌توان نام Stereotype را در guillemet پیش از name string نیز نمایش داد.

Valueها به‌صورت name-value pair نمایش داده می‌شوند:

<namestring> '=' <valuestring>

اگر Stereotype Property چندمقداری باشد، <valuestring> به‌صورت فهرست comma-separated نمایش داده می‌شود:

<valuestring> ::= <value> [',' <value>]*

برخی valueها قواعد نمایش ویژه دارند:

• برای Boolean Propertyها، به‌عنوان جایگزین name-value pair، diagram می‌تواند از conventionی استفاده کند که اگر <namestring> نمایش داده شود value برابر True و اگر نمایش داده نشود value برابر False باشد.
• اگر value نام NamedElement باشد، به‌طور اختیاری می‌توان qualifiedName آن را استفاده کرد.

اگر برای نمایش Stereotype value از compartment استفاده شود، برای هر Stereotype اعمال‌شده‌ای که valueهای آن باید نمایش داده شوند یک compartment اضافی لازم است. Header هر compartment نام Applied Stereotype داخل guillemet است. هر node گرافیکی می‌تواند این compartmentها را داشته باشد.

درون Comment symbol یا هنگامی که valueها پیش یا بالای <namestring> symbol نمایش داده می‌شوند، valueهای مربوط به Stereotype مشخص می‌توانند با نام Applied Stereotype داخل guillemet آغاز شوند. این کار زمانی مفید است که valueهای بیش از یک Applied Stereotype باید نشان داده شوند.

در compartment یا Comment symbol حداکثر یک name-value pair در هر خط قرار می‌گیرد. وقتی pairها بالا یا پیش از <namestring> نمایش داده شوند، با semicolon از هم جدا می‌شوند و همه pairهای یک Stereotype در brace قرار می‌گیرند.

اگر Extension end نام داشته باشد، هنگام اعمال Stereotype روی ModelElement می‌توان آن نام را به‌جای نام Stereotype داخل guillemet استفاده کرد.

می‌توان notation مشخصی به Stereotype متصل کرد تا به‌جای notation مربوط به ModelElementی که Stereotype روی آن اعمال شده است استفاده شود.

Icon Presentation

وقتی Stereotype شامل تعریف Icon باشد، این Icon می‌تواند به‌شکل گرافیکی به ModelElementهای توسعه‌یافته توسط Stereotype متصل شود. هر ModelElement دارای presentation گرافیکی می‌تواند attached Icon داشته باشد. در حالت‌های زیر:

• Boxها - شکل 13.14: Box را می‌توان با Icon جایگزین کرد و نام ModelElement زیر Icon قرار می‌گیرد. این presentation فقط وقتی مجاز است که ModelElement توسط یک Stereotype واحد توسعه یافته و Propertyهای خود ModelElement - مانند Attribute و Operation کلاس - نمایش داده نشده باشند. گزینه دیگر این است که Icon به‌صورت کوچک‌شده داخل و بالای Box نمایش داده شود. اگر چند Stereotype اعمال شده باشند، چند Icon می‌توانند داخل Box نمایش داده شوند.
• Linkها: Icon می‌تواند نزدیک Link قرار گیرد.
• Textual notation: Icon می‌تواند سمت چپ textual notation نمایش داده شود.

چند Icon می‌توانند به Stereotype attached شوند. تفسیر Iconهای مختلف در این حالت semantic variation point است. برخی ابزارها ممکن است Imageهای متفاوتی برای Icon جایگزین Box، Icon کوچک داخل Box، Iconهای Explorer و غیره استفاده کنند. بسته به image format، ابزارهای دیگر ممکن است یک Icon را در اندازه‌های مختلف نمایش دهند.

برخی ModelElementها از قبل Icon را در default presentation خود استفاده می‌کنند. نمونه معمول Actor است که از Icon «stickman» استفاده می‌کند. در این حالت اگر ModelElement توسط Stereotype دارای Icon توسعه یابد، Icon مربوط به Stereotype در diagram جایگزین default presentation icon می‌شود.

Style Guidelines

حرف اول Applied Stereotype نباید uppercase شود.

Examples

در شکل 13.13 Stereotype ساده‌ای به نام Clock تعریف شده که می‌تواند به‌دلخواه و به‌صورت dynamic روی instanceهای metaclass Class اعمال شود. Clock Propertyهای OSVersion:String، startOperation:Operation و POSIXCompliant:Boolean دارد.

شکل 13.14 چند presentation option برای Class توسعه‌یافته با Stereotype Clock را نشان می‌دهد، از جمله نمایش keyword «Clock» و شکل‌های Icon-based.

شکل 13.15 instance specification مربوط به مثال شکل 13.13 را نشان می‌دهد. توجه کنید ExtensionEnd باید composite باشد و Attribute مشتق‌شده isRequired در این مورد false است. شکل repository schema مربوط به Stereotype Clock را نمایش می‌دهد. Instance توسعه‌یافته :Class با name="Class" در repository مربوط به UML2.0 reference metamodel تعریف شده است. در UML modeling tool این instanceهای توسعه‌یافته که به استاندارد UML2.0 reference می‌دهند معمولاً read-only یا به‌صورت proxy برای metaclass توسعه‌یافته نمایش داده می‌شوند.

این مثال هنوز در همان meta-level UML است و instance model مربوط به Model توسعه‌یافته با Stereotype را نشان نمی‌دهد؛ نمونه آن در شکل‌های 13.17 و 13.18 آمده است. بخش Semantics مربوط به Extension معادل MOF و نحوه اتصال Constraintها به Stereotype را توضیح می‌دهد.

شکل 13.16 نشان می‌دهد همان Stereotype Clock می‌تواند metaclass Component یا metaclass Class را توسعه دهد و همچنین Stereotypeهای متفاوت می‌توانند یک metaclass واحد را توسعه دهند. Stereotype Creator در مثال required است.

شکل 13.17 نشان می‌دهد Stereotype Clock، مطابق تعریف شکل 13.16، روی Classی به نام StopWatch اعمال شده است.

شکل 13.18 نمونه instance model را برای حالتی نشان می‌دهد که Stereotype Clock روی Class StopWatch اعمال شده است. Extension میان Stereotype و metaclass باعث ایجاد link میان instance Stereotype Clock و Class تعریف‌شده توسط کاربر StopWatch می‌شود. Valueهای نمونه شامل OSVersion="3.32"، POSIXCompliant=False و startOperation=Click هستند.

سپس دو Stereotype Clock و Creator روی یک ModelElement واحد اعمال می‌شوند، همان‌طور که شکل 13.19 نشان می‌دهد. Attribute valueهای هر Applied Stereotype می‌توانند در Comment symbol متصل به ModelElement نمایش داده شوند.

در پایان شکل 13.20 دو فرم نمادگذاری جایگزین دیگر برای نمایش Stereotype valueها را نشان می‌دهد.

Changes from previous UML

در UML 1.3 tagged value می‌توانست ModelElement را بدون نیاز به حضور Stereotype توسعه دهد. در UML 1.4 این قابلیت با وجود ادامه پشتیبانی deprecated شد و فقط برای backward compatibility در نظر گرفته شد. در UML 2.0 tagged value فقط می‌تواند به‌عنوان Attribute تعریف‌شده روی Stereotype نمایش داده شود. بنابراین ModelElement برای توسعه با tagged value باید توسط Stereotype توسعه یافته باشد. بااین‌حال required Extension mechanism در عمل می‌تواند قابلیت UML 1.3 را فراهم کند، زیرا ابزار در این شرایط می‌تواند Stereotypeای را به‌طور خودکار تعریف کند که Attributeهای «unattached» یا tagged valueها به آن متصل شوند.

Part III - Annexes

Annexها شامل موارد زیر هستند:

• A - XMI Serialization and Schema
• B - Support for Model Driven Architecture

پیوست A - سریال‌سازی و Schema در XMI

وضعیت: هنجاری (normative)

مدل‌های UML 2 مطابق قواعد مشخص‌شده در MOF 2.0: XMI Mapping Specification در XMI سریال‌سازی می‌شوند.

XMI اجازه می‌دهد با استفاده از tagها، Schemaهای تولیدشده و سندهایی که به‌وسیله XMI تولید می‌شوند متناسب‌سازی شوند. تنظیمات tag زیر در UML2 Infrastructure Model برای تبادل XMI مدل‌های UML2 دیده می‌شوند:

• tag nsURI روی http://www.omg.org/spec/UML/20061001/uml-L0-model.xmi تنظیم شده است.
• tag nsURI روی http://www.omg.org/spec/UML/20061001/uml-LM-model.xmi تنظیم شده است.
• tag nsURI روی http://www.omg.org/spec/UML/20061001/uml-L0-model.merged.xmi تنظیم شده است.
• tag nsURI روی http://www.omg.org/spec/UML/20061001/uml-LM-model.merged.xmi تنظیم شده است.
• tag nsPrefix در هر دو مورد روی uml تنظیم شده است.
• هیچ tag دیگری به‌صورت صریح تنظیم نشده است؛ بنابراین مطابق مستندات MOF 2.0 XMI Mappings Specification مقادیر پیش‌فرض خود را می‌گیرد.

پیوست B - پشتیبانی از Model Driven Architecture

وضعیت: اطلاع‌رسان (informative)

ابتکار Model Driven Architecture (MDA) متعلق به OMG یک معماری مفهومیِ در حال تکامل برای مجموعه‌ای از مشخصات فناوری در سطح صنعت است که از رویکرد مدل‌محور به توسعه نرم‌افزار پشتیبانی می‌کنند. خود MDA یک مشخصه فناوری مستقل نیست، بلکه رویکرد و برنامه‌ای برای دستیابی به مجموعه‌ای منسجم از مشخصات فناوری مدل‌محور است.

ابتکار MDA پس از انتشار RFPهای UML 2.0 آغاز شد. بااین‌حال، همان‌گونه که در مرور اجرایی OMG درباره MDA بیان شده است، MDA بر پایه استانداردهای تثبیت‌شده OMG از جمله Unified Modeling Language (UML)، XML Metadata Interchange (XMI) و CORBA بنا شده است. در نتیجه انتظار می‌رود این بازنگری عمده UML نقش مهمی در پیشبرد اهداف MDA ایفا کند.

زیرکمیته Object Reference Model در OMG راهنمای MDA Guide را تهیه کرده است که تعریف رسمی و مورد توافق عمومی MDA را ارائه می‌کند. این راهنما MDA را رویکردی می‌داند که امکان ابزارسازی برای کارهای زیر را فراهم می‌کند:

• مشخص‌کردن یک سیستم مستقل از Platformی که آن را پشتیبانی می‌کند؛
• مشخص‌کردن Platformها یا انتخاب مشخصات Platformهای موجود؛
• انتخاب یک Platform مشخص برای سیستم؛
• تبدیل مشخصات سیستم به مشخصاتی برای Platform انتخاب‌شده.

این راهنما و بسیاری از اسناد MDA همچنین به «خانواده زبان‌های UML» اشاره می‌کنند؛ یعنی Extensionهایی برای UML که برای مقاصد خاص استاندارد می‌شوند و بسیاری از آن‌ها مشخصاً برای استفاده در MDA طراحی خواهند شد.

بخش‌های زیر توضیح می‌دهند UML 2.1.2 چگونه از برجسته‌ترین مفاهیم دیدگاه در حال تکامل MDA پشتیبانی می‌کند.

• خانواده زبان‌ها: UML یک زبان عمومی است و انتظار می‌رود برای طیف گسترده‌ای از Domainها، Platformها و Methodها سفارشی شود. برای این منظور، این مشخصه سازوکار Profile در UML 1.x را به‌گونه‌ای پالایش می‌کند که نیرومندتر، انعطاف‌پذیرتر و از نظر پیاده‌سازی و کاربرد ساده‌تر باشد. بنابراین می‌توان Dialectهای UML را برای Domainهایی مانند مالی، مخابرات و هوافضا، Platformهایی مانند J2EE و .NET، و Methodهایی مانند Unified Process و Agile Methods سفارشی کرد. برای نیازهایی که فراتر از این کاربردهای معمول است و در آن زبان‌های جدید از طریق Metamodel تعریف می‌شوند، InfrastructureLibrary برای استفاده مجدد توسط MOF 2.0 در نظر گرفته شده است. ابزارهای پیاده‌ساز MOF 2.0 به کاربران اجازه می‌دهند زبان‌های کاملاً جدید را از طریق Metamodel تعریف کنند.

• مشخص‌کردن سیستم مستقل از Platform پشتیبان: UML 2.1.2، همانند نسخه پیشین، برای استفاده با گستره وسیعی از Methodهای نرم‌افزاری طراحی شده است. در نتیجه از روش‌هایی پشتیبانی می‌کند که میان Modelهای تحلیلی یا منطقی و Modelهای طراحی یا فیزیکی تمایز می‌گذارند. چون Modelهای تحلیلی یا منطقی معمولاً از جزئیات Implementation و Platform مستقل‌اند، می‌توان آن‌ها را در اصطلاح MDA به‌عنوان Platform Independent Model (PIM) در نظر گرفت. از بهبودهای پیشنهادی برای آسان‌ترکردن مشخص‌سازی PIM می‌توان به امکان مدل‌سازی Classها و Componentهای منطقی و فیزیکی، سازگار با رویکردهای Class-based یا Component-based اشاره کرد.

• مشخص‌کردن Platformها: UML 1.x تنها پشتیبانی بسیار محدودی برای مدل‌سازی Platform Specific Model (PSM) داشت. این مشخصه دو بهبود مهم عرضه می‌کند. نخست، سازوکار بازنگری‌شده Profile امکان سفارشی‌سازی کارآمدتر UML برای Platformهای هدف مانند J2EE یا .NET را فراهم می‌کند. نمونه‌هایی از micro-profileهای J2EE/EJB یا .NET/COM در UML Superstructure Specification آمده‌اند. دوم، Constructهای مربوط به معماری Component، Containerهای Component به‌عنوان محیط‌های runtime اجرایی و Nodeهای محاسباتی به‌طور چشمگیری توسعه یافته‌اند و امکان مشخص‌سازی کامل محیط‌های Implementation هدف را فراهم می‌کنند.

• انتخاب یک Platform مشخص برای سیستم: این مورد بیشتر یک نیاز Method یا Approach است تا یک نیاز مدل‌سازی؛ بنابراین در این سند بررسی بیشتری درباره آن انجام نمی‌شود.

• تبدیل مشخصات سیستم به مشخصات یک Platform مشخص: منظور تبدیل PIM به PSM است. UML Superstructure Specification رابطه‌های مختلفی را برای مشخص‌کردن این تبدیل معرفی می‌کند، از جمله Realization، Refine و Trace. نحوه دقیق استفاده از این تبدیل‌ها به Profileهای به‌کاررفته برای PSMها و نیز Method یا Approach راهنمای فرایند تبدیل وابسته است؛ ازاین‌رو این سند وارد جزئیات بیشتری نمی‌شود.

نمایه

نمایه زیر شناسه‌ها، مفاهیم فنی و شماره صفحه‌های سند اصلی را حفظ می‌کند. نام Metaclassها، Propertyها، Operationها، Packageها و سایر شناسه‌های رسمی UML به‌صورت منبع نگه داشته شده‌اند تا ارجاع فنی دقیق باقی بماند.

INDEX                                                     common superclass 44, 93
                                                          Common Warehouse Metamodel (CWM) 16
                                                          compartment 119, 138
                                                          compartment name 36, 122
A                                                         compliance 4
Abstract syntax compliance 4                              compliance level 1
access 149                                                composite 113, 125
acyclical 82                                              composite aggregation 115, 118
adorn 57                                                  composite name 73
adorned 114                                               concrete 83
aggregation 115                                           Concrete syntax compliance 4
alias 142, 144, 146                                       conform 85
allFeatures 36                                            Conformance 1
allNamespaces 72                                          conformsTo 85
allOwnedElements 75                                       constant 60, 62
allParents 51                                             constrainedElement 41, 42
ancestor 83                                               constraint 41, 66, 83, 86, 127, 151
annotatedElement 38, 92, 105                              constraint language 22, 24
argument 98                                               constraints 119
arrow 99, 114, 144, 162                                   context 41, 46, 134
   solid                                                  contravariance 153, 154
      for navigation 115                                  Core 12, 29, 91, 103, 171
arrow notation 99                                         Core package 12, 27
arrowhead 114, 144, 149, 167                              covariance 154
association 114
association ends 64                                       D
association notation 123                                  dashed arrow 144, 149
association specialization 114                            dashed line 38, 167
asterisk 26, 64, 66, 174                                  DataType 91, 99
attribute 98, 119                                         default 119, 127, 155
attribute compartment 99, 122, 138                        definingFeature 55, 58
attributes 64                                             derived union 32, 36, 72, 76
                                                          diagram interchange 4
B                                                         diamond 114, 115
Bag 127                                                   digit 61, 64
behavioral compatibility 24, 77                           dimmed 160
BehavioralFeature 31, 32                                  direct instance 96
bestVisibility 88                                         DirectedRelationship 79, 106, 143
bidirectionally navigable associations 99                 direction 155
binary association 112, 113, 125                          distinguishable 32, 72
BNF 115                                                   double quotes 63, 174
bodyCondition 152, 153
boldface 119, 122                                         E
Boolean 60, 101, 140                                      Element 38, 39, 93
booleanValue 49, 60                                       Element (as specialized) 39
bound 65, 125, 127                                        element access 144
braces 42, 114                                            element import 144
                                                          ElementImport 142, 146
C                                                         empty name 72
cardinality 65                                            endType 112
Changeabilities 33                                        Enumeration 135, 137, 138, 139, 164
character set 63, 120, 173                                Enumeration rules 166
class 16, 17, 22, 25, 95, 96, 97, 98, 99, 118, 119, 124   EnumerationLiteral 139, 164
classifier 35, 51, 55, 56, 77, 83                         equal sign 56
Classifier (as specialized) 50, 82                        exception 97, 153
Classifiers package 35                                    excludeCollisions 147
colon 56                                                  expression 23, 41, 46
color 116, 160                                            Expressions package 45
comma 56, 114                                             extension 171
comment 37
Comments package 37



F                                               K
false 60                                        keyword 26, 119, 122
Feature 31, 130
featuringClassifier 36, 130                     L
formalism 21                                    language 21, 41
                                                Language Architecture 11
G                                               language units 1
Generalization 51, 88                           line width 116
ggeneralization arrow 114                       link 111
generalization hierarchy 51, 82                 literal 49, 100
Generalizations between associations 114, 116   literalBoolean 59
Generalizations package 49                      literalInteger 60
getName 143                                     literalNull 61
getNamesOfMember 73, 147                        Literals package 59
guillemets 36, 119, 122                         literalSpecification 62
                                                literalString 62
H                                               literalUnlimitedNatural 63
hasVisibilityOf 83                              lowerBound 65, 69
hidden 147                                      lowerValue 69
hierarchy 71
hollow triangle 52, 83                          M
                                                M2 16
I                                               makesVisible 159
identity 140                                    maySpecializeType 83
image 185                                       MDA 12, 207
import 88, 144, 149                             member 73
importedElement 143                             memberEnd 112
importedMember 146                              membersAreDistinguishable 73
importedPackage 148                             mergedPackage 161
importingNamespace 143, 148                     Model Driven Architecture 207
importMembers 147                               MOF 11, 12, 13, 14, 16, 91
includesCardinality 66                          multiple inheritance 96
infinity 174                                    multiplicities 116, 174
inherit 83, 119                                 Multiplicities package 64
inheritableMembers 83                           multiplicity 65, 66, 97, 113, 132
inheritedMember 83                              MultiplicityElement 65, 66
initial 119, 128                                MultiplicityElement (specialized) 68
initialization 98                               MultiplicityExpressions package 68
inout 156                                       multivalued 64
Instance specification 54                       mustBeOwned 75, 159
Instance value 57                               mutually constrained 99
Instances package 53
instantiated 119, 127                           N
instantiation 65                                name 33, 71, 83, 94, 127
integer 60, 65, 101, 123, 140, 145              NamedElement 71, 73, 83, 87
integerValue 49, 61                             NamedElement (as specialized) 87
isAbstract 82, 96                               Namespace 70, 146
isComposite 98                                  Namespace (as specialized) 43
isComputable 49, 60, 61, 63                     Namespaces 70
isConsistentWith 77, 153                        Namespaces diagram 141
isDerived 98, 112                               Namespaces package 70
isDistinguishableFrom 32, 72, 73                natural language 25, 47
isMultivalued 65                                navigable 117, 125, 166
isNull 49, 61                                   navigableOwnedEnd 112
isOrdered 65, 66, 152                           navigation arrows 57, 115
isQuery 152                                     nested namespaces 71
isReadOnly 34, 98, 125, 126                     nestedPackage 102
isUnique 65, 112, 127, 152                      nonprintable characters 174
italics 120                                     nonunique 67
                                                note symbol 38, 42
J                                               null 61
Java 41

210                                                                    UML Infrastructure Specification, v2.1.2

O                                          redefine 127, 129
OCL 23, 41, 47, 48, 69, 171, 173           RedefineableElement 131
opaqueExpression 47, 108, 109              redefined 152, 154
operand 46                                 redefinedElement 76, 131
operation 42, 119, 151, 156                redefinedOperation 152
operation compartment 122                  redefinedProperty 125
opposite 98, 125                           redefines 113, 128, 129, 154
ordered 113, 129, 138, 154                 redefinitionContext 76, 132
OrderedSet 127                             redefinitions 75
out 156                                    Redefinitions package 75
overriding 73                              relatedElement 79, 107
ownedAttribute 96, 118, 136                relationship 79, 105
ownedComment 39, 107                       relationship (directed) 78
ownedElement 75                            Relationships package 78
ownedEnd 112                               returnResult 153
ownedLiteral 100, 138                      Root diagram 105
ownedMember 146, 158                       round parentheses 47
ownedOperation 96, 119, 137                run-time extension 139
ownedParameter 97, 151
ownedRule 44, 135                          S
ownedType 158                              segments 114, 115
owner 75                                   self 24, 42
Ownerships package 74                      semantic variation point 23
owningAssociation 125                      semicircular jog 115
owningInstance 58                          separate target style 52
                                           separator 72
P                                          Sequence 127
package 88, 101, 179                       Set 127
package import 143, 148                    shared target style 52, 84
PackageableElement 134, 143, 146, 158      side effect 69
PackageImport 146, 148                     slash 114
PackageMerge 104, 156, 158, 160, 167       slot 55, 58, 81, 96
Packages diagram 101, 156                  snapshot 55
parameter 32, 97, 155, 162                 solid line 114
parameter list 155                         solid path 57
ParameterDirectionKind 156                 solid-outline rectangle 36
parameters 119                             source 79, 106
plus sign 159                              specialized 113
postcondition 42, 152                      specific 52
precondition 152                           specification 41, 54, 55, 135
predefined 41, 171                         square brackets 26, 66, 168
primitive type 27, 101                     state 154
printable characters 174                   static operation 153
private 88, 160                            String 62, 101, 140
ProfileApplication 195                     string 140
Profiles 13                                stringValue 49, 63
Profiles package 179                       structural compatibility 77
Property 96, 98, 118                       structuralFeature 132
property string 67, 114                    StructuralFeature (as specialized) 34
protected 88                               StructuralFeatures package 80
public 88, 159, 160                        subset 113, 128
                                           subsettedProperty 125
Q                                          subsetting 125, 126
qualified 143                              subsettingContext 125, 126
qualified name 144, 146, 159               substitutable 77, 154
query 153, 154, 166                        Super package 81
                                           superClass 96
R                                          superstructure 91
raisedException 97, 151, 152
                                           symbol 46
readOnly 128
rectangle 36, 38, 123, 138, 159
RedefinableElement 119, 124, 125, 129


T
tab 159
target 79, 106
ternary association 116
tree 115
true 60
tuple 111
type 83, 85, 102, 121, 133, 164
type conformance 51
typedElement 86, 129, 133
TypedElements package 84

U
UML 12
underlined name 57
union 128
unique 65, 67, 113, 128
unlimited 63
unlimitedNatural 49, 101, 140, 174
unlimitedValue 49, 64
unordered 66
upper 65, 69, 152
upperBound 65, 69
upperValue 69

V
value 58
ValueSpecification 41, 48, 69
visibilities 86
visibility 86, 127, 143, 159
visibility keyword 119
Visibility package 86
visibility symbol 115
visibilityKind 88

X
XMI 12, 27, 67, 163
XML Metadata Interchange (XMI) 14




212                                  UML Infrastructure Specification, v2.1.2