সফল প্রকল্পের জন্য ইউএমএল চিত্রগুলি কতটা গুরুত্বপূর্ণ? [বন্ধ]

Question

আমি একটি প্রকল্পের মাঝখানে আছি এবং আমাকে ইউএমএল ডায়াগ্রাম লিখতে বলা হয়েছিল (কেসগুলি, বর্গের চিত্রগুলি ইত্যাদি ব্যবহার করুন)। প্রকল্পটি খুব জটিল নয়।

আমি ভাবছিলাম এটা কি আমার সময়ের অপচয়? আমি কি কোড লেখার মতো অন্য মজাদার জিনিসগুলি করা উচিত? এবং সমস্ত ধারণাগত পর্যায়ে না গিয়ে যখন কোনও কিছু তৈরি করা ঠিক হয় না তখন? জটিলতা সব কি? এবং যদি তা হয় তবে এটি কীভাবে পরিমাপ করা যায়?

Comments

আপনি এই পোস্টে আগ্রহী হতে পারেন: প্রোগ্রামারস.সটেকেক্সচেঞ্জ

— প্রশ্নগুলি

দুঃখিত, তবে আমি ইউএমএলকে "প্রযুক্তিগত জঞ্জাল", সময় অপচয়কারী এবং .. ঠিক আছে, আমি এখানেই থামব। আমি এখন ভাল বোধ করছি.

— চিরন

"যদি গ্রাহক এটির জন্য অর্থ প্রদান করতে ইচ্ছুক হয় তার চেয়ে নকশা তৈরি করতে আপনার যদি আরও বেশি সময় লাগে তবে আপনি ডিজাইনের কাজটি শেষ করেছেন" - এটি কার সাথে যুক্ত করা উচিত তা মনে করতে পারছেন না, তবে এটি "কিনা" অনুমান করার জন্য এটি একটি উত্তম গাইড গাইড ব্যবহার করা হবে এবং এটি সার্থক হবে :)

— পিএইচডি

"Should I just be doing other fun stuff like writing code?"আপনি বলতে চাইছেন: "other stuff that contributes to the bottom line of the project like writing code"অবশ্যই?

— StuperUser

অবশ্যই আপনি করেন, এবং আপনাকে শিরলে ডাকে না।

— StuperUser

Answer 1

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

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

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

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

Comments

আপনি বলেছেন যে আপনি ওএমএল প্রত্যয়িত। ওএমএল কী? একটি ছাপাখানা?

— BЈовић

হ্যাঁ, এটি অবজেক্ট ম্যানেজমেন্ট গ্রুপের জন্য ওএমজি ছিল, ইউএমএল এর পিছনে জীব => uML.org

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

— থমাস

যদি আপনি কেবল ওএমজি এর স্বাভাবিক অর্থ সহ পড়েন তবে প্রথম অনুচ্ছেদটি আরও মজাদার ।

— জেএসবি ձոգչ

@ পিয়েরে 303 আমি সম্মত, ইউএমএল ছাড়াও অন্য বিকল্প রয়েছে। তবে প্রশ্নটি বিশুদ্ধ কোডিংয়ের বিপরীতে স্পেসিফিকেশন / ডকুমেন্টেশন সরঞ্জামগুলি ব্যবহার করার বিষয়ে। "টিম যতক্ষণ না এই কাজের জন্য সরঞ্জামগুলি ব্যবহার করে" যতক্ষণ না এটি "সরঞ্জাম" ব্যবহার করে তা বিচার্য নয় "? আপনি কি "[জটিল] খুব জটিল" প্রকল্পের জন্যও ব্যবহারকারীর গল্প ব্যবহার করেন না বা এই ক্ষেত্রে সেগুলি সময় নষ্ট করে?

— স্কার্ফ্রিজে

Answer 2

পরিকল্পনা সমালোচনামূলক, তবে বিখ্যাত কৌশলবিদ কার্ল ফন ক্লাউসউইজ সতর্ক করেছেন

কোনও প্রচারণার পরিকল্পনা শত্রুর সাথে প্রথম যোগাযোগ থেকে যায় না

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

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

Comments

But likely a waste of time for documenting your code for future programmers.যদি কোনও প্রকল্প ডকুমেন্টেশনের ফর্ম হিসাবে ইউএমএল ব্যবহার করতে চায় তবে এটি সাধারণত বিপরীত প্রকৌশল সরঞ্জামগুলি ব্যবহার করে তৈরি করা হয়। এমন বিভিন্ন সরঞ্জাম রয়েছে যা উত্স কোড থেকে শ্রেণি এবং সিকোয়েন্স ডায়াগ্রাম তৈরি করতে পারে (এবং কখনও কখনও কয়েক জন) এবং এই সরঞ্জামগুলির আউটপুট ডকুমেন্টেশন হিসাবে ধরা পড়ে।

— টমাসের মালিক

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

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

Comments

+1: প্রকৃতপক্ষে: ইউএমএলকে স্কেচ হিসাবে দেখুন ।

— রিচার্ড

Answer 5

আমি একবার এমন একটি গিগের উপর কাজ করেছি যেখানে বিদেশে চুক্তি বিকাশকারীদের একটি দল পরিচালনা করতে আমার প্রয়োজন হয়েছিল।

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

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

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

Comments

+1 - মডেলিংয়ের অন্যতম প্রধান উপকারিতা হ'ল কোডে আপনি এটি করতে পারবেন তার চেয়ে অনেক বেশি দ্রুত বিভিন্ন ধারণা তৈরি, পরিবর্তন, বুঝতে এবং অন্বেষণ করতে সক্ষম হবেন।

— ডাঙ্ক

Answer 6

যদি কেউ আপনাকে ইউএমএল ডায়াগ্রাম প্রস্তুত করতে বলে এবং কেউ আপনার বেতন দিচ্ছে, তবে এটি আসলে আপনার সময় নষ্ট নয়। এটি কারও সময় নষ্ট হতে পারে বা নাও হতে পারে।

যদি কেউ আপনার ইউএমএল ডায়াগ্রামগুলি পড়ে আপনার প্রকল্পটি বোঝার পরিকল্পনা করছেন তবে এটি সম্ভবত তাদের সময় নষ্ট নয়।

Answer 7

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

রাগু.পট্টবী এখানে দুটি ধরণের ইউএমএল পার্থক্য করে একটি ভাল পয়েন্ট তৈরি করেছেন ...

আমি মনে করি ইউএমএলের চৌকস স্বাদ (যেমন দ্রুত সাদা বোর্ড স্কেচ) ইউএমএলের জলপ্রপাতের স্বাদের চেয়ে বেশি সফল (যেমন ডকুমেন্টের বুদ্ধিমান ম্যানেজারদের খুশি করার জন্য ডকুমেন্টেশন, কোড জেনারেশন ইত্যাদির জন্য সমস্ত বিস্তৃত বিশদ সহ বিস্তৃত চিত্র)।

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

Comments

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

— ডাঙ্ক

Answer 8

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

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

Answer 9

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

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

আমি আপনাকে আপনার প্রকল্পে সময় বরাদ্দ দেওয়ার এবং চক্রগুলিতে চিত্রগুলি তৈরি করার পরামর্শ দিচ্ছি। প্রথমটি আপনার প্রকল্পের উচ্চ স্তরের দিকগুলি কভার করবে এবং পরবর্তী স্তরের বিশদগুলিতে আরও মনোনিবেশ করতে পারে।

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

Comments

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

— জিম জি।

@JimG। ডকুমেন্টেশনটি কতটা বিশদযুক্ত তার উপর নির্ভর করে এটি সত্য বা অসত্য হতে পারে। আপনি যদি আপনার ডকুমেন্টেশনগুলিকে উচ্চ-স্তরের (উপাদানগুলি, বড় শ্রেণীর প্রধান বিবরণ) রাখেন তবে ডকুমেন্টেশনটি দ্রুত বাসি হয়ে উঠবে না। আপনি যদি প্রতিটি ক্লাসের প্রতিটি সদস্যকে ম্যানুয়ালি নথিভুক্ত করেন তবে আপনার কাজটি খুব দ্রুত অকেজো হয়ে যাবে।

— ড্যানি ভারোড

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

— NoChance

@ এমদাদ কেরেম: অর্গান সম্পর্কিত যা আইটি অডিট করে - এই ডকুমেন্টেশনগুলির বেশিরভাগটি পারফেক্টরিয়াল এবং কেবল নিরীক্ষণের উদ্দেশ্যে তৈরি হয়। বেশিরভাগ সফটওয়্যার ডেভস এটি বিশ্বাস করবে না।

— জিম জি।

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

— NoChance

Answer 10

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

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

Answer 11

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

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

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

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

Answer 12

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

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

Answer 13

আমি তাদের অত্যন্ত ওভাররেটেড দেখতে পাই। আমি তাদের একমাত্র ছবি হিসাবে বিবেচনা করি যা হাজার শব্দ আঁকেন না।

Comments

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

— ডাঙ্ক

Answer 14

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

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

Comments

LMAO, কালো / সাদা? আপনার "প্রস্তাবিত" বিকাশের পদ্ধতি হ'ল কারণেই আমাকে প্রায়শই বিপর্যয়কর প্রকল্পগুলি পরিষ্কার ও সংশোধন করার জন্য ডাকা হয়েছিল। কোডটি নকশা নয়। খুব কম লোকই আছেন যারা এমনকি পরিমিত জটিল সিস্টেম তৈরি করতে পারেন (আমার ধারণা আমি এই বিবৃতিটি একাকী হিসাবে ছেড়ে যেতে হবে)। এবং এখানে অনেকগুলি, খুব কম লোক রয়েছে যা সরাসরি কোডে ঝাঁপিয়ে পড়ে এটি করতে পারে। এছাড়াও, আপনার একটি "ভাঙা" সিস্টেম দ্রুততর হতে পারে তবে সোজা কোডে ঝাঁপিয়ে আপনার কাছে "ওয়ার্কিং" সিস্টেমটি আর দ্রুত হবে না। তবে আমি অনুমান করি যে এটি আপনার সমস্ত প্রকল্পের ধরণের উপর নির্ভর করে। যদি অর্ধেক কাজ ঠিকঠাক হয়, তবে আপনার পদ্ধতির ঠিক আছে।

— ডাঙ্ক

Answer 15

আমি কখনই ইউএমএলের অনুরাগী নই, তবে সিস্টেম বা কার্যগুলির মধ্যে মিথস্ক্রিয়া বর্ণনা করার জন্য আমি একটি ভাল ক্রম ডায়াগ্রামকে মূল্য দিতে এসেছি।

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

ডকুমেন্টেশন সম্পর্কে জিনিস দুটি স্তর আছে:

• উচ্চ স্তরের (আর্কিটেকচারাল) সিদ্ধান্তগুলি ম্যানুয়ালি ডকুমেন্টেশন হওয়া উচিত
• নিম্ন স্তরের (সত্তা সম্পর্ক) তথ্যগুলি স্বয়ংক্রিয়ভাবে বের করা উচিত

Comments

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

— ডাঙ্ক

Answer 16

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

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

আমি খুঁজে পেয়েছি যে পুনরাবৃত্তি প্রয়োজনীয়, কারণ কেবল ছবি আঁকার ক্ষেত্রে সবসময় গুরুত্বপূর্ণ দিকগুলি মিস হয়, যখন কেবল কোডিংয়ের ফলে সমস্যাযুক্ত ডিজাইনের ফলাফল হয়।

যাইহোক, অন্য পোস্টারটির মতো বলা হয়েছে, এটি সমস্ত কিছু মানুষের কাছে ফোটে। যদি তারা ইউএমএল ডায়াগ্রামগুলি "ব্যবহার করে" দক্ষ হয় তবে ইউএমএল অমূল্য। যদি সেগুলি না হয় তবে ডায়াগ্রামগুলির কোনও মূল্য নেই।

সুতরাং, আপনার প্রশ্নের উত্তর সত্যই "এটি নির্ভর করে"। এই ক্ষেত্রে, এটি জনগণের উপর নির্ভর করে, প্রকল্পটির জটিলতা এবং সিস্টেমটি সঠিকভাবে কাজ করা কতটা গুরুত্বপূর্ণ।

Answer 17

আমার অভিজ্ঞতা থেকে ইউএমএল কোড প্যাটার্ন সম্পর্কে বিকাশকারীদের মধ্যে এবং আবেদনের সাধারণভাবে আর্কিটেকচারের মধ্যে যোগাযোগের জন্য গুরুত্বপূর্ণ important

Answer 18

আমি চিত্রগুলি পছন্দ করি, তবে যদি আমাকে একটি তৈরি করতে বলা হয় (বিশেষত ইউএমএল!), আমি দুটি প্রশ্ন জিজ্ঞাসা করব:

1. কার জন্য?
2. তাদের কি এখন এটি দরকার?

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

Answer 19

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

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

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

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

Answer 20

প্রশ্নটি ইউএমএলের মেধা সম্পর্কে, বা প্রোগ্রামগুলির আর্কিটেকচার ডিজাইনের যোগ্যতার বিষয়ে কিনা তা জানেন না।

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

প্রোগ্রাম ডিজাইন সম্পর্কে।

1. প্রতিটি প্রোগ্রামের একটি নকশা থাকে, আপনি এটি পরিকল্পনা না করলেও। কোডটি যখন লেখা থাকে, তখন এটি রিভার্স-ইঞ্জিনিয়ার করুন। আপনি যদি এটি পরিকল্পনা না করেন তবে বাজি ধরুন এটি একটি খারাপ নকশা হবে।

2. পুনরাবৃত্তিজনিত সমস্যাগুলির জন্য পরিচিত নিদর্শনগুলি ব্যবহার করে ডিজাইন আপনার সময় বাঁচাবে।

3. আপনি যদি একটি দলে কাজ করেন, কাজগুলি বিতরণ করার জন্য সমাধানগুলি, ধারণাগুলি প্রেরণ করার জন্য, এবং খুব ব্যবহারিক তবে প্রয়োজনীয় তবে ডিজাইনের প্রয়োজন।