استخدام الطرازات داخل عملية التطوير

في Visual Studio Ultimate ، يمكنك استخدام طراز للمساعدة في فهم و تغيير نظام أو تطبيق أو مكوّن. يمكن لطراز أن يساعدك في تمثيل العالم الذي يعمل فيه النظام, و توضيح احتياجات المستخدمين, و تعريف هندسة النظام, و تحليل التعليمات البرمجية , و التأكد من أن التعليمات البرمجية تلبي المتطلبات.

كيفية استخدام الطرازات

يمكن للطرازات المساعدة بعدة طرق:

• رسم مخططات طراز يساعدك في توضيح المفاهيم المتضمنة في المتطلبات, و البنية ، و التصميم عالي المستوى.

• العمل باستخدام الطرازات يمكن أن يساعدك على كشف حالات عدم التناسق في المتطلبات.

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

• يمكنك أحياناً استخدام الطرازات لإنشاء تعليمات برمجية أو عناصر ملموسة أخرى أخرى مثل مخططات قاعدة البيانات أو المستندات. على سبيل المثال، مكونات الطراز لـ Visual Studio Ultimate يتم إنشاؤها من الطراز.

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

استخدام الطرازات لتقليل الغموض

لغة الطراز تكون أقل غموضا من اللغة الطبيعية, و مصممة للتعبير عن الأفكار المطلوبة عادةً أثناء تطوير البرامج.

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

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

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

استخدام الطرازات مع العناصر الملموسة الأخرى

الطراز بمفرده ليس مواصفات متطلبات أو هندسة. هو أداة لتمثيل بعض أوجه هذه الأشياء بشكل أكثر وضوحاً, ولكن ليس كل المفاهيم المطلوبة أثناء تصميم البرنامج يمكن وصفها. لذلك يجب استخدام النماذج مع وسائل الاتصال الأخرى , مثل صفحات أو فقرات OneNote, أو مستندات Microsoft Office , أو عناصر العمل في Team Foundation, أو الملاحظات اللاصقة على جدار غرفة المشروع. بعيدا عن آخر عنصر, كافة أنواع الكائنات هذه يمكن ربطها مع أجزاء عناصر من الطراز.

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

• قصص المستخدم. قصة المستخدم هي وصف مختصر, يتم مناقشته مع المستخدمين والمالكين ، لوجه من سلوك النظام الذي سيتم تسليم في أحد تكرارات المشروع. قصة المستخدم النموذجية تبدأ بـ "العميل سيتمكن من …." قصة المستخدم قد تقدّم مجموعة من حالات الاستخدام , أو يمكنها تعريف ملحقات لحالات الاستخدام التي تم تطويرها مسبقاً. تعريف أو مدّ حالات الاستخدام يساعد على جعل قصة المستخدم أوضح.

• طلبات التغيير. طلب التغيير في مشروع أكثر رسمية يكون مشابهاً جداً لقصة مستخدم في مشروع سريع (agile). الأسلوب السريع (agile) يعامل كافة المتطلبات على أنها تغييرات في ما تم تطويره في التكرارات السابقة.

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

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

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

• قواعد العمل. العديد من قواعد العمل يمكن التعبير عنها كقيود ثابتة على الاقترانات والسمات في طراز الفئات للمتطلبات ، و كقيود على مخططات التسلسل.

• التصميم عالي المستوى. يوضح الأجزاء الرئيسية و كيفية تعاملها معاً. مخططات الواجهة و التسلسل و المكونات تعتبر جزءا رئيسيا من التصميم عالي-المستوى.

• أنماط التصميم. تصف قواعد التصميم المشتركة عبر الأجزاء المختلفة من النظام.

• مواصفات الاختبار. البرامج النصية للاختبار و التصاميم لاختبار التعليمات البرمجية يمكنها استخدام مخططات التسلسل و الأنشطة بشكل جيد لوصف تسلسلات خطوات الاختبار. اختبارات النظام يجب أن يتم التعبير عنها بمصطلحات من طراز المتطلبات بحيث يكون من السهل تغييرها عند تغيير المتطلبات.

• خطة المشروع. خطة المشروع أو "التراكم" تعرّف متى سيتم تسليم كل ميزة. يمكنك تعريف كل ميزة بواسطة توضيح حالات الاستخدام و قواعد الأعمال التي تنفّذها أو توسّعها. يمكنك إما الإشارة لحالات الاستخدام وقواعد الأعمال بشكل مباشر في الخطة , أو يمكن تعريف مجموعة من الميزات في مستند منفصل , و استخدم عناوين الميزات في الخطة.

استخدام الطرازات في تخطيط التكرار

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

قد تجد الاقتراحات التالية مفيدة للمساعدة في تحقيق فوائد الطراز في مشروع تكراري.

زيادة حدة التركيز مع اقتراب كل تكرار

مع اقتراب كل تكرار , استخدم طرازات للمساعدة في تحديد ما سيتم تسليمه عند نهاية التكرار.

• لا تقم بعمل نموذج لكل شيء بالتفصيل في التكرارات المبكرة . في التكرار الأول, أنشئ مخطط فئة للعناصر الرئيسية في قاموس مصطلحات المستخدم, و ارسم مخططا لحالات الاستخدام الرئيسية , و ارسم مخططا للمكونات الرئيسية. لا تصف أي من هذه بالتفصيل, لأن التفاصيل ستتغير فيما بعد في المشروع. استخدام المصطلحات المعرفة في هذا الطراز لإنشاء قائمة بالميزات أو قصص المستخدم الرئيسية. عيّن الميزات للتكرارات لموازنة حمل العمل المقدر خلال المشروع. سيتم تغيير هذه التعيينات لاحقاً في المشروع.

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

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

• هدف جلسة العمل هو موافقة الجميع على ما سوف يتم بنهاية التكرار التالي. استخدم الطرازات كأحد الأدوات للمساعدة في توضيح المتطلبات. ناتج جلسة العمل هو تراكم تكرار: أي, قائمة من مهام التطوير في Team Foundation و مجموعات اختبار فيMicrosoft Test Manager.

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

• المساهمون الغير تقنيين لا يكون لديهم عادةً أية مشاكل في فهم مخططات UML , مع بعض الإرشادات من قبلك.

ربط الطراز بعناصر العمل

بعد جلسة عمل المتطلبات , فم بزيادة التفاصيل في طراز المتطلبات , واربط الطراز بمهام التطوير. يمكنك القيام بذلك عن طريق ربط عناصر العمل في Team Foundation بالعناصر في الطراز. للتعرف على كيفية فعل ذلك، راجع كيفية القيام بما يلي: ربط عناصر العمل بالطراز.

يمكنك ربط أي عنصر بعناصر العمل , ولكن العناصر الأكثر فائدة كما يلي:

• حالات الاستخدام. يمكنك ربط حالة استخدام بمهام التطوير التي سوف تطبقها.

• ملحقات حالة الاستخدام. إذا كان سوف يتم تطبيق وجه واحد فقط من حالة الاستخدام في تكرار, يمكنك فصله في حالة استخدام أساسية مع ملحق واحد أو أكثر. الملحقات هي حالات استخدام مرتبطة بالحالة الأساسية مع علاقة «توسيع». للحصول على مزيد من المعلومات ملحق حالة الاستخدام, راجع مخطط حالات استخدام UML المرجع.

• تعليقات تصف قواعد العمل أو متطلبات جودة الخدمة. لمزيد من المعلومات، راجع بناء متطلبات المستخدم.

ربط طراز باختبارات

استخدم طراز المتطلبات لإرشاد تصميم اختبارات القبول. أنشئ هذه الاختبارات بشكل متزامن مع عمل التطوير.

لتعلّم المزيد من المعلومات حول هذه التقنية, راجع تطوير اختبارات من طراز.

تقدير العمل المتبقي

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

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

مستويات التجريد

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

يمكن أن يتم عرض الطراز عبر عدة أنواع من المخططات. للحصول على معلومات حول الطرازات و المخططات, راجع تطوير النماذج لتصميم البرامج.

أنواع مختلفة من المخططات تفيد في وصف التصميم على مستويات مختلفة من التجريد. العديد من أنواع المخططات تكون مفيدة في أكثر من مستوى. يُظهر هذا الجدول كيفية استخدام كل نوع من المخططات.

راجع أيضًا:

المبادئ

تطوير النماذج لتصميم البرامج

بناء متطلبات المستخدم

بناء نمذجة لبنية نظام البرامج.

تطوير اختبارات من طراز