صورة من www.uml.org هذه
المقالة مخصصة لـ UML وخصائص تطبيقها في الوقت الحاضر. القليل من المعلومات التاريخية ، القليل جدًا ، فقط النقاط الرئيسية:
- ولد UML في التسعينات نتيجة للعمل على إنشاء لغة نمذجة موجهة للكائنات.
- تم إصدار المواصفات 1.0 في عام 1997.
- ظهرت المواصفات 2.0 في عام 2005.
- حتى الآن، UML 2.5، عدة ملامح مثل SysML و وضعت SoaML .
إذا نظرت إلى كيفية تطبيق UML بين الحين والآخر ، وفكرت في الأمر ، يمكنك استخلاص النتيجة التالية: دع إصدار UML أصبح الآن 2.5 ، ولكن لم تتغير مبادئ استخدام اللغة منذ الإصدار الأول.
ونتيجة لذلك: يستخدم المحللون مفهوم وصف أنظمة البرمجيات ، التي تم وضعها منذ أكثر من 20 عامًا. المفهوم نفسه جيد ، لكنك تحتاج إلى ربطه بمكان وسياق الاستخدام.
إذا واصلنا هذا التحليل لاستخدام UML ، وكذلك ربطه بمتطلبات الوقت الحالي ، فإن الاستنتاجات هي كما يلي:
- جميع تقنيات استخدام UML "تجول" استخدام التطوير المستند إلى حالة الأحرف.
- نماذج UML تفتقر إلى التكامل. إن النهج المختار لوصف جوانب البنية والسلوك والأعمال ومستويات التطبيق بشكل منفصل يعقد إدراك النماذج ككل.
- UML هي لغة موجهة للكائنات ، مما يجعل من الصعب التعبير عن مفاهيم أخرى بها.
لن أقول أي شيء عن نهج الاستخدام القائم على حالة الاستخدام ؛ أحد تجسيداته هو العملية العقلانية الموحدة. بعد ذلك ، سأتحدث عن النقطتين الأخيرتين.
جوانب العرض
يتكون UML من العديد من الرسوم البيانية. كل منها يخضع لقواعده الخاصة ، ويستخدم العناصر والسهام في فهمه الخاص. ومن الخارج لا تبدو كلغة موحدة ، بل كمجموعة من التمثيلات المختلفة ، والتي غالبًا ما يتم تقديمها كفرصة للنظر في مجال الموضوع من وجهات نظر مختلفة. بنفس النجاح ، يمكن تسمية السكين السويسري بأداة موحدة ، وهي في الأساس مجموعة تتكون من الشفرات والمفكات وفتاحات الزجاجات والملاعق والشوك وكل هذا على مقبض واحد.
ماذا يفعل المحلل عندما يحاول احتواء جميع المخططات في نموذج واحد؟ يبدأ في بناء المخططات الهجينة وربط الجداول. والنتيجة ليست نموذجًا واحدًا ، بل مجموعة من الرسوم البيانية التي تمت إضافة المزيد من الرسوم البيانية والجداول.
مستويات العرض
لنفترض أن محلل أعمال قد وصف مجال الموضوع باستخدام الرسوم البيانية لـ UML. والآن يحتاج محلل الأنظمة أو نفس المحلل إلى تشكيل نموذج لنظام برمجيات. إذا كان المحلل يركز على UML ، فسيبدأ في إنشاء تمثيلات مقابلة لتلك التي تم تقديمها سابقًا ، ولكن بالفعل في إطار النظام. سيبدو مثل الرسوم البيانية مماثلة مرة أخرى.
ماذا سيفعل المحلل عندما يريد مقارنة وصف مجال الموضوع ونموذج النظام؟
يبدأ في إنشاء الرسوم البيانية الهجينة ، وربط الجداول والتتبعات مرة أخرى.
والنتيجة هي الكثير من الرسوم البيانية والجداول.
وتجدر الإشارة هنا إلى أن لغة UML هي لغة قديمة ويوجد بها الكثير من الكتب والأمثلة القديمة.الذي يصف بشكل رئيسي حالات الانتقال من الأعمال غير الآلية إلى الأعمال الآلية. ويتعلم المحللون من هذه الأمثلة. ولكن اليوم ، تغلغلت تكنولوجيا المعلومات في كل مكان. نهج "العمل بشكل منفصل ، تكنولوجيا المعلومات بشكل منفصل" غير مقبول .
نهج موجه نحو الخدمة
UML هي لغة موجهة للكائنات ، مما يجعل من الصعب التعبير عن مفاهيم أخرى بها. على سبيل المثال ، الخدمة الموجهة. في ملف تعريف UML القياسي ، لا يوجد مفهوم "الخدمة" ، ولكن يوجد ملف تعريف SoaML ، والذي يتم تقديمه كلغة نمذجة لبنية موجهة نحو الخدمة.
سأتحدث بإيجاز عن النهج الموجه نحو الخدمة ، بحيث يتضح لاحقًا لماذا SoaML غير مناسب لنمذجته. دعونا نأخذ تفسير التعاريف من TOGAF كأساس .
من أجل إضفاء طابع رسمي بسيط على نهج موجه نحو الخدمة ، نحتاج إلى تجريدين:
- العملية هي تدفق التحكم بين / فوق الخدمات. يجب أن يقال أيضًا أن العملية هي سلسلة من الإجراءات التي تحقق معًا نتيجة معينة.
- الخدمة هي عنصر من السلوك يوفر وظائف معينة استجابة لطلبات الموضوعات أو الخدمات الأخرى. توفر الخدمة أو تدعم الإمكانات ، ولها واجهة صريحة ، وتتم إدارتها بشكل صريح.
دعونا نرى كيف تم تصميم هذا على SoaML. في نفس الوقت ، سوف نقارن كيف ستختلف النمذجة الموجهة للكائنات في UML والنمذجة الموجهة نحو الخدمة في SoaML.
رجل ومتجر
المهمة: وصف نموذج شراء البضائع في المتجر.
أعتقد أن المنهج الموجه للكائن واضح وبسيط للجميع. حتى لا نضيع الوقت ، لن نفكر في مستوى الأعمال. أعتقد أن كل شخص يمكن أن يتخيل في رأسه حالة الاستخدام المشورة وتفاصيلها في شكل مخطط نشاط أو مخطط تسلسل.
لا يعمل الشخص كمستخدم ، ولكن كواحد من جوانب التفاعل.
الآن سنقوم بحل هذه المشكلة باستخدام SoaML ، طبقًا للمواصفات بدقة .
في هذا الرسم البياني ، نحدد مجتمع التفاعل ، وهذا هو المتجر والشخص.
نحدد العملية التجارية "بيع البضائع" التي تعمل بينهما ، والتي يعمل فيها المتجر بمثابة "البائع" والشخص باعتباره "المشتري".
استنادًا إلى عملية الأعمال ، يمكننا الآن تحديد خدمة الأعمال التالية ؛ في SoaML ، يتم استخدام مصنف ServiceContract لهذا الغرض.
في إطار هذه الخدمة: يعمل البائع كمزود والمشتري كمستهلك.
يقدم البائع كمورد عملية "بيع" واحدة. انتهى تحليل الأعمال ، نذهب إلى مستوى النظام.
نحتاج إلى وضع نسخة محدثة على مستوى النظام من عملية أعمالنا لبيع منتج. لهذا اخترت مخطط تتابع ، يمكنك استخدام أي مخطط سلوك آخر.
من عملية الأعمال المحدثة ، يمكننا تحديد عملية واحدة "بيع" ، وسوف نقوم بترتيبها في الواجهة الأساسية "من يعرف كيف يبيع".
بعد ذلك ، نحتاج إلى وصف واجهات الخدمة التي سيتم استخدامها لتنفيذ الخدمة.
نحصل على واجهات الخدمة التالية:
- "الرغبة في البيع" ، الموروثة من واجهة "البيع" ؛
- "الحاجة للشراء" ، والذي يعتمد على واجهة "البيع".
يمكنك الآن تمثيل نموذج الخدمة الهدف كمخطط هيكل مركب.
دعنا نقارن نتائج النمذجة الكائنية في UML والنمذجة الموجهة نحو الخدمة في SoaML.
بصريا ، الفرق الكلي هو في هذه المربعات الصغيرة على حدود المكونات. قمت بوضع علامة عليها باللون الأحمر. هل هذا كل الفرق؟
يوجد بالفعل الفرق بين النمذجة الموجهة للكائنات والموجهة نحو الخدمة ، فقط قام SoaML بتقليص كل شيء إلى كائنات. ولكن أكثر عن ذلك لاحقا.
والآن سننتهي من النظر في SoaML في حالة أكثر تعقيدًا ، ثم سنحصل على المخططات التالية تقريبًا.
ما هو الخطأ في رأيي مع SoaML.
أولا: مرة أخرى ، مشكلات سلامة اللغة والعلاقة بين مستوى الأعمال ومستوى التطبيقات ، لقد رأيت بنفسك مدى صعوبة كل شيء فيما يتعلق ببعضها البعض.
ثانياً : توصف الخدمة بأنها كائن هيكل ، وهذا ليس جيداً. في اللغة الروسية ، تعد عبارة "المزود يمثل الخدمة" أمرًا شائعًا ، وهذا نهج موجه نحو المكون يتم تطبيقه في SoaML. ولكن في حالة النموذج الموجه نحو الخدمة ، من الأصح أن نقول "المورد يوفر الخدمة". وإذا قمت بترجمة "الخدمة" إلى اللغة الروسية بطريقة أخرى ، فسيكون كل شيء في مكانه على الفور: "يقدم المزود الخدمة ". من وجهة النظر هذه ، "الخدمة" ليست "كائنًا" ، إنها "سلوك".
ثالثا: في الشريحة الخاصة بالعمارة الموجهة نحو الخدمة ، تحدثت عن تجريدين: العملية والخدمة. إن عرضهم ووصفهم من خلال عدسة النهج الموجه نحو الأشياء ، بعبارة ملطفة ، مهمة مرهقة.
نماذج
دعنا نعود إلى UML. UML ، من خلال نموذجه ، يحاول وصف النماذج الأخرى.
وإذا كان كل شيء يعمل مع نموذج موجه للمكونات ، فيمكن تمثيله على أنه استمرار منطقي لنموذج موجه نحو الكائن. مع تحول نحو الخدمة الموجهة بشكل سيئ.
في هذه الحالة ، التعبير عن نموذج واحد من خلال فكرة مؤسفة أخرى.
لقد برهنت على استخدام مثل هذا المفهوم مع SoaML باستخدام مثال مشكلة "الشخص والمتجر".
يتعلق بالنماذج بشكل أفضل كما هو موضح أدناه.
دعني أوضح كيف تختلف النمذجة الموجهة نحو الخدمة عن المنحى بالكائنات.
رجل وكلب
المهمة: وصف نموذج للتفاعل - يمشي الشخص مع كلب.
بدون تفكير ثانٍ ، من المحتمل أن يتم حل هذه المهمة من قبل أي طالب في الكلية التقنية. في المدارس والجامعات في التخصصات ذات الصلة ، فإن البرمجة الشيئية أمر إلزامي. يتم عرض النهج الشيئي أدناه.
وكيف سيبدو النموذج ذو النهج الموجه نحو الخدمة؟ لا أعرف ما إذا كان الطالب سيجيب على مثل هذا السؤال.
هذا ما أود الحصول عليه. (فكر لنفسك لمدة دقيقة ، ثم انظر)
, . - . () () «».
, . - . () () «».
يمكنك تذكر تاريخ البرمجة الشيئية. كيف كان حتى الأشخاص ذوو السلطة ، مثل Edsger Dijkstra و Niklaus Wirth ، متشككين في بداية ظهوره. وحتى يومنا هذا ، يعتبر بعض الناس أن OOP لا يستحق الانتباه.
حسنًا ، هذا النموذج يمكن أن يسبب الابتسامات أيضًا. النقطة هي أن النموذج الموجه للخدمة ليس لديه دعم كاف على المستوى الأولي للبرمجة والتصميم. بالنسبة للمبرمجين ، يتم توفير الدعم فقط من خلال أطر العمل ، على سبيل المثال ، Java Enterprise Edition أو Spring. أعتقد أن المبرمجين يصلون إليهم برأس منسق بالفعل لنهج موجه نحو الكائنات.
يبني المحللون فهمهم للهندسة والتصميم الموجهين نحو الخدمة على المقالات على الإنترنت التي تفهم بشكل مختلف ما هي عليه ، وبعض المقالات دون الغوص العميق في التفاصيل والتفاصيل الفنية غامضة بشكل عام. ونتيجة لذلك ، يعود المحللون إلى حالات الاستخدام المقبولة بشكل عام بين النظام والمستخدمين. من الشائع أيضًا أن يتم تصميم بنية النظام وتكوين مكوناته بالفعل من قبل المهندس المعماري أو يتم تحديدها بواسطة النظام الأساسي المختار. ثم يصف المحللون مرة أخرى ببساطة حالة الاستخدام بين النظام والمستخدمين.
قارن بين المقاربة الشيئية وهذا النهج السخيف على ما يبدو ، حيث يقدم الرجل الكلب خدمة "المشي". عندما يتوقف الأمر عن أن يكون مضحكا بالنسبة لك ، ولكن النهج الموجه للكائن ، حيث يقوم الإنسان بتنفيذ طريقة "المشي" ، سيبدو مضحكا ،عند المدخل الذي يتغذى عليه الكلب !!! وذلك عندما جئت إلى فهم النموذج الموجه نحو الخدمة.
وتجدر الإشارة إلى أن هذه النماذج متوافقة تمامًا. لا يزال بإمكان الشخص أداء أفعاله المعتادة: النوم والرقص ، ويمكن أن ينبح الكلب.
نقطة أخرى: في هذا المثال ، قدمت مفهومًا جديدًا لـ "الخدمة". في الوقت نفسه ، لم أقم بعد بتحديد القواعد بوضوح لاستخدامها ، ولكنها تختلف عن تلك الموجودة في SoaML. هنا يجب أن تكون حذرًا ، لا تبالغ في هذا ، لأن هذا النوع من التمديد يشير إلى metamodeling. قد يحدث أن تصبح النماذج التي تم إنشاؤها متناقضة وغامضة.
بدلا من الاستنتاج
- UML . , . .
- . , . .
- UML . , . , UML, .