أداة UML

📅 آخر تحديث: ٢٣ يوليو ٢٠٢٦
✍️ نُشر في: ٢٣ يوليو ٢٠٢٦
الموسوعة الحرة

أداة UML ( أداة لغة النمذجة الموحدة ) هي تطبيق برمجي يدعم بعض أو كل الرموز والدلالات المرتبطة بلغة النمذجة الموحدة (UML)، وهي لغة النمذجة العامة القياسية في مجال هندسة البرمجيات .

يتم استخدام أداة UML على نطاق واسع هنا لتضمين برامج التطبيقات التي لا تركز بشكل حصري على UML، ولكنها تدعم بعض وظائف لغة النمذجة الموحدة، سواء كإضافة أو كمكون أو كجزء من وظيفتها العامة.

أنواع الوظائف

تدعم أدوات UML الأنواع التالية من الوظائف:

رسم المخططات

يعني رسم المخططات في هذا السياق إنشاء وتحرير مخططات UML ؛ أي المخططات التي تتبع الترميز الرسومي للغة النمذجة الموحدة.

يتفق مطورو البرمجيات عمومًا على استخدام مخططات UML كوسيلة لرسم مخططات البرمجيات (غالبًا) الموجهة للكائنات . فعند رسم هذه المخططات، يستخدمون عادةً ترميز UML. ومع ذلك، غالبًا ما يُثار جدل حول مدى الحاجة إلى هذه المخططات، وفي أي مراحل من عملية تطوير البرمجيات ينبغي استخدامها، وكيفية تحديثها (إن وُجدت). وغالبًا ما تؤدي أولوية شفرة المصدر البرمجية إلى إهمال هذه المخططات.

هندسة الرحلة ذهابًا وإيابًا

تشير الهندسة العكسية إلى قدرة أداة UML على توليد الكود من النماذج، وتوليد النماذج من الكود (أي الهندسة العكسية )، مع الحفاظ على التناسق الدلالي بين النموذج والكود. سيتم شرح توليد الكود والهندسة العكسية بمزيد من التفصيل أدناه.

توليد الكود

في هذا السياق، تعني عملية توليد الشفرة أن يقوم المستخدم بإنشاء مخططات UML، التي تتضمن بيانات نموذجية مترابطة، ثم تستخلص أداة UML من هذه المخططات جزءًا أو كل الشفرة المصدرية لنظام البرمجيات. في بعض الأدوات، يمكن للمستخدم توفير هيكل أساسي للشفرة المصدرية للبرنامج، على شكل قالب شفرة مصدرية ، حيث يتم استبدال الرموز المميزة المُعرَّفة مسبقًا بأجزاء من الشفرة المصدرية للبرنامج أثناء عملية توليد الشفرة.

من الانتقادات الشائعة أن مخططات UML تفتقر إلى التفاصيل اللازمة لاحتواء نفس المعلومات التي يغطيها كود المصدر للبرنامج: يذكر جاك دبليو ريفز أن التجسيد النهائي للتصميم يكمن في كود المصدر. وقد أُسيء فهم عبارته الشهيرة "الكود هو التصميم" [ 1 ]، حيث فُسِّرت خطأً على أنها تعني عدم الحاجة إلى عناصر تصميم البرمجيات المتوسطة والعالية المستوى، مثل مخططات UML أو وثائق متطلبات البرمجيات.

الهندسة العكسية

الهندسة العكسية في هذا السياق تعني أن أداة UML تقرأ شفرة المصدر للبرنامج كمدخلات وتستمد بيانات النموذج ومخططات UML الرسومية المقابلة منها (على عكس المعنى الأوسع إلى حد ما الموضح في مقالة " الهندسة العكسية ").

من بين تحديات الهندسة العكسية ما يلي:

  • غالباً ما يحتوي الكود المصدري على معلومات أكثر تفصيلاً مما يرغب المرء في رؤيته في مخططات التصميم. وتُعالج هذه المشكلة من خلال إعادة بناء بنية البرمجيات .
  • لا تتضمن بيانات المخطط عادةً شفرة المصدر للبرنامج، لذا يتعين على أداة UML، في الخطوة الأولى على الأقل، إنشاء تخطيط عشوائي للرموز الرسومية لترميز UML أو استخدام خوارزمية تخطيط تلقائية لوضع الرموز بطريقة تُمكّن المستخدم من فهم المخطط. على سبيل المثال، يجب وضع الرموز في مواقع على لوحة الرسم بحيث لا يحدث تداخل. عادةً، يتعين على مستخدم هذه الوظيفة في أداة UML تعديل المخططات المُنشأة تلقائيًا يدويًا لتحقيق بعض المعنى. كما أنه غالبًا ما يكون من غير المجدي رسم مخططات لشفرة المصدر الكاملة للبرنامج، لأن ذلك يُمثل تفاصيل كثيرة جدًا لا تُفيد في مستوى مخطط UML.
  • من المعروف أن بعض ميزات لغات البرمجة يصعب تحويلها تلقائيًا إلى مخططات UML بكل تعقيداتها، على سبيل المثال: قوالب لغة C++ لـ أو .classfunction

تبادل النماذج والرسوم البيانية

يُعدّ تبادل بيانات XML الوصفية (XMI) تنسيقًا لتبادل نماذج UML. ولا يدعم XMI تبادل مخططات UML ، الذي يسمح باستيراد مخططات UML من نموذج إلى آخر.

تحويل النموذج

يُعدّ مفهوم تحويل نموذج إلى آخر أحد المفاهيم الأساسية المرتبطة بمبادرة هندسة البرمجيات الموجهة بالنماذج . فعلى سبيل المثال، قد يرغب المستخدم في تحويل نموذج مجال مستقل عن المنصة إلى نموذج خاص بمنصة جافا لتنفيذه. كما يُمكن إعادة هيكلة نماذج UML لإنتاج نماذج أكثر إيجازًا ووضوحًا. ومن الممكن أيضًا إنشاء نماذج UML من رموز نمذجة أخرى، مثل نموذج تدوين العمليات التجارية (BPMN)، وهو أيضًا أحد ملفات تعريف UML . ويُطلق على المعيار الذي يدعم ذلك اسم Query/View/Transformation ( QVT ). ومن الأمثلة على حلول QVT مفتوحة المصدر لغة تحويل ATLAS (ATL) التي طورها المعهد الفرنسي لأبحاث علوم الحاسوب والأتمتة (INRIA).

انظر أيضاً

مراجع

.