سند معماری نرم افزار سندی موجز و سطح بالا و فارغ از جزئیات پیادسازی از تصمیمات نرمافزاری است که در حیطه طراحی یک نرمافزار باید گرفته شود که در یک قالب استاندارد باید تهیه شود. محتوای این سند به دو بخش فضای مسأله و راهحل تقسیم میگردد. این سند در صورتی که به درستی و با دقت تنظیم گردد و به طور مداوم به روزرسانی گردد مرجعی پر استفاده برای تیم طراحی در طول زمان طراحی خواهد بود که همه ذینفعان نرمافزار اعم از مدیران فنی تیم، تیم برنامهنویسی و بهرهبردار نهایی از نرمافزار میتوانند به آن مراجعه و استناد نمایند. همچنین کلید تداوم مسیر پروژه در ریل اصلی آن در صورت تغییر تیم طراحی خواهد بود و وابستگی نرمافزار به افراد را کاهش میدهد. ضمن آنکه میتواند مبنایی برای ارزیابی تولید محصول نهایی باشد.
یکی از مدلهای رایج برای طراحی سند معماری مدل 4+1 میباشد که مدلی رایج و شامل یک بخش مرکزی نمای موارد کاربری از بخش فضای مساله و 4 نمای منطقی، استقرار، پردازه و پیادهسازی از بخش فضای راهحل است. البته غالب مراجعی که در رابطه با این مدل وجود دارند قدیمی هستند و احتمالاً برای طراحی سند نرمافزار مناسب نیستند و اگر بخواهیم بر پایه این مدل سند را طراحی نماییم ناگزیر از اضافه نمودن بخشهای تکمیلی بدان هستیم. لذا علاوه بر نمای برشمرده نیازمند نماهای تکمیلی دیگری نیز هستیم.
نمای موارد کاربری شامل نیازمندیهای کلان و اصلی عملکردی سیستم نرم افزاری است و توضیح مختصری از هر نیازمندی در آن ذکر میشود. این بخش به همراه مقدمه و بخش ویژگیهای کیفی، بخش فضای مساله سند معماری را شکل میدهد. در بخش مقدمه ضمن توضیح مختصری درباره نرمافزار و محدوده کاری آن، محدودیتهایی را که در زمینه تولید نرمافزار با آن مواجه هستیم و ناگزیر از آن هستیم بیان میکنیم. در بخش ویژگیهای کیفی نیز نیازهای کیفی سیستم را در قالب سه ستونی شامل ویژگی کیفی، معیار اندازهگیری و نتیجه موردانتظار بر حسب معیار مورد اشاره ذکر مینماییم.
در نمای منطقی اجزاء اصلی نرمافزار و روابط بین آنها را مشخص مینماییم. برای نمایش اجزاء نباید وارد جزئیات پیادهسازی نظیر کلاسهای برنامه نرمافزاری گردیم. بلکه جزئیات باید در سطح بالا و حداقل مؤلفههای نرمافزار باشند. در نمای استقرار زیرساختهای فیزیکی مثل تعداد سرورها و حافظه و تعداد هستههای پردازشی را که برای استقرار نرمافزار بدان نیاز داریم ذکر مینماییم. در نمای پردازه در قالب یک جدول برنامههای اجرایی سیستم نهایی مورد انتظار را مشخص مینماییم و توضیح مختصری درباره در هریک از آنها میدهیم. سپس نوع فناوری ارتباطی بین پردازهها را نیز در یک جدول دیگر ممکن است مشخص نماییم. در نمای پیادهسازی ماژولهای اصلی نرمافزار در سطح معماری و کلان نرمافزار ذکر میشود و ممکن است لایهبندی هر ماژول در نرمافزار نیز ذکر شود. در معرفی هر ماژول باید فناوری مورد استفاده برای آن و همچنین وابستگیهای آن نیز ذکر شود.
باید توجه داشت بعضی اوقات ممکن است چند نمای سند معماری شبیه یکدیگر شوند. به خصوص در نرمافزارهای میکروسرویس که این امر اشکالی ندارد. همچنین نماهای مختلف ممکن است متقاطع باشند. مثل آنکه در نمای پردازه ممکن است زیرساختهای فیزیکی برای هر پردازه را که مختص نمای استقرار است ذکر نماییم.یک بخش اختیاری که میتوان در سند نرمافزار گنجاند این است که نحوه تحقق چند مورد محدود (حدود دو تا سه عدد) از موارد کاربری کلیدی و مهم را مشخص نماییم. بدین منظور باید بیان نماییم مولفههای اصلی برای تحقق این امر چگونه تعامل مینمایند. یک روش رایج برای این امر استفاده از نمودارهای تعاملی در UML نظیر sequence diagram است.
در نمای تست تصمیمات و رویکردهای کلان درزمینه معماری نرمافزار را بیان مینماییم و نوع و رویکرد اتخاذ شده برای سطوح مختلف تست نظیر تست واحد، تست یکپارچه سازی و ... به همراه ابزارهای مورد استفاد را بیان مینماییم. به خصوص اگر رویکرد مورد استفاده نیازمند به کارگیری تمهیداتی در نرمافزار باشد. البته باز نباید وارد جزئیات پیادهسازی گردیم. بلکه باید رویکردها و تصمیمات سطح بالا را ذکر نماییم.
لاگها رویدادهای مهم در زمان اجرای نرمافزار را ثبت مینمایند. در نمای لاگ نوع لاگهایی که باید تولید شوند به همراه فرمت و ساختار آن را شرح میدهیم.
در نمای پایش معماری مونیتورینگ اجرای نرمافزار که مواردی چون سلامتی سرورها و دسترسپذیری آنها، میزان مصرف منابع سختافزاری سیستم مثل حافظه و CPU، یا تعداد کاربران فعال و یا تعداد درخواستهای وارده به سیستم را رصد مینماید، شرح میدهیم. بدین منظور باید ابزار مورد استفاده برای پایش مثل نام نرمافزار مورد استفاده به همراه معیارهایی که باید پایش گردد و همینطور هشدارهایی که باید داده شود و نحوه گزارشدهی آن را مطرح مینماییم.
در نمای داده معماری پایگاه اطلاعاتی شامل نوع پایگاه داده انتخابی، تکنیکهای مورد استفاده در زمینه دیتا نظیر استفاده از کش و یا CQRS و یا انبار داده را شرح میدهیم. همچنین ممکن است مقداری راجع به ساختار داده و موجودیتهای کلیدی آن توضیح دهیم. البته ضروری نیست به خصوص اگر اثری بر روی معماری ما نگذارد. همچنین تمهیدات اتخاذ شده برای امنیت داده و پشتیبانگیری از دیتا را میتوانیم در این بخش شرح دهیم.
در نمای الگوها و تکنیکها، تکنیکهای مورد استفاده در نرمافزار نظیر load balancer یا Kubernetes یا .... را برای هر ویژگی کیفی در قالب یک جدول مرور مینماییم و هر کدام را به نمایی که در آن توضیح داده شده است ارجاع میدهیم. بنابراین این بخش یک خلاصه از الگوهای مورد استفاده در نرمافزار است که در بخشهای دیگر توضیح داده شده است و در اینجا فقط تجمیع و گردآوری میگردد.
در نمای ابزارها و فناوریها، ابزارهای مورد استفاده را که احتمالا در بخش قبلی نیز شرح دادهایم در قالب نام و نسخه نرمافزاری مورد استفاده و جایگاه آن در سیستم ذکر مینماییم.
در بخش تصمیمات معماری، تصمیمات مهم نرمافزار که گرفته شده است را شرح میدهیم. در این بخش میتوانیم مواردی چون تصمیماتی که تغییر آنها هزینهبردار و مشکل هست، تصمیماتی که بدیهی نبودهاند و یا تاریخچهای که طی شده است تا آن تصمیم گرفته شود شرح دهیم. همچنین گزینههای دیگری نیز که با آنها مواجه بودیم و میتوانستیم انتخاب کنیم را نیز میتوانیم بیان نماییم.
در بخش ریسکها و بدهی های فنی نیز موارد مطروحه در نرمافزار را شرح میدهیم. بدهیهای فنی در نرمافزار تصمیماتی هستند که با مشکلات و مخاطرات آن آشنا هستیم ولی به دلیل مواردی چون ضیق وقت و یا محدودیتهای فنی و ... آن را انتخاب مینماییم. مثل انتخاب یک ابزار به رغم آگاهی از وجود برخی باگهای نرمافزار در داخل آن. در این بخش توضیحی از هر کدام میدهیم و ضمن برشمردن اولویت آن احتمال وقوع آن وتأثیر آن را در صورت وقوع شرح میدهیم.
علاوه بر موارد فوق ممکن است بخشهایی دیگر به دلخواه به این سند اضافه نماییم. برای مثال اکثر نرمافزارها دارای امکاناتی برای گزارشگیری توسط کاربران و یا مدیران سیستم هستند. از اینرو میتوانیم بخشی به نام گزارشگیری به سند اضافه نماییم که انواع گزارشهای تولیدی و تکنیک مورد استفاده برای آن را شرح دهد. همجنین میتوانیم در یک فصل برای آینده معماری نرمافزار و سمتی که میتوانیم بدان سوق داده شویم صحبت نماییم. چون سند معماری نرمافزار سند وضع موجود نرمافزار است و میتوانیم برای آن در این فصل چگونگی پیشرفت معماری وضع موجود و حرکت رو به جلو را نیز طراحی نماییم.
یک مدل دیگر برای نمایش سند معماری نرمافزار مدل c4 است که البته یک مدل موجز و مختصر است که به توصیف معماری میپردازد. در این مدل 4 سطحبندی داریم. سطح اول سطح Context است که مرز سیستم و ارتباط آن با محیط بیرونی را نشان میدهد. سطح دوم Container است که واحدهای درون سیستم را که به صورت مستقل اجرا میشود نشان میدهد. کانتیتر در اینجا با کانتیتر که در داکر هست متفاوت هست؛ هرچند هر کانتینر داکر میتواند یک کانتینر در این بخش باشد. سطح سوم هم Component هست که مولفههای درون کانتینرها را نشان میدهد. سطح چهارم نیز سطح Code میباشد که کلاسهای داخل هر مؤلفه را نشان میدهد و یا موجودیتهای داخل دیتابیس را نشان میدهد و میتواند مستند نگردد. چون در سطح پیادهسازی است.
