مشخصات زیرساخت زبان مدل‌سازی یکپارچه OMG (OMG UML)، نسخه 2.1.2

تاریخ: نوامبر 2007
نوع سند: مشخصات در دسترس OMG، بدون نوارهای تغییر
شماره سند OMG: formal/2007-11-04
نشانی استاندارد سند: http://www.omg.org/spec/UML/2.1.2/Infrastructure/PDF
فایل‌های شِمای مرتبط (فایل zip اصلی: ptc/06-10-06):

• http://www.omg.org/spec/UML/20061012/Infrastructure.cmof
• http://www.omg.org/spec/UML/20061012/uml-L0-model.xmi
• http://www.omg.org/spec/UML/20061012/uml-LM-model.xmi

نسخه 2.1.2 یک بازنگری جزئی نسبت به مشخصات UML 2.1.1 است و جایگزین سند formal/2007-02-06 می‌شود. از جمله مسائلی که موجب این بازنگری شدند می‌توان به Issueهای شماره 10992، 11152 و 11234 اشاره کرد.

حقوق مؤلف

Copyright © 2001-2003 Adaptive Ltd.
Copyright © 2001-2003 Alcatel
Copyright © 2001-2003 Borland Software Corporation
Copyright © 2001-2003 Computer Associates International, Inc.
Copyright © 2001-2003 Telefonaktiebolaget LM Ericsson
Copyright © 2001-2003 Fujitsu
Copyright © 2001-2003 Hewlett-Packard Company
Copyright © 2001-2003 I-Logix Inc.
Copyright © 2001-2003 International Business Machines Corporation
Copyright © 2001-2003 IONA Technologies
Copyright © 2001-2003 Kabira Technologies, Inc.
Copyright © 2001-2003 MEGA International
Copyright © 2001-2003 Motorola, Inc.
Copyright © 1997-2007 Object Management Group.
Copyright © 2001-2003 Oracle Corporation
Copyright © 2001-2003 SOFTEAM
Copyright © 2001-2003 Telelogic AB
Copyright © 2001-2003 Unisys
Copyright © 2001-2003 X-Change Technologies Group, LLC

استفاده از مشخصات - شرایط، ضوابط و اطلاعیه‌ها

مطالب این سند، مشخصاتی از Object Management Group را مطابق شرایط، ضوابط و اطلاعیه‌های درج‌شده در ادامه شرح می‌دهد. این سند به معنای تعهد هیچ شرکتی برای پیاده‌سازی هیچ بخش از این مشخصات در محصولات خود نیست. اطلاعات موجود در این سند ممکن است بدون اطلاع قبلی تغییر کند.

مجوزها

شرکت‌های فهرست‌شده در بالا، مجوزی غیرانحصاری، بدون حق امتیاز، کاملاً پرداخت‌شده و جهانی به Object Management Group, Inc. (OMG) اعطا کرده‌اند تا این سند را نسخه‌برداری و توزیع کند، آن را تغییر دهد و نسخه‌های اصلاح‌شده را نیز توزیع کند. هر یک از دارندگان حقوق مؤلف فوق موافقت کرده‌اند که صرف استفاده از مشخصات ارائه‌شده در این سند یا انطباق نرم‌افزار با آن، به‌خودی‌خود نقض حقوق مؤلفِ مطالب متعلق به آن دارنده حقوق محسوب نشود.

با رعایت تمام شرایط و ضوابط زیر، صاحبان حقوق مؤلف این مشخصات، مجوزی کاملاً پرداخت‌شده، غیرانحصاری، غیرقابل‌انتقال، دائمی و جهانی - بدون حق اعطای مجوز فرعی - به شما می‌دهند تا از این مشخصات برای ایجاد و توزیع نرم‌افزار و مشخصات ویژه‌ای که بر مبنای آن ساخته شده‌اند استفاده کنید و همچنین مطابق قانون حقوق مؤلف از این مشخصات استفاده، نسخه‌برداری و آن را توزیع کنید؛ مشروط بر اینکه: (1) اطلاعیه حقوق مؤلف فوق و این اجازه‌نامه در همه نسخه‌های این مشخصات درج شود؛ (2) استفاده از مشخصات صرفاً برای مقاصد اطلاعاتی باشد و مشخصات روی رایانه شبکه‌ای کپی یا منتشر نشود، از طریق رسانه‌ها پخش نگردد و برای مقاصد تجاری مجدداً فروخته یا منتقل نشود؛ و (3) هیچ تغییری در مشخصات ایجاد نشود. در صورت نقض هر یک از این شرایط یا ضوابط، این اجازه محدود به‌طور خودکار و بدون اطلاع قبلی خاتمه می‌یابد. پس از خاتمه، باید فوراً تمام نسخه‌های مشخصات را که در اختیار یا تحت کنترل شماست از بین ببرید.

اختراعات و حق اختراع

به استفاده‌کنندگان یادآوری می‌شود که انطباق با مشخصات OMG یا پذیرش آن‌ها ممکن است مستلزم استفاده از اختراعی باشد که تحت پوشش حقوق ثبت اختراع قرار دارد. OMG مسئول شناسایی حق‌اختراع‌هایی که ممکن است برای استفاده از هر یک از مشخصات OMG به مجوز نیاز داشته باشند نیست و همچنین مسئول انجام بررسی‌های حقوقی درباره اعتبار یا دامنه حق‌اختراع‌هایی که به اطلاعش رسانده می‌شوند نخواهد بود. مشخصات OMG صرفاً آینده‌نگر و مشورتی هستند. کاربران بالقوه مسئول حفاظت از خود در برابر مسئولیت ناشی از نقض حقوق ثبت اختراع‌اند.

محدودیت‌های عمومی استفاده

هرگونه استفاده غیرمجاز از این مشخصات ممکن است ناقض قوانین حقوق مؤلف، علائم تجاری و مقررات و قوانین ارتباطات باشد. این سند شامل اطلاعاتی است که تحت حمایت حقوق مؤلف قرار دارد. کلیه حقوق محفوظ است. هیچ بخشی از این اثر که مشمول حقوق مؤلف است، بدون اجازه صاحب حقوق مؤلف نباید به هیچ شکل یا وسیله‌ای - اعم از گرافیکی، الکترونیکی یا مکانیکی، از جمله فتوکپی، ضبط، نواربرداری یا سامانه‌های ذخیره و بازیابی اطلاعات - تکثیر یا استفاده شود.

سلب ضمانت

با وجود آنکه این انتشارنامه دقیق تلقی می‌شود، به‌صورت «همان‌گونه که هست» ارائه شده و ممکن است شامل خطا یا اشتباه چاپی باشد. Object Management Group و شرکت‌های فهرست‌شده در بالا، هیچ‌گونه ضمانت صریح یا ضمنی درباره این انتشارنامه ارائه نمی‌کنند؛ از جمله، اما نه محدود به، ضمانت مالکیت یا عنوان، ضمانت ضمنی قابلیت فروش یا ضمانت تناسب برای یک هدف یا کاربرد خاص.

در هیچ حالتی Object Management Group یا هیچ‌یک از شرکت‌های فوق در قبال خطاهای موجود در این سند یا خسارت‌های مستقیم، غیرمستقیم، اتفاقی، ویژه، تبعی، ناشی از اتکا یا هزینه‌های پوششی - از جمله از دست رفتن سود، درآمد، داده یا امکان استفاده - که برای هر کاربر یا شخص ثالث در ارتباط با ارائه، عملکرد یا استفاده از این مطالب ایجاد شود، حتی اگر قبلاً از امکان وقوع چنین خسارتی آگاه شده باشند، مسئول نخواهند بود.

تمام ریسک مربوط به کیفیت و عملکرد نرم‌افزاری که با استفاده از این مشخصات توسعه داده می‌شود بر عهده شماست. این سلب ضمانت بخش اساسی مجوز اعطاشده برای استفاده از این مشخصات است.

شرح حقوق محدودشده

استفاده، تکثیر یا افشای این مطالب توسط دولت ایالات متحده مشمول محدودیت‌های مندرج در بند فرعی (c)(1)(ii) از بند «حقوق در داده‌های فنی و نرم‌افزار رایانه‌ای» در DFARS 252.227-7013 یا بندهای فرعی (c)(1) و (2) از بندهای «نرم‌افزار رایانه‌ای تجاری - حقوق محدودشده» در 48 C.F.R. 52.227-19، یا مطابق 48 C.F.R. 227-7202-2 از مکمل مقررات تدارکات فدرال وزارت دفاع و جانشینان آن، یا حسب مورد مطابق 48 C.F.R. 12.212 از مقررات تدارکات فدرال و جانشینان آن است. صاحبان حقوق مؤلف این مشخصات همان اشخاص و نهادهای ذکرشده در بالا هستند و می‌توان از طریق Object Management Group، به نشانی 140 Kendrick Street, Needham, MA 02494, U.S.A. با آنان تماس گرفت.

علائم تجاری

MDA®، Model Driven Architecture®، UML®، UML Cube logo®، OMG Logo®، CORBA® و XMI® علائم تجاری ثبت‌شده Object Management Group, Inc. هستند. همچنین Object Management Group™، OMG™، Unified Modeling Language™، Model Driven Architecture Logo™، Model Driven Architecture Diagram™، CORBA logos™، XMI Logo™، CWM™، CWM Logo™، IIOP™، MOF™ و OMG Interface Definition Language (IDL)™ علائم تجاری Object Management Group هستند. سایر نام‌های محصول یا شرکت که در این سند ذکر شده‌اند صرفاً برای شناسایی استفاده شده‌اند و ممکن است علائم تجاری مالکان مربوطه باشند.

انطباق

دارندگان حقوق مؤلفِ فهرست‌شده در بالا اذعان می‌کنند که Object Management Group - چه به‌طور مستقیم و چه از طریق نمایندگان خود - همواره تنها نهادی است که می‌تواند به توسعه‌دهندگان، تأمین‌کنندگان و فروشندگان نرم‌افزار رایانه‌ای اجازه دهد از نشان‌های گواهی، علائم تجاری یا دیگر عناوین ویژه برای نشان‌دادن انطباق با این مطالب استفاده کنند.

نرم‌افزاری که تحت شرایط این مجوز توسعه یافته است تنها در صورتی می‌تواند ادعای انطباق یا سازگاری با این مشخصات داشته باشد که ماهیت انطباق آن به‌طور کامل با نقاط انطباق قابل‌اعمالِ ذکرشده در مشخصات مطابقت داشته باشد. نرم‌افزاری که فقط بخشی از نقاط انطباق قابل‌اعمال را پوشش می‌دهد، صرفاً می‌تواند ادعا کند که بر اساس این مشخصات ساخته شده است و نمی‌تواند مدعی انطباق یا سازگاری با آن باشد. اگر مجموعه‌های آزمون توسط Object Management Group, Inc. پیاده‌سازی یا تأیید شوند، نرم‌افزار توسعه‌یافته بر مبنای این مشخصات فقط زمانی می‌تواند ادعای انطباق یا سازگاری کند که مجموعه آزمون‌ها را با موفقیت پشت سر بگذارد.

رویه گزارش مسائل در OMG

تمام مشخصات OMG به‌طور پیوسته بازبینی و بهبود داده می‌شوند. به‌عنوان بخشی از این فرایند، از خوانندگان خواسته می‌شود هرگونه ابهام، ناسازگاری یا عدم دقتی را که مشاهده می‌کنند از طریق فرم گزارش مسئله در صفحه اصلی http://www.omg.org، در بخش Documents و گزینه Report a Bug/Issue (http://www.omg.org/technology/agreement.htm) گزارش کنند.

UML Infrastructure Specification, v2.1.2

فهرست مطالب

1. دامنه - صفحه 1
2. انطباق - صفحه 1
   2.1 واحدهای زبان - 2
   2.2 سطوح انطباق - 2
   2.3 معنا و انواع انطباق - 3
   2.4 محتوای سطوح انطباق - 5
3. مراجع هنجاری - 5
4. اصطلاحات و تعاریف - 5
5. نمادها - 6
6. اطلاعات تکمیلی - 6
   6.1 تغییرات در مشخصات پذیرفته‌شده OMG - 6
   6.2 هم‌ترازی معماری و پشتیبانی از MDA - 6
   6.3 نحوه مطالعه این مشخصات - 6
   6.3.1 قالب نمودار - 6
   6.4 سپاسگزاری‌ها - 7
7. معماری زبان - 11
   7.1 اصول طراحی - 11
   7.2 معماری زیرساخت - 11
   7.3 Core - 12
   7.4 Profiles - 13
   7.5 هم‌ترازی معماری میان UML و MOF - 14
   7.6 معماری Superstructure - 14
   7.7 استفاده مجدد از Infrastructure - 15
   7.8 بسته Kernel - 16
   7.9 لایه‌بندی متامدل - 16
   7.10 سلسله‌مراتب چهارلایه متامدل - 16
   7.11 متامدل‌سازی - 17
   7.12 نمونه‌ای از سلسله‌مراتب چهارسَطحی متامدل - 18
8. صورت‌بندی زبان - 21
   8.1 سطوح صوری‌بودن - 21
   8.2 ساختار مشخصات بسته - 22
   8.2.1 توصیف کلاس‌ها - 22
   8.2.2 نمودارها - 22
   8.2.3 مدل نمونه - 22
   8.3 ساختار مشخصات کلاس - 22
   8.3.1 توصیف - 23
   8.3.2 ویژگی‌ها - 23
   8.3.3 ارتباط‌ها - 23
   8.3.4 قیود - 23
   8.3.5 عملیات اضافی (اختیاری) - 23
   8.3.6 معناشناسی - 23
   8.3.7 نقاط تغییرپذیری معنایی (اختیاری) - 23
   8.3.8 نمادگذاری - 24
   8.3.9 گزینه‌های ارائه (اختیاری) - 24
   8.3.10 رهنمودهای سبک (اختیاری) - 24
   8.3.11 مثال‌ها (اختیاری) - 24
   8.3.12 منطق و دلیل طراحی (اختیاری) - 24
   8.3.13 تغییرات نسبت به UML 1.4 - 24
   8.4 استفاده از زبان قید - 24
   8.5 استفاده از زبان طبیعی - 25
   8.6 قراردادها و حروف‌چینی - 25
9. Core::Abstractions - 29
   9.1 بسته BehavioralFeatures - 31؛ 9.1.1 BehavioralFeature - 31
   9.2 Parameter - 32
   9.3 بسته Changeabilities - 33؛ 9.3.1 StructuralFeature (به‌صورت تخصصی‌شده) - 34
   9.4 بسته Classifiers - 35؛ 9.4.1 Classifier - 35؛ 9.4.2 Feature - 36
   9.5 بسته Comments - 37؛ 9.5.1 Comment - 37؛ 9.5.2 Element - 39
   9.6 بسته Constraints - 40؛ 9.6.1 Constraint - 41؛ 9.6.2 Namespace (تخصصی‌شده) - 43
   9.7 بسته Elements - 44؛ 9.7.1 Element - 44
   9.8 بسته Expressions - 45؛ 9.8.1 Expression - 46؛ 9.8.2 OpaqueExpression - 47؛ 9.8.3 ValueSpecification - 48
   9.9 بسته Generalizations - 49؛ 9.9.1 Classifier (تخصصی‌شده) - 50؛ 9.9.2 Generalization - 51
   9.10 بسته Instances - 53؛ 9.10.1 InstanceSpecification - 54؛ 9.10.2 InstanceValue - 57؛ 9.10.3 Slot - 58
   9.11 بسته Literals - 59؛ 9.11.1 LiteralBoolean - 59؛ 9.11.2 LiteralInteger - 60؛ 9.11.3 LiteralNull - 61؛ 9.11.4 LiteralSpecification - 62؛ 9.11.5 LiteralString - 62؛ 9.11.6 LiteralUnlimitedNatural - 63
   9.12 بسته Multiplicities - 64؛ 9.12.1 MultiplicityElement - 65
   9.13 بسته MultiplicityExpressions - 68؛ 9.13.1 MultiplicityElement (تخصصی‌شده) - 68
   9.14 بسته Namespaces - 70؛ 9.14.1 NamedElement - 71؛ 9.14.2 Namespace - 72
   9.15 بسته Ownerships - 74؛ 9.15.1 Element (تخصصی‌شده) - 74
   9.16 بسته Redefinitions - 75؛ 9.16.1 RedefinableElement - 76
   9.17 بسته Relationships - 78؛ 9.17.1 DirectedRelationship - 78؛ 9.17.2 Relationship - 79
   9.18 بسته StructuralFeatures - 80؛ 9.18.1 StructuralFeature - 80
   9.19 بسته Super - 81؛ 9.19.1 Classifier (تخصصی‌شده) - 82
   9.20 بسته TypedElements - 84؛ 9.20.1 Type - 85؛ 9.20.2 TypedElement - 86
   9.21 بسته Visibilities - 86؛ 9.21.1 NamedElement (تخصصی‌شده) - 87؛ 9.21.2 VisibilityKind - 88
10. Core::Basic - 91
    10.1 نمودار Types - 92؛ Comment - 92؛ Element - 93؛ NamedElement - 93؛ Type - 94؛ TypedElement - 94
    10.2 نمودار Classes - 95؛ Class - 95؛ MultiplicityElement - 96؛ Operation - 97؛ Parameter - 98؛ Property - 98
    10.3 نمودار DataTypes - 99؛ DataType - 99؛ Enumeration - 100؛ EnumerationLiteral - 100؛ PrimitiveType - 101
    10.4 نمودار Packages - 101؛ Package - 101؛ Type - 102
11. Core::Constructs - 103
    11.1 نمودار Root - 105؛ Comment - 105؛ DirectedRelationship - 106؛ Element - 106؛ Relationship - 107
    11.2 نمودار Expressions - 108؛ Expression - 108؛ OpaqueExpression - 109؛ ValueSpecification - 109
    11.3 نمودار Classes - 110؛ Association - 111؛ Class - 118؛ Classifier - 121؛ Operation - 124؛ Property - 124
    11.4 نمودار Classifiers - 129؛ Classifier - 129؛ Feature - 130؛ MultiplicityElement - 131؛ RedefinableElement - 131؛ StructuralFeature - 132؛ Type - 133؛ TypedElement - 133
    11.5 نمودار Constraints - 134؛ Constraint - 134؛ Namespace - 135
    11.6 نمودار DataTypes - 135؛ DataType - 136؛ Enumeration - 137؛ EnumerationLiteral - 138؛ Operation - 139؛ PrimitiveType - 140؛ Property - 141
    11.7 نمودار Namespaces - 141؛ ElementImport - 142؛ NamedElement - 145؛ Namespace - 146؛ PackageableElement - 147؛ PackageImport - 148
    11.8 نمودار Operations - 149؛ BehavioralFeature - 150؛ Operation - 151؛ Parameter - 155؛ ParameterDirectionKind - 156
    11.9 نمودار Packages - 156؛ Type - 157؛ Package - 158؛ PackageMerge - 160
12. Core::PrimitiveTypes - 171
    12.1 بسته PrimitiveTypes - 171؛ Boolean - 171؛ Integer - 172؛ String - 173؛ UnlimitedNatural - 174
13. Core::Profiles - 177
    13.1 بسته Profiles - 179؛ Class - 180؛ Extension - 181؛ ExtensionEnd - 184؛ Image - 185؛ Package - 186؛ Profile - 187؛ ProfileApplication - 195؛ Stereotype - 197
    پیوست A: سریال‌سازی و شِمای XMI - 205
    پیوست B: پشتیبانی از معماری مدل‌محور - 207
    نمایه - 209

1 دامنه

این مشخصات، زبان مدل‌سازی یکپارچه (UML) بازنگری 2 را تعریف می‌کند. هدف UML فراهم‌کردن ابزارهایی برای معماران سامانه، مهندسان نرم‌افزار و توسعه‌دهندگان نرم‌افزار است تا بتوانند سامانه‌های مبتنی بر نرم‌افزار را تحلیل، طراحی و پیاده‌سازی کنند و همچنین فرایندهای کسب‌وکار و فرایندهای مشابه را مدل‌سازی نمایند.

نسخه‌های اولیه UML (UML 1) از سه روش پیشرو شیءگرا - Booch، OMT و OOSE - سرچشمه گرفتند و شماری از بهترین رویه‌ها در طراحی زبان‌های مدل‌سازی، برنامه‌نویسی شیءگرا و زبان‌های توصیف معماری را در خود ادغام کردند. در مقایسه با UML 1، این بازنگری با تعریف‌های بسیار دقیق‌تر برای قواعد نحو انتزاعی و معناشناسی، ساختار زبانی ماژولارتر و قابلیت بسیار بهبودیافته برای مدل‌سازی سامانه‌های بزرگ‌مقیاس ارتقا یافته است.

یکی از اهداف اصلی UML، پیشبرد وضعیت صنعت از طریق فراهم‌کردن قابلیت تعامل میان ابزارهای مدل‌سازی بصری شیءگراست. با این حال، برای اینکه تبادل معنادار اطلاعات مدل میان ابزارها امکان‌پذیر باشد، توافق درباره معناشناسی و نمادگذاری ضروری است. UML نیازمندی‌های زیر را برآورده می‌کند:

• تعریف صوری یک متامدل مشترک مبتنی بر MOF که نحو انتزاعی UML را مشخص می‌کند. نحو انتزاعی مجموعه مفاهیم مدل‌سازی UML، ویژگی‌ها و روابط آن‌ها و نیز قواعد ترکیب این مفاهیم برای ساخت مدل‌های UML جزئی یا کامل را تعریف می‌کند.
• توضیح تفصیلی معناشناسی هر مفهوم مدل‌سازی UML. معناشناسی به‌صورت مستقل از فناوری تعیین می‌کند که مفاهیم UML چگونه باید توسط رایانه‌ها تحقق یابند.
• مشخص‌کردن عناصر نمادگذاری خوانا برای انسان جهت نمایش تک‌تک مفاهیم مدل‌سازی UML، همراه با قواعد ترکیب آن‌ها در انواع گوناگون نمودار که هر کدام متناظر با جنبه‌ای از سامانه مدل‌شده‌اند.
• تعریف تفصیلی روش‌هایی که ابزارهای UML می‌توانند بر اساس آن‌ها با این مشخصات منطبق شوند. این موضوع در یک مشخصات جداگانه با تعریف مبتنی بر XML برای قالب‌های متناظر تبادل مدل (XMI) پشتیبانی می‌شود؛ قالب‌هایی که ابزارهای منطبق باید آن‌ها را پیاده‌سازی کنند.

2 انطباق

UML زبانی با دامنه بسیار گسترده است که مجموعه بزرگ و متنوعی از حوزه‌های کاربرد را پوشش می‌دهد. همه قابلیت‌های مدل‌سازی آن لزوماً در تمام حوزه‌ها یا کاربردها مفید نیستند. این امر نشان می‌دهد که زبان باید به‌صورت ماژولار ساختاربندی شود، به‌گونه‌ای که فقط بخش‌هایی از زبان که مستقیماً مورد نیازند قابل انتخاب باشند. از سوی دیگر، انعطاف بیش از حد از این نوع، احتمال آن را افزایش می‌دهد که دو ابزار متفاوت UML زیرمجموعه‌های متفاوتی از زبان را پشتیبانی کنند و در نتیجه هنگام تبادل مدل میان آن‌ها مشکل ایجاد شود. بنابراین تعریف انطباق در UML باید میان ماژولار بودن و سهولت تبادل تعادل برقرار کند.

تجربه نسخه‌های پیشین UML نشان داده است که توانایی تبادل مدل میان ابزارها برای جامعه بزرگی از کاربران اهمیت بنیادی دارد. به همین دلیل، این مشخصات تعداد محدودی سطح انطباق تعریف می‌کند تا احتمال پشتیبانی دو یا چند ابزار منطبق از زیرمجموعه‌های یکسان یا سازگار زبان افزایش یابد. با این حال، UML با توجه به نیاز به انعطاف در یادگیری و استفاده از زبان، مفهوم «واحدهای زبان» را نیز فراهم می‌کند.

2.1 واحدهای زبان

مفاهیم مدل‌سازی UML در قالب «واحدهای زبان» گروه‌بندی شده‌اند. هر واحد زبان مجموعه‌ای از مفاهیم مدل‌سازی با ارتباط تنگاتنگ است که به کاربران امکان می‌دهد جنبه‌هایی از سامانه مورد مطالعه را مطابق یک پارادایم یا صورت‌بندی مشخص نمایش دهند. برای مثال، واحد زبان State Machines به مدل‌ساز اجازه می‌دهد رفتار گسسته و رویدادمحور را با گونه‌ای از صورت‌بندی شناخته‌شده statecharts مشخص کند، در حالی که واحد زبان Activities امکان مدل‌سازی رفتار بر مبنای پارادایمی شبیه گردش‌کار را فراهم می‌کند. از دید کاربر، این تقسیم‌بندی UML یعنی لازم است فقط با بخش‌هایی از زبان سروکار داشته باشد که برای مدل‌های خود ضروری می‌داند. اگر نیازها در طول زمان تغییر کنند، می‌توان واحدهای زبان بیشتری را حسب نیاز به مجموعه دانسته‌های کاربر افزود. بنابراین برای استفاده مؤثر از UML لازم نیست کاربر کل زبان را بداند.

افزون بر این، بیشتر واحدهای زبان به چند افزونه تدریجی تقسیم می‌شوند که هر یک قابلیت‌های مدل‌سازی بیشتری نسبت به مرحله قبلی اضافه می‌کند. این تجزیه ریزدانه UML یادگیری و استفاده از زبان را آسان‌تر می‌کند، اما بخش‌های منفرد در این ساختار نقاط انطباق مستقل محسوب نمی‌شوند. اتخاذ چنین رویکردی موجب ایجاد تعداد بیش از حد نقاط انطباق و در پی آن مشکلات تعامل‌پذیری شرح‌داده‌شده در بالا می‌شد. با این وجود، گروه‌بندی‌هایی که واحدهای زبان و افزونه‌های آن‌ها فراهم می‌کنند، تعریف انطباق UML را همان‌گونه که در ادامه توضیح داده می‌شود ساده‌تر می‌سازند.

2.2 سطوح انطباق

لایه‌بندی واحدهای زبان مبنای تعریف انطباق در UML است. به بیان دقیق‌تر، مجموعه مفاهیم مدل‌سازی UML به لایه‌های افقی با قابلیت‌های افزاینده تقسیم می‌شود که «سطوح انطباق» نام دارند. سطوح انطباق از میان واحدهای مختلف زبان عبور می‌کنند، هرچند برخی واحدهای زبان فقط در سطوح بالاتر حضور دارند. همان‌گونه که از نام آن‌ها پیداست، هر سطح انطباق یک نقطه انطباق متمایز محسوب می‌شود.

برای تسهیل تبادل مدل، در UML Infrastructure فقط دو سطح انطباق تعریف شده است:

• Level 0 (L0) - شامل یک واحد زبان است که امکان مدل‌سازی انواع ساختارهای مبتنی بر کلاس را که در بیشتر زبان‌های برنامه‌نویسی شیءگرای رایج دیده می‌شوند فراهم می‌کند. در نتیجه، یک قابلیت مدل‌سازی سطح ورود ارائه می‌دهد. مهم‌تر آنکه، کمینه مشترک کم‌هزینه‌ای را تشکیل می‌دهد که می‌تواند مبنای تعامل‌پذیری میان دسته‌های متفاوت ابزارهای مدل‌سازی باشد.
• Metamodel Constructs (LM) - یک واحد زبان اضافی برای ساختارهای پیشرفته‌تر مبتنی بر کلاس اضافه می‌کند که برای ساخت متامدل‌ها با استفاده از CMOF، مانند خود UML، به کار می‌روند.

همان‌طور که گفته شد، سطوح انطباق بر سطوح پشتیبان پایین‌تر بنا می‌شوند. سازوکار اصلی مورد استفاده در این مشخصات برای تحقق این موضوع، PackageMerge (ادغام بسته) است؛ به بخش 11.9.3 در صفحه 160 مراجعه کنید. ادغام بسته اجازه می‌دهد مفاهیم مدل‌سازی تعریف‌شده در یک سطح با ویژگی‌های جدید گسترش یابند. از همه مهم‌تر، این کار در چارچوب همان فضای نام انجام می‌شود و به همین دلیل تبادل مدل‌ها در سطوح مختلف انطباق، مطابق توضیح بخش «معنا و انواع انطباق»، امکان‌پذیر می‌شود.

به همین دلیل، تمام سطوح انطباق به‌صورت توسعه‌هایی روی یک بسته مرکزی واحد با نام UML تعریف می‌شوند که فضای نام مشترک تمام سطوح انطباق را مشخص می‌کند. Level 0 با متامدل سطح بالای نشان‌داده‌شده در ادامه تعریف می‌شود.

در این مدل، UML در ابتدا بسته‌ای خالی است که صرفاً محتوای بسته Basic از UML Infrastructure را در خود ادغام می‌کند. این بسته مفاهیم ابتدایی مانند Class، Package، DataType، Operation و موارد مشابه را در بر دارد.

در سطح بعدی (LM)، محتوای بسته UML - که اکنون بسته‌های ادغام‌شده در Level 0 و محتوای آن‌ها را نیز شامل می‌شود - با بسته Constructs گسترش می‌یابد.

توجه کنید که LM بسته Basic را به‌طور صریح ادغام نمی‌کند، زیرا عناصر موجود در Basic قبلاً در عناصر متناظرِ Constructs ادغام شده‌اند.

2.3 معنا و انواع انطباق

انطباق با یک سطح مشخص مستلزم تحقق کامل تمام واحدهای زبانی است که برای آن سطح انطباق تعریف شده‌اند. این امر همچنین به معنای تحقق کامل همه واحدهای زبان در تمام سطوح پایین‌تر است. «تحقق کامل» برای یک واحد زبان در یک سطح معین یعنی پشتیبانی از مجموعه کامل مفاهیم مدل‌سازی تعریف‌شده برای آن واحد زبان در همان سطح.

بنابراین برای مثال، ادعای انطباق با Level 2 بدون آنکه هم‌زمان انطباق با Level 0 و Level 1 وجود داشته باشد بی‌معناست. ابزاری که با یک سطح مشخص منطبق است باید بتواند مدل‌های تولیدشده توسط ابزارهای منطبق با سطوح پایین‌تر را بدون از دست‌رفتن اطلاعات وارد کند.

دو نوع متمایز انطباق وجود دارد:

• انطباق با نحو انتزاعی. برای یک سطح انطباق معین، این نوع شامل موارد زیر است:
  • انطباق با متاکلاس‌ها، روابط ساختاری آن‌ها و هر قیدی که به‌عنوان بخشی از متامدل ادغام‌شده UML برای همان سطح انطباق تعریف شده است؛ و
  • توانایی خروجی‌دادن مدل‌ها و خواندن مدل‌هایی که بر اساس شِمای XMI متناظر با آن سطح انطباق هستند.
• انطباق با نحو عینی. برای یک سطح انطباق معین، این نوع شامل موارد زیر است:
  • انطباق با نمادگذاری تعریف‌شده در زیربندهای «Notation» این مشخصات برای آن دسته از عناصر متامدل که بخشی از متامدل ادغام‌شده همان سطح انطباق هستند و، به‌تبع آن، انواع نمودارهایی که این عناصر ممکن است در آن‌ها ظاهر شوند؛ و به‌صورت اختیاری:
  • توانایی خروجی‌دادن و خواندن نمودارها بر اساس شِمای XMI تعریف‌شده توسط مشخصات Diagram Interchange برای نمادگذاری در آن سطح. این گزینه مستلزم انطباق هم با نحو انتزاعی و هم با نحو عینی است.

انطباق با نحو عینی مستلزم انطباق با هیچ‌یک از گزینه‌های ارائه‌ای که به‌عنوان بخشی از نمادگذاری تعریف شده‌اند نیست.

انطباق برای یک سطح مشخص می‌تواند به یکی از شکل‌های زیر بیان شود:

• انطباق با نحو انتزاعی؛
• انطباق با نحو عینی؛
• انطباق با نحو انتزاعی همراه با نحو عینی؛
• انطباق با نحو انتزاعی، نحو عینی و تبادل نمودار.

جدول 2.1 - نمونه بیانیه انطباق

در مورد ابزارهایی که از روی مدل‌ها کد برنامه تولید می‌کنند یا قادر به اجرای مدل‌ها هستند، دانستن سطح پشتیبانی آن‌ها از معناشناسی زمان اجرا که در زیربندهای مختلف «Semantics» مشخصات شرح داده شده نیز مفید است. با این حال، وجود نقاط تغییرپذیری متعدد در این معناشناسی - و همچنین این واقعیت که این موارد به‌صورت غیرصوری و با زبان طبیعی تعریف شده‌اند - تعریف آن به‌عنوان یک نوع رسمی انطباق را غیرعملی می‌کند، زیرا شمار ترکیب‌های ممکن بسیار زیاد است.

وضعیت مشابهی درباره گزینه‌های ارائه نیز وجود دارد، زیرا پیاده‌سازان مختلف ممکن است در مورد گزینه‌هایی که پشتیبانی می‌کنند انتخاب‌های متفاوتی داشته باشند. همچنین پذیرفته شده است که بعضی پیاده‌سازان و طراحان پروفایل ممکن است بخواهند فقط زیرمجموعه‌ای از قابلیت‌های سطوح بالاتر از سطح انطباق رسمی خود را پشتیبانی کنند. با این حال، آن‌ها فقط می‌توانند نسبت به سطحی ادعای انطباق کنند که آن را به‌طور کامل پشتیبانی می‌کنند، حتی اگر بخش قابل‌توجهی از قابلیت‌های سطوح بالاتر را پیاده‌سازی کرده باشند. با توجه به این تنوع بالقوه، مفید است بتوان به‌صورت روشن و کارآمد مشخص کرد که یک پیاده‌سازی معین از چه قابلیت‌هایی پشتیبانی می‌کند. برای این منظور، افزون بر بیانیه رسمی انطباق، پیاده‌سازان و طراحان پروفایل می‌توانند بیانیه‌های غیررسمی پشتیبانی از قابلیت نیز ارائه کنند. این بیانیه‌ها پشتیبانی از قابلیت‌های اضافی را بر حسب واحدهای زبان و/یا بسته‌های منفرد متامدل، و نیز ابعاد با تعریف کمتر دقیق مانند گزینه‌های ارائه و نقاط تغییرپذیری معنایی مشخص می‌کنند.

نمونه‌ای از بیانیه پشتیبانی قابلیت برای پیاده‌سازی‌ای که بیانیه انطباق آن در جدول 2.1 آمده در جدول 2.2 نشان داده شده است. در این حالت، پیاده‌سازی دو قابلیت جدید از واحد زبان Constructs را که در سطوح بالاتر قرار دارند اضافه می‌کند.

جدول 2.2 - نمونه بیانیه پشتیبانی قابلیت

2.4 محتوای سطوح انطباق

جدول 2.3 بسته‌هایی را که در هر سطح انطباق، علاوه بر بسته‌های تعریف‌شده در سطوح پایین‌تر، اضافه می‌شوند مشخص می‌کند. به‌عنوان یک قاعده، Level N همه بسته‌های پشتیبانی‌شده توسط Level N-1 را نیز در بر می‌گیرد. مجموعه قابلیت‌های واقعی مدل‌سازی که هر بسته اضافه می‌کند در بندهای متناظر واحد زبان مربوطه شرح داده شده است.

جدول 2.3 - بسته‌های متامدل افزوده‌شده به سطوح انطباق

3 مراجع هنجاری

اسناد هنجاری زیر شامل مقرراتی هستند که از طریق ارجاع در این متن، بخشی از مقررات این مشخصات محسوب می‌شوند. برای مراجع دارای تاریخ، اصلاحیه‌ها یا بازنگری‌های بعدی این انتشارات قابل اعمال نیستند.

• UML 2.0: Diagram Interchange
• OCL 2.0
• MOF 2.0: Core Specification
• MOF 2.0: XMI Mapping Specification

4 اصطلاحات و تعاریف

در این مشخصات هیچ تعریف رسمی‌ای که از اسناد دیگر گرفته شده باشد وجود ندارد.

5 نمادها

در این مشخصات هیچ نماد مستقلی تعریف نشده است.

6 اطلاعات تکمیلی

6.1 هم‌ترازی معماری و پشتیبانی از MDA

بند 7، «معماری زبان»، توضیح می‌دهد که UML 2.1.2: Infrastructure از نظر معماری چگونه با UML 2.1.2: Superstructure، که مکمل آن است، هم‌تراز شده است. همچنین توضیح می‌دهد InfrastructureLibrary تعریف‌شده در UML 2.1.2: Infrastructure چگونه می‌تواند به‌صورت سخت‌گیرانه توسط مشخصات MOF 2.0 مورد استفاده مجدد قرار گیرد.

مشخصات MOF 2.0: Core Specification نیز از نظر معماری با این مشخصات هم‌تراز است.

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

6.2 نحوه مطالعه این مشخصات

باقی این سند شامل محتوای فنی مشخصات است. به خوانندگان توصیه می‌شود ابتدا «بخش I - مقدمه» را مطالعه کنند تا با ساختار زبان و رویکرد صوری مورد استفاده برای مشخص‌کردن آن آشنا شوند. پس از آن، خواننده می‌تواند InfrastructureLibrary را که در «بخش II - کتابخانه زیرساخت» توصیف شده بررسی کند، یا بسته UML::Classes::Kernel را که از این کتابخانه مجدداً استفاده می‌کند و در UML 2.1.2: Superstructure شرح داده شده است مطالعه کند. اولی کتابخانه انعطاف‌پذیر متامدلی را مشخص می‌کند که دومی از آن استفاده مجدد می‌کند.

خوانندگانی که می‌خواهند سازه‌های سطح کاربر را که بر مبنای سازه‌های زیرساختی مشخص‌شده در اینجا ساخته شده‌اند بررسی کنند، باید مشخصات مکمل این سند، یعنی UML 2.1.2: Superstructure را مطالعه کنند.

هرچند بندها به‌صورت منطقی سازمان‌دهی شده‌اند و می‌توان آن‌ها را به‌ترتیب خواند، این سند یک مشخصات مرجع است و برای مطالعه غیرترتیبی نیز طراحی شده است. به همین دلیل ارجاعات متقابل فراوانی برای تسهیل مرور و جست‌وجو ارائه شده است.

6.2.1 قالب نمودار

قراردادهای زیر در سراسر این مشخصات برای همه نمودارهای متامدل به کار می‌روند:

• ارتباطی که در یکی از انتهاهای آن پیکان پیمایش‌پذیری وجود دارد به این معناست که:

  • ارتباط در جهت همان انتها قابل پیمایش است؛
  • انتهای علامت‌گذاری‌شده ارتباط در مالکیت classifier قرار دارد؛ و
  • انتهای مقابل و بدون علامت در مالکیت خود association است.

• ارتباطی که هیچ‌یک از انتهای آن با پیکان پیمایش‌پذیری علامت‌گذاری نشده باشد به این معناست که:

  • ارتباط در هر دو جهت قابل پیمایش است؛ و
  • هر انتهای ارتباط در مالکیت classifier واقع در انتهای مقابل قرار دارد؛ یعنی هیچ انتهایی در مالکیت خود association نیست.

• تخصصی‌سازی و بازتعریف association با قیدهای مناسب در نزدیکی انتهای association مربوطه مشخص می‌شوند. بنابراین:

  • قید {subsets endA} یعنی انتهای association که این قید روی آن اعمال شده، تخصصی‌شده انتهای endA است که بخشی از association مورد تخصصی‌سازی است؛
  • قید {redefines endA} یعنی انتهای association که این قید روی آن اعمال شده، انتهای endA را که بخشی از association مورد تخصصی‌سازی است بازتعریف می‌کند.

• اگر روی انتهای association چندیّت نمایش داده نشده باشد، چندیّت دقیقاً 1 فرض می‌شود.

• اگر انتهای association بدون برچسب باشد، نام پیش‌فرض آن انتها نام کلاسی است که انتها به آن متصل شده، با این تغییر که حرف نخست به حرف کوچک تبدیل می‌شود. توجه کنید که طبق قرارداد، انتهای غیرقابل‌پیمایش association اغلب بدون برچسب رها می‌شود، زیرا معمولاً نیازی به اشاره صریح به آن‌ها در متن یا قیود صوری نیست؛ هرچند ممکن است برای اهداف دیگری مانند bindingهای زبان MOF که از متامدل استفاده می‌کنند لازم باشند.

• associationهایی که صریحاً نام‌گذاری نشده‌اند، نامی مطابق قاعده تولید زیر دریافت می‌کنند:

  "A_" <association-end-name1> "_" <association-end-name2>

  که در آن <association-end-name1> نام نخستین انتهای association و <association-end-name2> نام دومین انتهای association است.

• یک dependency بدون برچسب بین دو package به‌عنوان رابطه package import تفسیر می‌شود.

توجه کنید که برخی از این قراردادها برای مقابله با مسائل عملی مربوط به فرایند تولید همین مشخصات اتخاذ شده‌اند، مانند در دسترس نبودن ابزارهای مدل‌سازی منطبق در زمانی که خود مشخصات در حال تعریف بود. ازاین‌رو این قراردادها را نباید لزوماً به‌عنوان توصیه عمومی برای استفاده در همه موارد تلقی کرد.

6.3 سپاسگزاری‌ها

شرکت‌ها و مؤسسات زیر بخش‌هایی از این مشخصات را ارائه کرده و/یا از آن پشتیبانی کرده‌اند:

Adaptive، Boldsoft، Borland Software Corporation، Compuware، Dresden University of Technology، International Business Machines Corp.، IONA، Kabira Technologies, Inc.، Kings College، Klasse Objecten، Oracle، Project Technology, Inc.، Rational Software Corporation، Softeam، Syntropy Ltd.، Telelogic، University of Bremen، University of Kent و University of York.

افراد زیر اعضای تیم اصلی طراحی و نگارش این مشخصات بوده‌اند: Don Baisley، Morgan Björkander، Conrad Bock، Steve Cook، Philippe Desfray، Nathan Dykman، Anders Ek، David Frankel، Eran Gery، Øystein Haugen، Sridhar Iyengar، Cris Kobryn، Birger Møller-Pedersen، James Odell، Gunnar Övergaard، Karin Palmkvist، Guus Ramackers، Jim Rumbaugh، Bran Selic، Thomas Weigert و Larry Williams.

افزون بر این، افراد زیر ایده‌ها و بازخوردهای ارزشمندی ارائه کردند که محتوای این مشخصات و کیفیت آن را به‌طور چشمگیری بهبود بخشید: Colin Atkinson، Ken Baclawski، Mariano Belaunde، Steve Brodsky، Roger Burkhart، Bruce Douglass، Sandy Friedenthal، Sébastien Gerard، Dwayne Hardy، Mario Jeckle، Larry Johnson، Allan Kennedy، Stuart Kent، Mitch Kokar، Thomas Kuehne، Michael Latta، Sumeet Malhotra، Dave Mellor، Jeff Mischkinksky، Hiroshi Miyazaki، Jishnu Mukerji، Ileana Ober، Barbara Price، Tom Rutt، Oliver Sims، Kendall Scott، Cameron Skinner، Jeff Smith، Doug Tolbert و Ian Wilkie.

نویسندگان از Pavel Hruby به‌خاطر stencil ابزار ترسیم UML او که برای ایجاد بسیاری از نمودارهای UML این سند مورد استفاده قرار گرفته است سپاسگزارند.

بخش I - مقدمه

زبان مدل‌سازی یکپارچه یک زبان بصری برای مشخص‌کردن، ساختن و مستندسازی مصنوعات سامانه‌هاست. UML یک زبان مدل‌سازی همه‌منظوره است که می‌تواند همراه با همه روش‌های اصلی شیءگرا و مؤلفه‌محور به کار رود و در تمام حوزه‌های کاربردی، مانند سلامت، مالی، مخابرات و هوافضا، و نیز روی بسترهای پیاده‌سازی مختلف، مانند J2EE و .NET، قابل استفاده است.

OMG مشخصات UML 1.1 را در نوامبر 1997 پذیرفت. از آن زمان، کارگروه‌های بازنگری UML چندین بازنگری جزئی تولید کرده‌اند که جدیدترین آن‌ها تا زمان نگارش این سند، UML 1.4 بوده است که در مه 2001 پذیرفته شد.

UML تحت سرپرستی OMG به زبان مدل‌سازی غالب در صنعت نرم‌افزار تبدیل شده است. این زبان با موفقیت در طیف گسترده‌ای از حوزه‌ها، از سلامت و مالی گرفته تا هوافضا و تجارت الکترونیکی، به کار گرفته شده است. همان‌گونه که انتظار می‌رود، استفاده گسترده از آن مسائل متعدد کاربردی و پیاده‌سازی را از سوی مدل‌سازان و فروشندگان مطرح کرده است. تا زمان نگارش این سند، بیش از 500 مسئله رسمی مربوط به کاربرد و پیاده‌سازی برای بررسی به OMG ارسال شده بود.

اگرچه بسیاری از مسائل در بازنگری‌های جزئی توسط Revision Task Forceها حل شده‌اند، برخی دیگر به تغییرات عمده‌ای در زبان نیاز دارند که خارج از دامنه یک RTF است. در نتیجه، OMG چهار درخواست پیشنهاد (RFP) مکمل و از نظر معماری هم‌تراز منتشر کرد تا UML 2.1.2 تعریف شود: UML 2.1.2 Infrastructure، UML 2.1.2 Superstructure، UML 2.0 Object Constraint Language و UML 2.0 Diagram Interchange.

این مشخصات UML 2.1.2 در دو جلد سازمان‌دهی شده است (UML 2.1.2: Infrastructure و UML 2.1.2: Superstructure) و این تقسیم‌بندی با تفکیک نیازمندی‌های زبان مدل‌سازی در دو RFP یعنی UML 2.0 Infrastructure RFP و UML 2.0 Superstructure RFP سازگار است. چون این دو جلد به یکدیگر ارجاع متقابل دارند و مشخصات آن‌ها کاملاً یکپارچه است، در آینده به‌سادگی می‌توان آن‌ها را در یک جلد واحد ترکیب کرد.

دو بند بعدی معماری زبان و رویکرد مشخصه‌سازی مورد استفاده برای تعریف UML 2.1.2 را توضیح می‌دهند.

7 معماری زبان

مشخصات UML با استفاده از رویکرد متامدل‌سازی تعریف شده است؛ یعنی برای مشخص‌کردن مدلی که UML را تشکیل می‌دهد از یک متامدل استفاده می‌شود. این رویکرد، تکنیک‌های مشخصه‌سازی صوری را با خود تطبیق می‌دهد. هرچند این روش بخشی از سخت‌گیری یک روش مشخصه‌سازی کاملاً صوری را ندارد، برای بیشتر پیاده‌سازان و متخصصان عملی، شهودی‌تر و کاربردی‌تر است. این بند معماری متامدل UML را توضیح می‌دهد.

زیربندهای بعدی اصول طراحی رعایت‌شده را خلاصه می‌کنند و نشان می‌دهند این اصول چگونه برای سازمان‌دهی Infrastructure و Superstructure در UML به کار رفته‌اند. زیربند آخر نیز توضیح می‌دهد که متامدل UML چگونه با الگوی معماری متامدل چهارلایه منطبق است.

یادداشت 1: مهم است توجه شود که مشخص‌کردن UML به‌صورت یک متامدل مانع از آن نیست که در آینده همان زبان با یک زبان ریاضی صوری، مانند Object-Z یا VDM، نیز مشخص شود.

7.1 اصول طراحی

معماری متامدل UML با درنظرگرفتن اصول طراحی زیر شکل گرفته است:

• Modularity (ماژولار بودن) - اصل انسجام قوی و کوپلینگ ضعیف برای گروه‌بندی سازه‌ها در packageها و سازمان‌دهی قابلیت‌ها در metaclassها به کار می‌رود.
• Layering (لایه‌بندی) - لایه‌بندی در متامدل UML به دو شکل استفاده می‌شود. نخست، ساختار package به‌صورت لایه‌ای سازمان‌دهی می‌شود تا سازه‌های هسته فراداده‌ای زبان از سازه‌های سطح بالاتری که از آن‌ها استفاده می‌کنند جدا شوند. دوم، الگوی معماری متامدل چهارلایه به‌طور یکنواخت برای جداسازی دغدغه‌ها، به‌ویژه در ارتباط با نمونه‌سازی، در لایه‌های مختلف انتزاع به کار می‌رود.
• Partitioning (بخش‌بندی) - بخش‌بندی برای سازمان‌دهی حوزه‌های مفهومی در یک لایه استفاده می‌شود. در InfrastructureLibrary بخش‌بندی ریزدانه برای فراهم‌کردن انعطاف مورد نیاز استانداردهای متامدل‌سازی فعلی و آینده به کار رفته است. در خود متامدل UML، بخش‌بندی درشت‌دانه‌تر است تا انسجام درون packageها افزایش و کوپلینگ میان packageها کاهش یابد.
• Extensibility (گسترش‌پذیری) - UML به دو شیوه قابل گسترش است:
  • می‌توان با استفاده از Profiles برای سفارشی‌سازی زبان برای بسترهای مشخص، مانند J2EE/EJB و .NET/COM+، یا حوزه‌های خاص مانند امور مالی، مخابرات و هوافضا، گویشی جدید از UML تعریف کرد.
  • می‌توان با استفاده مجدد از بخشی از package مربوط به InfrastructureLibrary و افزودن metaclassها و metarelationshipهای مناسب، زبانی جدید و مرتبط با UML مشخص کرد. حالت نخست گویشی جدید از UML می‌سازد، در حالی که حالت دوم عضو جدیدی از خانواده زبان‌های UML تعریف می‌کند.
• Reuse (استفاده مجدد) - یک کتابخانه متامدل ریزدانه و انعطاف‌پذیر فراهم شده که برای تعریف متامدل UML و نیز متامدل‌های مرتبط از نظر معماری، مانند Meta Object Facility (MOF) و Common Warehouse Metamodel (CWM)، مورد استفاده مجدد قرار می‌گیرد.

7.2 معماری Infrastructure

Infrastructure در UML توسط InfrastructureLibrary تعریف می‌شود و نیازمندی‌های طراحی زیر را برآورده می‌کند:

• تعریف یک هسته فراداده‌ای زبان که بتوان از آن برای تعریف انواع متامدل‌ها، از جمله UML، MOF و CWM، استفاده مجدد کرد؛
• هم‌ترازکردن معماری UML، MOF و XMI به‌گونه‌ای که تبادل مدل به‌طور کامل پشتیبانی شود؛
• فراهم‌کردن امکان سفارشی‌سازی UML از طریق Profiles و ایجاد زبان‌های جدید، یعنی خانواده‌ای از زبان‌ها، بر پایه همان هسته فراداده‌ای UML.

همان‌گونه که در شکل 7.1 نشان داده شده است، Infrastructure توسط packageای به نام InfrastructureLibrary نمایش داده می‌شود که از packageهای Core و Profiles تشکیل شده است. Profiles سازوکارهای مورد استفاده برای سفارشی‌سازی متامدل‌ها را تعریف می‌کند و Core مفاهیم بنیادی مورد استفاده در متامدل‌سازی را در بر دارد.

7.3 Core

در نخستین نقش خود، package Core یک متامدل کامل است که به‌طور ویژه برای قابلیت استفاده مجدد بالا طراحی شده است؛ به‌گونه‌ای که متامدل‌های دیگر در همان metalevel، یعنی همان سطح فرامدل، metaclassهای مشخص‌شده آن را import یا تخصصی می‌کنند. شکل 7.2 این موضوع را نشان می‌دهد؛ UML، CWM و MOF هر کدام به یک Core مشترک وابسته‌اند. از آنجا که این متامدل‌ها در قلب Model Driven Architecture (MDA) قرار دارند، Core مشترک را می‌توان هسته معماری MDA نیز دانست. هدف این است که UML و دیگر متامدل‌های MDA از تمام یا بخشی از package Core استفاده مجدد کنند؛ در نتیجه متامدل‌های دیگر نیز از نحو انتزاعی و معناشناسی از پیش تعریف‌شده بهره می‌برند.

برای تسهیل استفاده مجدد، package Core به چند package تقسیم شده است: PrimitiveTypes، Abstractions، Basic و Constructs، همان‌گونه که در شکل 7.3 نشان داده شده است. در بندهای بعدی خواهیم دید که برخی از این packageها برای آنکه هنگام تعریف یک متامدل جدید بتوان دقیقاً بخش‌های مرتبط را انتخاب کرد، به packageهای ریزدانه‌تری تقسیم شده‌اند. با این حال، انتخاب یک package مشخص به‌طور ضمنی به معنای انتخاب packageهای وابسته به آن نیز هست.

package PrimitiveTypes صرفاً چند نوع از پیش تعریف‌شده را شامل می‌شود که معمولاً در متامدل‌سازی استفاده می‌شوند و با توجه ویژه به نیازهای UML و MOF طراحی شده است. متامدل‌های دیگر ممکن است به مجموعه‌های متفاوت یا هم‌پوشان از انواع اولیه نیاز داشته باشند. منطق طراحی دو package دیگر تفاوت‌های جزئی دارد. package Abstractions عمدتاً متاکلاس‌های انتزاعی‌ای را شامل می‌شود که قرار است بیشتر تخصصی شوند یا انتظار می‌رود بسیاری از متامدل‌ها از آن‌ها به‌طور مشترک استفاده کنند. درباره متامدل‌هایی که ممکن است بخواهند از این package استفاده مجدد کنند فرض‌های بسیار کمی در نظر گرفته شده است؛ به همین دلیل package Abstractions نیز به چند package کوچک‌تر تقسیم می‌شود. در مقابل، package Constructs عمدتاً متاکلاس‌های عینی‌ای را شامل می‌شود که عمدتاً برای مدل‌سازی شیءگرا مناسب‌اند. این package به‌طور خاص هم توسط MOF و هم UML مورد استفاده مجدد قرار می‌گیرد و بخش قابل‌توجهی از تلاش انجام‌شده برای هم‌ترازی دو متامدل را نمایندگی می‌کند. package Basic چند سازه را در بر می‌گیرد که به‌عنوان مبنای XMI تولیدشده برای UML، MOF و دیگر متامدل‌های مبتنی بر InfrastructureLibrary استفاده می‌شوند.

در نقش دوم، package Core برای تعریف سازه‌های مدل‌سازی مورد استفاده در ایجاد متامدل‌ها به کار می‌رود. این کار از طریق نمونه‌سازی metaclassهای موجود در InfrastructureLibrary انجام می‌شود؛ به بخش 7.9 «لایه‌بندی متامدل» در صفحه 16 مراجعه کنید. هرچند نمونه‌سازی metaclassها از طریق MOF انجام می‌شود، InfrastructureLibrary خود metaclassهایی را تعریف می‌کند که برای نمونه‌سازی عناصر UML، MOF، CWM و حتی عناصر خود InfrastructureLibrary استفاده می‌شوند. از این منظر گفته می‌شود InfrastructureLibrary خودتوصیف یا reflective است.

7.4 Profiles

همان‌گونه که در شکل 7.1 نشان داده شد، package Profiles به package Core وابسته است و سازوکارهایی را تعریف می‌کند که برای انطباق متامدل‌های موجود با بسترهای خاص مانند C++، CORBA یا EJB، یا با حوزه‌هایی مانند سامانه‌های بلادرنگ، اشیای کسب‌وکار یا مدل‌سازی فرایند نرم‌افزار استفاده می‌شوند. هدف اصلی profileها UML است، اما می‌توان profileها را همراه با هر متامدلی که بر پایه Core مشترک ساخته شده، یعنی از آن نمونه‌سازی شده، به کار برد. یک profile باید بر پایه متامدلی مانند UML که آن را گسترش می‌دهد قرار داشته باشد و به‌تنهایی کاربرد زیادی ندارد.

Profileها با سازوکار گسترش ارائه‌شده توسط MOF هم‌تراز شده‌اند، اما رویکردی سبک‌تر با محدودیت‌هایی فراهم می‌کنند که برای تضمین سادگی پیاده‌سازی و استفاده از profileها و پشتیبانی آسان‌تر آن‌ها توسط فروشندگان ابزار اعمال می‌شوند.

7.5 هم‌ترازی معماری میان UML و MOF

یکی از اهداف مهم Infrastructure، هم‌ترازکردن UML و MOF از نظر معماری بوده است. نخستین رویکرد برای دستیابی به این هدف، تعریف Core مشترک - که در قالب package Core تحقق یافته - به‌گونه‌ای بوده که عناصر مدل میان UML و MOF مشترک باشند. رویکرد دوم، اطمینان از این بوده است که UML به‌صورت مدلی تعریف شود که بر MOF به‌عنوان متامدل متکی است؛ همان‌گونه که در شکل 7.4 نشان داده شده است. توجه کنید که MOF نه‌تنها متامدل UML، بلکه متامدل زبان‌های دیگری مانند CWM نیز هست.

نحوه کار این سلسله‌مراتب metalevel در بخش 7.6 «معماری Superstructure» در صفحه 14 با جزئیات بیشتری توضیح داده می‌شود. نکته مهم آن است که هر model element در UML دقیقاً نمونه یک model element در MOF است. همچنین InfrastructureLibrary هم در metalevel M2 و هم در M3 استفاده می‌شود، زیرا همان‌گونه که در شکل 7.2 نشان داده شد، UML و MOF هر یک به‌ترتیب از آن استفاده مجدد می‌کنند. در مورد MOF، metaclassهای InfrastructureLibrary بدون تغییر استفاده می‌شوند، در حالی که در UML به این model elementها ویژگی‌های بیشتری افزوده می‌شود. دلیل این تفاوت آن است که نیازمندی‌های متامدل‌سازی اندکی با نیازمندی‌های مدل‌سازی کاربردهایی با ماهیت بسیار متنوع تفاوت دارد.

برای مثال، MOF تعیین می‌کند مدل‌های UML چگونه با استفاده از XML Metadata Interchange (XMI) میان ابزارها مبادله شوند. MOF همچنین interfaceهای reflective با نام MOF::Reflection را برای درون‌نگری تعریف می‌کند که نه‌تنها برای خود MOF، بلکه برای CWM، UML و هر متامدل دیگری که نمونه‌ای از MOF باشد کار می‌کنند. افزون بر این، MOF سازوکار گسترشی تعریف می‌کند که می‌تواند به‌عنوان جایگزین profileها یا همراه آن‌ها برای گسترش متامدل‌ها به کار رود؛ همان‌گونه که در بند 13، Core::Profiles، شرح داده شده است. در واقع، profileها به‌عنوان زیرمجموعه‌ای از سازوکار گسترش MOF تعریف شده‌اند.

7.6 معماری Superstructure

متامدل UML Superstructure توسط package UML مشخص می‌شود که به چند package مربوط به مدل‌سازی ساختاری و رفتاری تقسیم شده است، همان‌گونه که در شکل 7.5 نشان داده می‌شود.

هر یک از این حوزه‌ها در بندی جداگانه از مشخصات UML 2.1.2: Superstructure شرح داده شده است. توجه کنید که برخی packageها وابستگی دوری به یکدیگر دارند. دلیل آن این است که وابستگی‌های میان packageهای سطح بالا خلاصه‌ای از همه روابط میان subpackageهای آن‌ها را نشان می‌دهند؛ میان subpackageهای آن packageها هیچ وابستگی دوری وجود ندارد.

7.7 استفاده مجدد از Infrastructure

یکی از کاربردهای اصلی مشخصات UML 2.1.2 Infrastructure این است که هنگام ایجاد متامدل‌های دیگر مورد استفاده مجدد قرار گیرد. متامدل UML به دو شیوه متفاوت از InfrastructureLibrary استفاده مجدد می‌کند:

• کل متامدل UML از meta-metaclassهایی که در InfrastructureLibrary تعریف شده‌اند نمونه‌سازی می‌شود.
• متامدل UML همه metaclassهای موجود در InfrastructureLibrary را import و تخصصی می‌کند.

همان‌گونه که پیش‌تر بحث شد، یک مدل می‌تواند به‌عنوان متامدل مورد استفاده قرار گیرد و در اینجا از همین واقعیت استفاده می‌شود. InfrastructureLibrary در یک نقش به‌عنوان meta-metamodel و در نقش دیگر به‌عنوان metamodel استفاده می‌شود و بنابراین در دو بُعد مورد استفاده مجدد قرار می‌گیرد.

7.8 package Kernel

InfrastructureLibrary عمدتاً در package Kernel از بخش Classes در UML 2.1.2: Superstructure مورد استفاده مجدد قرار می‌گیرد. این کار با گردهم‌آوردن packageهای مختلف Infrastructure از طریق package merge انجام می‌شود. Kernel در قلب UML قرار دارد و metaclassهای تمام packageهای دیگر به‌طور مستقیم یا غیرمستقیم به آن وابسته‌اند. package Kernel بسیار شبیه package Constructs در InfrastructureLibrary است، اما قابلیت‌های بیشتری به سازه‌های مدل‌سازی می‌افزاید که برای اهداف استفاده مجدد یا هم‌ترازی با MOF لازم نبودند در Constructs گنجانده شوند.

از آنجا که Infrastructure برای استفاده مجدد طراحی شده است، برخی metaclassها - به‌ویژه در Abstractions - به‌صورت جزئی در چند package متفاوت تعریف شده‌اند. این جنبه‌های متفاوت عمدتاً در Constructs در یک metaclass واحد گردآوری می‌شوند، اما در برخی موارد این کار تنها در Kernel انجام می‌شود. به‌طور کلی، اگر metaclassهایی با نام یکسان در چند package ظاهر شوند، منظور آن است که همان metaclass را نمایش می‌دهند و هر package که آن metaclass در آن تعریف یا تخصصی شده، یک factorization مشخص را نشان می‌دهد. همین الگوی تعریف‌های جزئی در Superstructure نیز دیده می‌شود؛ جایی که برخی جنبه‌های metaclassهایی مانند Class در packageهای جداگانه تفکیک می‌شوند تا نقاط انطباق تشکیل شود.

7.9 لایه‌بندی متامدل

معماری متمرکز بر package Core، نمای مکملی از سلسله‌مراتب چهارلایه متامدل است که متامدل UML به‌طور سنتی بر آن بنا شده است. هنگام کار با meta-layerها برای تعریف زبان‌ها، معمولاً سه لایه وجود دارند که همیشه باید در نظر گرفته شوند:

1. مشخصات زبان، یا metamodel؛
2. مشخصات کاربر، یا model؛
3. اشیای model.

این ساختار را می‌توان به‌صورت بازگشتی بارها اعمال کرد، به‌گونه‌ای که در حالت نظری تعداد نامتناهی meta-layer ایجاد شود. چیزی که در یک حالت metamodel است می‌تواند در حالت دیگری model باشد؛ دقیقاً همان اتفاقی که درباره UML و MOF رخ می‌دهد. UML یک مشخصات زبان، یعنی metamodel، است که کاربران می‌توانند از آن برای تعریف modelهای خود استفاده کنند. MOF نیز یک مشخصات زبان یا metamodel است که کاربران می‌توانند بر پایه آن modelهای خود را تعریف کنند. اما از دید MOF، UML به‌عنوان مشخصات یک کاربر - یعنی اعضای OMG که زبان را توسعه داده‌اند - دیده می‌شود که بر MOF به‌عنوان مشخصات زبان متکی است. در سلسله‌مراتب چهارلایه متامدل، معمولاً به MOF «meta-metamodel» گفته می‌شود، هرچند به معنای دقیق کلمه خود یک metamodel است.

7.10 سلسله‌مراتب چهارلایه متامدل

لایه meta-metamodeling پایه سلسله‌مراتب metamodeling را تشکیل می‌دهد. مسئولیت اصلی این لایه تعریف زبانی برای مشخص‌کردن یک metamodel است. این لایه معمولاً M3 نامیده می‌شود و MOF نمونه‌ای از یک meta-metamodel است. یک meta-metamodel معمولاً فشرده‌تر از metamodelی است که توصیف می‌کند و اغلب چند metamodel را تعریف می‌کند. به‌طور کلی مطلوب است metamodelها و meta-metamodelهای مرتبط فلسفه‌ها و سازه‌های طراحی مشترکی داشته باشند. با این حال، هر لایه را می‌توان مستقل از لایه‌های دیگر در نظر گرفت و هر لایه باید انسجام طراحی خودش را حفظ کند.

یک metamodel نمونه‌ای از یک meta-metamodel است؛ یعنی هر عنصر metamodel نمونه‌ای از عنصری در meta-metamodel است. مسئولیت اصلی لایه metamodel تعریف زبانی برای مشخص‌کردن modelهاست. این لایه معمولاً M2 نامیده می‌شود؛ UML و OMG Common Warehouse Metamodel (CWM) نمونه‌هایی از metamodel هستند. metamodelها معمولاً از meta-metamodelهایی که آن‌ها را توصیف می‌کنند مفصل‌ترند، به‌ویژه وقتی معناشناسی پویا را تعریف می‌کنند. متامدل UML نمونه‌ای از MOF است؛ در عمل، هر metaclass در UML نمونه‌ای از یک عنصر در InfrastructureLibrary است.

یک model نمونه‌ای از یک metamodel است. مسئولیت اصلی لایه model تعریف زبان‌هایی است که حوزه‌های معنایی را توصیف می‌کنند؛ یعنی به کاربران امکان می‌دهد طیف گسترده‌ای از حوزه‌های مسئله، مانند نرم‌افزار، فرایندهای کسب‌وکار و نیازمندی‌ها را مدل‌سازی کنند. چیزهایی که مدل می‌شوند خارج از سلسله‌مراتب metamodel قرار دارند. این لایه معمولاً M1 نامیده می‌شود. یک model کاربر نمونه‌ای از metamodel UML است. توجه کنید که model کاربر هم model elementها و هم snapshotهایی، یعنی تصویرهایی، از instanceهای این model elementها را در بر دارد.

سلسله‌مراتب metamodel در M0 خاتمه می‌یابد؛ جایی که instanceهای زمان اجرای model elementهای تعریف‌شده در model قرار دارند. snapshotهایی که در M1 مدل می‌شوند نسخه‌های محدودشده‌ای از instanceهای زمان اجرای M0 هستند.

هنگام کار با بیش از سه meta-layer، معمولاً لایه‌های بالاتر از M2 هرچه بالاتر می‌روند کوچک‌تر و فشرده‌تر می‌شوند. در مورد MOF که در M3 قرار دارد، در نتیجه فقط بخشی از metaclassهای تعریف‌شده در UML را با آن مشترک است. یکی از ویژگی‌های خاص metamodeling امکان تعریف زبان‌های reflective است؛ یعنی زبان‌هایی که می‌توانند برای تعریف خودشان استفاده شوند. InfrastructureLibrary نمونه‌ای از این موضوع است، زیرا تمام metaclassهای مورد نیاز برای تعریف خودش را در بر دارد. MOF نیز reflective است چون بر InfrastructureLibrary استوار است و بنابراین می‌تواند برای تعریف خودش به کار رود. به همین دلیل هیچ meta-layer اضافی بالاتر از MOF تعریف نشده است.

7.11 متامدل‌سازی

در metamodeling، تمایز اصلی میان metamodel و model است. همان‌طور که گفته شد، modelی که از یک metamodel نمونه‌سازی شده می‌تواند به‌صورت بازگشتی خود به‌عنوان metamodel برای model دیگری استفاده شود. یک model معمولاً شامل model elementهاست. این عناصر با نمونه‌سازی model elementهای موجود در metamodel، یعنی metamodel elementها، ایجاد می‌شوند.

نقش معمول یک metamodel تعریف معناشناسی چگونگی نمونه‌سازی model elementها در یک model است. برای مثال، شکل 7.6 را در نظر بگیرید؛ در آن، metaclassهای Association و Class هر دو به‌عنوان بخشی از metamodel UML تعریف شده‌اند. این metaclassها در یک model کاربر به‌گونه‌ای نمونه‌سازی می‌شوند که کلاس‌های Person و Car هر دو نمونه‌هایی از metaclass Class باشند و association با نام Person.car میان این دو کلاس نمونه‌ای از metaclass Association باشد. معناشناسی UML تعیین می‌کند هنگام نمونه‌سازی model elementهای تعریف‌شده توسط کاربر در M0 چه اتفاقی رخ دهد: یک instance از Person، یک instance از Car و یک link - یعنی instanceی از association - میان آن‌ها ایجاد می‌شود.

instanceهایی که در M0 از چیزهایی مانند Person ایجاد می‌شوند و گاهی «instanceهای زمان اجرا» نامیده می‌شوند، نباید با instanceهای metaclass InstanceSpecification که خود بخشی از metamodel UML است اشتباه شوند. یک instance از InstanceSpecification در همان سطح modelی تعریف می‌شود که model element مورد نمایش آن قرار دارد. شکل 7.7 این موضوع را نشان می‌دهد؛ Mike یک instance specification است که یک illustration یا snapshot از instance کلاس Person را نمایش می‌دهد.

7.12 نمونه‌ای از سلسله‌مراتب چهارسَطحی متامدل

شکل 7.8 نحوه ارتباط این meta-layerها با یکدیگر را نشان می‌دهد. باید توجه داشت که به هیچ وجه به همین چهار meta-layer محدود نیستیم و تعریف لایه‌های اضافی نیز امکان‌پذیر است. همان‌گونه که در شکل نشان داده شده، meta-layerها معمولاً از M0 به بالا شماره‌گذاری می‌شوند و این شماره‌گذاری به تعداد meta-layerهای مورد استفاده بستگی دارد. در این مورد خاص، شماره‌گذاری تا M3 ادامه دارد که متناظر با MOF است.

در این شکل، در سطح M3 (MOF) عنصر Class قرار دارد؛ در سطح M2 (UML) عناصری مانند Attribute، Class، classifier و Instance قرار دارند؛ در سطح M1 (User model) کلاس Video با ویژگی +title: String و snapshot متناظر :Video با مقدار title = "2001: A Space Odyssey" نمایش داده شده است؛ و در سطح M0 (Run-time instances) نمونه aVideo قرار دارد. روابط instanceOf میان سطوح، رابطه نمونه‌بودن عناصر هر سطح نسبت به metaclassهای سطح بالاتر را نشان می‌دهند.

8 صورت‌بندی زبان

مشخصات UML با استفاده از رویکرد متامدل‌سازی تعریف می‌شود که تکنیک‌های مشخصه‌سازی صوری را با خود تطبیق می‌دهد. تکنیک‌های صوری برای افزایش دقت و صحت مشخصات به کار می‌روند. این بند تکنیک‌هایی را توضیح می‌دهد که برای تعریف UML استفاده شده‌اند.

اهداف تکنیک‌های مشخصه‌سازی مورد استفاده برای تعریف UML عبارت‌اند از:

• Correctness (صحت) - تکنیک‌های مشخصه‌سازی باید با کمک به اعتبارسنجی متامدل، صحت آن را بهبود دهند. برای مثال، قواعد خوش‌ساختی باید به اعتبارسنجی نحو انتزاعی و شناسایی خطاها کمک کنند.
• Precision (دقت) - تکنیک‌ها باید دقت نحو و معناشناسی را افزایش دهند. این دقت باید به اندازه‌ای باشد که برای پیاده‌سازان و کاربران هیچ ابهام نحوی یا معنایی باقی نماند.¹
• Conciseness (ایجاز) - تکنیک‌ها باید مقتصدانه باشند تا نحو و معناشناسی دقیق بدون جزئیات زائد تعریف شوند.
• Consistency (سازگاری) - تکنیک‌ها باید رویکرد متامدل‌سازی را با افزودن جزئیات ضروری به‌شکل سازگار تکمیل کنند.
• Understandability (قابل‌فهم‌بودن) - تکنیک‌ها ضمن افزایش دقت و ایجاز باید خوانایی مشخصات را نیز بهتر کنند. به همین دلیل صورت‌بندی‌ای با سخت‌گیری کمتر از یک روش کاملاً صوری به کار رفته است، زیرا صورت‌بندی سخت‌گیرانه به تکنیک‌های رسمی کامل نیاز داشت.

تکنیک مشخصه‌سازی مورد استفاده، متامدل را در سه نما و با استفاده از ارائه‌های متنی و گرافیکی توصیف می‌کند.

باید توجه داشت که توصیف فعلی یک مشخصات کاملاً صوری از زبان نیست؛ زیرا انجام این کار پیچیدگی قابل‌توجهی ایجاد می‌کرد بدون آنکه منفعت روشنی داشته باشد.

با این حال، ساختار زبان با دقت مشخص شده است و این دقت برای تعامل‌پذیری ابزارها ضروری است. معناشناسی تفصیلی با استفاده از زبان طبیعی اما به‌شکلی دقیق توصیف شده تا به‌آسانی قابل درک باشد. در حال حاضر معناشناسی برای توسعه ابزارها ضروری تلقی نمی‌شود؛ هرچند احتمالاً این وضعیت در آینده تغییر خواهد کرد.

یادداشت 1: بنا بر تعریف، semantic variation pointها استثنای این قاعده‌اند.

8.1 سطوح صوری‌بودن

یک روش رایج برای مشخص‌کردن زبان‌ها آن است که ابتدا نحو زبان تعریف و سپس معناشناسی ایستا و پویا شرح داده شود. نحو تعیین می‌کند چه سازه‌هایی در زبان وجود دارند و هر سازه چگونه بر پایه سازه‌های دیگر ساخته می‌شود. گاهی، به‌ویژه اگر زبان نحو گرافیکی داشته باشد، مهم است نحو به‌صورت مستقل از نمادگذاری تعریف شود؛ یعنی نحو انتزاعی زبان مشخص گردد. سپس نحو عینی با نگاشت نمادگذاری روی نحو انتزاعی تعریف می‌شود.

معناشناسی ایستای یک زبان مشخص می‌کند یک instance از یک سازه چگونه باید به instanceهای دیگر متصل شود تا معنادار باشد، و معناشناسی پویا معنای یک سازه خوش‌ساخت را تعریف می‌کند. معنای یک توصیف نوشته‌شده در زبان تنها زمانی تعریف‌شده است که آن توصیف خوش‌ساخت باشد؛ یعنی قواعد تعریف‌شده در معناشناسی ایستا را برآورده کند.

این مشخصات برای توصیف نحو انتزاعی و معناشناسی UML کامل از ترکیبی از زبان‌ها استفاده می‌کند: زیرمجموعه‌ای از UML، یک زبان قید، و زبان طبیعی دقیق. توصیف خودکفاست و برای خواندن سند به منبع اطلاعاتی دیگری نیاز نیست.² هرچند این توصیف metacircular است،³ درک سند عملی است، زیرا برای توصیف معناشناسی آن فقط زیرمجموعه کوچکی از سازه‌های UML لازم است.

در ساخت متامدل UML، برای مشخص‌کردن سازه‌های زبان از تکنیک‌های متفاوت و از برخی قابلیت‌های UML استفاده شده است. سازه‌های اصلی زبان به‌شکل metaclass در متامدل reify شده‌اند. سازه‌های دیگری که در اصل variantهایی از سازه‌های دیگر هستند، به‌عنوان stereotypeهای metaclassهای موجود در متامدل تعریف می‌شوند. این سازوکار اجازه می‌دهد معناشناسی سازه variant به‌طور چشمگیری با metaclass پایه تفاوت داشته باشد. روش سبک‌تر دیگری برای تعریف variantها استفاده از metaattribute است. برای مثال، سازه aggregation با یک attribute از metaclass AssociationEnd مشخص می‌شود که تعیین می‌کند یک association یک aggregate عادی، composite aggregate یا association معمولی است.

یادداشت 2: هرچند درک معماری چهارلایه متامدل UML و meta-metamodel زیربنایی آن مفید است، برای فهم معناشناسی UML ضروری نیست.
یادداشت 3: برای درک توصیف معناشناسی UML لازم است بخشی از معناشناسی UML را از پیش بدانید.

8.2 ساختار مشخصات package

این زیربند برای هر package و هر class در metamodel UML اطلاعات ارائه می‌کند. هر package دارای یک یا چند زیربند از انواع زیر است.

8.2.1 توصیف کلاس‌ها

این زیربند فهرستی از classهایی را شامل می‌شود که سازه‌های تعریف‌شده در package را مشخص می‌کنند. بخش با یک یا چند نمودار آغاز می‌شود که نحو انتزاعی سازه‌ها - یعنی classها و روابط میان آن‌ها - را در package همراه با بخشی از نیازمندی‌های خوش‌ساختی مانند multiplicity و ordering نشان می‌دهند. سپس مشخصات هر class به‌ترتیب الفبایی ارائه می‌شود.

8.2.2 نمودارها

اگر سازه‌های تعریف‌شده در package معمولاً با نوع مشخصی از نمودار نمایش داده شوند، زیربندی برای توصیف آن نوع نمودار افزوده می‌شود.

8.2.3 مدل instance

ممکن است مثالی برای نشان‌دادن نحوه پرشدن یک instance model از classهای موجود ارائه شود. عناصر مثال instanceهایی از classهای موجود در package یا یک package واردشده هستند.

8.3 ساختار مشخصات class

مشخصات یک class با ارائه معنای کلی مفهوم آغاز می‌شود تا زمینه لازم برای تعریف آن فراهم گردد.

8.3.1 توصیف

این زیربند تعریف غیررسمی metaclassی را ارائه می‌کند که سازه موردنظر در UML را مشخص می‌کند. همچنین مشخص می‌کند که آیا metaclass انتزاعی است یا نه. این زیربند همراه با دو زیربند بعدی توصیف نحو انتزاعی سازه را تشکیل می‌دهد.

8.3.2 ویژگی‌ها

هر یک از attributeهای class همراه با توضیحی کوتاه فهرست می‌شود. زیربند مشخص می‌کند که آیا attribute مشتق‌شده است یا تخصصی‌شده attribute دیگری. اگر multiplicity ویژگی مقدار پیش‌فرض 1 در UML باشد، نمایش آن حذف می‌شود.

8.3.3 associationها

انتهای مقابل associationهایی که به class متصل هستند نیز به همین شیوه فهرست می‌شوند. مشخص می‌شود آیا association مشتق‌شده است یا تخصصی‌شده association دیگری. اگر multiplicity یک association end برابر *، مقدار پیش‌فرض در UML، باشد، نمایش آن حذف می‌شود.

هنگامی که به‌جای attribute از directed association استفاده می‌شود، multiplicity در انتهای بدون جهت * فرض می‌شود و نام role نباید استفاده شود.

8.3.4 قیود

قواعد خوش‌ساختی metaclass - به‌جز قیدهای multiplicity و ordering که در نمودار ابتدای زیربند package تعریف شده‌اند - به‌صورت مجموعه‌ای، احتمالاً تهی، از invariantها برای metaclass تعریف می‌شوند. تمام instanceهای آن metaclass باید این invariantها را برآورده کنند تا model معنادار باشد. بنابراین قواعد، قیدهایی را روی attributeها و associationهای تعریف‌شده در metamodel مشخص می‌کنند. بیشتر invariantها با عبارت‌های OCL همراه با توضیح غیررسمی عبارت تعریف می‌شوند، اما در برخی موارد invariantها به روش‌های دیگری، و در موارد استثنایی با زبان طبیعی، بیان می‌شوند. عبارت «No additional constraints» به این معناست که همه قواعد خوش‌ساختی در superclassها همراه با اطلاعات multiplicity و type موجود در نمودارها بیان شده‌اند.

8.3.5 عملیات اضافی (اختیاری)

در بسیاری از موارد برای عبارت‌های OCL به عملیات اضافی روی classها نیاز است. این عملیات پس از قیود سازه در زیربندی جداگانه تعریف می‌شوند و همان رویکرد زیربند Constraints را دنبال می‌کنند: ابتدا توضیحی غیررسمی و سپس عبارت OCL که operation را تعریف می‌کند.

8.3.6 معناشناسی

معنای یک سازه خوش‌ساخت با استفاده از زبان طبیعی تعریف می‌شود.

8.3.7 نقاط تغییرپذیری معنایی (اختیاری)

اصطلاح semantic variation point در سراسر این سند برای بخشی از مشخصات UML به کار می‌رود که هدف آن در کل مشخصات معلوم است اما شکل یا معناشناسی آن می‌تواند به‌نوعی تغییر کند. هدف یک semantic variation point فراهم‌کردن امکان تخصصی‌سازی آن بخش از UML برای وضعیت یا حوزه‌ای خاص است.

semantic variation pointها در استاندارد به چند شکل ظاهر می‌شوند:

semantic variation pointها در استاندارد به شکل‌های زیر ظاهر می‌شوند:

• پیش‌فرض قابل تغییر - در این حالت، استاندارد یک مشخصات پیش‌فرض واحد برای semantic variation point ارائه می‌کند، اما می‌توان آن را جایگزین کرد. برای مثال، استاندارد مجموعه‌ای پیش‌فرض از قواعد برای تخصصی‌سازی state machineها ارائه می‌کند، ولی این پیش‌فرض می‌تواند، مثلاً در یک profile، با مجموعه قواعد متفاوتی جایگزین شود. انتخاب معمولاً به تعریف مورد استفاده از سازگاری رفتاری بستگی دارد.
• انتخاب چندگانه - در این حالت، استاندارد چند گزینه ممکن و متقابلاً ناسازگار را به‌طور صریح مشخص می‌کند که ممکن است یکی از آن‌ها به‌عنوان پیش‌فرض علامت‌گذاری شود. طراحان زبان می‌توانند یکی از این گزینه‌ها را انتخاب کنند یا گزینه جدیدی تعریف نمایند. نمونه این نوع variation point در نحوه برخورد با رویدادهای غیرمنتظره در state machineها دیده می‌شود؛ گزینه‌ها شامل نادیده‌گرفتن رویداد به‌عنوان حالت پیش‌فرض، رد صریح آن، یا به‌تعویق‌انداختن آن است.
• تعریف‌نشده - در این حالت، استاندارد هیچ مشخصات از پیش تعریف‌شده‌ای برای semantic variation point ارائه نمی‌کند. برای نمونه، قواعد انتخاب متدی که هنگام فراخوانی یک operation چندریختی اجرا شود در استاندارد تعریف نشده‌اند.

8.3.8 نمادگذاری

نمادگذاری سازه در این زیربند ارائه می‌شود.

8.3.9 گزینه‌های ارائه (اختیاری)

اگر روش‌های متفاوتی برای نمایش سازه وجود داشته باشد - برای مثال لازم نباشد تمام بخش‌های سازه در هر بار ظهور نشان داده شوند - این امکان‌ها در این زیربند شرح داده می‌شوند.

8.3.10 رهنمودهای سبک (اختیاری)

اغلب هنگام نمایش بخشی از model از قراردادهای غیرهنجاری استفاده می‌شود. برای مثال، یکی از این قراردادها آن است که نام یک class همیشه به‌صورت پررنگ و در مرکز مستطیل class نمایش داده شود.

8.3.11 مثال‌ها (اختیاری)

در این زیربند نمونه‌هایی از نحوه نمایش سازه ارائه می‌شود.

8.3.12 منطق طراحی (اختیاری)

اگر دلیلی وجود داشته باشد که چرا یک سازه به شکل خاصی تعریف شده یا چرا نمادگذاری آن به این صورت است، آن دلیل در این زیربند ارائه می‌شود.

8.3.13 تغییرات نسبت به UML 1.4

در این بخش تغییرات نسبت به UML 1.4 شرح داده می‌شود و رویکرد مهاجرت از 1.4 به 2.0 مشخص می‌گردد.

8.4 استفاده از زبان قید

این مشخصات برای بیان قواعد خوش‌ساختی از Object Constraint Language (OCL) مطابق تعریف بند 6، «Object Constraint Language Specification» در مشخصات UML 1.4 استفاده می‌کند. برای افزایش خوانایی، قراردادهای زیر به کار می‌روند:

• Self - که می‌تواند به‌عنوان ارجاع به metaclass تعریف‌کننده context invariant حذف شود - برای وضوح حفظ شده است.
• در expressionهایی که روی یک collection پیمایش انجام می‌شود، برای وضوح از iterator استفاده می‌شود حتی اگر از نظر صوری لازم نباشد. type مربوط به iterator معمولاً حذف می‌شود، مگر آنکه درج آن به فهم بهتر کمک کند.
• operation با نام collect هرجا عملی باشد به‌صورت ضمنی در نظر گرفته می‌شود.
• بخش context یک constraint در OCL به‌طور صریح درج نمی‌شود، زیرا در زیربندی که constraint در آن ظاهر شده به‌روشنی مشخص است.

8.5 استفاده از زبان طبیعی

تلاش شده در استفاده از زبان طبیعی - در اینجا زبان انگلیسی - دقت رعایت شود. برای مثال، توصیف معناشناسی UML شامل عبارت‌هایی مانند «X امکان ... را فراهم می‌کند» و «X یک Y است» می‌شود. در هر مورد، معنای معمول زبان انگلیسی فرض می‌شود، هرچند یک توصیف کاملاً صوری مستلزم تعریف معناشناسی حتی همین عبارت‌های ساده است.

قواعد عمومی زیر اعمال می‌شوند:

• هنگام اشاره به instance یک metaclass، اغلب واژه instance حذف می‌شود. برای مثال، به‌جای عبارت «a Class instance» یا «an Association instance»، صرفاً گفته می‌شود «a Class» یا «an Association». وجود حرف تعریف نامعین a یا an باید به معنای «یک instance از» فهمیده شود. به همین ترتیب، عبارتی مانند «Elements» به معنای «یک مجموعه، یا مجموعه، از instanceهای metaclass Element» است.
• هر بار واژه‌ای که با نام یکی از سازه‌های UML منطبق است استفاده شود، منظور همان سازه است.
• اصطلاحاتی که یکی از پیشوندهای sub، super یا meta را دارند به‌صورت یک واژه نوشته می‌شوند، مانند metamodel و subclass.

8.6 قراردادها و حروف‌چینی

در توصیف UML قراردادهای زیر استفاده شده‌اند:

• هنگام اشاره به سازه‌های UML، نه نمایش آن‌ها در metamodel، از متن عادی استفاده می‌شود.
• نام metaclassهایی که از ترکیب اسم‌ها/صفت‌ها تشکیل شده‌اند با capital داخلی نوشته می‌شوند، مانند ModelElement و StructuralFeature.
• نام metaassociationها نیز به همان شیوه metaclassها نوشته می‌شود، مانند ElementReference.
• برای نام‌هایی که از ترکیب اسم‌ها/صفت‌ها ساخته شده‌اند از حرف بزرگ داخلی استفاده می‌شود، مانند ownedElement و allContents.
• نام metaattributeهای Boolean همیشه با is آغاز می‌شود، مانند isAbstract.
• نام typeهای enumeration همیشه با Kind پایان می‌یابد، مانند AggregationKind.
• هنگام اشاره به metaclassها، metaassociationها، metaattributeها و موارد مشابه در متن، دقیقاً همان نام‌هایی که در model ظاهر می‌شوند استفاده می‌شود.
• هیچ visibilityای در نمودارها نمایش داده نمی‌شود، زیرا همه عناصر public هستند.
• اگر یک بخش اجباری برای یک metaclass کاربرد نداشته باشد، متن No additional XXX استفاده می‌شود که در آن XXX نام heading مربوطه است. اگر یک بخش اختیاری کاربرد نداشته باشد، اصلاً درج نمی‌شود.

برای notationهای متنی اغلب از گونه‌ای از Backus-Naur Form (BNF) برای مشخص‌کردن قالب‌های مجاز استفاده می‌شود. قراردادهای این BNF عبارت‌اند از:

• همه non-terminalها ایتالیک و میان angle bracket قرار می‌گیرند، مانند <non-terminal>.
• همه terminalها، از جمله keywordها و stringها، میان single quote قرار می‌گیرند، مانند 'or'.
• تعریف production rule برای non-terminal با operator ::= مشخص می‌شود.
• تکرار یک item با قرار دادن * پس از آن item مشخص می‌شود.
• گزینه‌های جایگزین در یک production با نماد | از یکدیگر جدا می‌شوند؛ برای مثال: <alternative-A> | <alternative-B>.
• itemهای اختیاری در square bracket قرار می‌گیرند، مانند [<item-x>].
• هرجا لازم باشد itemها گروه‌بندی شوند در parenthesis ساده قرار می‌گیرند. برای مثال، (<item-1> | <item-2>)* دنباله‌ای از صفر یا چند item را نشان می‌دهد که هر یک <item-1> یا <item-2> است.

بخش II - کتابخانه Infrastructure

این بخش ساختار و محتوای Infrastructure Library برای متامدل UML و متامدل‌های مرتبط مانند Meta Object Facility (MOF) و Common Warehouse Metamodel (CWM) را شرح می‌دهد. package InfrastructureLibrary یک هسته فراداده‌ای قابل استفاده مجدد و یک سازوکار گسترش metamodel برای UML تعریف می‌کند. هسته فراداده‌ای را می‌توان برای مشخص‌کردن انواع metamodelها از جمله UML، MOF و CWM به کار برد. علاوه بر این، کتابخانه سازوکار گسترش profile را تعریف می‌کند که با آن می‌توان UML را برای platformها و domainهای متفاوت بدون پشتیبانی از قابلیت کامل metamodeling سفارشی کرد. packageهای سطح بالای InfrastructureLibrary در شکل زیر نشان داده شده‌اند.

شکل بخش II-1 - package متامدل Library شامل packageهای Core و Profiles است

package Core بخش مرکزی و قابل استفاده مجدد InfrastructureLibrary است و مطابق شکل بعدی به بخش‌های کوچک‌تری تقسیم می‌شود.

شکل بخش II-2 - package Core شامل packageهای PrimitiveTypes، Abstractions، Basic و Constructs است

package PrimitiveTypes یک package ساده است که تعدادی type از پیش تعریف‌شده را در بر دارد که معمولاً هنگام metamodeling استفاده می‌شوند؛ بنابراین هم در خود Infrastructure Library و هم در metamodelهایی مانند MOF و UML به کار می‌روند. package Abstractions چند package ریزدانه را شامل می‌شود که هر یک تعداد کمی metaclass دارند و بیشتر آن‌ها abstract هستند. هدف این package فراهم‌کردن مجموعه‌ای بسیار قابل استفاده مجدد از metaclassهاست تا هنگام تعریف metamodelهای جدید تخصصی شوند. package Constructs نیز چند package ریزدانه را در بر می‌گیرد و بسیاری از جنبه‌های Abstractions را گرد هم می‌آورد. metaclassهای Constructs بیشتر concrete هستند تا abstract و برای پارادایم مدل‌سازی شیءگرا طراحی شده‌اند. metamodelهایی مانند MOF و UML معمولاً package Constructs را import می‌کنند، زیرا در این صورت محتوای سایر packageهای Core به‌طور خودکار شامل می‌شود. package Basic زیرمجموعه‌ای از Constructs را در بر دارد که عمدتاً برای اهداف XMI استفاده می‌شود.

package Profiles سازوکارهای مورد استفاده برای ایجاد profile از metamodelهای مشخص و به‌ویژه UML را در بر دارد. این سازوکار گسترش، زیرمجموعه‌ای از قابلیت‌هایی است که سازوکار عمومی‌تر گسترش MOF ارائه می‌کند.

ساختار و محتوای تفصیلی packageهای PrimitiveTypes، Abstractions، Basic، Constructs و Profiles در بندهای بعدی با جزئیات بیشتری توضیح داده می‌شود.