سند معماری نرمافزار (Software Architecture Document) مجموعهای از تصمیمات کلان معماری یک نرمافزار است. هرچند در روشهای توسعه چابک ممکن است این سند به صورت مفصل نوشته نشود، اما وجود آن حتی در این متدولوژیها هم میتواند نقش مهم و مفیدی در موفقیت پروژه داشته باشد.
سند معماری نرمافزار نقشی کلیدی و بالادستی در توسعه دارد و به عنوان پل ارتباطی میان تیم فنی مثل مدیر فنی و توسعهدهندگان و همچنین ذینفعان غیر فنی مانند کارفرما یا مدیر بازرگانی عمل میکند. این تعامل و گفتگو بین گروههای مختلف را آسان میکند و برای هر گروه نمایی مناسب ارائه میدهد.
اگر این سند در طول پروژه بهروز نگه داشته شود، افراد مختلف میتوانند به آن مراجعه کنند و تعاملات پروژه به شکل قابل توجهی سادهتر و منسجمتر خواهد شد. علاوه بر این، سند معماری مبنای کاری تیم توسعه است و ورود اعضای جدید را راحتتر میکند، چون دانش معماری فقط در اختیار چند نفر محدود نخواهد بود. همینطور ارزیابی و بازبینی معماری با وجود این سند آسانتر میشود.
حتی در متدولوژیهای چابک نیز مستندسازی این سند اهمیت دارد. چون اصول چابک به مستندسازی کمحجم، مفید و تعامل محور تاکید دارد، سند معماری که به روش چابک تهیه و بهروزرسانی شود، مانع پیشرفت نخواهد بود و به همکاری اعضا کمک میکند.
سند معماری برای همه پروژهها قابل استفاده است اما بسته به اندازه و پیچیدگی پروژه، همه نماها ضرورت ندارند و قالب سند باید استاندارد و مختصر باشد تا به سندی حجیم تبدیل نشود. معمولا بهتر است تهیه آن بر عهده افراد ارشد مثل معمار نرمافزار باشد.
برای نگهداری سند معماری، استفاده از سامانههای ویکی مثل Confluence مناسبتر است، چرا که این ابزارها بهتر از نرمافزارهای متنی مانند Word میتوانند دانش و مستندات پروژه را مدیریت کنند.
یکی از مدلهای رایج و پایه برای نوشتن سند معماری، مدل 4+1 است که نماهای منطقی، فیزیکی، توسعه، پردازه و نمای سناریو (use case) را در بر میگیرد. در بخش فضای مسئله، مقدمه، نمای موارد کاربرد و ویژگیهای کیفی بررسی میشوند و در بخش فضای راهحل، نماهای منطقی، فیزیکی، پردازه، توسعه و نماهای دیگر توضیح داده میشوند.
فضای مسئله خود شامل سه فصل است. در فصل اول به توصیف کلی سامانه، محدوده نرمافزار، واژهنامه، اهداف کلان معماری، محدودیتها، استانداردها و مراجع پرداخته میشود. فصل دوم مربوط به نمای موارد کاربرد کلیدی است که نیازمندیهای کارکردی موثر بر معماری را شرح میدهد؛ بهتر است ابتدا کنشگران (اکتورهای انسانی یا غیرانسانی) شناسایی و برای هر مورد کاربرد شناسه، عنوان و شرح مشخص شود. در فصل سوم ویژگیهای کیفی سیستم بررسی میشود، یعنی کیفیت عملکرد سیستم با ذکر معیارهای سنجش و مقدار مطلوب. گاهی نیز سناریوهایی برای شرایط خاص ارائه میشود که ویژگیهای کیفی ممکن است تغییر کنند.
بخش فضای راهحل، فصلهای متعددی دارد؛ در نمای منطقی، اجزای اصلی معماری مثل کامپوننتها، زیرسیستمها و سرویسها با تمرکز بر ساختار کلی و مستقل از محیط اجرا شرح داده میشوند. نمای فیزیکی یا استقرار، به توصیف محیط اجرایی، سختافزارها، جدول یا نمودار استقرار سرورها و فرایندهای نصب میپردازد. نمای پردازه به فرآیندها و برنامههای اجرایی زمان اجرا، ارتباط و نگاشت آنها به سرورها، و ویژگیهای ارتباطی توجه میکند. نمای پیادهسازی نیز تصمیمات کلان پیادهسازی مانند ساختار ماژولها و لایهها را توضیح میدهد.
مدل 4+1 معمولاً کفایت نمیکند، گاهی نماها به هم شباهت دارند یا لازم است از چند جنبه مختلف توصیف شوند و حتی نماهای ترکیبی ایجاد شوند تا معماری کاملتر پوشش داده شود.
در کنار این، فصلهای اختیاری و تکمیلی نیز بهتر است در سند آورده شوند، مانند شرح اجرای موارد کاربرد مهم (use case realization)، که نحوه عملکرد کامپوننتها در اجرای سناریوهای کلیدی را توضیح میدهد، نمای تست که ساختار و تصمیمات مرتبط با تست نرمافزار را بیان میکند، نمای لاگ برای تشریح لاگهای نرمافزار، نمای مانیتورینگ برای پایش سیستم، نمای داده که معماری دادهها و مدیریت آنها را توضیح میدهد، و همچنین خلاصهای از الگوها و تکنیکهای معماری، ابزارها و فناوریهای استفاده شده، تصمیمات مهم معماری و در نهایت ریسکها و بدهیهای فنی.
در بخشهای دیگر هم میتوان نماهای متقاطع، گزارشگیری و پیشنهادهای بهبود آینده را اضافه کرد تا سند معماری کاملتر و کاربردیتر شود.
در نهایت، توصیه میشود سند معماری به صورت یکجا و ترتیبی نوشته نشود بلکه به شکل تدریجی و همراه با تکامل پروژه بهروزرسانی شود. به عنوان مثال نمای استقرار ممکن است پس از شروع بهرهبرداری نرمافزار تکمیل شود.
روش C4 یکی از مدلهای جدید و کاربردی برای مستندسازی معماری نرمافزار است که محبوبیت زیادی پیدا کرده است. این روش برخلاف مدل 4+1 که نماهای مختلفی دارد، تلاش میکند معماری را در چهار سطح یا نمای ساده و متوالی نمایش دهد.
این چهار نمای C4 عبارتاند از: نمای Context (System Context)، نمای Container، نمای Component و نمای Code. در نمای Context، معماری کلی سیستم و ارتباط آن با کاربران، سیستمهای خارجی و محیط پیرامون نشان داده میشود. این نما کمک میکند تا محدوده سیستم و نقش آن در کل کسبوکار به خوبی فهمیده شود.
در نمای Container، ساختار اصلی سیستم به اجزای بزرگتر تقسیم میشود که هر کدام میتوانند برنامههای جداگانه، سرویسها یا پایگاههای داده باشند. نمای Component جزئیات بیشتری را درون هر مولفه نشان میدهد، یعنی اجزای داخلی هر قسمت و چگونگی همکاری آنها برای ارائه عملکردهای سیستم. این مرحله بیشتر برای تیمهای توسعه مفید است تا ساختار داخلی سیستم را بهتر درک کنند. در نهایت نمای Code به سطح پایینتر و دقیقتر میرود و معمولاً برای توصیف کدهای مهم، کلاسها یا ماژولهای کلیدی به کار میرود. این نما به صورت دقیقتر روی پیادهسازی تمرکز دارد. توصیه می شود تا وقتی نیازی به این نما وجود نداشت این نما تولید نشود.
یکی از مزایای روش C4، سادگی در ارائه معماری در سطوح مختلف است که باعث میشود مخاطبان با تخصصهای متفاوت بتوانند راحتتر معماری را درک کنند؛ از مدیران و ذینفعان غیر فنی گرفته تا تیمهای توسعهدهنده. همچنین این روش قابل توسعه و انعطافپذیر است و میتواند به راحتی با نیازهای پروژههای مختلف سازگار شود.
منابع:
https://www.aparat.com/v/g85r76k
https://www.aparat.com/v/i0891w4
