دوره فى هندسه البرمجيات

بسم الله الرحمن الرحيم

الدرس الأول: ماذا نعني بهندسة البرمجيات؟

أهداف الدرس الأول:
سوف نحاول خلال هذا الدرس الإجابة على هذه الأسئلة:

ما هي هندسة البرمجيات؟
من يشارك بها؟
ما هي مكونات النظم البرمجية؟
وكيف يتم بنائها؟

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

المرجع :

1- Shari Pfleeger, "Software Engineering - Theory and Practice", 2nd Edition

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

وبنفس الفكرة يمكن النظر إلى علم الحوسبة computer science حيث يكون تركيزنا على الحواسيب ولغات البرمجة لدرستها وتطويرها في حد ذاتها.
أو يمكن النظر إليها والتعامل بها على أنها أدوات نستخدمها عند تصميم وتطوير حل لمشكلة ما تواجهنا أو الآخرين.

مهندس البرمجيات Software Engineer يعتبر أن الكمبيوتر هو أداة لحل المشاكل problem-solving tool.
وعليه أن يستخدم معلوماته حول الحاسوب وعلم الحوسبة للمساعدة في حل المشكلة التي يطلب منه إيجاد حل لها.

دوره فى هندسه البرمجيات Img1_1

ولكن ومن المهم أن نتذكر أن عملية كتابة البرامج تعد فن Art بقدر ما هي علم، لماذا؟

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

أي أن، هندسة البرمجيات تعنى بتصميم وتطوير برامج ذات جودة عالية.

من يشارك في هذه العملية؟
المشاركون في عملية صناعة البرنامج، عادة ما يندرجون تحت ثلاث مجموعات:

الزبون Customer: وهو الشركة (أو الشخص) الممولة لمشر وع تطوير البرنامج المطلوب

المستخدم User: الشخص (أو مجموعة الاشخاص ) الذي سوف يقوم فعلا باستعمال البرنامج، والتعامل معه مباشرة.

المطور Developer: وهو الشركة (أو الشخص) الذي سوف يقوم بتطوير البرنامج لصالح الزبون.

الشكل التالي يظهر العلاقة بين الفئات الثلاثة السابقة

دوره فى هندسه البرمجيات Img1_2

مكونات النظام
مشاريعنا التي نطورها لن تعمل في الفراغ، فعليها أن تتفاعل مع مستخدمين، أجهزة ومعدات متنوعة، نظم تشغيل وبرامج وملفات وقواعد بيانات .... إلخ و ربما حتى أنظمة حواسيب آخرى. لهذا يجب تعريف حدود النظام ومكوناته جيدا. أي يجب تعريف ما الذي يشتمل عليه النظام وما الذي لا يشتمل عليه.

أي نظام هو عبارة عن مجموعة من الكائنات objects والنشاطات activities بالإضافة إلى وصف للعلاقات التي تربط تلك الكائنات والنشاطات معا. مع تعريف قائمة المدخلات المطلوبة والخطوات المتبعة والمخرجات الناتجة لكل نشاط.

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

2. العلاقات وحدود النظام Relationships and System Boundary
بعد تعريف الكائنات والنشاطات جيدا، يمكن أن نربط بين كل كائن والنشاطات المتعلقة به بدقة. تعريف الكائن يتضمن الموقع الذي سوف ينشأ به(نعض العناصر يمكن أن تكون موجودة بملف سبق انشاءه، والبعض قد يتم انشاءه خلال حدث ما)، والهدف من انشاءه(بعض الكائنات تستخدم من قبل نشاط واحد فقط والبعض يمكن أن يستعمل من قبل نظم آخرى كمدخلات Input) , لذا يمكن أن نعتبر أن لنظامنا حدود boundary بعض الكائنات بمكن أن تعبر هذه الحدود إلى داخل النظام، والبعض الآخر هي مخرجات من نظامنا ويمكن أن ترحل إلى نظم آخرى.

بهذا يمكن أن نعرف النظام A System على أنه تجمع من:
· مجموعة من الكائنات entities.
· مجموعة من الانشطة activities.
· وصف للعلاقات بين الكائنات والانشطة Relationship.
· تعريف لحدود النظام boundary.

كيف نبي نظام؟
إذا طلب منا عميل تطوير نظام (برنامج) له، لحل مشكلة معينة تواجهه في عمله. فمثلا يحتاج نظام حماية لشركته، أو نظام صرف آلي لبنك، أو ممكن أن يكون صاحب مكتبة أو متجر و يريد تغير نظام البيع و الشراء أو العرض ليتم بشكل آلي. علينا اتباع الخطوات التالية لبناء هذا النظام:
1. عقد اجتماع مع العميل لتحديد متطلباته، هذه المتطلبات تشمل وصف النظام بجميع مكوناته التي شرحنا.
2. وضع تصميم عام للنظام يحقق المتطلبات التي حددها العميل، وعرضه على العميل ليوضح له الشكل الذي سيظهر عليه النظام عند الانتهاء، و ومراجعته معه لأخذ موافقته عليه.
3. بعد موافقة العميل على التصميم يتم العمل على وضع التصاميم التفصيلية لأجزاء المشروع.
4. كتابة البرنامج
5. اختباره، واعادة مراجعة المتطلبات التي وضعها العميل للتأكد من تحققها في البرنامج.
6. تسليم النظام إلى العميل.
7. بعد تسلم العميل للنظام قد تظهر بعض المشاكل أو الاخطاء التي لم تظهر خلال عملية الاختبار، والتي تجب على المطور اصلاحها فيما يعرف بصيانة النظام.

خلال الدروس التالية من الدورة سنتعرف على كل خطوة من هذه الخطوات وكيف تتم بشكل مبسط، وسوف نخوض في مزيد من التفاصيل في دروس لاحقة بإذن الله.

•·.·´¯`·.·• (نهاية الدرس الأول) •·.·´¯`·.·•

بسم الله الرحمن الرحيم

الدرس الثاني: دورة حياة تطوير المشروع

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

مقدمة:
عملية بناء أي منتج تمر بعدة مراحل يطلق عليها عادة "دورة الحياة" Life Cycle، ومما تعلمنا في الدرس السابق فإن دروة حياة تطوير أي نظام برمجي Software development life cycle تتضمن المراحل التالية:
1. تحديد وتعريف المتطلبات Requirements analysis and definition
2. تصميم النظام System design
3. تصميم البرنامج Program design
4. كتابة البرنامج (تطويره) Program implementation
5. أختبار وحدات البرنامج Unit testing
6. أختبار النظام system testing
7. تسليم النظام system delivery
8. الصيانة maintenance

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

أنماط دورة الحياة Lifecycle Models:

النموذج الانحداري Waterfall Model
في هذا النموذج تسير دورة الحياة بشكل تدريجي بدأ من الخطوة (1) وحتى الخطوة ( Cool

، وكما يظهر بالشكل (1) فإن كل مرحلة تبدأ بعد الأنتهاء من المرحلة التي تسبقها مباشرة.

دوره فى هندسه البرمجيات Img2_1

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

باختصار،النموذج الانحداري سهل الفهم و بسيط في إدارته. لكن مميزاته تبدأ في التداعي بمجرد أن يزداد تعقيد المشروع.

التطوير على مراحل Phased Development
حسب النموذج الانحداري فإنه يجب على المطورين إنهاء مرحلة تحليل المشروع بشكل تام قبل البدأ في التصميم، وكما وضحنا فإن هذه المرحلة قد تتطلب وقت طويل في بعض المشاريع وقد تمر عدة سنوات قبل أن يرى البرنامج النهائي النور، ولكن هل يمكن لسوق العمل الانتظار كل هذا الوقت؟!

الاجابة بالطبع لا.
لذا كان لابد من ايجاد طرق آخرى لتقليل زمن تطوير المشروع Cycle time. أحد هذه الطرق هي التطوير على مراحل Phased Development حيث يتم تطوير النظام على عدة مراحل، بتقديم إصدار من البرنامج به بعض الوظائف للعميل والعمل على تطوير الاصدار الاحق الذي سوف يقدم له بقية الوظائف.

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

دوره فى هندسه البرمجيات Img2_2

· النموذج التكراري Iterative model
هذه المرة يتم تسليم برنامج بكامل الوظائف من أول مرة، ولكن يتم تعديل وتغيير بعض تلك الوظائف مع كل إصدار من البرنامج.

دوره فى هندسه البرمجيات Img2_3

من مميزات هذا الأسلوب أنه يمكن المطورين من الحصول على ملاحظات وتقييم الزبون مبكرا و بصورة منتظمة، ورصد الصعوبات المحتملة قبل التمادي بعيدا في عمليات التطوير.كم أنه يمّكن من اكتشاف مدى حجم و تعقيد العمل مبكرا.

النموذج اللولبي Spiral Model
وهو شبيه لدرجة كبيرة إلى النموذج التزايدي والتكراري، ولكن فيه يتم دمج فعاليات التطوير مع إدارة المخاطر risk من إجل التحكم بها وتقليلها.
يبدأ النموذج اللولبي بمتطلبات العميل مع خطة العمل المبدئية (الميزانية، قيود النظام، والبدائل المتاحة). ثم يتقدم خطوة إلى الامام بتقدير المخاطر وتمثيل البدائل المتاحة قبل تقديم ما يعرف بـ "وثيقة العمليات" Concept of Operations التي تصف وبشكل عام (بدون الدخول في التفاصيل) كيف يجب على النظام أن يعمل. بعدها يتم تحديد وتدقيق المتطلبات للتأكد من أنها تامة ودقيقة إلى أقصى حد ممكن.
بذلك تكون وثيقة العمليات هي المنتج من الطور الأول، و المتطلبات هي المنتج الاساسي من الطور الثاني. وفي الطور الثالث تتم عملية التصميم، أما الاختبار فيتم خلال الطور الرابع.
في كل طور أو مرحلة يساعد تحليل المخاطر على تقدير البدائل المختلفة في ضوء متطلبات وقيود النظام، وتساعد النمذجة على التحقق من ملائمة أي بديل قبل أعتماده.

دوره فى هندسه البرمجيات Img2_4

•·.·´¯`·.·• (نهاية الدرس الثاني) •·.·´¯`·.·•

بسم الله الرحمن الرحيم

الدرس الثالث: دراسة المتطلبات

في هذا الدرس سوف نبدأ في دراسة أول (ولعلها أهم) خطوة في تطوير البرامج وهي تحديد متطلبات النظام Capturing the requirements.

الهدف من تحديد المتطلبات هو فهم ما يتوقعه العميل والمستخدم من النظام (ما الذي يمكن للنظام أداؤه وما لا يمكنه أداؤه).فقد يكون النظام المطلوب تصميمه بديل لنظام أو لطريقة مستخدمة لأداء مهمة محددة، أو ممكن أن يكون نظام جديد يقدم خدمة جديدة لم يسبق تقديمها من قبل. فلكل نظام برمجي وظيفة معينة، تحدد بما يمكن له أن يقوم به من أجل أداء تلك الوظيفة.

المتطلبات: هي تعريف لشكل النظام أو وصف لما يستطيع هذا النظام أن يقوم به لأداء وظيفته التي سيصمم من أجلها.

خطوات تحديد المتطلبات:

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

طرح الأسئلة على العميل، ومن المفيد أحيانا أن نطرح نفس السؤال ولكن بأسلوب مختلف أكثر من مرة فهذا يساعدنا على التأكد من أننا نفهم ما يقصده العميل بالتحديد.

عرض نظم مشابه للنظام المطلوب سبق تصميمها من قبل.

تصميم وعرض نماذج لأجزاء من النظام المطلوب أو للنظام بالكامل.

تقسم المتطلبات إلى عدة عناصر تشمل:

البيئة المحيطة بالنظام Physical Environment

وجهات الاستخدام Interfaces

المستخدمين وإمكاناتهم Users and human factors

وظائف النظام Functionality

التوثيق ****************************************************************ation

البيانات Data

المصادر Resources

الأمن Security

ضمان الجودة Quality Assurance

ويجب التأكد من أن نناقش جميع هذه العناصر

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

أولا تمكن المطورين من شرح فهمهم للطريقة التي يود المستخدمين أن يعمل بها النظام.

ثانيا توضح للمصممين ماهية الوظائف والخصائص التي سيمتاز بها النظام,

وثالثا: توضح المتطلبات لفريق الاختبار ما الذي يجب إثباته لإقناع الزبون أن النظام الذي تم تطويره هو ما سبق أن طلبه بالضبط.

لذلك ولضمان أن كلا من المطورين والزبون متفاهمون تماما على ما يجب القيام به، فإن المتطلبات المسجلة حتى هذه الخطوة يجب أن تكون لها الصفات التالية:
1. أن تكون صحيحة Correct وخالية من الأخطاء.
2. أن تكون ثابتة consistent بمعنى أن لا يكون هناك أي تعارض بين متطلب وآخر.
3. أن تكون تامة Complete يجب أن يتم ذكر جميع الحالات المحتملة للنظام، المدخلات، المخرجات المتوقعة منه، ...الخ.
4. أن تكون واقعية realistic بمعنى أن تكون قابلة للتطبيق في الواقع.
5. أن تكون متعلقة بأمور ضرورة للعميل، ويتطلبها النظام.
6. أن يكون من الممكن التحقق منها verifiable
7. أن تكون قابلة للتتبع traceable
يطلق على هذه الوثائق "وثائق تعريف المتطلبات" Requirement Definition ****************************************************************

ثالثا: إعادة تسجيل المتطلبات بشكل رياضي mathematical ليقوم المصممون بتحويل تلك المتطلبات إلى تصميم جيد للنظام في مرحلة التصميم.
لسنوات عديدة كان يتم الاكتفاء بوثيقة تعريف المتطلبات (التي تحدثنا عنها قبل قليل) والتي تكتب باستعمال اللغة الطبيعية (لغة البشر) لوصف وتسجيل متطلبات النظم بحيث يمكن للعميل أن يفهم كل كلمة موجودة بها، إلا أن ذلك يسبب العديد من المشاكل والتي يعود سببها في أغلب الأحيان إلى سوء تفسير بعض التعبيرات للمستخدمين من قبل المصمم أو العكس، فعلى سبيل المثال قد يطلق المستخدم على النظام التعبير (متوقف عن العمل) إذا كان النظام مشغول بعملية تسجيل احتياطي backup باعتبار أن لا يستجيب لأوامر المستخدم في هذه الحالة، بينما يعتبر المصمم أن النظام في هذه الحالة (مستمر في العمل) لأنه يقوم بمهمة أساسية!
لذا فأن الاعتماد على اللغة البشرية بشكل تام قد يؤدي إلى أخطاء كثيرة عند تصميم النظام، وينتج عنها نظام لا يقبله العميل لأنه لا يلبي متطلباته التي حددها من قبل، لذلك يتم كتابة نوع ثاني من الوثائق تسمى "وثائق مواصفات المتطلبات" Requirement specification **************************************************************** وهي تكتب باستعمال وسائل وطرق خاصة ابتكرها مهندسو البرمجيات لكتابة المتطلبات باسلوب تقني بحت. منها على سبيل المثال: لغة النمذجة الموحدة UML Unified Modeling Language و هي لغة نمذجة رسومية تقدم لنا صيغة لوصف العناصر الرئيسية للنظم البرمجية.
الشكل التالي يعرض مثال على استعمال UML

دوره فى هندسه البرمجيات Img3_1

رابعا: التثبت والتحقق من المتطلبات التي تم تسجليها في كلا من وثيقة تعريف المتطلبات (والتي تقدم للعميل) ووثيقة مواصفات المتطلبات (والتي تقدم للمصمم) للتأكد من صحتهما وشموليتهما وأن كلا منهما لا تعارض الثانية في أي نقطة، وإلا فإن النتيجة سوف تكون نظام لا يلبي طلبات العميل!.

•·.·´¯`·.·• (نهاية الدرس الثالث) •·.·´¯`·.·•

بسم الله الرحمن الرحيم

الدرس الرابع: تصميم النظام

نكمل مع خطوات بناء النظام، وهذه المرة سوف نتحدث عن خطوة "تصميم النظام"

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

عند الانتهاء من خطوة تحديد المتطلبات، فإننا ننتهي بوثيقتين (كما ذكرنا في الدرس السابق) الأولى هي (وثيقة تعريف المتطلبات) ويتم تقديمها للعميل والثانية (وثيقة مواصفات المتطلبات) ويتم تقديمها للمصمم.

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

أولا: يتم إنتاج التصميم التصوري conceptual design والذي يوضح للعميل ما الذي سيقوم به النظام بالتحديد.
وفي حال موافقة العميل على هذا النظام، يتم الانتقال للخطوة التالية.

ثانيا: تحويل التصميم التصوري إلى وثيقة بها تفاصيل أكثر عن التصميم يطلق عليها اسم التصميم التقني technical design والذي يجب أن يظهر للمطور ما هي المعدات والبرمجيات اللازمة لبناء النظام.

أحيانا يتطلب الأمر للعودة إلى الخطوة الأولى (التصميم التصوري) والتعديل عليه، لذا فأنها عملية تكرارية حتى الوصول إلى التصميم الذي يرضي العميل ويمكن تطبيقه على أرض الواقع في ظل الإمكانيات المتاحة للمطورين.

دوره فى هندسه البرمجيات Img4_1

التصميم التصوري conceptual design:
يركز هذا التصميم على وظائف النظام functions ويكتب بلغة يمكن للعميل أن يفهمها (لغة البشر) ليجيب عن أسئلة العميل حول ماذا (WHAT) يعمل النظام. ويجب أن يكون خالي تماما من أي تفاصيل برمجية أو فنية. والاهم أن يحقق كل المتطلبات التي تم تحديدها سابقا.

التصميم التقني technical design
هذا التصميم سوف يتم تقديمه إلى مطوري النظام ليقوموا هم بتحويله إلى النظام المطلوب، لذا يجب أن يقدم هذا التصميم إجابة شافية لأسئلة المطور عن كيفية (HOW) تطوير النظام. ولمنع إلى تضارب في المفاهيم فإن هذا التصميم عادة ما يكتب باستعمال تعبيرات وأساليب تقنية.

•·.·´¯`·.·• (نهاية الدرس الرابع) •·.·´¯`·.·•

بسم الله الرحمن الرحيم

الدرس الخامس: كتابة البرنامج واختباره

أهداف الدرس:

هذا الدرس لن يعلمك لغة برمجة لتكتب بها البرامج، ولكن الهدف منه التعرف على:

القواعد الصحيحة لكتابة البرامج

خطة الاختبار وأنواع الاختبارات

الجزء الأول: كتابة البرامج:

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

س: لماذا علينا إتباع هذه القواعد؟

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

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

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

بعض قواعد البرمجة Programming Guidelines

هياكل التحكم Control Structures

يقصد بها تلك الهياكل التي تتحكم في مسار عمل البرنامج (مثل Goto ، if- else)، وأثناء كتابة هذه الهياكل علنا أن نحاول أن نجعلها واضحة وسهلة التتبع، وخالية من القفزات الواسعة قدر الإمكان. انظر لهذا المثال:

benefit = minimum;

if (age < 75) goto A;

benefit = maximum;

goto C;

if (age < 65) goto B;

if (age < 55) goto C;

A: if (age < 65) goto B;

benefit = benefit * 1.5 + bonus;

goto C;

B: if (age < 55) goto C;

benefit = benefit * 1.5;

C: next statement

نفس الكود يمكن كتابته على هذا النحو:

if (age < 55) benefit = minimum;

else if (age < 65) benefit = minimum + bonus;

else if (age < 75) benefit = minimum * 1.5 +bonus;

else benefit = maximum

عالم البرمجة هناك قاعدة تقول أن العمومية ميزة generality is a virtue، لذلك حاول دائما أن تجعل شفراتك البرمجة عامة، لتتمكن من إعادة استعمالها في بقية برامجك بأقل قدر ممكن من التعديل، ولكن حاذر من التمادي في ذلك!

لا تستخدم أبدا أسماء لا معنى لها لمتغيرات أو بارمترات برنامجك ( ينصح بمراجعة هذا الدرس "}

بسم الله الرحمن الرحيم

-=-=-=-=-=-=-=-

كثيرٌ منّا يبحث عن بعض الـcodes على الانترنت، وقليل منّا من يقرأ ويفهم ما يجده بسرعة وسهولة، نظراً لكثرة المتغيرات في الـcode وتداخل أسماءها!
بعد قراءتك لهذا الدرس، وتعرفك على القواعد والملاحظات التي يجب أن تأخذ بعين الاعتبار حينما تختار أسماءاً للمتغيرات في برنامجك، ستكتب برامجك بطريقة احترافية، وتقرأ وتفهم برامج المحترفين بسهولة وسرعة إن شاء الله دوره فى هندسه البرمجيات Smile

عند كتابتك للبرنامج، لابد من ملاحظة القاعدات التالية عند تسميّة المتغيرات:

أن يبدأ اسم كل متغير بأي حرف من حروف الأبجدية، أو رمز الـ underscore فقط من بين الرموز، ولا يمكنك بدء الاسم برقم!
بعد الحرف الأول يمكنك استخدام أحرف أو أرقام أو حتى underscore .
يمنع استخدام الكلمات المحجوزة للغة التي تبرمج بها Keywords كأسماء لمتغيراتك.
إذا استخدمت تسميّة غير صحيحة، سيعطيك المفسّر compiler خطأ compile-time error.
دوره فى هندسه البرمجيات Naming1

أما الملاحظات التي لابد لك من معرفتها هي:

لديك الحرية المطلقة بجعل اسم المتغير بحروف كبيرة uppercase، ولكن مظهر برنامجك لن يكون مريحاً.
يفضل استخدام هذه الطريقة فقط عند اختيار أسماء للثوابت CONSTs في برنامجك!
لديك الحرية المطلقة بأن تبدأ اسم المتغير بـunderscore، ولكن هذه الطريقة لا يستخدمها المحترفين وإنما يستخدمها مبرمجوا الطراز القديم.
لديك الحرية المطلقة بجعل اسماء المتغيرات عبارة عن اختصارات مفهومة بالنسبة لك كمبرمج، ولكن هذه الطريقة لن تجعل برنامجك سهل القراءة من قبل مبرمج آخر!
لجعل مظهر برنامجك أكثر احترافية، في الاسماء المركبة من أكثر من كلمة استخدم PascalCasing naming or camelCasing naming كما سيأتي شرحه.

-=-=-=-=-=-=-=-

PascalCasing Naming Convention:

لاستخدام PascalCasing Naming Convention، اجعل أول حرف من كل كلمة بشكل capital، وباقي أحرف الكلمة small. استخدم هذا الطريقة في تسمية كلاً من:

الفئات classes.
الطرق methods أو الدوال functions.
الخصائص properties.
الكائنات الجديدة enums.
الواجهات interfaces.
الثوابت read only and constant.
namespaces or packages.
أمثلة على ذلك على ذلك:

[C]
void InitilaizeData ( ); /* multiple-word name*/

[Visual Basic]
Public Class FileStream /* multiple-word name*/
Public Class Button
Public Class String

[C#]
public class FileStream /* multiple-word name*/
public class Button
public class String

-=-=-=-=-=-=-=-

camelCasing Naming Convention:

لاستخدام camelCasing Naming Convention:، اجعل أول حرف من كل كلمة بشكل capital باستثناء الكلمة الأولى، استخدم هذه الطريقة في تسمية:

المتغيرات variables.
المعاملات parameters or arguments.
أمثلة على ذلك:

[C]
int loopCountMax; /* multiple-word name*/
char flower;

[Visual Basic]
GetType(typeName As String)As Type /* multiple-word name*/
Format(format As String, args() As object)As String

[C#]
Type GetType(string typeName) /* multiple-word name*/
string Format(string format, object[] args)

ملاحظة:
سمّيت هذه الطريقة بـcamelCasing لأن ظهور حرف كبير في وسط الاسم المركب يشبه نتوء السنام في الجمل:

دوره فى هندسه البرمجيات CamelCasing

وفي نهاية درسنا، تذكر أن اسم المتغير يفضّل أن يكون اسماً له معنى مختص بعمل المتغير في البرنامج، فمثلاً لو مثّل المتغيّر عداداً في البرنامج، يفضّل أن تسميه counter بدلاً من i أو j. ولو كنت تكتب class لبرنامج مختص بشركتك، يفضل أن تكتب اسم الشركة Computer4Arab مثلاً بدلاً من أن تكتب MyCompany.
وبالنسبة لصيغة الجمع او المفرد، فإن ذلك لا يشكل أي فارق ويرجع لحس المبرمج، ولكن يفضل استخدام صيغة الجمع فقط مع namespaces or packeges.

للمزيد، يمكنك قراءة مرشد تعليمات التسميات Naming Guidelines في SDK Help ****************************************************************ation، أو من هنا:

http://msdn.microsoft.com/library/de...guidelines.asp

أرجو أن يكون درسي البسيط قد أضاف إليك الجديد، والسلام عليكم دوره فى هندسه البرمجيات Smile

-=-=-=-=-=-=-=-

بسم الله الرحمن الرحيم

الدرس الخامس: كتابة البرنامج واختباره

الجزء الثاني: اختبار البرامج:

وصلنا الآن إلى آخر مرحلة في تطوير النظام، وهي اختبار البرنامج للتأكد من أنه يعمل على النحو الذي يتوقعه الزبون.

قبل تسليم النظام النهائي إلى الزبون تجرى عليه الكثير من الاختبارات، بعضها يعتمد على ما الذي يتم اختباره مثلا:

(أحد مكونات البرنامج - مجموعة من المكونات - جزء من النظام - النظام بالكامل)

والبعض الأخر يعتمد على ما الذي نريد معرفته من هذه الاختبارات، مثلا:

هل يعمل النظام وفقا لما ورد في المتطلبات؟

هل يعمل النظام وفقا لما ورد في التصميم؟

هل يعمل النظام كما يتوقعه الزبون منه؟

مراحل الاختبار:

عند العمل على اختبار نظام من الحجم الكبير، فإن عملية الاختبار تتم على عدة مراحل موجزها في ما يلي:

اختبار المكون Module Testing أو component Testing

أول مراحل اختبار النظم، هي اختبار كل مكون على حدى بمعزل عن بقية مكونات النظام، للتأكد من عمله على النحو المتوقع منه. باختبار المعلومات المتحصل عليها (output) منه بعد إمداده بالبيانات اللازمة له (input).

اختبار التكامل Integration Testing

بعد اختبار كل مكونات النظام والتأكد من سلامة تصميمها، يجب أن نتأكد من أنها ستعمل معا بشكل صحيح وأنه لا يوجد تضارب بين بعضها البعض بحيث أن المعلومات المنتقلة بين هذه المكونات تصل بالهيئة المتوقعة لها. وهذا هو الهدف من اختبار التكامل.

اختبار الوظيفة Function Testing

ويقصد به اختبار النظام بعد تجميع كل مكوناته للتأكد من أنه يؤدي الوظيفة التي يتعين عليه القيام بها، والموضحة في وثائق متطلبات النظام. عندما يجتاز النظام هذا الاختبار يمكننا اعتبار هذا النظام على أنه نظام عامل Functioning System

اختبار الأداء Performance Testing

في هذه الخطوة يتم اختبار أداء البرنامج في بيئة عمل الزبون للتأكد من أن النظام متوافق مع بقية المتطلبات. عند اجتياز النظام لهذا الاختبار يتم التصديق على النظام validated system وبهذا فإننا نعتبر أن النظام أصبح جاهز حسب مفهومنا لما طلبه الزبون.

اختبار القبول Acceptance Test

يتم إجراء هذا الاختبار للتأكد من أن النظام المحقق موافق لما توقعه الزبون، وبعدها يعد النظام مقبول عند المستخدم والزبون Accepted system

اختبار التثبيت Installation Test

الاختبار الأخير يتم فيه تثبيت النظام في بيئة العمل الخاصة به والتأكد من أنه يعمل كما هو مطلوب منه.

الشكل التالي يوضح خطوات تطبيق عملية اختبار النظام، والتي يحسن تطبيقها على اي نظام مهما كان حجمه للتأكد من أنه سيؤدي المهمة المطلوبة منه.

دوره فى هندسه البرمجيات Les5

تسلم ايدك