هل UML عملي؟[مغلق]

https://stackoverflow.com/questions/18803

09-06-2019
|

سؤال

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

يحرر: تجربتي تقتصر على المشاريع الصغيرة التي تقل عن 10 مطورين.

يحرر: هناك العديد من الإجابات الجيدة، وعلى الرغم من أنها ليست الأكثر تفصيلاً، إلا أنني أعتقد أن الإجابات المختارة هي الأكثر توازناً.

المحلول

في نظام معقد بما فيه الكفاية هناك بعض الأماكن حيث تعتبر بعض لغة UML مفيدة.

تختلف الرسوم البيانية المفيدة للنظام حسب قابلية التطبيق.ولكن الأكثر استخدامًا هي مخططات الحالة، ومخططات النشاط، ومخطط التسلسل.

هناك العديد من الشركات التي تقسم بها والعديد ممن يرفضونها تمامًا باعتبارها مضيعة للوقت والجهد.

من الأفضل عدم الإفراط في التفكير والتفكير في ما هو الأفضل للمشروع الذي تعمل عليه واختيار الأشياء القابلة للتطبيق والمنطقية.

نصائح أخرى

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

لا يتعلق الأمر فقط بما تفعله.ماذا عن الموظف الجديد الذي سيأتي بعد ستة أشهر من الآن ويحتاج إلى سرعة تنفيذ الكود؟ماذا بعد خمس سنوات من الآن عندما يختفي كل من يعمل حاليًا في المشروع؟

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

لقد وجدت أن مفتاح التوثيق هو الاعتدال.لن يقرأ أحد 50 صفحة من مخططات UML الكاملة مع وثائق التصميم دون أن ينام بضع صفحات فيها.من ناحية أخرى، يرغب معظم الأشخاص في الحصول على 5-10 صفحات من الرسوم البيانية البسيطة للفصل مع بعض الأوصاف الأساسية لكيفية تجميع النظام.

الحالة الأخرى التي وجدت فيها UML مفيدة هي عندما يكون أحد كبار المطورين مسؤولاً عن تصميم مكون ولكن بعد ذلك يقوم بتسليم التصميم إلى مطور مبتدئ لتنفيذه.

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

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

يمكن أن يكون سير العمل العام وDFDs مفيدًا جدًا للعمليات المعقدة.جميع الرسوم البيانية الأخرى (وخاصة UML) كانت، في تجربتي، دون استثناء مضيعة مؤلمة للوقت والجهد.

يجب أن لا أوافق على ذلك، يتم استخدام UML في كل مكان - في أي مكان يتم فيه تصميم مشروع تكنولوجيا المعلومات، عادة ما تكون لغة UML موجودة هناك.

الآن ما إذا كان يتم استخدامه حسنًا إنها مسألة أخرى.

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

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

واحدة من أكبر مشاكل UML هي مقدار العمل المطلوب لإبقائها محدثة بمجرد إنشاء التعليمات البرمجية، حيث يوجد عدد قليل من الأدوات التي يمكنها إعادة هندسة UML من التعليمات البرمجية، ولا يزال القليل منها يقوم بذلك بشكل جيد.

سأقوم بتأهيل إجابتي بالإشارة إلى أنني لا أملك خبرة في بيئات تطوير الشركات الكبيرة (مثل IBM).

الطريقة التي أعرض بها UML و عملية موحدة عقلانية هو أنه أكثر من ذلك تتحدث حول ما ستفعله من الواقع عمل ماذا ستفعل.

(بعبارة أخرى، إنها مضيعة للوقت إلى حد كبير)

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

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

كان وقت الفصل محدودًا، كما كان الوقت الذي أقضيه خارج الفصل الدراسي.على هذا النحو، كان علينا إجراء مراجعات للتعليمات البرمجية في كل اجتماع للفصل الدراسي، ولكن مع تسجيل 25 طالبًا، كان وقت المراجعة الفردية قصيرًا جدًا.كانت الأداة التي وجدناها الأكثر قيمة في جلسات المراجعة هذه هي ERD ومخططات الفصل ومخططات التسلسل.تم عمل مخططات ERD والفصل الدراسي فقط في Visual Studio، لذلك كان الوقت اللازم لإنشائها تافهًا للطلاب.

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

بدون استخدام الرسوم البيانية، كان علينا أن نأخذ الوقت الكافي لتصفح ملفات التعليمات البرمجية الخاصة بالطلاب واحدًا تلو الآخر بحثًا عن المشكلات.

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

تواصل
وثائق التصميم/الحل الموحدة
تعريف DSL (لغة المجال المحددة).
تعريف النموذج (ملفات تعريف UML)
استخدام النمط/الأصول
رمز الجيل
نموذج لنموذج التحولات

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

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

لقد عملت UML بالنسبة لي لسنوات.عندما بدأت قرأت كتاب فاولر UML المقطر حيث يقول "افعل ما يكفي من النمذجة/الهندسة المعمارية/وما إلى ذلك".فقط استخدم ما لك يحتاج!

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

أعتقد أن لغة UML مفيدة وأعتقد أن مواصفات الإصدار 2.0 جعلت ما كان في السابق مواصفات واضحة منتفخًا ومرهقًا إلى حد ما.أنا أتفق مع إصدار الرسوم البيانية للتوقيت وما إلى ذلك لأنها ملأت الفراغ ...

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

ومع ذلك، فأنا أحب أدوات UML التالية:

البنفسجي - لو كان الأمر أكثر بساطة لكانت قطعة من الورق
Altova UModel - أداة جيدة لنمذجة Java وC#
MagicDraw - أداتي التجارية المفضلة للنمذجة
بوسيدون - أداة لائقة ذات قيمة جيدة مقابل المال
StarUML - أفضل أداة نمذجة مفتوحة المصدر

تعد مخططات UML مفيدة لالتقاط المتطلبات وتوصيلها والتأكد من أن النظام يلبي تلك المتطلبات.ويمكن استخدامها بشكل متكرر وخلال مراحل مختلفة من التخطيط والتصميم والتطوير والاختبار.

من الموضوع: استخدام النماذج في عملية التطوير في http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

يمكن أن يساعدك النموذج في تصور العالم الذي يعمل فيه نظامك ، وتوضيح احتياجات المستخدمين ، وتحديد بنية نظامك ، وتحليل الكود ، والتأكد من تلبية الكود الخاص بك بالمتطلبات.

قد ترغب أيضًا في قراءة ردي على المشاركة التالية:

كيف تتعلم "تصميم/هندسة البرمجيات الجيدة"؟ في https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

وعلى الرغم من أن هذه المناقشة ظلت خاملة لفترة طويلة، إلا أن لدي نقطتين - في رأيي مهمتين - أود إضافتهما.

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

UML له جانب مهم آخر:إنها "تتحدث" مباشرة مع أقوى قدراتنا، وهي قدرة التصور.على سبيل المثال، لو أن ITIL V3 (في جوهره بسيط بما فيه الكفاية) تم توصيله في شكل مخططات UML، لكان من الممكن نشره على بضع عشرات من المطويات بحجم A3.وبدلاً من ذلك، فقد ظهر في عدة مجلدات ذات أبعاد توراتية حقًا، مما أدى إلى إنتاج صناعة بأكملها، وتكاليف مذهلة وصدمة جامدة واسعة النطاق.

أرى مخططات التسلسل ومخططات النشاط تستخدم في كثير من الأحيان.أقوم بالكثير من العمل باستخدام أنظمة "الوقت الفعلي" والأنظمة المدمجة التي تتفاعل مع الأنظمة الأخرى، كما أن المخططات التسلسلية مفيدة جدًا في تصور جميع التفاعلات.

أحب عمل مخططات حالة الاستخدام، لكنني لم أقابل الكثير من الأشخاص الذين يعتقدون أنها ذات قيمة.

لقد تساءلت كثيرًا عما إذا كان Rational Rose مثالًا جيدًا لأنواع التطبيقات التي تحصل عليها من التصميم القائم على نموذج UML.انها منتفخة، عربات التي تجرها الدواب، بطيئة، قبيحة، ...

لقد وجدت أن لغة UML ليست مفيدة حقًا للمشاريع الصغيرة جدًا، ولكنها مناسبة حقًا للمشاريع الأكبر حجمًا.

في الأساس، لا يهم حقًا ما تستخدمه، عليك فقط أن تضع في اعتبارك شيئين:

تريد نوعا من التخطيط المعماري
تريد التأكد من أن كل فرد في الفريق يستخدم بالفعل نفس التكنولوجيا لتخطيط المشروع

إذن UML هو ما يلي:معيار لكيفية التخطيط لمشاريعك.إذا قمت بتعيين أشخاص جدد، فمن المرجح أن تكون على دراية بأي معيار موجود - سواء كان UML، أو Flowchard، أو Nassi-Schneiderman، أو أي شيء آخر - بدلاً من الأشياء الموجودة داخل الشركة.

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

UML مفيد، نعم بالفعل!الاستخدامات الرئيسية التي قمت بها هي:

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

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

أعتقد أنه قد تكون هناك طريقة لاستخدام حالات استخدام UML على طراز Cockburn ، والطائرة الورقية ، وحالات الاستخدام على مستوى البحر كما وصفها Fowler في كتابه "Uml Distilled". كانت فكرتي هي توظيف حالات استخدام Cockburn كمساعد لقدرة الكود.

لذلك قمت بتجربة وهناك منشور هنا مع العلامة "UML" أو "Fowler". لقد كانت فكرة بسيطة لـ C#.ابحث عن طريقة لتضمين حالات استخدام Cockburn في مساحات أسماء بنيات البرمجة (مثل مساحات أسماء الفئات والفئة الداخلية أو عن طريق الاستفادة من مساحات الأسماء للتعدادات).أعتقد أن هذا يمكن أن يكون أسلوبًا قابلاً للتطبيق وبسيطًا ولكن لا يزال لدي أسئلة وأحتاج إلى الآخرين للتحقق منه.قد يكون هذا مفيدًا للبرامج البسيطة التي تحتاج إلى نوع من اللغة الزائفة الخاصة بالمجال والتي يمكن أن توجد مباشرة في منتصف كود C# دون أي امتدادات لغة.

من فضلك قم بمراجعة المنشور إذا كنت مهتما.يذهب هنا.

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

لقد حاولت أيضًا طرح أسئلة محددة حول وثيقة البنية الفوقية في العديد من منتديات UML، ولأعضاء OMG نفسها، مع نتائج قليلة أو معدومة.لا أعتقد أن مجتمع UML ناضج بما يكفي لدعم نفسه.

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

يتم استخدام UML بمجرد تمثيل فصل دراسي بحقوله وأساليبه على الرغم من أنه مجرد نوع من مخططات UML.

مشكلة UML هي أن كتاب المؤسسين غامض للغاية.

UML هي مجرد لغة، وليست طريقة حقًا.

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

UML له مكانه.وتزداد أهمية ذلك مع نمو حجم المشروع.إذا كان لديك مشروع طويل الأمد، فمن الأفضل توثيق كل شيء في UML.

يبدو أن UML مناسب للمشاريع الكبيرة التي تضم فرقًا كبيرة من الأشخاص.ومع ذلك فقد عملت في فرق صغيرة حيث يكون التواصل أفضل.

يعد استخدام مخططات UML-esque أمرًا جيدًا، خاصة في مرحلة التخطيط.أميل إلى التفكير في البرمجة، لذلك أجد صعوبة في كتابة مواصفات كبيرة.أفضّل تدوين المدخلات والمخرجات وترك المطورين يصممون الجزء في المنتصف.

في تجربتي:

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

إن معرفة تفاصيل UML - متى يتم استخدام خط متقطع، أو نقطة نهاية دائرة - ليس ضروريًا تمامًا، ولكنه لا يزال أمرًا جيدًا.

أعتقد أن UML مفيد فقط لأنه يجعل الناس يفكرون في العلاقات بين فئاتهم.إنها نقطة انطلاق جيدة للبدء في التفكير في مثل هذه العلاقات، لكنها بالتأكيد ليست حلاً للجميع.

في اعتقادي أن استخدام UML يخضع للموقف الذي يعمل فيه فريق التطوير.

UML مفيد بطريقتين:

الجانب الفني:يعتقد الكثير من الأشخاص (المدير وبعض المحللين الوظيفيين) أن لغة UML هي ميزة فاخرة لأنها الكود هو التوثيق:تبدأ البرمجة، بعد تصحيح الأخطاء وإصلاحها.إن مزامنة مخططات UML مع التعليمات البرمجية والتحليلات تجبرك على فهم طلبات العميل جيدًا؛
الجانب الإداري:تعد مخططات UMl مرآة لمتطلبات العميل غير الدقيقة:إذا قمت بالبرمجة بدون UML، فربما يمكنك العثور على خطأ في المتطلبات بعد ساعات طويلة من العمل.تسمح لك الرسوم البيانية UML بالعثور على نقاط الخلاف المحتملة وحلها قبل أن يساعدك الترميز في التخطيط.

بشكل عام، جميع المشاريع التي لا تحتوي على مخططات UML لديها تحليل سطحي أو ذات حجم قصير.

إذا كنت في مجموعة ينكدين مهندسي النظم, ، يرى مناقشتي القديمة.

في النهاية UML موجود فقط بسبب RUP.هل نحتاج إلى UML أو أي من الأشياء ذات الصلة لاستخدام Java/.Net؟الإجابة العملية هي أن لديهم وثائقهم الخاصة (javadoc وما إلى ذلك) وهي كافية وتتيح لنا إنجاز مهمتنا!

UML لا ثناكس.

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

UML بالتأكيد لها مكانها في الصناعة.تخيل أنك تقوم ببناء برنامج لطائرات بوينج أو أي نظام معقد آخر.سيكون UML و RUP عونا كبيرا هنا.

UML هي إحدى طرق التواصل بين الأشخاص.السبورة البيضاء أفضل.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow