صفحهٔ منبع 172Constraint
توضیح
Constraint Element یک محدودیت روی عناصر دیگر را مشخص میکند و میتواند به هر نوع Element متصل شود. آیکون Constraint در همهٔ Enterprise Architect Diagramها از صفحات «Common» در Toolbox قابل دسترس است. این عنصر فقط وجود Constraint روی عناصر مرتبط را مستند میکند و روی خود عناصر اثر اجرایی ندارد.
Constraint یک Named Element است، در Browser Window فهرست میشود و میتواند در صورت نیاز Copy/Re-use شود. Typeهای Constraint را در Project Reference Data تعریف میکنید، در Properties عنصر اعمال میکنید و از Responsibility Window مدیریت میکنید.
عنصر تصویری اصلی — صفحه 172عنصر تصویری اصلی — صفحه 172© Sparx Systems 2026 — صفحهٔ 172 از ۴۲۲ — ایجادشده با Enterprise Architect
صفحهٔ منبع 173Datastore
توضیح
Datastore برای تعریف Data ذخیرهشدهٔ پایدار استفاده میشود. Data Token ورودی به Datastore بهصورت دائمی ذخیره میشود و Token مربوط به Data موجود را Update میکند. Token خروجی یک Copy از Data اصلی است.
با Object Flow، عنصرهایی مانند Activity را به Datastore متصل کنید تا Value و Information میان Nodeها عبور کنند. Selection و Transformation Behavior میتوانند نوع Data Access را شبیه Query مشخص کنند؛ Selection تعیین میکند کدام Objectها تحت تأثیر Connection هستند و Transformation میتواند Value یک Attribute از Object انتخابشده را تعیین کند.
برای تعریف Access Behavior، یک Note به Object Flow وصل کنید: روی Flow راستکلیک و «Attach Note or Constraint» را انتخاب کنید. گفتوگو Flowهای دیگر Activity Diagram را نیز برای اتصال همان Note نشان میدهد. برای انطباق با UML 2.x، Behavior را با «selection» یا «transformation» آغاز کنید.
مشخصات OMG UML
طبق UML 2.5.1 صفحهٔ 399، DataStoreNode نوعی CentralBufferNode است که Object Tokenهای خود را در طول اجرای Activity بهصورت پایدار نگه میدارد. وقتی Downstream Object Node Token را میپذیرد، Token طبق Semantics عادی CentralBufferNode حذف میشود، اما بلافاصله Copyای با همان Value دوباره در DataStoreNode قرار میگیرد؛ بنابراین Valueها در طول Execution پایدار بهنظر میرسند. اگر Token پذیرفتهشده Objectای با Identity یکسان با Object موجود داشته باشد، Duplicate Token افزوده نمیشود؛ DataStoreNode برخلاف CentralBufferNode معمولی Objectها را بهصورت یکتا نگه میدارد.
عنصر تصویری اصلی — صفحه 173عنصر تصویری اصلی — صفحه 173© Sparx Systems 2026 — صفحهٔ 173 از ۴۲۲ — ایجادشده با Enterprise Architect
صفحهٔ منبع 174Decision
توضیح
Decision عنصر Activity Diagram یا Interaction Overview Diagram است که نقطهٔ پیشروی Conditional را نشان میدهد: اگر Condition True باشد Processing یک مسیر و در غیر این صورت مسیر دیگری را ادامه میدهد.
Decision میتواند بهعنوان Merge Node نیز استفاده شود تا چند Alternative Flow بدون Synchronization به یک Flow تبدیل شوند. منبع برای هر دو کاربرد نمونه دارد و به شکلهای 12.77 و 12.106 از UML 2.5.1 ارجاع میدهد.
میتوانید یک Behavior Element را بهعنوان Decision Input Property یا decisionInput در Properties Window انتخاب کنید. برای نمایش آن روی Diagram، Note را به Decision متصل کنید، روی Note Link راستکلیک و «Link this Note to an Element feature» را انتخاب کنید و سپس «Decision Input» را بهعنوان Feature انتخاب کنید.
همچنین میتوانید Object Flow را بهعنوان Decision Input Flow یا decisionInputFlow انتخاب کنید؛ Object Flow ورودی را انتخاب و در Properties گزینهٔ «Decision Input Flow» را فعال کنید.
یادداشت
جابهجایی Diagram معمولاً Location عناصر در Packageها را تغییر نمیدهد؛ اما Decision فقط در همان Diagram معنا دارد و Re-use نمیشود، بنابراین اگر Diagram حاوی Decision به Package دیگری منتقل شود، Decisionها نیز همراه Diagram به Parent Package جدید منتقل میشوند.
عنصر تصویری اصلی — صفحه 174عنصر تصویری اصلی — صفحه 174عنصر تصویری اصلی — صفحه 174© Sparx Systems 2026 — صفحهٔ 174 از ۴۲۲ — ایجادشده با Enterprise Architect
صفحهٔ منبع 175مشخصات OMG UML
طبق UML 2.5.1 صفحهٔ 390، DecisionNode یک ControlNode است که میان Flowهای خروجی انتخاب میکند. باید حداقل یک و حداکثر دو ActivityEdge ورودی و دستکم یک ActivityEdge خروجی داشته باشد. اگر دو ورودی داشته باشد، یکی decisionInputFlow و دیگری Primary Incoming Edge است؛ با یک ورودی همان Edge اصلی محسوب میشود. اگر Primary Incoming یک ControlFlow باشد همهٔ خروجیها باید ControlFlow باشند و اگر ObjectFlow باشد همهٔ خروجیها باید ObjectFlow باشند.
DecisionNode Tokenهای Primary Incoming Edge را میپذیرد و به همهٔ Edgeهای خروجی Offer میکند، اما هر Token حداکثر از یک خروجی عبور میکند و Duplicate نمیشود. Guardهای خروجی برای هر Token ارزیابی میشوند؛ ترتیب ارزیابی تعریف نشده و ممکن است Concurrent باشد. اگر Primary Incoming یک ObjectFlow باشد و DecisionNode فاقد decisionInput یا decisionInputFlow باشد، Value داخل Incoming Object Token میتواند برای ارزیابی Guardهای ObjectFlow خروجی استفاده شود.
عنصر تصویری اصلی — صفحه 175© Sparx Systems 2026 — صفحهٔ 175 از ۴۲۲ — ایجادشده با Enterprise Architect