أدوات تصميم البرامج
| English | العربية |
|---|---|
| structure chart/ˈstrʌktʃə tʃɑːt/ | مخطط البنية |
| state-transition diagram/steɪt trænˈsɪʃn ˈdaɪəɡræm/ | مخطط انتقال الحالة |
| pseudocode/ˈsuːdəʊkəʊd/ | الكود الوهمي |
| decomposition/ˌdiːkɒmpəˈzɪʃn/ | تحلل |
| subroutines/ˈsʌbruːtiːnz/ | إجراءات جزئية |
| parameters/pəˈræmɪtəz/ | المعاملات |
| top-down design/tɒp daʊn dɪˈzaɪn/ | التصميم من الأعلى إلى الأسفل |
| states/steɪts/ | تُصيغ |
العام الذي أصبح فيه البرمجيات هندسة
- في أكتوبر 1968، اجتمع خمسون من أبرز مبرمجي العالم في غارمش بألمانيا لمناقشة أسباب فشل البرامج الكبيرة: التأخير، تجاوز الميزانية، عدم الموثوقية. صاغوا مصطلح لما كان ناقصاً: هندسة البرمجيات.
- كانت الشكوى بسيطة. البناؤون يرسمون قبل البناء. المهندس يحسب قبل القطع. كان المبرمجون يكتبون الكود قبل أن يقوم أحد برسم ما يجب أن يكون عليه البرنامج.
- الرسومات التي نتجت عن ذلك العقد هي التي ستستخدمها في مرحلة التصميم: مخطط الهيكلية، الذي يوضح كيف يتم تقسيم البرنامج إلى أجزاء، ومخطط انتقال الحالة، الذي يوضح سلوكه.
- هذه الدرس حول كيفية قراءتها، وكيفية بنائها، وكيفية تحويل مخطط الهيكلية إلى كود وهمي.
ما يقرره التصميم
- التحليل قال ماذا يجب أن يفعل البرنامج. التصميم يقرر كيف: هياكل البيانات، الخوارزميات، الوحدات والواجهة.
- تنتج مرحلة التصميم رسومات يمكن للمبرمج البرمجة منها: مخطط انسيابي لمنطق خوارزمية واحدة، الكود الوهمي لنفس الشيء نصياً، مخطط للهيكلية للوحدات، ومخطط لانتقال الحالات للسلوك.
- كل أداة تجيب على سؤال مختلف، ويطلب الامتحان أيهما يناسب.
منطق خوارزمية واحدة، مرسوم قبل البرمجة
معمل عملية البرمجيات
صنّف أمثلة التطوير حسب المرحلة أو الأداة التي تنتمي إليها.
مخطط البنية
- يُظهر مخطط الهيكلية التقسيم الهرمي للبرنامج إلى وحدات، والفرعيات، والمعاملات المارة بينها. هذا التصميم من الأعلى للأسفل يقسم مشكلة كبيرة واحدة إلى مشاكل فرعية أصغر، تصبح كل منها وحدة.
- كل وحدة عبارة عن مستطيل. خط يربط بين المُدعِي، بالأعلى، والوحدة التي يستدعيها، بالأسفل. الوحدات على نفس المستوى تُستدعى من اليسار إلى اليمين.
- أسهم صغيرة بجانب الخطوط تحمل البيانات: معاملة تُمرر لأسفل داخل الوحدة، نتيجة تُعاد أعلى إلى المُدعِي. معين يحدد اختياراً، وسهم منحني يحدد حلقة تكرار.
الهرمية على الخطوط، البيانات على الأسهم
يوضح المخطط الهيكلي:
المخطط الهيكلي هو التفصيل الهرمي إلى وحدات، حيث المعاملات للأسفل والنتائج للأعلى.
تكسير المشكلة إلى وحدات من الأعلى إلى الأسفل يسمى:
التصميم من الأعلى إلى الأسفل ينتج حلاً وظيفياً.
مثال محلول: قراءة التوقيعات من المخطط
CalculatePay
/ | \
GetEmployee CalculateBonus CalculateTax
returns: takes: sales takes: gross
employeeID returns: bonus returns: tax
GetEmployeeلا تستقبل شيئاً وترجع معرف موظف:FUNCTION GetEmployee() RETURNS INTEGER.CalculateBonusتأخذ قيمة المبيعات لأسفل وتبعث العمولة للأعلى:FUNCTION CalculateBonus(Sales : REAL) RETURNS REAL.CalculateTaxتأخذ الأجر الإجمالي وترجع الضريبة. كل سهم على المخطط هو معاملة أو قيمة مرجعة في التوقيع؛ توقيع يحتوي على معاملة لا يظهرها المخطط خاطئ.
في المخطط الهيكلي، يشير سهم صغير يتجه لأسفل من الداعية إلى الوحدة ليدل على ____ يتم تمريره إليها.
الأسهم المتجهة لأسفل هي معاملات تدخل؛ والأسهم المتجهة لأعلى هي نتائج تُرجَع. معاً يشكلان ترويسة الوحدة.
مثال محلول: بناء مخطط هيكلية
- يقوم برنامج بقراءة درجات طالب، وحساب المتوسط، وإخراج الدرجة. ارسم مخطط هيكلية.
- الوحدة العليا:
ProcessStudent. تحتها، من اليسار إلى اليمين:ReadMarks، الذي يرجع مصفوفة الدرجات؛CalculateAverage، الذي يأخذ مصفوفة الدرجات لأسفل ويرجع المتوسط؛OutputGrade، الذي يأخذ المتوسط لأسفل ولا يرجع شيئاً. - ثلاثة أشياء تحقق النقاط: الهرمية مع المهمة الرئيسية في الأعلى، المهام الفرعية بالترتيب الذي تعمل به، والمعاملات المسماة على الأسهم في الاتجاه الصحيح. السهم غير المسمى يمنح نصف نقطة كحد أقصى.
من مخطط الهيكلية إلى الكود الوهمي
- تصبح الوحدة العليا البرنامج الرئيسي؛ كل مستطيل تحتها يصبح إجراءً أو دالة يتم قراءة توقيعها من الأسهم؛ يستدعي البرنامج الرئيسي إجراءاتها من اليسار إلى اليمين.
PROCEDURE ProcessStudent()
DECLARE Marks : ARRAY[1:10] OF INTEGER
DECLARE Average : REAL
Marks ← ReadMarks()
Average ← CalculateAverage(Marks)
CALL OutputGrade(Average)
ENDPROCEDURE
- القيمة المرجعة تعني
FUNCTION … RETURNS؛ الوحدة التي لا ترجع شيئاً هيPROCEDURE. قائمة المعاملات هي بالضبط الأسهم الهابطة.
رتب خطوات تصميم برنامج باستخدام مخطط هيكلي.
من الأعلى إلى الأسفل: مهمة، مهام فرعية، تدفق بيانات، ترويسات، استدعاءات. يُنتهي المخطط قبل كتابة أول سطر من الكود.
الوحدة التي تظهر أسهم المخطط الهيكلي الخاصة بها قيمة تُرجَع للأعلى يجب كتابتها كـ PROCEDURE (إجراء).
القيمة المُرجعة تجعلها FUNCTION (دالة) … RETURNS. الـ PROCEDURE لا تُرجع شيئاً.
مخطط انتقال الحالة
- مخطط انتقال الحالة وثّق سلوك النظام: الحالات التي يمكن أن يكون فيها والأحداث التي تنقله من حالة إلى أخرى.
- كل حالة دائرة أو صندوق دائري الحواف؛ كل انتقال سهم مُعنّن بالحدث الذي يسببه، أحياناً مع الإجراء المتخذ. علامة تشير إلى الحالة الابتدائية.
- مناسب للأنظمة التي تنتظر الأحداث وتتفاعل معها: آلة بيع، إشارة مرور، قفل باب، واجهة مستخدم.
كل حالة، كل حدث، كل سهم
يوضح مخطط انتقال الحالات:
الحالات دوائر؛ الانتقالات أسهم مُعلَّمة بالأحداث. مثالي لأجهزة البيع الآلي، الأقفال، إشارات المرور.
ماذا يظهر مخطط انتقال الحالات؟ حدد كل ما ينطبق.
الحالات، الانتقالات المُعلَّمة، وعلامة البداية. الوقت ليس جزءاً من المخطط.
مثال محلول: قراءة مخطط قفل الباب
- يفتح القفل عند إدخال الرمز 2، 5، 9. ابدأ من مغلق. الضغط على 2 ينقلك إلى رقم واحد صحيح؛ والضغط على 5 من هناك ينقلك إلى رقمان صحيحان؛ والضغط على 9 من هناك ينقلك إلى غير مغلق.
- أي مفتاح آخر في أي حالة انتظار يعيد النظام إلى مغلق: الرسم البياني يُظهر هذه الأسهم أيضاً، والرسم البياني الذي يتجاهلها يحتوي على فجوة. ماذا يحدث إذا تم الضغط على 2 أثناء وجود النظام في حالة غير مغلق؟ إذا لم يكن هناك سهم يشير إلى ذلك، فإن التصميم لم يقرر الأمر بعد.
- هذا هو الغرض من الرسم البياني: يجب أن يوضح كل حالة ما يحدث عند كل حدث، لذا تُستنتج الانتقالات المفقودة على الورق ولا تُترك للعميل.
يُسهّل مخطط انتقال الحالات اكتشاف الانتقالات المفقودة أو غير المعالجة، لأن كل حالة والأحداث بينها موضحة.
رؤية كل حالة وحدث يكشف عن حالات لم تتعامل معها — على سبيل المثال، إدخال عملة ثانية غير متوقعة في جهاز بيع آلي.
اختيار الأداة
- لإظهار كيف يتم تقسيم البرنامج إلى وحدات وما الذي ينتقل بينها: مخطط البنية.
- لإظهار كيف يتصرف النظام بمرور الوقت استجابة للأحداث، خاصةً الآلات أو الواجهات ذات الأوضاع المختلفة: مخطط انتقال الحالة.
- لإظهار المنطق خطوة بخطوة لخوارزمية واحدة: مخطط انسيابي أو كود زائف. حدد أيهما واستخدمه ولماذا.
صوّغ كل أداة تصميم بما تظهره.
كل أداة تنظر إلى التصميم بطريقة مختلفة — البنية (وحدات)، السلوك (حالات)، التدفق (مخطط انسيابي) أو الخطوات (الخوارزمية الوهمية).
يجب أن يستجيب تحكم إشارات المرور لجهاز مؤقت وزر مشاة. أي أداة تصميم توثق سلوكه بشكل أفضل؟
الأحمر، الأحمر-العنبري، الأخضر، العنبري هي حالات؛ الجهاز المؤقت والزر هما أحداث. سيُظهر المخطط الهيكلي الوحدات، وليس السلوك.
علامات ضائعة
- مخطط البنية ليس مخططاً انسيابياً. إنه يُظهر التسلسل الهرمي والمعلمات، وليس تسلسل القرارات داخل الوحدة.
- ضع اسماً على كل سهم للمعامل أو النتيجة وشعّبه في الاتجاه الصحيح. السهم العاري لا يحمل أي معنى.
- الحالة هي شرط يكون فيه النظام في حالة انتظار؛ والحدث هو ما يحدث له. "الضغط على 5" هو حدث، وليس حالة.
- يجب أن تتطابق رؤوس الكود الزائف مع المخطط: نفس المعلمات، نفس قيم الإرجاع، ونفس ترتيب الاستدعاءات.
لقد فهمت الأمر
- يُظهر مخطط البنية التفكيك التنازلي إلى وحدات، مع المعاملات الممررة للأسفل والنتائج المُرجعة للأعلى عبر أسهم مُسمَّاة.
- اقرأ رؤوس الكود الزائف منه: الأسهم المتجهة لأسفل تمثل قائمة المعلمات، والسهم المتجه لأعلى يجعله
FUNCTION … RETURNS، وتُستدعى الوحدة الرئيسية من اليسار إلى اليمين. - يُظهر مخطط انتقال الحالة الحالات والأحداث التي تنقل بين-states، ويكشف عن الانتقالات التي لم يقررها أحد بعد.
- التفكيك → مخطط البنية؛ السلوك → مخطط انتقال الحالة؛ منطق خوارزمية واحدة → مخطط انسيابي أو كود زائف.