المحاضرة السابعة القسم الاول

مفاهيم التحليل ومبادئه Analysis Concepts and Principles
مقدمة Introduction :
إنَ الفهم التام لمتطلبات البرامجيات شيء أساسي في إنجاح جهد تطوير البرامجيات. حيث لا أهمية ليكون تصميمه جيد أو إنَ كتابة الشفرة جيدة , وإنما التحليل والتحديد الضعيف للبرنامج سيضر المستخدم والمطور .
أن مهمة تحليل المتطلبات هي عملية استكشاف , إعادة تصفية , نمذجة , وضع محددات. حيث إن مجال البرمجية بداية يتم تأسيسها من قبل مهندس النظام ويتم تصفيتها خلال التخطيط للمشروع البرمجي. سيتم نمذجة البيانات المطلوبة, سريان المعلومات و السيطرة، وتكوين السلوك الإجرائي Operation Behavior ومن ثم سيتم تحليل وتخصيص حلول مختلفة لعناصر البرمجية المتعددة .
إن المطور والزبون , كلاهما يأخذان دورا فعالا في تحليل المتطلبات و وضع المحددات. حيث إن الزبون يحاول في بعض الأحيان تحويل وظيفة و أداء البرمجية الهش إلى تفاصيل صلبة. أما المطور فيعمل كمستشار او حلال للمشكلات.
في بعض الأحيان قد تظهر عملية تحليل المتطلبات ووضع المحددات كمهمة بسيطة , ولكن المظاهر خادعة. فمحتويات الاتصال يجب أن تكون عالية ، فرصة وجود التفسير أو معلومات مفقودة غير محدودة ، الغموض وارد .

تحليل المتطلبات Requirements Analysis:
إن تحليل المتطلبات هي إحدى مهام هندسة البرامجيات التي تكون كجسر للفجوة بين هندسة النظام System Engineering وتصميم البرامجية Software Design، حيث:
1- إن تحليل المتطلبات يمكِّن مهندس النظام من تحديد وظيفة النظام وأداءه , يضع مؤشرات لواجهة البرامجية مع بقية عناصر النظام , ويؤسس قيود على البرامجية إن تُطابقها .
2- إن تحليل المتطلبات تسمح للمحلل بتصفية تخصيصات البرامجية وبناء موديلات للـ ( المجال البياني , المجال الوظيفي , والمجال السلوكي) التي تُعالج من قبل البرامجية .
3- إن تحليل المتطلبات تزوِّد مصمم البرامجية بالموديلات التي يمكن تحويلها إلى تصميم للبيانات , للواجهات , للإجراءات .
4- أخيرا إنَّ تحديد المتطلبات تزود المطور و الزبون بالطرق التي تساعد على زيادة الجودة حالما يتم بناء البرمجية .













تقنيات التواصل Communication Techniques:

أن أكثر التقنيات الخاصة بالاتصال المعروفة هي الاجتماع Meeting حيث يكون هو جسر الاتصال بين الزبون والمطور إن الاجتماع الأول بين المطور والزبون يحوي على بعض الصعوبات مثل وجود حاجز للصمت الذي يجب على كل منهما تجاوزه والسعي لطرح رغبات الزبون وإمكانيات المطور .
إن أفضل الاجتماعات هي التي تحوي على (الزبون customer , المطور developer , المفاوض أو المسهل Facilitator و المسجل Recorder )
يُفضل أن يكون ناتج الاجتماع هو اقتراح خطة عمل agenda تكون رسمية كفاية لتغطي جميع النقاط المهمة وبالمقابل مرنه كفاية لتشجِّع الانسياب الحر للأفكار .

أساسيات التحليل Analysis Principles:

1- إن نطاق المعلومات (Information Domain) الخاصة بالمشكلة يجب أن يتم تمثيلها وفهمها understood
2- الوظائف التي على النظام أن ينجزها يجب أن تُعرَّف Defined
3- إن سلوك Behavior)) البرمجية يجب أن يتم تمثيله .
4- يجب على الموديلاتModels ) ) الخاصة بالمعلومات , الوظائف , والسلوك أن تجزئ بطريقة الطبقات أو الطريقة الهرمية .
5- إن عملية التحليل يجب أن تتحرك من المعلومات الأساسية إلى التفاصيل التطبيقية (Detail Essential ).

نطاق المعلومات The Information Domain:

إن كل من البيانات Data والسيطرة Event Control موجودة داخل نطاق المعلومات الخاص بالمشكلة .

إن نطاق المشكلة يحوي على ثلاثة وجهات مختلفة للـ (Data & Event) وهي :-
1- محتوى البيانات Information Content) ) :- ويمثل كيانات البيانات والسيطرة التي تحوي على مجموعة كبيرة من المعلومات التي يتم تناقلها Transformed من قبل البرمجية
2- جريان البيانات (Information Flow ) ويمثل الطريقة التي يتم فيها تغيير كل من كيانات البيانات والسيطرة خلال تحركها داخل النظام .
3- هيكل البيانات Information Structure)) ويمثل التنظيم الداخلي لمختلف عناصر البيانات والسيطرة .

بناء موديل Modeling:

عندما نقوم ببناء موديل سنحصل على فهم أفضل حول الكيان الواقعي ليتم بناؤه ,عندما يكون الكيان ملموس نستطيع بناء موديل له مشابه بالشكل والصيغة ولكنه أصغر بالحجم. أما بالنسبة للكيان غير الملموس ( البرامجيات ) فيجب أن يأخذ الموديل صيغة أخرى. إن الموديل يركز حول ما على النظام أن يعمل لا عن كيفية قيامه بذلك. ممكن أن يكون الموديل على شكل رسومي وله بعض الأجزاء النصِّية لوصف المتطلبات. إن بناء موديل خلال مرحلة تحليل المتطلبات يخدم ادوار عديدة مهمة :
1- إن الموديل يساعد المحلل على فهم معلومات , وظائف , وسلوك النظام .
2- إن الموديل يساعد كنقطة مركزية لمرحلة مراجعة المحددات Specification .
3- إن الموديل هو أساس التصميم , حيث يجهز المصمم بالتمثيلات الأساسية الخاصة بالبرامجية .

التجزئة Partitioning:

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



















Software Prototyping

في بعض الأحيان تكون هنالك حاجة لبناء الـ Prototype في بداية مرحلة التحليل لكونه الطريقة الوحيدة التي سيتم من خلالها اشتقاق المتطلبات Requirements الخاصة بالنظام بصورة فعّالة , خلافا لطرق التحليل الاعتيادية .
هنالك نوعين لنموذج الـ Prototype "Closed-ended" أو "Open-ended" . يدعى الـ closed - ended أحيانا بـ Throwaway Prototyping وباستخدام هذه الطريقة فان الـ Prototype يخدم كإيضاح قوي للمتطلبات Requirements , ومن ثم يرمى ليستخدم نموذج آخر في هندسة هذا النظام .
أما الـ Open-ended , فيدعى بـ Evolution Prototyping , ويستخدم كجزء أول من نشاط التحليل ليستمر للتصميم ومن ثم البناء , ويكون هذا الـ Prototype كأول إصدار للنظام .
قبل السعي لاختيار احد نوعي الـ Prototype يجب أن يحدد فيما إذا كان النظام قابل للبناء باستخدام هذا النموذج . لذلك هنالك عدد من عوامل الترشيح يمكن ذكرها ( Application Complexity, Application area , خصائص كل من الزبون والمشروع) .
بصورة عامة كل تطبيق يكوِّن عرض مرئي ديناميكي , يتفاعل مع المستخدم بصورة كبيرة أو يطلب خوارزميات ذات طبيعة تطورية فهو مرشح للـ Prototyping , ولكن يجب أن يكون بالمقابل متوازن مع التعقيد .

أساليب و أدوات الـ Prototyping :

1- تقنيات الجيل الرابع(Forth Generation Techniques) (4GT) :
تُجمَّع مجموعة كبيرة من التقنيات كـ استفسارات وتقارير قواعد بيانات , مولدات البرامج والتطبيقات وكذلك لغات ذات مستوى عالي غير إجرائية . وبسبب إنها تولد شفرة تنفيذية بصورة سريعة فهي مثالية للـ Rapid Prototyping .
2- مكونات البرامجيات القابلة لإعادة الاستخدام Reusable Soft Components :
وهي طريقة أخرى للـ Rapid Prototyping ولكنها تُجمِّع و لا تبني الـ Prototype باستخدام مجموعة من مكونات البرمجيات الموجودة مسبقا , مثل Data Base أو Module . في كل الأحوال يجب أن يصمم هذا المكون البرمجي ليستخدم من دون معرفة تفصيلية خاصة بعمله الداخلي .
إن هذه الطريقة ستحتاج لعملها مكتبة متطورة لتظم هذه المكونات البرمجية وتدرج ضمن كتالوج ليتم استرجاعها بسهولة
3- البيئة الخاصة بالـ Prototyping والخصائص الرسمية
Formal Specification and Prototyping Environments
هي بيئة تفاعلية تقوم بـ :
1. تمكن المحلل من كتابة لغة خصائص خاصة بالنظام بصورة تفاعلية .
2. إشراك أدوات مؤتمتة تساهم في تحويل لغة الخصائص إلى شفرة تنفيذية .
3. تمكن الزبون من استخدام هذه الشفرة التنفيذية لتنقية المتطلبات.
إن هذه البيئة حاليا تحت التطوير ...

الخصائص المحددة لمتطلبات النظام
Software Requirement Specifications

ان هذه الخصائص تنتج عند ذروة مهمة التحليل. وقد اقترح بعض الصيغ المرشحة كمحددات لمتطلبات النظام :
1- المقدمة Introduction
2- وصف المعلومات Information Description
3- وصف السلوكيات الوظائفياتFunctional & Behavioral Description
4- معايير القبول Validation Criteria
5- الملاحق والمراجع Bibliography and Appendix