চৌকস পরিবেশে স্থাপত্য নকশা কীভাবে করা হয়?


59

আমি এগ্রিল আর্কিটেক্টের জন্য নীতিগুলি পড়েছি , যেখানে তারা পরবর্তী নীতিগুলি সংজ্ঞায়িত করেছে:

মূল নীতি # 1 টিমগুলি সিস্টেমকে কোড দেয় তারা সিস্টেমটি ডিজাইন করে।
নীতি # 2 সহজতম আর্কিটেকচার তৈরি করুন যা সম্ভবত কাজ করতে পারে।
নীতি # 3 সন্দেহ হলে, এটিকে কোড করুন।
নীতি # 4 তারা এটি তৈরি করে, তারা এটি পরীক্ষা করে।
মূল নীতি # 5 সিস্টেম যত বড়, রানওয়ে তত দীর্ঘ।
নীতিমালা # 6 সিস্টেম আর্কিটেকচার একটি ভূমিকা সহযোগিতা।
নীতি # 7 উদ্ভাবনের উপর কোনও একচেটিয়া নেই is

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

সুতরাং, সিস্টেমের নকশাটি কীভাবে করা হয়? ইউএমএল ব্যবহার করছেন? বা এমন একটি নথি যা ইন্টারফেস এবং প্রধান ব্লকগুলি সংজ্ঞায়িত করে? হয়ত অন্য কিছু?


11
আপনি ইউএমএলে "নকশাটি করেন না"। আপনি নকশাটি করেন এবং তারপরে আপনি এটি লিখতে বা যোগাযোগ করার জন্য ইউএমএল ব্যবহার করেন।
tdammers

4
@tdammers: সুনির্দিষ্টভাবে বলতে গেলে, আপনি এটি লিখতে ইউএমএল ব্যবহার করার চেষ্টা করবেন এবং লক্ষ্য করুন যে ইউএমএল পর্যাপ্ত নয়।
ডক ব্রাউন

উত্তর:


77

দাবি পরিত্যাগী: আমি আছি একটি চঞ্চল পরিবেশে একজন স্থপতি কিন্তু Helmuth ভন Moltke যেমন এল্ডার বলেন, "কোন যুদ্ধ পরিকল্পনা প্রাণে বেঁচে যান শত্রু সঙ্গে যোগাযোগ"। অন্য কথায়, ব্যবহারিকাগুলি মানে নির্দেশিকাটির সঠিক অক্ষরটি সর্বদা অনুসরণ করা যায় না।

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

সুতরাং, সিস্টেমের নকশাটি কীভাবে করা হয়? ইউএমএল ব্যবহার করছেন? বা এমন একটি নথি যা ইন্টারফেস এবং প্রধান ব্লকগুলি সংজ্ঞায়িত করে? হয়ত অন্য কিছু?

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

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

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

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

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


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

@ ম্যাপেল_শ্যাফ্ট আমি ডিজাইনটিতে আরও ফোকাস করার জন্য আমার উত্তরটি প্রসারিত করেছি।
অ্যাকটন

3
এর মূল্য কী, অন্য এক স্থপতি হিসাবে যারা বহু বহুজাতিক সেটিংয়ে বেশ কয়েক বছর ধরে চতুর পরিবেশে কাজ করেছিলেন, এটি স্পট-অন।
রেক্স এম

12

দাবি অস্বীকার: আমি কোন চটচটে কোচ / স্থপতি নই - আমি এটি কাজ করেছি যা চতুর প্রকল্পে দেখেছি এবং আমি মনে করি এটি ভালভাবে কাজ করে।

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

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

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


0

পরীক্ষা চালিত বিকাশ করার সময় আপনি টেস্টকোড তৈরি করেন যা আপনার মডিউলগুলি বিচ্ছিন্নতায় পরীক্ষা করে (= যতটা সম্ভব অন্যান্য মডিউলগুলির থেকে স্বতন্ত্র))

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

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

আমার মতে টিডিডিও আর্কিটেকচারাল কাজ work


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