arc42 کا فیصلہ ریکارڈ سانچہ

1. تعارف اور اہداف

تقاضوں، محرک قوتوں کی مختصر وضاحت، تقاضوں کا اقتباس (یا خلاصہ)۔ آرکیٹیکچر کے لیے سرِفہرست تین (زیادہ سے زیادہ پانچ) معیاری اہداف جو اہم اسٹیک ہولڈرز کے لیے سب سے زیادہ ترجیح رکھتے ہیں۔ اہم اسٹیک ہولڈرز کی ایک جدول جس میں آرکیٹیکچر سے متعلق ان کی توقعات ہوں۔

1.1 تقاضوں کا جائزہ

مواد

فعلی تقاضوں، محرک قوتوں کی مختصر وضاحت، تقاضوں کا اقتباس (یا خلاصہ)۔ (امید ہے کہ موجود) تقاضوں کی دستاویزات کے لنکس، یہ معلومات کے ساتھ کہ وہ کہاں ملیں گی۔

محرک

حتمی صارفین کے نقطۂ نظر سے سسٹم کسی کاروباری سرگرمی کی بہتر معاونت کرنے اور/یا معیار بہتر بنانے کے لیے بنایا یا بدلا جاتا ہے۔

شکل

مختصر متنی وضاحت، غالباً جدولی استعمال کے کیس کی شکل میں۔ اگر تقاضوں کی دستاویزات موجود ہوں تو اس جائزے کو ان دستاویزات کا حوالہ دینا چاہیے۔

ان اقتباسات کو جتنا ممکن ہو مختصر رکھیں۔ اس دستاویز کی قابلِ مطالعہ ہونے اور تقاضوں کی دستاویزات کے سلسلے میں ممکنہ تکرار کے درمیان توازن رکھیں۔

1.2 معیاری اہداف

مواد

آرکیٹیکچر کے لیے سرِفہرست تین (زیادہ سے زیادہ پانچ) معیاری اہداف جن کی تکمیل اہم اسٹیک ہولڈرز کے لیے سب سے زیادہ اہم ہے۔ ہمارا مطلب واقعی آرکیٹیکچر کے معیاری اہداف ہیں۔ انہیں منصوبے کے اہداف سے گڈ مڈ نہ کریں۔ وہ لازماً ایک جیسے نہیں ہوتے۔ ISO 25010 معیار ممکنہ دلچسپی کے موضوعات کا اچھا جائزہ دیتا ہے۔

محرک

آپ کو اپنے سب سے اہم اسٹیک ہولڈرز کے معیاری اہداف معلوم ہونے چاہئیں، کیونکہ وہ آرکیٹیکچر کے بنیادی فیصلوں پر اثر انداز ہوں گے۔ ان خوبیوں کے بارے میں بہت ٹھوس رہیں، دلکش الفاظ سے بچیں۔ اگر آپ بطور آرکیٹیکٹ نہیں جانتے کہ آپ کے کام کے معیار کو کیسے پرکھا جائے گا …

شکل

ایک جدول جس میں اہم ترین معیاری اہداف اور ٹھوس منظرنامے ہوں، ترجیحات کے لحاظ سے ترتیب دیے گئے۔

1.3 اسٹیک ہولڈر

مواد

سسٹم کے اسٹیک ہولڈرز کا واضح جائزہ، یعنی تمام افراد، کردار یا تنظیمیں جو

آرکیٹیکچر جانیں
جنہیں آرکیٹیکچر پر قائل کرنا ہو
جنہیں آرکیٹیکچر یا کوڈ کے ساتھ کام کرنا ہو
جنہیں اپنے کام کے لیے آرکیٹیکچر کی دستاویزات درکار ہوں
جنہیں سسٹم یا اس کی ڈویلپمنٹ کے بارے میں فیصلے کرنے ہوں

محرک

آپ کو سسٹم کی ڈویلپمنٹ میں شامل یا سسٹم سے متاثر ہونے والے تمام فریقوں کو جاننا چاہیے۔ ورنہ آپ کو ڈویلپمنٹ کے عمل میں بعد میں ناخوشگوار حیرتیں ہو سکتی ہیں۔ یہ اسٹیک ہولڈرز آپ کے کام اور اس کے نتائج کی وسعت اور تفصیل کی سطح طے کرتے ہیں۔

شکل

جدول جس میں کرداروں کے نام، افراد کے نام، اور آرکیٹیکچر اور اس کی دستاویزات کے بارے میں ان کی توقعات ہوں۔

2. پابندیاں

ہر وہ چیز جو ٹیموں کو ڈیزائن اور نفاذ کے فیصلوں یا متعلقہ عمل کے فیصلوں میں محدود کرتی ہے۔ بعض اوقات انفرادی سسٹمز سے آگے بڑھ سکتی ہیں اور پوری تنظیموں اور کمپنیوں کے لیے درست ہوتی ہیں۔

مواد

کوئی بھی تقاضا جو سافٹ ویئر آرکیٹیکٹس کو ڈیزائن اور نفاذ کے فیصلوں یا ڈویلپمنٹ کے عمل کے فیصلے میں ان کی آزادی میں محدود کرتا ہو۔ یہ پابندیاں بعض اوقات انفرادی سسٹمز سے آگے بڑھتی ہیں اور پوری تنظیموں اور کمپنیوں کے لیے درست ہوتی ہیں۔

محرک

آرکیٹیکٹس کو ٹھیک سے معلوم ہونا چاہیے کہ وہ اپنے ڈیزائن کے فیصلوں میں کہاں آزاد ہیں اور کہاں پابندیوں پر عمل کرنا ہوگا۔ پابندیوں سے ہمیشہ نمٹنا ہوتا ہے؛ تاہم وہ قابلِ گفت و شنید ہو سکتی ہیں۔

شکل

وضاحتوں کے ساتھ پابندیوں کی سادہ جدولیں۔ اگر ضرورت ہو تو آپ انہیں تکنیکی پابندیوں، تنظیمی اور سیاسی پابندیوں اور اصولوں (مثلاً پروگرامنگ یا ورژننگ کی ہدایات، دستاویزات یا ناموں کے اصول) میں تقسیم کر سکتے ہیں

3. سیاق و سباق اور دائرہ کار

آپ کے سسٹم کو اس کے (بیرونی) رابطہ شراکت داروں (پڑوسی سسٹمز اور صارفین) سے الگ کرتا ہے۔ بیرونی انٹرفیسز متعین کرتا ہے۔ کاروباری/ڈومین کے نقطۂ نظر سے (ہمیشہ) یا تکنیکی نقطۂ نظر سے (اختیاری) دکھایا جاتا ہے

مواد

سسٹم کا دائرہ کار اور سیاق و سباق - جیسا کہ نام سے ظاہر ہے - آپ کے سسٹم (یعنی آپ کے دائرہ کار) کو اس کے تمام رابطہ شراکت داروں (پڑوسی سسٹمز اور صارفین، یعنی آپ کے سسٹم کا سیاق و سباق) سے الگ کرتا ہے۔ اس طرح یہ بیرونی انٹرفیسز متعین کرتا ہے۔

اگر ضروری ہو تو کاروباری سیاق و سباق (ڈومین کے مخصوص ان پٹ اور آؤٹ پٹ) کو تکنیکی سیاق و سباق (چینلز، پروٹوکولز، ہارڈ ویئر) سے الگ کریں۔

محرک

رابطہ شراکت داروں کے ساتھ ڈومین انٹرفیسز اور تکنیکی انٹرفیسز آپ کے سسٹم کے سب سے نازک پہلوؤں میں سے ہیں۔ یقینی بنائیں کہ آپ انہیں مکمل طور پر سمجھتے ہیں۔

شکل

مختلف سیاق و سباق کے خاکے
رابطہ شراکت داروں اور ان کے انٹرفیسز کی فہرستیں۔

3.1 کاروباری سیاق و سباق

مواد

تمام رابطہ شراکت داروں (صارفین، IT سسٹمز، …) کی تفصیل، ڈومین کے مخصوص ان پٹ اور آؤٹ پٹ یا انٹرفیسز کی وضاحتوں کے ساتھ۔ اختیاری طور پر آپ ڈومین کے مخصوص فارمیٹس یا رابطے کے پروٹوکولز شامل کر سکتے ہیں۔

محرک

تمام اسٹیک ہولڈرز کو سمجھنا چاہیے کہ سسٹم کے ماحول کے ساتھ کون سا ڈیٹا تبادلہ ہوتا ہے۔

شکل

ہر قسم کے خاکے جو سسٹم کو بلیک باکس کے طور پر دکھائیں اور رابطہ شراکت داروں کے ساتھ ڈومین انٹرفیسز متعین کریں۔

متبادل کے طور پر (یا اضافی طور پر) آپ جدول استعمال کر سکتے ہیں۔ جدول کا عنوان آپ کے سسٹم کا نام ہے، تین کالموں میں رابطہ شراکت دار کا نام، ان پٹس اور آؤٹ پٹس ہوتے ہیں۔

3.2 تکنیکی سیاق و سباق

مواد

تکنیکی انٹرفیسز (چینلز اور ترسیل کے ذرائع) جو آپ کے سسٹم کو اس کے ماحول سے جوڑتے ہیں۔ اس کے علاوہ ڈومین کے مخصوص ان پٹ/آؤٹ پٹ کا چینلز پر نقشہ، یعنی وضاحت کہ کون سا I/O کون سا چینل استعمال کرتا ہے۔

محرک

بہت سے اسٹیک ہولڈرز سسٹم اور اس کے سیاق و سباق کے درمیان تکنیکی انٹرفیسز کی بنیاد پر آرکیٹیکچر کے فیصلے کرتے ہیں۔ خاص طور پر انفراسٹرکچر یا ہارڈ ویئر کے ڈیزائنر ان تکنیکی انٹرفیسز کا فیصلہ کرتے ہیں۔

شکل

مثلاً UML ڈپلائمنٹ ڈایاگرام جو پڑوسی سسٹمز تک چینلز بیان کرے، ساتھ نقشے کی جدول جو چینلز اور ان پٹ/آؤٹ پٹ کے درمیان تعلقات دکھائے۔

4. حل کی حکمتِ عملی

بنیادی فیصلوں اور حل کی حکمتِ عملیوں کا خلاصہ جو آرکیٹیکچر کو شکل دیتی ہیں۔ اس میں ٹیکنالوجی، اعلیٰ سطح کی تقسیم، بنیادی معیاری اہداف حاصل کرنے کے طریقے اور متعلقہ تنظیمی فیصلے شامل ہو سکتے ہیں۔

مواد

بنیادی فیصلوں اور حل کی حکمتِ عملیوں کا مختصر خلاصہ اور وضاحت جو سسٹم کے آرکیٹیکچر کو شکل دیتی ہیں۔ ان میں شامل ہیں

ٹیکنالوجی کے فیصلے
سسٹم کی اعلیٰ سطح کی تقسیم کے بارے میں فیصلے، مثلاً کسی آرکیٹیکچر پیٹرن یا ڈیزائن پیٹرن کا استعمال
کلیدی معیاری اہداف حاصل کرنے کے طریقوں کے بارے میں فیصلے
متعلقہ تنظیمی فیصلے، مثلاً ڈویلپمنٹ کے عمل کا انتخاب یا بعض کام تیسرے فریقوں کو سونپنا۔

محرک

یہ فیصلے آپ کے آرکیٹیکچر کے سنگِ بنیاد ہیں۔ یہ بہت سے دیگر تفصیلی فیصلوں یا نفاذ کے اصولوں کی بنیاد ہیں۔

شکل

ان کلیدی فیصلوں کی وضاحت مختصر رکھیں۔

اپنے مسئلے کے بیان، معیاری اہداف اور کلیدی پابندیوں کی بنیاد پر بیان کریں کہ آپ نے کیا فیصلہ کیا اور آپ نے اس طرح کیوں فیصلہ کیا۔ تفصیلات کے لیے اگلے حصوں کا حوالہ دیں (ساختی تفصیلات کے لیے حصہ 5، عمومی تصورات کے لیے حصہ 8)۔

آپ حل کے طریقوں کی فہرست یا جدول استعمال کر سکتے ہیں۔

5. بلڈنگ بلاک منظر

سسٹم کی جامد تقسیم، سورس کوڈ کی تجریدیں، جو تفصیل کی مناسب سطح تک وائٹ باکسز (جن میں بلیک باکسز ہوں) کی درجہ بندی کے طور پر دکھائی جاتی ہیں۔

مواد

بلڈنگ بلاک منظر سسٹم کی بلڈنگ بلاکس (ماڈیولز، اجزا، ذیلی نظام، کلاسز، انٹرفیسز، پیکجز، لائبریریاں، فریم ورکس، پرتیں، پارٹیشنز، ٹائرز، فنکشنز، میکروز، آپریشنز، ڈیٹا اسٹرکچرز، …) میں جامد تقسیم کے ساتھ ان کے انحصارات (تعلقات، وابستگیاں، …) دکھاتا ہے

یہ منظر ہر آرکیٹیکچر کی دستاویز کے لیے لازمی ہے۔ مکان کی مثال لیں تو یہ منزل کا نقشہ ہے۔

محرک

تجرید کے ذریعے اپنے سورس کوڈ کی ساخت کو قابلِ فہم بنا کر اس کا مجموعی جائزہ برقرار رکھیں۔

یہ آپ کو نفاذ کی تفصیلات ظاہر کیے بغیر اپنے اسٹیک ہولڈر سے تجریدی سطح پر بات چیت کرنے دیتا ہے۔

شکل

بلڈنگ بلاک منظر بلیک باکسز اور وائٹ باکسز (نیچے شکل دیکھیں) اور ان کی وضاحتوں کا درجہ بند مجموعہ ہے۔

5.1 وائٹ باکس: مکمل سسٹم

یہاں آپ درج ذیل وائٹ باکس سانچے کا استعمال کرتے ہوئے مکمل سسٹم کی تقسیم بیان کرتے ہیں۔ اس میں ہے

ایک جائزہ خاکہ
تقسیم کا محرک
شامل بلڈنگ بلاکس کی بلیک باکس وضاحتیں۔ ان کے لیے ہم آپ کو متبادل پیش کرتے ہیں:
- تمام شامل بلڈنگ بلاکس اور ان کے انٹرفیسز کے مختصر اور عملی جائزے کے لیے ایک جدول استعمال کریں
- بلڈنگ بلاکس کی بلیک باکس وضاحتوں کی فہرست بلیک باکس سانچے (نیچے دیکھیں) کے مطابق استعمال کریں۔ آپ کے ٹول کے انتخاب پر منحصر یہ فہرست ذیلی ابواب (ٹیکسٹ فائلوں میں)، ذیلی صفحات (وکی میں) یا تہہ دار عناصر (ماڈلنگ ٹول میں) ہو سکتی ہے۔
- (اختیاری:) اہم انٹرفیسز، جن کی وضاحت کسی بلڈنگ بلاک کے بلیک باکس سانچوں میں نہیں کی گئی، لیکن وائٹ باکس سمجھنے کے لیے بہت اہم ہیں۔

چونکہ انٹرفیسز متعین کرنے کے بہت سے طریقے ہیں، ہم ان کے لیے مخصوص سانچہ فراہم نہیں کرتے۔

بہترین صورت میں آپ مثالوں یا سادہ دستخطوں (signatures) سے کام چلا لیں گے۔

5.2 سطح 2

یہاں آپ سطح 1 کے (کچھ) بلڈنگ بلاکس کی اندرونی ساخت وائٹ باکسز کے طور پر متعین کر سکتے ہیں۔

آپ کو فیصلہ کرنا ہے کہ آپ کے سسٹم کے کون سے بلڈنگ بلاکس اتنے اہم ہیں کہ ایسی تفصیلی وضاحت کا جواز بنیں۔ براہِ کرم مکمل ہونے پر مطابقت کو ترجیح دیں۔ اہم، حیران کن، خطرناک، پیچیدہ یا بدلنے والے بلڈنگ بلاکس متعین کریں۔ اپنے سسٹم کے عام، سادہ، اکتا دینے والے یا معیاری حصے چھوڑ دیں

5.2.1 بلڈنگ بلاک 1 کے لیے وائٹ باکس

بلڈنگ بلاک 1 کی اندرونی ساخت متعین کرتا ہے۔

وائٹ باکس سانچہ (اوپر دیکھیں) استعمال کریں۔

6. رن ٹائم منظر

بلڈنگ بلاکس کا رویہ منظرناموں کی صورت میں، جو اہم استعمال کے کیسز یا خصوصیات، نازک بیرونی انٹرفیسز پر تعاملات، آپریشن اور انتظامیہ نیز غلطی اور استثنا کے رویے کا احاطہ کرتے ہیں۔

مواد

رن ٹائم منظر سسٹم کے بلڈنگ بلاکس کے ٹھوس رویے اور تعاملات کو درج ذیل شعبوں کے منظرناموں کی شکل میں بیان کرتا ہے:

اہم استعمال کے کیسز یا خصوصیات: بلڈنگ بلاکس انہیں کیسے انجام دیتے ہیں؟
نازک بیرونی انٹرفیسز پر تعاملات: بلڈنگ بلاکس صارفین اور پڑوسی سسٹمز کے ساتھ کیسے تعاون کرتے ہیں؟
آپریشن اور انتظامیہ: لانچ، اسٹارٹ اپ، اسٹاپ
غلطی اور استثنا کے منظرنامے

تبصرہ: ممکنہ منظرناموں (ترتیبوں، ورک فلو) کے انتخاب کا بنیادی معیار ان کی آرکیٹیکچر کے لحاظ سے مطابقت ہے۔ بہت سے منظرنامے بیان کرنا اہم نہیں۔ آپ کو بلکہ ایک نمائندہ انتخاب دستاویزی کرنا چاہیے۔

محرک

آپ کو سمجھنا چاہیے کہ آپ کے سسٹم کے بلڈنگ بلاکس (کی مثالیں) رن ٹائم پر اپنا کام کیسے کرتے ہیں اور کیسے رابطہ کرتے ہیں۔ آپ زیادہ تر منظرنامے اپنی دستاویزات میں سمیٹیں گے تاکہ اپنا آرکیٹیکچر ان اسٹیک ہولڈرز تک پہنچا سکیں جو جامد ماڈلز (بلڈنگ بلاک منظر، ڈپلائمنٹ منظر) پڑھنے اور سمجھنے پر کم آمادہ یا کم قابل ہیں۔

شکل

منظرنامے بیان کرنے کے لیے بہت سی اصطلاحات (notations) ہیں، مثلاً

مراحل کی نمبر والی فہرست (قدرتی زبان میں)
ایکٹیویٹی ڈایاگرام یا فلو چارٹس
سیکوئنس ڈایاگرام
BPMN یا EPC (ایونٹ پراسس چینز)
اسٹیٹ مشینیں
وغیرہ

6.n رن ٹائم منظرنامہ n (1، 2، 3 وغیرہ)

رن ٹائم ڈایاگرام یا منظرنامے کی متنی وضاحت داخل کریں۔

اس ڈایاگرام میں دکھائی گئی بلڈنگ بلاک مثالوں کے درمیان تعاملات کے قابلِ ذکر پہلوؤں کی وضاحت داخل کریں۔

7. ڈپلائمنٹ منظر

ماحول، کمپیوٹرز، پروسیسرز، ٹوپولوجیز کے ساتھ تکنیکی انفراسٹرکچر۔ (سافٹ ویئر) بلڈنگ بلاکس کا انفراسٹرکچر عناصر سے نقشہ۔

مواد

ڈپلائمنٹ منظر بیان کرتا ہے:

آپ کے سسٹم کو چلانے کے لیے استعمال ہونے والا تکنیکی انفراسٹرکچر، جس میں انفراسٹرکچر کے عناصر جیسے جغرافیائی مقامات، ماحول، کمپیوٹرز، پروسیسرز، چینلز اور نیٹ ٹوپولوجیز نیز دیگر انفراسٹرکچر عناصر ہوں، اور
(سافٹ ویئر) بلڈنگ بلاکس کا ان انفراسٹرکچر عناصر سے نقشہ۔

اکثر سسٹمز مختلف ماحول میں چلتے ہیں، مثلاً ڈویلپمنٹ ماحول، ٹیسٹ ماحول، پروڈکشن ماحول۔ ایسے معاملات میں آپ کو تمام متعلقہ ماحول دستاویزی کرنے چاہئیں۔

ڈپلائمنٹ منظر خاص طور پر تب دستاویزی کریں جب آپ کا سافٹ ویئر ایک سے زیادہ کمپیوٹر، پروسیسر، سرور یا کنٹینر والے تقسیم شدہ سسٹم کے طور پر چلے یا جب آپ اپنے ہارڈ ویئر پروسیسرز اور چپس ڈیزائن اور تعمیر کریں۔

سافٹ ویئر کے نقطۂ نظر سے انفراسٹرکچر کے صرف وہ عناصر سمیٹنا کافی ہے جو آپ کے بلڈنگ بلاکس کی ڈپلائمنٹ دکھانے کے لیے درکار ہیں۔ ہارڈ ویئر آرکیٹیکٹس اس سے آگے جا کر انفراسٹرکچر کو تفصیل کی اس سطح تک بیان کر سکتے ہیں جو انہیں سمیٹنا ہو۔

محرک

سافٹ ویئر ہارڈ ویئر کے بغیر نہیں چلتا۔ یہ بنیادی انفراسٹرکچر آپ کے سسٹم اور/یا کچھ عمومی تصورات کو متاثر کر سکتا ہے اور کرے گا۔ اس لیے آپ کو انفراسٹرکچر جاننا ضروری ہے۔

شکل

شاید اعلیٰ ترین سطح کا ڈپلائمنٹ ڈایاگرام پہلے ہی حصہ 3.2 میں تکنیکی سیاق و سباق کے طور پر شامل ہے جس میں آپ کا اپنا انفراسٹرکچر ایک بلیک باکس ہے۔ اس حصے میں آپ اضافی ڈپلائمنٹ ڈایاگرام کے ذریعے اس بلیک باکس میں زوم کریں گے۔

UML اس منظر کے اظہار کے لیے ڈپلائمنٹ ڈایاگرام پیش کرتا ہے۔ جب آپ کا انفراسٹرکچر زیادہ پیچیدہ ہو تو اسے، غالباً تہہ دار ڈایاگرام کے ساتھ، استعمال کریں۔
جب آپ کے (ہارڈ ویئر) اسٹیک ہولڈرز UML ڈپلائمنٹ ڈایاگرام کی بجائے دوسری قسم کے ڈایاگرام پسند کریں تو انہیں کوئی بھی ایسی قسم استعمال کرنے دیں جو انفراسٹرکچر کے نوڈز اور چینلز دکھا سکے۔

7.1 انفراسٹرکچر سطح 1

بیان کریں (عموماً ڈایاگرام، جدولوں اور متن کے امتزاج میں):

آپ کے سسٹم کی متعدد مقامات، ماحول، کمپیوٹرز، پروسیسرز، .. میں تقسیم اور ان کے درمیان طبعی روابط
اس ڈپلائمنٹ ڈھانچے کا اہم جواز یا محرک
انفراسٹرکچر کی معیار اور/یا کارکردگی کی خصوصیات
سافٹ ویئر آرٹیفیکٹس (بلڈنگ بلاکس) کا انفراسٹرکچر کے عناصر سے نقشہ

متعدد ماحول یا متبادل ڈپلائمنٹس کے لیے براہِ کرم arc42 کا وہ حصہ تمام متعلقہ ماحول کے لیے نقل کریں۔ **

7.2 انفراسٹرکچر سطح 2

یہاں آپ انفراسٹرکچر سطح 1 کے (کچھ) انفراسٹرکچر عناصر کی اندرونی ساخت شامل کر سکتے ہیں۔

براہِ کرم ہر منتخب عنصر کے لیے سطح 1 کی ساخت نقل کریں۔

8. عمومی (Crosscutting) تصورات

مجموعی، بنیادی ضوابط اور حل کے طریقے جو سسٹم کے متعدد حصوں میں (← عمومی) متعلقہ ہیں۔ تصورات اکثر متعدد بلڈنگ بلاکس سے متعلق ہوتے ہیں۔ ڈومین ماڈلز، آرکیٹیکچر پیٹرنز اور انداز، مخصوص ٹیکنالوجی کے استعمال کے اصول اور نفاذ کے اصول جیسے مختلف موضوعات شامل کریں۔

مواد

یہ حصہ عمومی تصورات (مشقیں، پیٹرنز، ضوابط یا حل کے خیالات) بیان کرتا ہے۔ ایسے تصورات اکثر متعدد بلڈنگ بلاکس سے متعلق ہوتے ہیں۔ ان میں بہت سے مختلف موضوعات شامل ہو سکتے ہیں۔

محرک

تصورات آرکیٹیکچر کی تصوراتی سالمیت (ہم آہنگی، یکسانیت) کی بنیاد بناتے ہیں۔ اس طرح وہ آپ کے سسٹم کی اندرونی خوبیاں حاصل کرنے میں اہم کردار ادا کرتے ہیں۔

یہ ٹیمپلیٹ میں وہ جگہ ہے جو ہم نے ایسے تصورات کی مربوط تفصیل کے لیے فراہم کی ہے۔

ان میں سے بہت سے تصورات آپ کے کئی بلڈنگ بلاکس سے متعلق ہیں یا انہیں متاثر کرتے ہیں۔

شکل

شکل مختلف ہو سکتی ہے:

تصوراتی مقالے کسی بھی قسم کی ساخت کے ساتھ
نفاذ کی مثالیں، خاص طور پر تکنیکی تصورات کے لیے
عمومی ماڈل کے اقتباسات یا منظرنامے آرکیٹیکچر کے مناظر کی اصطلاحات استعمال کرتے ہوئے

اس حصے کی ساخت

اپنے سسٹم کے لیے صرف سب سے زیادہ ضروری موضوعات چنیں اور اس حصے میں ہر ایک کو سطح-2 کا عنوان دیں (مثلاً 8.1، 8.2 وغیرہ)۔

مذکورہ ڈایاگرام کے تمام موضوعات کا احاطہ کرنے کی کوشش نہ کریں۔

پس منظر

سسٹمز کے اندر کچھ موضوعات اکثر متعدد بلڈنگ بلاکس، ہارڈ ویئر عناصر یا ڈویلپمنٹ کے عملوں سے متعلق ہوتے ہیں۔ ایسے عمومی موضوعات کو متعلقہ بلڈنگ بلاکس، ہارڈ ویئر عناصر یا ڈویلپمنٹ کے عملوں کی وضاحت میں دہرانے کی بجائے مرکزی جگہ پر بیان یا دستاویزی کرنا آسان ہو سکتا ہے۔

بعض تصورات سسٹم کے تمام عناصر سے متعلق ہو سکتے ہیں، دوسرے صرف چند کے لیے متعلقہ ہو سکتے ہیں۔

9. آرکیٹیکچر کے فیصلے

اہم، مہنگے، نازک، بڑے پیمانے کے یا خطرناک آرکیٹیکچر فیصلے جوازات سمیت۔

مواد

اہم، مہنگے، بڑے پیمانے کے یا خطرناک آرکیٹیکچر فیصلے جوازات سمیت۔ “فیصلوں” سے ہمارا مطلب دیے گئے معیارات کی بنیاد پر ایک متبادل کا انتخاب ہے۔

اپنی صوابدید استعمال کر کے فیصلہ کریں کہ آیا کسی آرکیٹیکچر فیصلے کو یہاں اس مرکزی حصے میں دستاویزی کرنا چاہیے یا اسے مقامی طور پر دستاویزی کرنا بہتر ہے (مثلاً کسی ایک بلڈنگ بلاک کے وائٹ باکس سانچے کے اندر)۔ فاضل متون سے بچیں۔ حصہ 4 کا حوالہ دیں، جہاں آپ نے اپنے آرکیٹیکچر کے سب سے اہم فیصلے پہلے ہی سمیٹ لیے ہیں۔

محرک

آپ کے سسٹم کے اسٹیک ہولڈرز کو آپ کے فیصلوں کو سمجھنے اور ان کا سراغ لگانے کے قابل ہونا چاہیے۔

شکل

ہر اہم فیصلے کے لیے ADR (آرکیٹیکچر فیصلے کا ریکارڈ)
اہمیت اور نتائج کے لحاظ سے ترتیب دی گئی فہرست یا جدول، یا
ہر فیصلے کے لیے الگ حصوں کی شکل میں زیادہ تفصیل سے

پس منظر (ADR کے بارے میں)

دستاویزات کے چھوٹے ٹکڑے پڑھنے، بنانے اور برقرار رکھنے میں آسان ہوتے ہیں۔ جب بات آرکیٹیکچر کے فیصلوں کی ہو تو ڈویلپمنٹ ٹیمیں اکثر:

فیصلے کو جانتی ہیں، کیونکہ وہ مثلاً سورس کوڈ میں نظر آتا ہے، لیکن
اس فیصلے کے پیچھے محرک سے ناواقف ہوتی ہیں (دیکھیں Nygard 2011)

اس لیے آپ کو کچھ اہم فیصلے ان کے محرک اور استدلال کے ساتھ دستاویزی کرنے چاہئیں

فیصلوں کے بارے میں ہماری تجویز

آرکیٹیکچر کے لحاظ سے اہم فیصلوں کا مجموعہ رکھیں، یعنی وہ فیصلے جو ساخت، معیار کی خصوصیات، اہم (خاص طور پر بیرونی) انحصارات اور انٹرفیسز، یا تعمیر کی تکنیکوں کو متاثر کرتے ہیں (اس تجویز کے لیے Michael Nygard کا شکریہ)۔

10. معیاری تقاضے

معیاری تقاضے منظرناموں کی صورت میں، اعلیٰ سطح کا جائزہ دینے کے لیے معیار کے درخت کے ساتھ۔ سب سے اہم معیاری اہداف حصہ 1.2 (معیاری اہداف) میں بیان ہو چکے ہوں گے۔

مواد

اس حصے میں تمام متعلقہ معیاری تقاضے ہیں۔

ان تقاضوں میں سب سے اہم پہلے ہی حصہ 1.2 (معیاری اہداف) میں بیان کیے جا چکے ہیں، اس لیے یہاں صرف ان کا حوالہ دینا چاہیے۔ اس حصہ 10 میں آپ کو کم اہمیت کے معیاری تقاضے بھی سمیٹنے چاہئیں، جو مکمل طور پر حاصل نہ ہونے پر بڑے خطرات پیدا نہیں کریں گے (لیکن ہو جائیں تو اچھا ہو)۔

محرک

چونکہ معیاری تقاضوں کا آرکیٹیکچر کے فیصلوں پر بہت اثر ہوگا، آپ کو معلوم ہونا چاہیے کہ آپ کے اسٹیک ہولڈرز کے لیے کون سی خوبیاں واقعی اہم ہیں، مخصوص اور قابلِ پیمائش انداز میں۔

مزید معلومات

https://quality.arc42.org پر وسیع Q42 معیاری ماڈل دیکھیں۔

10.1 معیاری تقاضوں کا جائزہ

مواد

معیاری تقاضوں کا جائزہ یا خلاصہ۔

محرک

اکثر ہمارا سامنا درجنوں (یا سینکڑوں) تفصیلی معیاری تقاضوں سے ہوتا ہے۔ اس جائزے کے حصے میں آپ کو خلاصہ کرنے کی کوشش کرنی چاہیے، مثلاً زمروں یا موضوعات کی وضاحت کر کے (جیسا کہ ISO 25010:2023 یا Q42 تجویز کرتے ہیں

اگر یہ خلاصہ وضاحتیں پہلے ہی کافی درست، مخصوص اور قابلِ پیمائش ہیں تو آپ حصہ 10.2 چھوڑ سکتے ہیں۔

شکل

سادہ جدول استعمال کریں جس کی ہر لائن میں ایک زمرہ یا موضوع اور معیاری تقاضے کی مختصر وضاحت ہو۔ متبادل کے طور پر آپ ان معیاری تقاضوں کو ترتیب دینے کے لیے مائنڈ میپ استعمال کر سکتے ہیں۔

ادب میں معیار کی خصوصیات کے درخت کا خیال بھی بیان کیا گیا ہے، جو عمومی اصطلاح “معیار” کو جڑ بناتا ہے اور اصطلاح “معیار” کی درخت جیسی تفصیل استعمال کرتا ہے۔ [Bass+21] نے اس مقصد کے لیے “Quality Attribute Utility Tree” کی اصطلاح متعارف کرائی۔

10.2 معیار کے منظرنامے

مواد

معیار کے منظرنامے معیاری تقاضوں کو ٹھوس بناتے ہیں اور فیصلہ کرنے دیتے ہیں کہ آیا وہ پورے ہو گئے (قبولیت کے معیارات کے معنی میں)۔ یقینی بنائیں کہ آپ کے منظرنامے مخصوص اور قابلِ پیمائش ہیں۔

دو قسم کے منظرنامے خاص طور پر مفید ہیں:

استعمال کے منظرنامے (جنہیں ایپلیکیشن منظرنامے یا استعمال کے کیس منظرنامے بھی کہتے ہیں) کسی خاص محرک پر سسٹم کے رن ٹائم ردعمل کو بیان کرتے ہیں۔ اس میں وہ منظرنامے بھی شامل ہیں جو سسٹم کی کارگزاری یا کارکردگی کو بیان کرتے ہیں۔ مثال: سسٹم صارف کی درخواست پر ایک سیکنڈ کے اندر ردعمل دیتا ہے۔
تبدیلی کے منظرنامے سسٹم یا اس کے فوری ماحول میں ترمیم یا توسیع کے مطلوبہ اثر کو بیان کرتے ہیں۔ مثال: اضافی فعالیت نافذ کی جاتی ہے یا کسی معیاری اٹریبیوٹ کے تقاضے بدل جاتے ہیں، اور تبدیلی کی کوشش یا دورانیہ ناپا جاتا ہے۔

شکل

تفصیلی منظرناموں کی عام معلومات میں درج ذیل شامل ہیں:

مختصر شکل میں (Q42 ماڈل میں پسندیدہ):

سیاق و سباق/پس منظر: کس قسم کا سسٹم یا جز، ماحول یا صورتحال کیا ہے؟
ماخذ/محرک: کون یا کیا کسی رویے، ردعمل یا عمل کو شروع یا متحرک کرتا ہے۔
میٹرک/قبولیت کا معیار: پیمائش یا میٹرک سمیت ردعمل

منظرناموں کی طویل شکل (SEI اور [Bass+21] کی پسندیدہ) زیادہ تفصیلی ہے اور درج ذیل معلومات شامل کرتی ہے:

منظرنامے کی شناخت: منظرنامے کا منفرد شناخت کنندہ۔
منظرنامے کا نام: منظرنامے کا مختصر، وضاحتی نام۔
ماخذ: وہ ہستی (صارف، سسٹم یا واقعہ) جو منظرنامہ شروع کرتی ہے۔
محرک: وہ متحرک کرنے والا واقعہ یا شرط جس سے سسٹم کو نمٹنا ہے۔
ماحول: وہ عملی سیاق و سباق یا شرط جس کے تحت سسٹم محرک کا سامنا کرتا ہے۔
آرٹیفیکٹ: بلڈنگ بلاکس یا سسٹم کے دیگر عناصر جو محرک سے متاثر ہوتے ہیں۔
ردعمل: وہ نتیجہ یا رویہ جو سسٹم محرک کے جواب میں ظاہر کرتا ہے۔
ردعمل کی پیمائش: وہ معیارات یا میٹرک جن سے سسٹم کے ردعمل کا جائزہ لیا جاتا ہے۔

مزید دیکھیں

جنوری 2023 سے arc42 ایک عملی معیاری ماڈل فراہم کرتا ہے، جو معیاری تقاضوں پر #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable جیسے ہیش ٹیگز یا لیبل لگانے کی تجویز دیتا ہے۔

11. خطرات اور تکنیکی قرض

معلوم تکنیکی خطرات یا تکنیکی قرض۔ سسٹم کے اندر یا اس کے ارد گرد کون سے ممکنہ مسائل ہیں؟ ڈویلپمنٹ ٹیم کو کس بات سے بے چینی ہے؟

مواد

شناخت شدہ تکنیکی خطرات یا تکنیکی قرضوں کی فہرست، ترجیح کے لحاظ سے ترتیب دی گئی

محرک

“خطرات کا انتظام بالغوں کے لیے منصوبے کا انتظام ہے” (Tim Lister, Atlantic Systems Guild.)

یہ آپ کا اصول ہونا چاہیے آرکیٹیکچر میں خطرات اور تکنیکی قرضوں کی منظم شناخت اور جائزے کے لیے، جو انتظامی اسٹیک ہولڈرز (مثلاً پراجیکٹ مینیجرز، پروڈکٹ مالکان) کو مجموعی خطرات کے تجزیے اور پیمائش کی منصوبہ بندی کے حصے کے طور پر درکار ہوگا۔

شکل

خطرات اور/یا تکنیکی قرضوں کی فہرست، غالباً خطرات کو کم سے کم کرنے، ان کی شدت گھٹانے یا ان سے بچنے، یا تکنیکی قرض کم کرنے کے تجویز کردہ اقدامات سمیت۔