কোডটি কি সাধারণত ইউএমএল থেকে উত্পন্ন হয়? [বন্ধ]


39

সুতরাং আমি যখন বিশ্ববিদ্যালয়ে ছিলাম তখন আমি ইউএমএলের সুবিধা এবং কোড বিকাশে এর ভবিষ্যতের বিষয়ে শিক্ষিত হয়েছিলাম।

তবে আমার শিল্পের অভিজ্ঞতা থেকে, আমি খুঁজে পেয়েছি যে আমরা যখন ডায়াগ্রামগুলি ব্যবহার করি - ইআর ডায়াগ্রাম, শ্রেণি চিত্র, রাজ্য চিত্রগুলি থেকে শুরু করে কাজ প্রবাহের চিত্রগুলি ব্যবহার করি - এগুলি সবই যোগাযোগের উদ্দেশ্যে for

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

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

লোকেরা কি কোড বা ডাটাবেস তৈরির মতো আরও পরিশীলিত জিনিসগুলিতে ইউএমএল ব্যবহার করে?


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

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

9
@ এসকে-যুক্তি - আমি ভেবেছিলাম একটি ছবি হাজার শব্দ আঁকা?
মাইকেল আর্নেল

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

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

উত্তর:


64

হ্যাঁ, ইউএমএল CASE সরঞ্জামগুলি 90 এর দশকের অন্যতম হট আইটেম ছিল ... এবং তারপরে সরবরাহ করতে ব্যর্থ হয়েছিল।

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

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

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


5
যথাযথভাবে। কিন্তু তারপরে প্রশ্ন ওঠে যে ইউএমএল তার অর্থহীন কঠোর নিয়মগুলির সাথে কেন এবং ইউএমএল তৈরির ফলস্বরূপ ফুলে যাওয়া সরঞ্জামগুলি প্রথম স্থানে রয়েছে? লিমি এবং তীর দ্বারা সংযুক্ত সরল বহুভুজ এবং উপবৃত্তগুলি ইউএমএলের মতো অভিপ্রায় জানাতে যেমন একটি ভাল কাজ না হয় তেমনই ভাল কাজ করে।
ডেক্সটার

1
90 এর দশকের হাইপটির জন্য +1, হার্ডওয়্যার ডিজাইন একই সময়ে স্কিমেটিক ক্যাপচার থেকে এবং এইচডিএলগুলির দিকে বিপরীত দিকেও এগিয়ে চলেছিল।
জে কে।

2
1996 থেকে 2002 পর্যন্ত আমি এমন একটি সংস্থার জন্য কাজ করছিলাম যেখানে আমরা সফলভাবে ইউএমএল ডায়াগ্রামগুলিকে "আরও ভাল" ইআর মডেল হিসাবে ব্যবহার করেছি। আমাদের ওআরএম কাঠামোর জন্য সি ++ কোড তৈরির জন্য আমাদের নিজস্ব কোড জেনারেটর, এসকিউএল / ডিডিএল এবং একটি একক মডেল থেকে সমস্ত ডকুমেন্টেশন ছিল।
ডক ব্রাউন

2
ইউএমএল ডায়াগ্রামের দুর্দান্ত ব্যবহার হ'ল ভারাও। গিটার / সেটটার, সম্ভবত আপনার ডিরেক্টরি গাছ ইত্যাদির সাথে ক্লাস তৈরি করুন
ক্লিমেন্ট হেরেম্যান

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

36

সুতরাং আমি যখন ইউনিতে ছিলাম (কিছুক্ষণ আগে) তখন আমাকে জানানো হয়েছিল যে ইউএমএল ভবিষ্যত, ইউএমএল প্রোগ্রামিং প্রতিস্থাপন করবে এবং আমরা ডায়াগ্রামগুলি থেকে কোড তৈরি করব etc.

তারা ভুল ছিল. লোকেরা যখন বক্তৃতা ত্যাগ করে এবং গুহা চিত্রকলায় ফিরে যায় তখনই এটি ঘটবে।

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


2
+1, বাস্তব শব্দ সমস্যার জটিলতা সম্পর্কে বিষয়টি সামনে আনার জন্য আপনাকে ধন্যবাদ। দুর্দান্ত পয়েন্ট।
NoChance

জি, ল্যাবভিউ-তে ব্যবহৃত গ্রাফিকাল প্রোগ্রামিং ভাষা কী?
অ্যাঞ্জেলো.হান্নস

1
@ অ্যাঞ্জেলো.হান্নেস: পরীক্ষার মতো অদৃশ্য পদ্ধতির মধ্যে বাস্তব বিশ্বের সমস্যাগুলি সমাধান করা: img.thedailywtf.com/images/201104/labview.jpg
কিয়াসনাম

@wwisisname এই চিত্রটি খুব বিশৃঙ্খল। তবে আমি ল্যাবভিউতে খুব ভাল কাঠামোগত এবং খুব "পাঠযোগ্য" ডায়াগ্রামগুলি বাস্তব বিশ্বের সমস্যার সমাধান করতে দেখেছি।
অ্যাঞ্জেলো.হান্নস

@ অ্যাঞ্জেলো.হান্নেস: আমি ল্যাবভিউয়ের মতো সিস্টেম ব্যবহার করেছি। সীমিত ডোমেনে ছোট অ্যাপ্লিকেশন গড়ার জন্য তারা ভাল।
কেভিন

9

কোন

কিংবদন্তিটি এই লেখার ব্যর্থ অনুমানের ভিত্তিতে তৈরি হয়েছিল:

class ClassName extends SomeThing
{

}

... এটি শক্ত এবং অটোমেশন প্রয়োজন

আপনি এখনও মাঝেমধ্যে বিশ্বাসী বা বিশ্বাসীদের ভিড় খুঁজে পেতে পারেন ।
তবে ধর্ম এবং ধর্মের সাথে এটিই চলে।


4
আমি সত্যিই কোথাও একটি বড় NO সঙ্গে একটি উত্তর প্রয়োজন অনুভূত ।
জেডজেআর

6

সেখানে ছিলেন, এটি খুব দরকারী খুঁজে পেলেন না।

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

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

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

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


@ মউভিচিয়েল: আমি মনে করি না এমন কোনও সরঞ্জাম রয়েছে যাতে এরকম সমস্যা হবে না। দুর্ঘটনাক্রমে প্রকৃতপক্ষে উত্পন্ন কোডটি, যা পাঠ্য, সদস্যদের পক্ষে অনুমোদনযোগ্য হিসাবে ব্যবহার করে সবচেয়ে খারাপ সমস্যাগুলি হ্রাস করার চেষ্টা করে।
জানু হুডেক

3

যদিও ইউএমএল মডেলগুলি থেকে সরাসরি কোড (এবং এমনকি পুরো সিস্টেমগুলি) উত্পন্ন করা সম্ভব, আমি কখনও এটিকে এভাবে ব্যবহার করার মুখোমুখি হইনি।

আমার অভিজ্ঞতায়, বেশিরভাগ সংস্থাগুলি এটি প্রয়োজনীয়তার জন্য যোগাযোগের সরঞ্জাম হিসাবে বা "ডায়াগ্রাম আঁকার জন্য এমএস পেইন্ট" হিসাবে ব্যবহার করেছে বলে মনে হয়।

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


1

এর সবগুলি (মডেলিং ডায়াগ্রাম) যোগাযোগের উদ্দেশ্যে

মডেলিংয়ের সফ্টওয়্যার বিকাশ প্রক্রিয়াটিতে 4 টি গুরুত্বপূর্ণ ব্যবহার রয়েছে:

  1. ইন্টিগ্রেটেড ডিজাইনের সরঞ্জাম

  2. যোগাযোগের সরঞ্জাম

  3. সফটওয়্যার জেনারেশনে সহায়তা

  4. আসল-শব্দের সমস্যার জটিলতা হ্রাস করার একটি উপায় (আমি উপরের @ কেভিন ক্লাইনের প্রতিক্রিয়া থেকে এটি শিখেছি)

  5. মডেলিংয়ের প্রক্রিয়াটি কিছু ডিজাইনারকে কোডিং করার সময় বিবেচনা করা হয়নি এমন বিশদগুলি সম্পর্কে চিন্তাভাবনা করতে (এবং উপবৃত্ত) gets ডিজাইনের সময় মডেলিং আপনাকে কোনও পদ্ধতিতে কোনও ভাষা বা ক্লাস কোডিংয়ের চেয়ে আরও বড় ছবি বিবেচনা করতে দেয়।

আমার মতে মডেলিং করা ডেটাবেসগুলি (ইআর ডায়াগ্রাম) তৈরি করা, প্রক্রিয়া প্রবাহ বুঝতে (ক্রিয়াকলাপ ডায়াগ্রাম) এবং ব্যবহারকারী-সিস্টেমের মিথস্ক্রিয়া বোঝার জন্য (কেস ডায়াগ্রামগুলি ব্যবহার করুন) গুরুত্বপূর্ণ।

লোকেরা কি কোড বা ডাটাবেস তৈরির মতো আরও পরিশীলিত জিনিসগুলিতে ইউএমএল ব্যবহার করে?

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

1 - ডেটা সংজ্ঞা ভাষা (ডিডিএল)

2 - আপনার পছন্দের ভাষায় সিআরইউডি এবং ক্লাস ডায়াগ্রামের জন্য সঞ্চিত পদ্ধতি (ওআরএম সরঞ্জামগুলি এ সম্পর্কে আরও কিছু করার কারণে কম কার্যকর)

মডেলিং সরঞ্জামগুলির সবচেয়ে মূল্যবান বৈশিষ্ট্যগুলির মধ্যে রয়েছে:

1 - মডেলটির অখণ্ডতা রাখার ক্ষমতা Ab আপনি যদি কোনও পরিবর্তন করেন তবে এটি মডেলটিতে প্রচার করে

2 - কোথায়-ব্যবহৃত প্রশ্নের উত্তর দেওয়ার ক্ষমতা (আমার মডেলটিতে 'অ্যাকাউন্ট' কোথায় ব্যবহৃত হয়?)

3 - সমবর্তী ব্যবহারকারীদের মডেলটিতে কাজ করার অনুমতি দেওয়ার ক্ষমতা

4 - গ্রাফিকাল উপস্থাপনার মধ্যে অনুসন্ধান করুন

5 - মুদ্রণ নিয়ন্ত্রণ

6 - স্তরকরণ (আপনার ডায়াগ্রাম উপাদানগুলিকে স্তরগুলিতে সংগঠিত করুন) যাতে আপনি একসাথে কোনও স্তরটিতে ফোকাস করতে পারেন

7 - বেশ কয়েকটি ডাটাবেস সিস্টেমের জন্য ডাটাবেস কোড জেনারেশন

8 - মডেল বৈধতা (চেক ধারাবাহিকতা, অনুপস্থিত কী, চক্র, ইত্যাদি)

সুতরাং, মডেলিং সরঞ্জামগুলি, বিশেষত ভাল ভালগুলি পেইন্টের চেয়ে অনেক বেশি কাজ করে।


3
আমি 2 টি জিনিস উল্লেখ করতে চাই: 1. আপনি আদেশ তালিকাগুলি পছন্দ করেন।
ট্যালনিকোলস

ট্যালনিকোলস, আপনি সঠিক! আমি করি :)
NoChance

0

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

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


0

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


-1

আমার সর্বশেষ প্রকল্পে আমি ইউএমএল-ল্যাব (https://www.uml-lab.com) ব্যবহার করছি। এটি একটি দুর্দান্ত সরঞ্জাম যা মডেলটিকেও বিপরীত ইঞ্জিনিয়ারিং করতে দেয়। সরঞ্জামটি জাভা কোড এবং এমনকি জেপিএ টীকা উত্পন্ন করে যা মোটামুটি সঠিক।

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

আমি প্রথমবারের মতো কোডটি উত্পন্ন করার পাশাপাশি একটি শটে কোনও পণ্যকে অবজেক্ট মডেলিং এবং ডেটা মডেলিং করতে দেখলাম।

অন্যথায় আমার অতীতের প্রকল্পগুলিতে, আমি সবসময় বাসি মডেলগুলি দেখেছি যা সঠিক বা খুব বিশদ নয়।

আমার অতীতের প্রকল্পগুলিতে আমি কখনও কখনও বিপরীত প্রকৌশল দ্বারা ডায়াগ্রাম তৈরি করি। বেশিরভাগ সময় আমি ডায়াগ্রামগুলি বিশৃঙ্খল অবস্থায় পেয়েছি এবং আমি সমস্ত শব্দটি ম্যানুয়ালি ফিল্টার করে এগুলিকে আঁকতে পছন্দ করি।


-4

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

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

ওএডাব্লু, এবং এন্টারপ্রাইজ আর্কিটেক্টের মতো মডেলিং সরঞ্জাম ব্যবহার করে আমরা শক্তিশালী কোড জেনারেটর লিখতে পারি, যা এমনকি স্টিরিওটাইপস এবং ট্যাগযুক্ত মান ব্যবহার করে কনফিগারেশন ফাইল, ফ্যাক্টরি কোড তৈরি করতে সহায়তা করতে পারে can


-5

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

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

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

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

কোডের সাথে লাইভ সিঙ্ক্রোনাইজেশন করা থাকলেও মডেল চালিত বিকাশ টেম্পলেট কোড জেনারেশন সহ এমডিএ ব্যবহার করে traditionalতিহ্যবাহী হয়ে একেবারে বিধ্বস্ত হয়ে গেলে আমি ইউএমএল দ্বারা উচ্চ স্তরের দর্শক হিসাবে কখনও হতাশ হইনি। কোনও মডেল থেকে কোড জেনারেশন একটি শব্দের ডকুমেন্ট থেকে আসা HTML পৃষ্ঠার মতো। এটি তৈরির পরে এটি কীভাবে পরিবর্তন করবেন? এটি আপডেট করা কেবল অসম্ভব এবং আপনি স্ক্র্যাচ থেকে লেখার চেয়ে কোড পরিষ্কার করতে আরও সময় ব্যয় করেন!


1
এটি কোনও উত্তর মানুষ নয়, কেবল একটি অভিযোগ। ড্র্যাগ এবং ড্রপ সহ ছোট কোড কনস্ট্রাক্টর তৈরি করা সহজ যখন কেন কোডাররা এখনও প্রতিটি একক লাইন কোডটি রচনা করছে সে সম্পর্কে আমি কিছুটা সম্মত agree আপনি সম্পূর্ণরূপে ঠিক বলেছেন যে প্রযুক্তি ব্যবহারকারীরা যে প্রযুক্তি ব্যবহার করেন তাদের তুলনায় প্রযুক্তিটি আরও ভাল বাস্তবায়ন করেছে। আপনি সেকেন্ডে আপনার অ্যাপ্লিকেশন সহ পুরো প্রাক-কনফিগার করা মেশিন তৈরি করতে পারেন তবে আপনি কয়েকটি (হাজার) ক্লিক বা কী স্ট্রোক সহ সফ্টওয়্যার তৈরি করতে পারবেন না। অতিরিক্ত। আমি জানি যে ডায়া এবং পাইথনেক্ট আপনার ইউএমএল থেকে ঠিক একটি কার্যকর কোড কার্যকর করতে পারে, কিন্তু এখনও পরীক্ষা করে নি।
erm3nda
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.