|
هل يمكن للبرمجيات أن تساعد في كتابة برامج أفضل؟
|
الحضارة البشرية الحالية تقوم على البرمجيات، كما يلاحظ المبرمج المخضرم بجرانستروسترب، فالبرمجيات متواجدة في كل شيء وليس فقط على الحاسبات، فهي في الأجهزة المنزلية والسيارات والطائرات والمصاعد والتليفونات ولعب الأطفال، وفي ما لا يحصى من أجزاء الماكينات والمعدات الصناعية بأنواعها.
في مجتمع كهذا يعتمد على البرمجيات إلى هذا القدر، فإن عواقب الأخطاء في البرمجيات التي بدأت تكثر في شكل فيروسات وجراثيم برمجية في الآونة الأخيرة قد تؤدي إلى كوارث كبيرة، مثل تحطم صاروخ، انهيار شبكة التليفون، توقف نظام المراقبة الجوية عن العمل، وغيرها.
في عام 2002 أجرى المعهد القومي الأمريكي للمعايير والتكنولوجيا دراسة توقعت أن أخطاء البرمجيات قد تكلف الاقتصاد الأمريكي 60 مليار دولار سنويا، أو ما يقرب من 6 في الألف من إجمالي الناتج القومي.
ومما زاد الأمر صعوبة، أن نظم المعلومات القائمة على البرمجيات أصبحت متداخلة ومتصلة معا بطريقة غير مسبوقة، كما نجد أن تطبيقاتها تتصرف بتعقيدات كبيرة.
ومتابعة أخطاء البرمجيات بالطريقة التقليدية وهي كتابة سطور من لغة البرمجة ثم اختبارها على جهاز الحاسب ومعالجة أي أخطاء تنتج أثناء تجربة البرنامج أصبحت أقل فاعلية بكثير في ظل التعقيدات الحالية في تداخلات البرمجيات. «لقد اصطدمنا بحائط» هكذا علق بلاك ستون رئيس العلماء بشركة بورلاند المنتجة للغات البرمجة.
لا مجال للخطأ
المبرمجون يقضون أوقاتهم في تصحيح ومعالجة أخطاء البرامج القائمة أكثر من الوقت الذي يقضونه في كتابة برامج جديدة، وطبقا لإحصائيات المعهد القومي الأمريكي للمعايير والتكنولوجيا فإن 80% من تكلفة تطوير البرمجيات لمشروع نظم معلومات تكون في تحديد ومعالجة عيوب البرامج.
ومن هنا تظهر أهمية البرامج التي يمكنها تحليل مفردات البرنامج المكتوب واختباره آليا ووضع أسس تأكيد الجودة. والهدف كما يوضح اميتاب سريفستافاالمهندس المتميز بأبحاث شركة مايكروسوفت هو الوصول إلى طريقة لضمان جودة البرمجيات أثناء صناعتها كما يحدث في صناعة السيارات، فهو يقول: المتابعة الآلية للجودة هي معيار الثقة في البرمجيات. ويمكن اعتباره هو استخدام البرمجيات لتحسين صناعة البرمجيات.
قريب جدا من المبرمج.. أفضل مكان لبرنامج اكتشاف الأخطاء هو أقرب ما يكون للمبرمج، لأنه كلما كان الاكتشاف مبكرا للخطأ كانت تكلفة المعالجة أقل.
هناك مثل دارج في أوساط البرمجيات تشرحه دجينانا كامبرا المدير التكنولوجي لمؤسسة كلوكورك الكندية أن الخطأ في البرنامج يتكلف دولارا واحدا لمعالجته على جهاز المبرمج، ومائة دولار إذا ظهر في إطار برمجيات أخرى وآلاف الدولارات إذا تم اكتشافه بعد انتشار استخدامه، وهناك حالات تكون تكلفة المعالجة أكبر من ذلك بكثير مثل الخطأ في برنامج شبكة التليفونات أو نظام المراقبة الجوية الذي قد يتكلف الملايين إذا كان يستخدم فعليا.
إن استخدام برنامج ما لفحص برنامج آخر واكتشاف أخطائه هو أمر ليس باليسير، وقام خبراء البرمجيات لعقود طويلة مضت في محاولة وضع أسس واختبارات لتحليل البرمجيات والتأكد من سلامتها وقيامها بالدور المنوط بها، ولكن هناك عقبتان تواجهان هذا الأمر:
الأولى أن هذه الاختبارات مرهقة وغير عملية، فمثلا ثلاثة سطور من البرمجة تحتاج إلى صفحة كاملة من الجبر والمعادلات الرياضية للتأكد من صحتها، والآن يحتوي البرنامج الواحد على ملايين السطور، والعقبة الثانية أن هذه الاختبارات غير قابلة للبرمجة، حيث إنها يدوية وتحتاج إلى عمالة مكثفة.
أما جريدي بوش وهو من رواد تقنيات تطوير البرمجيات المدير العلمي لمؤسسة راشونال الشهيرة في مجال تطوير تقنيات تطبيقات البرمجيات، وهي الآن تتبع شركةأي بي إم فإنه يقول إن الطرق التقليدية لتحليل ومعالجة البرمجيات لم تحقق وعودها الكبيرة المفترض منها. ويتابع: لقد رأينا بعض التحسينات في التقنيات والتكنولوجيا، ولكني لم ألاحظ أي طفرة منذ الستينيات.
أنا لا أعني أنها غيرمفيدة ولكنها مجدية فقط في المهمات الحساسة مثل مركبات الفضاء وشبكات الاتصالات والنظم العسكرية.
الحلول العملية
بالرغم من أن الأبحاث لم توفق في تحقيق الوعود التي تعهدت بها في الستينات، إلا أنها نجحت في الوصول إلى تقنيات مفيدة، فهناك العديد من المؤسسات التكنولوجية تنتج برمجيات تساعد المبرمجين على ضمان نجاح برامجهم. وحجر الزاوية في الموضوع هو ربط نظم تطوير البرمجيات بتقنيات تحليل البرامج وتصويب أخطائها ويؤكد بعض الخبراء أنه لا يوجد حل مثالي وحيد، ولكن لابد من تقبل الحلول العملية أن لكل بيئة برمجية الوسيلة الملائمة لتحليل برامجها وتصويب أخطائها.
الأمل هو أن انتشار استخدام تقنيات الاختبار والتحليل حتى تصبح جزءا لا يتجزأ من أدوات البرمجة التي لا غنى عنها للمبرمج، وتكون النتيجة برمجيات بأخطاء أقل وتحسن في نوعيتها.
الخطأ من الصواب من التقنيات المعروفة في مجال تحديد الأخطاء في البرمجيات هو كتابة توصيف رياضي للمطلوب من البرنامج تنفيذه، ومقارنة الوصف الرياضي بالبرنامج المكتوب. ولكن الوصف الرياضي من الصعب التعامل معه تماما مثل البرنامج المكتوب، وتبقى الاستثناءات في البرامج الصغيرة ذات الوظائف المحددة، فهي أسهل للمتابعة والتحليل من البرمجيات المعقدة والمتشعبة.
شركة مايكروسوفت تستخدم نظام تحليل البرامج والبحث عن الأخطاء المعروف باسم static driver verifier للتعامل مع برمجيات تعريف الكروت.
هذه البرامج تتكون مما يزيد عن مائة ألف سطر من الشفرات والرموز، ولها وظيفة محددة هي الربط بين جهاز الكمبيوتر والأجهزة الطرفية، مثل كارت الشاشة أو وحدة التخزين. أما المحاكاة الرياضية لبرمجيات نظم التشغيل أو متصفح الانترنت فهي من الناحية العملية أمر شبه مستحيل. إحدى الوسائل المتعارف عليها للوصول إلى المطلوب هي ترك النمذجة الرياضية لهذه البرمجيات ومحاولة توصيف الأخطاء، وهو أمر أسهل نسبيا.
ومثال لذلك الخطأ الشائع المعروف باسم buffer overflow والذي يحدث عندما يحاول الكمبيوتر تخزين بيانات في الذاكرة الاحتياطية أكثر من سعتها، مما يؤدي إلى ضياع البيانات المخزنة، ويعتبر خطأ في تنفيذ البرنامج. وأحد طرق معالجته تكون بتمشيط كود البرنامج للبحث عن أماكن الكتابة في الذاكرة الاحتياطية والتأكد من سعتها، وإذا لم ينجح في تحديد مكان الخطأ فإنه يسجل أن هناك خطأ.
العودة إلى الكود
البحث عن أخطاء البرمجيات داخل سطور الكود يسمى «التحليل الاستاتيكي» لأنه يتم والبرنامج لا يعمل، وهذا مفيد في حالة البحث عن الثغرات الأمنية، والكود المضطرب والسطور التي لم تعد تستخدم في البرنامج، وكل هذا لايحتاج إلى معرفة بوظائف البرنامج أو الغرض منه، ويحتاج إلى أداة بحث عامة الغرض للبحث الاستاتيكي. شركة مايكروسوفت طورت أداة للبحث الاستاتيكي عن الأخطاء في البرامج فوركتابتها مما يؤدي إلى تقلصها، وتسمى PRE fast وهو جزء من الاستراتيجية التي تتبناها مايكروسوفت تحت شعار الثقة في البرمجيات لزيادة الاعتماد على منتجاتها، وتم استخدامه أثناء تطوير بيئة الويندوز اكس بي، وبعد ذلك تم تعميم استخدامها داخل الشركة وتخطط لاستخدامها على نطاق واسع.
مقاونة الاصدارات
أخطاء البرمجيات يمكن أيضا اكتشافها بمقارنة الإصدارات الحديثة من البرمجيات بمثيلتها القديمة التي كانت تعمل، مثال ذلك برنامج التصحيح الإملائي في أوفيس مايكروسوفت، عندما يتم تطوير إصدار جديد له، يتم اختباره للتأكد من أنه مازال يعمل بالطريقة التقليدية للبرنامج.
هذه الطريقة في اختبار البرمجيات تتم داخل مايكروسوفت وعلى نطاق واسع في أماكن أخرى في العالم. ويقول سريفستافا الخبير الدولي أن الصعوبة تكمن في تحديد الكود المطلوب اختباره، لأن البرنامج يحتوي على عشرات الوظائف والأكواد، من أجل هذا فقد اقترح نظام تحليل جديد يسمى سكوت Scout يقارن البرنامج بشكله الثنائي Binary مع الشكل الثنائي للإصدار القديم، وهذا يظهر نقاط الاختلاف ويحدد الوظائف المطلوب اختبارها. وتقنية سكوت لها فائدة أخرى أنها تحدد عدد الوظائف المطلوب اختبارها في الإصدار الجديد، فإذا كان التغيير الجديد يحتاج إلى اختبارات كثيرة، فهذا دليل على خطورة التعديل، ومن الأفضل تجنبه. وكذلك يمكنه ترتيب أولويات الاختبارات، فيتم اختبار الأهم فالمهم، وهذا يؤثر في معالجة الاختراقات الأمنية لنظم التشغيل حيث سرعة المعالجة عامل فعال.
اختبار واقتراح التصويبات
شركة أجيتار بولاية كاليفورنيا تؤمن بخطوة أعمق، اقترحت نظام اختبار يسمى Agitator يختبر البرنامج ويحدد الأخطاء ويقترح التصويبات اللازمة، وهذا يوفر وقت المبرمج من الفحص اليدوي وصيانة البرنامج، وهذا شعار ألبرتو سافويا الخبير المحنك بجوجل وسن سيستيمز ومؤسس شركة اجيتار، ووعد بكشف المزيد من التفاصيل قريبا.
البرمجة بالنماذج
أحد الطرق لاكتشاف أخطاء البرمجيات هي تحليل الكود التفصيلي وتكوين نموذج لفكرة البرنامج ووظائفه، وتتم مقارنة هذا النموذج بالنموذج الجديد للإصدار الجديد للتأكد من تطابقهما، وخلو الإصدار الجديد من أخطاء جديدة وتحديد الأخطاء القديمة الموجودة في الإصدار السابق للبرنامج.
وكما يمكن استنتاج وتكوين النموذج الرياضي من كود البرنامج يمكن العكس أيضا، وهو كتابة كود برامج من النموذج الرياضي وذلك إلى حد ما. فنظم النمذجة مثل Rational Rose تسمح بتصميم البرمجيات طبقا لنموذج فكري ورياضي بدون الحاجة لكتابة أي كود بيد المبرمجين.
وذلك ينتج هيكل كودي يمكن للمبرمج أن يضيف عليهما يريد من الكود تحقيق متطلباته، وأشهر هذه النماذج هو language unifiedmodeling (UML) الذي ابتكره د/بوش واعتبرها مسودة للبرمجيات. وهو يتفوق على كل لغات البرمجة ونظم التشغيل والتفاصيل الفنية المعقدة ويسمح باختبار البرنامج طبقا لمتطلبات التصميم، وأصبحت الآن جزءا لا يتجزأ من نظم البرمجيات.
هذا لا يعني بأي حال من الأحوال أن النموذج الرياضي للبرنامج هو شق نظري بحت، ويوضح د/بوش كتابة النموذج الرياضي ثم كتابة الكود أمر لن ينجح أبداً ولكن النموذج الرياضي والكود هما وجهتا نظر لنفس الشيء، فالنماذج ما هي إلا وسائل لمساعدة المبرمجين على فهم البرامج القائمة وكتابة البرامج الجديدة.
وخلافا للصراع القائم بين نظريات البرمجة التي تختلف بين تكوين البرنامج من أعلى لأسفل أو تكوين النموذج ثم كتابة الكود، فإن د/بوش يؤيد البداية المحدودة للنموذج والكود واختبارهما، ثم تطور الكود تدريجيا مع تحديث متواز للنموذج.
استخدا م النماذج الرياضية للبرمجيات يعزز من إمكانية التحليل والتصويب الآلي للبرمجيات، وخاصة تجانس الكود والنموذج بحيث يكون الكود المضاف إلى البرنامج.
معرف للنموذج
لسنوات عديدة حاول الباحثون بناء نظم وبرمجيات بالطرق التقليدية من نماذج تفصيلية، ولكن هذه المحاولات لم تخرج من إطار الطموحات الفكرية. لأنه في الحقيقة معظم المبرمجين يعملون مع الأكواد والبرامج القائمة فعلا، وهي عادة ما تفتقر لوجود نماذج موضحة لها، وهذا ما يجب على أدوات النمذجة القيام به «عمل نماذج للبرمجيات القائمة».
والنماذج لها فوائد كثيرة، منها التأكد من أن المبرمجين لا يقومون بتعديل البرمجيات بما يغير من طبيعتها والهدف من إنشائها، هذا بالإضافة إلى مكافحة الأخطاء واكتشافها، وذلك بمقارنة النموذج الناتج من الكود مع النموذج الأصلي للبرنامج، وتطلق السيدة كامبارا على هذه الطريقة «حماية النموذج من التآكل»، وتؤكد على حتمية وجود هذه الأدوات داخل مطورات البرمجيات نفسها، فمطالبة المبرمجين بتغيير أسلوب عملهم بين عشية وضحاها أمر غير عملي، وتطالب بأن تكون أدوات المساعدة في البرمجة سهلة الاستخدام ومريحة للمبرمج حتى لا ينفر منها.
العامل البشري وكتابة الكود
كل ما سبق يصب في موضوع مهم ويعتبر أساسيا في تحسين نوعية البرمجيات، وهو أثره على المبرمجين من حيث تحويل انتباههم عن الهدف الرئيس وهو البرمجة.
فأدوات الاختبار الآلية وتصويب الأخطاء تعطي إشارات لمطوري البرمجيات لتوضيح المشاكل التي قد تتواجد في البرامج، فرئيس فريق العمل يمكنه حينئذ تحديد أجزاء البرنامج التي بها عيوب ومعالجتها.
وهذا يجعل البرنامج أسهل في التتبع والأخطاء أو المشاكل تظهر بسرعة، وتؤدي أيضا إلى مقارنة أداء المبرمجين بطريقة غير مقصودة، حيث يمكن للمديرين تحديد نسبة الأخطاء عند كل مبرمج، فذلك مخيف بالنسبة لبعض المبرمجين، ولكنه أمر حتمي أن تحدث هذه المقارنات كما توضح السيدة كامبارا.
هناك خلاف في أوساط البرمجيات في مدى ترحيب المبرمجين بمثل هذه الأدوات التي تكشف أخطاء البرمجة فور كتابتها، فمنهم من يتوقع قبولها واستخدامها وآخرون يؤكدون أن المبرمجين سيرفضونها، فالسيد سريفستافا متفائل بشرط أن تستخدم هذه الأدوات بطريقة صحيحة لتحسين مستوى المبرمجين وليس لعقابهم، فهو يقول: عندما تكتشف خطأ ما وتدرب المبرمج لعدم تكراره مرة أخرى فهذا شيء جيد. وكذلك أيضا يوضح د/بوش أحد الأبحاث التي راقبت خمسين من المبرمجين لمدة أربع وعشرين ساعة، وجد أن 30% فقط من الوقت استخدم في كتابة الكود والباقي في التحدث مع الزملاء. ويقول: تطوير البرمجيات هي عمل جماعي ويؤكد أن الأدوات التي تتعمق في الكود وتسبح خلاله لاكتشاف الأخطاء وتحدد اتجاهات العمل فذلك يساعد في تحسين العمل الجماعي.
هناك دائما المعارضون، فالسيد ستون يحذر من مغبة الثقة الزائدة في الأرقام والاقتراحات الناتجة من أدوات متابعة البرمجيات، ويعترف أنها تعطي انطباعات داخلية عن الكود. ولكن هل تستخدم هذه الأرقام في قرارات سليمة أم غير ذلك؟ويقترح أدوات إضافية تحدد المبرمج الذي عدل وظيفة ما داخل البرامج واقتراح التطورات اللازمة لتطوير البرمجيات.
ان التخاطب والاتصال بالآخرين هي رغبة بشرية تلقائية وكذلك عمل الأخطاء في البرمجيات، فلاستخدام البرمجيات في صناعة البرمجيات لابد من مراعاة البعد البشري والنفسي للمبرمجين، فلا ننسى أنهم بشر في المقام الأول.
.....
الرجوع
.....
|
|
|
|
توجه جميع المراسلات التحريرية والصحفية الى
chief@al-jazirah.com عناية رئيس التحرير
توجه جميع المراسلات الفنية الى
admin@al-jazirah.com عناية مدير وحدة الانترنت
Copyright 2002, Al-Jazirah Corporation, All rights Reserved
| 