ما مدى استخدام UML في عملنا اليومي كمبرمجين؟

ممكن يستفيد منها المحلل اكثر من المبرمج عشان تكون الطريقة المناسبة للحديث بها للعميل .. لانها لغة موحده وسهل تعلمها

لم أستخدمها في أيٍ من المشاريع التي عملتُ عليها حتي الآن، ربما يكون السبب في ذلك هو أنني أعمل منفرداً في أغلبها و أحتاج باستمرارٍ إلي التركيز علي الأمور التي أري أنه لا مفر من عملها، بينما أقوم بتجاهل كل ما يمكنني تجاهله و لا أجد بسبب تجاهلي إياه ضررا.

ربما أكون مخطئا: و لكن لم أحس بأنها ذات أهميةٍ فائقةٍ بالنسبة لعملي.

انا لا ازال طالب في الجامعة تخصص software engineering

واليوم كان فاينل اكزام لمادة software design كلها عن UML و Design Pattern

ورقة الاجابة كلها رسوم UML بانواعها سواء Structure او Behavior بكل ما فيهم من رسمات

مدري عن طبيعة العمل في الخارج لكن لو بتكلم عن الDesign Pattern مثلا صحيح انه فكرة حل المشكلة موجودة في الراس وتقدر تطبقها مباشرة لكن احيانا تكون معقدة زيادة فلازم تلجأ الى رسم Structure diagrams بكل اللي فيه Class , Object , Pakage .. الخ وتحلل المشكلة بالكامل

القكرة كلها انه مجرد لغة موحدة بين المطورين ويفهموها اما ان انك ما تعرف عنها اي شي وتشتغل لوحدك فمجرد حلل برنامجك باي طريقة انت تفهمها وبس

بالنسبة لرسمات الBehavior مثل use-case , sequence , Activity ... الخ ابسط شي ممكن يقال عنها انها المتطلبات اللي بينك وبين العميل باكثر من مستوى ما تشرح طريقة كتابة الكود مباشرة مجرد الشكل الخارجي

غالبا حسب كلام المدرس وقت العمل (في الشركات الضخمة) لكل واحد له وظيفة معينة وكل شخص مسؤول عن رسمات معينة يشتغل عليها

استخدم ال Class diagram لتوضيح الجزئية التي أقوم بتصميمها في مرحلة ال modeling ، لا أركز على التفاصيل الدقيقة. يهمني هو توضيح ال pattern المستخدم.

النتيجة: Model متناسق وكود عالي الجودة، يصعب الحصول اليه بدون ذلك.

استخدم Use Case لتوضيح حالات استخدام المنتج ، ستحتاج الى توضيح جميع الحالات وجميع المكونات الخارجية التي تقوم بالتعامل مع الحالة.

النتيجة: أخذ فكرة شاملة عن المشروع، وأيضا قياس لمدى تقدمك (يمكنك اعتبار اي use case على أنها user story وتبدأ العمل عليها)

استخدم Sequence diagram لوصف عملية معقدة بشكل تسلسلي.

النتيجة: فهم العملية المعقدة complex business operation بشكل سريع وأخذ تصور فوري عن بداية العملية ونهايتها والمدخلات والمخرجات من الخطوات الداخلية.

في مثل هذه العمليات غالبا ما يستخدم الكود العديد من ال patterns التي ربما تحتاج الى وقت طويل لتتبعها في حالة لم تجد sequence diagram.

لم أستخدمها أبداً .. أستخدم WorkFlow , DataFlow

ولشرح المشاريع للمستخدم العادي أستخدم Info Graphics بدون قواعد فقط أركز على توصيل الفكرة بالصور والابتعاد عن الأمور التقنية.

لم أجد حاجة ل UML في مشاريعي رغم أني عملت على بعض المشاريع الكبيرة التي يعمل عليها عدة أشخاص.

استخدمها كوسيلة مساعده Sketching لتوضيح Module أو جزء معين من تصميم الكود High Level Design (مثلاً فيه أكثر من Patterns وقد يصعب فهمه من الكود) ، بعكس استخدامها ك Blueprint (التي عاده يقوم بها الطلاب) وهي رسم كل صغيرة وكبيرة في المشروع وسوف تخرج بأوراق طويلة عريضة سوف تحرقها بالنار بعد أول عملية Refactoring.

هذه الطريقة Sketching مناسبه في العالم الحقيقى (سواء قبل كتابه الكود Forward أو بعد كتابه الكود Reverse) لأنك ستخرج برسم يوضج لك الفكرة من وراء هذه الجزئية وأي مبرمج آخر يستطيع معرفة الفكرة من التصميم بمجرد رؤية الرسم ، ويمكنك فيما بعد (في الغالب) رمي هذه الرسمة في سله المهملات اذا لم تعد بحاجه اليها

هذا من وجهه نظرى هي طريقة تنفع في العالم الحقيقي (سواء في غرفه الاجتماعات أو على لوحة بيضاء لعمل بنية المشروع الأساسية) حيث أنها مناسبة جداً لمشاركة الاراء بشكل موحد Ideas Communication (وحتى لو تستخدم المعيار Standard وتلتزم به بشكل دقيق).

هناك مشاركة في صفحة على الفيس تتحدث حول نفس الموضوع:

باعتقادي كلما زاد تعقيد البرنامج الذي تود برمجته زادت حاجتك الى استخدامها، انا استخدمها فقط في البرامج والمشاريع الضخمة

معلومات جديدة قيمة بارك الله فيك