আমরা কেন আরও কার্যকরভাবে সফ্টওয়্যারটির নকশা ক্যাপচার করতে পারি না? [বন্ধ]


14

ইঞ্জিনিয়ার হিসাবে, আমরা সবাই "নকশা" শিল্পকলা (বিল্ডিং, প্রোগ্রাম, সার্কিট, অণু ...)। এটি এমন একটি ক্রিয়াকলাপ (ডিজাইন-দ্য ক্রিয়া) যা কিছু প্রকারের ফলাফল (নকশা-বিশেষ্য) তৈরি করে।

আমি মনে করি আমরা সকলেই একমত যে ডিজাইন-দ্য বিশেষ্যটি শিল্পকলাটির চেয়ে পৃথক সত্তা।

সফ্টওয়্যার ব্যবসায়ের একটি মূল ক্রিয়াকলাপ (প্রকৃতপক্ষে, যে কোনও ব্যবসায় যেখানে ফলাফলের পণ্যসম্পদগুলি বাড়ানো দরকার) হ'ল "নকশা (বিশেষ্য)" বোঝা। তবুও আমরা মনে করি একটি সম্প্রদায় হিসাবে এটি রেকর্ডিংয়ে বেশ সম্পূর্ণ ব্যর্থতা হতে পারে, যেমন প্রমাণিত হয়েছে যে লোকেরা তাদের কোড বেস সম্পর্কে তথ্য আবিষ্কারের ক্ষেত্রে কী পরিমাণ প্রচেষ্টা করেছে। কাউকে তাদের কোডের ডিজাইন দেখাতে বলুন এবং আপনি কী পান তা দেখুন।

আমি মনে করি সফ্টওয়্যারটির জন্য একটি নকশা রয়েছে:

  • সফ্টওয়্যারটি কী করণীয় এবং এটি কতটা ভাল করে তার জন্য একটি স্পষ্ট স্পেসিফিকেশন
  • কোডটির একটি স্পষ্ট সংস্করণ (এই অংশটি সহজ, প্রত্যেকের কাছে এটি রয়েছে)
  • কোডটির প্রতিটি অংশ স্পেসিফিকেশন অর্জনে কীভাবে কাজ করে তার একটি ব্যাখ্যা (উদাহরণস্বরূপ, নির্দিষ্ট অংশ এবং কোড টুকরাগুলির মধ্যে একটি সম্পর্ক)
  • কোডটি কেন এমনভাবে হয় তার একটি যুক্তি (যেমন, কেন অন্যের চেয়ে কোনও নির্দিষ্ট পছন্দ)

নকশা কী নয় তা কোডের একটি নির্দিষ্ট দৃষ্টিভঙ্গি। উদাহরণস্বরূপ [বিশেষভাবে বাছাই করা নয়] ইউএমএল চিত্রগুলি ডিজাইন নয় not পরিবর্তে, এগুলি এমন বৈশিষ্ট্য যা আপনি কোড থেকে উত্পন্ন করতে পারেন, বা তর্কসাপেক্ষভাবে, এমন বৈশিষ্ট্য যা আপনি ইচ্ছে করেন যে আপনি কোডটি থেকে পেতে পারেন। তবে সাধারণ নিয়ম হিসাবে, আপনি ইউএমএল থেকে কোডটি অর্জন করতে পারবেন না।

এটি কেন যে বিল্ডিং সফটওয়্যারটির 50+ বছর পরে, কেন আমাদের এটি প্রকাশ করার নিয়মিত উপায় নেই? (স্পষ্ট উদাহরণ দিয়ে আমার সাথে দ্বিধায় দ্বিধা বোধ করুন!)

যদিও আমরা তা করি, সম্প্রদায়ের বেশিরভাগ লোক "কোড" পাওয়ার দিকে এতটাই মনোযোগী বলে মনে হয় যে নকশা-বিশেষ্যটি যে কোনওভাবেই হারিয়ে যায়। (আইএমএইচও, যতক্ষণ না ডিজাইন ইঞ্জিনিয়ারিংয়ের উদ্দেশ্য হয়ে ওঠে, ডিজাইন থেকে নিদর্শনগুলি বের করে নেওয়া পর্যন্ত, আমরা এটির কাছাকাছি যাব না)।

রেকর্ডিং ডিজাইনের অর্থ হিসাবে আপনি কী দেখেছেন (অর্থে আমি এটি বর্ণনা করেছি)? কাগজপত্রের স্পষ্ট উল্লেখ উল্লেখ করা ভাল। আপনি কেন নির্দিষ্ট এবং সাধারণ উপায়গুলি সফল হয়নি বলে মনে করেন? কীভাবে আমরা এটি পরিবর্তন করতে পারি?

[আমার নিজের ধারণাগুলি রয়েছে যে উপরের বুলেটযুক্ত দৃষ্টিভঙ্গিটি প্রকাশিত হয়েছে, তবে আমি অন্য লোকের জবাবগুলিতে আগ্রহী ... এবং আমার স্কিম বাস্তবায়ন করা কঠিন [[এবং সম্ভবত এটিই আসল সমস্যা: -]]]]

সম্পাদনা 2011/1/3: একটি উত্তর-থ্রেড ইঙ্গিত দেয় যে "ডকুমেন্টেশন" (সম্ভবত পাঠ্যসূচী, বিশেষত অনানুষ্ঠানিক) পর্যাপ্ত হতে পারে। আমি অনুমান করি আমার পরিষ্কার করা উচিত যে আমি এটি বিশ্বাস করি না। সিএএসই সরঞ্জামগুলি 80 এর দশকে শুরু হওয়া দৃশ্যে উপস্থিত হয়েছিল, তবে প্রাথমিক সরঞ্জামগুলি বেশিরভাগই স্রেফ পিক্সেলগুলি আপনার আঁকির ডায়াগ্রামের জন্য গ্রহণ করেছিল; যদিও সরঞ্জামগুলি বিতর্কিতভাবে বাণিজ্যিকভাবে সফল হয়েছিল, তারা আসলে খুব বেশি সহায়ক ছিল না। একটি মূল অন্তর্দৃষ্টি ছিল, অতিরিক্ত "ডিজাইন" শিল্পকর্মগুলি যদি আনুষ্ঠানিকভাবে ব্যাখ্যাযোগ্য না হয় তবে আপনি কোনও গুরুতর সরঞ্জাম সহায়তা পেতে পারেন না can't আমি বিশ্বাস করি যে একই অন্তর্দৃষ্টি ডিজাইন ক্যাপচারের যে কোনও দীর্ঘমেয়াদী দরকারী ফর্মের জন্য প্রযোজ্য: এটি যদি কোনও আনুষ্ঠানিক কাঠামো না পায়, তবে এটি কোনও বাস্তব কাজে আসবে না। পাঠ্য নথিগুলি বেশিরভাগই এই পরীক্ষায় ব্যর্থ হয়।


1
ইউএমএলে সম্মত হয়েছেন - সর্বোত্তমভাবে একটি যোগাযোগ সরঞ্জাম, ডিজাইনের বিবরণে অবদান রাখছে, তবে নকশায় নিজেরাই নয়। সবচেয়ে খারাপ, যদিও, ইউএমএল হ'ল গ্রাফিকাল উত্স কোড।
স্টিভ 314

"এটি কতটা ভাল করে"
স্টিভেন এ। লো

আমি যখন সিস্টেমগুলি তৈরি করি, তখন আমি অনেকগুলি "অযৌক্তিক" প্রয়োজনীয়তা পূরণ করি: এই ভাষায় কোডেড , সেই ডাটাবেসটি ব্যবহার করে, 100mS গড় প্রতিক্রিয়া সময় সহ 1E10 রেকর্ড পরিচালনা করে, ... আপনি এগুলিকে স্পেসিফিকেশন থেকে ছাড়তে পারবেন না। (অযৌক্তিক প্রয়োজনীয়তা ব্যতীত চিরকালীন লুপ কোনও কার্যকরী অনুষঙ্গের জন্য একটি প্রসূত প্রোগ্রাম)। "ডিজাইন" ক্যাপচার সম্পর্কে আমার পুরো বিষয়টি হ'ল অন্য অ-কার্যকারিতা প্রয়োজন: "রক্ষণাবেক্ষণযোগ্য"।
ইরা

আপনার আলোচনাটি আকর্ষণীয় দেখায় তবে আমি এখনও ঠিক জানি না যে প্রশ্নটি ঠিক কী। আপনি কি মনে করেন যে আপনি কোনও দৃ in় উদাহরণের মতো কিছু দেওয়ার চেষ্টা করতে পারেন বা আপনি ঠিক কীভাবে আগ্রহী তা স্পষ্ট করে দেওয়ার জন্য। আমি এফএফটি উদাহরণের মতো এমন কিছু সম্পর্কে ভাবছি যেখানে আপনি নিজের প্রশ্নের 4 টি বুলেট পয়েন্টের পুরো চিত্রটি দিতে পারতেন যেমন আপনি সেগুলি দেখেন এবং ফলাফলগুলি একবার ধারণ করার পরে আপনি কী ধরণের জিনিসগুলি করতে চান maybe
n1ckp

আমি এই সমস্যাটির কৌতুক সম্পর্কে কোন ধারণা রাখি না, তবে এটি ফ্রেড ব্রুকস '' ডিজাইনের নকশা 'এর বিষয় । (আপনি যদি ইতিমধ্যে পরিচিত হন তবে ক্ষমা প্রার্থনা করুন।) তিনি প্রোগ্রামিং এবং আর্কিটেকচারের উদাহরণগুলি নিয়ে আলোচনা করেন। তিনি বিশেষত নোট করেছেন যে র্যাশনালগুলি ক্যাপচার করা (উভয় ডিজাইনের জন্য এবং বিকল্প নকশাকে প্রত্যাখ্যান করা) সত্যিই দরকারী, এবং বর্তমান সরঞ্জামগুলির দ্বারা ভালভাবে পরিবেশন করা হয়নি।
পল ডি ওয়েট

উত্তর:


8

আমি মনে করি যে আমরা এখনও এই ক্ষেত্রে ভাল না হওয়ার বেশ কয়েকটি কারণ রয়েছে।

  1. লোকেরা দীর্ঘকাল ধরে যদিও সফ্টওয়্যারটি ঘরের মতো ছিল এবং নির্মাণ থেকে প্রক্রিয়া এবং আইডিয়া ব্যবহার করছিল। "সফ্টওয়্যার আর্কিটেক্ট" একটি শিরোনাম ছিল যা সমস্ত প্রোগ্রামাররা চেয়েছিল। গত দশ বছরে সফটওয়্যার স্থপতি প্রায় মারা গেছেন। জলপ্রপাত প্রক্রিয়াগুলির ধারণা যেখানে আপনার প্রথমে একজন স্থপতি রয়েছে যা বলছে যে সফ্টওয়্যারটি কীভাবে কাজ করবে এবং দেখতে হবে এবং তারপরে লোকেরা কীভাবে এটি নির্মাণ করা উচিত তার চিত্র চিত্র তৈরি করে এবং শেষ পর্যন্ত কোড বানরকে এই দুর্দান্ত কর্মপ্রবাহগুলি / ইউএমএল ডায়াগ্রামগুলি প্রয়োগ করতে পারে, এই ধারণাটি এই এখন ব্যাপকভাবে বিদ্রূপ। সুতরাং বাস্তবে, পুরো শিল্পটি 40 বছর ধরে ভুল পথে ঝাঁপিয়ে পড়েছিল।

  2. আমরা ক্রমাগত যে সরঞ্জামগুলি ব্যবহার করি তা পরিবর্তন এবং উন্নত করে। প্রোগ্রামিং একটি লজিকাল ধাঁধা এবং আমরা সেই ধাঁধাটি বিমূর্ত করার এবং এটিকে বোধগম্য করার জন্য আরও ভাল ধারণা এবং কৌশল নিয়ে আসি। আমরা যেভাবে মডেল করি এটি অবশ্যই একই গতিতে বিকশিত হওয়া উচিত তবে এটি পিছনে gs প্রোগ্রামিং ধাঁধা বিমূর্ত করার উন্নত কৌশলগুলি এর অর্থ আমরা জটিলতা বাড়াতে পারি। এবং তাই আমরা কি। প্রোগ্রামিং হ'ল প্রোগ্রামার হ'ল জটিলতাগুলির কিনারায় থাকে program

  3. প্রোগ্রামটি বর্ণনা করার উপায়গুলি তৈরি করা এক প্রকার বিমূর্ততা। আমরা যদি সফ্টওয়্যারটিকে বিমূর্ত করার ভাল উপায় নিয়ে আসতে পারি, আমরা সেই বিমূর্তিটি সরাসরি বিকাশের সরঞ্জামগুলিতেও রাখতে পারি, এবং সেইজন্য প্রোগ্রামিংয়ে আরও একটি বিমূর্ততা / সরলকরণ যুক্ত করতে পারি। এটি বহুবার ঘটেছে। এই জাতীয় বিমূর্ততার উদাহরণগুলি হ'ল ফাংশন, ক্লাস এবং গ্রন্থাগার।

  4. অতএব; আপনার যদি সফ্টওয়্যারটির একটি সফল এবং সঠিক মডেল থাকে তবে সেই মডেলটি সফ্টওয়্যারটির সমতুল্য হবে । কোন ধরণের পুরো প্রচেষ্টাটি অর্থহীন করে তোলে, যার ফলে উপরে 1 পয়েন্টটি সংক্ষিপ্ত করে: সফ্টওয়্যারটির মডেলিং করা আগের তুলনায় অনেক কম কার্যকর। কোড থেকে সফ্টওয়্যার সম্পর্কিত ডেটা উত্তোলনের পরিবর্তে এটি আরও ভাল। কোডটি আসলে কীভাবে দেখায় তা থেকে একটি ইউএমএল মডেল তৈরি করা একটি ইউএমএল মডেল তৈরি করা এবং তাত্ত্বিক মডেলটি বাস্তবায়নের চেষ্টা করার চেয়ে অনেক বেশি আলোকিত।


2
আপনার শেষ পয়েন্টের সাথে একমত নন। হ্যাঁ, এটি সফ্টওয়্যারটির তুলনায় সমতুল্য হবে, তবে আসল সফ্টওয়্যারটির রিফ্যাক্টর করার চেয়ে কোনও মডেল পুনরায় আঁকানো এখনও সহজ when আমি ডিজাইনিং পদক্ষেপের গুরুত্বকে অবমূল্যায়ন করব না।
জোরিস মেয়েস

1
@ জরিস মাইস: সমস্যাটি হ'ল আপনি এটিকে বাস্তবায়ন না করা অবধি জানেন না কী এবং কোনটি ভাল ধারণা নয়। (তুচ্ছ ঘটনা ব্যতীত তবে তবে আপনার কোনও ইউএমএল ডায়াগ্রামের ব্যবহার আর হবে না)। এছাড়াও রিফ্যাক্টর কোডটি করা আপনার পক্ষে কতটা কঠোর তা পর্যালোচনা করা উচিত নয়। আমি এক্সপি এবং টেস্ট চালিত ডিজাইনের কেন্ট বেকস বই পড়ার পরামর্শ দিই।
লেনার্ট রেজেব্রো

@ লেনার্ট: টিপস টিপসের জন্য
জোরিস

2
@ লেনার্ট: আপনার এবং কাজের মধ্যে পার্থক্য হ'ল আপনি একমত হয়েছেন বলে মনে হয় যে কোনও স্পেসিফিকেশনটি কোনওরকমভাবে প্রকাশ করা প্রয়োজন হতে পারে, যদিও আমি জানি না যে আপনার বর্তমানে-প্রোগ্রামযোগ্য বিমূর্তির সেটটি কীভাবে এটি করে। তবে কল্পনা করুন যে আমার একটি সংকেত প্রক্রিয়াকরণ প্রোগ্রামের দরকার যা মূল ফ্রিকোয়েন্সিগুলি বের করে। লক্ষ্য করুন আমি কীভাবে পরামর্শ দিইনি। আপনি একটি ফাস্ট ফুরিয়ার ট্রান্সফর্ম ব্যবহার করার সিদ্ধান্ত নিতে পারেন এবং আমি অবশ্যই সমস্ত কোডে এফএফটি বিট প্রয়োগ করে এমন পদক্ষেপগুলি খুঁজে পাব। তবে আপনি কোথায় এফএফটি স্পষ্টভাবে রেকর্ড করার সিদ্ধান্ত নিয়েছেন? আমি বিশ্বাস করি আপনার পাঠক সর্বজ্ঞ না হলে আপনার এটি প্রয়োজন।
ইরা বাক্সটার

1
@ ইরা বাক্সটার: কীভাবে "আমরা এফএফটি দিয়ে সিগন্যাল প্রসেসিং প্রয়োগ করতে বেছে নিয়েছি"? উত্স কোডে মন্তব্য রয়েছে, আপনি জানেন। এবং আমি এটি একটি README ফাইলেও লিখতে পারি। স্পেসিফিকেশন স্পষ্ট অভিব্যক্তি কোড হয়। "আমরা এফএফটি বুদ্ধিমানের সাথে এটি প্রয়োগ করেছিলাম" এর মতো পাঠ্য লাইনগুলি সুস্পষ্ট নয়, বা আপনার মূল পোস্টের অর্থে নকশাও নয়। এটি বাস্তবায়নের ডকুমেন্টেশন। মনে হয় আপনি বিতর্কিত মোডে এসে পৌঁছেছেন, তবে আপনি কীসের বিরুদ্ধে তর্ক করার চেষ্টা করছেন তা আমি বুঝতে পারি না।
লেনার্ট রেজেব্রো

5

আপনি সফ্টওয়্যার সনাক্তকরণের সাহিত্য পর্যালোচনা করতে আগ্রহী হতে পারে। কোনও নির্দিষ্ট ক্রমে:

  • কিউবারিক, ডি।, মার্ফি, জিসি, সিঙ্গার, জে, এবং বুথ কেলগ, এস হিপিক্যাট: সফ্টওয়্যার বিকাশের জন্য একটি প্রকল্পের স্মৃতি। সফ্টওয়্যার ইঞ্জিনিয়ারিং 31, 6 (2005), 446–65 এ লেনদেন।
  • টাঙ্গ, এ।, বাবার, এমএ, গর্টন, আই।, এবং হান, জে। আর্কিটেকচার ডিজাইনের যৌক্তিকতার ব্যবহার এবং ডকুমেন্টেশনের একটি সমীক্ষা। সফটওয়্যার আর্কিটেকচারের উপর 5 তম ওয়ার্কিং আইইইই / আইএফআইপি সম্মেলনের প্রোক ইন (2005)।
  • রামেশ, বি।, বিদ্যুৎ, টি।, স্টুববিস, সি, এবং এডওয়ার্ডস, এম। প্রয়োজনীয়তাগুলি সনাক্তকরণের কার্যকরকরণ: একটি কেস স্টাডি। ইন প্রস ইন ইন'ল সিম্প অন রিকোয়ারমেন্টস ইঞ্জিনিয়ারিং (ইয়র্ক, 1995)
  • হার্নার, জে।, এবং অ্যাটওয়ড, এমই ডিজাইনের যুক্তি: যুক্তি এবং বাধা। মানব-কম্পিউটার মিথস্ক্রিয়া সম্পর্কিত চতুর্থ নর্ডিক সম্মেলনের প্রোক ইন: পরিবর্তনশীল ভূমিকা (অসলো, নরওয়ে, 2006)
  • ক্লেল্যান্ড-হুয়াং, জে।, সেটটিমি, আর।, রোমানোভা, ই।, বেরেনবাচ, বি।, এবং ক্লার্ক, এস। স্বয়ংক্রিয় ট্রেসেবিলিটির জন্য সেরা অনুশীলন। কম্পিউটার 40, 6 (জুন 2007), 27-35।
  • অ্যাসুনসিওন, এইচ।, ফ্রানোয়াইস, এফ। এবং টেলর, আরএন একটি শেষ-থেকে-শেষ শিল্প সফটওয়্যার ট্রেসেবিলিটি সরঞ্জাম। সফটওয়্যার ইঞ্জিনিয়ারিং এর ফাউন্ডেশন (ইএসইসি / এফএসই) এর এসিএম সিগসফ্ট ইন্ট'ল সিম্পের (ডাব্রোভনিক, ২০০)) ইউরোপীয় সফটওয়্যার ইঞ্জি কনফ এবং AC ষ্ঠ যৌথ সভার প্রোকে।

মনে রাখবেন এটি আইসবার্গের কেবলমাত্র টিপ, এবং আমি নিশ্চিত যে আমি কিছু মূল কাগজপত্র রেখেছি।

একটি পৃথক নোটে, আর্কামে আমার নিজের কাজটি প্রোগ্রামারদের আইডিইকে ক্রসকাটিং ডিজাইনের আইডিয়ামগুলির ব্যবহারটি প্রকাশ করার একটি মাধ্যম ছিল। একবার প্রকাশ করা হলে, প্রোগ্রামাররা তারপরে বিকল্প বাস্তবায়নগুলি ব্যবহার করতে তাদের উত্স কোডটি রূপান্তর করতে পারে:

ঘটনাচক্রে, আরকুম আপনার ডিএমএস কাজের সাথেও সম্পর্কিত।


1
এই জন্য +1। রিটুইট সবকিছু নয়, কিন্তু এটি আসলে দিকে বিভিন্ন ইতিবাচক পদক্ষেপ এক সমাধানে সমস্যা পরিবর্তে এটির জন্য একই বয়সী অজুহাত করে।
অ্যারোনআউট

2

ইউএমএল হ'ল একটি হামলার পরিকল্পনাতে একটি বিল্ডিংয়ের পরিকল্পনা কী। একা পরিকল্পনাগুলি কোনও ডিজাইনের বাইরে নয়, এর জন্য আপনার প্রয়োজনীয় সামগ্রীর স্পেসিফিকেশন (ব্যবহৃত কোড সরঞ্জামগুলি) প্রয়োজন, বিল্ডিংয়ের একটি সাধারণ ভিউ (জিইআইআই ডিজাইন সহ পুরো সফটওয়্যারটির কিছু পরিকল্পনামূলক উপস্থাপনা), আশপাশে কীভাবে ভবনটি রোপণ করা হয় need (সফ্টওয়্যারটি অন্যের সাথে কীভাবে যোগাযোগ করে / ওএসের মধ্যে রোপণ করা হয় তার একটি পরিষ্কার পরিকল্পনা), কীভাবে এটি জলবায়ু এবং মাটির দিকে দাঁড়ায় (হার্ডওয়্যারের সাথে মিথস্ক্রিয়া), ... ডিজাইনের প্রচুর বইগুলি এটি সংজ্ঞায়িত করার চেষ্টা করে, তবে যেমন রয়েছে বিজ্ঞানের অনেক কিছুই, প্রতিটি বিজ্ঞানীর নিজস্ব নিজস্ব সংজ্ঞা থাকে।

এখন, আমি আপনার পর্যবেক্ষণের সাথেও একমত নই যে আপনি ইউএমএল থেকে কোডটি অর্জন করতে পারবেন না। আপনি যদি অতিরিক্ত তথ্য উল্লেখ করেন তবে আপনি তা করতে পারেন। কিন্তু আসল কোডটি আর কোনও নকশা নয়, এটি হস্তনির্মিত। আপনি কোনও পরিকল্পনা থেকে আসল পাথর এবং কংক্রিট বের করতে পারবেন না, তবে আপনার সত্যিকারের পাথর এবং কংক্রিটকে সঠিক ফর্ম এবং সঠিক জায়গায় রাখার পরিকল্পনা দরকার।

এই আলোকে, আমি নিম্নলিখিত নিবন্ধটি আকর্ষণীয় পেয়েছি (আমি যখন গ্রাফ সফ্টওয়্যারটি খুঁজছিলাম তখন এটি অন্য প্রসঙ্গে দেখা হয়েছিল, তবে তবুও ...)। ডিজাইন বর্ণনা করার গ্রাফ পদ্ধতির বিষয়টি আমার কাছে বোধগম্য হয়েছে, যদিও -আজ্ঞান- এটি আমার মতে ডিজাইনের একটি অংশ মাত্র। মজার বিষয় হ'ল এই পদ্ধতিটি নীচের কাগজগুলিতে ইঙ্গিত অনুসারে (সফ্টওয়্যারটির রিফ্যাক্টারের বিপরীতে) ডিজাইনগুলি বোঝার এবং রিফ্যাক্টর ডিজাইনগুলির কাঠামো দেয়:

স্ট্রাকচার্ড ডিজাইন (এইচআইপিও চার্ট) বা ইন্টিগ্রেটেড প্রোগ্রাম ডিজাইন , ডিজাইনের নিদর্শনগুলির মতো নকশাকে বর্ণনা করার (অন্যান্য অংশ) বর্ণনা করার জন্য আরও অনেকগুলি পন্থা রয়েছে ...

তবুও, যতক্ষণ না কোনও শিল্পের মান সেট নেই, এটি প্রকাশ করার জন্য "নিয়মিত" উপায় পাওয়ার সম্ভাবনা কম। এমনকি 50+ বছর পরেও। এবং সত্য কথা বলুন, যদি আপনার সংস্থা কোনও ডিজাইন প্রকাশের জন্য ভাল উপায় খুঁজে পায়, তবে আপনি কি এটি বিশ্বের সাথে ভাগ করে নেবেন?


যদি আপনার সংস্থাটি এটি করার কোনও ভাল উপায় খুঁজে পায় তবে প্রোগ্রামাররা দ্রুত সবাইকে খুব সুন্দরভাবে জানান। :-)
লেনার্ট রেজেব্রো

আমি মনে করি আপনি ইউএমএল (এবং অন্য কোনও "একক" স্বরলিপি) সম্পর্কে আমার বক্তব্য মিস করেছেন। ইউএমএল-আগে-কোড আপনি কীভাবে সফ্টওয়্যারটি তৈরি করতে চান তার একটি সীমাবদ্ধতা। অন্যান্য সমস্ত স্বরলিপিগুলিও (হ্যাঁ, আমি এগুলি অনেকগুলি দেখেছি, আমি কিছুক্ষণের কাছাকাছি এসেছি)। একটি বাধা দেওয়া হয়েছে, তত্ক্ষণাত্ এই সীমাবদ্ধতার কোড কোড তৈরি করা সম্ভব (তামাশার পদ্ধতি: সমস্ত সম্ভাব্য প্রোগ্রাম তৈরি করুন এবং কোনটি সীমাবদ্ধতার সাথে মেলে তা পরীক্ষা করে দেখুন, সেগুলির মধ্যে একটি চয়ন করুন)। এই অর্থে আপনি "ইউএমএল থেকে কোড উত্পন্ন করতে পারেন"। তবে (আমরা যদি ক্লাস ডায়াগ্রামগুলিতে লেগে থাকি) সেই কোডটি আপনার
ইরা বাক্সার

... এবং অন্যান্য নোটেশনাল স্কিমগুলির বেশিরভাগ এটির দ্বারা ভুগছে, প্রোগ্রামটি কী করণীয় সেটির একটি স্পেসিফিকেশন তারা সত্যই ক্যাপচার করে না। তারা যুক্তির মতো কিছু সরবরাহ করে না; আপনার ইউএমএলটি এটির আকারটি কেন ? চার্টটি না ভেঙে আমি কোডের কোন অংশটি পরিবর্তন করতে পারি? আমি কি এমনভাবে পরিবর্তন করতে পারি যা চার্টের পিছনের উদ্দেশ্যটির ক্ষতি করে না?
ইরা

@ ইরা: আপনার ওয়েবপৃষ্ঠাটি দেখার পরে এটি আমার কাছে আরও স্পষ্ট হয়ে উঠেছে। তবে আমাকে স্বীকার করতে হবে যে এই বিষয়গুলিতে একটি উচ্চ-স্তরের অর্থপূর্ণ আলোচনা আমার দক্ষতার বাইরে। তবুও, যদি আপনি বিবেচনা বাস্তব নকশা অংশ হিসাবে কোড, তারপর যেখানে প্রকৃত হস্তনির্মিত বস্তু কি? ইউএমএল-অথবা অন্য কোনও স্বীকৃতি- আমার বিনীত মতে কোড কাঠামোর একটি নীলনকশা এবং এটিই আমি ডিজাইনের অংশটিকে কল করতে পছন্দ করি । প্রকৃত কোডের চেয়ে বেশি। কিছু মনে অংশ । এটি নকশা নয়, তবে এটির জন্য এখনও একটি প্রয়োজনীয় অবদান। আবার, আমার নম্র মতামত। যুক্তি ইত্যাদিতে বর্ণিত হিসাবে যুক্ত করা যেতে পারে।
জোরিস মেয়েস

@ জরিস: বেশিরভাগ ডায়াগ্রাম্যাটিক স্বরলিপিগুলি কোড থেকে অনুমান (অনুমানকৃত নিদর্শন) হিসাবে বিবেচনা করা যেতে পারে (কমপক্ষে এটি শেষ হওয়ার পরে) বা কোড তৈরি করার জন্য নীল নির্দেশিকা হিসাবে বিবেচনা করা যেতে পারে (নীলনকশা)। সম্ভাব্য চিত্রগুলি প্রচুর আছে (কিছু আপনার উত্তরে তালিকাভুক্ত)। আপনার কোডগুলির জন্য কোনটি মৌলিক এবং কোনটি কেবল দুর্ঘটনা? ফ্লোচার্টগুলি ডিগ্রগ্রাম, তাই তাদের যোগ্য হওয়া উচিত; তবুও আমি যথেষ্ট আত্মবিশ্বাসী যে কোনও কোড খণ্ডের ফ্লোচার্টগুলি এর নকশার অংশ হিসাবে বিবেচিত হবে না । সুতরাং, মৌলিক কি? দুর্ঘটনা কী?
ইরা

2

আমার নিজের ব্যক্তিগত অভিজ্ঞতা থেকে, আমি যুক্তি দিয়ে বলব যে আমরা সফ্টওয়্যারটির নকশাটি ভালভাবে ধারণ করি। আমরা আমাদের প্ল্যাটফর্মে কখনও প্রয়োগ করেছি এমন একক বৈশিষ্ট্যের জন্য আমাদের প্রয়োজনের একটি ডাটাবেস এবং নকশার দলিল রয়েছে। আমি মনে করি আমার পরিস্থিতিটি সম্ভবত অনন্য। যদিও কিছু বিষয় চিন্তা করতে হবে তা এখানে।

আমার দলের প্রতিটি একক ব্যক্তির ইঞ্জিনিয়ারিং ডিগ্রি রয়েছে ... বেশিরভাগই ইই বা সিই হয়। ইঞ্জিনিয়ারিং আপনাকে পাঠ্যক্রমের অংশ হিসাবে নকশা শেখায়।

আমি মনে করি যে অনেকগুলি তথাকথিত সফটওয়্যার প্রকৌশলী যা সিএস ব্যাকগ্রাউন্ড থেকে আসে। সফ্টওয়্যার ডিজাইন বেশিরভাগ সিএস প্রোগ্রামের অবিচ্ছেদ্য অঙ্গ নয়। আমি বলছি না যে সমস্ত সিএস মেজর ডিজাইনে খারাপ, তবে আমি বাজি ধরব যে বেশিরভাগের কোনও আনুষ্ঠানিক শিক্ষা নেই যা তাদের শেখায়। আমি মনে করি অনেক লোক ধরেছে যে আপনি যদি এমন প্রোগ্রাম করতে পারেন যে আপনি সফ্টওয়্যার ডিজাইন করতে পারেন, যা সত্য নয়। অনেক প্রোগ্রামারদের ইঞ্জিনিয়ারিং ব্যাকগ্রাউন্ড না থাকায় এটি আশ্চর্যজনক নয় যে অনেক সফ্টওয়্যার প্রকল্পের একটি দল নেই যা ক্যাপচার ডিজাইনে ভাল।


সুতরাং লেখার প্রয়োজনীয়তা এবং নকশা নথির কোন নির্দিষ্ট পদ্ধতিটি আপনি ব্যবহার করেন? (আমি আপনার বায়োটির দিকে তাকিয়েছিলাম এবং প্রতিরক্ষা স্থান থেকে কাউকে দেখার আশা করছিলাম এবং অবাক হয়েছিলাম) আমি প্রয়োজন অনুসারে ধরে নিয়েছি আপনি কিছু প্রাকৃতিক ভাষার পাঠ্য বোঝাতে চাইছেন? ... যদি তাই হয়, তাদের সম্পর্কে আপনার কোনও যুক্তি নেই? (আমি আনুষ্ঠানিক চশমা থেকে প্রাকৃতিক ভাষা প্রয়োজনীয়তা পৃথক)। তারা কি সম্পূর্ণ? আর ডিজাইনের ডকুমেন্টস? বর্তমানে শিপিং সিস্টেমের জন্য সেগুলি কি সম্পূর্ণ আপডেট রয়েছে? আমি সম্মত হই যে প্রচুর তথাকথিত প্রোগ্রামার এবং সফ্টওয়্যার ইঞ্জিনিয়াররা নন, তাই আমরা কী কী করা উচিত তা নিয়ে আলোচনা করতে পারি।
ইরা বাক্সটার

1
আমি নিশ্চিত না যে আমাদের পদ্ধতির একটি নির্দিষ্ট নাম আছে। আমাদের প্রয়োজনীয়তা হ'ল আমি প্রাকৃতিক ভাষার প্রয়োজনীয়তা এবং একটি উচ্চ স্তরের ডিজাইনের নথিগুলির মধ্যে একটি সংকর কল করব। আমাদের সম্পাদনায় সাধারণত দুটি দফা থাকে। প্রথমত, আমরা সরল ইংরেজিতে কোনও বৈশিষ্ট্যটির কী করা দরকার তা ডকুমেন্ট করি। তারপরে আমরা এটি নির্দিষ্ট করে দেব যে এটি ব্যবহারকারীর দৃষ্টিকোণ থেকে কীভাবে কাজ করবে। নথির দুটি লক্ষ্য রয়েছে। এক, আমরা এমন একটি দস্তাবেজ সরবরাহ করতে চাই যা আমাদের বিপণন দল পর্যালোচনা করতে পারে যাতে আমরা আমাদের ব্যবসায়ের প্রয়োজনীয়তা নিশ্চিত করি। দুই, আমরা এমন একটি দলিল সরবরাহ করতে চাই যা আমাদের কিউএ দলটি এর বিরুদ্ধে পরীক্ষার জন্য ব্যবহার করতে পারে।
পেমদাস

1
আমাদের ডিজাইনের নথিগুলি আরও অনেক আনুষ্ঠানিক এবং বিস্তারিত। এগুলি সর্বদা নিম্নলিখিতটি অন্তর্ভুক্ত করে: কিছু ক্ষেত্রে ব্যবহারের কেস বিশ্লেষণ, ব্যবসায়ের কোনও ব্যাখ্যা বা কারণগুলি আমরা কিছু করার বিশেষ উপায় বেছে নিয়েছি, অন্যান্য ডিজাইনের উল্লেখ, স্পষ্ট ইন্টারফেস সংজ্ঞা, ডেটা স্ট্রাকচার ... ect। নির্দিষ্ট কোড কীভাবে নির্দিষ্ট প্রয়োজনীয়তা পূরণ করে সে সম্পর্কে আমাদের স্পষ্টত মন্তব্য নেই। আমি এটি গুরুত্বপূর্ণ মনে করি কিনা সে সম্পর্কে আমি অনিশ্চিত।
পেমদাস

1
আমি বলব যে আমাদের নথিগুলি 95% আপ টু ডেট। কয়েকটি জিনিস এখানে এবং সেখানে ফাটলগুলি পড়ে যায়।
পেমদাস

2

আমি দুটি সমস্যা দেখতে পাচ্ছি।

প্রথমটি হ'ল কোড এবং ডকুমেন্টেশন সিঙ্কে রাখা রক্তাক্ত সমস্যা। যদি তারা আলাদা হয় তবে তারা ডাইভারেজ করবে এবং ডকুমেন্টেশন অকেজো হয়ে যাবে। প্রোগ্রামাররা তাদের সিঙ্কে রাখার কাজ করার জন্য সরঞ্জামগুলি ব্যবহার করার চেষ্টা করেছে (যেমন সিএএসই-সরঞ্জাম), তবে এই সরঞ্জামগুলি প্রোগ্রামার এবং তাদের কোডের মধ্যে পেয়েছিল যা ভালের চেয়ে বেশি ক্ষতি করেছে। ডোমেন চালিত ডিজাইনের অন্যতম গুরুত্বপূর্ণ অন্তর্দৃষ্টি (ইভান্স, 2004) হ'ল ভাল নকশাটি সত্যই শক্ত, তাই এর থেকে কিছু পাওয়ার জন্য আপনাকে অবশ্যই:

  • আপনার প্রোগ্রামের ক্ষুদ্রতম সম্ভাব্য ক্ষেত্রটি চয়ন করুন যেখানে ভাল ডিজাইনের ফলে দুর্দান্ত সুবিধা পাওয়া যায়, তথাকথিত মূল ডোমেন
  • সমস্ত দলের সদস্যরা সর্বদা ব্যবহার করে যে সর্বব্যাপী ভাষা আকারে একটি ভাল ডিজাইন পেতে সত্যিই কঠোর পরিশ্রম করুন
  • যতটা সম্ভব, নকশার কোডটির অংশ করুন

আমরা যেভাবে ডিজাইন করি তার সাথে অন্য বড় সমস্যাটি হ'ল আমাদের ডিজাইন-পদ্ধতিগুলি যথেষ্ট পরিমাণে গাণিতিক নয়। ফাঁস বিমূর্ততাগুলি তাদের কাছ থেকে দৃlus় সিদ্ধান্ত নেওয়ার জন্য নিজেকে ধার দেয় না এবং কঠোরভাবে প্রয়োগ করা যুক্তি এবং স্পষ্ট সত্যের বিশ্বকে গণিত বলা হয়, যা প্রোগ্রামাররা বেশিরভাগ ক্ষেত্রেই এড়িয়ে চলে।

আমাদের কাছে কয়েকটি গাণিতিক সরঞ্জাম যেমন আনুষ্ঠানিক পদ্ধতিগুলি খুব অযাচিত।

ম্যাপ-হ্রাস প্রোগ্রামিংয়ে গণিতের একটি দুর্দান্ত উদাহরণ। মূল ধারণাটি হ'ল: যখন আপনার কোনও সহযোগী, বাইনারি অপারেশন হয় আপনি খুব সহজেই এর কার্যকরকরণ বিতরণ করতে পারেন। একটি বাইনারি অপারেশন হল দুটি পরামিতি সহ একটি ফাংশন, সাহচর্যতা বোঝায় যে (a + b) + c = a + (b + c)

এ 1 + এ 2 + ... + এ 99 + বি 1 + বি 2 + ... + বি 99 + সি 1 + সি 2 + ... + সি 99

(a1 + a2 + ... + a99) + (বি 1 + বি 2 + ... + বি 99) + (সি 1 + সি 2 + ... + সি 99) যেখানে As, Bs এবং Cs তুচ্ছভাবে বিভিন্ন জায়গায় যুক্ত করা যায়, তাদের ফলাফল সংগ্রহ করা হয়েছে এবং সংক্ষিপ্ত পরিমাণে।

মানচিত্র হ্রাস একটি হাস্যকর সহজ ধারণা। এটি কাগজের এক টুকরোতে বর্ণনা করা যেতে পারে। আপনি যদি ধরে নিতে পারেন যে পাঠক সাহিত্যের ধারণার উপর দৃ gra়ভাবে উপলব্ধি করতে পারেন, তবে যদি কাগজের বেশ কয়েকটি ছোট অংশে ফিট করে। এসোসিয়েটিভিটি শব্দটি ব্যবহার না করে বা পরোক্ষভাবে উল্লেখ না করে কারও কাছে মানচিত্র-হ্রাসের ব্যাখ্যা দেওয়ার চেষ্টা করুন। আমি তোমাকে সাহস করি

গাণিতিক বিমূর্ততা ছাড়াই সফটওয়্যার ডিজাইন হ'ল জ্যামিতি শেখার জন্য বিরক্ত না করে আর্কিটেকচার করার চেষ্টা করার মতো।

হয়তো হাস্কেল সময়ের সাথে এটি ঠিক করতে পারে। প্রোগ্রামগুলি বর্ণনা করতে বিভাগের তত্ত্ব থেকে ধারণাগুলির ব্যবহার আমার কাছে আশাব্যঞ্জক বলে মনে হচ্ছে। বিভাগ তত্ত্বটি এত বিমূর্ত যে এমনকি গণিতবিদরাও এর জন্য খুব কম ব্যবহার করেছিলেন, তবে দৃশ্যত বিভাগগুলি, যা স্বীকৃতির বাইরে বিমূর্ত, এটি সফ্টওয়্যারটির কাঠামো বর্ণনা করার জন্য যথেষ্ট বিমূর্ত বলে মনে হয়। আমরা খুঁজে বের করব। ধীরে ধীরে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.