أرابيكا

بناء البرمجيات

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

أسس بناء البرمجيات

تقليل التعقيد

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

توقع التغيير

يساعد توقع التغيير مهندسي البرمجيات على بناء برمجيات قابلة للتوسيع، ما يعني أنهم يستطيعون تحسين المنتج البرمجي دون تعطيل البنية الأساسية. أظهرت الأبحاث على مدى 25 عامًا أن تكلفة إعادة العمل قد تزيد بمقدار 10 أضعاف إلى 100 ضعف (من 5 إلى 10 أضعاف للمشاريع الأصغر) عن تكلفة الحصول على المتطلبات الصحيحة في المرة الأولى. ولأن 25% من المتطلبات تتغير أثناء عملية تطوير مشروع متوسط، فإن الحاجة إلى تقليل تكاليف إعادة العمل توضح الحاجة إلى توقع التغيير.[3]

البناء للتحقق

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

إعادة الاستخدام

يمكن أن تتيح إعادة الاستخدام المنتظمة تحسينات كبيرة في إنتاجية البرمجيات وجودتها وتكلفتها. لإعادة الاستخدام جانبين مترابطين بشكل وثيق:[2]

  • البناء لإعادة الاستخدام: إنشاء أصول برمجية قابلة لإعادة الاستخدام.
  • البناء مع إعادة الاستخدام: إعادة استخدام الأصول البرمجية في بناء حل جديد.

المعايير في البناء

تشمل المعايير، سواء كانت خارجية (أنشأتها المنظمات الدولية)، أو داخلية (أنشئت على مستوى الشركة)، والتي تؤثر مباشرة على مسائل البناء، ما يلي:

إدارة البناء

نموذج البناء

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

تخطيط البناء

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

قياس البناء

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

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

يعتمد بناء البرمجيات على العديد من الاعتبارات العملية:

تصميم البناء

يجب إجراء بعض تعديلات التصميم أثناء بناء البرنامج على نطاق صغير أو كبير لتوضيح تفاصيل تصميم البرمجيات، لحصر الثغرات غير المتوقعة في تصميم البرمجيات.[4]

وجد الباحثون أن تقليل عدد المخارج هو أحد خصائص التصميم المفيدة. وأثبت أن إخفاء المعلومات هو أسلوب تصميم مفيد في البرامج الكبيرة لأن من السهل تعديلها بمعدل 4 أضعاف.[5]

لغة البناء

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

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

وجد أن المبرمجون العاملون بلغة استخدموها لمدة ثلاث سنوات أو أكثر هم أكثر إنتاجية بنحو 30% من المبرمجين الذين لديهم نفس الخبرة ولكنهم جدد في استخدام لغة برمجة ما. تحقق لغات البرمجة عالية المستوى مثل سي++، وجافا، وسمول توك، وفيجوال بيزك، إنتاجية وموثوقية وبساطة وشمولية أفضل بـ5 إلى 15 مرة من اللغات منخفضة المستوى مثل لغة أسيمبلي ولغة سي. ثبت أن التعليمات البرمجية تنفذ بسطور أقل في اللغات عالية المستوى مقارنة باللغات ذات المستوى الأدنى.[7]

الترميز

تطبق الاعتبارات التالية على عملية ترميز بناء البرمجيات:[8]

  • تقنيات لبناء كود مصدري مفهوم، تشمل تسمية وتخطيط الكود المصدري. أظهرت إحدى الدراسات أن الجهد المطلوب لتصحيح أخطاء البرنامج يقل إلى أدنى حد عندما تتراوح أسماء المتغيرات بين 10 و16 محرف. [9]
  • استخدام الصفوف والأنواع المعددة والمتغيرات والثوابت المسماة وكيانات مماثلة أخرى:
  • أظهرت دراسة أجرتها ناسا أن صياغة الكود باستخدام أصناف محللة بشكل جيد يمكن أن يضاعف إمكانية إعادة استخدام الكود مقارنة بالكود المطور باستخدام التصميم الوظيفي.[10][11]
  • أظهرت إحدى التجارب أن التصاميم التي تصل إلى المصفوفات بالتتابع، وليس بشكل عشوائي، تنتج عددًا أقل من المتغيرات ومراجع المتغيرات.[12]
  • استخدام بنى التحكم:
  • وجدت إحدى التجارب أن الحلقات المنتهية (بالإنجليزية: loops-with-exit)‏ مفهومة أكثر من الحلقات الأخرى.[13]
  • في ما يتعلق بمستوى تداخل الحلقات والجمل الشرطية، أظهرت الدراسات أن المبرمجين يجدون صعوبة في فهم أكثر من ثلاثة مستويات متداخلة.[13][14]
  • معالجة حالات الخطأ -كل من الأخطاء المتوقعة والاستثناءات (إدخال بيانات سيئة مثلًا)
  • منع خروقات الأمان على مستوى الكود (تجاوز سعة المخزن المؤقت أو تجاوز سعة فهرس المصفوفة مثلًا)

انظر أيضًا

المراجع

  1. ^ أ ب ت ث SWEBOK "Chapter 4: Software Construction". Guide to the Software Engineering Body of Knowledge. IEEE Computer Society. 2004. ص. 4–1 – 4–5. ISBN:0-7695-2330-7. مؤرشف من الأصل في 2014-07-14. {{استشهاد بكتاب}}: الوسيط غير المعروف |المحررين= تم تجاهله (مساعدة) ويحتوي الاستشهاد على وسيط غير معروف وفارغ: |بواسطة= (مساعدة)
  2. ^ أ ب ت SWEBOK 2014، صفحة 3-3.
  3. ^ McConnell 2004، Chapter 3.
  4. ^ SWEBOK 2014، صفحة 3-5.
  5. ^ McConnell 2004، Chapter 5.
  6. ^ SWEBOK 2014، صفحة 3-5 - 3-6.
  7. ^ McConnell 2004، Chapter 4.
  8. ^ SWEBOK 2014، صفحة 3-6.
  9. ^ McConnell 2004، Chapter 11.
  10. ^ McConnell 2004، Chapter 6.
  11. ^ McConnell 2004، Chapter 7.
  12. ^ McConnell 2004، Chapter 12.
  13. ^ أ ب McConnell 2004، Chapter 16.
  14. ^ أ ب McConnell 2004، Chapter 19.
مجلوبة من «https://3rabica.org/index.php?title=بناء_البرمجيات&oldid=3166916»