Archive for the ‘هندسة البرمجيات’ Category

State Pattern

2009/05/05

أي، مرحبا
اليوم كان عندي تقديم جزء* من محاضرة في هندسة البرمجيات، كنت سأتحدث عن النموذج State و هذا ما حصل.

هنا PDF (صفحتين) و هنا مثال Java

مختصر جدا، لكن هذا رأيي (مختصر مفيد).


* استغرقت 7 دقائق تقريبا

بناء التطبيقات البرمجية

2008/10/25

( البرمجة في الموضوع هي تطبيق على فكرته لا أكثر )

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

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

بعض الأمثلة على الحالات الخاصة :

1 – تطبيق يحوي فئات و من المسموح أن تكون فئة فرعية من فئة أخرى، لتكن A,B,C ثلاث فئات و من المسموح أيضا تعديل هذه الفئات في أي وقت، لنفرض أنه تم اعتبار الفئة B ابنا للفئة A و الفئة C ابنا للفئة B ، فهل من الصحيح أن يتم قبول الفئة C كأب للفئة A عند تعديل A في وقت لاحق؟؟

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

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

لمحة لغوية:

– كلمة ابن لا تكتب إبن فالهمزة هنا وصل و ليست قطع و هذا أيضا في ابنة و اثنين و اثنتين و امرأة و ايم الله و كلمات أخرى …
– تخالف الأعداد من 3 إلى 9 و الـ 10 الغير مركبة المعدود في حال التذكير و التأنيث أما الـ 1 و الـ 2 و الـ 10 المركبة توافق المعدود.
أمثلة:
قوله تعالى في القرآن الكريم : إذ قال يوسف لأبيه يا أبتِ إني رأيت أحد عشر كوكبا و الشمس و القمر رأيتهم لي ساجدين.
و قوله أيضا : إنّ هذا أخي له تسع و تسعون نعجة و لي نعجة واحدة فقال أكفلنيها و عزّني في الخِطاب.