UML PrimitiveTypes و آغاز Profiles: انواع اولیه، Extension، Image و Package

UML PrimitiveTypes و آغاز Profiles: انواع اولیه، Extension، Image و Package

توسط admin | گروه مهندسی نرم افزار | 1405/05/21

نظرات 0

12 Core::PrimitiveTypes

Package PrimitiveTypes از InfrastructureLibrary::Core شامل تعدادی Type ازپیش‌تعریف‌شده است که هنگام تعریف abstract syntax مربوط به metamodelها استفاده می‌شوند.

شکل 12.1 - Package Core تحت مالکیت InfrastructureLibrary است و چند Subpackage را دربر می‌گیرد
شکل 12.1 - Package Core تحت مالکیت InfrastructureLibrary است و چند Subpackage را دربر می‌گیرد

12.1 Package PrimitiveTypes

Subpackage PrimitiveTypes در Package Core انواع مختلف primitive valueهایی را تعریف می‌کند که برای تعریف Core metamodel استفاده می‌شوند. همچنین هدف این است که هر metamodel مبتنی بر Core، PrimitiveTypeهای زیر را دوباره استفاده کند.

در Core و UML metamodel این PrimitiveTypeها ازپیش‌تعریف‌شده‌اند و در همه زمان‌ها برای Core و extensionهای UML در دسترس هستند. این Typeهای value ازپیش‌تعریف‌شده مستقل از هر object model و بخشی از تعریف Core هستند.

PrimitiveTypeهای تعریف‌شده عبارت‌اند از Integer، Boolean، String و UnlimitedNatural.

شکل 12.2 - کلاس‌های تعریف‌شده در Package PrimitiveTypes
شکل 12.2 - کلاس‌های تعریف‌شده در Package PrimitiveTypes

12.1.1 Boolean

Type Boolean برای expressionهای منطقی استفاده می‌شود و از valueهای ازپیش‌تعریف‌شده true و false تشکیل شده است.

Description

Boolean یک instance از PrimitiveType است. در metamodel، Boolean یک Enumeration تعریف می‌کند که یک condition منطقی را نشان می‌دهد. EnumerationLiteralهای آن عبارت‌اند از:

  • true - شرط Boolean برقرار است.
  • false - شرط Boolean برقرار نیست.

این Type برای Boolean attributeها و Boolean expressionها در metamodel، مانند OCL expression، استفاده می‌شود.

Attributes

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

Associations

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

Constraints

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

Semantics

Boolean یک instance از PrimitiveType است.

Notation

Boolean به‌عنوان Type Attributeها در metamodel ظاهر می‌شود. Instanceهای Boolean valueهایی مرتبط با slotها هستند و به‌صورت literal فقط می‌توانند true یا false باشند.

Examples

شکل 12.3 Attribute مربوط به Car::isAutomatic با Type Boolean و مقدار پیش‌فرض true را نشان می‌دهد.

شکل 12.3 - نمونه یک Boolean Attribute
شکل 12.3 - نمونه یک Boolean Attribute

12.1.2 Integer

Integer یک PrimitiveType است که valueهای صحیح را نمایش می‌دهد.

Description

Instance از Integer عضوی از مجموعه نامتناهی اعداد صحیح (..., -2, -1, 0, 1, 2, ...) است. Integer برای Attributeها و expressionهای صحیح در metamodel استفاده می‌شود.

Attributes

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

Associations

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

Constraints

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

Semantics

Integer یک instance از PrimitiveType است.

Notation

Integer به‌عنوان Type Attributeها در metamodel ظاهر می‌شود. Instanceهای Integer valueهای مرتبط با slotها هستند؛ مانند 1، -5، 2، 34 و 26524.

Examples

شکل 12.4 Attribute مربوط به Magazine::pages با Type Integer و مقدار 64 را نشان می‌دهد.

شکل 12.4 - نمونه یک Integer Attribute
شکل 12.4 - نمونه یک Integer Attribute

12.1.3 String

String دنباله‌ای از characterها در یک character set مناسب است که برای نمایش اطلاعات درباره Model به‌کار می‌رود. Character set می‌تواند alphabetها و characterهای غیرلاتین را نیز شامل شود.

Description

Instance از String یک قطعه متن را تعریف می‌کند. معناشناسی خود String به هدف آن بستگی دارد؛ می‌تواند Comment، expression یک زبان محاسباتی، OCL expression و مانند آن باشد. String برای Attributeها و expressionهای رشته‌ای در metamodel استفاده می‌شود.

Attributes

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

Associations

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

Constraints

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

Semantics

String یک instance از PrimitiveType است.

Notation

String به‌عنوان Type Attributeها در metamodel ظاهر می‌شود. Instanceهای String valueهایی مرتبط با slotها هستند. Value دنباله‌ای از characterهاست که داخل double quote (") قرار می‌گیرد. فرض می‌شود character set زیربنایی برای نمایش multibyte characterها در زبان‌های انسانی مختلف کافی است؛ به‌ویژه character set سنتی 8-bit ASCII کافی نیست. همچنین فرض می‌شود ابزارها و رایانه‌ها Stringها را، از جمله escape conventionهای characterهای خاص، به‌درستی پردازش و ذخیره می‌کنند. این سند فرض می‌کند arbitrary String قابل استفاده است.

String به‌صورت text string graphic نمایش داده می‌شود. Characterهای printable عادی باید مستقیماً نمایش داده شوند. روش نمایش characterهای nonprintable مشخص نشده و وابسته به platform است.

Examples

شکل 12.5 Attribute مربوط به Book::author با Type String و مقدار "Joe" را نشان می‌دهد.

شکل 12.5 - نمونه یک String Attribute
شکل 12.5 - نمونه یک String Attribute

12.1.4 UnlimitedNatural

UnlimitedNatural یک PrimitiveType است که valueهای natural نامحدود را نمایش می‌دهد.

Description

Instance از UnlimitedNatural عضوی از مجموعه نامتناهی اعداد طبیعی (0, 1, 2, ...) است. مقدار infinity با asterisk (*) نشان داده می‌شود.

Attributes

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

Associations

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

Constraints

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

Semantics

UnlimitedNatural یک instance از PrimitiveType است.

Notation

UnlimitedNatural به‌عنوان Type مربوط به upper boundهای multiplicity در metamodel ظاهر می‌شود. Instanceهای UnlimitedNatural valueهایی مرتبط با slotها هستند؛ مانند 1، 5 و 398475. مقدار infinity می‌تواند با asterisk (*) نشان داده شود.

Examples

شکل 12.6 نمونه‌ای از multiplicity نامحدود را در Association میان Teacher و Student نشان می‌دهد که end مربوط به student با * مشخص شده است.

شکل 12.6 - نمونه یک UnlimitedNatural
شکل 12.6 - نمونه یک UnlimitedNatural

13 Core::Profiles

Package Profiles سازوکارهایی دربر دارد که اجازه می‌دهند metaclassهای metamodelهای موجود برای اهداف مختلف توسعه یابند. این قابلیت شامل تطبیق UML metamodel برای platformهای متفاوت - مانند J2EE یا .NET - یا domainهای متفاوت - مانند real-time یا business process modeling - است. سازوکار Profile با OMG Meta Object Facility (MOF) سازگار است.

جایگاه Profileها در برابر Metamodel، MOF و UML

Infrastructure Specification در چند meta-level و در Specificationهای مختلف OMG مرتبط با modeling دوباره استفاده می‌شود. برای مثال MOF از آن برای فراهم‌کردن قابلیت مدل‌سازی metamodelها استفاده می‌کند، درحالی‌که UML Superstructure آن را برای مدل‌کردن UML Model به‌کار می‌گیرد. این بخش use caseهایی در سطح meta-meta بررسی می‌کند که با MOF قابل مقایسه‌اند و یک level بالاتر از UML metamodel specification قرار دارند. بنابراین در این بخش وقتی از Class سخن گفته می‌شود، در بیشتر موارد منظور meta-metaclass Class است؛ همان عنصری که برای تعریف هر metaclass در UML Superstructure Specification مانند Activity، Class، State و Use Case استفاده می‌شود.

تاریخچه Profileها و الزامات طراحی

Profile mechanism به‌طور خاص برای ارائه یک lightweight extension mechanism برای استاندارد UML تعریف شده است. در UML 1.1، stereotype و tagged value به‌عنوان extensionهای مبتنی بر String استفاده می‌شدند که می‌توانستند به‌شکل انعطاف‌پذیر به UML ModelElementها متصل شوند. در revisionهای بعدی UML، مفهوم Profile برای افزودن ساختار و دقت بیشتر به تعریف Stereotypeها و Tagged Valueها تعریف شد. UML 2.0 Infrastructure و Superstructure این ایده را بیشتر توسعه داده و آن را به‌عنوان یک meta-modeling technique مشخص تعریف کرده‌اند. Stereotypeها metaclassهای خاص، tagged valueها meta-attributeهای استاندارد و Profileها نوع خاصی از Package هستند.

الزامات زیر از آغاز، تعریف معناشناسی Profile را هدایت کرده‌اند:

  1. Profile باید سازوکارهایی برای تخصصی‌کردن یک reference metamodel - مانند مجموعه‌ای از UML Packageها - فراهم کند به‌گونه‌ای که معناشناسی تخصصی‌شده با معناشناسی reference metamodel تناقض نداشته باشد. Constraintهای Profile معمولاً می‌توانند well-formedness ruleهایی تعریف کنند که محدودکننده‌تر، اما سازگار با قواعد reference metamodel باشند.
  2. باید امکان interchange Profileها بین ابزارها همراه با Modelهایی که Profile روی آن‌ها اعمال شده، با استفاده از UML XMI interchange mechanism وجود داشته باشد. بنابراین Profile باید به‌صورت UML Model قابل interchange تعریف شود. افزون بر exchange Profile همراه Model بین ابزارها، Profile application باید «by reference» نیز قابل تعریف باشد؛ مثلاً import by name. یعنی اگر Profile از قبل در ابزار importکننده وجود داشته باشد لازم نیست خود Profile exchange شود.
  3. Profile باید بتواند به UML libraryهای domain-specific که برخی ModelElementها در آن‌ها از قبل تعریف شده‌اند reference دهد.
  4. باید بتوان مشخص کرد چه Profileهایی روی یک Package مشخص - یا specializationهای آن مفهوم - اعمال شده‌اند. این قابلیت هنگام model interchange مهم است تا environment واردکننده بتواند Model را درست تفسیر کند.
  5. باید امکان تعریف UML extensionی وجود داشته باشد که Profileها و Model Libraryها - از جمله Template Libraryها - را در یک logical unit واحد ترکیب کند. بااین‌حال درون چنین واحدی، برای شفافیت تعریف و سهولت interchange - مانند reference by name - باید همچنان بتوان Library و Profile را از هم جدا نگه داشت.
  6. Profile باید بتواند معناشناسی UML metamodel elementهای استاندارد را تخصصی کند. برای مثال در Modelی با Profile به نام Java model باید بتوان generalization Classها را به single inheritance محدود کرد، بدون اینکه لازم باشد stereotype «Java class» به تک‌تک Class instanceها اختصاص یابد.
  7. باید convention نمادگذاری برای تعریف گرافیکی Stereotype به‌عنوان بخشی از Profile فراهم شود.
  8. برای برآوردن الزام [1]، UML Profileها باید metamodel extension mechanismی باشند که محدودیت‌های خاصی بر نحوه تغییر UML metamodel اعمال می‌کند. Reference metamodel مانند Model «read-only» در نظر گرفته می‌شود که Profileها بدون تغییر آن را توسعه می‌دهند. بنابراین واردکردن metaclass جدید در UML metaclass hierarchy - مانند superclass جدید برای UML metaclass استاندارد - یا تغییر تعریف UML metaclass استاندارد - مانند افزودن meta-association - ممنوع است. این محدودیت‌ها در context مربوط به MOF اعمال نمی‌شوند؛ جایی که اصولاً هر metamodel را می‌توان در هر جهت بازطراحی کرد.
  9. اکثریت بسیار زیاد UML CASE toolها باید قادر به پیاده‌سازی Profile باشند. بنابراین طراحی UML Profile نباید این ابزارها را مجبور کند implementation داخلی مبتنی بر meta-metamodel/metamodel architecture داشته باشند.
  10. Profileها می‌توانند به‌صورت dynamic روی Model اعمال یا از آن retract شوند. روی Model موجود می‌توان Profile جدید اعمال کرد یا مجموعه Profileهای اعمال‌شده را تغییر داد.
  11. Profileها می‌توانند به‌صورت dynamic ترکیب شوند. اغلب چند Profile به‌طور هم‌زمان روی یک Model اعمال خواهند شد و لازم نیست این ترکیب هنگام تعریف Profile از قبل پیش‌بینی شده باشد.
  12. Modelها مستقل از Profileهایی که destination می‌شناسد قابل exchange هستند. Destination مربوط به exchange مدل توسعه‌یافته با Profile ممکن است آن Profile را نشناسد و الزامی ندارد description خاص Profile را تفسیر کند. Destination environment فقط زمانی extensionها را تفسیر می‌کند که Profileهای لازم را در اختیار داشته باشد.

Extensibility

Profiles mechanism یک first-class extension mechanism نیست؛ یعنی اجازه تغییر metamodelهای موجود را نمی‌دهد. هدف Profileها ارائه سازوکاری ساده برای تطبیق metamodel موجود با constructهای خاص یک domain، platform یا method است. هر adaptation در یک Profile گروه‌بندی می‌شود. با Profile نمی‌توان هیچ Constraint اعمال‌شده بر metamodelی مانند UML را حذف کرد، اما می‌توان Constraintهای جدید مخصوص Profile افزود. محدودیت‌های دیگر فقط محدودیت‌های ذاتی Profiles mechanism هستند و قصد دیگری برای محدودکردن نحوه customize کردن metamodel وجود ندارد.

First-class extensibility از طریق MOF انجام می‌شود؛ جایی که محدودیتی بر کارهایی که می‌توان با metamodel انجام داد وجود ندارد: می‌توان metaclassها و relationshipها را در صورت نیاز افزود یا حذف کرد. البته سپس ممکن است methodology constraintهایی اعمال شود که اجازه تغییر metamodel موجود را ندهند و فقط extension را مجاز کنند. در این حالت سازوکار first-class extensibility و Profileها به یکدیگر نزدیک می‌شوند.

دلایل مختلفی برای customize کردن metamodel وجود دارد:

  • ارائه terminology متناسب با platform یا domain مشخص؛ برای مثال ثبت terminology مربوط به EJB مانند home interface، enterprise Java bean و archive.

  • ارائه syntax برای constructهایی که notation ندارند؛ مانند Actionها.

  • ارائه notation متفاوت برای symbolهای موجود؛ مثلاً استفاده از تصویر یک رایانه به‌جای node symbol معمولی برای نمایش رایانه در network.

  • افزودن معناشناسی‌ای که در metamodel unspecified باقی مانده است؛ مانند نحوه مدیریت priority هنگام دریافت signal در state machine.

  • افزودن معناشناسی‌ای که در metamodel وجود ندارد؛ مانند تعریف timer، clock یا continuous time.

  • افزودن Constraintهایی که نحوه استفاده از metamodel و constructهای آن را محدود می‌کنند؛ مانند ممنوع‌کردن اجرای parallel Actionها در یک transition واحد.

  • افزودن اطلاعاتی که هنگام transform کردن Model به Model دیگر یا به code قابل استفاده باشد؛ مانند تعریف mapping rule میان Model و Java code.

Profileها و Metamodelها

پاسخ ساده‌ای وجود ندارد که چه زمانی باید metamodel جدید ساخت و چه زمانی به‌جای آن Profile جدید ایجاد کرد.

13.1 Package Profiles

Package Profiles به Package Constructs از Core وابسته است؛ همان‌گونه که شکل 13.1 نشان می‌دهد.

شکل 13.1 - وابستگی میان Packageهای شرح‌داده‌شده در این بخش
شکل 13.1 - وابستگی میان Packageهای شرح‌داده‌شده در این بخش

Classهای Package Profiles در شکل 13.2 نمایش داده شده و سپس به‌صورت متنی مشخص می‌شوند.

شکل 13.2 - کلاس‌های تعریف‌شده در Package Profiles
شکل 13.2 - کلاس‌های تعریف‌شده در Package Profiles

13.1.1 Class - از Profiles

Generalizations

  • InfrastructureLibrary::Constructs::Class - merge increment

Description

Class دارای Association مشتق‌شده‌ای است که نشان می‌دهد چگونه می‌تواند از طریق یک یا چند Stereotype توسعه یابد.

Stereotype تنها نوع metaclass است که خودش نمی‌تواند توسط Stereotype توسعه یابد.

Attributes

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

Associations

  • /extension: Extension[*] - Extensionهایی را ارجاع می‌دهد که Propertyهای اضافی metaclass را مشخص می‌کنند. این Property از Extensionهایی مشتق می‌شود که memberEnd آن‌ها با Class نوع‌دهی شده است.

Constraints

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

Semantics

معناشناسی اضافی ندارد.

Notation

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

Presentation Options

Classی که توسط Stereotype توسعه یافته است می‌تواند با keyword اختیاری «metaclass» در بالا یا پیش از نام خود نمایش داده شود.

Examples

شکل 13.3 نمونه‌ای را نشان می‌دهد که در آن صریح شده Class توسعه‌یافته Interface در واقع یک metaclass از reference metamodel است و توسط Stereotype Remote توسعه یافته است.

شکل 13.3 - نمایش اینکه Class توسعه‌یافته یک metaclass است
شکل 13.3 - نمایش اینکه Class توسعه‌یافته یک metaclass است

Changes from previous UML

Linkی که در UML 1.4 با ModelElement::stereotype type شده است به linkی نگاشت می‌شود که با Class::extension type شده است.

13.1.2 Extension - از Profiles

Extension برای نشان‌دادن این موضوع استفاده می‌شود که Propertyهای یک metaclass از طریق Stereotype توسعه یافته‌اند و قابلیت انعطاف‌پذیر افزودن - و بعداً حذف - Stereotypeها به Classها را فراهم می‌کند.

Generalizations

  • InfrastructureLibrary::Constructs::Association

Description

Extension نوعی Association است. یکی از endهای Extension یک Property معمولی و end دیگر یک ExtensionEnd است. Property معمولی Extension را به Class متصل می‌کند و ExtensionEnd آن را به Stereotypeای که Class را توسعه می‌دهد متصل می‌سازد.

Attributes

  • /isRequired: Boolean - نشان می‌دهد آیا هنگام ایجاد instance از Class توسعه‌یافته باید instanceای از Stereotype توسعه‌دهنده نیز ساخته شود یا خیر. مقدار Attribute از multiplicity Property ارجاع‌شده توسط Extension::ownedEnd مشتق می‌شود؛ multiplicity برابر 1 یعنی isRequired=true و در غیر این صورت false است. چون multiplicity پیش‌فرض ExtensionEnd برابر 0..1 است، مقدار پیش‌فرض isRequired برابر false است.

Associations

  • ownedEnd: ExtensionEnd[1] - end مربوط به Extension را ارجاع می‌دهد که Type آن Stereotype است. {Redefines Association::ownedEnd}.
  • /metaclass: Class[1] - Classی را ارجاع می‌دهد که از طریق Extension توسعه یافته است. این Property از Type مربوط به memberEndی مشتق می‌شود که ownedEnd نیست.

Constraints

[1] end غیر-owned یک Extension با Class type می‌شود.

metaclassEnd()->notEmpty() and metaclass()->oclIsKindOf(Class)

[2] Extension دودویی است؛ یعنی فقط دو memberEnd دارد.

memberEnd->size() = 2

Additional Operations

[1] Query metaclassEnd() Propertyای را برمی‌گرداند که با metaclass type شده است، نه Stereotype.

Extension::metaclassEnd(): Property;
metaclassEnd = memberEnd->reject(ownedEnd)

[2] Query metaclass() metaclassای را برمی‌گرداند که در حال توسعه است، نه Stereotype توسعه‌دهنده.

Extension::metaclass(): Class;
metaclass = metaclassEnd().type

[3] Query isRequired() اگر owned end دارای multiplicity با lower bound برابر 1 باشد true است.

Extension::isRequired(): Boolean;
isRequired = (ownedEnd->lowerBound() = 1)

Semantics

Required Extension به این معناست که instanceای از Stereotype باید همیشه به instanceای از metaclass توسعه‌یافته link باشد. Instance Stereotype معمولاً فقط زمانی حذف می‌شود که instance metaclass توسعه‌یافته حذف شود یا Profile تعریف‌کننده Stereotype از applied profileهای Package برداشته شود. اگر isRequired=true باشد و instance Stereotype وجود نداشته باشد، Model well-formed نیست. اگر Stereotype توسعه‌دهنده Subclass داشته باشد، حداکثر یک instance از خود Stereotype یا یکی از Subclassهای آن مورد نیاز است.

Non-required Extension یعنی instance Stereotype می‌تواند به‌دلخواه به instance metaclass توسعه‌یافته link شود و بعداً نیز به‌دلخواه حذف شود؛ اما الزامی وجود ندارد که هر instance از metaclass توسعه یابد. Instance Stereotype همچنین وقتی instance metaclass توسعه‌یافته حذف شود یا Profile تعریف‌کننده Stereotype از applied profileهای Package برداشته شود حذف می‌شود.

معادل این ساختار در MOF در شکل 13.4 نشان داده شده است. شکل موردی را نشان می‌دهد که در شکل 13.6 نیز آمده و Stereotype Home، metaclass Interface را توسعه می‌دهد. در این شکل Interface یک instance از CMOF::Class و Home یک instance از CMOF::Stereotype است. Construct معادل Extension در MOF یک aggregation از metaclass توسعه‌یافته به extension stereotype است که از extension stereotype به metaclass توسعه‌یافته navigable است. وقتی Extension required باشد، cardinality سمت extension stereotype برابر 1 است.

Role nameها طبق قواعد زیر ساخته می‌شوند. نام role مربوط به metaclass توسعه‌یافته:

'base_' extendedMetaclassName

نام role مربوط به extension stereotype:

'extension$_' stereotypeName

Constraintها اغلب به Stereotypeها اضافه می‌شوند. Role nameها برای OCL navigation استفاده می‌شوند. برای مثال expression زیر می‌گوید Home interface نباید Attribute داشته باشد:

self.base_Interface.ownedAttributes->size() = 0
شکل 13.4 - MOF Model معادل توسعه `Interface` با Stereotype `Home`
شکل 13.4 - MOF Model معادل توسعه `Interface` با Stereotype `Home`

Notation

Extension با پیکانی از Stereotype به Class توسعه‌یافته نشان داده می‌شود که arrowhead آن یک مثلث توپر است. Extension می‌تواند همان adornmentهای Association معمولی را داشته باشد، اما navigation arrow هیچ‌گاه نشان داده نمی‌شود. اگر isRequired=true باشد Property به فرم {required} نزدیک ExtensionEnd قرار می‌گیرد.

شکل 13.5 - نمادگذاری Extension
شکل 13.5 - نمادگذاری Extension

Presentation Options

به‌عنوان جایگزین Property {required} می‌توان multiplicityهای 0..1 یا 1 را روی ExtensionEnd نمایش داد. با توجه به derivation مربوط به isRequired، multiplicity 0..1 متناظر با false بودن isRequired است.

Style Guidelines

Adornmentهای Extension معمولاً elide می‌شوند.

Examples

در شکل 13.6 نمونه ساده‌ای از Extension نشان داده شده که Stereotype Home، metaclass Interface را توسعه می‌دهد.

شکل 13.6 - نمونه استفاده از Extension
شکل 13.6 - نمونه استفاده از Extension

Instance از Stereotype Home می‌تواند به‌دلخواه به instance Class Interface افزوده یا از آن حذف شود. این رویکرد امکان افزودن و حذف dynamic اطلاعات مخصوص Profile را در Model فراهم می‌کند.

در شکل 13.7، instance Stereotype Bean همیشه باید به instance Class Component link باشد، زیرا Extension به‌صورت required تعریف شده است. چون Bean انتزاعی است، در عمل instance یکی از Subclassهای عینی آن باید همیشه به instance Component link باشد. بدون اعمال چنین Stereotypeای Model well-formed نیست. این روش برای بیان Extensionهایی است که، بسته به Profileهای اعمال‌شده، باید برای همه instanceهای base metaclass وجود داشته باشند.

شکل 13.7 - نمونه یک required Extension
شکل 13.7 - نمونه یک required Extension

Changes from previous UML

Extension در UML 1.x به‌عنوان metaclass وجود نداشت.

Occurrenceهای Stereotype::baseClass در UML 1.4 به instanceای از Extension نگاشت می‌شوند که ownedEnd آن با Stereotype type شده و end دیگر با metaclass مشخص‌شده توسط baseClass type شده است.

13.1.3 ExtensionEnd - از Profiles

ExtensionEnd برای اتصال Extension به Stereotype هنگام توسعه metaclass استفاده می‌شود.

Generalizations

  • InfrastructureLibrary::Constructs::Property

Description

ExtensionEnd نوعی Property است که همیشه با Stereotype type می‌شود.

ExtensionEnd هیچ‌گاه navigable نیست. اگر navigable بود، Propertyای از Classifier توسعه‌یافته محسوب می‌شد. از آنجا که Profile اجازه تغییر reference metamodel را ندارد، نمی‌توان Property جدید به Classifier توسعه‌یافته افزود. در نتیجه ExtensionEnd فقط می‌تواند تحت مالکیت Extension باشد.

Aggregation یک ExtensionEnd همیشه composite است.

Multiplicity پیش‌فرض ExtensionEnd برابر 0..1 است.

Attributes

  • lower: Integer = 0 - این redefinition multiplicity پیش‌فرض association endها را تغییر می‌دهد، زیرا ModelElementها معمولاً با 0 یا 1 instance از extension stereotype توسعه می‌یابند. {Redefines MultiplicityElement::lower}.

Associations

  • type: Stereotype[1] - Type مربوط به ExtensionEnd را ارجاع می‌دهد و Typeهای ممکن را فقط به Stereotype محدود می‌کند. {Redefines TypedElement::type}.

Constraints

[1] Multiplicity مربوط به ExtensionEnd فقط 0..1 یا 1 است.

(self->lowerBound() = 0 or self->lowerBound() = 1) and self->upperBound() = 1

[2] Aggregation مربوط به ExtensionEnd composite است.

self.aggregation = #composite

Additional Operations

[1] Query lowerBound() lower bound multiplicity را به‌صورت Integer برمی‌گرداند. این یک redefinition از lower bound پیش‌فرض است که در MultiplicityElement معمولاً اگر خالی باشد به 1 ارزیابی می‌شود.

ExtensionEnd::lowerBound() : Integer;
lowerBound = if lowerValue->isEmpty() then 0 else lowerValue->IntegerValue() endif

Semantics

معناشناسی اضافی ندارد.

Notation

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

Examples

به بخش Extension (from Profiles) در صفحه 181 مراجعه کنید.

Changes from previous UML

ExtensionEnd در UML 1.4 به‌عنوان metaclass وجود نداشت. برای جزئیات بیشتر بخش Extension (from Profiles) در صفحه 181 را ببینید.

13.1.4 Image - از Profiles

تعریف فیزیکی یک graphical image.

Generalizations

  • Element، صفحه 93

Description

Class Image اطلاعات لازم برای نمایش Image در diagram را فراهم می‌کند. Iconها معمولاً از طریق Class Image مدیریت می‌شوند.

Attributes

  • content: String[0..1] - serialization مربوط به Image را مطابق imageFormat نگه می‌دارد. Value می‌تواند bitmap یا image مانند GIF، یا drawing instruction با استانداردی مانند Scalable Vector Graphics (SVG) مبتنی بر XML را نمایش دهد.
  • format: String[0..1] - format مربوط به imageContent و نحوه تفسیر String imageContent را مشخص می‌کند. مقادیر زیر رزرو شده‌اند: SVG، GIF، PNG، JPG، WMF، EMF، BMP. افزون بر آن prefix MIME: نیز رزرو شده و باید با MIME type معتبر مطابق RFC3023 دنبال شود. برای مثال به‌جای SVG می‌توان MIME: image/svg+xml نوشت.
  • location: String[0..1] - locationی را نگه می‌دارد که ابزار می‌تواند به‌عنوان جایگزین embedding Image در Stereotype برای یافتن Image استفاده کند.

Associations

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

Constraints

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

Semantics

اطلاعاتی مانند physical localization یا format توسط Class Image ارائه می‌شود. Image روشی عمومی برای نمایش Image در formatهای مختلف فراهم می‌کند. اگرچه چند value ازپیش‌تعریف‌شده برای imageFormat جهت convenience و interoperability مشخص شده‌اند، مجموعه formatهای ممکن open-ended است. بااین‌حال هیچ الزامی وجود ندارد که implementation بتواند format خاصی، حتی valueهای ازپیش‌تعریف‌شده، را تفسیر و نمایش دهد.

13.1.5 Package - از Profiles

Generalizations

  • InfrastructureLibrary::Constructs::Package - merge increment

Description

Package می‌تواند یک یا چند ProfileApplication داشته باشد تا مشخص شود چه Profileهایی اعمال شده‌اند.

از آنجا که Profile خود یک Package است، Profile را می‌توان نه‌تنها روی Packageها بلکه روی Profileهای دیگر نیز اعمال کرد.

Attributes

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

امتیاز کاربران به این مقاله

☆☆☆☆☆

0 نفر امتیاز داده اند. میانگین: 0.0 از 5

 

0 نظر

نظر محترم شما در مورد مقاله های وب سایت برنامه نویسی و پایگاه داده

نظرات محترم شما در خدمات رسانی بهتر ما را یاری می نمایند. لطفا اگر مایل بودید یک نظر ما را مهمان فرمائید. آدرس ایمیل و وب سایت شما نمایش داده نخواهد شد.

0 / 500

اطلاعات تماس

  • آدرس:اصفهان-خیابان ام کلثوم غربی - بعد خیابان تخم چی - بیست متر بعد از پیتزا ننه شب - کوچه تعمیر گاه سمار زغالی - پلاک 354 - درب مشکی - طبقه هفتم
  • آدرس ایمیل:najafzade@gmail.com
  • وب سایت:http://www.a00b.com/
  • تلفن ثابت:(+98)9131253620
  • تلفن همراه:09131253620