2009-07-14 9 views
12

मैं जानना चाहता हूं कि मुझे वेंडिंग मशीन जैसे डिज़ाइन जैसी समस्याओं तक पहुंचने के लिए क्या कदम उठाने चाहिए और कई डिज़ाइन दस्तावेज़ों (जैसे केस केस, अनुक्रम आरेख, कक्षा आरेख)। क्या कोई स्रोत/लिंक है जिसे मैं पढ़ सकता हूं जहां यह चरण-दर-चरण कैसे जाना है, इस बारे में बात करता है।"डिज़ाइनिंग वेंडिंग मशीन" जैसे डिजाइन समस्याओं से कैसे संपर्क करें

धन्यवाद।

+0

जेसी लिबर्टी का संदर्भ लें इस पर एक अच्छी किताब लिखा है: http://www.amazon.com/Beginning-Object-Oriented-Analysis-Design-C/dp/1861001339 – Robert

+0

यह प्रतीत हो रहा है गृहकार्य। – Tiger

+11

यह शायद होमवर्क है, लेकिन hes उनके लिए उपयोग किए जाने वाले मामलों के लिए नहीं पूछ रहा है। उसे सिर्फ सही दिशा में धक्का चाहिए। – Brandon

उत्तर

17

मुझे यकीन नहीं है कि क्या किसी भी सार्वभौमिक रूप से स्वीकार्य सेट हैं, लेकिन सबसे आसान काम यह है कि आप जितनी दूर तक जा सकते हैं, हर कदम को तोड़ दें।

प्रमुख कार्यों (पैसे में डालने, एक चयन दबाने, प्राप्त पेय)
  • जब तक यह लगभग तुच्छ हो जाता है छोटे कार्यों और प्रतिक्रियाओं में हर क्रिया सड़ते हुए जारी साथ
    1. प्रारंभ। तो पैसे डालने के लिए, आपको यह जानना होगा कि कितना रखा जा रहा था, जो कुल मिलाया गया था, प्रदर्शित करने की राशि इत्यादि।
    2. किसी भी परिदृश्य के बारे में सोचें जहां आपके कार्य अब मान्य नहीं होंगे (आप एक चयन धक्का देते हैं और मशीन खाली है), और आप इसके साथ कैसे निपटेंगे। (अपने पैसे वापस लौटें, एक और विकल्प के लिए तत्काल, आदि)
    3. कलाकारों और सिस्टम को कार्यों और प्रतिक्रियाओं को असाइन करें। पैसे में कौन डालता है, जो रनिंग कुल का ट्रैक रखता है?

    फिर आप अपने अनुक्रम आरेखों और कक्षा आरेख को आधार के आधार पर बना सकते हैं।

  • +0

    मुझे यह "फ्रैक्टाइलाइजेशन" दृष्टिकोण पसंद है! +1 – Janie

    5

    ठीक है, एक वेंडिंग मशीन मूल रूप से state machine है।

    मैं तय करता हूं कि वैध इनपुट क्या होगा (सिक्के और बिल?) और आउटपुट क्या होगा।

    मशीन पर चलने वाले उपयोगकर्ता के संभावित परिणाम क्या हैं। क्या समस्याएं हो सकती हैं? (बहुत अधिक पैसा, बहुत कम पैसा) उन्हें कैसे संभाला जाएगा? (डिस्पेंस चेंज, डिफेंस रिफंड)

    आखिरकार, उन चीज़ों को लिखें जिन्हें आपको उपयोग मामलों को संभालने की आवश्यकता होगी। आपके संज्ञा वर्गों की संभावना है। आपके क्रियाएं उन वर्गों से संबंधित विधियों की संभावना है।

    3

    मोटे तौर पर, क्या वस्तुओं एक वेंडिंग मशीन में शामिल हैं के बारे में सोचना:

    • VendingMachine - संभवतः एक अमूर्त वर्ग
    • DrinkMachine, SnackMachine, और वर्गों VendingMachine
    • VendingProduct का विस्तार - एक अमूर्त वर्ग?
    • Drink, अन्य VendingProduct
    • Coke विस्तार कक्षाएं, अन्य वर्गों का विस्तार Drink
    • & ग, & सी।

    लेकिन मुझे यकीन है कि आप इसे आसानी से समझ सकते हैं। मशीन के नट और बोल्ट किसी प्रकार की उपयोगिता कक्षा में होंगे, बिल और सिक्के स्वीकार करने, परिवर्तन की गणना आदि के तरीकों के साथ।

    अतिरिक्त पठन:

    • Here एक OOP डिजाइन शुरुआत पर एक अच्छा लेख, एलन होलुब कर रहा है।
    • Here ओओपी का उपयोग कर कॉफी वेंडिंग मशीन डिज़ाइन की शुरुआत है।
    +0

    पहला लिंक मर चुका है, क्या आप इसके लिए एक और दे सकते हैं? – ahujamoh

    +0

    संग्रहीत संस्करण के साथ अपडेट किया गया: https://web.archive.org/web/20090228114745/http://www.ibm.com/developerworks/webservices/library/ws-oo-design1/ –

    +0

    पहला लिंक भी मर चुका है। यहां नया पता है: http://www.maheshsubramaniya.com/article/object-oriented-programming-encapsulation-is-not-just-hiding-data.html – Yar

    1

    शुरुआत को परिभाषित "विक्रेता मशीन" द्वारा:

    वेंडर मशीन एक मशीन है कि .....

    Presto है! आपकी आवश्यकताएं हैं

    0

    ये विचार मदद मिल सकती है:

    एक अंतरफलक दृष्टिकोण से आदानों, आउटपुट, उम्मीद की स्थिति, त्रुटि की स्थिति को परिभाषित।

    तय करें कि इसे कितना अच्छा दिखाना है।

    इसे संचालित करने में कितनी देर (सेवा जीवन) की आवश्यकता है।

    इसे कितनी बार पुन: प्रयास करने की आवश्यकता है?

    2

    मुझे लगता है कि आपने पहले ही this link देखा है।

    कोड (कक्षाएं, & सी।) के बारे में पहले मत सोचें। उपयोग मामलों और कार्यात्मक आवश्यकताओं के बारे में सोचें। वेंडिंग मशीन प्रदान करने के लिए क्या कार्यक्षमता है? उपयोगकर्ताओं को इसके साथ बातचीत करने की उम्मीद कैसे की जाती है? रखरखाव के बारे में कैसे? ऐसा करने के दौरान उच्च स्तरीय आवश्यकताओं से कार्यान्वयन विवरण भ्रमित न करने का प्रयास करें।

    फिर, किस प्रकार के वर्ग प्रोजेक्ट के आधार पर यह गैर-कार्यात्मक आवश्यकताओं के बारे में सोचने के लिए है। सबसे महत्वपूर्ण विशेषता क्या है: गति, विश्वसनीयता, रखरखाव में आसानी, नई परिस्थितियों में अनुकूलता, सुरक्षा, ...? अन्य संभावनाएं हैं। ये बाइनरी नहीं हैं, हां/कोई जवाब नहीं है, श्रेणियों और न्यूनतम मानकों बनाम इष्टतम लक्ष्यों के संदर्भ में और सोचें। नोट, "इष्टतम" हितधारक के दृष्टिकोण पर निर्भर करता है। उपयोग और सुरक्षा की आसानी अक्सर संघर्ष में होती है, इसलिए आपको यह पता लगाना होगा कि कौन सा महत्वपूर्ण है।

    उसके बाद, आप अपने उपयोग के मामलों में वापस जा सकते हैं, और देख सकते हैं कि वे आपकी गैर-कार्यात्मक आवश्यकताओं से कैसे प्रभावित होते हैं। यह वह जगह है जहां आपके ग्राहक के साथ बातचीत होती है, जो इस मामले में शायद आप हैं। क्या आपको किसी अन्य लक्ष्य को पूरा करने के लिए सुविधाओं का त्याग करना है? प्रत्येक सुविधा के लिए, इनाम का जोखिम क्या है? उच्च मूल्य प्रदान करने वाली सुविधाओं को लागू करने में आसान है। लागू करने में कठिनाई (बाधाओं के कारण) विशेषताएं जो केवल छोटे मूल्य को जोड़ती हैं उन्हें स्पष्ट रूप से प्राथमिकता दी जानी चाहिए। अन्य दो संयोजनों को सावधानीपूर्वक विचार की आवश्यकता होती है।

    फिर आप मशीन को डिज़ाइन करना शुरू कर सकते हैं।

    कई अलग-अलग आरेख हैं जिनका उपयोग आप समस्या को देखने में मदद करने के लिए कर सकते हैं, या दूसरों के लिए आपके प्रस्तावित समाधान की व्याख्या कर सकते हैं।

    0

    स्क्रैच से सभी सॉफ़्टवेयर डिज़ाइन करने का केवल एक सही तरीका नहीं है!

    संभवतः अलग बिग अप फ्रंट डिजाइन जो August 2005 on JoelOnSoftware में लिखा गया था Evolutionary Design में के रूप में बहुत कम अग्रिम डिजाइन से लेकर दृष्टिकोण के दर्जनों रहे हैं। शायद उनके स्थान के कुछ तरीकों से अधिक संभावनाएं हैं, इसलिए यह इस बात पर निर्भर करता है कि आप किस विकास पद्धति का उपयोग करना चाहते हैं, क्योंकि कुछ लोगों को अधिक अपफ्रंट डिज़ाइन की आवश्यकता हो सकती है जैसे कि वाटरफॉल दृष्टिकोण में कुछ और एग्इल की तुलना में जहां आवश्यकताएं नियमित रूप से बदल सकती हैं और यह ' टी बहुत सारी समस्याओं का कारण बनता है या कम से कम यह सिद्धांत है।

    0

    इस तरह की समस्याओं

    दृष्टिकोण करने के लिए
    1. तुच्छ और बुनियादी

    2. चुनौतियां और मुद्दों है कि उपयोगकर्ता का सामना कर सकते पहचानें कार्यों में इन आवश्यकताओं को नीचे USECASE

    3. तोड़, आवश्यकताओं की पहचान कार्यक्षमता, और सिस्टम से परिप्रेक्ष्य सभी अमान्य scnearios। प्रदर्शन, सुरक्षा, विश्वसनीयता की भी आवश्यकता है।

    4. सभी चुनौतियां और मुद्दों नीचे पहले
    5. निशान वर्गों और क्रिया और विधि के रूप में कार्रवाई के रूप में सभी संज्ञाओं सूचीबद्ध के लिए समाधान की पहचान करें। परिदृश्य और समस्या कथन के आधार पर कक्षाएं एक-दूसरे के साथ बातचीत करने के लिए कक्षाओं के लिए सार्वजनिक इंटरफेस की पहचान करें और बाहरी अभिनेताओं के साथ
    6. किसी भी डिज़ाइन पैटर्न को लागू करने का प्रयास करें। (सिर्फ एक डिजाइन पैटर्न के अपने ज्ञान दिखाने के लिए पर जोड़ने)
    7. वर्ग रेखाचित्र के उपयोग के मामले चित्र आदि

    और निश्चित रूप से की मदद से अपने डिजाइन पेश आवश्यकताओं स्पष्ट करने के लिए ढेर सारे प्रश्न पूछना

    1

    कुछ समस्याओं (जैसे वेंडिंग मशीन) के लिए, इसे ऑब्जेक्ट ओरिएंटेड डिज़ाइन द्वारा राज्य मशीन के साथ निपटाया जा सकता है।

    प्रारंभिक स्थिति निष्क्रिय है और टाइपिंग शुरू होने पर टाइपिंग पर जाती है, यह आइटम पंक्ति और कॉलम नंबर टाइप करते समय स्पष्ट, रद्द और सबमिट करने की अनुमति देती है, फिर आइटम आइटम और कॉलम नंबर सबमिट करने के बाद भुगतान का ख्याल रखता है, अंततः यह सफलतापूर्वक भुगतान किए जाने पर आइटम को पॉप आउट करें, अन्यथा भुगतान करें।

    वेंडिंग मशीन में कक्षाओं के लिए, पंक्ति (ए, बी, सी) और कॉलम (1, 2, 3) संख्या इंगित करने के लिए कुछ बटन होना चाहिए, पंक्तियों और कॉलम संख्याओं को साफ़ करने, रद्द करने या सबमिट करने के लिए कुछ बटन, कुछ स्लॉट भुगतान (नकदी, सिक्का, क्रेडिट/डेबिट कार्ड) स्वीकार करने के लिए, कुछ स्लॉट आइटम रखने के लिए (पेय, नाश्ता, आदि)।

    blog

    संबंधित मुद्दे