مستند سازی معماری نرم افزار، یک انتخاب یا الزام؟ چگونه با مدل C4 معماری را مستند کنیم؟

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

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

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

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

یک سیستم نرم افزاری شامل اجزای زیر است.

Context

این جنبه از نرم افزار به جزئیات توجهی ندارد و اجزای کلیدی را بیان می کند، مثلا نرم افزاری در حوزه بانکی که در دسترس تمام افرادی است که از خدمات آن بانک استفاده می کنند.

Containers

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

Components

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

Code

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

روش های رسم نمودار ها در مدل C4، مانند هر نمودار دیگری می تواند باشد، صرفا ماهیت مواردی که در هر سطح باید وجود داشته باشد، در این مدل اهمیت دارد. یکی از ساده و در دسترس ترین روش ها استفاده از سایت draw.io یا بعضی افزونه های موجود در گیت هاب می باشد.

و در پایان

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

منابع

https://www.aparat.com/v/6Rvzo

https://c4model.com/

https://en.wikipedia.org/wiki/C4_model

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»