یک سیستم نرم افزاری از یک یا چند Container (برنامه های کاربردی وب، برنامه های موبایل، برنامه های کاربردی دسکتاپ، پایگاه های داده، سیستم های فایل و غیره) تشکیل شده است که هر کدام شامل یک یا چند جزء است که به نوبه خود توسط یک یا چند عنصر کد پیاده سازی می شوند. (به عنوان مثال کلاس ها، رابط ها، اشیاء، توابع و غیره). مدل C4 ساختارهای ایستا یک سیستم نرم افزاری را از نظر Container ها، اجزا و کد در نظر می گیرد.
مدل C4 یک رویکرد "انتزاعی-اول" (abstraction-first) برای نمودارسازی معماری نرم افزار است که بر اساس انتزاعات نشان می دهد که معماران و توسعه دهندگان نرم افزار چگونه در مورد نرم افزار فکر می کنند و آن را می سازند.
این مدل از چهار سطح تشکیل می شود. همان طور که از نام آن مشخص است این سطوح از چهار C تشکیل شده اند:
1) System Context
که شامل محیط سیستم است. محیط در واقع کاربران و المان هایی هستند که با سیستم در ارتباط اند.
نمودار زمینه سیستم (System Context) نقطه شروع خوبی برای نمودارسازی و مستندسازی یک سیستم نرم افزاری است و، نموداری را ترسیم می کند که سیستم ما را به صورت جعبه ای در مرکز نشان می دهد که توسط کاربران آن و سایر سیستم هایی که با آنها تعامل دارد احاطه شده است. در این سطح جزئیات مهم نیست زیرا این نمای کوچک شده ای است که تصویر بزرگی از چشم انداز سیستم را نشان می دهد. تمرکز باید بر روی افراد (بازیگران، نقش ها، شخصیت ها و ...) و سیستم های نرم افزاری باشد تا فناوری ها، پروتکل ها و سایر جزئیات سطح پایین. این همان نموداری است که می توان به افراد غیر فنی نشان داد. شکل ۱ یک نمودار زمینه سیستم را برای یک سیستم اینترنت بانک نشان می دهد.
2) Containers
یک واحد ایزوله است و بستری را برای مؤلفه های نرم آفزار و وابستگی های آن ها فراهم می کند. این واحد به صورت یکپارچه قابلیت اجرا دارد.
یک "کانتینر" چیزی است مانند یک برنامه وب سمت سرور، برنامه تک صفحه ای، برنامه دسکتاپ، برنامه تلفن همراه، طرح پایگاه داده، سیستم فایل، و غیره. در اصل، یک کانتینر یک واحد قابل اجرا/قابل استقرار جداگانه است (به عنوان مثال یک فضای فرآیند جداگانه ) که کد را اجرا می کند یا داده ها را ذخیره می کند.
نمودار Container شکل ۲ سطح بالای معماری نرم افزار و نحوه توزیع مسئولیت ها در آن را نشان می دهد. همچنین گزینه های اصلی فناوری و نحوه ارتباط کانتینرها با یکدیگر را نشان می دهد. این یک نمودار ساده و متمرکز بر فناوری سطح بالا است که برای توسعه دهندگان نرم افزار و کارکنان پشتیبانی/عملیات به طور یکسان مفید است.
3) Components
یا مؤلفه که از نظر دانه بندی از Container ها ریز دانه تر اند و از نظر سطح انتزاع، در سطح بالاتری از کلاس ها قرار می گیرند. مؤلفه ها توسط یک یا چند کلاس در بستر Container قادر به اجرا است، و با Container در ارتباط هستند.
نمودار کامپوننت نشان می دهد که چگونه یک Container از تعدادی "مولفه" تشکیل شده است، هر یک از آن اجزا چیست، مسئولیت های آنها و جزئیات فناوری/اجرای آنها چه است.
شکل ۳ یک نمونه از این نمودار را برای یک سیستم اینترنت بانک نشان می دهد.
4) Classes (or Code)
که شامل کلاس ها و کدهای برنامه است.
در نهایت، می‌توان روی هر مؤلفه بزرگنمایی کرد تا نحوه پیاده‌سازی آن به‌عنوان کد را نشان داده شود. این سطح با استفاده از نمودارهای کلاس UML، نمودارهای رابطه موجودیت یا موارد مشابه قابل پیاده سازی است.
این یک سطح اختیاری، و نمایش دهنده ی جزئیات است. در حالت ایده‌آل، این نمودار به طور خودکار با استفاده از ابزار (به عنوان مثال یک ابزار مدل‌سازی IDE یا UML) تولید می‌شود. این سطح از جزئیات برای هیچ چیز، جز مهم ترین یا پیچیده ترین اجزا توصیه نمی شود.
توجه: نیازی به استفاده از هر 4 سطح نمودار نیست. فقط آنهایی که ارزشمند هستند مورد استفاده قرار می گیرند - نمودارهای System Context و Container برای بسیاری از تیم های توسعه نرم افزار کافی است.
در ادامه از یک مثال استفاده شده است که به کمک آن این روش توضیح داده می شود. شکل ۵ بخشی از یک مثال است که، روش C4 و سطوح آن را نشان می دهد.
در این مثال روش C4 را برای یک سیستم اینترنت بانک ساده انجام شده است. همان طور که در شکل ۵ نیز ملاحظه می شود، در سطح Context، مربع آبی سیستم اینترنت بانک را نشان می دهد که با محیط خود (کاربر، سیستم ایمیل، سیستم پردازنده بانک) در ارتباط است. در این سطح باید این نکته را مد نظر قرار داد که، چه عناصر محیطی با سیستم ما در ارتباط خواهند بود پس ابتدا باید آن ها را مشخص کرد.
برای اینکه وارد سطح دوم شویم یک بزرگنمایی (Zoom in) در سیستم اینترنت بانک صورت می گیرد تا بتوان جزئیات این سیستم را در این سطح مورد ملاحظه قرار داد، این سطح که سطح Containers نام دارد شامل یک یا چند Container است، در مثال مورد بررسی یک Container که شامل،Web Application، Single Page Application، Mobile App، API Application و Database است که این Containerها هم با هم و هم با کاربر و دیگر المان های محیطی در ارتباط هستند. حال اگر یک بزرگنمایی روی API Application داشته باشیم وارد سطح سوم یعنی Components می شویم این سطح نگاه جزئی تری نسبت به سطح قبل دارد و قرار است شامل مؤلفه هایی باشد که با هم کاری می کنند و شامل مؤلفه هایی چون Sign in Controller، Security Component، Reset password و ... هستند. با همکاری این مؤلفه ها API Application کار می کند و سرویس می دهد. با اگر بزرگنمایی کنیم و جزئیات بیشتری را می توان در سطح Class یا Code ملاحظه کرد. این Class ها قرار است نحوه ی عملکرد Component را به عهده بگیرند. این سطح ریزدانه ترین سطح از بین این چهار سطح می باشد.
نکاتی که در مستند سازی به روش C4 باید به آن توجه کرد این است که حرکت از سطح درشت دانه به سطح ریز دانه است. ارتباطات بین المان ها باید مشخص شود و نام گذاری مناسب برای هر قسمت در نظر گرفته شود.
ابزارها : دو ابزار مناسب برای ترسیم به روش C4 عبارتند از: c4-plantUML و Structurizr
یکی از کاربردهای مدل C4، استفاده از آن به عنوان مکمل نمودارهای UML مورد استفاده قرار گرفته شده است. که، از دو سطح اول مدل C4 برای تکمیل فرآیند استخراج نیازمندی‌ها استفاده می‌کند، و اجازه می دهد طراحی سیستم‌ها بدون پرداختن به جزئیات فنی بیشتر انجام شود.
نشانه گذاری: در مورد نشانه گذاری مدل C4 می توان این طور گفت که به مجموعه ای از قوانین سختگیرانه محدود نمی شود. در واقع، نشانه گذاری بیشتر به تقسیم سیستم در چهار سطح ذکر شده و به ایجاد نمودارهای قابل فهم می پردازد تا استانداردسازی یک syntax.
مدل C4 هیچ علامت خاصی را تجویز نمی کند. یک نماد ساده که به خوبی روی تخته‌های سفید، کاغذ، یادداشت‌های چسبناک، کارت‌های فهرست و انواع ابزارهای نمودار استفاده می شود. همچنین می توان از رنگ و اشکال برای تکمیل نمودار ها استفاده کرد (یا برای افزودن اطلاعات اضافی یا صرفاً برای زیباتر کردن نمودار). هر نمادی که استفاده می‌شود باید تا حد امکان قابل توصیف باشد، اما همه نمودارها باید دارای یک کلید/راهنما باشند تا نشانه‌گذاری واضح باشد.
اگرچه مدل C4 یک رویکرد انتزاعی-اول و مستقل از نماد است، با این حال هنوز باید مطمئن شد که نمادها در نمودار منطقی و قابل درک هستند. یک راه خوب برای فکر کردن به این موضوع این است که از خود بپرسید که آیا هر نمودار می تواند به تنهایی و بدون نیاز به یک تفسیر، قابل درک باشد.
یکی از نقاط قوت مدل C4 استفاده مداوم از توضیحات صریح در هر عنصر درگیر در نمودارها است، و از ابهامی که می‌توان از طریق UML با توجه به نحو دقیق آن معرفی کرد، اجتناب کرد.
«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» «معماری_نرم_افزار_بهشتی»
[1] S. Brown. (2018),The C4 Model for Software Architecture, Available https://c4model.com
[2] https://www.youtube.com/watch?v=x2-rSnhpw0g
[3] A. Vázquez-Ingelmo, A. García-Holgado and F. J. García-Peñalvo, "C4 model in a Software Engineering subject to ease the comprehension of UML and the software," 2020 IEEE Global Engineering Education Conference (EDUCON), 2020, pp. 919-924.
