UML للمطورين

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

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

ماذا سنرسم؟


إذا كان هدفك "سريعًا وجميلًا" (على سبيل المثال ، للعرض التقديمي أو لهذه المقالة) ، فإن Visio أكثر من مناسب: محررها مناسب ويغفر أي انحرافات عن التدوين.

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

مهمة فنية


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

أبسط رسم تخطيطي هو حالة الاستخدام:



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

تسأل - وما هي الفائدة؟ بعد كل شيء ، يمكن تحديد قائمة الوظائف ببساطة في نص ، في قائمة واحدة مدمجة! وستكون على حق ، ولكن هناك فروق دقيقة.

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

لماذا قمنا بخلط UML و Archimate في نفس الرسم البياني؟ لا تحتاج إلى اتباع الرموز بدقة ؛ ليس عليك اجتياز الامتحانات في الجامعة بهذا ، ولكن التواصل مع الفريق ، الذي تقوم بإعداده كله.

لماذا استخدمنا الخطوط بدلاً من الأسهم لربط العناصر؟ لأنه لا أحد يتذكر كيف تبدو سهام "التعميم" و "التمديد" ، وما هي عليه بشكل عام. كلما قمت برسم أبسط ، زاد فهم الأشخاص للرسم البياني بدون مشاركتك.

النوع الثاني من المخططات التي يمكن أن تقابلها في المهمة الفنية هو مخطط النشاط:



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

التصميم المعماري


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

  • النظام الفرعي لحجز الدرس
  • النظام الفرعي للتدريب على شبكة الإنترنت
  • الفواتير
  • النظام الفرعي لإدارة التسجيل الصوتي

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

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

لكل نظام فرعي ، مطلوب مخطط معماري ، كيفية رسمه بشكل صحيح؟ لا توجد رسوم بيانية مناسبة في UML لهذا ، فلنلق نظرة على Archimate:



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



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

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

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



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

التفاصيل


الرسمان الأخيران مفيدان للغاية (لاحظ القارئ اليقظ بالطبع أنه لم يعد هناك 2-3 أنواع من الرسوم البيانية): مخطط التسلسل (مخطط الفصل) ومخطط الفصل (مخطط الرسم البياني للفئة ، ولكن ليس للفصول على الإطلاق).

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



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

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

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

لكن التطبيق العملي لـ Class Diagram لا يزال قائما - تصميم قاعدة البيانات:



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

لا تحاول رسمه في Visio أو Enterprise Architect أو ما يعادله. لتصميم قاعدة البيانات ، هناك العديد من الأدوات المتخصصة التي تم تصميمها خصيصًا لـ DBMSs معينة ، استخدمها.

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

شكرًا لك على اهتمامك ، كانت هناك شركة منتجات برمجيات معك.

All Articles