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

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

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

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

سند معماری نرم‌افزار باید در کوتاه‌ترین حالت ممکن باشد. جزئیات و نکات فرعی در این سند جایی ندارند. این سند باید در طول پیاده سازی نرم افزار بروز رسانی شود.

به طور کلی سند معماری نرم‌افزار از دو بخش اصلی فضای مسئله و فضای راه حل تشکیل شده است.

فضای مسئله شامل نیازمندی‌های کارکردی و غیرکارکردی و فضای راه‌حل شامل پیشنهاد راهکارهایی مناسب برای نیازمندی‌های بخش فضای مسئله است.

فضای مسئله:

1. مقدمه

بخش مقدمه شامل زیربخش‌های محدوده، فهرست تعاریف، اختصارات و واژه نامه، اهداف معماری، محدودیت‌ها و استانداردهای لحاظ شده و مراجع است.

در قسمت محدوده باید به بیان توصیفی خلاصه از کاربرد سامانه مورد نظر بپردازیم. اینکه این سامانه چه کاری انجام می‌دهد.

در فهرست تعاریف، واژه‎ها و عباراتی که مفهوم آنها منحصرا برای این سامانه است و در سند استفاده شده، قید می‌کنیم. کلماتی که معنی آن‌ها در اینترنت وجود دارد را نباید در این سند بیاوریم.

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

در قسمت محدودیت‌های لحاظ شده، اگر محدودیتی یا پیش زمینه ای در تیم وجود داشته، باید ذکر شود.

و در آخرین قسمت منابعی که استفاده شده را قرار می‌دهیم.

1. نمای Usecase

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

* عنوان کارکرد حتما باید به صورت یک فعل باشد و نشان‌دهنده یک عمل باشد.

* اکتور به معنی فرد یا سیستم استفاده کننده است.

مثال:

در این بخش می‌توانیم یک Usecase Diagram هم رسم کنیم.

1. ویژگی‌های کیفی

در این بخش نیازمندی‌های غیرکاکردی سامانه را بیان می‌کنیم.

این بخش هم شامل یک جدول با ستون‌های شناسه، معیار ارزیابی و اندازه مطلوب است.

ویژگی‌های کارایی، مقیاس‌پذیری، دسترس‌پذیری، آزمون‌پذیری، قابلیت نگهداری و تعامل‌پذیری باید در این بخش بررسی شوند.

پیشنهاد می‌شود برای هر ویژگی کیفی چند معیار ارزیابی ارائه شود.

این بخش نیازمند‌های غیرکارکردی را به صورت عددی مشخص می‌کند. برای مثال برای ویژگی کارایی مشخص می‌کنیم که تعداد کاربران همزمان سامانه باید حداقل ده هزار نفر باشد.

تا اینجا فضای مسئله بیان شد، در بخش‌های بعدی به بیان فضای راه‌حل می‌پردازیم.

فضای راه‌حل:

1. نمای منطقی

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

این بخش باید شامل یک یا چند نمودار سطح بالا که اجزای اصلی سامانه را نشان می‌دهند، باشد.

1. نمای استقرار

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

این بخش باید شامل یک جدول با عنوان جدول استقرار و با ستون‌های شناسه ماشین، محل استقرار، توضیح کارکرد ماشین، نوع ماشین، تعداد ماشین، تعداد و نوع پردازنده، حافظه اصلی و حافظه جانبی باشد.

همچنین در صورت استفاده از مجازی سازی باید در زیر بخش زیرساخت و مجازی سازی در همین قسمت اشاره شود.

و در پایان فرایند نصب به صورت کلی و در سطح کلان باید ذکر شود.

1. نمای پردازه

در این بخش برنامه هایی که بر روی سرور اجرا خواهند شد بیان می‌شوند.

این بخش باید شامل دو جدول پردازه‌ها و ارتباط بین پردازه‌ها باشد. جدول پردازه‌ها شامل ستون‌های پردازه، ماشین یا ماشین مجازی و توضیح کارکرد است.

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

1. نمای توسعه و پیاده سازی

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

این بخش هم باید شامل یک جدول با ستون‌های عنوان ماژول، توضیح، فناوری‌ها و وابستگی‌ها باشد.

1. نمای تست

در این بخش به بیان جنبه‌هایی از تست که بر روی معماری تاثیر گذار است باید ذکر شود. برای مثال اینکه از چه ابزاری برای تست استفاده شده است.

همچنین در صورت وجود سند تضمین کیفیت برای نرم افزار، میتوانیم در این قسمت به آن ارجاع دهیم.

1. مدیریت لاگ

در این قسمت رخداد‌های مهم سیستم ثبت می‌شود. همچنین اینکه با توجه به لاگ‌های ثبت شده چه تصمیماتی گرفته می‌شود در این بخش بیان می‌شود.

1. پایش (Monitoring)

در این بخش نحوه بررسی وضعیت سیستم مشخص می‌شود. از جمله اینکه چه مواردی باید پایش شوند، در صورت رخ دادن هشداری، این هشدارها باید برای چه کسانی و چگونه ارسال شوند، میزان مصرف حافظه و پردازنده‌ها و ….

1. نمای داده

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

1. الگوها و تکنیک‌های مورد استفاده

در این بخش الگوهای مورد استفاده برای دستیابی به نیازمندی‌های بخش "ویژگی‌های کیفی" ذکر می‌شود.

1. ابزارها و فناوری‌ها

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

1. مهم‌ترین تصمیمات معماری

در این بخش به بیان تصمیماتی که از نظر معماری بسیار مهم بوده، پرداخته می‌شود.

برای مثال استفاده از زبان برنامه نویسی x بجای زبان برنامه نویسی y به این دلیل…

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

1. ریسک‌ها و بدهی‌های فنی

ریسک‌ها و اشکالات شناسایی شده در نرم افزار در این بخش ذکر می‌شوند.

این بخش نیز می‌تواند در قالب یک جدول با ستون‌های زیر باشد.