মডেলিং সফটওয়্যার সিস্টেমগুলি বনাম। কোডে এটি সব করার সুবিধা কী?


20

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

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

এগুলি সবই ডায়াগ্রাম এবং অন্যান্য নথি দিয়ে করা যায় না। হ্যাঁ, এমন সরঞ্জাম রয়েছে যা ইউএমএল পরীক্ষা করে তবে আমি এখন পর্যন্ত যা কিছু দেখেছি তা খুব সীমাবদ্ধ। সুতরাং এই নথিগুলি অসম্পূর্ণ, অসঙ্গতিপূর্ণ বা সরল মিথ্যা হতে থাকে।

এমনকি চিত্রগুলি যদি নিজেরাই সামঞ্জস্যপূর্ণ হয় তবে আপনি নিশ্চিত হতে পারবেন না যে কোডটি আসলে তাদের প্রয়োগ করেছে। হ্যাঁ, কোড জেনারেটর রয়েছে, তবে তারা কখনই সমস্ত কোড জেনারেট করে না।

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

মডেলিং সফটওয়্যার সিস্টেমগুলির জন্য আমার কী যুক্তি অনুপস্থিত?

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

ব্যাখ্যা:

প্রশ্নটি অস্পষ্ট বলে আটকানো হয়েছে। অতএব আমাকে কিছু ব্যাখ্যা যোগ করুন:

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

আমি এই পদ্ধতির কিছু অসুবিধাগুলি তালিকাভুক্ত করেছি যা আমাকে অবাক করে দিয়েছিল যে কেন এত লোক (আমার অভিজ্ঞতায়) এটিকে সফ্টওয়্যার ডিজাইন করার পছন্দনীয় উপায় হিসাবে বিবেচনা করে?



5
আমি মনে করি এটি সম্পূর্ণ বৈধ প্রশ্ন যদি আমাদের মডেলের কোনও মান থাকে তবে এটি কোডের সাথে মিলিয়ে যেতে পারে। তাহলে মডেলটি কেন একই ভাষায় আমরা পরে এটি বাস্তবায়নের জন্য ব্যবহার করব না? তারপরে তারা সর্বদা সিঙ্কে থাকে। এবং যদি আপনি অভিনব গ্রাফিক্স পছন্দ করেন তবে সেগুলি কোড থেকে উত্পন্ন করা যেতে পারে।
রাল্ফ ক্লেবারহফ 21

3
আপনার তখন আরও "আইটি" লোকদের জানা উচিত। অথবা সম্ভবত আমার বলা উচিত, আপনার এই ছাতার মধ্যে আরও সম্প্রদায়ের সাথে পরিচিত হওয়া উচিত।
ডেরেক এলকিন্স

@ ডকব্রাউন: যদিও এই প্রশ্নের উত্তর এবং বিশেষত আপনার মন্তব্যে লিঙ্কিত নিবন্ধগুলি প্রাসঙ্গিক তথ্য সরবরাহ করে, মূল প্রশ্নটি খুব আলাদা।
ফ্রাঙ্ক পাফার

@ ফ্র্যাঙ্কপুফার: আমি এটি সম্পর্কে সচেতন, পুনরায় খুলতে ভোট দিয়েছি। তবুও আমি মনে করি আপনার প্রশ্নের মূল - "সফ্টওয়্যার ডিজাইন কী" এবং "সফ্টওয়্যার ডিজাইনে মডেলিংয়ের ভূমিকা", একটি খুব বিস্তৃত প্রশ্ন, সম্ভবত বোধগম্যভাবে এখানে উত্তর দেওয়া খুব সম্ভবত বিস্তৃত।
ডক ব্রাউন

উত্তর:


23

সমস্ত কোডে মডেলিং সফ্টওয়্যার সিস্টেমগুলির সুবিধা: আমি হোয়াইটবোর্ডে মডেলটি ফিট করতে পারি।

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

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

এর অর্থ এই নয় যে আমি এখন থেকে কোনও ইউএমএল স্কেচ বের করব না। আপনি কোড দেওয়ার আগে আমি কোনও লোকই হবো না যে আপনি ইউএমএল ডকুমেন্টটি চালু করবেন। আমার প্রয়োজন হতে পারে যে আপনি 5 মিনিট সময় নিয়েছেন এবং আপনি কী করছেন তা বোঝানোর জন্য কিছু উপায় খুঁজে বের করুন কারণ আমি কেবলমাত্র একজন ব্যক্তি বোঝে এমন কোডের অস্তিত্বটি দাঁড়াতে পারছি না।

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

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

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


2
"হোয়াইটবোর্ডের সাথে মানানসই বিমূর্তির স্তরে এমন কোনও কোড কেবল নেই" যা একটি আকর্ষণীয় প্রশ্ন নিয়ে আসে। কেন না? কোনও সিস্টেমের এন্ট্রি পয়েন্টের জন্য এটি কী হতে পারে তা খুব উচ্চ স্তরে ব্যাখ্যা করার জন্য সত্য হতে হবে?
রাবারডাক

2
কারণ কোড অবশ্যই সমস্ত লোকের কাছে সমস্ত জিনিস (এবং কমপক্ষে একটি সংকলক)। একটি মডেল একটি মনোযোগী শ্রোতা থাকতে পারে।
candied_orange

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

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

1
"আমি হোয়াইটবোর্ডে মডেলটি ফিট করতে পারি" বলার একটি অত্যন্ত কংক্রিট (দুর্দান্ত!) উপায় "আমি যে দিকটি গুরুত্বপূর্ণ অনুভব করি তা বুঝতে বা যোগাযোগ করতে আরও জটিল যে কোনও বিষয়কে আমি জটিল করতে পারি" " এটি ভাল মডেলিং সাধারণভাবে যা করে তা সে সফ্টওয়্যার বা অন্য যে কোনও জটিল বিষয়।
ফুহরম্যানেটর

6

আমি জিজ্ঞাসা করছি যে সফ্টওয়্যারটিকে সফ্টওয়্যার ডিজাইন সম্পর্কে সত্যের প্রাথমিক উত্স হিসাবে মডেল করে (নন-কোড) নথিগুলি ব্যবহার করা কি বোধগম্য?

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

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

কিছু লোক কোড লেখা শুরু করার আগে ডায়াগ্রাম আকারে তাদের চিন্তাভাবনাগুলি স্কেচ করা দরকারী বলে মনে করে। তবে মনে রাখবেন চাচা বব এই বিষয়ে কী বলেছিলেন:

" তাই, হ্যাঁ, ডায়াগ্রামে অনুপযুক্ত সময়ে হতে পারে। তারা হয় বেঠিক মনে করে? যখন আপনি তাদের কোড ছাড়া তৈরি তাদের যাচাই করতে, এবং তারপর তাদের অনুসরণ মনস্থ। সেখানে একটি ডায়াগ্রাম আঁকার একটি ধারণা অন্বেষণ করতে সঙ্গে কিছুই ভুল। "

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


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

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

5

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

আমি জানিনা যে আপনি জানেন সমস্ত লোকই এটি বিশ্বাস করে, তবে আমি মনে করি না যে এটি বোর্ডের মধ্যে অগত্যা সাধারণ বিষয়। 1970 সালে, উইনস্টন রইস জানতেন যে সফ্টওয়্যার বিকাশের নকশা এবং কোড ক্রিয়াকলাপগুলির মধ্যে কিছুটা পুনরাবৃত্তি রয়েছে। 1992 সালে, জ্যাক রিভস কোডিং সম্পর্কে সত্য নকশা ক্রিয়াকলাপ ( সি 2 উইকিতেও আলোচিত ) লিখেছিলেন

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

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

কোড মিথ্যা বলে না। এটি সংকলক বা দোভাষী দ্বারা পরীক্ষা করা হয়। আশা করি এটি স্বয়ংক্রিয় পরীক্ষা করেছে এবং স্ট্যাটিক কোড বিশ্লেষণ পাস করতে হবে pass যদি কোনও মডিউল অন্য মডিউলের সাথে সঠিকভাবে ইন্টারফেস না করে তবে এটি কোডে সাধারণত স্পষ্ট হয় কারণ আপনি একটি ত্রুটি বার্তা পান।

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

এমনকি চিত্রগুলি যদি নিজেরাই সামঞ্জস্যপূর্ণ হয় তবে আপনি নিশ্চিত হতে পারবেন না যে কোডটি আসলে তাদের প্রয়োগ করেছে। হ্যাঁ, কোড জেনারেটর রয়েছে, তবে তারা কখনই সমস্ত কোড জেনারেট করে না।

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

বিভিন্ন ডিগ্রী রয়েছে এমন বিভিন্ন সরঞ্জাম রয়েছে যা বিভিন্ন ভাষার জন্য এটি সমর্থন করে। ভাষা এবং দৃষ্টান্তগুলির প্রকৃতি দেওয়া, এটি অন্যের তুলনায় কারও পক্ষে সহজ।

আমি এই পদ্ধতির কিছু অসুবিধাগুলি তালিকাভুক্ত করেছি যা আমাকে অবাক করে দিয়েছিল যে কেন এত লোক (আমার অভিজ্ঞতায়) এটিকে সফ্টওয়্যার ডিজাইন করার পছন্দনীয় উপায় হিসাবে বিবেচনা করে?

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

মডেলিং সফটওয়্যার সিস্টেমগুলি বনাম। কোডে এটি সব করার সুবিধা কী?

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


5

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

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

  • ব্যবহারের ক্ষেত্রে ডায়াগ্রামগুলি ব্যবহারকারী বা বাহ্যিক সিস্টেমগুলির সাথে অভিযুক্ত বৈশিষ্ট্য এবং মিথস্ক্রিয়া প্রদর্শন করতে পারে। এখানে চিত্র বর্ণনা লিখুন

  • ক্রিয়াকলাপ ডায়াগ্রামগুলি এমন ব্যবসায়ের প্রক্রিয়াগুলি দেখাতে পারে যা কোনও সফ্টওয়্যারকে সমর্থন করার দরকার হয়। এখানে চিত্র বর্ণনা লিখুন

  • রাষ্ট্রীয় চিত্রগুলি কোনও ওয়েবসাইটে লক্ষ্যযুক্ত গতিশীল দেখায়: এখানে চিত্র বর্ণনা লিখুন

  • গ্যাং অফ ফোর ডিজাইনের নিদর্শনগুলি স্থির এবং গতিশীল মডেল হিসাবে উপস্থাপিত হয়। উদাহরণস্বরূপ, মেমেন্টো:
    এখানে চিত্র বর্ণনা লিখুন
    এখানে চিত্র বর্ণনা লিখুন

আমি এই পদ্ধতির কিছু অসুবিধাগুলি তালিকাভুক্ত করেছি যা আমাকে অবাক করে দিয়েছিল যে কেন এত লোক (আমার অভিজ্ঞতায়) এটিকে সফ্টওয়্যার ডিজাইন করার পছন্দনীয় উপায় হিসাবে বিবেচনা করে?

আপনি যদি আপনার অভিজ্ঞতার বাইরে ইউএমএলের ব্যবহার সম্পর্কে কিছু সত্য তথ্য জানতে আগ্রহী হন তবে কিছু গবেষণা রয়েছে যা হয়েছে (আমি নন-পেওয়াল নিবন্ধগুলির লিঙ্কগুলি সন্ধান করার চেষ্টা করেছি):


0

আমরা বিকাশকারীরা আমাদের বিশ্বকে ব্যাখ্যা করতে চিত্র ব্যবহার করতে পছন্দ করি তাই এখানে একটি গাড়ী উত্পাদন সহ একটি রয়েছে:

  • কোডটি কোডের জন্য একই উত্পাদন পেনের ফলাফল (অবশ্যই মোতায়েনের প্রক্রিয়াটি যুক্ত করুন)।
  • গাড়ির ডিজাইনের ডকুমেন্টটি সফ্টওয়্যারটির ডিজাইনের ডকুমেন্টের মতোই।

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

কোডিং ছাড়াই প্রথমে সেই নথিগুলি তৈরি করে (দ্রুততার পক্ষে ধারণার প্রমাণের মতো কিছু বাদ দিয়ে ...):

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

দ্রষ্টব্য: এইগুলি নিশ্চিত করে মনে করুন যে কোডটি সত্যই ডিজাইনের প্রতিচ্ছবি এবং তারা উভয়ই আপ টু ডেট রাখে ...


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

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