سؤال

ممكن مكررة:
هل UML عملي؟

سمعت العديد من الآراء حول UML. يقول بعض الناس أنه لا طائل منه. يقول بعض الناس أنه مفيد للغاية.

ما هي تجربتك على استخدام UML؟ كيف يؤثر على عملية التنمية؟

هل كانت مفيدة؟

المحلول

g'day،

أجد أنني أميل إلى استخدام مجموعة فرعية من معيار UML الكامل.

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

مخططات التسلسل: لإظهار كيف تتفاعل الفصول مع بعضها البعض وإظهار تدفق الرسائل بين الفئات في تسلسل استخدام الرسالة.

وأحيانا:

مخططات النشاط: لإظهار المعالجة الموازية.

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

هذر

في صحتك،

نصائح أخرى

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

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

كل ما يساعدك على توفير الوقت والمال.

UML يمكن أن تكون جيدة أو سيئة ... الكثير من أي شيء يمكن أن يكون سيئا.

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

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

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

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

غالبا ما تكون الورق والأبضاء والمناديل في كثير من الأحيان أفضل صديق! سوف يساعدونك على تذكر واكتساب فهم أعمق لأفكارك ومفاهيمك.

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top