সফ্টওয়্যার ডিজাইন বনাম সফ্টওয়্যার আর্কিটেকচার [বন্ধ]

Question

সফ্টওয়্যার ডিজাইন এবং সফ্টওয়্যার আর্কিটেকচারের মধ্যে পার্থক্যটি কেউ ব্যাখ্যা করতে পারেন?

আরো নির্দিষ্টভাবে; যদি আপনি কাউকে আপনাকে 'ডিজাইন' উপস্থাপন করতে বলেন - আপনি কী তাদের উপস্থাপনের প্রত্যাশা করবেন? একই 'আর্কিটেকচার' জন্য যায়।

আমার বর্তমান বোঝাপড়াটি হ'ল:

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

আমি ভুল হলে শুধরে. আমি উইকিপিডিয়ায় http://en.wikedia.org/wiki/Software_design এবং http://en.wikedia.org/wiki/Software_architecture এ নিবন্ধগুলি উল্লেখ করেছি , তবে আমি নিশ্চিত নই যে এগুলি সঠিকভাবে বুঝতে পেরেছি কিনা।

Comments

নীচের কোন প্রশ্ন কি সহায়ক ছিল? ;)

— প্যাট্রিক কারচার

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

— হট লিকস

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

— হট লিক্স

Answer 1

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

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

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

Comments

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

— আসফ আর

হাই @ আসফআর! এটি আমাকে আর্কিটেকচার হিসাবে বিশ্লেষণ হিসাবে ভাবতে বাধ্য করেছে কারণ বিশ্লেষণ কী করে (সম্পন্ন হয়) এবং ডিজাইনের সাথে কীভাবে ডিজাইন করে? আপনি কী ভাবেন?

— ক্রিস

আজকাল লোকেরা সমস্ত ডিজাইনিং, বাস্তবায়ন, ব্যাকএন্ড সার্ভারগুলি বজায় রাখতে পারে (সম্ভবত মেঘ-ভিত্তিক) এবং ফ্রন্ট-এন্ড ডিজাইন (ওয়েব বা মোবাইল) এগুলি নিজেরাই করে। আমি তাদের পুরো স্ট্যাক বিকাশকারী বলা হয় বলে মনে করি। রাইট?

— মাজিয়ার

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

— ইভান হু

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

— রাজ্জি

Answer 2

এসডিএলসি (সফটওয়্যার ডেভলপমেন্ট লাইফ সাইকেল) এর কিছু বিবরণে তারা আদান-প্রদানের যোগ্য, তবে কনসেসাস হ'ল এগুলি আলাদা। তারা একই সময়ে: পৃথক (1) পর্যায় , (2) দায়িত্বের ক্ষেত্র এবং (3) সিদ্ধান্ত গ্রহণের স্তর ।

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

এই দুটি পর্যায় বিভিন্ন কারণে একত্রে মিশে যাবে বলে মনে হবে ।

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

এমনকি যদি পর্যায়ে বা দায়িত্বের ক্ষেত্রগুলি একসাথে মিশে যায় এবং পুরো জায়গা জুড়ে ঘটে, তবে সিদ্ধান্ত নেওয়ার স্তরটি কী ঘটছে তা সর্বদা জানা ভাল। (আমরা এটি দিয়ে চিরদিনের জন্য এগিয়ে যেতে পারছিলাম I'm আমি এটির সংক্ষিপ্তসার রাখার চেষ্টা করছি)) আমি এখানেই শেষ করব: আপনার প্রকল্পের কোনও formalપચારিক স্থাপত্য বা নকশার মঞ্চ / এওআর / ডকুমেন্টইটন নেই বলে মনে হলেও এটি ঘটছে যে কেউ আছেন কিনা সচেতনভাবে এটি করছেন বা না। যদি কেউ আর্কিটেকচার করার সিদ্ধান্ত না নেয়, তবে একটি ডিফল্ট এমনটি ঘটে যা সম্ভবত দুর্বল। ডিজাইনের জন্য দিতো। এই ধারণাগুলি যদি কোনও আনুষ্ঠানিক পর্যায়ে তাদের প্রতিনিধিত্ব না করে তবে প্রায় গুরুত্বপূর্ণ ।

Comments

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

— টম ডব্লু

Answer 3

আর্কিটেকচার কৌশলগত, অন্যদিকে নকশা কৌশলগত।

আর্কিটেকচারে ফ্রেমওয়ার্ক, সরঞ্জামগুলি, প্রোগ্রামিং প্যারাডিজম, উপাদান-ভিত্তিক সফ্টওয়্যার ইঞ্জিনিয়ারিং মান, উচ্চ-স্তরের নীতিগুলি রয়েছে ...

ডিজাইনটি স্থানীয় বাধা যেমন ডিজাইনের ধরণ, প্রোগ্রামিং আইডিয়াম এবং রিফ্যাক্টরিংগুলির সাথে সম্পর্কিত এমন কার্যকলাপ While

Comments

আমি এটিকে ভোট দেওয়ার জন্য "ডিজাইন" এবং "আর্কিটেকচার" এর সংজ্ঞায় আরও কম উল্লেখ চাই ...

— পিটার হ্যানসেন

সম্মত .. এটি সম্ভবত: আর্কিটেকচারটিতে ফ্রেমওয়ার্ক, সরঞ্জামগুলি, প্রোগ্রামিং প্যারাডিজমগুলি, উপাদান-ভিত্তিক সফ্টওয়্যার ইঞ্জিনিয়ারিং মানগুলি, উচ্চ-স্তরের নীতিগুলি রয়েছে ... যদিও ডিজাইন স্থানীয় সীমাবদ্ধতাগুলির সাথে সম্পর্কিত যেমন একটি নকশা নকশার নকশা, প্রোগ্রামিং আইডিয়াম এবং রিফ্যাক্টরিংগুলি ings

— ক্রিস কানন 18

Answer 4

আমি আর্কিটেকচার এবং নিজেকে ডিজাইনের মধ্যে সাধারণ পার্থক্য খুঁজছিলাম বলে আমি এটি পেয়েছি;
এগুলি দেখার জন্য আপনি কী মনে করেন:

• আর্কিটেকচারটি "কী" আমরা তৈরি করছি;
• ডিজাইনটি "কীভাবে" আমরা তৈরি করছি;

Comments

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

— মেরেক

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

— RecursiveExceptionException

Answer 5

1. আর্কিটেকচার বলতে কম্পিউটার বা কম্পিউটার ভিত্তিক সিস্টেমের ধারণামূলক কাঠামো এবং যৌক্তিক সংগঠন বোঝায়।

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

2. আপনি যদি কোনও উপাদানকে "আর্কিটেকিং" করছেন, আপনি বৃহত্তর সিস্টেমে এটি কীভাবে আচরণ করে তা নির্ধারণ করছেন।

   আপনি যদি একই উপাদানটিকে "ডিজাইনিং" করে থাকেন তবে আপনি এটি অভ্যন্তরীণভাবে কীভাবে আচরণ করে তা নির্ধারণ করছেন।

সমস্ত আর্কিটেকচার ডিজাইন তবে সমস্ত ডিজাইন আর্কিটেকচার নয়।

Whatঅংশ নকশা, Howকংক্রিট বাস্তবায়ন ও ছেদ হয় WhatএবংHow আর্কিটেকচার হয়।

আর্কিটেকচার এবং ডিজাইনের পার্থক্য করার জন্য চিত্র :

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

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

লিঙ্কটি যা ভাল উপমা দেয়

Comments

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

— মার্টিন Čাকা

Answer 6

আমি বলব আপনি ঠিক বলেছেন, আমার নিজের কথায়;

আর্কিটেকচার হ'ল সিস্টেম উপাদানগুলিতে সিস্টেমের প্রয়োজনীয়তার বন্টন। একটি স্থাপত্য সম্পর্কে চারটি বিবৃতি:

1. এটি ভাষা বা নিদর্শনগুলির মতো অ-কার্যকরী প্রয়োজনীয়তার পরিচয় দিতে পারে।
2. এটি উপাদান, ইন্টারফেস, সময় ইত্যাদির মধ্যে মিথস্ক্রিয়া সংজ্ঞায়িত করে
3. এটি নতুন কার্যকারিতা প্রবর্তন করবে না,
4. এটি উপাদানগুলির কার্য সম্পাদন করার উদ্দেশ্যে সিস্টেমটি (ডিজাইন করা) ফাংশনগুলি বরাদ্দ করে।

যখন সিস্টেমের জটিলতা উপ-বিভাগিত হয় তখন আর্কিটেকচার একটি প্রয়োজনীয় ইঞ্জিনিয়ারিং পদক্ষেপ ।

উদাহরণ: আপনার ঘর সম্পর্কে চিন্তা করুন, আপনার রান্নাঘরের জন্য আপনার কোনও স্থপতি প্রয়োজন নেই (কেবলমাত্র একটি উপাদান জড়িত) তবে সম্পূর্ণ বিল্ডিংয়ের জন্য কিছু মিথস্ক্রিয়া সংজ্ঞা যেমন দরজা এবং একটি ছাদ প্রয়োজন ।

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

রান্নাঘরটি ইনস্টল হওয়ার আগে রান্নাঘরের নকশাটি দেখতে ভাল লাগবে তবে রান্নার প্রয়োজনীয়তার জন্য এটি প্রয়োজনীয় নয় :

যদি আমি এটি সম্পর্কে চিন্তা করি তবে আপনি বলতে পারেন:

• আর্কিটেকচারটি আরও বিমূর্ত বিস্তৃত স্তরের পাবলিক / ইঞ্জিনিয়ারদের জন্য
• ডিজাইনটি কম বিশদ বিমূর্ত স্তরের জনসাধারণের জন্য উদ্দেশ্যে করা হয়েছে

Comments

আর্কিটেকচারের জন্য +1 হ'ল সিস্টেম উপাদানগুলিতে সিস্টেমের প্রয়োজনীয়তার বন্টন। চূড়ান্ত তালিকায় 'এ' শব্দটি ব্যবহারের জন্য ভার্চুয়াল -1 1 আমার এটি গ্রহণ আপনার (সঠিক) প্রাথমিক সংজ্ঞাটি বিমূর্তির বিরোধী।

— ক্রিস ওয়ালটন

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

— মাইক জি

বাস্তবায়ন কোথায় ফিট? বাস্তবায়ন কি ডিজাইন নয়?

— jwilleke

Answer 7

আমার অনুস্মারক:

• আমরা কাউকে না জিজ্ঞাসা করে ডিজাইন পরিবর্তন করতে পারি
• আমরা যদি আর্কিটেকচারটি পরিবর্তন করি তবে আমাদের এটির কারও সাথে যোগাযোগ করা প্রয়োজন (দল, ক্লায়েন্ট, স্টেকহোল্ডার, ...)

Answer 8

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

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

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

( Http://www.copypasteisforword.com/notes/software-architecture-vs-software-design এর একটি টুকরো )

Comments

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

— মাইক জি

Answer 9

ব্যক্তিগতভাবে, আমি এটি পছন্দ করি:

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

জাভা জন্য এসসিইএ Mark মার্ক কেড এবং হামফ্রে শীল দ্বারা পরিচালিত EE স্টাডি গাইড

Comments

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

— রেনে এনরিকিক্স

Answer 10

আমি অনেক ব্যাখ্যার সাথে একমত; মূলত আমরা স্থাপত্য নকশা এবং সফ্টওয়্যার সিস্টেমগুলির বিশদ নকশার মধ্যে পার্থক্যটি স্বীকৃতি দিচ্ছি।

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

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

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

Answer 11

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

এটি সাধারণভাবে বলা যায় যে নকশার চেয়ে আর্কিটেকচারটি উচ্চ বিমূর্ত মাত্রায় রয়েছে, বা আর্কিটেকচারটি যৌক্তিক এবং নকশাটি শারীরিক। তবে এই ধারণাটি সাধারণত গৃহীত হয়, বাস্তবে এটি অকেজো। যৌক্তিক এবং শারীরিক মধ্যে আপনি উচ্চ বা নিম্ন বিমূর্ততার মধ্যে রেখাটি কোথায় আঁকেন? এটা নির্ভর করে!

সুতরাং, আমার পরামর্শটি হ'ল:

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

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

Comments

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

— থমাস আইজিংগার

@ThomasEizinger। আমি আমাদের বইয়ের সাথে একটি লিঙ্ক যুক্ত করেছি। ভাল পরামর্শ। এবং আপনার মন্তব্যও যথাযথ ক্রেডিট দিতে সহায়তা করে। শেষ প্রশ্ন হিসাবে, আমি ডিজাইন ডকুমেন্টেশন প্রচেষ্টা বোঝাতে চাইছি। আমি অনুচ্ছেদে সম্পাদনা করেছি। ধন্যবাদ!

— পাওলো মেরসন

Answer 12

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

Answer 13

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

(উইকিপিডিয়া থেকে, http://en.wikedia.org/wiki/Software_architecture )

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

(উইকিপিডিয়া থেকে, http://en.wikedia.org/wiki/Software_design )

এটি নিজের চেয়ে ভাল বলতে পারত না :)

Answer 14

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

সুতরাং আপনি বিল্ডিংটি আর্কিটেক্ট করার সময় আপনি প্রতিটি অফিসের বিন্যাস ডিজাইন করেননি। আমি মনে করি একই সফ্টওয়্যার জন্য সত্য।

আপনি "লেআউটটি আর্কিটেকিং" হিসাবে লেআউটটি ডিজাইনিং করতে পারেন ...

Answer 15

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

Answer 16

সফ্টওয়্যার আর্কিটেকচারটি "ইস্যুগুলির সাথে সম্পর্কিত ... গণনার অ্যালগরিদম এবং ডেটা কাঠামো ছাড়িয়ে।

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

নকশাটি ডিজাইনের উপাদানগুলির Modulariization এবং বিস্তারিত ইন্টারফেস, তাদের আলগোরিদিম এবং পদ্ধতি এবং আর্কিটেকচার সমর্থন এবং প্রয়োজনীয়তা পূরণের জন্য প্রয়োজনীয় ডেটা ধরণের সাথে সম্পর্কিত is

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

এই লিঙ্কটি দেখুন।

আর্কিটেকচার, ডিজাইন এবং বাস্তবায়ন শর্তাদি সংজ্ঞায়িত করা

Answer 17

আর্কিটেকচার:
বিমূর্ততার উচ্চ স্তরে কাঠামোগত ডিজাইনের কাজ যা সিস্টেমে প্রযুক্তিগতভাবে গুরুত্বপূর্ণ প্রয়োজনীয়তা উপলব্ধি করে। স্থাপত্যটি আরও নকশার জন্য ভিত্তি স্থাপন করে down

নকশা:
বিমূর্ততার প্রতিটি স্তরের পুনরাবৃত্ত প্রক্রিয়াটির মাধ্যমে আর্কিটেকচারটি কী করে না তা পূরণ করার শিল্প।

Answer 18

আর্কিটেকচারটি ডিজাইন থেকে আলাদা করার ক্ষেত্রে আমার এই কাগজটি সত্যই পছন্দ হয়েছে:

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

একে ইনটেনশন / লোকাল হাইপোথিসিস বলে। স্থানীয় এবং অবিচ্ছিন্ন সফ্টওয়্যারটির প্রকৃতি সম্পর্কিত বিবৃতিগুলি স্থাপত্যগুলি। স্থানীয় এবং অন্তরঙ্গ যে বিবৃতিগুলি হ'ল নকশা।

Comments

হ্যাঁ অবশ্যই. আমি উপরে প্রস্তাবিত একই ধারণা (একই লেখক থেকে)। আমি মনে করি তারা এই ক্ষেত্রে সহায়ক ধারণা।

— ইয়ন

Answer 19

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

Comments

আমি এই উত্তরটি কেবল এই বাক্যটির কারণে পছন্দ করি "তবে আর্কিটেকচারটিও নকশার মধ্যে রয়েছে" " আমি বলব যে "আর্কিটেকচার ডিজাইনের মধ্যে থাকতে পারে।" - এটা আপনার উপর নির্ভর করছে. তারা আলাদা হয় না।

— মিরোস্লাভ ট্রিনিনিক

Answer 20

অত্যন্ত বিষয়গত তবে আমার গ্রহণ:

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

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

Answer 21

সফ্টওয়্যার আর্কিটেকচারটি সিস্টেম পর্যায়ে সর্বাধিক ব্যবহৃত হয়, যখন আপনার প্রয়োজন হয় উচ্চতর আর্কিটেকচার স্তরের দ্বারা অ্যাপ্লিকেশনগুলিতে চিহ্নিত বিজনেস এবং ফাংশনগুলি project

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

তবে যখন কোনও সফ্টওয়্যার আর্কিটেক্ট তার সমাধানের বিবরণ দেবে, তখন সে বুঝতে পারবে:

"পোর্টফোলিও মূল্যায়ন" কেবল একটি অ্যাপ্লিকেশন হতে পারে না। এটি পরিচালনাযোগ্য প্রকল্পগুলিতে যেমন:

• গুই
• লঞ্চার
• ডেস্প্যাচার
• ...

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

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

Answer 22

যদি কেউ কোনও জাহাজ তৈরি করে, তবে ইঞ্জিন, হাল, বৈদ্যুতিক সার্কিট ইত্যাদি হবে তার "স্থাপত্য উপাদান" elements তার জন্য, ইঞ্জিন-নির্মাণ হবে "ডিজাইনের কাজ"।

তারপরে যদি তিনি ইঞ্জিনটি অন্য কোনও দলের কাছে নির্ধারিত করেন তবে তারা একটি "ইঞ্জিন আর্কিটেকচার" তৈরি করবেন ...

সুতরাং - এটি বিমূর্ততা বা বিশদ স্তরের উপর নির্ভর করে। এক ব্যক্তির 'আর্কিটেকচার অ্যানরিজ ডিজাইন' হতে পারে!

Answer 23

আর্কিটেকচার হ'ল "নকশার সিদ্ধান্তগুলি যা পরিবর্তন করা শক্ত" "

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

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

Answer 24

ক্লিফ নোট সংস্করণ:

ডিজাইন: পছন্দসই পণ্যের নির্দিষ্টকরণের ভিত্তিতে একটি সমাধান কার্যকর করা।

আর্কিটেকচার: আপনার নকশাকে সমর্থন করে এমন ভিত্তি / সরঞ্জাম / অবকাঠামো / উপাদানগুলি।

এটি একটি বিস্তৃত প্রশ্ন যা প্রচুর প্রতিক্রিয়া জানাবে।

Answer 25

আর্কিটেকচার হ'ল একটি সিস্টেম তৈরির জন্য নকশা নিদর্শনগুলির ফলাফল।

আমার ধারণা ডিজাইন কি এই সব একসাথে রাখার জন্য সৃষ্টিশীলতা ব্যবহার করা হয়?

Comments

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

— জাভিয়ের 16

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

— মার্ক রেডম্যান

Answer 26

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

একাডেমিকরা সফ্টওয়্যার ডিজাইনের বৃহত্তর ক্ষেত্রের অংশ হিসাবে আর্কিটেকচারটি দেখার প্রবণতা দেখায়। যদিও ক্রমবর্ধমান স্বীকৃতি রয়েছে যে আর্চ একটি নিজস্ব ক্ষেত্র।

অনুশীলনকারীরা আর্চকে উচ্চ-স্তরের ডিজাইন সিদ্ধান্ত হিসাবে দেখেন যা কৌশলগত এবং পূর্বাবস্থায় ফেলার জন্য ব্যয়বহুল হতে পারে।

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

Answer 27

আর্কিটেকচারটি উচ্চ স্তর, বিমূর্ত এবং যৌক্তিক নকশা যেখানে সফ্টওয়্যার ডিজাইনটি নিম্ন স্তরের, বিশদ এবং শারীরিক নকশা।

Answer 28

এছাড়াও, দেখুন: http://en.wikedia.org/wiki/4%2B1_ আর্কিটেকচারাল_ভিউ_মডেল

Comments

ভাদদী, লিঙ্কটি পোস্ট করার পাশাপাশি সামগ্রীর সংক্ষিপ্তসার বিবেচনা করুন। বিষয়টি নিয়ে আলোচনার জন্য এই মেটা পোস্টটি দেখুন । ধন্যবাদ!

— গারগান্টুচেট

Answer 29

আমি তার কাগজে রয় থমাস ফিল্ডিংয়ের সংজ্ঞা এবং ব্যাখ্যাটি সফ্টওয়্যার আর্কিটেকচারটি কী তা সম্পর্কে পছন্দ করি: আর্কিটেকচারাল স্টাইলস এবং নেটওয়ার্ক-ভিত্তিক সফ্টওয়্যার আর্কিটেকচারের ডিজাইন

একটি সফ্টওয়্যার আর্কিটেকচার হ'ল কোনও সফ্টওয়্যার সিস্টেমের ক্রিয়াকলাপের কিছু পর্যায়ে রান-টাইম উপাদানগুলির বিমূর্ততা। একটি সিস্টেম বিভিন্ন স্তরের বিমূর্ততা এবং বিভিন্ন ক্রিয়াকলাপের সমন্বয়ে গঠিত হতে পারে যার প্রতিটি নিজস্ব সফ্টওয়্যার আর্কিটেকচার সহ।

তিনি "রান-টাইম উপাদানগুলি" এবং "বিমূর্তির স্তর" তে জোর দিয়েছিলেন।

Comments

রান-টাইম উপাদানগুলি অ্যাপ্লিকেশনের উপাদানগুলি বা মডিউলগুলিকেও বোঝায় এবং প্রতিটি মডিউল বা উপাদান তার নিজস্ব স্তর বিমূর্ততা ধারণ করে। সঠিক?

— অঙ্কিত রানা

Answer 30

এর কোনও যথাযথ উত্তর নেই কারণ "সফ্টওয়্যার আর্কিটেকচার" এবং "সফ্টওয়্যার ডিজাইন" এর বেশ কয়েকটি সংজ্ঞা রয়েছে এবং এর কোনওটির পক্ষেও কোনও প্রচলিত সংজ্ঞা নেই।

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

আমার সামান্য ফ্লিপ্যান্ট সংজ্ঞা ( এসআইআই সংজ্ঞা পৃষ্ঠায় পাওয়া যায় ) হ'ল এটি এমন সিদ্ধান্তের সেট যা ভুলভাবে করা হলে, আপনার প্রকল্পটি বাতিল করতে দেয়।

ধারণাটি হিসাবে আর্কিটেকচার, নকশা এবং বাস্তবায়নকে পৃথক করার একটি কার্যকর প্রচেষ্টা কিছু বছর আগে "আর্কিটেকচার, ডিজাইন, বাস্তবায়ন" শীর্ষক একটি গবেষণামূলক গবেষণাপত্রে আমোনন ইডেন এবং রিক কাজম্যান করেছিলেন যা এখানে পাওয়া যায়: http: //www.sei.cmu .edu / গ্রন্থাগার / সম্পদ / ICSE03-1.pdf । তাদের ভাষাটি বেশ বিমূর্ত তবে সরলতার সাথে তারা বলেছে যে আর্কিটেকচারটি এমন নকশা যা অনেকগুলি প্রসঙ্গে ব্যবহার করা যেতে পারে এবং এটি সিস্টেম জুড়ে প্রয়োগ করা যেতে পারে, নকশাটি (ভুল) নকশা যা অনেকগুলি প্রসঙ্গে ব্যবহার করা যেতে পারে তবে একটি নির্দিষ্ট অংশে প্রয়োগ করা হয় সিস্টেমের, এবং বাস্তবায়নটি একটি প্রসঙ্গে নির্দিষ্ট নকশা করা হয় এবং সেই প্রসঙ্গে প্রয়োগ করা হয়।

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

আশা করি এটা কাজে লাগবে!