What is /- are Composite Structure Diagram-s in UML? ما هو مخطط الهيكل المركب في لغة النمذجة الموحدة؟
What is /- are Composite Structure Diagram-s in UML? ما هو مخطط الهيكل المركب في لغة النمذجة الموحدة؟
الهيكل عبارة عن مجموعة من العناصر المترابطة الموجودة في وقت التشغيل لتوفير بعض الوظائف بشكل جماعي. على سبيل المثال ، يمكنك استخدام بنية لتمثيل التركيب الداخلي لمصنف مثل النظام الفرعي (ما هي الكائنات المرتبطة ببعضها البعض ، ومن يتواصل مع من ، وما إلى ذلك). UML يدعو مثل هذه الهياكل الهياكل الداخلية. يعرف UML عدة رموز لالتقاط العلاقات والاتصالات بين العناصر في بنية داخلية.
موصلات connectors
تمثل الموصلات روابط الاتصال بين حالات الفئات المشاركة في بنية داخلية. يمكن أن تكون حالات وقت تشغيل للجمعيات ، أو يمكن أن تمثل اتصال ديناميكي تم إعداده في وقت التشغيل - على سبيل المثال من خلال كونها قيمًا للمتغيرات المحلية. تعرض الموصل كخط متصل بين مثيلين. لاحظ أنه بينما تمثل الارتباطات بين الفئات ارتباطًا بين أي مثيلات من هذه الفئات ، فإن الرابط يمثل ارتباطًا بين المثيلين المحددين فقط في كل نهاية للموصل
يمكنك توفير معلومات الاسم والكتابة للموصل باستخدام التنسيق التالي:
name:classname
حيث
Name:الاسم
هو اسم الموصل. يمكن استخدام الاسم لاحقًا في عمليات التعاون للإشارة إلى هذا الموصل.
Classname:اسم الفئة
هو اسم ارتباط يمثله هذا الموصل.
الشكل التالي هو مثال لموصل مسمى.
الرابط بين الدواس pedal والعجلة wheel هو موصل يسمى "c" ، وهو عبارة عن سلسلة
يحدد UML عدة قواعد لتحديد أنواع العناصر في كل نهاية:
- إذا كان الموصل مثيلًا لاقتران ، يجب أن تكون أنواع المثيلات في أي من طرفي الرابط هي نفس الأنواع في أي من طرفي الاقتران.
- إذا تطلب مثيل في أحد طرفي الموصل واجهات ، فيجب أن يوفر المثيل الموجود في الطرف الآخر للموصل إحدى هذه الواجهات. ملاحظة التمثيل هو نسخة مشيدة عن الفئة اي كائن.
- إذا كان مثيل في أحد طرفي الموصل يشتمل على واجهات مطلوبة وكان المنفذ متصلاً بالطرف الآخر للموصل ، فيجب أن يوفر المنفذ واجهة مطلوبة.
- لم يتم تحديد وسائل الاتصال الفعلية بواسطة الموصل ؛ يمكن أن يمثل استدعاء طريقة بسيطة أو بروتوكول معقد عبر اتصال مأخذ التوصيل. يمكنك تقييد الاتصال باستخدام تدوين ملاحظة UML العادي. ما عليك سوى تحديد القيد في ملاحظة ، وربطه بالموصل باستخدام خط متقطع. يوضح الشكل التالي موصل مقيد.
شكل لموصل مقيد constrained connector
يمكنك تحديد تعدد كل طرف موصل باستخدام صيغة التعددية العادية. ما عليك سوى كتابة عدد المثيلات لنهاية معينة بالقرب من نهاية الموصل. على سبيل المثال ، قد تتطلب علاقة الطالب / المعلم ما لا يقل عن 5 طلاب ولا يزيد عن 20. يمكنك إظهار العلاقة بين الطالب / المعلم كما هو موضح في الشكل التالي.
يجب أن يكون لدى المعلم 5 طلاب على الأقل ولكن ليس أكثر من 20 طالبًا
المنافذ ports
المنفذ هو وسيلة لتقديم وظائف من هيكل مركب دون الكشف عن التفاصيل الداخلية لكيفية تحقيق هذه الوظيفة. على سبيل المثال ، قد يكون لديك نظام فرعي يمكنه إجراء التحقق من الدفع ببطاقة الائتمان. قد ينتشر التنفيذ الفعلي لهذه الوظيفة عبر عدة فئات تعمل بالتزامن. يمكن تمثيل تنظيم هذه الفئات كهيكل داخلي داخل النظام الفرعي ، ويمكن الكشف عن الوظيفة العامة ، أو التحقق من بطاقة الائتمان ، باستخدام منفذ. يتيح الكشف عن الوظيفة من خلال منفذ للنظام الفرعي أن يتم استخدامه بواسطة أي مصنف آخر يتوافق مع مواصفات المنفذ. بدءًا من UML 2.0 ، تم تمديد الفئات للسماح بالمنافذ والهياكل الداخلية. بشكل افتراضي ، تكون المنافذ عامة ، ولكن UML 2.0 يسمح لك بالحصول على منافذ داخلية متاحة فقط للهيكل المركب الذي يستضيفها.
تظهر لك المنفذ كمربع صغير. عادةً ما ترسم اسم وتعدد المنفذ بالقرب من المربع ، على الرغم من أن كلاهما قد يكون مخفيًا. إذا قمت برسم المنفذ الموجود على حافة المصنف ، فسيكون المنفذ عامًا ومتاحًا للبيئة. إذا قمت برسم المنفذ داخل مصنف ، فإن المنفذ محمي ومتاح فقط للهيكل المركب. يوضح الشكل التالي مثال منفذ.
النظام الفرعي CreditCardVerification مع منفذ عام واحد ، CreditCardServices
الواجهات المطلوبة والمتوفرة Required and provided interfaces
ترتبط المنافذ بالواجهات المطلوبة والمتوفرة
تظهر الواجهات المطلوبة ما قد يطلبه المصنف المالك من بيئته من خلال منفذ معين. تعرض الواجهات المتوفرة الوظيفة التي يعرضها المصنف للبيئة. على سبيل المثال ، قد يوفر نظام الدفع ببطاقات الائتمان الخاص بنا واجهة للتحقق من بطاقات الائتمان ، معالج CreditCard ، بينما يتطلب الوصول إلى نظام التحقق من الحساب ، خدمات الحساب ، التي تقدمها شركة بطاقة الائتمان. إذا كنت تستخدم المنافذ في الرسوم التخطيطية الخاصة بك ، فإن الواجهات المطلوبة والمقدمة تلتقط كل التفاعل الذي قد يكون للنظام مع مصنف معين. عادة ما يتم عرض الواجهات المقدمة والمطلوبة باستخدام تدوين الكرة والمقبس (المصاصة) ، على الرغم من أنه يمكنك كتابة منفذ بشكل صريح. إذا كان هناك العديد من الواجهات المطلوبة أو المتوفرة ، فما عليك سوى سرد اسم كل واجهة متبوعًا بفاصلة ؛ لا تظهر عدة مصاصات. يوضح الشكل التالي منفذًا بواجهة مطلوبة واثنين من الواجهات المتوفرة
يوفر النظام الفرعي CreditCardVerification واجهتين (معالج CreditCard و CardHolderVerification) ويتطلب واحدة (خدمات الحساب)
تحقيق تطبيقات المنافذ Realizing port implementations
يتم توصيل المنافذ بالتطبيق الداخلي باستخدام الموصلات. راجع "الموصلات" للحصول على معلومات حول كيفية تمثيل موصل. إذا كان المصنف الذي يمتلك المنفذ يوفر تنفيذ الوظيفة نفسها ، فإن المنفذ يعتبر منفذًا سلوكيًا. في هذه الحالة ، يرتبط الموصل بحالة داخل المصنف. تُستخدم هذه الحالة لشرح سلوك المصنف عند استخدام المنفذ (راجع الفصل 8 لمزيد من المعلومات حول استخدام الحالات لنمذجة السلوك). يستخدم هذا عادةً للمصنفات البسيطة (وليس الهياكل المعقدة) التي تنفذ الوظائف نفسها. يوضح الشكل التالي منفذًا سلوكيًا.
منفذ سلوكي
من ناحية أخرى ، إذا تم تحقيق الوظيفة من خلال عناصر داخلية ، فإنك تربط الموصل بالمصنفات الداخلية التي توفر التنفيذ. يستخدم هذا عادةً للهياكل المركبة مثل المكونات والأنظمة الفرعية. يوضح الشكل التالي مثل هذا المنفذ.
منفذ مرتبط بتنفيذ داخلي
موصلات متعددة multi connectors
يتيح لك UML 2.0 الحصول على موصلات متعددة تؤدي من منفذ إلى عناصر داخلية مختلفة. ومع ذلك ، فإنه لا يحدد ما يحدث عند تلقي الاتصال في ذلك المنفذ ؛ هذا متروك لمصمم الأزياء. تتمثل بعض الحلول الممكنة في إعادة توجيه الاتصال إلى جميع الموصلات ، أو إعادة التوجيه بناءً على الأولوية ، أو إعادة التوجيه على أساس جولة روبن ، أو ببساطة اختيار موصل عشوائيًا. بغض النظر عن قرارك ، تأكد من توثيقه في نموذجك ، ربما باستخدام ملاحظة مرفقة بالمنفذ. يوضح الشكل التالي مثالاً على استخدام منفذ به موصلات عديدة.
منفذ موصلات متعددة
تعدد المنافذ multi ports
قد يحدد المصنف التعددية لمنفذ مثل أي عنصر آخر. ما عليك سوى وضع العدد المطلوب من مثيلات المنفذ بين قوسين بعد اسم المنفذ ونوعه (إن وجد). عندما يتم إنشاء مثيل للمصنف ، يتم إنشاء مثيل للمنافذ المرتبطة أيضًا. هذه تسمى نقاط التفاعل ويمكن تحديدها بشكل فريد بواسطة المصنف. على سبيل المثال ، إذا كان المصنف الخاص بك يحتوي على منفذين ، أحدهما مزود بواجهات توفر وصولاً مجهولاً إلى البيانات والآخر مزود بواجهة توفر وصولاً مصادقًا إلى البيانات ، يمكن للمصنف الخاص بك التمييز بين المنفذ الذي تم استخدامه بواسطة النظام الخارجي. يوضح الشكل التالي نظام التحقق من بطاقة الائتمان الذي يقدم حالتين من منفذ التحقق من بطاقة الائتمان.
مكون مع نسختين من منفذ CCServices
كتابة المنفذ port typing
في الممارسة العملية ، عندما يتم إنشاء مثيل للمنفذ ، يتم تمثيله بواسطة المصنف الذي يدرك الواجهات المتوفرة. أي اتصال مع نقطة التفاعل هذه يمرر المعلومات ببساطة إلى المصنفات الداخلية التي تدرك السلوك. يتيح لك UML 2.0 تحديد نوع المنفذ باستخدام الفئات لتوفير سلوك أكثر تعقيدًا. على سبيل المثال ، يمكنك تحديد كتابة المنفذ باستخدام فئة تقوم بتصفية الاتصالات التي يتلقاها أو تعطي الأولوية للتسليم. عندما يتم إنشاء مثيل لهذا المنفذ ، يكون للفئة المقابلة فرصة لمعالجة الاتصال الذي يتلقاه قبل تمريره إلى المصنفات المحققة. لإظهار أنه يجب تمثيل المنفذ باستخدام مصنف محدد ، ما عليك سوى اتباع اسم المنفذ بنقطتين واسم المصنف المراد استخدامه. لاحظ أن المصنف يجب أن يدرك الواجهات المتوفرة. يمكنك استخدام هذا الترميز لإظهار الواجهات المتوفرة باستخدام واجهة كنوع المنفذ ، على الرغم من أن تدوين المصاصة غالبًا ما يكون أكثر مرونة. يوضح الشكل التالي منفذًا مكتوبًا بشكل واضح.
منفذ تمت كتابته بشكل صريح باعتباره PacketPrioritizer
الفئات المهيكلة والخصائص Structured Classes and Properties
عادةً ما تستخدم الفئات ذات العلاقات مع الجزء الكامل أسهم التكوين لإظهار علاقاتهم. في سياق الهياكل المركبة ، حدد UML 2.0 مصطلح الخاصية لوصف جزء "جزء" من علاقة الجزء كله. على سبيل المثال ، في نظام تشغيل رسومي ، قد يتكون التطبيق من نافذة رئيسية وعدة أزرار. الأزرار هي جزء من التطبيق ، بحيث يمكن إظهار العلاقة الكاملة بين التطبيق والأزرار باستخدام التكوين. ومع ذلك ، يتم مشاركة النافذة الرئيسية مع نظام التشغيل (بحيث يمكن للنظام تغيير موضع النافذة أو إخفائها) ؛ نتيجة لذلك ، تكون العلاقة بين نظام التشغيل والنافذة أضعف قليلاً وتظهر باستخدام الاقتران. يمكنك نمذجة علاقات التطبيق والنافذة والأزرار كما هو موضح في الشكل التالي.
علاقة التطبيق ، النافذة ، الزر
عند استخدامها في الرسوم البيانية للهيكل المركب ، تظهر العلاقات بين الخصائص في مستطيل المصنف المالك. يتيح لك ذلك تقييد الارتباط بين أجزاء المصنف المركب. على سبيل المثال ، يوضح الشكل السابق أنه يمكن ربط الأزرار بأي نافذة. باستخدام رسم تخطيطي للهيكل المركب ، يمكنك تقييد النافذة بحيث تقترن فقط بزر مملوك لنفس التطبيق. عندما تقوم برسم مخطط الهيكل المركب ، تظهر الخصائص المرتبطة بالهيكل المركب من خلال التركيب باستخدام مستطيلات صلبة ، ويتم عرض الخصائص المشتركة مع الهياكل الأخرى باستخدام مستطيل متقطع. يمكنك وضع معلومات التعددية لخاصية في مستطيلها في الزاوية اليمنى العليا ، أو بعد اسم الخاصية بين قوسين. يوضح الشكل
التالي مخطط الهيكل المركب لعلاقات التطبيق والنافذة والأزرار.
بالإضافة إلى تحديد كيفية ملاءمة الخصائص معًا ، يمكنك استخدام الهياكل المركبة لتحديد كيفية إنشاء مثيل ، يتم عرض الحالات من خلال وضع خط تحت اسم ونوع المصنف. يمكنك تحديد القيم الأولية لكل سمة من سمات المصنف من خلال تحديد اسم السمة متبوعًا بعلامة يساوي وقيمة السمة. عند استخدامها كمثيلات ، يمكنك تحديد الأدوار التي ستتولاها كل خاصية من خلال إظهار شرطة مائلة "/" متبوعة باسم الدور بعد اسم الخاصية ونوعها. يوضح الشكل 2 تهيئة زر بقيمه المناسبة.
يمكنك إظهار أن مثيل المصنف المالك مرتبط بمُنشئ معين لمصنف باستخدام سطر تبعية يسمى بالكلمة الأساسية «إنشاء». يمكنك استخدام أي معلمات للمنشئ عند تهيئة الخصائص ببساطة باستخدام اسم المعلمة. يوضح الشكل 3 الرسم التخطيطي المركب للتطبيق المرتبط بمُنشئ في فئة التطبيق.
علاقات التطبيقات والنافذة والأزرار كهيكل مركب
شكل 2
الهيكل المركب للتطبيق مع قيم الممتلكات
شكل 3
منشئ التطبيق المتعلق بمثيل التطبيق
التعاون
أحد الأغراض الأساسية للهياكل المركبة هو توثيق كيفية تنفيذ جزء معين من الوظائف داخل النظام. يسمى تنظيم العناصر لتحقيق السلوك بالتعاون. التعاون هو مجموعة من المثيلات التي تم توصيلها معًا باستخدام الموصلات لإظهار تدفق الاتصال.
نظرًا لأن الغرض من عمليات التعاون هو وصف كيفية عمل جزء معين من الوظائف ، يتم عادةً ترك التفاصيل خارج نطاق الوظيفة المطلوبة خارج الرسم التخطيطي. بدلاً من ذلك ، يعرض مخطط التعاون الروابط المطلوبة بين الطبعات والسمات المضمنة في التعاون. قد يكون لديك العديد من عمليات التعاون التي تتضمن نفس الحالات ولكن تظهر طرق عرض مختلفة لكل منها بناءً على الوظيفة المعبر عنها. تتمثل إحدى الطرق الفعالة لإظهار طرق عرض مختلفة للمصنف في استخدام الواجهات لتجميع الوظائف ذات الصلة. قد تدرك فئة واحدة واجهات متعددة ، ولكن يمكن لكل تعاون أن يركز على واجهة واحدة.
ضمن التعاون ، من المفيد تسمية الطبعات المعنية. عادةً ما تقوم بتسمية مثيل بناءً على دوره في التعاون. على سبيل المثال ، إذا كنت ترغب في تصميم نموذج مراقب / يمكن ملاحظته ، فمن المحتمل أن يكون لديك مثيل في دور المراقب ومثال في دور الموضوع.
تظهر تعاونًا باستخدام شكل بيضاوي متقطع مع كتابة اسم التعاون في الداخل. يوضح الشكل التالي تعاونًا يسمى "مراقب / يمكن ملاحظته.
الشكل السابق تعاون بسيط
هناك طريقتان لعرض تفاصيل التعاون. الأول هو إضافة مقصورة إلى الشكل البيضاوي للتعاون ورسم المثيلات المتضمنة في التعاون في الداخل. تظهر الروابط بين الحالات كخطوط متصلة. يتم تسمية كل مثيل وفقًا لدورها في التعاون. يوضح الشكل التالي الهيكل الداخلي للتعاون المراقب / المرصود.
التفاصيل الداخلية للتعاون
بدلاً من ذلك ، يمكنك إظهار المثيلات التي تشكل تعاونًا خارج القطع الناقص للتعاون واستخدام روابط الاتصال لربطها مرة أخرى. في هذه الحالة ، لا تحدد اسم الدور داخل المصنفات ؛ بدلاً من ذلك ، تكتب اسم الدور على طول رابط الاتصال لكل حالة. تتمثل ميزة هذا الترميز في أنه يمكنك تحديد السمات والعمليات المتضمنة في التعاون (تذكر أنه يمكنك استبعاد أي سمة أو عملية لا ترتبط مباشرة بالوظيفة التي تعبر عنها). عيب هذا الترميز هو أنك لا تضع نموذجًا لمسارات الاتصال المباشر بين الحالات المختلفة. يوضح الشكل التالي نمط المراقب / المرصود باستخدام هذا الترميز البديل.
الشكل السابق تعاون المراقب / المرصود مع تفاصيل خارج القطع الناقص للتعاون
توضح مواصفات UML أنه يمكن استبدال أي مصنف بأي عضو في التعاون طالما أنها توفر السمات والعمليات المناسبة لأداء دورها. على سبيل المثال ، في تعاون المراقب / المرصود الموضح في الشكل السابق ، يجب أن يكون لدى المرصد وسيلة لإضافة المراقبين وإزالتهم وإخطارهم ، ويجب أن يكون لدى المراقب طريقة للتعامل مع التغييرات التي يمكن ملاحظتها. يمكن استخدام أي مصنف آخر في هذا التعاون طالما أنه يمكنه توفير سمة خط الرسالة والعملية المناسبة. كما ذكرنا سابقًا ، تتناسب الواجهات بشكل جيد مع عمليات التعاون. يمكنك تحديد واجهة يمكن ملاحظتها والتقاط السمات والعمليات المطلوبة بالضبط برمجيًا لأداء دور ما.
يقوم UML 2.0 بعمل المصنفات الكاملة للتعاون ، مما يعني أنه يمكنك إرفاق مخططات التسلسل ، أو آلات الحالة ، أو أي مخطط سلوكي آخر للمساعدة في التقاط تفاصيل التنفيذ.
حالات التعاون
قدم UML 2.0 مفهومًا جديدًا للسماح لك بإرفاق تعاون بعملية معينة أو مصنف لإظهار كيفية تحقيقه بواسطة العناصر الأخرى. عندما تقوم بربط تعاون مع عملية أو مصنف ، فإنك تقوم بإنشاء حالة مشاركة. يمكنك التفكير في حالات التعاون على أنها حالات للتعاون. على سبيل المثال ، يمكنك استخدام حدوث تعاون لتوثيق كيف تشكل الفئات المختلفة نظامًا فرعيًا ، وما هو المسؤول عن الاستمرارية ، وما هو في الواقع واجهة لنظام فرعي آخر ، وما إلى ذلك. ميزة استخدام حدوث تعاون لتوثيق تنفيذ الوظيفة هي أنه يمكنك تعيين أسماء الأدوار للعناصر الداخلية للمصنف. قد يكون هناك تكرارات متعددة لتعاون معين داخل المصنف ، لكل منها عناصر داخلية مختلفة تفي بأدوار التعاون.
يمكنك إظهار حدوث مشاركة باستخدام نفس القطع الناقص المتقطع المستخدم لإظهار المشاركة ، باستثناء أنك تقوم بإدراج اسم التكرار متبوعًا بنقطتين ، ثم اسم نوع المشاركة. لكل دور مستخدم في التعاون الأصلي ، يمكنك رسم خط متقطع من حدوث التعاون إلى العنصر الذي يؤدي الدور. يمكنك تسمية السطر المتقطع باسم الدور. على سبيل المثال ، يظهر في الشكل التالي حدوث تعاون لتعاوننا المراقب / الذي يمكن ملاحظته.
حدثان للتعاون للمراقب / التعاون المرصود