Software architecture
سافٹ ویئر فن تعمیر ایک سافٹ ویئر سسٹم اور اس طرح کے ڈھانچے اور نظام بنانے کے نظم و ضبط کے بارے میں استدلال کرنے کے لیے درکار ڈھانچوں کا مجموعہ ہے۔ ہر ڈھانچہ سافٹ ویئر عناصر، ان کے درمیان تعلقات، اور دونوں عناصر اور تعلقات کی خصوصیات پر مشتمل ہوتا ہے۔ سافٹ ویئر سسٹم کا فن تعمیر ایک استعارہ ہے، جو عمارت کے فن تعمیر سے ملتا جلتا ہے۔ یہ نظام اور ترقیاتی منصوبے کے بلیو پرنٹ کے طور پر کام کرتا ہے، جسے پراجیکٹ مینجمنٹ بعد میں ٹیموں اور اس میں شامل لوگوں کے ذریعے انجام دیے جانے والے ضروری کاموں کو خلاصہ کرنے کے لیے استعمال کر سکتا ہے۔ سافٹ ویئر فن تعمیر بنیادی ساختی انتخاب کرنے کے بارے میں ہے جو ایک بار نافذ ہونے کے بعد تبدیل کرنا مہنگا ہوتا ہے۔ سافٹ ویئر فن تعمیر کے انتخاب میں سافٹ ویئر کے ڈیزائن میں امکانات سے مخصوص ساختی اختیارات شامل ہیں۔ مثال کے طور پر، خلائی شٹل لانچ گاڑی کو کنٹرول کرنے والے نظاموں کو بہت تیز اور بہت قابل اعتماد ہونے کی ضرورت تھی۔ لہذا، ایک مناسب ریئل ٹائم کمپیوٹنگ زبان کا انتخاب کرنے کی ضرورت ہوگی۔ مزید برآں، وشوسنییتا کی ضرورت کو پورا کرنے کے لیے پروگرام کی متعدد بے کار اور آزادانہ طور پر تیار کردہ کاپیاں رکھنے کا انتخاب کیا جا سکتا ہے، اور نتائج کی جانچ پڑتال کرتے ہوئے ان کاپیوں کو آزاد ہارڈ ویئر پر چلانے کا انتخاب کیا جا سکتا ہے۔ دستاویزی سافٹ ویئر فن تعمیر اسٹیک ہولڈرز کے درمیان بات چیت کو آسان بناتا ہے، اعلی سطحی ڈیزائن کے بارے میں ابتدائی فیصلوں پر قبضہ کرتا ہے، اور منصوبوں کے درمیان ڈیزائن کے اجزاء کے دوبارہ استعمال کی اجازت دیتا ہے۔ سافٹ ویئر آرکیٹیکچرز کے دائرہ کار کے بارے میں رائے کا دائرہ مختلف ہوتا ہے: میکروسکوپک سسٹم کا ڈھانچہ: اس سے فن تعمیر کو سافٹ ویئر سسٹم کے اعلی سطح کے خلاصہ کے طور پر مراد کیا جاتا ہے جو کنیکٹرز کے ساتھ مل کر کمپیوٹیشنل اجزاء کے مجموعے پر مشتمل ہوتا ہے جو ان اجزاء کے درمیان تعامل کو بیان کرتا ہے۔ اہم چیزیں-جو بھی وہ ہے: اس سے مراد یہ حقیقت ہے کہ سافٹ ویئر آرکیٹیکٹس کو خود کو ان فیصلوں سے متعلق ہونا چاہیے جن کا نظام اور اس کے اسٹیک ہولڈرز پر زیادہ اثر پڑتا ہے۔ وہ جو کسی نظام کو اس کے ماحول میں سمجھنے کے لیے بنیادی ہے وہ چیزیں جنہیں لوگ تبدیل کرنا مشکل سمجھتے ہیں: چونکہ فن تعمیر کو ڈیزائن کرنا سافٹ ویئر سسٹم کے لائف سائیکل کے آغاز میں ہوتا ہے، اس لیے معمار کو ان فیصلوں پر توجہ دینی چاہیے جو پہلی بار درست ہونے چاہئیں۔ اس سوچ کی پیروی کرتے ہوئے، آرکیٹیکچرل ڈیزائن کے مسائل غیر آرکیٹیکچرل بن سکتے ہیں جب ان کی ناقابل واپسی پر قابو پایا جا سکتا ہے۔ آرکیٹیکچرل ڈیزائن کے فیصلوں کا ایک مجموعہ: سافٹ ویئر آرکیٹیکچر کو محض ماڈلز یا ڈھانچوں کا ایک مجموعہ نہیں سمجھا جانا چاہیے، بلکہ اس میں وہ فیصلے شامل ہونے چاہئیں جو ان مخصوص ڈھانچوں کی طرف لے جاتے ہیں، اور ان کے پیچھے استدلال۔ اس بصیرت کی وجہ سے سافٹ ویئر آرکیٹیکچر نالج مینجمنٹ میں کافی تحقیق ہوئی ہے۔ سافٹ ویئر فن تعمیر بمقابلہ ڈیزائن اور ضروریات انجینئرنگ کے درمیان کوئی واضح فرق نہیں ہے (نیچے متعلقہ فیلڈز دیکھیں)۔ یہ سب اعلی سطح کے ارادوں سے لے کر نچلی سطح کی تفصیلات تک "جان بوجھ کر کیے جانے والے سلسلے" کا حصہ ہیں۔ خصوصیات سافٹ ویئر فن تعمیر مندرجہ ذیل کو ظاہر کرتا ہے: اسٹیک ہولڈرز کی کثیر تعداد: سافٹ ویئر سسٹم کو مختلف اسٹیک ہولڈرز جیسے کاروباری مینیجرز، مالکان، صارفین اور آپریٹرز کی ضروریات کو پورا کرنا ہوتا ہے۔ نظام کے حوالے سے ان تمام اسٹیک ہولڈرز کے اپنے خدشات ہیں۔ ان خدشات کو متوازن کرنا اور یہ ظاہر کرنا کہ ان پر توجہ دی گئی ہے، نظام کو ڈیزائن کرنے کا حصہ ہے۔ اس کا مطلب یہ ہے کہ فن تعمیر میں مختلف قسم کے خدشات اور اسٹیک ہولڈرز سے نمٹنا شامل ہے، اور اس کی نوعیت کثیر الضابطہ ہے۔ خدشات کو الگ کرنا: معماروں کے لیے پیچیدگی کو کم کرنے کا قائم شدہ طریقہ ان خدشات کو الگ کرنا ہے جو ڈیزائن کو چلاتے ہیں۔ آرکیٹیکچر دستاویزات سے پتہ چلتا ہے کہ تمام اسٹیک ہولڈرز کے خدشات کو مختلف اسٹیک ہولڈرز کے خدشات سے وابستہ الگ الگ نقطہ نظر سے ماڈلنگ اور فن تعمیر کی وضاحت کے ذریعے حل کیا جاتا ہے۔ ان الگ الگ وضاحتوں کو آرکیٹیکچرل ویوز کہا جاتا ہے (مثال کے طور پر 4 + 1 آرکیٹیکچرل ویو ماڈل دیکھیں)۔ معیار پر مبنی: کلاسیکی سافٹ ویئر ڈیزائن کے نقطہ نظر (مثال کے طور پر۔ جیکسن اسٹرکچرڈ پروگرامنگ) مطلوبہ فعالیت اور سسٹم کے ذریعے ڈیٹا کے بہاؤ سے کارفرما تھے، لیکن موجودہ بصیرت یہ ہے کہ سافٹ ویئر سسٹم کا فن تعمیر اس کے معیار کی صفات جیسے غلطی رواداری، پسماندہ مطابقت، توسیع پذیری، وشوسنییتا، برقرار رکھنے، دستیابی، سلامتی، استعمال پذیری، اور اس طرح کی دیگر صلاحیتوں سے زیادہ قریب سے متعلق ہے۔ اسٹیک ہولڈر کے خدشات اکثر ان معیار کی صفات کی ضروریات میں تبدیل ہو جاتے ہیں، جنہیں مختلف طور پر غیر فعال ضروریات، اضافی فعال ضروریات، طرز عمل کی ضروریات، یا معیار کی خاصیت کی ضروریات کہا جاتا ہے۔ بار بار آنے والے انداز: تعمیراتی فن تعمیر کی طرح، سافٹ ویئر فن تعمیر کے شعبے نے بار بار آنے والے خدشات کو دور کرنے کے لیے معیاری طریقے تیار کیے ہیں۔ ان "معیاری طریقوں" کو تجریدی کی مختلف سطحوں پر مختلف ناموں سے پکارا جاتا ہے۔ بار بار آنے والے حل کے لیے عام اصطلاحات آرکیٹیکچرل سٹائل، حکمت عملی، حوالہ فن تعمیر اور آرکیٹیکچرل پیٹرن ہیں۔ تصوراتی سالمیت: ایک اصطلاح جسے فریڈ بروکس نے اپنی 1975 کی کتاب دی میتھکل مین منتھ میں اس خیال کی نشاندہی کرنے کے لیے متعارف کرایا تھا کہ سافٹ ویئر سسٹم کا فن تعمیر اس کے مجموعی وژن کی نمائندگی کرتا ہے کہ اسے کیا کرنا چاہیے اور اسے کیسے کرنا چاہیے۔ اس وژن کو اس کے نفاذ سے الگ کیا جانا چاہیے۔ معمار "وژن کے محافظ" کا کردار ادا کرتا ہے، اس بات کو یقینی بناتا ہے کہ نظام میں اضافے فن تعمیر کے مطابق ہیں، اس لیے تصوراتی سالمیت کو محفوظ رکھتا ہے۔ علمی رکاوٹیں: ایک مشاہدہ جو سب سے پہلے 1967 کے ایک مقالے میں کمپیوٹر پروگرامر میلون کونوے نے کیا تھا کہ وہ تنظیمیں جو سسٹم ڈیزائن کرتی ہیں وہ ایسے ڈیزائن تیار کرنے پر مجبور ہیں جو ان تنظیموں کے مواصلاتی ڈھانچے کی کاپیاں ہیں۔ تصوراتی سالمیت کی طرح، یہ فریڈ بروکس ہی تھے جنہوں نے اسے وسیع تر سامعین کے سامنے متعارف کرایا جب انہوں نے اپنے خوبصورت کلاسک دی میتھکل مین منتھ میں اس مقالے اور اس خیال کا حوالہ دیتے ہوئے اسے "کونوے کا قانون" قرار دیا۔ محرک سافٹ ویئر فن تعمیر ایک پیچیدہ نظام کا "ذہنی طور پر قابل فہم" خلاصہ ہے۔ یہ خلاصہ متعدد فوائد فراہم کرتا ہے: یہ نظام کی تعمیر سے پہلے سافٹ ویئر سسٹم کے رویے کے تجزیے کی بنیاد فراہم کرتا ہے۔ اس بات کی تصدیق کرنے کی صلاحیت کہ مستقبل کا سافٹ ویئر سسٹم اصل میں تعمیر کیے بغیر اپنے اسٹیک ہولڈرز کی ضروریات کو پورا کرتا ہے، لاگت کی خاطر خواہ بچت اور خطرے کو کم کرنے کی نمائندگی کرتا ہے۔ اس طرح کے تجزیے انجام دینے کے لیے متعدد تکنیکیں تیار کی گئی ہیں، جیسے اے ٹی اے ایم یا سافٹ ویئر سسٹم کی بصری نمائندگی بنا کر۔ یہ عناصر اور فیصلوں کے دوبارہ استعمال کی بنیاد فراہم کرتا ہے۔ ایک مکمل سافٹ ویئر فن تعمیر یا اس کے کچھ حصے، جیسے انفرادی تعمیراتی حکمت عملی اور فیصلے، متعدد نظاموں میں دوبارہ استعمال کیے جا سکتے ہیں جن کے اسٹیک ہولڈرز کو یکساں معیار کی صفات یا فعالیت کی ضرورت ہوتی ہے، ڈیزائن کے اخراجات کو بچانا اور ڈیزائن کی غلطیوں کے خطرے کو کم کرنا۔ یہ ابتدائی ڈیزائن فیصلوں کی حمایت کرتا ہے جو نظام کی ترقی، تعیناتی اور دیکھ بھال کی زندگی کو متاثر کرتے ہیں۔ شیڈول اور بجٹ میں اضافے کو روکنے کے لیے ابتدائی، زیادہ اثر والے فیصلوں کو درست کرنا ضروری ہے۔ یہ اسٹیک ہولڈرز کے ساتھ بات چیت کو آسان بناتا ہے، ایک ایسے نظام میں حصہ ڈالتا ہے جو ان کی ضروریات کو بہتر طریقے سے پورا کرتا ہے۔ اسٹیک ہولڈرز کے نقطہ نظر سے پیچیدہ نظاموں کے بارے میں بات چیت کرنے سے انہیں ان کی بیان کردہ ضروریات کے نتائج اور ان پر مبنی ڈیزائن کے فیصلوں کو سمجھنے میں مدد ملتی ہے۔ فن تعمیر نظام کو نافذ کرنے سے پہلے ڈیزائن کے فیصلوں کے بارے میں بات چیت کرنے کی صلاحیت دیتا ہے، جب وہ اب بھی موافقت کے لیے نسبتا آسان ہوتے ہیں۔ یہ رسک مینجمنٹ میں مدد کرتا ہے۔ سافٹ ویئر فن تعمیر خطرات اور ناکامی کے امکانات کو کم کرنے میں مدد کرتا ہے۔ یہ لاگت میں کمی کے قابل بناتا ہے۔ سافٹ ویئر فن تعمیر پیچیدہ آئی ٹی منصوبوں میں خطرے اور اخراجات کو سنبھالنے کا ایک ذریعہ ہے۔ سافٹ ویئر ڈیزائن اور (سول) فن تعمیر کے درمیان موازنہ پہلی بار 1960 کی دہائی کے آخر میں کیا گیا تھا، لیکن "سافٹ ویئر فن تعمیر" کی اصطلاح 1990 کی دہائی تک وسیع پیمانے پر استعمال نہیں ہوئی تھی۔ کمپیوٹر سائنس کے شعبے کو اپنے قیام کے بعد سے ہی پیچیدگی سے وابستہ مسائل کا سامنا کرنا پڑا تھا۔ پیچیدگی کے ابتدائی مسائل کو ڈویلپرز نے صحیح ڈیٹا ڈھانچے کا انتخاب کرکے، الگورتھم تیار کرکے، اور خدشات کو الگ کرنے کے تصور کو لاگو کرکے حل کیا تھا۔ اگرچہ "سافٹ ویئر فن تعمیر" کی اصطلاح صنعت کے لیے نسبتا نئی ہے، لیکن اس شعبے کے بنیادی اصولوں کو 1980 کی دہائی کے وسط سے سافٹ ویئر انجینئرنگ کے علمبرداروں نے وقفے وقفے سے لاگو کیا ہے۔ کسی نظام کے سافٹ ویئر فن تعمیر کو پکڑنے اور اس کی وضاحت کرنے کی ابتدائی کوششیں غیر واضح اور غیر منظم تھیں، جن کی خصوصیت اکثر باکس اور لائن خاکے کے ایک سیٹ سے ہوتی ہے۔ ایک تصور کے طور پر سافٹ ویئر فن تعمیر کی ابتدا 1968 میں ایڈسگر ڈیکسٹرا اور 1970 کی دہائی کے اوائل میں ڈیوڈ پرناس کی تحقیق سے ہوئی ہے۔ ان سائنسدانوں نے اس بات پر زور دیا کہ سافٹ ویئر سسٹم کا ڈھانچہ اہم ہے اور ڈھانچے کو درست کرنا بہت ضروری ہے۔ 1990 کی دہائی کے دوران نظم و ضبط کے بنیادی پہلوؤں کی وضاحت اور ضابطہ بندی کے لیے ایک ٹھوس کوشش کی گئی، جس میں تحقیقی کام آرکیٹیکچرل اسٹائل (پیٹرن)، آرکیٹیکچر کی تفصیل کی زبانوں، آرکیٹیکچر دستاویزات، اور رسمی طریقوں پر مرکوز تھا۔ تحقیقی اداروں نے سافٹ ویئر فن تعمیر کو ایک نظم کے طور پر آگے بڑھانے میں نمایاں کردار ادا کیا ہے۔ کارنیگی میلن کی میری شا اور ڈیوڈ گارلن نے 1996 میں سافٹ ویئر آرکیٹیکچر: ایک ابھرتے ہوئے نظم و ضبط پر تناظر کے عنوان سے ایک کتاب لکھی، جس نے سافٹ ویئر آرکیٹیکچر کے تصورات جیسے اجزاء، کنیکٹرز اور اسٹائل کو فروغ دیا۔ سافٹ ویئر آرکیٹیکچر ریسرچ میں یونیورسٹی آف کیلیفورنیا، اروائن کے انسٹی ٹیوٹ فار سافٹ ویئر ریسرچ کی کوششیں بنیادی طور پر آرکیٹیکچرل اسٹائل، آرکیٹیکچر کی تفصیل کی زبانوں اور متحرک آرکیٹیکچرز میں ہوتی ہیں۔ آئی ای ای ای 1471-2000، "سافٹ ویئر-انٹینسیو سسٹمز کی آرکیٹیکچر تفصیل کے لیے تجویز کردہ مشق"، سافٹ ویئر آرکیٹیکچر کے شعبے میں پہلا رسمی معیار تھا۔ اسے 2007 میں آئی ایس او نے آئی ایس او/آئی ای سی 42010:2007 کے طور پر اپنایا تھا۔ نومبر 2011 میں، آئی ای ای ای 1471-2000 کو آئی ایس او/آئی ای سی/آئی ای ای ای 42010:2011، "سسٹمز اینڈ سافٹ ویئر انجینئرنگ-آرکیٹیکچر ڈسکریشن" (مشترکہ طور پر آئی ای ای ای اور آئی ایس او کے ذریعے شائع) نے ختم کر دیا۔ جبکہ آئی ای ای ای 1471 میں، سافٹ ویئر فن تعمیر "سافٹ ویئر سے بھرپور نظاموں" کے فن تعمیر کے بارے میں تھا، جس کی تعریف "کسی بھی ایسے نظام کے طور پر کی گئی ہے جہاں سافٹ ویئر مجموعی طور پر نظام کے ڈیزائن، تعمیر، تعیناتی اور ارتقا میں ضروری اثرات کا باعث بنتا ہے"، 2011 کا ایڈیشن ایک قدم آگے بڑھ کر آئی ایس او/آئی ای سی 15288 اور آئی ایس او/آئی ای سی 12207 کی تعریفوں کو شامل کرتا ہے، جس میں نہ صرف ہارڈ ویئر اور سافٹ ویئر شامل ہیں، بلکہ "انسان، عمل، طریقہ کار، سہولیات، مواد اور قدرتی طور پر پائے جانے والے ادارے" بھی شامل ہیں۔ یہ سافٹ ویئر فن تعمیر، انٹرپرائز فن تعمیر اور حل فن تعمیر کے درمیان تعلقات کی عکاسی کرتا ہے۔ آرکیٹیکچر کی سرگرمیاں بہت سی سرگرمیاں ہیں جو ایک سافٹ ویئر آرکیٹیکٹ انجام دیتا ہے۔ سافٹ ویئر آرکیٹیکٹ عام طور پر پروجیکٹ مینیجرز کے ساتھ کام کرتا ہے، اسٹیک ہولڈرز کے ساتھ آرکیٹیکچرل لحاظ سے اہم ضروریات پر تبادلہ خیال کرتا ہے، سافٹ ویئر آرکیٹیکچر ڈیزائن کرتا ہے، ڈیزائن کا جائزہ لیتا ہے، ڈیزائنرز اور اسٹیک ہولڈرز کے ساتھ بات چیت کرتا ہے، آرکیٹیکچرل ڈیزائن کو دستاویز کرتا ہے اور بہت کچھ۔ سافٹ ویئر آرکیٹیکچر ڈیزائن میں چار بنیادی سرگرمیاں ہیں۔ یہ بنیادی فن تعمیر کی سرگرمیاں بار بار اور ابتدائی سافٹ ویئر ڈویلپمنٹ لائف سائیکل کے مختلف مراحل کے ساتھ ساتھ کسی نظام کے ارتقاء پر بھی انجام دی جاتی ہیں۔ آرکیٹیکچرل تجزیہ اس ماحول کو سمجھنے کا عمل ہے جس میں ایک مجوزہ نظام کام کرے گا اور نظام کی ضروریات کا تعین کرے گا۔ تجزیہ کی سرگرمی کے لیے ان پٹ یا تقاضے کسی بھی تعداد میں اسٹیک ہولڈرز کی طرف سے آ سکتے ہیں اور اس میں ایسی چیزیں شامل ہوتی ہیں جیسے: آپریشنل ہونے پر سسٹم کیا کرے گا (فنکشنل تقاضے) کہ سسٹم رن ٹائم غیر فعال ضروریات جیسے وشوسنییتا، آپریبلٹی، کارکردگی کی کارکردگی، سیکیورٹی، مطابقت کی وضاحت آئی ایس او/آئی ای سی 25010:2011 معیاری ترقیاتی وقت میں غیر فعال ضروریات جیسے کہ برقرار رکھنے اور منتقلی کی وضاحت آئی ایس او 25010:2011 معیاری کاروباری ضروریات اور کسی نظام کے ماحولیاتی سیاق و سباق جو وقت کے ساتھ بدل سکتے ہیں، جیسے کہ قانونی، سماجی، مالی، مسابقتی اور ٹیکنالوجی کے خدشات۔ تجزیہ کی سرگرمی کے نتائج وہ تقاضے ہیں جن کا سافٹ ویئر سسٹم کے فن تعمیر پر قابل پیمائش اثر پڑتا ہے، جسے آرکیٹیکچرل لحاظ سے اہم تقاضے کہا جاتا ہے۔ آرکیٹیکچرل ترکیب یا ڈیزائن فن تعمیر کی تخلیق کا عمل ہے۔ تجزیہ کے ذریعہ طے شدہ آرکیٹیکچرل لحاظ سے اہم ضروریات، ڈیزائن کی موجودہ حالت اور کسی بھی تشخیصی سرگرمیوں کے نتائج کو دیکھتے ہوئے، ڈیزائن بنایا اور بہتر بنایا جاتا ہے۔ فن تعمیر کی تشخیص اس بات کا تعین کرنے کا عمل ہے کہ موجودہ ڈیزائن یا اس کا ایک حصہ تجزیہ کے دوران حاصل کردہ ضروریات کو کتنی اچھی طرح سے پورا کرتا ہے۔ تشخیص تب بھی ہو سکتی ہے جب کوئی معمار ڈیزائن کے فیصلے پر غور کر رہا ہو، یہ ڈیزائن کے کچھ حصے کے مکمل ہونے کے بعد ہو سکتا ہے، یہ حتمی ڈیزائن مکمل ہونے کے بعد ہو سکتا ہے یا یہ نظام کی تعمیر کے بعد ہو سکتا ہے۔ دستیاب سافٹ ویئر فن تعمیر کی تشخیصی تکنیکوں میں آرکیٹیکچر ٹریڈ آف اینالیسس میتھڈ (اے ٹی اے ایم) اور ٹی اے آر اے شامل ہیں۔ تکنیکوں کا موازنہ کرنے کے فریم ورک پر سار رپورٹ اور آرکیٹیکچر ریویوز: پریکٹس اینڈ ایکسپیرئنس جیسے فریم ورک میں تبادلہ خیال کیا گیا ہے۔ آرکیٹیکچر ارتقاء ضروریات اور ماحول میں ہونے والی تبدیلیوں کو پورا کرنے کے لیے موجودہ سافٹ ویئر فن تعمیر کو برقرار رکھنے اور اپنانے کا عمل ہے۔ چونکہ سافٹ ویئر فن تعمیر سافٹ ویئر سسٹم کا ایک بنیادی ڈھانچہ فراہم کرتا ہے، اس لیے اس کا ارتقاء اور دیکھ بھال لازمی طور پر اس کے بنیادی ڈھانچے کو متاثر کرے گی۔ اس طرح، فن تعمیر کے ارتقاء کا تعلق نئی فعالیت کو شامل کرنے کے ساتھ ساتھ موجودہ فعالیت اور نظام کے رویے کو برقرار رکھنے سے ہے۔ فن تعمیر میں تنقیدی معاون سرگرمیوں کی ضرورت ہوتی ہے۔ یہ معاون سرگرمیاں بنیادی سافٹ ویئر فن تعمیر کے پورے عمل میں ہوتی ہیں۔ ان میں علم کا انتظام اور مواصلات، ڈیزائن استدلال اور فیصلہ سازی، اور دستاویزات شامل ہیں۔ فن تعمیر کی معاون سرگرمیاں سافٹ ویئر فن تعمیر کی معاون سرگرمیاں بنیادی سافٹ ویئر فن تعمیر کی سرگرمیوں کے دوران انجام دی جاتی ہیں۔ یہ معاون سرگرمیاں سافٹ ویئر آرکیٹیکٹ کو تجزیہ، ترکیب، تشخیص اور ارتقاء انجام دینے میں مدد کرتی ہیں۔ مثال کے طور پر، ایک معمار کو تجزیہ کے مرحلے کے دوران علم جمع کرنا، فیصلے کرنا اور دستاویز کرنا ہوتا ہے۔ علم کا انتظام اور مواصلات علم کی تلاش اور انتظام کا عمل ہے جو سافٹ ویئر فن تعمیر کو ڈیزائن کرنے کے لیے ضروری ہے۔ سافٹ ویئر آرکیٹیکٹ الگ تھلگ کام نہیں کرتا۔ وہ مختلف اسٹیک ہولڈرز سے ان پٹ، فنکشنل اور غیر فنکشنل ضروریات، اور ڈیزائن کے سیاق و سباق حاصل کرتے ہیں ؛ اور اسٹیک ہولڈرز کو آؤٹ پٹ فراہم کرتے ہیں۔ سافٹ ویئر فن تعمیر کا علم اکثر خاموش ہوتا ہے اور اسے اسٹیک ہولڈرز کے سروں میں برقرار رکھا جاتا ہے۔ سافٹ ویئر آرکیٹیکچر نالج مینجمنٹ سرگرمی علم کو تلاش کرنے، بات چیت کرنے اور برقرار رکھنے کے بارے میں ہے۔ چونکہ سافٹ ویئر آرکیٹیکچر ڈیزائن کے مسائل پیچیدہ اور باہم منحصر ہیں، اس لیے ڈیزائن استدلال میں علم کا فرق غلط سافٹ ویئر آرکیٹیکچر ڈیزائن کا باعث بن سکتا ہے۔ علم کے انتظام اور مواصلاتی سرگرمیوں کی مثالوں میں ڈیزائن کے نمونوں کی تلاش، پروٹو ٹائپنگ، تجربہ کار ڈویلپرز اور آرکیٹیکٹس سے پوچھنا، اسی طرح کے نظاموں کے ڈیزائنوں کا جائزہ لینا، دوسرے ڈیزائنرز اور اسٹیک ہولڈرز کے ساتھ علم کا اشتراک کرنا، اور ویکی پیج پر تجربے کو دستاویزی شکل دینا شامل ہیں۔ ڈیزائن استدلال اور فیصلہ سازی ڈیزائن کے فیصلوں کا جائزہ لینے کی سرگرمی ہے۔ یہ سرگرمی تینوں بنیادی سافٹ ویئر فن تعمیر کی سرگرمیوں کے لیے بنیادی ہے۔ اس میں فیصلے کے سیاق و سباق کو جمع کرنا اور جوڑنا، ڈیزائن کے فیصلے کے مسائل کو وضع کرنا، حل کے اختیارات تلاش کرنا اور فیصلے کرنے سے پہلے تجارت کا جائزہ لینا شامل ہے۔ یہ عمل اہم آرکیٹیکچرل ضروریات اور سافٹ ویئر آرکیٹیکچر کے فیصلوں، اور سافٹ ویئر آرکیٹیکچر تجزیہ، ترکیب، اور تشخیص کا جائزہ لیتے ہوئے فیصلہ سازی کی مختلف سطحوں پر ہوتا ہے۔ استدلال کی سرگرمیوں کی مثالوں میں معیار کی صفات پر کسی ضرورت یا ڈیزائن کے اثرات کو سمجھنا، ان مسائل پر سوال اٹھانا جو ڈیزائن کا سبب بن سکتے ہیں، ممکنہ حل کے اختیارات کا اندازہ لگانا، اور حل کے درمیان تجارت کا اندازہ لگانا شامل ہیں۔ دستاویزات سافٹ ویئر فن تعمیر کے عمل کے دوران تیار کردہ ڈیزائن کو ریکارڈ کرنے کا عمل ہے۔ سسٹم کے ڈیزائن کو متعدد ویوز کا استعمال کرتے ہوئے بیان کیا جاتا ہے جس میں اکثر سسٹم کے کوڈ ڈھانچے کو ظاہر کرنے والا جامد نظارہ، عمل کے دوران سسٹم کے اعمال کو ظاہر کرنے والا متحرک نظارہ، اور تعیناتی کا نظارہ شامل ہوتا ہے جس میں دکھایا جاتا ہے کہ کسی سسٹم کو عمل کے لیے ہارڈ ویئر پر کیسے رکھا جاتا ہے۔ کروچٹن کا 4 + 1 ویو سافٹ ویئر فن تعمیر کو دستاویزی شکل دینے کے لیے عام طور پر استعمال ہونے والے ویوز کی تفصیل تجویز کرتا ہے۔ سافٹ ویئر آرکیٹیکچرز کو دستاویزی شکل دینا: ویوز اینڈ بیونڈ میں ان قسم کے اشاروں کی وضاحت ہے جو ویو کی تفصیل میں استعمال کیے جا سکتے ہیں۔ دستاویزات کی سرگرمیوں کی مثالیں تفصیلات لکھنا، سسٹم ڈیزائن ماڈل کو ریکارڈ کرنا، ڈیزائن کے جواز کو دستاویزی شکل دینا، نقطہ نظر تیار کرنا، خیالات کو دستاویزی شکل دینا ہیں۔ سافٹ ویئر فن تعمیر کے موضوعات سافٹ ویئر فن تعمیر کی تفصیل سافٹ ویئر فن تعمیر کی تفصیل میں فن تعمیر کی وضاحت کی زبانیں، فن تعمیر کے نقطہ نظر، اور فن تعمیر کے فریم ورک جیسے میکانزم کا استعمال کرتے ہوئے ماڈلنگ اور آرکیٹیکچرز کی نمائندگی کے اصولوں اور طریقوں کو شامل کیا گیا ہے۔ فن تعمیر کی وضاحتی زبان (ADL) اظہار کا کوئی بھی ذریعہ ہے جو سافٹ ویئر فن تعمیر (ISO/IEC/IEEE 42010) کو بیان کرنے کے لیے استعمال ہوتا ہے۔ 1990 کی دہائی سے بہت سے خصوصی مقاصد کے اے ڈی ایل تیار کیے گئے ہیں، جن میں اے اے ڈی ایل (ایس اے ای معیار)، رائٹ (کارنیگی میلن کے ذریعہ تیار کردہ)، ایکمی (کارنیگی میلن کے ذریعہ تیار کردہ)، ایکس اے ڈی ایل (یو سی آئی کے ذریعہ تیار کردہ)، ڈارون (امپیریل کالج لندن کے ذریعہ تیار کردہ)، ڈی اے او پی-اے ڈی ایل (ملاگا یونیورسٹی کے ذریعہ تیار کردہ)، ایس بی سی-اے ڈی ایل (نیشنل سن یات سین یونیورسٹی کے ذریعہ تیار کردہ)، اور بی اے ڈی ایل (یونیورسٹی آف ایل ایکولا، اٹلی) شامل ہیں۔ فن تعمیر کے نقطہ نظر سافٹ ویئر فن تعمیر کی وضاحتیں عام طور پر نظریات میں منظم کی جاتی ہیں، جو عمارت کے فن تعمیر میں بنائے گئے مختلف قسم کے بلیو پرنٹس سے مشابہت رکھتی ہیں۔ ہر نظریہ اپنے نقطہ نظر کے کنونشنوں کی پیروی کرتے ہوئے نظام کے خدشات کے ایک سیٹ کو خطاب کرتا ہے، جہاں ایک نقطہ نظر ایک وضاحت ہے جو نوٹیشن، ماڈلنگ، اور تجزیہ کی تکنیکوں کو اس نقطہ نظر میں استعمال کرنے کے لیے بیان کرتا ہے جو اسٹیک ہولڈرز کے دیئے گئے سیٹ اور ان کے خدشات (آئی ایس او/آئی ای سی/آئی ای ای ای 42010) کے نقطہ نظر سے زیر بحث فن تعمیر کا اظہار کرتا ہے۔ نقطہ نظر نہ صرف بنائے گئے خدشات (یعنی، جن پر توجہ دی جانی چاہیے) بلکہ پیش کش، استعمال شدہ ماڈل کی اقسام، استعمال شدہ کنونشن اور کسی بھی مستقل مزاجی (خط و کتابت) کے اصولوں کی وضاحت کرتا ہے تاکہ کسی نقطہ نظر کو دوسرے نظریات کے مطابق رکھا جا سکے۔ آرکیٹیکچر فریم ورک ایک آرکیٹیکچر فریم ورک "ایپلی کیشن کے ایک مخصوص ڈومین اور/یا اسٹیک ہولڈرز کی کمیونٹی کے اندر قائم کردہ آرکیٹیکچرز کی وضاحت کے لیے کنونشن، اصولوں اور طریقوں" (آئی ایس او/آئی ای سی/آئی ای ای ای 42010) پر قبضہ کرتا ہے۔ ایک فریم ورک عام طور پر ایک یا زیادہ نقطہ نظر یا اے ڈی ایل کے لحاظ سے نافذ کیا جاتا ہے۔ آرکیٹیکچرل سٹائل اور پیٹرن ایک آرکیٹیکچرل پیٹرن کسی دیئے گئے سیاق و سباق میں سافٹ ویئر آرکیٹیکچر میں عام طور پر پائے جانے والے مسئلے کا ایک عمومی، دوبارہ قابل استعمال حل ہے۔ آرکیٹیکچرل پیٹرن اکثر سافٹ ویئر ڈیزائن پیٹرن کے طور پر دستاویزی ہوتے ہیں۔ روایتی تعمیراتی فن تعمیر کے بعد، 'سافٹ ویئر آرکیٹیکچرل سٹائل' تعمیر کا ایک مخصوص طریقہ ہے، جس کی خصوصیت ان خصوصیات سے ہوتی ہے جو اسے قابل ذکر بناتی ہیں۔ بہت سے تسلیم شدہ آرکیٹیکچرل پیٹرن اور اسٹائل ہیں، ان میں سے: بلیک بورڈ کلائنٹ سرور (2-درجے، 3-درجے، این-درجے، کلاؤڈ کمپیوٹنگ اس انداز کی نمائش کرتا ہے) جزو پر مبنی ڈیٹا پر مبنی ایونٹ پر مبنی (یا مضمر دعوت) پرتوں والا (یا کثیر درجے کا فن تعمیر) مائیکرو سروسز فن تعمیر یک سنگی ایپلی کیشن پیر سے پیر (پی 2 پی) پائپ اور فلٹر پلگ ان ری ایکٹیو فن تعمیر نمائندہ ریاستی منتقلی (آر ای ایس ٹی) اصول پر مبنی سروس پر مبنی کچھ بھی نہیں فن تعمیر خلا پر مبنی سرور لیس فن تعمیر کچھ آرکیٹیکچرل پیٹرن اور آرکیٹیکچرل اسٹائل کو یکساں سمجھتے ہیں، کچھ اسٹائل کو نمونوں کی تخصص کے طور پر مانتے ہیں۔ ان میں جو چیز مشترک ہے وہ یہ ہے کہ نمونے اور انداز دونوں معماروں کے استعمال کے لیے فقرے ہیں، وہ "ایک مشترکہ زبان" یا "الفاظ" فراہم کرتے ہیں جس کے ساتھ نظام کی کلاسوں کو بیان کیا جاتا ہے۔ سافٹ ویئر فن تعمیر اور فرتیلی ترقی اس بات کے بھی خدشات ہیں کہ سافٹ ویئر فن تعمیر بہت زیادہ بگ ڈیزائن اپ فرنٹ کی طرف لے جاتا ہے، خاص طور پر فرتیلی سافٹ ویئر ڈویلپمنٹ کے حامیوں میں۔ اپ فرنٹ ڈیزائن اور چستی کے تبادلے کو متوازن کرنے کے لیے متعدد طریقے تیار کیے گئے ہیں، جن میں فرتیلی طریقہ ڈی ایس ڈی ایم بھی شامل ہے جو ایک "فاؤنڈیشنز" مرحلے کا حکم دیتا ہے جس کے دوران "صرف کافی" تعمیراتی بنیادیں رکھی جاتی ہیں۔ آئی ای ای ای سافٹ ویئر نے چستی اور فن تعمیر کے درمیان تعامل کے لیے ایک خاص مسئلہ وقف کیا۔ سافٹ ویئر فن تعمیر کا کٹاؤ سافٹ ویئر فن تعمیر کا کٹاؤ (یا "ڈیک") سے مراد سافٹ ویئر سسٹم کے منصوبہ بند اور حقیقی فن تعمیر کے درمیان مشاہدہ کیا گیا فرق ہے جیسا کہ اس کے نفاذ میں محسوس ہوتا ہے۔ سافٹ ویئر فن تعمیر کا کٹاؤ اس وقت ہوتا ہے جب عمل درآمد کے فیصلے یا تو منصوبہ بندی کے مطابق فن تعمیر کو مکمل طور پر حاصل نہیں کرتے ہیں یا بصورت دیگر اس فن تعمیر کی رکاوٹوں یا اصولوں کی خلاف ورزی کرتے ہیں۔ مثال کے طور پر، ایک سختی سے پرتوں والے نظام پر غور کریں، جہاں ہر پرت صرف اس کے نیچے کی پرت کے ذریعہ فراہم کردہ خدمات کا استعمال کر سکتی ہے۔ کوئی بھی سورس کوڈ جزو جو اس رکاوٹ کا مشاہدہ نہیں کرتا ہے وہ فن تعمیر کی خلاف ورزی کی نمائندگی کرتا ہے۔ اگر درست نہ کیا جائے تو، اس طرح کی خلاف ورزیاں فن تعمیر کو یک سنگی بلاک میں تبدیل کر سکتی ہیں، جس سے سمجھنے، برقرار رکھنے اور ارتقا پر منفی اثرات مرتب ہوتے ہیں۔ کٹاؤ سے نمٹنے کے لیے مختلف طریقے تجویز کیے گئے ہیں۔ ان طریقوں، جن میں اوزار، تکنیک اور عمل شامل ہیں، کو بنیادی طور پر تین عام زمروں میں درجہ بند کیا گیا ہے جو فن تعمیر کے کٹاؤ کو کم کرنے، روکنے اور مرمت کرنے کی کوشش کرتے ہیں۔ ان وسیع زمروں کے اندر، ہر نقطہ نظر کو مزید تقسیم کیا گیا ہے جو کٹاؤ سے نمٹنے کے لیے اپنائی گئی اعلی سطحی حکمت عملیوں کی عکاسی کرتا ہے۔ یہ عمل پر مبنی فن تعمیر کی مطابقت، فن تعمیر ارتقاء کا انتظام، فن تعمیر کے ڈیزائن کا نفاذ، فن تعمیر سے نفاذ کے ربط، خود موافقت اور فن تعمیر کی بحالی کی تکنیکیں ہیں جن میں بازیابی، دریافت اور مفاہمت شامل ہیں۔ آرکیٹیکچرل خلاف ورزیوں کا پتہ لگانے کے لیے دو بڑی تکنیکیں ہیں: اضطراری ماڈل اور ڈومین مخصوص زبانیں۔ اضطراری ماڈل (آر ایم) تکنیک نظام کے معماروں کے ذریعہ فراہم کردہ اعلی سطحی ماڈل کا ماخذ کوڈ کے نفاذ سے موازنہ کرتی ہیں۔ ڈومین مخصوص زبانیں بھی ہیں جن میں آرکیٹیکچرل رکاوٹوں کی وضاحت اور جانچ پر توجہ دی جاتی ہے۔ سافٹ ویئر فن تعمیر کی بازیابی (یا تعمیر نو، یا ریورس انجینئرنگ) میں دستیاب معلومات سے سافٹ ویئر سسٹم کے فن تعمیر کو بے نقاب کرنے کے طریقے، تکنیک اور عمل شامل ہیں، بشمول اس کے نفاذ اور دستاویزات۔ فن تعمیر کی بازیابی اکثر متروک یا پرانی دستاویزات اور فن تعمیر کے کٹاؤ کے پیش نظر باخبر فیصلے کرنے کے لیے ضروری ہے: نفاذ اور دیکھ بھال کے فیصلے تصور شدہ فن تعمیر سے مختلف ہوتے ہیں۔ جامد پروگرام تجزیہ کے طور پر سافٹ ویئر فن تعمیر کی بازیابی کے لیے طریق کار موجود ہیں۔ یہ سافٹ ویئر انٹیلی جنس پریکٹس کے زیر احاطہ مضامین کا ایک حصہ ہے۔ متعلقہ شعبے ڈیزائن آرکیٹیکچر ڈیزائن ہے لیکن تمام ڈیزائن آرکیٹیکچرل نہیں ہیں۔ عملی طور پر، معمار وہ ہوتا ہے جو سافٹ ویئر فن تعمیر (آرکیٹیکچرل ڈیزائن) اور تفصیلی ڈیزائن (غیر آرکیٹیکچرل ڈیزائن) کے درمیان لکیر کھینچتا ہے۔ ایسے کوئی اصول یا رہنما خطوط نہیں ہیں جو تمام معاملات کے مطابق ہوں، حالانکہ فرق کو باقاعدہ بنانے کی کوششیں کی گئی ہیں۔ انٹینشن/لوکلٹی ہائپوتھیسس کے مطابق، آرکیٹیکچرل اور تفصیلی ڈیزائن کے درمیان فرق کی وضاحت لوکلٹی کرائٹیرین کے ذریعے کی جاتی ہے، جس کے مطابق سافٹ ویئر ڈیزائن کے بارے میں بیان غیر مقامی (آرکیٹیکچرل) ہوتا ہے اگر اور صرف اس صورت میں جب کوئی ایسا پروگرام جو اسے مطمئن کرتا ہے اسے ایک ایسے پروگرام میں بڑھایا جا سکتا ہے جو نہیں کرتا ہے۔ مثال کے طور پر، کلائنٹ سرور سٹائل آرکیٹیکچرل (اسٹریٹجک) ہے کیونکہ اس اصول پر بنایا گیا پروگرام ایک ایسے پروگرام میں بڑھایا جا سکتا ہے جو کلائنٹ سرور نہیں ہے-مثال کے طور پر، پیئر ٹو پیئر نوڈس کو شامل کرکے۔ ضروریات انجینئرنگ ضروریات انجینئرنگ اور سافٹ ویئر فن تعمیر کو تکمیلی نقطہ نظر کے طور پر دیکھا جا سکتا ہے: جب کہ سافٹ ویئر فن تعمیر 'حل کی جگہ' یا 'کیسے' کو نشانہ بناتا ہے، ضروریات انجینئرنگ 'مسئلہ کی جگہ' یا 'کیا' کو حل کرتی ہے۔ ضروریات کی انجینئرنگ میں وضاحت، گفت و شنید، تفصیلات، توثیق، دستاویزات، اور ضروریات کا انتظام شامل ہے۔ انجینئرنگ اور سافٹ ویئر فن تعمیر دونوں ضروریات اسٹیک ہولڈرز کے خدشات، ضروریات اور خواہشات کے گرد گھومتی ہیں۔ ضروریات انجینئرنگ اور سافٹ ویئر فن تعمیر کے درمیان کافی حد تک اوورلیپ ہے، جیسا کہ مثال کے طور پر پانچ صنعتی سافٹ ویئر فن تعمیر کے طریقوں کے مطالعے سے ظاہر ہوتا ہے جو یہ نتیجہ اخذ کرتا ہے کہ "ان پٹ (اہداف، رکاوٹیں، وغیرہ)"۔ وہ عام طور پر غیر متعین ہوتے ہیں، اور صرف اسی وقت دریافت یا بہتر طور پر سمجھ میں آتے ہیں جب فن تعمیر ابھرنا شروع ہوتا ہے "اور یہ کہ اگرچہ" زیادہ تر تعمیراتی خدشات کا اظہار نظام کی ضروریات کے طور پر کیا جاتا ہے، لیکن ان میں لازمی ڈیزائن کے فیصلے بھی شامل ہو سکتے ہیں "۔ مختصرا، مطلوبہ طرز عمل حل کے فن تعمیر کو متاثر کرتا ہے، جو بدلے میں نئی ضروریات کو متعارف کرا سکتا ہے۔ جڑواں چوٹیوں کے ماڈل جیسے طریقوں کا مقصد ضروریات اور فن تعمیر کے درمیان ہم آہنگی کے تعلق کو بروئے کار لانا ہے۔ 'فن تعمیر' کی دیگر اقسام کمپیوٹر فن تعمیر کمپیوٹر سسٹم کے اندرونی ڈھانچے کو نشانہ بناتا ہے، ہارڈ ویئر اجزاء جیسے سی پی یو-یا پروسیسر-بس اور میموری کے تعاون کے لحاظ سے۔ سرور لیس فن تعمیر کلاؤڈ کمپیوٹنگ کا ایک نمونہ ہے جسے اکثر سرور فری ہونے کے طور پر غلط سمجھا جاتا ہے۔ یہ بنیادی طور پر سرور مینجمنٹ کی ذمہ داریوں کو ڈویلپرز سے کلاؤڈ سروس فراہم کرنے والوں میں منتقل کرتا ہے۔ یہ کاروباری اداروں کو کلاؤڈ انفراسٹرکچر پر اپنا بیک اینڈ کوڈ چلانے کی اجازت دیتا ہے، جس سے فزیکل سرور مینجمنٹ کی ضرورت ختم ہو جاتی ہے۔ سرور لیس فن تعمیر کا ایونٹ پر مبنی نقطہ نظر چھوٹے، کام سے متعلق مخصوص افعال پر منحصر ہے جو مطالبہ پر انجام دیے جاتے ہیں۔ ان افعال کو فنکشن ایز اے سروس (ایف اے اے ایس) کے نام سے جانا جاتا ہے، اور وہ درخواست کی طلب کی بنیاد پر پے-ایز-یو-گو بلنگ ماڈل اور متحرک ریسورس اسکیلنگ کے ذریعے لاگت کی کارکردگی پیش کرتے ہیں۔ سسٹم فن تعمیر اصطلاح کا اطلاق اصل میں ان نظاموں کے فن تعمیر پر کیا گیا ہے جو ہارڈ ویئر اور سافٹ ویئر دونوں پر مشتمل ہوتے ہیں۔ اس کے بعد نظام کے فن تعمیر کی طرف سے جس اہم تشویش کو حل کیا جاتا ہے وہ ایک مکمل، صحیح طریقے سے کام کرنے والے آلے میں سافٹ ویئر اور ہارڈ ویئر کا انضمام ہے۔ ایک اور عام معنی میں، یہ اصطلاح کسی بھی پیچیدہ نظام کے فن تعمیر پر لاگو ہوتی ہے جو تکنیکی، سماجی تکنیکی یا سماجی نوعیت کا ہو سکتا ہے۔ انٹرپرائز فن تعمیر انٹرپرائز فن تعمیر کا مقصد "کاروباری وژن اور حکمت عملی کو موثر انٹرپرائز میں تبدیل کرنا" ہے۔ انٹرپرائز آرکیٹیکچر فریم ورک، جیسے کہ ٹوگاف اور زچمین فریم ورک، عام طور پر مختلف انٹرپرائز آرکیٹیکچر تہوں کے درمیان فرق کرتے ہیں۔ اگرچہ اصطلاحات فریم ورک سے فریم ورک میں مختلف ہوتی ہیں، لیکن بہت سے میں کم از کم کاروباری پرت، ایپلی کیشن (یا معلومات) پرت، اور ٹیکنالوجی پرت کے درمیان فرق شامل ہوتا ہے۔ انٹرپرائز فن تعمیر دوسروں کے درمیان ان تہوں کے درمیان صف بندی سے خطاب کرتا ہے، عام طور پر اوپر سے نیچے کے نقطہ نظر میں۔ مزید پڑھنا-یہ کتاب نظم و ضبط کے بنیادی تصورات کا احاطہ کرتی ہے۔ تھیم کسی نظام کی معیاری صفات کے حصول پر مرکوز ہے۔ - یہ کتاب بیان کرتی ہے کہ سافٹ ویئر فن تعمیر کیا ہے اور یہ دکھاتی ہے کہ اسے یو ایم ایل اور دیگر اشاروں کا استعمال کرتے ہوئے متعدد نظاروں میں کیسے دستاویز کیا جائے۔ یہ یہ بھی بتاتا ہے کہ طرز عمل، سافٹ ویئر انٹرفیس، اور عقلی دستاویزات کے ساتھ فن تعمیر کے نظریات کی تکمیل کیسے کی جائے۔ کتاب کے ساتھ ایک ویکی ہے جس میں سافٹ ویئر آرکیٹیکچر دستاویزات کی ایک مثال موجود ہے۔ آرکیٹیکچرل ڈیزائن اور تفصیلی ڈیزائن کے درمیان فرق پر۔ بیرونی روابط آئی بی ایم ڈویلپر ورکس پر وضاحت سافٹ ویئر انجینئرنگ انسٹی ٹیوٹ (ایس ای آئی)، کارنیگی میلن یونیورسٹی (سی ایم یو) انٹرنیشنل ایسوسی ایشن آف آئی ٹی آرکیٹیکٹس (آئی اے ایس اے گلوبل) میں سافٹ ویئر آرکیٹیکچر کی تعریفوں کا مجموعہ، جسے پہلے انٹرنیشنل ایسوسی ایشن فار سافٹ ویئر آرکیٹیکٹس (آئی اے ایس اے) کے نام سے جانا جاتا تھا-سافٹ ویئر آرکیٹیکچر پر آئی ایف آئی پی ورکنگ گروپ 2.10 کی ویب سائٹ SoftwareArchitectures.com-سافٹ ویئر آرکیٹیکچر کے شعبے پر معلومات کا ایک آزاد وسیلہ، رائے فیلڈنگ کے ریسٹ مقالے کا باب 1 جب اچھا فن تعمیر خراب ہوتا ہے تو سرپل آرکیٹیکچر سے چلنے والی ترقی-سرپل ماڈل پر مبنی ایس ڈی ایل سی کا مقصد غیر موثر فن تعمیر سافٹ ویئر آرکیٹیکچر ریئل لائف کیس اسٹڈیز کے خطرات کو کم کرنا ہے۔