1

DATA FLOW DIAGRAMSडेटा फ्लो डायग्राम

A DFD shows how data moves through the processes of a system, in terms of inputs and outputs.

• A PROCESS is a named circle, or BUBBLE; it transforms incoming data into outgoing data
• A DATA FLOW is a named ARROW entering or leaving a bubble
• An EXTERNAL ENTITY is a RECTANGLE: a producer or consumer of information outside the system
• A DATA STORE is a pair of PARALLEL LINES
• The CONTEXT DIAGRAM is the top-level, LEVEL 0 DFD: one process for the whole system

A DFD is not a flowchart: it shows the flow of data, while a flowchart shows the flow of control. So you avoid procedural detail when you draw a DFD.डीएफडी दिखाता है कि इनपुट और आउटपुट के रूप में डेटा प्रणाली की प्रक्रियाओं से कैसे गुजरता है।

• प्रोसेस एक नामित वृत्त, अर्थात् बबल, है; यह आने वाले डेटा को जाने वाले डेटा में बदलता है
• डेटा फ्लो बबल में आता या उससे जाता नामित तीर है
• एक्सटर्नल एंटिटी आयत है: प्रणाली के बाहर सूचना का उत्पादक या उपभोक्ता
• डेटा स्टोर समानांतर रेखाओं का जोड़ा है
• कॉन्टेक्स्ट डायग्राम शीर्ष-स्तर, अर्थात् लेवल 0, डीएफडी है: पूरी प्रणाली के लिए एक प्रोसेस

डीएफडी फ्लोचार्ट नहीं है: यह डेटा का प्रवाह दिखाता है, जबकि फ्लोचार्ट नियंत्रण का प्रवाह। अर्थात् डीएफडी बनाते समय आप प्रक्रियात्मक विवरण से बचते हैं।

2

DESIGN PRINCIPLES AND THE STRUCTURE CHARTडिजाइन के सिद्धांत और स्ट्रक्चर चार्ट

Design moves you from the problem domain to the solution domain. Its output is the DESIGN DOCUMENT, a blueprint for the solution.

• SYSTEM DESIGN decides what components are needed; DETAILED DESIGN decides how to build them
• PROBLEM PARTITIONING is divide and conquer; ABSTRACTION considers a component by its external behaviour
• Functional abstraction underlies STRUCTURED design; data abstraction underlies OBJECT-ORIENTED design
• A system is MODULAR when a change to one component has minimal impact on the others
• In a STRUCTURE CHART, modules are boxes; calling modules are SUPERORDINATE and called ones SUBORDINATE
• The four kinds of module are INPUT, OUTPUT, TRANSFORM and COORDINATE

So you partition the problem, and abstract each part.डिजाइन आपको समस्या क्षेत्र से समाधान क्षेत्र में ले जाता है। इसका परिणाम डिजाइन दस्तावेज है, जो समाधान का खाका है।

• सिस्टम डिजाइन तय करता है कि कौन-से घटक चाहिए; डिटेल्ड डिजाइन तय करता है कि उन्हें कैसे बनाएँ
• प्रॉब्लम पार्टीशनिंग 'बाँटो और जीतो' है; एब्सट्रैक्शन घटक को उसके बाहरी व्यवहार से देखता है
• फंक्शनल एब्सट्रैक्शन स्ट्रक्चर्ड डिजाइन का आधार है; डेटा एब्सट्रैक्शन ऑब्जेक्ट-ओरिएंटेड डिजाइन का
• प्रणाली मॉड्यूलर है जब एक घटक के बदलाव का दूसरों पर न्यूनतम प्रभाव हो
• स्ट्रक्चर चार्ट में मॉड्यूल बॉक्स हैं; बुलाने वाले मॉड्यूल सुपरऑर्डिनेट और बुलाए गए सबऑर्डिनेट हैं
• चार प्रकार के मॉड्यूल हैं: इनपुट, आउटपुट, ट्रांसफॉर्म और कोऑर्डिनेट

अर्थात् आप समस्या को बाँटते हैं, और हर भाग का एब्सट्रैक्शन करते हैं।

3

COUPLING AND COHESIONकपलिंग और कोहेशन

COUPLING is the degree of interaction between modules. COHESION is how closely the tasks inside one module are related.

• Good modules have LOW COUPLING and HIGH COHESION
• COHESION, worst to best: COINCIDENTAL, LOGICAL, TEMPORAL, PROCEDURAL, COMMUNICATIONAL, FUNCTIONAL
• FUNCTIONAL cohesion: every element serves one well-defined task. COINCIDENTAL: the elements are unrelated
• COUPLING, worst to best: CONTENT, COMMON, CONTROL, STAMP, DATA
• DATA coupling passes parameters; CONTENT coupling lets one module alter another's data

You should be able to place any type on these two scales. So the best is functional cohesion with data coupling.कपलिंग मॉड्यूलों के बीच पारस्परिक क्रिया की मात्रा है। कोहेशन यह है कि एक मॉड्यूल के भीतर के कार्य आपस में कितने संबंधित हैं।

• अच्छे मॉड्यूलों में कम कपलिंग और उच्च कोहेशन होता है
• कोहेशन, सबसे खराब से सबसे अच्छा: कोइंसिडेंटल, लॉजिकल, टेम्पोरल, प्रोसीजरल, कम्युनिकेशनल, फंक्शनल
• फंक्शनल कोहेशन: हर तत्व एक सुपरिभाषित कार्य करता है। कोइंसिडेंटल: तत्व असंबंधित हैं
• कपलिंग, सबसे खराब से सबसे अच्छा: कंटेंट, कॉमन, कंट्रोल, स्टैम्प, डेटा
• डेटा कपलिंग पैरामीटर भेजती है; कंटेंट कपलिंग एक मॉड्यूल को दूसरे का डेटा बदलने देती है

आपको किसी भी प्रकार को इन दोनों पैमानों पर रख पाना चाहिए। अर्थात् सबसे अच्छा है फंक्शनल कोहेशन के साथ डेटा कपलिंग।

4

STRUCTURED PROGRAMMINGस्ट्रक्चर्ड प्रोग्रामिंग

STRUCTURED PROGRAMMING is a procedural design concept from the work of DIJKSTRA and others in the late 1960s.

• It is also called GOTO-LESS programming
• It uses simple constructs with a SINGLE ENTRY and a SINGLE EXIT
• It forbids GOTO, a break or continue out of the middle of a loop, and multiple entry or exit points
• It reduces complexity, and improves readability, testability and maintainability

Its opposite is SPAGHETTI CODE, whose control flow is tangled like spaghetti. So you build programs from sequence, decision and iteration only.स्ट्रक्चर्ड प्रोग्रामिंग 1960 के दशक के अंत में डाइकस्ट्रा और अन्य के कार्य से आई प्रक्रियात्मक डिजाइन अवधारणा है।

• इसे गोटो-रहित प्रोग्रामिंग भी कहते हैं
• यह एकल प्रवेश और एकल निकास वाली सरल संरचनाओं का उपयोग करती है
• यह गोटो, लूप के बीच से break या continue, और कई प्रवेश या निकास बिंदु वर्जित करती है
• यह जटिलता घटाती है, और पठनीयता, परीक्षणीयता और रखरखाव सुधारती है

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

5

SCREEN, REPORT AND MENU DESIGNस्क्रीन, रिपोर्ट और मेनू डिजाइन

Your user meets the system through its screens, reports and menus, so their design decides how easily it is used.

• SCREENS: keep the layout consistent, order the fields as on the source form, and give sensible defaults
• Validate each entry where it is made, with a clear message that says how to correct it
• REPORTS: give a title, date and page number, column headings, and sub-totals and totals at each break
• MENUS: group related options, keep the hierarchy shallow, and offer shortcut keys to frequent users

Modular application design builds each screen and report as a separate module. So a good interface is consistent, validated and quick to navigate.आपका उपयोगकर्ता प्रणाली से उसकी स्क्रीनों, रिपोर्टों और मेनू के माध्यम से मिलता है, इसलिए इनका डिजाइन तय करता है कि उपयोग कितना आसान है।

• स्क्रीन: लेआउट एक-सा रखें, फील्डों का क्रम स्रोत प्रपत्र जैसा रखें, और उचित डिफॉल्ट मान दें
• हर प्रविष्टि वहीं सत्यापित करें, स्पष्ट संदेश के साथ जो बताए कि उसे कैसे सुधारें
• रिपोर्ट: शीर्षक, तिथि और पृष्ठ संख्या, कॉलम शीर्षक, और हर विराम पर उप-योग और योग दें
• मेनू: संबंधित विकल्प एक साथ रखें, पदानुक्रम उथला रखें, और नियमित उपयोगकर्ताओं को शॉर्टकट कुंजियाँ दें

मॉड्यूलर एप्लिकेशन डिजाइन हर स्क्रीन और रिपोर्ट को अलग मॉड्यूल के रूप में बनाता है। अर्थात् अच्छा इंटरफेस एकरूप, सत्यापित और तेजी से चलने योग्य होता है।