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

امیررضا وفائی

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

اهمیت سند:

۱- مرجع تصمیمات فنی
وقتی در پروژه‌ای تصمیم گرفته می‌شود از پایگاه‌داده NoSQL استفاده شود یا سیستم به صورت سرویس‌گرا طراحی شود، لازم است این تصمیم‌ها جایی نوشته شوند. سند معماری کمک می‌کند تا بعدا تیم توسعه بداند چرا چنین تصمیمی گرفته شده و چه معیارهایی در نظر گرفته شده‌اند.

۲- ارتباط بهتر بین تیم‌ها
معماری نرم‌افزار یک زبان مشترک بین تحلیل‌گران، برنامه‌نویسان، مدیر پروژه و حتی ذی‌نفعان تجاری است. سند باعث می‌شود همه درباره‌ ساختار سیستم تصویر یکسانی داشته باشند و از سردرگمی جلوگیری می‌شود.

۳- نگهداری ساده‌تر سیستم
یک سیستم نرم‌افزاری معمولا سال‌ها کار می‌کند. با تغییر اعضای تیم، اگر مستندات دقیقی وجود نداشته باشد، درک ساختار سیستم بسیار دشوار می‌شود. سند معماری باعث می‌شود در آینده توسعه‌دهندگان جدید بتوانند راحت‌تر وارد پروژه شوند.

۴- ارزیابی کیفیت
می‌توان بررسی کرد که آیا سیستم پاسخگوی نیازهای غیر‌عملکردی مثل امنیت، پایداری، و قابلیت استفاده هست یا نیست. به عنوان مثال می‌توان فهمید که آیا طراحی انجام‌شده توانایی مقیاس‌پذیری در آینده را دارد یا ندارد.

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

ممکن است بسته به نوع پروژه یا سازمان این ساختار کمی تغییر کند، ولی اغلب شامل بخش‌های زیر است:

۱- مقدمه

کلیات پروژه بیان می‌شود، اینکه سیستم چه هدفی دارد، چه کسانی مخاطب این سند هستند و خلاصه‌ای از ساختار بیان می‌شود.

۲- نمای کلی سیستم

تصویری ابتدایی ولی کلیدی از ساختار اصلی سیستم نرم‌افزاری است. در این بخش، هدف این است که مخاطب حتی اگر خیلی با جزئیات فنی آشنا نباشد، متوجه شود سیستم قرار است چه اجزایی داشته باشد و این اجزا چگونه با هم تعامل دارند.

هدف این بخش:

· درک سریع و شهودی از معماری سیستم

· شناسایی اجزای اصلی و ارتباط‌های بین آن‌ها

· ایجاد یک چارچوب ذهنی برای مطالعه بقیه بخش‌های سند معماری

در این قسمت معمولا موارد زیر پوشش داده می‌شوند:

۱. اجزای اصلی سیستم (Main Components):

· سیستم از چه اجزایی یا ماژول‌هایی تشکیل شده به عنوان مثال رابط کاربری، سرویس‌های سمت سرور، پایگاه‌داده، سیستم احراز هویت، APIها و ماژول گزارش‌گیری که نشان دهیم هر جز چه مسئولیتی دارد.

۲. نحوه تعامل اجزا (Interactions):

· اجزا چطور با هم ارتباط برقرار می‌کنند به عنوان مثال از طریق HTTP، REST API، پیام‌بر (Message Queue)، اتصال مستقیم به دیتابیس که ارتباط‌ها ممکن است یک‌طرفه یا دوطرفه، هم‌زمان (synchronous) یا غیرهم‌زمان (asynchronous) باشند.

۳. مرز سیستم (System Boundary):

· چه اجزایی داخل سیستم ما هستند و چه اجزایی بیرونی هستند به عنوان مثال کاربر، سیستم بانکی خارجی، سرویس ارسال پیامک، API گوگل.

۴. دیاگرام‌های نمای کلی (High-Level Diagrams):

معمولا دو نوع دیاگرام برای نمایش این دید استفاده می‌شود

نمودار محتوا (context diagram) که ساده‌ترین نوع دیاگرام است و در مرکز سیستم ما قرار دارد و با خطوط مشخص شده که با چه سیستم‌ها یا کاربران خارجی در تعامل است. این نمودار مشخص می‌کند که اطلاعات از کجا وارد سیستم می‌شود و به کجا می‌رود.

نمودار کامپوننت که اجزای داخلی سیستم را به صورت جعبه (بلوک) نشان می‌دهد. خطوط بین بلوک‌ها مشخص می‌کند که کدام جز به کدام جز دیگر دسترسی یا وابستگی دارد.

۳- دید‌های معماری

معماری سیستم از جنبه‌های مختلفی توصیف می‌شود. این دید‌ها شامل:

• دید منطقی (Logical View): ساختار نرم‌افزار از دید کلاس‌ها، ماژول‌ها و اجزای منطقی.
• دید فرآیندی (Process View): نحوه اجرای هم‌زمان اجزا و ارتباط بین فرآیندها.
• دید فیزیکی (Deployment View): نحوه توزیع اجزای نرم‌افزار روی سرورها یا دستگاه‌های مختلف.
• دید توسعه (Development View): ساختار کد و نحوه سازمان‌دهی پروژه در سطح فایل‌ها، پکیج‌ها و وابستگی‌ها.
• دید مورد کاربری (usecase view): داستان‌های کاربر و ارتباط بین بقیه دیدها

۴- تصمیمات کلیدی معماری

تصمیمات مهمی که در طراحی معماری گرفته شده توضیح داده می‌شود، مثل:

• استفاده از معماری چندلایه یا مونولوٍثیک یا میکروسرویس
• انتخاب پایگاه‌داده SQL یا NoSQL
• انتخاب فریم‌ورک‌ها و زبان‌های برنامه‌نویسی
• استفاده از الگوهای طراحی مشخص

هر تصمیم باید با دلیل و تحلیل بیان شود.

۵- سناریوهای کیفیت

توضیح داده می‌شود که چگونه معماری طراحی‌شده در حوزه امنیت، مقیاس‌پذیری، کارایی و در دسترس بودن را تأمین می‌کند.

ویژگی‌های کیفیتی مهم

· کارایی (Performance): سرعت پاسخ‌گویی و مصرف منابع سیستم

· مقیاس‌پذیری (Scalability): توانایی سیستم در افزایش حجم بار و داده‌ها بدون افت کیفیت

· امنیت (Security): حفاظت از داده‌ها و جلوگیری از دسترسی غیرمجاز

· در دسترس بودن (Availability): توانایی سیستم در کار کردن بدون وقفه یا خرابی

· قابلیت نگهداری (Maintainability): سادگی اصلاح و گسترش کد

· قابلیت اطمینان (Reliability): احتمال عملکرد صحیح سیستم در زمان‌های مختلف

· قابلیت استفاده مجدد (Reusability): استفاده مجدد از اجزای معماری در پروژه‌های دیگر

· قابل آزمودن بودن (Testability): سهولت نوشتن تست برای سیستم

سند معماری خوب باید ساده و قابل‌فهم باشد، دارای نمودارها و تصاویر مربوطه باشد و همچنین دلیل‌محور باشد.