قابلية التوسعة

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

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

تصميم قابل للتوسيع

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

أهمية

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

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

تصنيف آليات التمدد

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

صندوق أبيض

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

صندوق مفتوح

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

صندوق زجاجي

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

صندوق أسود

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

غراي بوكس

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

قابلية التوسع مقابل قابلية إعادة الاستخدام

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

حماية

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

تُعدّ واجهة البوابة العامة (CGI ) إحدى الوسائل الرئيسية التي توفر من خلالها خوادم الويب إمكانية التوسع. ويرى البعض أن نصوص CGI البرمجية تُشكّل "ثغرة أمنية هائلة". [ 9 ]

انظر أيضاً

مراجع

  1. يوهانسون، نيكلاس، وأنطون لوفغرين. التصميم من أجل قابلية التوسع: دراسة بحثية تطبيقية حول تعظيم قابلية التوسع باستخدام مبادئ التصميم. بدون مكان نشر: بدون ناشر، بدون تاريخ. قسم تكنولوجيا المعلومات التطبيقية، جامعة غوتنبرغ، 29 مايو 2009. موقع إلكتروني. 26 أبريل 2014. < https://gupea.ub.gu.se/bitstream/2077/20561/1/gupea_2077_20561_1.pdf >.
  2. راوس، مارغريت. "قابل للتوسيع". SearchSAO. بدون ناشر، مارس 2007. موقع إلكتروني. 27 أبريل 2014. < http://searchsoa.techtarget.com/definition/extensible مؤرشف في 6 ديسمبر 2016 في Wayback Machine >.
  3. كيلي، آلان. "فلسفة البرمجيات القابلة للتوسيع". ACCU-الاحترافية في البرمجة (2002): موقع إلكتروني. 27 أبريل 2014. < http://accu.org/index.php/journals/391 >.
  4. زينجر، ماتياس. "1.2 خصائص آليات التوسعة". تجريدات لغة البرمجة لمكونات البرمجيات القابلة للتوسيع. لوزان: المعهد الفدرالي السويسري للتكنولوجيا، 2004. بدون ترقيم صفحات. موقع إلكتروني. 26 أبريل 2014. < http://zenger.org/papers/thesis.pdf >.
  5. ^ مارتن ريتر وبو نوريجارد يورجنسن. “سياقات قابلة للتوسيع بشكل مستقل”. تم نشره في "هندسة البرمجيات: المؤتمر الأوروبي الرابع، ECSA 2010، كوبنهاجن، الدنمارك، 23-26 أغسطس 2010، وقائع" . 2010. ص. 327.
  6. زينجر، ماتياس. "1.3 تصنيف آليات التوسعة". تجريدات لغة البرمجة لمكونات البرمجيات القابلة للتوسيع. لوزان: المعهد الفدرالي السويسري للتكنولوجيا، 2004. بدون ترقيم صفحات. موقع إلكتروني. 26 أبريل 2014.
  7. زينجر، ماتياس. "1.1.1 إعادة الاستخدام". تجريدات لغة البرمجة لمكونات البرمجيات القابلة للتوسيع. لوزان: المعهد الفدرالي السويسري للتكنولوجيا، 2004. بدون ترقيم صفحات. موقع إلكتروني. 26 أبريل 2014.
  8. غاري مكغرو. "أمن البرمجيات: بناء الأمن في" 2006. ص 9.
  9. لين باس، بول كليمنتس، ريك كازمان. "هندسة البرمجيات في الممارسة العملية" . 2003. ص 339.

شعار ويكشنريتعريف كلمة " قابلية التمدد" في قاموس ويكشنري