تصميم البرمجيات

الموسوعة الحرة

تصميم البرمجيات هو عملية تصور كيفية عمل نظام برمجي قبل تنفيذه أو تعديله. [ 1 ] يشير تصميم البرمجيات أيضًا إلى النتيجة المباشرة لعملية التصميم - مفاهيم كيفية عمل البرنامج والتي قد تكون موثقة رسميًا أو قد يتم الحفاظ عليها بشكل أقل رسمية، بما في ذلك من خلال التقاليد الشفوية .

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

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

جزء من العملية الشاملة

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

في بعض الأحيان، يتم إنشاء محاكاة أو نموذج أولي لنمذجة النظام في محاولة لتحديد تصميم صالح وجيد.

الكود كتصميم

من بين نقاط الالتباس الشائعة فيما يتعلق بمصطلح "التصميم" في البرمجيات، أن هذه العملية تُطبّق على مستويات تجريد متعددة ، مثل بنية البرمجيات عالية المستوى والمكونات والوظائف والخوارزميات منخفضة المستوى . قد تكون عملية التصميم رسمية نسبيًا على مستويات التجريد العالية، ولكن على المستويات الأدنى، تكون عملية التصميم أقل رسمية في أغلب الأحيان، حيث قد يكون الناتج الوحيد للتصميم هو الكود البرمجي وحده. وبناءً على ذلك، فإن تصميم البرمجيات يُشير إلى تصميم التصميم نفسه. وقد أشار إدسكار دبليو ديكسترا إلى هذا التدرج في المستويات الدلالية باعتباره "الجديد الجذري" في برمجة الحاسوب، [ 4 ] واستخدم دونالد كنوث تجربته في كتابة لغة TeX لوصف عبثية محاولة تصميم برنامج قبل تنفيذه.

كان مشروع TEX سيُمنى بفشل ذريع لو أنني اكتفيت بتحديد مواصفاته دون المشاركة الكاملة في تنفيذه الأولي. فقد قادتني عملية التنفيذ باستمرار إلى أسئلة غير متوقعة وإلى رؤى جديدة حول كيفية تحسين المواصفات الأصلية. [ 5 ]

القطع الأثرية

مثال على مخطط انسيابي للبرمجيات

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

التصميم التكراري

تتعامل أنظمة البرمجيات بطبيعتها مع حالات عدم اليقين، ويمكن أن يؤثر حجم مكونات البرمجيات بشكل كبير على نتائج النظام، إيجابًا وسلبًا. يقترح نيل فورد ومارك ريتشاردز منهجًا تكراريًا لمعالجة تحدي تحديد المكونات وتحديد حجمها الأمثل. تركز هذه الطريقة على التحسين المستمر مع تطور فهم الفرق لسلوك النظام ومتطلباته بشكل أدق. [ 6 ]

يتضمن هذا النهج عادةً دورة تتكون من عدة مراحل: [ 6 ]

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

تُشكل هذه الدورة إطاراً عاماً ويمكن تكييفها مع مجالات مختلفة.

مبادئ التصميم

تُمكّن مبادئ التصميم مهندس البرمجيات من اجتياز عملية التصميم بسلاسة. وقد اقترح ديفيس [ 7 ] مبادئ تم تطويرها وتحسينها بمرور الوقت، وهي كالتالي:

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

مفاهيم التصميم

تُزوّد ​​مفاهيم التصميم المصمم بأساسٍ يُمكن من خلاله تطبيق أساليب أكثر تطوراً. وتشمل مفاهيم التصميم ما يلي:

التجريد
تقليل المحتوى المعلوماتي لمفهوم أو ظاهرة قابلة للملاحظة، عادةً للاحتفاظ فقط بالمعلومات ذات الصلة لغرض معين. وهو فعل تمثيل السمات الأساسية دون تضمين التفاصيل الخلفية أو التفسيرات.
بنيان
تُعنى بنية البرمجيات الجيدة بالهيكل العام للبرنامج وكيفية مساهمة هذا الهيكل في تحقيق التكامل المفاهيمي للنظام. ويؤدي تصميم البرمجيات الجيد إلى عائد استثمار مجزٍ فيما يتعلق بالنتائج المرجوة للمشروع، كالأداء والجودة والالتزام بالجدول الزمني والتكلفة.
التسلسل الهرمي للتحكم
هيكل البرنامج الذي يمثل تنظيم مكون البرنامج ويتضمن تسلسلًا هرميًا للتحكم.
بنية البيانات
تمثيل العلاقة المنطقية بين عناصر البيانات.
نمط التصميم
قد يحدد المصمم جانبًا تصميميًا للنظام سبق حله. ويمكن أن يؤدي إعادة استخدام هذه الأنماط إلى زيادة سرعة تطوير البرمجيات. [ 8 ]
إخفاء المعلومات
ينبغي تحديد وتصميم الوحدات بحيث تكون المعلومات الموجودة داخل الوحدة غير قابلة للوصول إليها من قبل الوحدات الأخرى التي لا تحتاج إلى مثل هذه المعلومات.
نمطية التصميم
تقسيم الحل إلى أجزاء (وحدات).
التحسين
عملية التوسع. يتم تطوير التسلسل الهرمي من خلال تفكيك عبارة وظيفية كلية تدريجيًا حتى الوصول إلى عبارات لغة البرمجة. في كل خطوة، يتم تفكيك تعليمة واحدة أو أكثر من تعليمات البرنامج إلى تعليمات أكثر تفصيلًا. التجريد والتحسين مفهومان متكاملان.
إجراءات البرمجيات
يركز على معالجة كل وحدة على حدة.
التقسيم الهيكلي
يمكن تقسيم بنية البرنامج أفقيًا وعموديًا. تحدد التقسيمات الأفقية فروعًا منفصلة من التسلسل الهرمي المعياري لكل وظيفة رئيسية في البرنامج. أما التقسيم العمودي فيشير إلى ضرورة توزيع التحكم والعمل من أعلى إلى أسفل في بنية البرنامج.

يذكر غرادي بوتش التجريد والتغليف والنمطية والتسلسل الهرمي كمبادئ أساسية لتصميم البرمجيات. [ 9 ] ويشير مصطلح " مبادئ التسلسل الهرمي والتجريد والنمطية والتغليف " (PHAME) إلى هذه المبادئ. [ 10 ]

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

هناك جوانب عديدة يجب مراعاتها عند تصميم البرمجيات. وينبغي أن تعكس أهمية كل جانب منها الأهداف والتوقعات التي تُصمم البرمجيات من أجلها. ومن أبرز هذه الجوانب:

التوافق
يستطيع البرنامج العمل مع منتجات أخرى مصممة للتوافق معها. على سبيل المثال، قد يكون البرنامج متوافقًا مع الإصدارات السابقة منه.
قابلية التوسعة
يمكن إضافة قدرات جديدة إلى البرنامج دون إجراء تغييرات كبيرة على البنية الأساسية.
تحمل الأعطال
البرنامج مقاوم لفشل المكونات وقادر على التعافي منه.
قابلية الصيانة
مقياس لمدى سهولة إصلاح الأخطاء أو إجراء تغييرات على الوظائف. يمكن أن تكون سهولة الصيانة العالية نتاجًا للنمطية وقابلية التوسع.
نمطية التصميم
يتألف البرنامج الناتج من مكونات مستقلة ومحددة جيدًا، مما يُحسّن من سهولة صيانته. ويمكن بعد ذلك تنفيذ هذه المكونات واختبارها بشكل منفصل قبل دمجها لتشكيل نظام برمجي متكامل. وهذا يُتيح تقسيم العمل في مشروع تطوير البرمجيات.
التكاليف العامة
كيف يؤثر استهلاك الموارد اللازمة للتكاليف العامة على الموارد اللازمة لتحقيق متطلبات النظام.
أداء
يقوم البرنامج بتنفيذ مهامه في إطار زمني مقبول للمستخدم، ولا يتطلب الكثير من الذاكرة.
سهولة الحمل
ينبغي أن يكون البرنامج قابلاً للاستخدام في عدد من الظروف والبيئات المختلفة.
مصداقية
يستطيع البرنامج أداء وظيفة مطلوبة في ظل ظروف محددة لفترة زمنية معينة.
إمكانية إعادة الاستخدام
القدرة على استخدام بعض أو كل جوانب البرامج الموجودة في مشاريع أخرى مع تعديلات طفيفة أو معدومة.
المتانة
يستطيع البرنامج العمل تحت الضغط أو تحمل المدخلات غير المتوقعة أو غير الصحيحة. على سبيل المثال، يمكن تصميمه بحيث يكون مرنًا في ظروف نقص الذاكرة.
قابلية التوسع
يتكيف البرنامج بشكل جيد مع زيادة البيانات أو الميزات المضافة أو عدد المستخدمين. ووفقًا لمارك بروكر: "يكون النظام قابلاً للتوسع في النطاق الذي تكون فيه التكلفة الحدية لعبء العمل الإضافي ثابتة تقريبًا". تتوافق تقنيات الحوسبة بلا خوادم مع هذا التعريف، ولكن يجب مراعاة التكلفة الإجمالية للملكية وليس فقط تكلفة البنية التحتية. [ 11 ]
حماية
البرنامج قادر على الصمود ومقاومة الأعمال والتأثيرات العدائية.
سهولة الاستخدام
يجب أن تكون واجهة المستخدم الخاصة بالبرنامج سهلة الاستخدام للمستخدم/الجمهور المستهدف. يجب اختيار القيم الافتراضية للمعلمات بحيث تكون مناسبة لأغلبية المستخدمين. [ 12 ]

لغة النمذجة

يمكن استخدام لغة النمذجة للتعبير عن المعلومات أو المعرفة أو الأنظمة في بنية محددة بمجموعة متسقة من القواعد. تُستخدم هذه القواعد لتفسير المكونات داخل البنية. قد تكون لغة النمذجة رسومية أو نصية. من أمثلة لغات النمذجة الرسومية لتصميم البرمجيات:

لغة وصف الهندسة المعمارية (ADL)
لغة تستخدم لوصف وتمثيل بنية البرمجيات لنظام برمجي .
تدوين نمذجة العمليات التجارية (BPMN)
مثال على لغة نمذجة العمليات .
إكسبريس و إكسبريس-جي (ISO 10303-11)
لغة نمذجة بيانات عامة الأغراض ذات معيار دولي .
لغة نمذجة المؤسسات الموسعة (EEML)
يُستخدم عادةً لنمذجة عمليات الأعمال عبر عدد من الطبقات.
مخطط انسيابي
تمثيلات تخطيطية للخوارزميات أو العمليات الأخرى المتدرجة.
مفاهيم النمذجة الأساسية (FMC)
لغة نمذجة للأنظمة كثيفة البرمجيات.
IDE
عائلة من لغات النمذجة، أبرزها IDEF0 للنمذجة الوظيفية، و IDEF1X لنمذجة المعلومات، و IDEF5 لنمذجة الأنطولوجيات .
برمجة جاكسون الهيكلية (JSP)
طريقة للبرمجة الهيكلية تعتمد على التوافق بين بنية تدفق البيانات وبنية البرنامج.
ليبوس 3
لغة وصف التصميم المرئي الموجهة للكائنات ولغة المواصفات الرسمية المناسبة بشكل أساسي لنمذجة البرامج الكبيرة الموجهة للكائنات ( Java و C++ و C# ) وأنماط التصميم .
مثال على مخطط مكونات UML
لغة النمذجة الموحدة (UML)
لغة نمذجة عامة لوصف البرمجيات من الناحيتين الهيكلية والسلوكية. تتميز برموزها الرسومية وتسمح بتوسيعها باستخدام ملف تعريف (UML) .
سبيكة (لغة المواصفات)
لغة مواصفات عامة الأغراض للتعبير عن القيود الهيكلية المعقدة والسلوك في نظام برمجي. وهي توفر لغة موجزة تستند إلى منطق العلاقات من الدرجة الأولى.
لغة نمذجة الأنظمة (SysML)
لغة نمذجة عامة الأغراض لهندسة النظم.
إطار نمذجة موجه نحو الخدمة (SOMF) [ 13 ]

انظر أيضاً

مراجع

  1. ↑ رالف، ب. وواند، ي. (2009). اقتراح لتعريف رسمي لمفهوم التصميم. في: ليتينين، ك.، لوكوبولوس، ب.، ميلوبولوس، ج.، وروبنسون، و. (محررون)، ورشة عمل متطلبات التصميم (LNBIP 14)، ص 103-136. سبرينغر-فيرلاغ، ص 109. doi : 10.1007/978-3-540-92966-6_6 .
  2. ↑ فريمان، بيتر؛ ديفيد هارت (2004). "علم تصميم الأنظمة كثيفة البرمجيات". اتصالات رابطة مكائن ​​الحوسبة . 47 (8): 19-21 [20]. doi : 10.1145/1012037.1012054 . S2CID 14331332 . 
  3. ↑ رالف، ب.، وواند، ي. اقتراح لتعريف رسمي لمفهوم التصميم. في: ليتينين، ك.، ولوكوبولوس، ب.، وميلوبولوس، ج.، وروبنسون، و. (محررون)، هندسة متطلبات التصميم: منظور عشر سنوات: سبرينغر-فيرلاغ، 2009، ص 103-136
  4. ↑ ديكسترا، إي دبليو (1988). "حول قسوة تدريس علوم الحاسوب فعلياً" . تم الاسترجاع في 10 يناير 2014 .
  5. ↑ كنوت، دونالد إي. (1989). "ملاحظات حول أخطاء TeX" (PDF) .
  6. 1 2 أساسيات هندسة البرمجيات: منهج هندسي . دار نشر أورايلي ميديا. 2020. ISBN 978-1492043454.
  7. ↑ ديفيس، أ: "201 مبدأ لتطوير البرمجيات"، ماكجرو هيل، 1995.
  8. ↑ جوديث بيشوب. "أنماط تصميم C# 3.0: استخدم قوة C# 3.0 لحل مشاكل واقعية" . كتب C# من O'Reilly Media . تم الاطلاع عليه بتاريخ 15 مايو 2012. إذا كنت ترغب في تسريع تطوير تطبيقات .NET الخاصة بك، فأنت جاهز لأنماط تصميم C# - وهي طرق أنيقة ومقبولة ومثبتة لمعالجة مشاكل البرمجة الشائعة.
  9. ↑ بوش، جرادي؛ وآخرون (2004). التحليل والتصميم الموجه للكائنات مع التطبيقات ( الطبعة الثالثة). ماساتشوستس، الولايات المتحدة الأمريكية: أديسون ويسلي. ISBN   0-201-89551-Xتم الاطلاع عليه بتاريخ 30 يناير 2015 .
  10. ↑ سوريانارايانا، جيريش (نوفمبر 2014). إعادة هيكلة البرمجيات لمعالجة عيوب التصميم . مورغان كوفمان. ص 258. ISBN  978-0128013977.
  11. ↑ بناء تطبيقات بدون خادم باستخدام Knative . دار نشر O'Reilly Media. رقم ISBN 9781098142049.
  12. ↑ كارول، جون، محرر. (1995). التصميم القائم على السيناريوهات: تصور العمل والتكنولوجيا في تطوير الأنظمة . نيويورك: جون وايلي وأولاده. ISBN 0471076597.
  13. ↑ بيل، مايكل (2008). "مقدمة في نمذجة الخدمات الموجهة". نمذجة الخدمات الموجهة: تحليل الخدمات، والتصميم، والهندسة المعمارية . وايلي وأولاده. ISBN 978-0-470-14111-3.

^ روجر س. بريسمان (2001). هندسة البرمجيات: منهج عملي . ماكجرو هيل. ISBN 0-07-365578-3.