كيف تُستخدم ال UML بشكل صحيح ؟

كيف تُستخدم ال UML بشكل صحيح ؟

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

سأتحدث عن طريقتين الآن الأولى وهي توضيح كل العلاقات والكلاسات وبما داخلها بشكل مفصل جداً (سوف نسمية Blueprint) ، أما الثانية وهو توضيح جزء معين من تصميم المشروع Designing فقط بدون حتى الدخول في تفاصيله الدقيقة (سوف نسميه Sketch )

هذه الطرق يمكن ان تستخدمها قبل كتابه المشروع Forward Engineering، أو بعد كتابه المشروع Reverse Engineering، ولكل منها سبب،

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

في الغالب القيام بعمل التفاصيل Blueprint يستلزم أدوات لتوليدها سواء كانت ضمن بيئتك البرمجية IDE أو أداة خارجية Third-Party تقوم بها (سواء قبل Forward أو بعد المشروع Reverse). الكتب الأكاديمية تسمى هذه الأدوات CASE Tools وقد سمى هذا المصطلح Martin Fowler (مهندس البرمجيات المعروف) بال Dirty Word وأن كثير من الشركات والمصنعين Vendors أصبحوا لا يستخدمونه ، واتفق معه في ذلك  ..

الطريقة الثانية للاستخدام UML وهو ما افضله واستخدمه وهو رسم ما يلزم لايصال الفكرة بدون الحاجه للدخول في التفاصيل Sketch. مثلاً كنت تريد ان تحل مشكلة عمل فهرسه للملفات فسوف تقوم بوضع ال High Level Design مع الفريق أو مع نفسك ومن ثم ترى هل سيحل هذا التصميم المشكلة ؟ فاذا كان كذلك والا فتقوموا بالتعديل عليه الا حين الوصول للشيء المناسب (طريقة الاستخدام هذه Forward Sketch تصلح ايضاً في اجتماعات المبرمجين في الفريق )، أو مثلاً لنقل أنك انهيت حل مشكلة ما وتريد توثيق الDesign أو أن هناك مبرمج جديد انضم وتريد شرح الفكرة العامه من هذا الاجزاء من الكود فال Reverse Sketch هنا أيضاً مفيد في تلك الحالة.

عندما تقوم بال Sketcher فقد لا تلتزم بأي Standard للرسم ، بمجرد أن تصل فكرتك المطلوبة للفريق وهذا هو الهدف Communication Ideas فهذا يكفى ولو لم تكن مطابق لل UML Standards (الصورة المرفقة توضح Sketch قديم قمت بعمله وهو يوضح فكرة معينة بغض النظر عن الالتزام الحرفي بالمعيار وطريقة الرسم).

فأسأل نفسك هل انت Sketcher أم Blueprinter ، ولا تتعصب لطريقة واستخدم كل منها في الوقت المناسب