पृष्ठ पलटने के लिए स्क्रॉल करें
Computer Science Principles · AP Computer Science Principles
सहयोग, डिज़ाइन और डीबगिंग
प्रोग्राम एक ही बार में नहीं लिखे जाते। उनकी जाँच-पड़ताल होती है, डिज़ाइन बनता है, मोटे रूप में बनाए जाते हैं, परखे जाते हैं और बार-बार दोहराए जाते हैं, चक्कर पर चक्कर, जब तक वे वह न करें जो उनके उपयोगकर्ताओं को चाहिए।
आकृति एक प्रचलित विकास प्रक्रिया चलाती है: जाँच-पड़ताल और चिंतन, designing, prototyping and testing। लाल गेंद हाथ में लिया काम है; हर स्टेशन पर वह टीम को किसी पहले के चरण में वापस भेज सकती है। हर चक्कर प्रोग्राम (नीला) को अधिक पूर्ण छोड़ता है: 3 चक्कर के बाद संस्करण 3।
प्रक्रिया क्रमबद्ध और सोची-समझी हो सकती है, योजना के अनुसार चरणों का पालन करती हुई, या खोजी, विचार आज़माती और जो चले उसे रखती हुई। कई प्रक्रियाएँ हैं; ये चार चरण उनमें से अधिकांश में समान हैं।
यह अध्याय AP Computer Science Principles का बिग आइडिया 1 है, रचनात्मक विकास: बहुविकल्पीय परीक्षा का 10–13%। इसमें साथ मिलकर काम करना (1.1), प्रोग्राम क्या करता है और किन इनपुट और आउटपुट के साथ (1.2), प्रोग्राम कैसे डिज़ाइन, निर्मित और प्रलेखित किए जाते हैं (1.3), और त्रुटियाँ कैसे खोजी और ठीक की जाती हैं (1.4) शामिल हैं। यह क्रिएट परफ़ॉर्मेंस टास्क का भी काम है, जो अध्याय का अंतिम पेज है।
और वे दृष्टिकोण जो उन्हें बेहतर बनाते हैं
कंप्यूटिंग नवाचार में प्रोग्राम अपने कार्य के एक अभिन्न भाग के रूप में शामिल होता है।
यह भौतिक हो सकता है, जैसे स्वचालित कार; अभौतिक कंप्यूटिंग सॉफ़्टवेयर, जैसे तस्वीर संपादित करने का सॉफ़्टवेयर; या अभौतिक कंप्यूटिंग अवधारणा, जैसे ई-कॉमर्स।
नवाचार सहयोग से बेहतर होते हैं। प्रभावी सहयोग ऐसा नवाचार बनाता है जो उसे डिज़ाइन करने वालों की प्रतिभाओं और दृष्टिकोणों की विविधता दर्शाता है, और विविध दृष्टिकोण पूर्वाग्रह से बचने में मदद करते हैं: जिस टीम के सभी सदस्य एक ही अनुभव साझा करते हैं, वह उसी अनुभव के लिए बनाने की ओर झुकेगी।
आकृति एक काल्पनिक टीम है जो उन स्थितियों की सूची बना रही है जिन्हें उसके ऐप को सँभालना है। डेवलपर A अकेला 12 में से 5 सोच पाता है। तीनों डेवलपर साथ मिलकर 10 सोचते हैं। बाकी उपयोगकर्ताओं से परामर्श से आती हैं: 12 में से 12।
इसीलिए उपयोगकर्ताओं से परामर्श और संवाद मायने रखते हैं। संभावित उपयोगकर्ताओं से जुटाई जानकारी डेवलपरों को विविध दृष्टिकोणों से प्रोग्राम का उद्देश्य समझने और ऐसा प्रोग्राम बनाने में मदद करती है जो उन्हें पूरी तरह शामिल करे।
पेयर प्रोग्रामिंग, ऑनलाइन टूल, पारस्परिक कौशल
समूह सहयोग के प्रचलित मॉडलों से नवाचार विकसित करते हैं। एक है पेयर प्रोग्रामिंग।
दो प्रोग्रामर एक कंप्यूटर साझा करते हैं। ड्राइवर (लाल) कोड टाइप करता है; नेविगेटर (नीला) हर पंक्ति को लिखे जाते समय परखता है, गलतियाँ पकड़ता है और आगे की सोचता है। आकृति के बीच में वे भूमिकाएँ बदलते हैं: भूमिका कीबोर्ड के साथ जाती है, व्यक्ति के साथ नहीं। वे जो प्रोग्राम लिख रहे हैं वह अगले पेज वाला है।
ऑनलाइन टूल प्रोग्रामरों को विचार और दस्तावेज़ साझा करने और उन पर फ़ीडबैक देने देकर सहयोग में सहायता करते हैं, चाहे वे एक ही कमरे में काम करें या नहीं।
प्रभावी टीमें पारस्परिक कौशल का अभ्यास करती हैं, जिनमें ये शामिल हैं पर इन्हीं तक सीमित नहीं:
प्रोग्राम क्या करता है, और कैसे
प्रोग्राम प्रोग्राम स्टेटमेंट का संग्रह है जो कंप्यूटर द्वारा चलाए जाने पर एक विशिष्ट कार्य करता है। प्रोग्राम को अक्सर सॉफ़्टवेयर कहा जाता है।
total ← 0 REPEAT 3 TIMES { n ← INPUT() total ← total + n } DISPLAY(total / 3) कोड खंड प्रोग्राम स्टेटमेंट का संग्रह है जो प्रोग्राम का हिस्सा है: यहाँ, पंक्तियों 2–6 का लूप (आकृति में नीला)।
प्रोग्राम का वर्णन मोटे तौर पर किया जा सकता है, कि वह क्या करता है: “यह उपयोगकर्ता द्वारा टाइप की तीन संख्याओं का औसत दिखाता है।” या अधिक ब्योरे में, कि वह क्या करता है और उसके स्टेटमेंट यह कैसे करते हैं: “यह total को 0 पर सेट करता है; तीन बार, यह एक संख्या n में पढ़ता है और उसे total में जोड़ता है; फिर total / 3 दिखाता है।”
प्रोग्राम को विविध इनपुट और स्थितियों के लिए काम करना चाहिए। आकृति इसे दो बार चलाती है:
| इनपुट | लूप के बाद total | दिखाया गया |
|---|---|---|
| 4, 8, 9 | 21 | 7 |
| −2, 0, 5 | 3 | 1 |
इसका व्यवहार यह है कि वह निष्पादन के दौरान कैसे काम करता है, जिसे अक्सर इससे बताया जाता है कि उपयोगकर्ता उससे कैसे संवाद करता है: उपयोगकर्ता तीन संख्याएँ टाइप करता है, और एक संख्या दिखती है।
हर नवाचार का एक उद्देश्य होता है: कोई समस्या हल करना, या रचनात्मक अभिव्यक्ति से किसी रुचि को आगे बढ़ाना। जो डेवलपर उद्देश्य समझते हैं वे प्रोग्राम को बेहतर विकसित कर पाते हैं।
डेटा अंदर, डेटा बाहर, कई रूपों में
प्रोग्राम इनपुट वह डेटा है जो प्रोग्राम द्वारा प्रोसेस किए जाने के लिए कंप्यूटर को भेजा जाता है। प्रोग्राम आउटपुट प्रोग्राम से किसी डिवाइस को भेजा गया कोई भी डेटा है।
दोनों कई रूपों में आते हैं: स्पर्शीय (एक स्पर्श, एक कंपन), श्रव्य (एक बोला शब्द, एक ध्वनि), दृश्य (कैमरा इमेज, स्क्रीन) या टेक्स्ट। आकृति हर रूप का एक इनपुट बारी-बारी से प्रोग्राम में भेजती है, और हर रूप का एक आउटपुट उससे बाहर।
इनपुट उपयोगकर्ता से या अन्य प्रोग्रामों से आ सकता है; नीचे दाईं ओर का टेक्स्ट आउटपुट दूसरे प्रोग्राम को जाता है, जिसके लिए वह इनपुट है।
इनपुट आमतौर पर प्रोग्राम के आउटपुट को प्रभावित करते हैं। और आउटपुट आमतौर पर प्रोग्राम के इनपुट या उसकी पूर्व अवस्था पर आधारित होता है: उसके संग्रहीत मान। यह प्रोग्राम मिले इनपुट की गिनती (नीली) रखता है, इसलिए स्क्रीन पर वही स्पर्श दूसरी बार अलग आउटपुट दे सकता है।
पिछले पेज के औसत वाले प्रोग्राम में INPUT() के तीन कॉल उसके इनपुट थे, और DISPLAY ने उसका आउटपुट स्क्रीन को भेजा।
स्टेटमेंट ट्रिगर होने पर चलते हैं
इवेंट किसी क्रिया से जुड़ा होता है और प्रोग्राम को इनपुट डेटा देता है।
इवेंट तब बनते हैं जब कोई कुंजी दबाई जाती है, माउस क्लिक होता है, प्रोग्राम शुरू होता है, या निष्पादन के प्रवाह को प्रभावित करने वाली कोई अन्य परिभाषित क्रिया होती है।
इवेंट-ड्रिवन प्रोग्रामिंग में, प्रोग्राम स्टेटमेंट नियंत्रण के अनुक्रमिक प्रवाह की जगह ट्रिगर होने पर निष्पादित होते हैं। ऊपर से पंक्ति-दर-पंक्ति कुछ नहीं चलता: हर इवेंट उसे सँभालने वाली प्रक्रिया चलाता है, और प्रोग्राम अगले की प्रतीक्षा करता है।
PROCEDURE onStart() { count ← 0 DISPLAY(count) } PROCEDURE onClick() { count ← count + 1 DISPLAY(count) } PROCEDURE onKeyPress() { count ← count - 1 DISPLAY(count) } परीक्षा की रेफ़रेंस शीट में इवेंट का कोई सिंटैक्स नहीं है, इसलिए यहाँ हर हैंडलर एक प्रक्रिया है और एक काल्पनिक परिवेश उसे तब कॉल करता है जब उसका इवेंट होता है। आकृति में प्रोग्राम शुरू होता है, बटन तीन बार क्लिक होता है, एक कुंजी दबती है और बटन एक बार और क्लिक होता है। दिखाए गए मान 0, 1, 2, 3, 2, 3 हैं।
count पूरे प्रोग्राम का है, इसलिए हर क्लिक का आउटपुट उससे पहले के इवेंट पर निर्भर करता है।
पुनरावृत्तीय और क्रमिक
विकास प्रक्रिया क्रमबद्ध और सोची-समझी हो सकती है, या प्रकृति से खोजी। कई हैं; अधिकांश जाँच-पड़ताल और चिंतन, डिज़ाइन, प्रोटोटाइप बनाने और परीक्षण के चरणों का उपयोग करती हैं।
पुनरावृत्तीय प्रक्रिया में पूरी प्रक्रिया के दौरान फ़ीडबैक, परीक्षण या चिंतन के आधार पर सुधार और संशोधन की आवश्यकता होती है। इसमें पहले के चरणों पर लौटना पड़ सकता है। निचली पंक्ति में पूरा प्रोग्राम पहले ही पास से मौजूद है, मोटे रूप में; फ़ीडबैक का हर दौर (लाल) उसे वापस भेजता है, और हर भाग अधिक पूर्ण होकर निकलता है।
क्रमिक प्रक्रिया समस्या को छोटे टुकड़ों में तोड़ती है और पूरे में जोड़ने से पहले सुनिश्चित करती है कि हर टुकड़ा काम करता है। ऊपरी पंक्ति में एक बार में एक टुकड़ा बनता और परखा जाता है, और पूरे में तभी जुड़ता है जब उसका परीक्षण पास हो।
दोनों विपरीत नहीं हैं। अधिकांश टीमें दोनों करती हैं: वे टुकड़ा-टुकड़ा बनाती हैं, और फ़ीडबैक आने पर हर टुकड़े और पूरे को संशोधित करती हैं।
आवश्यकताएँ, विनिर्देश, स्टोरीबोर्ड, मॉड्यूल
प्रोग्राम का डिज़ाइन जाँच-पड़ताल से शुरू होता है, ताकि उसकी आवश्यकताएँ तय हों।
जाँच-पड़ताल प्रोग्राम की सीमाओं, और उसे उपयोग करने वालों की चिंताओं और रुचियों की पहचान करती है। यह surveys, यूज़र टेस्टिंग, interviews and प्रत्यक्ष अवलोकन से की जा सकती है।
प्रोग्राम आवश्यकताएँ बताती हैं कि प्रोग्राम कैसे काम करता है, और उनमें उन उपयोगकर्ता-संवादों का वर्णन हो सकता है जो उसे देने हैं। प्रोग्राम का विनिर्देश उसकी आवश्यकताएँ परिभाषित करता है। पुस्तकालय के अध्ययन कक्ष बुक करने वाले एक काल्पनिक ऐप के लिए: (1) उपयोगकर्ता एक तारीख चुनता है।; (2) उपयोगकर्ता उस दिन खाली कमरे देखता है।; (3) उपयोगकर्ता एक बुक करता है और कोड पाता है।।
डिज़ाइन चरण रेखांकित करता है कि विनिर्देश को कैसे पूरा करें। इसमें ये शामिल हो सकते हैं:
आकृति इनमें से दो बनाती है: इंटरफ़ेस का स्टोरीबोर्ड, हर चरण के लिए एक स्क्रीन, जिनमें उपयोगकर्ता का टैप उन्हें एक स्क्रीन से दूसरी तक ले जाता है; और प्रोग्राम, मॉड्यूल में व्यवस्थित, हर आवश्यकता के लिए एक।
और दूसरों के कोड को स्वीकार करना
प्रोग्राम डॉक्यूमेंटेशन कोड खंड, इवेंट, प्रक्रिया या प्रोग्राम के कार्य का, और वह कैसे विकसित हुआ इसका, लिखित वर्णन है।
कमेंट डॉक्यूमेंटेशन का एक रूप हैं जो लोगों के पढ़ने के लिए प्रोग्राम में लिखा जाता है; वे प्रोग्राम के चलने को प्रभावित नहीं करते। सभी प्रोग्रामिंग परिवेश कमेंट का समर्थन नहीं करते, और परीक्षा की रेफ़रेंस शीट में कोई नहीं है, इसलिए आकृति में हर प्रक्रिया का डॉक्यूमेंटेशन उसके बगल में रखा है।
PROCEDURE average(numList) { total ← 0 FOR EACH num IN numList { total ← total + num } RETURN(total / LENGTH(numList)) } PROCEDURE isEven(n) { RETURN(n MOD 2 = 0) } average([6, 9, 3, 10]) 7 लौटाता है। डॉक्यूमेंटेशन पूरे विकास के दौरान लिखा जाता है: average का कार्ड उसके कोड के साथ बढ़ता है। यह सही प्रोग्राम विकसित करने और बनाए रखने में, अकेले या टीम में, मदद करता है, क्योंकि अगला पाठक (अक्सर बाद में लिखने वाला खुद) देख सकता है कि हर भाग किस लिए है।
सहयोग से या किसी अन्य स्रोत से विकसित हर कोड खंड को स्वीकार करना महत्वपूर्ण है। स्वीकृति प्रोग्राम डॉक्यूमेंटेशन में हो सकती है, और उसमें मूल या मूल लेखक का नाम होना चाहिए। आकृति में isEven (नीला) किसी अन्य स्रोत से आया है, और उसका कार्ड यह कहता है।
हर एक कब दिखाई देती है
तीन प्रोग्राम, हर एक [90, 75, 82] के सभी स्कोर दिखाने के लिए है; हर एक में एक गलती है।
सिंटैक्स त्रुटि प्रोग्राम की वह गलती है जिसमें प्रोग्रामिंग भाषा के नियमों का पालन नहीं किया गया। पहले प्रोग्राम में पंक्ति 5 में बंद करने वाला कोष्ठक नहीं है। प्रोग्राम बिल्कुल नहीं चलता: कोई पंक्ति नहीं चलती, और कुछ भी प्रदर्शित नहीं होता।
रन-टाइम त्रुटि वह गलती है जो प्रोग्राम के निष्पादन के दौरान होती है; हर प्रोग्रामिंग भाषा अपनी रन-टाइम त्रुटियाँ परिभाषित करती है। दूसरा प्रोग्राम प्रदर्शित करने से पहले i में 1 जोड़ देता है, इसलिए वह 75 and 82 दिखाता है, फिर scores[4] माँगता है। संदर्भ शीट में, 1 से छोटा या लिस्ट की लंबाई से बड़ा इंडेक्स एक त्रुटि है, और प्रोग्राम समाप्त हो जाता है।
लॉजिक त्रुटि एल्गोरिदम या प्रोग्राम की वह गलती है जिससे वह गलत या अप्रत्याशित व्यवहार करता है। तीसरा प्रोग्राम एक बार कम दोहराता है। उसे कुछ नहीं रोकता: वह अंत तक चलता है, पर 3 में से केवल 2 स्कोर दिखाता है। केवल उसके आउटपुट की अपेक्षित आउटपुट से तुलना करने पर ही गलती दिखती है।
scores ← [90, 75, 82] i ← 1 REPEAT LENGTH(scores) - 1 TIMES { DISPLAY(scores[i]) i ← i + 1 } सुधारने के बाद, पंक्ति 3 है REPEAT LENGTH(scores) TIMES।
सीमा से बाहर की संख्या
ओवरफ़्लो त्रुटि तब होती है जब कंप्यूटर ऐसी संख्या सँभालने की कोशिश करता है जो मानों की परिभाषित सीमा से बाहर है।
कई प्रोग्रामिंग भाषाएँ पूर्णांकों को बिट की निश्चित संख्या में संग्रहीत करती हैं, जो मानों की सीमा तय कर देती है। एक काल्पनिक भाषा लें जो पूर्ण संख्याओं को 4 बिट में संग्रहीत करती है: वह अधिकतम 1111 रख सकती है, जो 15 है।
आकृति 12 से ऊपर की ओर गिनती है। हर चरण बदलने वाले बिट पलटता है। 15 पर, 1 जोड़ने के लिए पाँचवाँ बिट चाहिए (16 है 10000), और स्टोर में केवल 4 हैं: ओवरफ़्लो। आगे क्या होता है, यह भाषा पर निर्भर है: कुछ त्रुटि के साथ रुक जाती हैं, कुछ जितने बिट समाएँ उन्हें रखकर गलत मान के साथ चलती रहती हैं (यहाँ, 0)।
असली भाषाएँ अधिक बिट उपयोग करती हैं, इसलिए उनकी सीमाएँ बहुत बड़ी हैं, पर वे फिर भी सीमाएँ हैं। परीक्षा की रेफ़रेंस शीट की भाषा अलग है: वहाँ पूर्णांक का आकार केवल कंप्यूटर की मेमोरी से सीमित है।
परिभाषित इनपुट, अपेक्षित आउटपुट
टेस्टिंग निर्धारित इनपुट का उपयोग करके यह सुनिश्चित करती है कि कोई एल्गोरिदम या प्रोग्राम अपेक्षित परिणाम देता है। प्रोग्रामर परिणामों के आधार पर उसमें सुधार करते हैं।
एक काल्पनिक थिएटर की आवश्यकता: 13 से कम, या 65 और उससे अधिक उम्र पर टिकट $8 का है; बाकी सबके लिए $12 का। आवश्यकता ही टेस्टर को बताती है कि कौन-से इनपुट आज़माने हैं और हर एक पर क्या अपेक्षित है।
PROCEDURE price(age) { IF(age < 13 OR age ≥ 64) { RETURN(8) } RETURN(12) } अच्छे टेस्ट इनपुट अलग-अलग अपेक्षित परिणामों को दिखाते हैं और इनपुट डेटा की चरम सीमाओं (न्यूनतम और अधिकतम) पर या उनके ठीक बाहर होते हैं, जहाँ गलतियाँ जमा होती हैं: यहाँ एक सीमा के दोनों ओर 12 और 13, दूसरी सीमा के दोनों ओर 64 और 65, और सबसे छोटी उम्र 0।
| age (इनपुट) | अपेक्षित | वास्तविक | |
|---|---|---|---|
| 0 | $8 | $8 | pass |
| 12 | $8 | $8 | pass |
| 13 | $12 | $12 | pass |
| 40 | $12 | $12 | pass |
| 64 | $12 | $8 | विफल |
| 65 | $8 | $8 | pass |
64 पर टेस्ट विफल होता है: कोड में age ≥ 64 लिखा है जबकि आवश्यकता का अर्थ age ≥ 65 है, यह एक लॉजिक त्रुटि है। 40 जैसी सामान्य उम्र पर टेस्ट इसे कभी नहीं पकड़ पाता।
ट्रेसिंग, विज़ुअलाइज़ करना, डीबगिंग, प्रदर्शित करना
त्रुटियाँ खोजने और सुधारने के प्रभावी तरीके: टेस्ट केस, हाथ से ट्रेसिंग, विज़ुअलाइज़ेशन, डीबगर और अतिरिक्त आउटपुट स्टेटमेंट जोड़ना।
findMax को लिस्ट की सबसे बड़ी संख्या लौटानी चाहिए। [-3, -7, -2] पर टेस्ट करने पर यह 0 लौटाता है, −2 नहीं। कारण देखने के लिए प्रोग्रामर लूप के अंदर DISPLAY(max) जोड़ता है (नीला): एक अतिरिक्त आउटपुट स्टेटमेंट।
PROCEDURE findMax(numList) { max ← 0 FOR EACH num IN numList { IF(num > max) { max ← num } DISPLAY(max) } RETURN(max) } इसे हाथ से ट्रेस करें, हर अवयव के लिए एक पंक्ति:
| num | num > max? | बाद में max | DISPLAY दिखाता है |
|---|---|---|---|
| −3 | false | 0 | 0 |
| −7 | false | 0 | 0 |
| −2 | false | 0 | 0 |
max कभी नहीं बदलता: कोई भी अवयव 0 से बड़ा नहीं है। डीबगर प्रोग्राम को रोककर उसके वेरिएबल दिखाते हुए यही बात दिखाता है (आकृति के खाने, उसकी स्थिति का एक विज़ुअलाइज़ेशन)। त्रुटि पंक्ति 3 में है: max 0 से शुरू होता है, जो सभी-ऋणात्मक लिस्ट के हर अवयव से बड़ा है।
सुधार max ← numList[1] है: लिस्ट के ही किसी अवयव से शुरू करें। फिर से चलाने पर अतिरिक्त आउटपुट −3, −3, −2 दिखाता है, और यह −2 लौटाता है। तब अतिरिक्त DISPLAY हटा दिया जाता है।
आपका अपना प्रोग्राम, और उस पर प्रश्न
क्रिएट परफ़ॉर्मेंस टास्क इस अध्याय का व्यावहारिक रूप है: आपके अपने चुने हुए प्रोग्राम का निर्माण, जो 1.1–1.4 की प्रक्रिया, डॉक्यूमेंटेशन और टेस्टिंग से विकसित किया गया हो।
आप AP Digital Portfolio में तीन चीज़ें जमा करते हैं: आपका प्रोग्राम कोड, उसके चलने का एक वीडियो, और एक पर्सनलाइज़्ड प्रोजेक्ट रेफ़रेंस (PPR)। इसके लिए आपको कम से कम 9 घंटे का कक्षा-समय दिया जाता है। आपके प्रोग्राम में कुछ तत्व होने चाहिए, जैसे लिस्ट और प्रक्रियाएँ।
परीक्षा के दिन लिखित उत्तर आता है: 60 मिनट, आपके अपने PPR के कोड पर 2 प्रश्न, जिसे आप उत्तर देते समय देख सकते हैं।
टास्क और लिखित उत्तर मिलकर AP स्कोर का 30% हैं; बहुविकल्पीय परीक्षा (120 मिनट में 70 प्रश्न) बाकी 70% है।
इसलिए इस अध्याय के प्रश्न आपके अपने प्रोग्राम के बारे में लौटकर आते हैं: उसका उद्देश्य और कार्य क्या है, उसके इनपुट और आउटपुट क्या हैं, आपने क्या और किन इनपुट से टेस्ट किया, और कौन-सी त्रुटि पाई और ठीक की।