السلام عليكم ورحمة الله وبركاتة
ارجو ان يكون الجميع بخير تعلمنا معكم الكثير ولك هنا امر ارى ان اكثر اهمية
هى " مرحلة ماقبل التصميم " كيف ارسم مخطط برمجى للبرنامج قبل العمل ؟
لم يشرح احد "حسب علمى" كيفية التفكير فى البرنامج واستوعاب المطلوب وتحويلة الى برنامج بطريقة سهلة
ارجو من الجميع التفاعل
إبحث في الموقع عن دروس UML Diagrams أو ابحث في GOOGLE عنها
مشكور على المرور والاهتمام
ولكن ان قصرت على الطريق يكون افضل
اريد اتفاعل ويبادل الارائ لتكمل الرأى
فهذة طريق ممتازة فى الفهم
نداء الى الجميع نرجو التفاعل
مرحبا
ما تقصده اخي وهو المرحلة قبل التصميم تسمى تحليل النظام
وهي مرحلة يتم فيها تحديد متطلبات البرنامج من جداول وعلاقات والمدخلات والمخرجات وغيرها
ثم يتم رسم مخطط لها من خلال رموز خاص
وهو ضروري عندما يريد اي مبرمج ان يصنع برنامج خاص للشركة او جهة معينة حيث يجب ان يقدم تحليل للنظام والرسم
قبل ان يصمم البرنامج
واسف على الاطالة
وسلمتوا
كل ساعة متبقية من عمري هي فرصة لتطوير نفسي وتغير حياتي
سلمت اخي
ساحاول جمع بعض المعلومات واضعها لك ان شاء الله
ساحاول
شكراا
كل ساعة متبقية من عمري هي فرصة لتطوير نفسي وتغير حياتي
مراحل العمل فى البرنامج :
لعمل لبرنامج بأسلوب علمي هناك ثلاث مراحل متتالية :
أولا ً : تحليل النظام :
ثانيا : تصميم النظام :
ثالثا : التنفيذ ( أو البرمجة )
الكثير من المبرمجين يتعاملون مع أول مرحلتين ، علي أنهما تحصيل حاصل ، و أنه يمكن تجاوزهما بناء علي الفهلوة أو الخبرة – تبعا لنظرية : العلم فى الراس مش فى الكراس. :lol:
و لا أخفيكم أني كثيرا ما أفعل هذا ، و لكن لاتباع الاسلوب العلمي فى اعداد البرنامج فوائد جمة، أهمها هو التوثيق و سهولة استرجاع معلومات التصميم سواء من المبرمج نفسه أو من من يكمل العمل بعده فى نفس البرنامج
و هذا يقودني الي كلمة طالما تحدثت عنها مع إخوان لكم فى مواقع مماثلة ، و لكن دائما كانت تلقي القبول و ليس لها حظ كبير من التنفيذ ، الا و هي " التوثيـــــــــــــــق "
و هذه الكلمة كما لها علاقة بالاكسس و البرمجة ، لها علاقة كبيرة بحياتنا كلها ، لذا أستميحكم عذرا أن أعرض لها علي عجالة قبل أن أكمل
التوثيق و تناقل و حفظ الخبرات
الفرق الاساسي و الكبير (( من وجهة نظري المتواضعة )) بيننا و بين ما يسمونه دول العالم الاول من ناحية الادارة ، هو النظام الاداري الموثق المتبع فى كل شيء فى العمل ، و عليه فيتم تناقل الخبرات بصورة كبيرة و دائما هناك إكمال للمسيرة و البداية من حيث إتنهي الأخرون و ليس من الصفر
فالمؤسسات صغرت أم كبرت ، لديها نظام إداري محكم و مكتوب ، و الجميع يلتزم به و يعرف حقوقه وواجباته ، و المشاكل يتم توثيقها ليستفيد بها الغير . و لكي تتضح الصورة لما أقصد سأضرب لكم مثلين تعرضت لهما شخصيا فى العمل مع الأجانب ، و أثرا في كثيرا.
الأول كنت أعمل فى إحدي الدول العربية ، و كنت أتبع أحد الأجانب إداريا. و طلب مني القيام بعمل ما و اطلاعه علي ال Procedure أو وثيقة الاجراءات للعمل الذي سأقوم به قبل البدء.
فاستغربته ، و ظننت أني بانجاز العمل مباشرة سأبهره ، و فعلا أعددته بسرعة و عرضته عليه ، فاستغرب جدا ، و قال لي " لا يمكن أن يقوم إنجليزي يعمل فى شركة كبيرة بمثل هذا العمل قبل أن يكون هناك وثيقة مكتوبة لأسلوب العمل " و أصر و أراني وثيقة مماثلة لما يقصد ، و بعد قرائتها و اعداد مثيلة لها علي مضض ، فهمت المغزي من وراء ذلك.
هذه الوثيقة تم فيها تحديد المعايير المختلفة لأسلوب العمل ، و تحديد الفرضيات التي يم بناء الحسابات عليها ، باختصار وصف لكل ما كنت سأضطر لشرحه لأي شخص يريد فهم تفاصيل العمل الذي قمت به ، و مع الوقت وفرت علي هذه الوثيقة الكثير من الكلام عند مراجعة هذا العمل مع أشخاص مختلفين ، و عند تسليم هذا العمل لشخص آخر ، و أيضا حينما أعيد إسناد نفس العمل لي فى وقت لاحق .
أيضا أثناء مناقشة مشكلة فنية ، تصورت أن المرجع الوحيد للمناقشة هو الخبرة و المنطق ، و بعد فترة من النقاش ، أخرج الأجنبي ملفات و رجع اليها ، ثم قال عندما اتبع هذا الحل فى بلد كذا فى مشروع كذا .. كانت العيوب كذا .. و الحل الآخر .. ميزاته كذا .. و ... ، يعني وجدت خبرة شركته فى جميع أنحاء العالم منذ عشرات السنين موثقة و مكتوبة و متاحة له و لباقي مسئولي الشركة . و هنا أدركت أهمية التوثيق و تناقل الخبرات ، و عرفت أحد أهم أسباب ما قد يسمي بالتقدم الاداري و التخلف الاداري ، الا و هو التوثيق
نعود لموضوعنا
و عليه فان توثيق البرنامج من الأهمية بمكان لك و لغيرك ، فنصيحتي لكم و لنفسي الا نتجاوز المرحلتين الأوليين ، و الا نمر عليهما مرور الكرام
ما يلي هو تصورات شخصية ، من الخبرة و بعض الكتب ، و لا يجب اعتباره مرجع علمي ، و انما هي تصوراتي و خبرتي أنقلها اليكم للنقاش حولها :
أولاً تحليل النظام :
تحليل النظام هو فهمنا للنظام المطلوب انشاؤه
و لكي نصل الي هذا الفهم :
1. نفهم قواعد نظام العمل
2. مواصفات احتياجات و متطلبات العميل
3. تخطيط مبدئ لشكل واجهة الاستخدام ( من ناحية طلبات العميل )
أو بمعني آخر هي مرحلة تجميع للبيانات الخاصة بالنظام المطلوب عمل برنامج له
و يمكن تصنيف المعلومات الي :
1. المدخلات
2. المخرجات
3. النقاط الواجب مراعاتها
4. وصف عام لعمل البرنامج و مجاله أي ماذا سيغطي و ماذا لن يتطرق اليه هذا البرنامج _ و ما هي النقاط التي تؤثر فيه
5. رسم Flow Chart يمثل آلية نظام العمل
• و في نهاية هذه المرحلة يتم اعداد مستند يسمي مستند لتحليل النظام .
ثانيا تصميم النظام :
بناء علي مستند تحليل النظام تبدأ هذه المرحلة :
ملاحظة : أن هذا الكلام كله بعيدا عن التصميم و الجداول و الكائنات و الأكسس ككل ، و انما مجرد وصف و تحليل منطقي للنظام ، و لا يرد ذكر الجداول الا في المرجلة الاخيرة و هي بدء تنفيذ البرنامج ( تصميم الجداول)
باختصار ما يتم فى هذه المرحلة هو تصميم البرنامج علي الورق ، أي تصور للبرنامج و امكانياته و هيكله و الاهدافه و قواعده و الحركة داخله ، و العمل اليومي عليه ، و تفاصيل شاشاته و استعلاماته و تقاريره
أو بمعني أبسط ، توثيق ما يتخيله المبرمج عن البرنامج قبل أن يبدأ التنفيذ .
و فى هذا فائدة عظيمة لأن التوثيق مفيد سواء فى حال الرغبة فى التعديل بعد فترة أو حينما يكمل مبرمج آخر العمل في المشروع كما ذكرنا سابقا.
أحيانا أحب أن أسمي هذه المرحلة ( شخبطة البرنامج ) ، فانما هي تنفيذ البرنامج و توثيق الفكر المتبع فيه و لكن علي الورق. أو أيضا بمعني آخر ترجمة و توثيق للمعطيات التي حصل عليها المبرمج ( علي الورق )
و توجد بعض الاساليب العلمية فى التصميم مثل اسلوب علاقات الكائنات
Entity relationship diagram ERD و الذي يغني عن الخبرة فى ترجمة التحليل و التصميم الي تنفيذ ( جداول ) ، و سنعرض له فى موضوع منفصل
و أحد التصورات عن مرحلة التصميم هي كالتالي
1- الوصف العام للنظام
a. وصف ملخص للنظام
b. أهداف النظام
نقاط محددة توضح فوائد النظام و الخدمات الني يقدمها
c. هيكله
هيكل تنظيمي Flow Shart يوضح الاجزاء الرئيسية للبرنامج ( من حيث التقسيم و ليس النماذج)
أي بمعني أكثر وضوحا الاعمال الرئيسية التي يغطيها البرنامج و التفاصيل التي تندرج تحت كل منها
d. القواعد العامة لاستخدامه
وصف عام و ليس تفصيلي لشاشات العرض
وصف عام لشاشات الادخال
اللانتقال بين الحقول و الاختصارات المستخدمة
قواعد عامة لكتابة المدخلات
قواعد عامة فى النماذج
قواعد عامة فى الطباعة و التقارير
قواعد تسمية الشاشات
قواعد تسمية التقارير
أنواع الصلاحيات المختلفة فى البرنامج
2- الحركة داخل النظام
فى هذا الجزء ، سيكون هناك شكل للشاشات و التقارير ( كروكي ) بدون تنسيق مصحوب بوصف للبيانات الموجودة فى كل شاشة و بيانات الحركة منها الي الشاشات المختلفة ، و بيان الصلاحيات النختلفة للتعامل مع كل شاشة و كل جزء منها ان وجد .
3- العمل اليومي و الدوري علي البرنامج
وصف للعمل اليومي علي البرنامح و ما يقوم به كل من المستخدمين
وصف للعمل الدوري علي البرنامح ( المهام التي يقوم بها المستخدم فى نهاية كل فترة أو كل مرحلة من مراحل الاستخدام ) و ما يقوم به كل من المستخدمين ( مثل الجرد مثلا )
4- ادارة النظام
وصف للعمليات الخاصة بالادارة و النقاط الواجب مراعاتها فيها
مثل النسخ الاحتياطي ، و التوجيه علي الشبكة ، ...
و بعد انتهاء هذا الجزء ، يبدأ الجزء الثاني من المرحلة الثانية و هو ال ERD كما سبق
او تخطيها و القفز مباشرة الي تصميم– و هذا الحل سيعتمد علي الخبرة أكثر من الترتيب العلمي للعمل ، و فى حالة الدخول الي التصميم مباشرة يجب الاهتمام بتوثيقه و شرحه شاملا التصميم و العلاقات و كيفية اختيارها
ثالثا التنفيذ
و هو الذي يبدأ بتحديد الهيكل العام للجداول و العلاقات
بعض الملاحظات الخاصة بالتسميات
• يجب كون التسميات للحقول و الكائنات بالانجليزية ، و يفضا استخدام نسخة الأكسس ذات واجهة التطبيق اللإنجليزية – و هذا ليس حبا فى الانجليزية و لكن لأن العربية لها مشاكل مع كتابة أكود البيزيك .
• يجب وجود نظان ثابت للتسميات بمعني أنه علي سبيل المثال
فى البداية كنت أفضل البدايات المختصرة للتسميات مثل :
o كل النماذج تبدأ بحرف F – فيكون نموذج الموظفين اسمه FEMP أو F_EMP
o كل التقارير تبدأ ب R و الاستعلامات تبدأ ب Q
منقول من بعض المنتديات للمعلومية
مراحل العمل فى البرنامج :
لعمل لبرنامج بأسلوب علمي هناك ثلاث مراحل متتالية :
أولا ً : تحليل النظام :
ثانيا : تصميم النظام :
ثالثا : التنفيذ ( أو البرمجة )
الكثير من المبرمجين يتعاملون مع أول مرحلتين ، علي أنهما تحصيل حاصل ، و أنه يمكن تجاوزهما بناء علي الفهلوة أو الخبرة – تبعا لنظرية : العلم فى الراس مش فى الكراس. :lol:
و لا أخفيكم أني كثيرا ما أفعل هذا ، و لكن لاتباع الاسلوب العلمي فى اعداد البرنامج فوائد جمة، أهمها هو التوثيق و سهولة استرجاع معلومات التصميم سواء من المبرمج نفسه أو من من يكمل العمل بعده فى نفس البرنامج
و هذا يقودني الي كلمة طالما تحدثت عنها مع إخوان لكم فى مواقع مماثلة ، و لكن دائما كانت تلقي القبول و ليس لها حظ كبير من التنفيذ ، الا و هي " التوثيـــــــــــــــق "
و هذه الكلمة كما لها علاقة بالاكسس و البرمجة ، لها علاقة كبيرة بحياتنا كلها ، لذا أستميحكم عذرا أن أعرض لها علي عجالة قبل أن أكمل
التوثيق و تناقل و حفظ الخبرات
الفرق الاساسي و الكبير (( من وجهة نظري المتواضعة )) بيننا و بين ما يسمونه دول العالم الاول من ناحية الادارة ، هو النظام الاداري الموثق المتبع فى كل شيء فى العمل ، و عليه فيتم تناقل الخبرات بصورة كبيرة و دائما هناك إكمال للمسيرة و البداية من حيث إتنهي الأخرون و ليس من الصفر
فالمؤسسات صغرت أم كبرت ، لديها نظام إداري محكم و مكتوب ، و الجميع يلتزم به و يعرف حقوقه وواجباته ، و المشاكل يتم توثيقها ليستفيد بها الغير . و لكي تتضح الصورة لما أقصد سأضرب لكم مثلين تعرضت لهما شخصيا فى العمل مع الأجانب ، و أثرا في كثيرا.
الأول كنت أعمل فى إحدي الدول العربية ، و كنت أتبع أحد الأجانب إداريا. و طلب مني القيام بعمل ما و اطلاعه علي ال Procedure أو وثيقة الاجراءات للعمل الذي سأقوم به قبل البدء.
فاستغربته ، و ظننت أني بانجاز العمل مباشرة سأبهره ، و فعلا أعددته بسرعة و عرضته عليه ، فاستغرب جدا ، و قال لي " لا يمكن أن يقوم إنجليزي يعمل فى شركة كبيرة بمثل هذا العمل قبل أن يكون هناك وثيقة مكتوبة لأسلوب العمل " و أصر و أراني وثيقة مماثلة لما يقصد ، و بعد قرائتها و اعداد مثيلة لها علي مضض ، فهمت المغزي من وراء ذلك.
هذه الوثيقة تم فيها تحديد المعايير المختلفة لأسلوب العمل ، و تحديد الفرضيات التي يم بناء الحسابات عليها ، باختصار وصف لكل ما كنت سأضطر لشرحه لأي شخص يريد فهم تفاصيل العمل الذي قمت به ، و مع الوقت وفرت علي هذه الوثيقة الكثير من الكلام عند مراجعة هذا العمل مع أشخاص مختلفين ، و عند تسليم هذا العمل لشخص آخر ، و أيضا حينما أعيد إسناد نفس العمل لي فى وقت لاحق .
أيضا أثناء مناقشة مشكلة فنية ، تصورت أن المرجع الوحيد للمناقشة هو الخبرة و المنطق ، و بعد فترة من النقاش ، أخرج الأجنبي ملفات و رجع اليها ، ثم قال عندما اتبع هذا الحل فى بلد كذا فى مشروع كذا .. كانت العيوب كذا .. و الحل الآخر .. ميزاته كذا .. و ... ، يعني وجدت خبرة شركته فى جميع أنحاء العالم منذ عشرات السنين موثقة و مكتوبة و متاحة له و لباقي مسئولي الشركة . و هنا أدركت أهمية التوثيق و تناقل الخبرات ، و عرفت أحد أهم أسباب ما قد يسمي بالتقدم الاداري و التخلف الاداري ، الا و هو التوثيق
نعود لموضوعنا
و عليه فان توثيق البرنامج من الأهمية بمكان لك و لغيرك ، فنصيحتي لكم و لنفسي الا نتجاوز المرحلتين الأوليين ، و الا نمر عليهما مرور الكرام
ما يلي هو تصورات شخصية ، من الخبرة و بعض الكتب ، و لا يجب اعتباره مرجع علمي ، و انما هي تصوراتي و خبرتي أنقلها اليكم للنقاش حولها :
أولاً تحليل النظام :
تحليل النظام هو فهمنا للنظام المطلوب انشاؤه
و لكي نصل الي هذا الفهم :
1. نفهم قواعد نظام العمل
2. مواصفات احتياجات و متطلبات العميل
3. تخطيط مبدئ لشكل واجهة الاستخدام ( من ناحية طلبات العميل )
أو بمعني آخر هي مرحلة تجميع للبيانات الخاصة بالنظام المطلوب عمل برنامج له
و يمكن تصنيف المعلومات الي :
1. المدخلات
2. المخرجات
3. النقاط الواجب مراعاتها
4. وصف عام لعمل البرنامج و مجاله أي ماذا سيغطي و ماذا لن يتطرق اليه هذا البرنامج _ و ما هي النقاط التي تؤثر فيه
5. رسم Flow Chart يمثل آلية نظام العمل
• و في نهاية هذه المرحلة يتم اعداد مستند يسمي مستند لتحليل النظام .
ثانيا تصميم النظام :
بناء علي مستند تحليل النظام تبدأ هذه المرحلة :
ملاحظة : أن هذا الكلام كله بعيدا عن التصميم و الجداول و الكائنات و الأكسس ككل ، و انما مجرد وصف و تحليل منطقي للنظام ، و لا يرد ذكر الجداول الا في المرجلة الاخيرة و هي بدء تنفيذ البرنامج ( تصميم الجداول)
باختصار ما يتم فى هذه المرحلة هو تصميم البرنامج علي الورق ، أي تصور للبرنامج و امكانياته و هيكله و الاهدافه و قواعده و الحركة داخله ، و العمل اليومي عليه ، و تفاصيل شاشاته و استعلاماته و تقاريره
أو بمعني أبسط ، توثيق ما يتخيله المبرمج عن البرنامج قبل أن يبدأ التنفيذ .
و فى هذا فائدة عظيمة لأن التوثيق مفيد سواء فى حال الرغبة فى التعديل بعد فترة أو حينما يكمل مبرمج آخر العمل في المشروع كما ذكرنا سابقا.
أحيانا أحب أن أسمي هذه المرحلة ( شخبطة البرنامج ) ، فانما هي تنفيذ البرنامج و توثيق الفكر المتبع فيه و لكن علي الورق. أو أيضا بمعني آخر ترجمة و توثيق للمعطيات التي حصل عليها المبرمج ( علي الورق )
و توجد بعض الاساليب العلمية فى التصميم مثل اسلوب علاقات الكائنات
Entity relationship diagram ERD و الذي يغني عن الخبرة فى ترجمة التحليل و التصميم الي تنفيذ ( جداول ) ، و سنعرض له فى موضوع منفصل
و أحد التصورات عن مرحلة التصميم هي كالتالي
1- الوصف العام للنظام
a. وصف ملخص للنظام
b. أهداف النظام
نقاط محددة توضح فوائد النظام و الخدمات الني يقدمها
c. هيكله
هيكل تنظيمي Flow Shart يوضح الاجزاء الرئيسية للبرنامج ( من حيث التقسيم و ليس النماذج)
أي بمعني أكثر وضوحا الاعمال الرئيسية التي يغطيها البرنامج و التفاصيل التي تندرج تحت كل منها
d. القواعد العامة لاستخدامه
وصف عام و ليس تفصيلي لشاشات العرض
وصف عام لشاشات الادخال
اللانتقال بين الحقول و الاختصارات المستخدمة
قواعد عامة لكتابة المدخلات
قواعد عامة فى النماذج
قواعد عامة فى الطباعة و التقارير
قواعد تسمية الشاشات
قواعد تسمية التقارير
أنواع الصلاحيات المختلفة فى البرنامج
2- الحركة داخل النظام
فى هذا الجزء ، سيكون هناك شكل للشاشات و التقارير ( كروكي ) بدون تنسيق مصحوب بوصف للبيانات الموجودة فى كل شاشة و بيانات الحركة منها الي الشاشات المختلفة ، و بيان الصلاحيات النختلفة للتعامل مع كل شاشة و كل جزء منها ان وجد .
3- العمل اليومي و الدوري علي البرنامج
وصف للعمل اليومي علي البرنامح و ما يقوم به كل من المستخدمين
وصف للعمل الدوري علي البرنامح ( المهام التي يقوم بها المستخدم فى نهاية كل فترة أو كل مرحلة من مراحل الاستخدام ) و ما يقوم به كل من المستخدمين ( مثل الجرد مثلا )
4- ادارة النظام
وصف للعمليات الخاصة بالادارة و النقاط الواجب مراعاتها فيها
مثل النسخ الاحتياطي ، و التوجيه علي الشبكة ، ...
و بعد انتهاء هذا الجزء ، يبدأ الجزء الثاني من المرحلة الثانية و هو ال ERD كما سبق
او تخطيها و القفز مباشرة الي تصميم– و هذا الحل سيعتمد علي الخبرة أكثر من الترتيب العلمي للعمل ، و فى حالة الدخول الي التصميم مباشرة يجب الاهتمام بتوثيقه و شرحه شاملا التصميم و العلاقات و كيفية اختيارها
ثالثا التنفيذ
و هو الذي يبدأ بتحديد الهيكل العام للجداول و العلاقات
بعض الملاحظات الخاصة بالتسميات
• يجب كون التسميات للحقول و الكائنات بالانجليزية ، و يفضا استخدام نسخة الأكسس ذات واجهة التطبيق اللإنجليزية – و هذا ليس حبا فى الانجليزية و لكن لأن العربية لها مشاكل مع كتابة أكود البيزيك .
• يجب وجود نظان ثابت للتسميات بمعني أنه علي سبيل المثال
فى البداية كنت أفضل البدايات المختصرة للتسميات مثل :
o كل النماذج تبدأ بحرف F – فيكون نموذج الموظفين اسمه FEMP أو F_EMP
o كل التقارير تبدأ ب R و الاستعلامات تبدأ ب Q
منقول من بعض المنتديات للمعلومية
كل ساعة متبقية من عمري هي فرصة لتطوير نفسي وتغير حياتي
سابحث عن رابط الموضوع السابق
حفاظا للحقوق
حيث انه موجود على جهازي وساحاول ايجاد الرابط الخاص به
كل ساعة متبقية من عمري هي فرصة لتطوير نفسي وتغير حياتي
اخى ماكس اشكرك جدا على هذا المجهود
ولكن انا اريد معرفة كيف ارسم Flow Shart او UML Diagrams
اى مثال علية وكيف اقوم برسمة ارجو المساعدة الامر مهم للجميع
ان تحليل النظام مهم جدا لكل واحد منا
واكرر شكرى لك
مرحبا اخي ehab_m27
ساقوم ان شاء الله بجمع ووضع الصور والرموز التي تستخدم في التحليل والتي تسمى
داتا فلو
مشكور اخي khaledmedra على الرد الجميل
وسلمتو
كل ساعة متبقية من عمري هي فرصة لتطوير نفسي وتغير حياتي
تفضل اخي
هذه بعض الروابط التي يمكن الاستفاده منها الرسم
http://www.smartdraw.com/tutorials/software-dfd/dfd.htm
http://www.research.ibm.com/journal/sj/381/millet.html
http://www.laynetworks.com/use%20case%20vs...w%20diagram.htm
http://www.getahead-direct.com/gwbadfd.htm
وهذه بعض المخططات
http://www.smartdraw.com/examples/software-dfd/
هذه مواقع انجليزية حيث لم اجد مواقع عربية تتكلم على هذه الرموز
وللتوسع قم بعمل بحث على جملة DATA FLOW DIAGRAMS
في محرك البحث
وجاري البحث والتجميع اذا امكن
وشكر
كل ساعة متبقية من عمري هي فرصة لتطوير نفسي وتغير حياتي
هذا الموضوع مغلق.