بناء نمذجة لبنية نظام البرامج.
للمساعدة في التأكد من أن نظام البرامج أو تطبيق يلبي احتياجات المستخدمين لديك ، يمكنك إنشاء نماذج في Visual Studio Ultimate كجزء من وصف بنية وسلوك الكلي من برنامج النظام أو التطبيق. يمكنك أيضاً استخدام نماذج ، وصف النقوش المستخدمة خلال التصميم. هذه الطرازات يساعدك علي فهم بنية الموجودة و مناقشة التغييرات و توصيل النوايا الخاصة بك بوضوح.
الغرض من نموذج هو تقليل الغموض التي تحدث في وصف باللغة الطبيعية للمساعدة الذي الزملاء تمثيل التصميم ثم تناقش تصميمات بديل. يجب أن يتم استخدام نموذج مع المستندات الأخرى أو المناقشات. وحدها, لا يمثل طراز مواصفات كاملة من البنية.
ملاحظة
خلال هذا الموضوع "النظام" يعني أن البرنامج الذي يتم تطوير. قد يكون مجموعة كبيرة من مكونات البرامج والأجهزة; أو تطبيق واحد; أو أحد مكونات البرامج داخل نظام أكبر.
البنية النظام يمكن أن تقسم إلى ناحيتين:
تصميم عالي-المستوي. هذا يصف المكونات الرئيسية وكيف كانت تتفاعل مع البعض لتلبية متطلبات كل. إذا كان النظام كبيرة لدى كل مكون الخاصة به التصميم عالي المستوى يُظهر كيفية تتألف من مكونات أصغر.
نقش التصميم والاصطلاحات استخدامه خلال التصميمات من المكونات. نمط وصف أسلوب معين لتحقيق هدف للبرمجة. باستخدام نفس النقوش خلال التصميم ، يمكن الفريق الخاص بك تقليل تكلفة إجراء تغييرات وتطوير البرنامج الجديد.
تصميم عالي المستوي.
وصف تصميم عالي المستوى الرئيسية مكونات النظام و كيف كانت تتفاعل مع البعض لتحقيق أهداف التصميم. يتم تضمين الأنشطة في القائمة التالية في تطوير تصميم عالي المستوى على الرغم من أنه ليس بالضرورة تكون في تسلسل معين.
إذا كنت تقوم بتحديث التعليمات البرمجية الموجودة قد تبدأ طريق وصف في المكونات الرئيسية . تأكد من فهم التغييرات إلى متطلبات المستخدم ومن ثم إضافة أو تعديل التفاعلات بين المكونات. إذا كنت تقوم بتطوير نظام جديد ، ابدأ التعرف على الميزات الرئيسية لاحتياجات المستخدمين. يمكنك استكشاف تسلسلات تفاعلات حالات الاستخدام الرئيسي ثم ومن ثم دمج التسلسلات في مكون التصميم.
في كل هذه الحالة، يفضل أن يكون تطوير نشاطات مختلفة في نفس الوقت ، وتطوير التعليمات البرمجية الاختبارات في مرحلة مبكرة. تجنب محاولة لإكمال أحد المجالات هذه قبل بدء تشغيل آخر. بشكل عام، كل من المتطلبات و الخاص بك في فهم أفضل طريقة للتصميم سيتم تغيير النظام أثناء الكتابة ثم اختبار التعليمات البرمجية. لذلك، يجب أن تبدأ عن طريق فهم ترميز ميزات الرئيسي متطلبات والتصميم الخاص بك. قم بملء التفاصيل في تكرارات لاحقة للمشروع.
فهم متطلبات. نقطة البداية أي تصميم يتم فهم قم بإلغاء تحديد احتياجات المستخدمين.
النقوش المعمارية . الاختيارات التي قمت بتحديدها حول التقنيات الأساسية والعناصر المعمارية للنظام.
المكونات والواجهات الخاصة بهم . يمكنك رسم رسومات تخطيطية للمكونات لإظهار الأجزاء الأساسية لنظام ثم إظهار الواجهات من خلالها التفاعل مع بعضها البعض. الواجهات لكل مكون تتضمن كافة الرسائل التي قمت بتحديدها في رسومات تخطيطية للتسلسل.
التفاعلات بين المكونات. كل حالة الاستخدام أو الحدث أو الرسالة الواردة ، يمكنك رسم مخطط تسلسلي التي تُظهر كيفية التفاعل مكونات النظام رئيسي لتحقيق الاستجابة المطلوبة.
طراز البيانات من المكونات و الواجهات. يمكنك رسم الرسومات التخطيطية للفئة يصف المعلومات التي يتم تمريرها بين المكونات و المخزنة داخل المكونات.
فهم متطلبات.
تصميم التطبيق كاملة عالية المستوى الأكثر بفاعلية تطوير مع طراز متطلبات أو وصف احتياجات المستخدمين الأخرى. للحصول على مزيد من المعلومات حول طرازات المتطلبات, راجع بناء متطلبات المستخدم.
إذا كان النظام الذي يتم تطويره هو مكون في نظام أكبر جزء أو كافة المتطلبات الخاصة بك قد تكون مدمجة في الواجهات البرمجي.
يوفر طراز متطلبات هذه الأجزاء الأساسية من المعلومات:
توفير واجهات. الواجهات المتوفرة تسرد الخدمات أو العمليات التي يجب أن توفر نظام أو مكون به للمستخدمين سواء كانت المستخدمين البشرية أو مكونات برامج أخرى.
الواجهات المطلوبة. تسرد واجهة مطلوبة الخدمات أو العمليات التي يمكن استخدامها نظام أو مكون. في بعض الحالات، سيكون بإمكانك تصميم كافة هذه الخدمات كجزء من النظام الخاص بك. في حالات أخرى خاصة إذا كنت تقوم بتصميم مكون يمكن ضم مكونات أخرى في العديد من تكوينات سيتم تعيين الواجهة المطلوبة بواسطة اعتبارات خارجية.
متطلبات جودة الخدمة. الأداء الأمان ، الشدة ، و أهداف أخرى و القيود التي يجب أن يفي بها النظام.
تتم كتابة طراز متطلبات من طريقة العرض من نقطة من النظام الخاص بك المستخدمين، سواء كانت الأشخاص أو مكونات البرامج الأخرى . معرفة أي شيء عن دواخل العمل للنظام الخاص بك . وعلى النقيض، فإن كان الهدف في طراز المعمارية أن تصف العمل الداخلي وإظهار كيف أنها تفي باحتياجات المستخدمين.
الاحتفاظ طرازات المعمارية ومتطلبات منفصلة مفيد لأن فإنه يجعل من السهل مناقشة المتطلبات مع المستخدمين. كما يساعدك إعادة بناء التصميم ثم خذ بعين الاعتبار البديل من ناحية هندسة مع الاحتفاظ المتطلبات دون تغيير.
يمكنك فصل طرازات المعمارية ومتطلبات بطريقتين بديل:
الاحتفاظ بها في الحل نفس ولكن مشاريع مختلفة. سوف تظهر كـ نماذج منفصلة في مستكشف طرازات UML. يمكن أن تعمل أعضاء الفريق مختلفة في نفس الوقت على النماذج. يمكن إنشاء أنواع محددة من تتبع بين النماذج.
وضعها في طراز UML نفس ولكن في حزم مختلفة. هذا يسهّل عملية تتبع الإعتماديات بين الطرازات ، ولكن يمنع أكثر من شخص واحد في وقت العمل في الطراز. بالإضافة إلى ذلك، قد يستغرق طراز وقت أطول للتحميل في Visual Studio. يعتبر هذا الأسلوب وبالتالي يناسب أقل للمشاريع الكبيرة.
يستند مقدار التفاصيل يجب وضع في متطلبات أو طراز المعمارية من المشروع وإعادة حجم التوزيع الفريق. قد انتقل فريق صغير على مشروع قصيرة لم مزيد من رسم تخطيطي فئة من مفاهيم الأعمال وبعض نقوش التصميم ; مشروع كبير موزعة على أكثر من بلد هل تحتاج بشكل ملحوظ أكثر التفاصيل.
النقوش المعمارية.
في تطوير لديك اختر تقنيات الرئيسية والعناصر التي التصميم تعتمد عليها. تتضمن النواحي التي يجب إجراء هذه الخيارات ما يلي:
اختيارات التقنية الأساسية مثل اختيار بين قاعدة بيانات "و" نظام ملفات, ثم اختيار بين تطبيقات الموجودة على شبكة اتصال و عميل الويب وهكذا.
خيارات الإطارات مثل اختيار بين Windows Foundation سير العمل أو Framework وحدة ADO.NET.
تكامل أسلوب الاختيارات ، على سبيل المثال بين ناقل خدمة مؤسسة أو قناة نقطة لنقطة.
هذه الخيارات بشكل متكرر يتم تحديد جودة متطلبات خدمة مثل مقياس ومرونة ثم إجراء قبل تعرف متطلبات مفصلة. في نظام كبير, التكوين من الأجهزة والبرامج بشدة متصلة ببعضها.
التحديدات التي تقوم بإجرائها تؤثر على كيفية استخدام طراز المعمارية وتفسيرها. على سبيل المثال، في نظام يستخدم قاعدة البيانات، اقترانات في مخطط الفئة قد يمثل العلاقات أو المفاتيح الخارجية في قاعدة بيانات ، بينما قد اقترانات يشير الإسنادات الترافقية التي تستخدم XPath في نظام يستند إلى ملفات XML. في نظام موزعة يمكن أن يمثل رسائل في رسم تخطيطي للتسلسل رسائل على سلك; في تطبيق مُضمن يمكن تمثّل استدعاءات دالة.
المكونات والواجهات الخاصة بهم.
توصيات الرئيسية لهذا المقطع هي كما يلي:
إنشاء رسومات تخطيطية للمكونات لإظهار أجزاء رئيسية من النظام.
رسم الإعتماديات بين المكونات أو الواجهات الخاصة بهم لإظهار بنية النظام.
استخدم واجهات على المكونات لإظهار الخدمات التي يوفرها كل مكون أو يتطلب.
يمكنك رسم رسومات تخطيطية منفصل إلغاء تكوين كل في تصميم كبيرة أو تحليله إلى أجزاء أصغر.
يتم توسيع هذه النقاط في باقي هذا القسم.
المكونات
طرق العرض مركزي لنموذج هندسة البنية الرسومات التخطيطية التي تُظهر أجزاء رئيسية من النظام "و" كيف أنها تعتمد على بعضها البعض. للحصول على مزيد من المعلومات حول المكونات التخطيطية، راجع مخططات مكونات UML: المرجع.
قد يحتوي رسم تخطيطي للمكونات نموذجية لنظام كبيرة التي تتضمن مكونات مثل هذه:
عرض تقديمي المكونات التي توفر الوصول إلى المستخدم عادةً قيد التشغيل على مستعرض الويب.
مكونات خدمة ويب . يوفر الاتصال بين الأجهزة العميلة الخوادم.
استخدام وحدات تحكم حالة الأحرف. إجراء المستخدم من خلال الخطوات لكل سيناريو.
الأعمال الأساسية. يحتوي على الفئات التي تستند إلى الفئات في الطراز متطلبات بتنفيذ عمليات المفتاح ويفرض قيود الأعمال.
قاعدة بيانات يقوم بتخزين كائنات العمل.
تسجيل الدخول "و" مكونات معالجة الخطأ.
تبعية بين المكونات
بالإضافة إلى مكونات نفسها يمكنك إظهار التبعيات بينها. سهم تبعية بين المكونات قد تؤثر على العروض تغييرات في تصميم أحد التصميم الأخرى. يحدث هذا عادةً لأن مكون واحد يستخدم خدمات أو الدالات التي يتم توفيرها من قبل مكون آخر أو غير مباشر.
يحتوي بناء المبني جيداً ترتيب مسح للتبعيات, في التي تحققت هاتان الحالاتان:
لا توجد أية حلقات في الرسم البياني للتبعيات.
يمكن ترتيب في طبقات فيه كل التبعية الانتقال من مكوّن في طبقة واحدة إلى مكون في التالي. كافة التبعيات بين الطبقات أي جهازي الانتقال في نفس الاتجاه.
يمكنك إظهار التبعيات مباشرة بين مكونات أو يمكنك إظهار التبعيات بين المطلوبة و توفير واجهات المتصلة للمكونات. باستخدام واجهات يمكنك تعريف العمليات التي تستخدم في كل تبعية. بشكل عام، يتم إظهار التبعيات بين المكونات عند المخططات يتم رسمها أولاً ثم استبدال تبعيات بين الواجهات كإضافة المعلومات. كلا الإصدارين وصف الصحيح من البرنامج ولكن يوفر الإصدار بواجهات المزيد من التفاصيل من إصدار سابق.
إدارة التبعيات الأكثر أهمية بالنسبة إنتاج برامج قابلة للإصلاح. يجب أن تعكس رسومات تخطيطية للمكونات كافة التبعيات في التعليمات البرمجية. إذا التعليمة البرمجية مسبقاً, تأكد من أن كافة التبعيات يتم عرضها في المخططات. إذا كان يتم تطوير التعليمات البرمجية ، تأكد من أن وهو لا يتضمن تبعيات التي لا المخطط في الرسم التخطيطي للمكونات. لمساعدتك في اكتشاف تبعيات في التعليمات البرمجية يمكنك إنشاء طبقة الرسومات التخطيطية. للمساعدة في التأكد من أن يتم استيفاء القيود التبعية المخطط ، يمكنك التحقق من صحة الرمز مقابل طبقة الرسومات التخطيطية. لمزيد من المعلومات، راجع الرسومات التخطيطية الطبقية: المرجع.
الواجهات
عن طريق وضع الواجهات على المكونات الخاصة بك , افصل وتسميتها مجموعات العمليات التي يتم توفيرها من قبل كل مكون رئيسي. على سبيل المثال، قد يكون لديك مكونات في نظام مبيعات المستندة إلى ويب خلال أي من العملاء شراء السلع ، الواجهات خلال التي الموردين تحديث النشرات المصورة الخاصة بهم أو واجهة ثالثة التي من خلالها والتي تتم إدارة النظام.
مكون يمكن أن يكون أي عدد من الواجهات المتوفرة والمطلوبة. توفير الواجهات لإظهار الخدمات ويوفر المكون للمكونات الأخرى لاستخدام. مطلوب إظهار الواجهات الخدمات التي يستخدمها المكون في مكونات أخرى .
في حالة تعريف كليهما توفير الواجهات المطلوبة يساعدك هذا بفصل المكون بوضوح عن باقي التصميم ، بحيث يمكن استخدام هذه الأساليب:
وضع المكون في نظام اختبار الذي يحيط المكونات التي تم محاكاتها بواسطة نظام الاختبار.
تطوير مكون بشكل مستقل عن المكونات الآخري .
إعادة استخدام المكون في سياقات الأخرى بواسطة ازدواج الواجهات الخاصة به إلى مكونات مختلفة.
عندما تريد تحديد قائمة العمليات في واجهة ، يمكنك إنشاء طريقة عرض أخرى للواجهة على رسم تخطيطي فئة UML. للقيام بذلك، حدد موقع الواجهة في مستكشف طرازات UML، واسحبه إلى رسم تخطيطي للفئة. ثم يمكنك إضافة عمليات للواجهة.
عملية في واجهة UML يمكن أن تمثل بالطريقة التي يمكن استدعاء سلوك مكون. قد يمثل طلب خدمة ويب ،فإشارة أو تفاعل من نوع آخر أو استدعاء دالة برنامج عادية.
لتحديد ما هي عمليات إضافة إنشاء رسومات تخطيطية للتسلسل لإظهار كيفية التفاعل المكونات بعضها البعض. أنظر التفاعلات بين المكونات . كل من هذه الرسومات التخطيطية للتسلسل يعرض الإجراءات التي تحدث في مختلف حالات الإستخدام. بهذه الطريقة يمكنك تدريجياً إضافة إلى قائمة العمليات في كل واجهة مكون ، كما استكشاف حالات الاستخدام.
تحليل مكون إلى أجزاء
يمكنك تطبيق الإجراء الموضحة في الأقسام السابقة لكل مكون.
داخل كل مكون يمكنك إظهار المكونات الفرعية الخاصة به كأجزاء. يعتبر جزء ويب بشكل فعال سمة من موقعه الأصل ، وهو نوع الفئة. يحتوي كل جزء الخاصة به والذي من الممكن أن يكون أحد مكونات. يمكنك وضع هذا المكون على رسم تخطيطي وإظهار الأجزاء. لمزيد من المعلومات، راجع مخططات مكونات UML: إرشادات.
من المفيد لتطبيق هذه التقنية للنظام بالكامل. رسم كمكون واحد وإظهار الرئيسية الخاصة به كأجزاء. يساعدك ذلك بوضوح تعريف الواجهات النظام مع العالم الخارجي.
عندما يستخدم التصميم لمكون مكون آخر, لديك بشكل متكرر خيار حول ما إذا كان سيتم تمثل كجزء أو كمكون منفصلة الوصول من خلال يتطلب واجهة.
استخدام أجزاء في الحالات التالية:
تصميم مكون الأصلي يجب دوماً استخدامه نوع المكون جزء. لذلك، يتم تصميم الجزء المتكاملة لتصميم المكون الأصلي.
المكون الأصل لا يحتوي على وجود الخرسانة خاصة بها. على سبيل المثال، قد يكون لديك مكون تصوري تسمى "طبقة العرض التقديمي" الذي يمثل مجموعة من المكونات الحقيقية التي يتم معالجتها طرق العرض وطريقة تفاعل المستخدم.
استخدام مكونات منفصلة الوصول إليها من خلال الواجهات المطلوبة في هذه الحالات:
بدقة مكون يتطلب خلال الواجهات الخاصة به إلى توفير مكونات مختلفة في وقت التشغيل.
يتم التصميم بحيث يتم ذلك سهلاً لاستبدال موفر واحد مع آخر.
استخدام الواجهات المطلوبة أفضل عادةً لاستخدام أجزاء. على الرغم من أن تصميم يمكن أن تستغرق وقتاً أطول ،فالنظام الناتج أكثر مرونة. من السهل أيضاً اختبار المكونات بشكل منفصل. يسمح هذا بالإقتران أقل في خطط التطوير الخاصة بهم.
التفاعلات بين المكونات.
توصيات الرئيسية لهذا المقطع هي كما يلي:
تحديد حالات الاستخدام للنظام الخاص بك.
بالنسبة لكل حالة استخدام رسم رسومات تخطيطية أو أكثر لإظهار كيفية تحقيق مكونات النظام المطلوبة النتيجة عن طريق التعاون مع البعض والمستخدمين الأخرين. عادةً، هذه هي الرسومات التخطيطية تسلسل أو نشاط الرسومات التخطيطية.
استخدم واجهات لتحديد الرسائل المتلقاة من قبل كل مكون.
تصف تأثيرات العمليات في الواجهات.
كرر الإجراء لكل مكون ، يوضح كيفية التفاعل الأجزاء.
على سبيل المثال، في المستندة إلى ويب مبيعات نظام طراز متطلبات قد تعرف شراء العميل مثل حالة استخدام. يمكنك إنشاء مخطط تسلسلي لإظهار تفاعلات لدى العميل مع المكونات الموجودة في الطبقة العرض التقديمي و لإظهار التفاعلات لديهم مع مستودع ومكونات المحاسبة.
تعريف بدء الأحداث
العمل المنجز من قبل معظم أنظمة برامج يمكن بشكل ملائم تقسيم استجابات فإنه يعطي الإدخالات مختلفة أو الأحداث. قد يكون حدث البدء أحد الأحداث التالية:
الإجراء الأول في حالة استخدام. قد تظهر في طراز متطلبات خطوة في حالة استخدام أو إجراء في الرسم التخطيطي. لمزيد من المعلومات، راجع مخطط حالات استخدام UML إرشادات ومخططات أنشطة UML: إرشادات.
رسالة في الواجهة البرمجية. حالة النظام التي يتم تطويره من مكون في نظام أكبر فإنه يجب أن يكون وصفها كعملية في إحدى واجهات المكوّن. أنظر المكونات والواجهات الخاصة بهم .
شرط معين مراقبة من قبل النظام, أو حدث مثل وقت من اليوم.
تصف الحسابات
رسم رسومات تخطيطية للتسلسل لإظهار كيفية أن تستجيب المكونات إلى الحدث الأولي.
رسم على فترة تواجد لكل مكون المثيل الذي يأخذ جزء في تسلسل نموذجية. في بعض الحالات، قد يكون هناك أكثر من مثيل واحد لكل نوع. إذا تم وصفها للنظام بالكامل كمكون واحد ، يجب أن يكون هناك فترة تواجد واحد لكل جزء الذي يحتوي على.
لمزيد من المعلومات، راجع مخططات تسلسل UML: إرشادات.
الرسومات التخطيطية للنشاطات مفيدة أيضاً في بعض الحالات. على سبيل المثال، إذا كان لديك تدفق مستمر البيانات, يمكنك وصف مثل تدفق ما للكائنات. إذا كان المكون الخاص بك يحتوي خوارزمية معقدة, يمكنك وصف مثل تدفق عناصر تحكم. تأكد من أنه يمكنك جعله قم بإلغاء تحديد المكون الذي ينفذ كل إجراء على سبيل المثال وذلك باستخدام التعليقات. لمزيد من المعلومات، راجع مخططات أنشطة UML: إرشادات.
تحديد العمليات
إظهار الرسومات التخطيطية العمليات التي يتم تنفيذها بواسطة كل مكون ، ممثل إما أنها رسائل على رسم تخطيطي للتسلسل أو إجراءات في رسم تخطيطي للأنشطة.
جمع هذه العمليات مع بعضها البعض عن كل مكون. إنشاء "توفير واجهات" على المكون وإضافة العمليات للواجهات. بشكل عام، واجهة منفصلة مستخدمة لكل نوع من العميل. تتم إضافة العمليات بسهولة للواجهات في مستكشف طرازات UML. بنفس الطريقة تجميع العمليات التي تستخدم كل مكون من الآخر ، ووضعها في "واجهات مطلوب" إرفاق المكون.
من المفيد إضافة تعليقات إلى المخططات نشاط أو تسلسل ملاحظة ما تحقيق بعد كل عملية. يمكنك أيضاً كتابة التأثير لكل عملية في به خاصية بعد الشرط المحلي .
طراز البيانات من المكونات و الواجهات.
لتعريف المعلمات ثم إرجاع القيم كل العملية في الواجهات المكون. حيث العمليات تمثل إستدعاءات مثل طلبات خدمات ويب والمعلمات هي تلك أجزاء المعلومات التي يتم إرسالها كجزء من الطلب. حيث يتم إرجاع القيم العديد من عملية ،يمكنك استخدام المعلمات مع مجموعة الخصائص اتجاه معين إلي مخرج .
كل قيمة المعلمة وإرجاع يحتوي على نوع. يمكنك تعريف هذه الأنواع باستخدام رسومات تخطيطية فئة UML. لم يكن لديك لتمثل تفصيل تطبيق في الرسومات التخطيطية هذه. على سبيل المثال، إذا تم تصف البيانات التي تم إرسالها كـ XML ، يمكنك استخدام اقتران لتمثل أي نوع من إسناد ترافقي بين عقد XML و استخدام فئات لتمثل العقد.
استخدام تعليقات لتصف قيود الأعمال على اقترانات والسمات. على سبيل المثال، إذا كان يجب أن تأتي كافة العناصر الموجودة في ترتيب العملاء من مورد نفس "، يمكنك وصف هذا حسب المرجع إلى اقترانات بين عناصر ترتيب العناصر على كتالوج المنتج وبين العنصر الكتالوج و المورد الخاصة به.
نقوش التصميم
نقش تصميم مخطط تفصيلي كيف تقوم بتصميم أوجه معينة البرامج خاصةً تلك تكرر في أجزاء مختلفة من النظام. خلال تستخدم أسلوب موحد عبر المشروع, يمكنك تقليل التكلفة المشروع للتأكد من تناسق في واجهة المستخدم و تقليل تكلفة فهم وتغيير التعليمات البرمجية.
بعض نقوش التصميمات العامة مثل الملاحظة المعروفة و للتطبيق على نطاق واسع. بالإضافة إلى ذلك، هناك أنماط قابلة للتطبيق فقط للمشروع الخاص بك. على سبيل المثال، في نظام مبيعات ويب سيكون هناك عدة عمليات في التعليمات البرمجية حيث إجراء تغييرات على أحد أوامر العملاء. للتأكد من أنه يتم عرض حالة الترتيب بدقة في كل مرحلة يجب أن تتبع كافة هذه العمليات بروتوكول معين لتحديث قاعدة البيانات.
جزء من العمل هندسة برنامج لتحديد ما يجب أن يكون النقوش ويعرّف عبر التصميم. ويرجع ذلك عادة الجارية مهمة، النقوش الجديدة والتحسينات للنقوش الموجودة التي سيتم اكتشافها أثناء تقدم العمل في المشروع. يفضل أن يكون تنظيم خطة تطوير بحيث التمرين كل من النقوش تصميم رئيسي في مرحلة مبكرة.
يمكن أن يكون مدمج النقوش تصميم معظم جزئياً في رمز إطار العمل. يمكن تقليل جزء النقش إلى طلب المطور استخدام بفئات خاصة أو مكونات مثل طبقة الوصول إلى قاعدة بيانات الذي يضمن معالجة قاعدة البيانات بشكل صحيح.
نقوش التصميم في مستند ويتضمن عادةً الأجزاء التالية:
الاسم.
وصف السياق الذي كان قابلاً للتطبيق. ما هي المعايير يجب إنشاء مطور تطبيق هذا النقش ؟
شرح مختصر لحل المشكلة.
طراز أجزاء رئيسية وعلاقاتها. قد تكون هذه الفئات "أو" مكونات "و" واجهات مع اقترانات وتبعيات التي بينها. العناصر تنقسم عادةً إلى فئتين:
العناصر التي يجب إجراء نسخ متماثل المطور في كل جزء من التعليمات البرمجية حيث يتم استخدام النقش. يمكنك استخدام أنواع قالب لتصفها. لمزيد من المعلومات، راجع مخطط حالات استخدام UML المرجع.
العناصر تصف فئات إطار العمل التي يجب على المطور استخدامها.
طراز التفاعلات بين الأجزاء باستخدام رسومات تخطيطية تسلسل أو نشاط.
اصطلاحات التسمية
وصف كيفية النقش حل المشكلة.
وصف الاختلافات قد يمكنك للمطورين إقرارها.
راجع أيضًا:
المبادئ
كيفية القيام بما يلي: تحرير مخططات و طراز UML