ویرگول
ورودثبت نام
Fatemeh Rafiee
Fatemeh Rafiee
Fatemeh Rafiee
Fatemeh Rafiee
خواندن ۸ دقیقه·۹ ماه پیش

مستندسازی معماری نرم‌افزار

در این جا به صورت خلاصه بررسی می کنیم که سند معماری نرم افزار (SAD) چه اهمیتی داره و چه موضوعاتی رو باید پوشش بده.

در مهندسی نرم افزار غالبا وقتی صحبت از متدولوژی های چابک میشه، بحث نوشتن داکیومنت ها به آخرین اولویت تنزل پیدا می کنه. در حالی که متدولوژی های Agile این موضوع رو بیان نمیکنن که اسناد لازم نیستن، بلکه میگن باید روی اسناد مهم و کاربردی وقت گذاشته بشه، اون هم نه به این صورت که در ابتدای راه توسعه زمان زیادی رو صرف نوشتن اسناد کنیم و از کار اصلی، یعنی توسعه جا بمونیم. (مثل RUP که فاز بندی های نسبتا مجزایی داشت)

سند معماری نرم افزار هم برخلاف بعضی از اسناد مربوط به طراحی و تحلیل یکی از اسناد مهم و کابردیه که عدم حضورش به پیشرفت کار به شکل جدی ضربه وارد میکنه چرا که به تعداد زیادی از ذینفعان و طیف گستردهای مربوط میشه. ولی اگر اصولی نوشته نشه، بود و نبودش عملا فرق زیادی نداره. یه نکته مهم در اسناد معماری، اینه که سند باید در کل فرایند توسعه، به روز باشه چون در غیر این صورت قابل استفاده نیست. از طرفی هم باید abstract و سطح بالا باشه و جزئیات در اون وارد نشه چرا که جزء اسناد بالا دستی محسوب میشه.

نبود این سند (یا اصولی نبودنش) باعث میشه دانش ضمنی ای که در افراد تیم وجود داره، به مرور زمان از بین بره. به این مفهوم که به این ترتیب، معماری یک سامانه ممکنه به یک گروه خاصی وابستگی پیدا کنه و وقتی افراد جدید وارد سازمان میشن به اون گروه برای فهم سیستم نیاز دارن و اگر اون ها هم سازمان رو ترک کرده باشن، عملا باید reverse engineering انجام بگیره تا دلیل تصمیمات معماری مشخص بشه و یا دوباره از ابتدا طراحی انجام بشه. یا حتی ممکنه خود افراد اصلی که این تصمیم رو گرفتن هم بعد از مدتی نسبت به علت تصمیمات معماری که در گذشته اتخاذ کردن دچار فراموشی بشن.

همچنین سند معماری به عنوان یک رابط بین stake holder های فنی و غیرفنی عمل میکنه و هر یک از این ذینفعان از یک بخش معماری بهره میبرن و در صورتی که این سند آپدیت باشه، افراد میتونن در صورت نیاز بهش رجوع کنن و تعاملات تیم ها با همدیگه آسون تر میشه، چون این سند در واقع مبنای توسعه قرار می گیره.

لازم به ذکره که SAD عمدتا باید توسط افراد ارشد تیم، مثل معمار یا tech lead تنظیم بشه و صرفا در بخش های جزئی تر میشه از توسعه دهنده ها هم کمک گرفت.

برای اینکه بتونیم راهکارهای معماری و تصمیماتی که اتخاذ میشه رو بررسی و توجیه کنیم (فضای راه حل)، ابتدا نیازه که نیازمندی ها (فضای مسئله) رو درست درک کرده باشیم چرا که معماری باید مناسب یک سیستم باشه. این نیازمندی ها هم میتونن functional باشن و هم non functional.

نکته در خصوص ابزار پیاده سازی: از word و PDF و ابزارهای عام منظوره بهتره استفاده نشه و به جاش از confluence که یکی از سامانه های ویکی هست استفاده بشه.

مدل های مختلفی برای نوشتن سند معماری نرم افزار وجود داره که یکی از ابتدایی ترین اون ها مدل 4 + 1 هست. که پنج نمای مختلف رو شامل میشه. یکی از این 5 نما، نمای use case هست که در بخش فضای مسئله وجود داره. فضای حل مسئله همچنین دو بخش دیگه هم داره: مقدمه و Quality Attribute ها. در بخش مقدمه که عموما کوتاه هست، اسکوپ کار و تعاریف و واژه ها و استانداردها و constraint ها آورده میشه.

در بخش use case view هم معمولا functional requirement ها توصیف میشن، البته این کار برای تمام use case ها انجام نمیشه، چرا که در این صورت، سند معماری بسیار حجیم خواهد شد. بهتر هست که صرفا برای موارد کاربری کلان این کار انجام بشه. توجه داریم که وقتی use case کشیده میشه، باید به notation ها هم پایبند باشیم ولی برای شروع میشه اون ها رو به طور موقت نادیده گرفت. بعد از تعیین actor ها و روابط بین اون ها، به هر یوزکیس یک شناسه و عنوان هم اختصاص داده میشه و در نهایت، هر یوزکیس به یک actor نسبت داده میشه (assign میشه) و برای هر یک هم توصیفی در حد چند جمله داریم.

برای این که سند SAD بیش از حد طولانی نشه، به توصیف تک تک موارد کاربری نمی پردازیم و به جای اون، یکی از کاربردها رو توضیح می-دیم یا یوزکیس ها رو گروه بندی می کنیم و هر گروه رو بررسی می کنیم.

در ادامه ی فضای حل مسئله، باید ویژگی های کیفی سیستم هم بیان بشن. در حقیقت آوردن اسم QA کافی نیست، و باید معیار سنجش و همچنین بازه مطلوبش برای سیستم ما هم ذکر بشه. مثلا میانگین response time سامانه باید زیر 2 ثانیه باشه (جزو performance)

فضای راه حل از 12 فصل تشکیل شده. البته تکمیل کردن این فصل ها به صورت چرخشی و تکاملی انجام میشه و نه به یکباره.

1. نمای منطقی: شامل بلوک های اصلی سازنده سیستم و نحوه ارتباط بین اجزا و همچنین لایه ها.

2. نمای استقرار: نمای فیزیکی سیستم، و شامل سرورها و کانتینرها و VMهاست. یکی از بخش های اصلیش هم جدول استقرار هست که البته اگر سامانه ای هنوز در نیمه های راه باشه، ممکنه جدول استقرارش نیمه تکمیل باشه.

3. نمای process: شامل executable های محیط عملیاتی و mapping اون ها با سرورهاست. البته در یک جدول دیگر، ارتباط بین process ها هم بیان میشه. (پردازه مبدا و مقصد و پروتکل ها و …)

توجه داریم که منظور از process در اینجا، processهای سیستم هست و نه فرایندهای بیزینسی سازمان.

4. نمای پیاده سازی: شامل ماژول های اصلی که توسعه داده میشن، و ساختار پروژه ها و زیرپروژه ها و تصمیمات مربوط به توسعه و پیاده سازی.

5. نمای تست: شامل تصمیمات کلان در زمینه تست (به ویژه اون هایی که روی معماری تاثیرگذارن) و همچنین تکنولوژی و رویکردهایی که برای تست به کار گرفته می¬شه.

6. نمای log: شامل سطوح لاگ، ساختار و فرمت ثبت لاگ، سیستم های مدیریت لاگ، و KPIهایی که بدست میاد.

7. نمای monitoring: شامل منابع (حافظه و CPU) و ابزارها (مثل پروموتئوس) و سناریوهای پایش هست.

8. نمای داده: شامل تصمیمات مهم در زمینه دیتابیس ها و الگوریتم های به کارگرفته شده در لایه داده و دلیل استفاده از اون ها (مثل Cache, CQRS) و همچنین مدیریت متادیتا و بازیابی دیتا. تصمیمات مربوط به data integration و data migration هم در این بخش قرار می گیره.

9. بخش Use case realization: برای حداکثر سه use case کلان و پرکاربرد، نشون میده مولفه ها چطور با هم تعامل دارن و روند اجرای کارها به چه ترتیبی ست. البته با نماهای process و منطقی هم ارتباط داره.

10. تکنولوژی ها و ابزارها: به طور خلاصه هر تکنولوژی رو به همراه ورژن و جایگاه استفاده اش لیست می کنه.

11. تصمیمات معماری: این فصل باید برای زمانی که کسی نیاز داشته باشه در زمان کوتاهی متوجه روند تغییرات در سیستم بشه، مناسب باشه و شامل تصمیم ها و دلایل انتخابشون و جایگزین های موجود باشه. این کار هم برای افرادی که جدید به تیم اضافه میشن مفیده و هم برای زمانی که خود شخص تصمیم گیر، فراموش کرده در گذشته چرا یک گزینه خاص رو انتخاب کرده. (به خصوص وقتی که یک تصمیم بدیهی نبوده باشه)

12. بخش Technical debts: در این قسمت به صورت خلاصه، هر یک از ریسک ها و بدهی های فنی رو (به صورت جدا) لیست می کنیم و تاثیرش رو در صورت رخ دادن بررسی می کنیم و همچنین اولویت رسیدگی به اون رو هم مشخص می کنیم. این تصمیمات عمدتا بخاطر وقت، دانش، یا تجربه کم گرفته می شن.

13. نمای Reporting: این قسمت شامل هر نوع ابزار و تکنیک و الگویی میشه که برای گزارش های تحلیلی لازم هست و همچنین mapping این گزارش ها با افراد و نقش ها.

نکته:

- گاهی اوقات بعضی نماها شبیه هم میشن و تفکیکشون سخت می شه (به خصوص در معماری میکروسرویس)

- بین نمودارهای UML و نماها در معماری هیچ نگاشتی وجود ندارد و بسته به نیاز و کمک به فهم سیستم، تصمیم گرفته میشه که در کدوم نما، کدوم نمودار قرار بگیره. (نمودار خاصی برای هر فصل وجود نداره)

- مشخص کردن معماری To-Be علاوه بر معماری As-Is این فرصت رو میده که gap ها رو شناسایی کنیم و سیستم رو راحت تر بهبود بدیم.

- لایه منطقی و پیاده سازی در برخی پروژه ها به خاطر نزدیکی زیاد به هم، ممکنه ادغام بشن.

یکی از شیوه های مستندسازی معماری، مدل C4 است که از 4 بخش system context, containers, components, code تشکیل شده، که به صورت سلسله مراتبی قرار می گیرن. این مدل عموما با ساخت دیاگرام، یک overview از کل پروژه نشون میده. برای کشیدن این نمودار معمولا، سه سطح اول کفایت می کنه و بهتره وارد سطح code نشیم چون اکثر اوقات فقط باعث overhead می شه. برای شروع هم کافی هست که با باکس های ساده آغاز کنیم که شامل اسم موجودیت و نوعش هست. استفاده از notation ها و رنگ ها صرفا باید به عنوان یک مکمل، به درک بهتر نمودارها کمک کنه و اگر با حذف اون ها، درک افراد دچار مشکل می شه، باید در انتخاب اسامی و توضیحات تجدید نظر کنیم.

هر کدوم از بخش های مدل C4 یک سطح از انتزاع رو توصیف می کنن. ویوی Context یک بررسی اجمالی سطح بالا از سیستم و تعاملاتش با موجودیت های خارجی ارائه میده. نمای Container کمی زوم می کنه تا بتونه بلوک های سازنده اصلی مثل اپلیکیشن ها و دیتابیس ها رو نمایش بده. نمای Component وارد هر یک از کانتینرها میشه و اون ها رو به بخش های جزئی و کوچکتر تقسیم می کنه و روابط و مسئولیت های هریک رو بررسی می کنه. در نمای Code هم پیاده سازی جزئیات، کلاس ها و متدها یافت میشه.

نرم افزارمعماریمعماری نرم افزار بهشتیمعماری نرم افزار
۵
۱
Fatemeh Rafiee
Fatemeh Rafiee
شاید از این پست‌ها خوشتان بیاید