साइट के लिए संदर्भ की शर्तें। अभ्यास

लेख के लिए टिप्पणियों में, तकनीकी असाइनमेंट, साइट ने संदर्भ की शर्तों के लिए टेम्पलेट के बारे में बात की और, वास्तव में, काम के बयान का उदाहरण, लेख में वर्णित सिद्धांतों के अनुसार संकलित किया गया। वहां मैंने टेम्पलेट और TK दोनों को दिखाने का वादा किया।

मैं अपना वादा रखता हूं, और इस लेख में मैं टीके के लेखन को दिखाने की कोशिश करूंगा। इस लेख को पढ़ने से पहले, मैं साइट के लिए संदर्भ की शर्तों को पढ़ने की सलाह देता हूं, जैसा कि यहां मैं यह नहीं समझाऊंगा कि टीओआर इस तरह क्यों दिखता है, लेकिन मैं केवल उपरोक्त लेख के सिद्धांतों के अनुसार संदर्भ की शर्तों को बनाने की प्रक्रिया का वर्णन करूंगा।



संदर्भ संरचना की शर्तें इस प्रकार होंगी:

1. आम शब्द
2. ऑपरेशनल उद्देश्य
3. कार्यशीलता
4. नियम और परिभाषाएँ
5. डेटा प्रकार
6. कार्यात्मक विशेषताएं
7. पेज
विश्वसनीयता की आवश्यकताएं
9. होस्टिंग आवश्यकताएँ
10. सामग्री भरना
11. वितरण और स्वीकृति

इन वर्गों को हमारे उदाहरण टीके में वर्णित किया जाएगा।

मैं एक आरक्षण करना चाहता हूं कि लेख में कुछ बिंदुओं को छोड़ दिया जाएगा, सरलीकृत किया जाएगा या योजनाबद्ध तरीके से दिखाया जाएगा। यह आवश्यक है ताकि अप्रासंगिक विवरण के साथ लेख को अव्यवस्थित न करें और समझ को जटिल न करें।

अचानक, यह पता चला कि मैं वेबसाइटों के लिए तकनीकी विनिर्देश बनाने के लिए एक प्रणाली विकसित कर रहा था। और, इस अवसर पर, मैं इस प्रणाली का उपयोग करके टीके लिखने की प्रक्रिया का वर्णन करूंगा। इसे azalo.net कहा जाता है।

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

लेख को कई चरणों में विभाजित किया गया है। प्रत्येक चरण के अंत में, संदर्भ की शर्तों का एक लिंक दिया जाएगा, जिस रूप में यह पारित चरण के बाद होगा।

टीके पाठ में पाठ के बगल में निशान होंगे।



जो उन हिस्सों को चिह्नित करेगा जो पिछले चरण की तुलना में बदल गए हैं, या यह उन पर ध्यान देने योग्य है और यह पाठ में इंगित किया गया है।

साइट के बारे में, जिसका उपयोग टीके बनाने के लिए एक उदाहरण के रूप में किया जाता है। यह एक वास्तविक साइट है, और एक वास्तविक, थोड़ा सुगम, टीके, जिस पर साइट बनाई गई थी। यह सवाल करने के लिए कि ग्राहक ऐसी साइट क्यों चाहता है, और दूसरी नहीं, मैं जवाब नहीं दे सकता। जैसा कि वे कहते हैं, साइट मेरी नहीं है, मैंने सिर्फ TK की घोषणा पोस्ट की है ।

---

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

हम समस्या के विश्लेषण के लिए आगे बढ़ते हैं।

चरण 1. साइट का प्रारंभिक लेआउट।

हम भविष्य की साइट की योजना की रूपरेखा तैयार करते हैं।



यह योजना ग्राहक के शब्दों को दोहराती है "साइट के पास होना चाहिए: शिविर स्थल के बारे में सामान्य जानकारी, शिविर स्थल के स्थान के साथ एक नक्शा, मूल्य, फोटो, समीक्षा, ऑनलाइन बुकिंग और प्रतिक्रिया की संभावना"।

मुख्य पृष्ठ में शिविर स्थल के बारे में सामान्य जानकारी है, बाकी बॉक्स पृष्ठों के नामों से स्पष्ट है। व्यवस्थापक क्षेत्र अभी तक हमारे लिए कोई दिलचस्पी नहीं है और "व्यवस्थापक पैनल में प्रवेश करें" बॉक्स द्वारा दर्शाया गया है।

एक नया प्रोजेक्ट बनाया है और azalo.net में इस आरेख को स्केच किया है, हम पहले ही थोड़ा सा टीके लिख चुके हैं। हमने टीके के लिए एक रिक्त बनाया है, आरेख पर प्रत्येक बॉक्स (पृष्ठ) एक आइटम से मेल खाता है, और हमने टीके के अन्य सभी भागों के लिए जगह तैयार की है।

हम ग्राहक को योजना दिखाते हैं और समझाते हैं, वह यह देखना चाहता है कि क्या सब कुछ है और हमारी समझ की पुष्टि करता है। जबकि सही ढंग से चल रहा है।

कार्य , साइट लेआउट के विवरण के लिए लिंक।

चरण 2. परिचयात्मक भाग, होस्टिंग और विश्वसनीयता के लिए आवश्यकताएं, वितरण और स्वीकृति की शर्तें।

जबकि भविष्य की साइट का विवरण हमारे सिर में पक रहा है, हम संदर्भ की शर्तों की शुरुआत और अंत में अनुभागों को भर देंगे, जो बाकी टीके के साथ शिथिल रूप से जुड़े हुए हैं। ये हमारे टीके के 1-3, 8-10 भाग हैं।

सामान्य प्रावधान

यहाँ हम संकेत देते हैं कि हम एक शिविर स्थल के लिए एक साइट बना रहे हैं और हमें अपनी वस्तु के बारे में पता है।

वन हिल्स कैंप साइट के लिए एक वेबसाइट बनाने की आवश्यकता है। शिविर स्थल काला सागर पर स्थित है, जो कम पहाड़ों से घिरा हुआ है और पहाड़ियों की एक जोड़ी पर स्थित है। इसमें 3 श्रेणी के कमरों के साथ 16 घर हैं। घरों में 2 और 4 कमरे हैं। जब एक टिकट जारी किया जाता है, तो ग्राहक कमरे के प्रकार को इंगित करता है, लेकिन विशिष्ट घर प्रबंधक द्वारा मुक्त स्थानों के आधार पर निर्धारित किया जाता है।

Azalo.net सेवा में, यह टुकड़ा इस तरह दिखेगा:



अब हम कमोबेश कल्पना करते हैं कि किस हॉस्टल के लिए साइट बनाई जाएगी।

संचालन का उद्देश्य

जैसा कि लेख में कहा गया है कि साइट के लिए संदर्भ की शर्तें : परिचालन उद्देश्य, यह धन प्राप्त करने से पहले एक कदम है। हमें एक वेबसाइट की आवश्यकता है ताकि पर्यटक इसमें आएं, फ़ोटो देखें, समीक्षा पढ़ें, इन स्थानों पर जाने और टिकट खरीदने की इच्छा पर प्रकाश डालें। पैसे वापस जाएं (वाउचर खरीद):

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

कार्यात्मक उद्देश्य

किस माध्यम से हम "परिचालन उद्देश्य" प्रदान करेंगे:

साइट को शिविर स्थल के बारे में सामान्य जानकारी प्रदान करनी चाहिए; तस्वीरें देखने की क्षमता; साइट में आपके गंतव्य तक पहुंचने का एक नक्शा होना चाहिए; कमरे का आरक्षण फॉर्म; और समीक्षा (अतिथि पुस्तक) छोड़ने के अवसर वाले मेहमानों की समीक्षा

अभी के लिए, हम डेटा, कार्यक्षमता और पृष्ठों से संबंधित सभी चीजों को छोड़ देंगे, और साइट को भरने के बारे में आइटम पर जाएंगे। हम बुकिंग पर अनुभाग में नीचे दिए गए लापता बिंदुओं पर विस्तार से विचार करेंगे।

साइट की सामग्री

हमारे अनुबंध में भरना शामिल नहीं है।
क्योंकि मैंने पहले भी इस स्थिति का वर्णन किया है azalo में, मैंने इस मामले के लिए पाठ तैयार किया है। इस तरह के रिक्त भाग अनुभाग के दाईं ओर स्थित हैं, और प्रत्येक के बगल में एक बटन है "Add to TK"। हम "न्यूनतम भरने" बटन दबाते हैं, पाठ को दस्तावेज़ में जोड़ा जाता है, हम इसे थोड़ा ठीक करेंगे और आगे बढ़ेंगे।

ठेकेदार साइट की न्यूनतम सामग्री को पूरा करने के लिए बाध्य है, जो ग्राहक को साइट का उपयोग शुरू करने की अनुमति देगा। ठेकेदार को इस टीके में वर्णित वस्तुओं की श्रेणियों को बनाना होगा, एक सुपर-उपयोगकर्ता बनाना होगा। इस तरह के अनुभागों को "गैलरी" या पाठ पृष्ठों की सामग्री के रूप में भरना ठेकेदार का कर्तव्य नहीं है।

होस्टिंग आवश्यकताओं

हमें थोड़ी PHP होस्टिंग चाहिए। क्योंकि साइट बनाने के लिए हम लगातार एक ही फ्रेमवर्क का उपयोग करते हैं, फिर उसी विशेषताओं के साथ साइट से साइट पर होस्टिंग की आवश्यकता होती है। स्वाभाविक रूप से, हमारे पास होस्टिंग के लिए आवश्यकताओं का वर्णन करने वाला एक रिक्त स्थान है और हम सिर्फ काम के बयान में एक रिक्त जोड़ते हैं:

न्यूनतम उपयुक्त कॉन्फ़िगरेशन:

• कम से कम 330 एमबी के डिस्क कोटा के साथ होस्टिंग
• PHP5 के साथ होस्टिंग और अपाचे रिवाइटर मॉड्यूल स्थापित किया है
• MySQL डेटाबेस संस्करण 5 और InnoDB मॉड्यूल के साथ उच्चतर
• एक पंजीकृत और सही ढंग से कॉन्फ़िगर डोमेन की उपस्थिति

क्यों 330mb? उन्होंने प्रोग्रामर्स के साथ स्पष्ट किया, उन्होंने कहा कि उन्हें इस परियोजना के लिए 330 की जरूरत है ।

विश्वसनीयता आवश्यकताओं

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

साइट को मुख्य प्रकार के हमलों के खिलाफ बुनियादी सुरक्षा प्रदान करनी चाहिए: क्रॉस-साइट स्क्रिप्टिंग (एक्सएसएस), एसक्यूएल इंजेक्शन, सीएसआरएफ भेद्यता।

लेकिन इस सब के साथ, किसी ने भी बैकअप रद्द नहीं किया।

यह अनुशंसा की जाती है कि आप सॉफ़्टवेयर की एक प्रति बाहरी मीडिया पर संग्रहीत करें। यह भी सिफारिश की जाती है कि आप नियमित रूप से डेटाबेस फ़ाइल को बाहरी मीडिया में कॉपी करें यदि होस्टिंग कंपनी ऐसी सेवा प्रदान नहीं करती है।

वितरण और स्वीकृति की शर्तें

हम ग्राहक के साथ एक आरक्षण करते हैं कि उसके पास स्वीकृति के लिए 7 दिन का समय है, इस समय के दौरान हमें साइट को एक सामान्य कार्यशील स्थिति में लाना होगा, और पाए गए कीड़े को ठीक करने के लिए एक और 30 दिन का समय देना होगा। उसके बाद, हम अपने काम को एक स्पष्ट विवेक के साथ करते हैं।

साइट को सामान्य रूप से देखना और कार्य करना चाहिए:

साइट को निम्न ब्राउज़रों में सही ढंग से प्रदर्शित और कार्य करना चाहिए:

• क्रोम 13
• फ़ायरफ़ॉक्स ४
• सफ़ारी ५
• ओपेरा 11
• इंटरनेट एक्सप्लोरर 8 और 9

बेशक, किसी को गलती मिल सकती है: "सही ढंग से प्रदर्शित" करने का क्या मतलब है? एक डिजाइन के साथ पिक्सेल पिक्सेल या अगर हम एक वेबसाइट का आदेश दिया है तो आप क्या समझेंगे? हम दिखावा करेंगे कि हमने सवाल नहीं सुना है और आगे बढ़ना है।

कार्यक्रम के परीक्षण के संचालन की अवधि के बाद कार्यक्रम की स्वीकृति की जाती है। यदि साइट 7 कैलेंडर दिनों के लिए सही और स्थिर रूप से संचालित होती है, तो परीक्षण ऑपरेशन की अवधि पूरी हो जाती है। ठेकेदार तकनीकी अवधि के साथ सभी दोषों और विसंगतियों को समाप्त करने के लिए, ऑपरेशन अवधि की शुरुआत से 1 महीने के भीतर सॉफ्टवेयर उत्पाद के साथ काम करता है (कार्यक्रम के कार्यों की संरचना को बदले बिना)।

अब, चरण 2 के बाद, हमारे पास संदर्भ की शर्तें हैं । पिछले चरण से साइट लेआउट नहीं बदला गया है।

संदर्भ की शर्तों के पाठ में, किए गए विवरण एक नीली पट्टी के साथ चिह्नित हैं।

नाइट की चाल

व्यक्तिगत रूप से मेरे लिए, तुरंत और पूरे तकनीकी कार्य को लिखना, बहुत मुश्किल काम है। मैं कार्य को छोटे उप-प्रकारों में विभाजित करने का प्रयास करता हूं। वे ध्यान केंद्रित करने और निर्णय लेने में आसान होते हैं, और इन समाधानों का पुन: उपयोग किया जा सकता है।

Azalo.net में TK पर काम करते समय, मैं "घटकों" का उपयोग करता हूं। अवयव तार्किक रूप से एक साइट के कुछ हिस्सों को तैयार करते हैं, जो एक नियम के रूप में, विभिन्न परियोजनाओं में उपयोग किया जा सकता है। उदाहरण के लिए, समाचार, एक ब्लॉग इत्यादि। यह साइटों के प्रोग्रामर्स के लिए प्लगइन "समाचार", प्लगइन "ब्लॉग", आदि की तरह है।

उदाहरण के लिए, नीचे इस तरह के एक घटक का एक आरेख है। यह एक अतिथि पुस्तक है। इसमें केवल वही शामिल है जो अतिथि पुस्तक से संबंधित है, और इससे अधिक कुछ नहीं। जैसा कि आप अनुमान लगा सकते हैं, इस घटक का उपयोग विभिन्न परियोजनाओं में किया जा सकता है जहां अतिथि पुस्तक की आवश्यकता होती है।



घटक के लिए तकनीकी कार्य लगभग पूरी साइट के समान है, लेकिन कुछ अपवादों के साथ।
TK घटक में निम्नलिखित वर्णनात्मक ब्लॉक नहीं हैं जो TK पूरी साइट पर हैं:

• सामान्य प्रावधान
• संचालन का उद्देश्य
• कार्यात्मक उद्देश्य
• साइट की सामग्री
• विश्वसनीयता आवश्यकताओं
• वितरण और स्वीकृति की शर्तें

हालांकि, घटक, साइट के साथ, इस तरह के आइटम हैं:

• नियम और परिभाषाएँ
• कार्यात्मक विशेषताएं
• होस्टिंग आवश्यकताओं

इस तरह के एक घटक को मुख्य परियोजना से जोड़ा जा सकता है, और घटक से संदर्भ की शर्तों के सभी भाग मुख्य तकनीकी कार्य में विलय हो जाएंगे। शब्द, पृष्ठ से पृष्ठ, आदि के लिए शर्तें

इस तरह के एक घटक का निर्माण नीचे दिखाया जाएगा। एक घटक के रूप में, मैंने "आरक्षण" को सबसे विशेषता घटक के रूप में चुना। इस तरह के एक घटक के लिए टीके का निर्माण मूल रूप से एक पूरी साइट और अन्य घटकों के निर्माण से अलग नहीं है। यानी वास्तव में, हम एक मिनी-टीके का निर्माण जारी रखेंगे, जो एक पूर्ण कार्य के निर्माण के सभी प्रमुख बिंदुओं को दिखाएगा। ऐसा पैंतरेबाज़ी आपको सभी महत्वपूर्ण भागों को दिखाने की अनुमति देगा और लेख को पाठ की विशाल शीट में नहीं बदल देगा।

हमारी साइट में कई घटक होंगे, लेकिन वे "बुकिंग" की तुलना में बहुत सरल होते हैं और समान सिद्धांतों के अनुसार बनाए जाते हैं, इसलिए मैं उनका वर्णन नहीं करूंगा, लेकिन यह कहें कि वे पहले अन्य कार्यों के लिए बने थे, और बस परियोजना से जुड़े थे काम के अंत में।

तो, आगे के चरण 3, 4 और 5 "बुकिंग" घटक से संबंधित हैं।

चरण 3. कार्यात्मक विवरण; डेटा और सूची

धारा 6 "कार्यात्मक विशेषताएं" सीधे साइट के काम (भागों) का वर्णन करती है। क्योंकि हमारे पास साइट (घटक) और सभी संस्थाओं के सभी पृष्ठों का विस्तृत विवरण होगा, यहां हम या तो काम के सामान्य सिद्धांतों को बाहर निकाल देंगे, या उस कार्यक्षमता को एक विशिष्ट पृष्ठ से नहीं जोड़ा जा सकता है।

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

और बुकिंग करते समय, ग्राहक को यह इंगित करने में सक्षम होना चाहिए कि वे एक घर में कमरे किराए पर लेना चाहते हैं।

छुट्टियों के लिए कीमतें कमरे के प्रकार और अवधि पर निर्भर करती हैं। गर्मियों में, एक कीमत, सर्दियों में, एक और।

आरक्षण प्रणाली को उपयोगकर्ता को समय की उपलब्धता के साथ खुद को परिचित करने का अवसर प्रदान करना चाहिए जो उसे ब्याज देता है और आरक्षण का अनुरोध करता है।

यह माना जाता है कि शिविर स्थल पर एक ही प्रकार के कई घर हैं। घरों में कमरों को मानक और लक्जरी जैसे कई श्रेणियों में विभाजित किया गया है।

बुकिंग करते समय, उपयोगकर्ता वांछित प्रकार के कमरे को इंगित करता है, लेकिन यह इंगित नहीं करता है कि उसे कौन सी संख्या चाहिए। विशिष्ट संख्या जिसमें अतिथि को समायोजित किया जाएगा, प्रबंधक द्वारा निर्धारित किया जाएगा।

बुकिंग आवेदन में 3 राज्य हैं:

• पुष्टि नहीं हुई
• इस बात की पुष्टि
• बुक

जब कोई उपयोगकर्ता किसी एप्लिकेशन को खींचता है, तो यह स्वतः अपुष्ट हो जाता है। प्रबंधक द्वारा ग्राहक से संपर्क करने पर और वह आदेश की पुष्टि करता है, प्रबंधक आदेश की स्थिति को "पुष्टि" कर देगा और एप्लिकेशन को किसी विशेष घर में एक विशिष्ट संख्या के साथ जोड़ देगा। भुगतान प्राप्त होने के बाद, प्रबंधक आवेदन की स्थिति को "आरक्षित" में बदल देगा।

एक अपुष्ट आवेदन में क्षेत्र "आवेदन की पुष्टि की अवधि" द्वारा परिभाषित एक जीवन काल है। यदि आरक्षण की स्थिति "नॉट कन्फर्म" स्थिति से नहीं बदली गई है, तो आवेदन की पुष्टि के लिए समय सीमा तक पहुंचने पर एप्लिकेशन को स्वचालित रूप से हटा दिया जाना चाहिए।

कमरे की कीमतें कमरे की श्रेणी (मानक, विलासिता, आदि) और मौसम पर निर्भर करती हैं (उदाहरण के लिए, गर्मियों में अधिक महंगी, सर्दियों में सस्ती)।

आरक्षण करते समय, उपयोगकर्ता को यह चिन्हित करने के लिए एक चेकमार्क उपलब्ध होना चाहिए कि उपयोगकर्ता एक घर के सभी कमरों को बुक करना चाहे। हालांकि, यह चेकमार्क केवल एक इच्छा है और प्रबंधक को सूचित करने के लिए कार्य करता है, संख्याओं द्वारा पुनर्वास पर अंतिम निर्णय प्रबंधक द्वारा परिस्थितियों के आधार पर किया जाता है।

हर चीज की कार्यात्मक विशेषताओं के अनुसार।

इकाई विश्लेषण।

ग्राहक की कहानियों से यह स्पष्ट हो जाता है कि हमारे पास:

• घर पर
• घरों में कमरे
• कमरे के प्रकार (श्रेणियां) (सरल, आरामदायक, ...)
• समय अवधि (सर्दी-गर्मी)
• कीमतें जो मौसम और कमरे पर निर्भर करती हैं
• कवच

हमें "डेटा प्रकार" संदर्भ की शर्तों के 5 वें भाग में इन संस्थाओं का वर्णन करना होगा।

संख्या

नंबर से शुरू करते हैं। एक नंबर एक घर में एक कमरा है, विशेषताओं से इसमें एक "संख्या", एक संख्या, एक नाम के अर्थ में, एक पहचानकर्ता, उदाहरण के लिए, "संख्या 205" और एक श्रेणी है।

घर

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

मकान और कमरे एक-से-कई संबंधों से जुड़े हुए हैं: एक घर में कई नंबर होते हैं।



"संख्या" प्रकार के साथ "संख्या" चर, जैसा कि यह था, एक-से-कई संबंधों की उपस्थिति पर जोर देता है।

अगर किसी स्तर पर हमारे पास एक चर है, लेकिन हम अभी तक नहीं जानते हैं या इसका अर्थ नहीं समझते हैं, तो हम इसके प्रकार को "अपरिभाषित" के रूप में चिह्नित कर सकते हैं। यह भी उपयोगी हो सकता है यदि प्रकार "संख्या" अभी तक नहीं बनाया गया है, और यह अभी तक डेटा प्रकारों की सूची में नहीं है:

श्रेणी

इसका केवल एक नाम है। ग्राहक ने हमें बताया कि साइट पर श्रेणियों को इस क्रम में जाना चाहिए: "लक्स", "जूनियर सूट" और "मानक"। अंतर्ज्ञान हमें बताता है कि हमें व्यवस्थापक पैनल में श्रेणियों के क्रम को निर्धारित करने की क्षमता जोड़ने की आवश्यकता है। यह "ऑर्डर" चर की संरचना के विवरण को जोड़कर नोट किया गया है।

अवधि

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

यदि हमें यह सुनिश्चित करने की आवश्यकता है कि दो मूल्य हमेशा मेल खाते हैं, तो एक मूल्य को बाहर फेंकना सबसे अच्छा है, वैसे भी यह कुछ भी नया नहीं जोड़ेगा। इसलिए, अवधि में केवल शुरुआत होगी, एक अवधि का अंत अगले की शुरुआत होगी।

कीमत

मूल्य (इकाई) की एक कीमत (विशेषता) है और, एक तरफ, कमरे की श्रेणी पर निर्भर करती है, दूसरी ओर, समय की अवधि पर। इससे हम यह निष्कर्ष निकाल सकते हैं कि मूल्य एक संयोजी तालिका है जो सभी श्रेणियों को वर्ष की सभी अवधि से जोड़ती है, और मूल्य इन लिंक पर स्थित हैं।

कवच

शायद सबसे व्यापक संरचना। कवच होना चाहिए:

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

सूचियों

कम से कम व्यवस्थापक पैनल में हमें मूल्य के अलावा, ऊपर वर्णित सभी संस्थाओं की सूची की आवश्यकता होगी, जो एक अलग बातचीत होगी। हमारे मामले में, सूचियां बिना किसी तामझाम के सरल हैं, और किसी विशेष विवरण की आवश्यकता नहीं है।

इस क्षण तक, डेटा संरचनाओं के साथ संदर्भ की शर्तों को अच्छी तरह से फिर से भरना था।

चरण 4. घटक संरचना और पृष्ठ विवरण

"आरक्षण" घटक के हमारे ToR में, "पेज" का भाग 7 खाली छोड़ दिया गया था। यह रेखांकित करना आसान है कि हमें रूपरेखा संरचना की स्केचिंग करके किन पृष्ठों की आवश्यकता है।

आरक्षण का सार्वजनिक पक्ष छोटा होगा और इसमें कीमतों के साथ एक पृष्ठ और आरक्षण और कई सहायक के साथ एक पृष्ठ शामिल होगा।

व्यवस्थापक पैनल में, आपको पहले वर्णित संस्थाओं को संपादित करने के लिए कई अनुभाग बनाने की आवश्यकता है।

ऐसी "निर्देशिकाओं" का संपादन एक विशिष्ट उपस्थिति है: एक इकाई के सभी तत्वों की एक सूची, एक मौजूदा इकाई को संपादित करने के लिए स्विच करना, एक नया बनाना और एक मौजूदा को हटाना। इस प्रकारहमें प्रत्येक इकाई के लिए 3 पृष्ठ चाहिए: तत्व को हटाने की क्षमता के साथ एक सूची (एक प्रविष्टि), एक प्रविष्टि बनाने और संपादित करने के लिए एक पृष्ठ।

हम कीमत के लिए एक अलग पेज बनाएंगे, और जब हम इसे छोड़ेंगे, जैसा कि ऊपर बताया गया है, इसके लिए एक अलग परीक्षण की आवश्यकता होगी।

संशोधित योजना:


यहां तकनीकी कार्य है , जो अब तक पृष्ठों का वर्णन करने और साइट की योजना के लिए खाली वर्गों के साथ बदला गया है ।

चरण 5. पृष्ठों का विवरण

साइट पृष्ठों के लिए पाठ लिखने की तैयारी

हमने पहले ही तय कर लिया है कि बुकिंग घटक के लिए कौन से पृष्ठ और डेटा की आवश्यकता है।

अब हम एक मुश्किल चाल चलेंगे, जो पृष्ठों के पाठ के विवरण को और सरल बनाएगा।

हम पिछले चरण में वर्णित डेटा को पृष्ठों के साथ जोड़ते हैं। ऐसा करने के लिए, उपयुक्त पृष्ठ पर संरचना या सूची को खींचें और छोड़ें। उदाहरण के लिए, हम "अवधि बनाना" के लिए व्यवस्थापक पृष्ठ पर "अवधि" छोड़ देंगे और अगली कार्रवाई के साथ संकेत देंगे कि इस पृष्ठ पर एक नई अवधि बनाई जा सकती है:



यह क्रिया, पृष्ठ विवरण बनाने की तैयारी के अलावा, आपको हमारे टीके में "अंतराल" नोटिस करने की भी अनुमति देती है। । उदाहरण के लिए, यदि हम "बॉक्स" को डेटा से भरा हुआ नहीं देखते हैं, तो यह कम से कम अजीब है। यह किस प्रकार का पृष्ठ है जिसके साथ कोई डेटा संबद्ध नहीं है? या हो सकता है कि कोई पृष्ठ है, लेकिन इसके लिए डेटा का वर्णन करना भूल गया है?

अब हम पूरे सर्किट को डेटा और संबंधित संचालन के साथ भर देंगे, थोड़ी देर बाद यह हमारे लिए बहुत उपयोगी होगा।

पृष्ठ विवरण

यह हमारे लिए अंतिम चरण को पूरा करने के लिए रहता है - सभी पृष्ठों का वर्णन करने के लिए, अर्थात TOR "पृष्ठ" के 7 वें भाग को भरें। यह कदम बड़ा नहीं है, लेकिन हमारे पास काम को आसान बनाने के साधन हैं।

एक नियम के रूप में, प्रत्येक साइट में किसी प्रकार का "हाइलाइट" होता है जिसके चारों ओर बाकी सब कुछ घूमता है। जब कोई ग्राहक अपनी साइट के बारे में बात करता है, तो वह इस विशेष हाइलाइट पर सबसे अधिक ध्यान देता है, और ठेकेदार, क्रमशः इस हाइलाइट पर सबसे अधिक काम करता है। यह हाइलाइट, एक नियम के रूप में, आलस्य नहीं है, बल्कि इसके बारे में सोचना, टीओआर में इसका वर्णन करना और इसे कोड में लागू करना दिलचस्प है।

जब "हाइलाइट" किया जाता है, तो कलाकार की आत्मा को लगता है कि काम पूरा हो गया है, और शेष दिनचर्या trifles है। मुख्य बात पीछे है।

हमारी साइट के लिए, हाइलाइट आरक्षण होगा। और एक विस्तृत विवरण 3 पृष्ठों का हकदार है:

• बुकिंग, ग्राहक पृष्ठ
• आदेशों का मानचित्र (व्यवस्थापक)
• एक आवेदन का संपादन (व्यवस्थापक)

जब मुझे पृष्ठों का वर्णन करना होता है, तो मैं पहले पृष्ठ को स्केच करता हूं, इससे सूक्ष्मताओं को समझने और देखने में मदद मिलती है, और उसके बाद ही पाठ का वर्णन होता है। तो अब, सबसे पहले, "ऑर्डर ऑफ मैप्स" पेज का एक थंबनेल।

_{रेखाचित्रों के बारे में। रेखाचित्र बनाने के लिए मैं पेंसिल प्रोजेक्ट का उपयोग करता हूं । मैं यह नहीं कहूंगा कि यह अपनी तरह का सबसे अच्छा कार्यक्रम है, लेकिन ऐसा हुआ। इसकी मदद से आगे के सभी स्केच बनाए गए थे। थोड़ी सी चाल: जब मैं घटक बनाता हूं, तो मैं हमेशा घटक के साथ स्रोत स्केच फ़ाइलों को सहेजता हूं। इसलिए, जब मैं अगली साइट बनाता हूं, तो एक नए प्रोजेक्ट की जटिलताओं को ध्यान में रखते हुए स्केच को फिर से तैयार करना मुश्किल नहीं है।}



और अब एक पाठ विवरण:



पेरेटो सिद्धांत के अनुसार, कुंजी पृष्ठों-किशमिश परिणाम का 80% निर्धारित करते हैं, जबकि 20% प्रयास की आवश्यकता होती है। अगला हमें परिणाम का 20% और प्रयास का 80% मिलेगा: एक रूटीन पेज।

उदाहरण के लिए, कुछ रुटीन एडमिन पेजों की संख्या और समय अवधि की सूचियों के साथ पेज लिखते हैं:





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

और यहां बहादुर विमानन हमारी सहायता के लिए आता है, डेटा का वर्णन करने और उन्हें आरेख पर बॉक्स बक्से से जोड़ने के लिए किया गया कार्य। इस तरह के बंधन के बाद, वर्णन पीढ़ी हमारे लिए उपलब्ध हो जाती है। उदाहरण के लिए, संख्याओं की श्रेणियों वाले एक पृष्ठ के लिए, हमारे पास निम्नलिखित विकल्प हैं:



इस पृष्ठ से जुड़े डेटा के आधार पर जिन शब्दों को प्रतिस्थापित किया गया था, उन्हें हरे रंग के फ्रेम के साथ हाइलाइट किया गया है।

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

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



हमारे पास अभी भी मूल्य निर्धारण पृष्ठ है जिसका मैंने पहले उल्लेख किया था।

कीमतों को संपादित करने का एक अलग तरीका हो सकता है। हमारी कीमतें पीरियड्स से जुड़ी हैं। इसलिए, संपादन की संभावना के साथ विभिन्न श्रेणियों के लिए इस अवधि के लिए कीमतों की एक सूची की अवधि को संपादित करने के लिए पृष्ठ पर प्रदर्शित करना संभव होगा।



लेकिन, इस मामले में, जब कमरों की एक नई श्रेणी जोड़ते हैं, तो हमें सभी अवधियों से गुजरना होगा और एक नया मूल्य जोड़ना होगा। और यह इस तथ्य से भरा है कि कुछ कीमत भूल जाना चाहिए।

श्रेणी संपादन पृष्ठ पर एक संपादक बनाने से एक समान समस्या उत्पन्न होती है: एक अवधि जोड़ते समय, आपको सभी श्रेणियों के माध्यम से जाने और कीमत का संकेत देने की आवश्यकता होती है।

एक स्वीकार्य विकल्प एक तालिका बनाने के लिए प्रतीत होता है जहां कॉलम अवधि हैं, पंक्तियां श्रेणियां हैं, और सेल कीमतें हैं। इस परिदृश्य में, मूल्य का संकेत देना मुश्किल है, क्योंकि वे सभी दृष्टि में हैं:



और विवरण:

वह पृष्ठ जिस पर मूल्य तालिका प्रदर्शित होती है।
तालिका में, पंक्तियां संख्याओं की श्रेणी हैं, कॉलम समय की अवधि है। तालिका कक्षों में इनपुट फ़ील्ड हैं जहाँ आप कीमतें बदल सकते हैं।

यदि दर्ज डेटा गलत है या आवश्यक फ़ील्ड खाली हैं, तो कीमतें डेटाबेस में संग्रहीत नहीं होनी चाहिए।
इस मामले में, उसी पृष्ठ पर एक संक्रमण पहले दर्ज किए गए डेटा के संरक्षण और गलत तरीके से भरे गए फ़ील्ड के संकेत के साथ किया जाना चाहिए।

इस बिंदु पर, हमारे पास संदर्भ घटक के लिए एक तैयार-से- उपयोग "आरक्षण" शब्द और सभी पृष्ठों के थंबनेल के साथ एक आरेख है ।

हाइलाइट किए गए पृष्ठों को नीली पट्टियों के साथ और एक मूल्य-संपादन पृष्ठ के साथ हाइलाइट किया गया है, ग्रे पन्नों के साथ नियमित पृष्ठ। पृष्ठ विवरण के आगे के चित्र क्लिक करने योग्य हैं।

चरण 6. सब कुछ

बाकी उल्लू ड्रा करें। हमारे पास बहुत कम बचा है। छवि गैलरी, फीडबैक फॉर्म, ग्राहक समीक्षा, स्थान का नक्शा।

उपरोक्त सभी के लिए, हमारे पास पिछली परियोजनाओं के घटक हैं, और हम उन्हें अपनी परियोजना के लिए डॉक करते हैं।

और यहां हमारे काम का परिणाम है: संदर्भ की अंतिम शर्तें , और परिणामी साइट का लेआउट ।

---

मुझे समीक्षाओं और प्रश्नों, "अंधेरे" स्थानों पर खुशी होगी जो मुझे याद हो सकते हैं। मैं आपके सभी सवालों का जवाब देने की कोशिश करूंगा।