البرمجيات المتقدمة (هندسة ـ)
هندسة البرمجيات الغرضية التوجه
1 ـ مفاهيم المنهج الغرضي التوجه في هندسة البرمجيات
تجسِّد التقانات الغرضية رؤيةً طبيعية للعالم. إذ تصنَّف الأغراض ضمن صفوف وهرميات صفوف. يحوي كل صف مجموعة من الواصفات التي تصِفه ومجموعة من العمليات التي تعرّف سلوكه. وتقوم الأغراض (والصفوف التي تشتق منها هذه الأغراض) بكبسلة المعطيات والإجرائية معاً. إن عمليات المعالجة هي جزء من الغرض، وتبدأ هذه المعالجة بإرسال رسالة إلى الغرض. يكوّن تعريف الصف أساساً لإعادة الاستخدامية reusability في مستويات النمذجة والتصميم والتنجيز implementation.
تؤدي التقانات الغرضية التوجه إلى إعادة الاستخدام reuse، وإعادة الاستخدام (للمكونات البرمجية) تؤدي إلى تطوير برمجي أسرع، وإلى برامج ذات جودة أعلى. إن البرمجيات الغرضية التوجه أسهل صيانةً لأن بنيتها منفصلة الأجزاء بطبيعتها.
هناك ثلاثة مفاهيم هامة تميّز بين المنهج الغرضي التوجه والمنهج التقليدي في هندسة البرمجيات. فالكبسلة encapsulation تحزم كلاً من المعطيات والعمليات التي تتعامل مع هذه المعطيات في غرض واحد مسمّى. والوراثة inheritance تمكّن من توريث الواصفات والعمليات في صف لجميع الصفوف الفرعية والأغراض المستنسخة instances من هذه الصفوف. أما تعدّدية الأشكال polymorphism، فتسمح لعدد من العمليات المختلفة بأن يكون لها الاسم ذاته، وهذا يُخَفِّض عدد أسطر الرماز اللازم لتنجيز النظام، ويُسهّل التعديلات حين الحاجة إليها.
تعتمد إدارة المشاريع البرمجية في حالة المشاريع الغرضية التوجه على المبادئ الأساسية نفسها في الإدارة، ولكن التقنية يجب أن تُكيَّف بحيث تدار المشاريع الغرضية التوجه بطريقة مناسبة. إن إطار العمل في حالة المشاريع الغرضية التوجه ليس نموذجاً خطياً تتابعياً. فالنماذج الخطية التتابعية، تفترض أنّ المتطلبات محدّدةٌ في بداية المشروع، وأن الفعاليّات الهندسيّة تتقدم بطريقة تتابعية خطية. على حين أن هندسة البرمجيات الغرضية التوجه يجب أن تطبِّق نموذجاً يُشجّع التطوير التكراري. ذلك أن البرمجيات الغرضية التوجه تتطور من خلال عدد من الدورات.
هناك «نموذج عوديّ/متوازٍ» recursive/parallel لتطوير البرمجيات الغرضية التوجه. يعمل هذا النموذج وفق الطريقة التالية:
ـ القيام بتحليل كافٍ لعزل الصفوف الرئيسة في المسألة والارتباطات الرئيسية؛
ـ استخراج الأغراض القابلة لإعادة الاستخدام من مكتبةٍ بغية بناء نموذج أولي تقريبي؛
ـ إجراء بعض الاختبارات لكشف الأخطاء الموجودة في النموذج الأولي؛
ـ تسجيل ردود فعل الزبون على النموذج الأولي؛
ـ تعديل النموذج التحليلي بناءً على ما استُنتِج من النموذج الأولي، ومن ردود فعل الزبون؛
ـ تفصيل التصميم لملاءمته مع التعديلات؛
ـ القيام بهندسة بعض الأغراض الخاصة (غير المتوفرة في المكتبة)؛
يستمر هذا المنهج إلى أن يتحول النموذج الأولي إلى تطبيقٍ إنتاجي. ويتطلب كل تكرار في الإجرائية العودية/المتوازية تخطيطاً وهندسة (تحليلاً وتصميماً واستخراجاً للصفوف، ونمذجة أولية، واختباراً) إضافة إلى فعّاليات التقويم.
2 ـ التحليل الغرضي التوجه
التحليل الغرضي التوجه هو الفعّالية التقنية الأولى في هندسة البرمجيات الغرضية التوجه. والغاية منه هي تعريف جميع الصفوف (والعلاقات والسلوك المرتبط بها) التي ترتبط بالمسألة المراد حلها.
إن منهج التحليل الغرضي التوجه مختلف اختلافاً جذرياً عن المنهجيات الموجَّهة بالإجرائية كالتحليل البنيوي (منهج تقليدي). وأدى رواج التقانات الغرضية إلى إنتاج العشرات من مناهج التحليل الغرضية التوجه.
على الرغم من اختلاف طرائق التحليل الغرضي التوجه وتباين المصطلحات المستخدمة فيها، فإنها تتضمن الخطوات العمومية التالية:
ـ الحصول على متطلبات الزبون للنظام.
ـ تعيين حالات الاستخدام use cases (أي المَشاهد التي تصف كيفية استخدام النظام).
ـ استخراج الصفوف والأغراض انطلاقاً من المتطلبات.
ـ تعيين واصفات كل غرض في النظام وعملياته.
ـ تعريف البنى والهرميات التي تنظّم الصفوف.
ـ بناء نموذج لعلاقات الأغراض.
ـ بناء نموذج لسلوك الأغراض.
ـ مراجعة نموذج التحليل مقارنةً بحالات الاستخدام.
3 ـ التصميم الغرضي التوجه
يترجم التصميمُ الغرضي التوجه نموذجَ التحليل الغرضي التوجه للعالم الحقيقي إلى نموذج قابل للتحقيق برمجياً. تُوصف إجرائية التصميم الغرضي التوجه كهرَم مكوّن من أربع طبقات (الشكل 1). تركّز الطبقة القاعدية في هذا الهرم على تصميم النظم الفرعية التي تحقق الوظائف الرئيسية للنظام. وتحدِّد طبقة الصفوف بنيان الأغراض وهرمية الصفوف اللازمة لتحقيق النظام. وتبيِّن طبقة الرسائل كيفية تحقيق المشاركة بين الأغراض. وأخيراً تعيِّن طبقةُ المسؤوليات الواصفاتِ والعمليات التي تميّز كل صف.
خلال مرحلة تصميم النظم الفرعية، تراعى أربعة مكوّنات: نطاق المسألة (متطلبات الزبون)، التفاعل مع الأشخاص، إدارة المهمات tasks، إدارة المعطيات.
تركّز إجرائية تصميم الأغراض على وصف بنى المعطيات التي تحقق واصفات الصف، والخوارزميات التي تحقق العمليات، والرسائل التي تتيح المشاركات والعلاقات بين الأغراض.
تنتقل البرمجة الغرضية التوجه بالنموذج التصميمي باتجاه التنفيذ. وتُستعمل لغة غرضية التوجه لترجمة الصفوف والواصفات والعمليات والرسائل إلى برنامج قابل للتنفيذ.
هناك طرائق مختلفة للتصميم الغرضي التوجه، بيد أنها جميعاً تتوافق مع هرم التصميم المذكور.
4 ـ الاختبارات الغرضية التوجه
إن الهدف من الاختبارات الغرضية التوجه يطابق هدف الاختبارات في البرمجيات التقليدية، وهو إيجاد أكبر عدد من الأخطاء بأقل قدر من الجهد. بيد أن الاستراتيجية والخطط في الاختبارات الغرضية التوجه تختلف على نحوٍ ملحوظ.
تبدأ استراتيجية اختبار البرمجيات الغرضية التوجه بالاختبارات الضيقة وتعمل متوسّعةً باتجاه الاختبارات العريضة. وباستخدام المصطلحات المألوفة في اختبارات هندسة البرمجيات[ر]، نبدأ باختبار الوحدة ثم نسير باتجاه اختبار التكامل ثم نبلغ غايتنا باختبار إقرار الصلاحية واختبار النظام.
بعد أن تُنجَز البرمجة الغرضية التوجه، يطبَّق اختبار الوحدة لاختبار الصفوف كلٍ على حدة، ذلك أن نقطة تركيز الاختبار في الحالة الغرضية التوجه هي الصف وليس الوحدة البرمجية (المجتزأ) كما في حالة البرمجيات التقليدية. يَستخدم اختبار الصف العديد من الطرائق، مثل اختبار التجزئة (وهي طريقة تخفِّض عدد حالات الاختبار اللازمة لتجريب صف ما). وتَعتمد كل طريقة على تصميم متتاليات اختبار للتأكّد أن العمليات المكبسلة في الصف قد جُرِّبت. تُفحص حالة الصف (الممثّلة بقيم واصفاتها) لاكتشاف الأخطاء.
يمكن القيام باختبارات التكامل باستخدام استراتيجية معتمدة على النيسب thread. يُكامِل الاختبارُ المعتمِد على النيسب مجموعةَ الصفوف التي تتشارك في الاستجابة لدخل وحيد أو لحدث وحيد. يُكامَل كل نيسب ويختبر إفرادياً.
إن اختبارات إقرار الصلاحية في النظم الغرضية التوجه هي من النوع الموجه بالصندوق الأسود، ويمكن أن تحقق بتطبيق نفس طرائق الصندوق الأسود المدروسة في البرمجيات التقليدية. بيد أن حالات الاختبار هي الموجّه الرئيسي لاختبارات إقرار الصلاحية.
مواضيع متقدمة في هندسة البرمجيات
1ـ هندسة برمجيات الغرفة النظيفة
هندسة برمجيات الغرفة النظيفة cleanroom software engineering هي منهجٌ صوريٌ formal approach للتطوير البرمجي (تقنية تعتمد على الرياضيات لوصف خواص البرمجيات). يعتمد هذا المنهج على بناء الصحة correctness ضمن البرمجية أثناء تطويرها. فبدلاً من الدورة التقليدية المتمثلة في التحليل، والتصميم، والترميز، والاختبار، والتفلية (التنقيح)، يَتبع منهجُ الغرفةِ النظيفة فلسفة مغايرة. تتمثل هذه الفلسفة في تجنب الحاجة إلى إجرائيات مكلفة لإزالة العيوب، وذلك بكتابة تزايدات الرماز كتابة صحيحة من المرة الأولى، وبتحقق صحتها قبل الاختبارات.
يبدأ منهج الغرفة النظيفة بنماذج التحليل والتصميم التي تستخدم تمثيل البنية الصندوقية. إذ يُكبسِل «صندوقٌ» النظامَ على مستوى معين من التجريد. فتُستخدَمُ الصناديقُ السوداء لتمثيل السلوك الظاهري للنظام. وتُكبسِل صناديقُ الحالة state boxes حالةَ المعطيات والعمليات. في حين يُستخدَمُ الصندوق الواضح clear box لنمذجة التصميم الإجرائي المضمَّن في معطيات وعمليات صندوق الحالة.
يُطبَّق «تحقق الصحة» عندما يكتمل تصميم البنية الصندوقية. يقسم التصميم الإجرائي لمكون برمجي إلى متتالية من الوظائف الجزئية. ولإثبات صحة كل من هذه الوظائف الجزئية، تُحدَّد شروط الخروج لكل من هذه الوظائف، وتُطبَّق مجموعة من البراهين الجزئية. إذا تحقق كل شرط من شروط الخروج عندها يكون التصميم صحيحاً.
بعد تحقُّق الصحة، تبدأ اختبارات الاستخدام الإحصائية. وخلافاً للاختبارات التقليدية، لا تُلِحُّ هندسة برمجيات الغرفة النظيفة على اختبار الوحدات أو التكامل. إذ تُختَبَرُ البرمجية بتعريف مجموعة من مشاهد الاستخدام، وتحديد احتمال استخدام كل مشهد، ومن ثَم تعريف اختبارات عشوائية متوافقة مع الاحتمالات. ويجري دمجُ تسجيلات الأخطاء الناتجة في نماذج العينات والمكونات والمصادقة ليصبح بالإمكان حساب الموثوقية المتوقعة رياضياً للمكون البرمجي.
2 ـ إعادة استخدام البرمجيات
أصبحَ ضرورياً، في الوقت الحاضر، بناءُ نظمٍ حاسوبية معقدة وعالية الجودة، وذلك خلال مُدَدٍ قصيرة، وهذا يتطلب منهجاً أكثر تنظيماً لإعادة الاستخدام. تقدِّم إعادةُ استخدام المكوناتِ أرباحاً من حيث جودة البرمجية، وإنتاجية المطوِّر، والكلفة الإجمالية للنظام.
تشمل إعادة استخدام البرمجيات أكثر من مجرد الرماز المصدري. فهناك مجموعة من المصنوعات artifacts يعاد استخدامها عند القيام بهندسة البرمجية. تشمل هذه المجموعة: المواصفات، نماذج البنيان، التصميم، الرماز، الوثائق، معطيات الاختبار، وحتى المهمات المتعلقة بالإجرائية (كتقنيات التدقيق).
تتضمن إجرائية إعادة الاستخدام إجرائيتين فرعيتين متسايرتين، هما هندسة النطاق وهندسة البرمجيات. تهدف هندسة النطاق إلى تعيينِ مجموعةٍ من المصنوعات البرمجية وبنائها وتصنيفِها ونشرها، ضمن نطاق محدد للتطبيقات. وتقوم هندسة البرمجيات بعدئذ باستخلاص هذه المصنوعات لإعادة استخدامها عند تطوير نظام جديد.
يُدرَس اقتصاد إعادةِ استخدام البرمجيات من خلال سؤال وحيد هو: هل تكون الكلفة مجدية عندما نُقِلُّ من البناء ونُكثِرُ من إعادة الاستخدام؟ والجواب بوجهٍ عام هو «نعم»، ولكن يجب على مُخَطَِّط المشروع البرمجي أن يدرس التكاليف غير الضئيلة، المتعلقة بتكييف المكونات القابلة لإعادة الاستخدام ومكاملتها.
3 ـ إعادة الهندسة
تشمل إعادة الهندسة مستويين مختلفين من التجريد: مستوى الأعمال ومستوى البرمجيات. ففي مستوى الأعمال، تركِّز إعادة الهندسة الاهتمام في إجرائية الأعمال، بغية إجراء التغييرات لتحسين القدرة التنافسية في بعض مناطق الأعمال. على حين تقوم إعادة الهندسة في مستوى البرمجيات بفحص نظم المعلومات والتطبيقات بقصد إعادة تنظيم بنيتها أو إعادة بنائها للحصول على جودة أعلى.
تتضمن إعادة هندسة إجرائية الأعمال Business Process Reengineering (BPR): تعريف أهداف الأعمال، تعيّن إجرائية الأعمال المتاحة (ضمن سياق الأهداف المحددة) وتقويمها، توصيف الإجرائيات المنقَّحة وتصميمها وصنع نموذج أولي لها، تفصيل تلك الإجرائيات. يمتد اهتمام BPR إلى ما بعد البرمجيات. وغالباً ما ينتج عن BPR تعريف الأساليب التي تمكِّن تقانات المعلومات من دعم الأعمال على وجهٍ أفضل.
تشمل إعادة هندسة البرمجيات سلسلة فعاليات تتضمن:
ـ تحليل الجرد (تقييم كل تطبيق لدى المؤسسة بقصد تحديد البرامج المرشَّحة لإعادة الهندسة).
ـ إعادة تنظيم بنية الوثائق.
ـ الهندسة العكسية reverse engineering (إجرائية تحليل برنامج معطى بغية استخراج المعلومات المتعلقة بتصميم المعطيات والتصميم البنياني والإجرائي).
ـ إعادة تنظيم بنية البرنامج والمعطيات.
ـ الهندسة الأمامية forward engineering (إعادة بناء برنامج معين باستخدام الممارسات المعاصرة لهندسة البرمجيات والمعلومات المكتسبة خلال الهندسة العكسية).
القصد من هذه الفعاليات هو إنشاء إصدارات لبرامج موجودة تتمتع بجودة أعلى وقابلية صيانة أفضل – برامج قابلة للحياة في القرن الحادي والعشرين.
4 ـ هندسة برمجيات الزبون/المخدم
تحوي بنية الزبون/المخدم (C/S) تقليدياً، حواسيب تقدِّم خدمات، تسمى مخدِّمات، وحواسيب تطلب تلك الخدمات، تسمى زبائن. وتتصل الزبائن بالمخدمات بواسطة شبكة اتصال. يتألف نظام الزبون/المخدم من عدة مكونات متمايزة: مكون التخاطب مع المستخدم، التطبيق، إدارة قاعدة المعطيات. وتُسنَد هذه المكونات إلى الزبون أو المخدم أو توزع بينهما. وهناك إرشادات لتوزيع تلك المكونات. إضافة إلى تلك المكونات، توجد في جميع نظم الزبون/ المخدم كتلةٌ أخرى لبناء البرمجيات، تسمى في الغالب برمجيات وسطى middleware تتولى معالجة طلبات الأغراض بين الزبون والمخدم. من أمثلة البرمجية الوسطى، وسيط طلب الأغراض Object Request Broker (ORB).
تستطيع نظم الزبون/ المخدم اعتماد أحد نماذج الإجرائية البرمجية، وكثيراً من طرائق التحليل والتصميم والاختبار التقليدية. بيد أن نموذجاً تطورياً يستخِدمُ هندسةَ البرمجيات المعتمدة على الأحداث و/أو الغرضية التوّجه، هو أشدّ فعالية لها.
تنطبق مبادئ التحليل الأساسية التقليدية وطرائق نمذجة التحليل على برمجيات الزبون/ المخدم أيضاً. إضافة إلى ذلك، يمكن أن يَستخدم تحليلُ نظم الزبون/المخدم وتصميمُها مخططَ تدفق المعطيات ومخططَ العلاقات بين الكيانات.
بسببٍ من طبيعة نظم الزبون/المخدم الموزعة، فإنه يجب تعديل استراتيجيات الاختبار لتناسب الاختبارات التي تفحص الاتصالات الشبكية والدور المتبادل بين البرمجيات القاطنة عند الزبون والمخدم.
5 ـ هندسة البرمجيات بمعونة الحاسوب
هندسة البرمجيات بمعونة الحاسوب CASE هي صندوق أدوات مهندس البرمجيات، وهي تمنحه المقدرةَ على أتمتة الفعاليات اليدوية. تشمل أدوات CASE كل مرحلة من مراحل الإجرائية البرمجية والفعاليات المرافقة لتلك الإجرائية مثل: هندسة المعلومات، نمذجة الإجرائيات، تخطيط المشروع، التوثيق، ضمان الجودة، إدارة تشكيلة البرمجيات، التحليل والتصميم، النمذجة الأولية، أدوات المكاملة والاختبار، إعادة الهندسة. وتضم مجموعةً من كتلِ البناء تبدأ من مستوى العتاديات وبرمجيات نظم التشغيل، وتنتهي بالأدوات الإفرادية.
تتفاوت أدوات CASE في التعقيد، فقد توفِّر حلولاً نقطية فقط، أي تقدم المساعدة في فعالية معينة من فعاليات هندسة البرمجيات (كنمذجة التحليل) ولكنها لا تكون على اتصال مباشر مع أدوات أخرى. ويمكن أن تكون الأدوات متكاملة وتضم آليات تكامل للمعطيات وللأدوات ولتخاطب الإنسان مع الحاسوب.
6 ـ هندسة برمجيات الإنترنت
أدى اتساع الإنترنت واتخاذها ممراً مركزياً للتجارة العالمية وللمعلومات، إلى إدخال لغة جديدة. فنحن نتكلم اليوم عن عصر الإنترنت وبرمجيات الإنترنت وارتفاع وانخفاض الأعمال الإلكترونية. وأخذت أدوات تطوير برمجيات الإنترنت بالتطور والاتساع.
7 ـ مستقبل هندسة البرمجيات
إن الأشخاص الذين يطورون البرمجيات ويستخدمونها، وإجرائية هندسة البرمجيات التي تُطبَّق، والمعلومات التي تُنتَج، كل ذلك يتأثر بالتقدم الحاصل في تقانة العتاديات والبرمجيات. لقد استُخدمت العتاديات تاريخياً محرِّكاً للتقانة في الحوسبة. إن أي تقانة عتاديات جديدة تمثل كموناً. فيقوم مطورو البرمجيات بعد ذلك بالتفاعل مع طلبات الزبون في محاولة للاستفادة من ذاك الكمون. لكن التغيرات الفعلية في تقانة العتاديات قد تَحدُث في مسار آخر. إذ إن تطوير البنيانات العتادية غير التقليدية (مثل الآلات الغزيرة التوازي massively parallel machines، والمعالِجات الضوئية، وآلات الشبكة العصبونية) قد تسبب تغيرات جذرية في نوع البرمجيات التي نبنيها، وفي منهجنا لهندسة البرمجيات.
سوف تتغير هندسة البرمجيات. ومع ذلك سيبقى التحليل والتصميم الفعّالين والاختبار المنافس محتلاً مكاناً في تطوير النظم الحاسوبية.
نزار الحافظ
المراجع
موسوعة الأبحاث العلمية
التصانيف
الأبحاث