آشنایی با مدل C4 جهت مستندسازی معماری نرم‌افزار

مدل مستندسازی C4 برای اولین بار در سال 2006 توسط يکي از معماران نرم‌افزار به نام آقای سایمون براون ابداع شد. او ایده‌هایی برای بصری سازی معماری نرم‌افزار داشت، که در این مقاله به بررسی اجمالی آن‌ها خواهیم پرداخت.آقای سامون براون (Simon Brown) مبدع روش C4برای مستندسازی معماری نرم‌افزار چه مشکلاتی داشتیم؟‌در چرخه توسعه‌ی یک نرم‌افزار، بیشترین تمرکز بر روی کد پروژه است و این کاملاً منطقی است. چرا که خروجی آن همان محصولی است که تحویل مشتری داده‌ می‌شود. اما آیا اين منطقی است که توضیح یک سیستم را از کد آن شروع کنیم؟‌پرواضح است که شروع توضیح معماری سیستم از روی کد ایده چندان مناسبي نيست. از اين رو به‌جای کد، معماران شروع به توضیح معماری توسط علایم و اشکالی مانند نمودارهاي UML می‌کنند تا بتوانند معماری سيستم خود را به دیگران (و خودشان) بهتر بفهمانند. اما نمودارهای UMLمشکلاتی هم دارند، که از آن جمله مي توان به عدم آشنايي بسیاری از اعضای تیم با علایم UML نام برد. به همين دليل، معماران نرم‌افزار تلاش کردند تا طرح‌های ابتکاری خودشان بر روی کاغذ ارائه دهند. اما آیا این نمودارها برای تمامي افرادي که در پروژه نرم‌افزاری مشارکت دارند (اعم از برنامه‌نویس، طراح، مدیرمحصول و ...) قابل فهم هستند؟آیا معماری این سامانه نرم‌افزاری را به راحتی متوجه می‌شوید؟ اگرچه ممکن است خروجی این دیاگرام‌ها زیبا و شکیل باشد، اما همچنان برای درک سیستم کمک چندانی به ما نمی‌کند.بسیاری از نمودارهای معماری نرم‌افزار، اگرچه زیبا هستند اما در عمل کاربرد ندارند.بنابراین مي توان اينگونه برداشت کرد که نمودارهایی که امروزه برای بیان معماری نرم‌افزار گفته می‌شوند، چندان کاربردی نیستند و چه بسا باعث سردرگمی ديگران نیز بشوند.ایده آقای براون برای مستند‌سازی معماری نرم‌افزاراز نظر آقای براون ضرورتي ندارد که تمامي افرادی که درگیر یک پروژه معماری هستند به یک اندازه از معماری سیستم اطلاع داشته باشند. برای مثال برنامه‌نویس با توجه به اینکه درگیر پیاده‌سازی است، نیاز دارد تا بیشترین اطلاعات را از معماری سیستم داشته باشد. درحالی‌که لزومی ندارد تا مالک محصول بسیاری از جزئیات معماری نرم‌افزار را بداند. پس بهتر است معماری نرم‌افزار در قالب سطوح مختلفی بیان شود.از نظر آقای براون، زمینه فعالیت (context) ما یک سامانه نرم‌افزاری است که این سامانه از تعدادی کانتینر تشکیل شده است. در اینجا کانتینر به معنای فرآیند ایزوله شده در سطح سیستم‌عامل - همان مفهومی که داکر بیان می‌کند- نیست. بلکه به معنای یک اپلیکیشن مستقل است که تحت این سامانه فعالیت می‌کند(مانند یک وب اپلیکیشن یا موبایل اپلیکیشن). درون هر کانتینر نیز تعدادی کامپوننت درون فعالیت‌ هستند که تجمیع آن‌ها برابر با عملکرد کانتینر است. مثل میکروسرویس‌هایی که درون یک وب اپلیکیشن اجرا می‌شوند. اما خود این کامپوننت ها نیز از قطعه‌های کد تشکیل شده اند. این قطعات می‌توانند توابع یا کلاس‌ها باشند.سطوح معماری نرم‌افزار از نظر سایمون براونبراون سیستم‌ نرم‌افزاری را به ۴ سطح از انتزاع تقسیم می‌کند که هر سطح دانه‌بندی متفاوتی با سطح دیگر در بیان معماری نرم‌افزار دارد. او این ایده در توصیف معماری سیستم را به نام مدل C4، یعنی Context، Container، Component و Code تقسیم کرد.خلاصه مدل C4مدل مستندسازی C4تصویر فوق، نمایانگر سطوح انتزاع در مدل C4 است که خلاصه آن به شرح زیر است:‌ زمینه (Context): یک نمودار با سطح انتزاع بالا است که برای ما اسکوپ پروژه را مشخص می‌کند و نیازمندی‌ها و بازیگران اصلی سیستم را به ما نشان می‌دهد و سعی می‌کند به این سؤالات پاسخ دهد : سیستم‌ نرم‌افزاری که می‌خواهیم بسازیم چیست؟چه کسانی از این سیستم استفاده می‌کنند؟سیستمی که قرار است ساخته شود در کجای کسب و کار ما قرار می‌گیرد؟کانتینر (Container): در لایه‌ي container یک قسمت از سیستم که در سطح context نمایش داده شده است، تشریح می‌شود. یک کانتینر دیاگرام تاحدی مشخص می‌کند که از چه تکنولوژی‌هایی در پروژه استفاده کرده‌ایم، مسئولیت‌ها چگونه توزیع شده‌است و کانتینرها چگونه با یکدیگر ارتباط برقرار می‌کنند. نمودار کانتینر سعی دارد که به این سؤالات پاسخ دهد:معماری کلی سیستم چیست؟چه تصمیمات سطح بالایی اتخاذ شده است؟چگونه وظایف در سیستم توزیع شده است؟کانتینر‌ها چگونه با هم ارتباط برقرار می‌کنند؟هر ویژگی باید در کجا پیاده‌سازی شود؟کامپوننت (Component): هر کانتینر از چندین کامپوننت تشکیل شده‌ است. در سطح مولفه، جزئیات کامپوننت را موشکافانه بررسی می‌کنیم. این بررسی شامل شناسایی اجزای اصلی یک کامپوننت و روابط بین آن‌ها می‌شود. سطح کامپوننت سعی در پاسخ‌گویی به این سؤالات دارد:سیستم از چه اجزا و خدماتی تشکیل شده است؟روشن است که چگونه سیستم در سطح بالا کار می کند؟کد (Code): هر کامپوننت توسط واحد‌های کد پیاده‌سازی می‌شود که پایین‌ترین سطح انتزاع در مدل C4 است. کدها معمولاً در قالب نمودار‌های UML بیان می‌شوند و سطح پیچیدگی این نمودارها به درجه سختی پروژه یا تجربه تیم بستگی دارد.براي درک بهتر موارد فوق را به مثال زير توجه کنيد:فرض کنيد مي خواهيم معماری یک سیستم بانکی انتزاعی را با C4 نمایش دهیم.زمینه (Context):نمودار زمینه برای یک سیستم اینترنت بانک فرضیهمانطور که گفتیم، سطح context بالاترین سطح انتزاع را بین بازیگران سیستم مشخص می‌کند. تصویر بالا، ارتباط مشتریان با سیستم بانکی که جهت انجام امور مختلف مانند نمايش صورت حساب و پرداخت استفاده می‌شود را نشان مي دهد. برای این‌کار نرم‌افزار بانکداری اینترنتی از سامانه mainframe بانک که از قبل پیاده‌سازی شده است، استفاده می‌کند. برای ارسال ایمیل نیز، از یک سامانه ارسال ایمیل استفاده شده که قبلاً پیاده‌سازی شده است. این را از رنگ‌های اشکال در جدول متوجه می‌شویم. رنگ خاکستری به معنای سامانه‌های از قبل پیاده‌سازی شده است و رنگ آبی به معنای سامانه‌ای است که قرار است پیاده‌سازی شود.کانتینر (Container):در سطح کانتینر، قسمتی از سیستم بانکداری را باز می‌کنیم. سامانه بانکداری از کانتینر‌های متفاوتی تشکیل شده است. کانتینر در اینجا به معنای برنامه‌های موبایل، کنسول، وب یا … است.دیاگرام کانتینر برای سامانه بانکداری اینترنتیبرای مثال، سامانه بانکداری ما از موبایل اپ، اپلیکیشن تک صفحه‌ای (SPA) ، پایگاه‌ داده و API اپلیکیشن تشکیل شده است. هر کدام از این موارد یک کانتینر هستند و روابط بین آن‌ها نیز در نمودار مشخص شده است. برای مثال کانتینر موبایل اپ اینترفیسی برای کار با سیستم بانکداری اینترنتی برای مشتریان فراهم می‌کند و برای پرداخت یا ارسال ایمیل، از کانتینر API استفاده می‌کند. برای ادامه در سطوح پایینتر، کانتینر API را مورد بررسی قرارمی‌دهیم.مولفه (Component):اجزای دیاگرام مولفه در کانتینر API Application همانطور که مشاهده می‌شود، کانتیر API Application از چندین کامپوننت شامل، کامپوننت‌های ایمیل، امنیتی، ارتباط با سامانه Mainframe و … تشکیل شده است که ارتباط این کامپوننت‌ها در سطح کامپوننت نشان داده می‌شود.کد (Code):دیاگرام کد، بزرگنمایی محتویات درون یک کامپوننت استجزئیات سطح کد شیوه پیاده‌سازی کامپوننت را مشخص می‌کند. سطح کد معمولاً با نمودار‌های UML نمایش داده می‌شود. به توصیه طراح C4، این سطح از جزئیات تنها براي مهم ترین یا پیچیده ترین اجزا توصیه می‌شود. تصویر فوق، شیوه پیاده‌سازی کامپوننت ارتباط با Mainframe بانک در کانتینر API Application را نشان می‌دهد.نشانه‌گذاری ها در C4:مدل C4 نمادی رسمی برای نشانه‌گذاری ندارد. C4 سعی در ساده کردن نماد‌ها دارد تا بتوان در هر جا معماری را به سادگی رسم کرد. البته تیم‌ها می‌توانند با استفاده از نشانه‌های UML یا نشانه‌های ابداعی خودشان در سطوح مختلف، مستندسازی معماری نرم‌افزار را انجام دهند.نشانه‌گذاری‌های پیشنهادی توسط C4در C4 تنها الزام به نوشتن نام نمودارها است اما بسیار توصیه می‌شود که برای هر نمودار توضیحی ذکر شود. ضمناً اگر برای توصیف نمودار از اشکال قراردادی استفاده می‌کنیم، لازم است حتما توضیحی برای آن‌ها نوشته شود.چه ابزار‌هایی جهت رسم دیاگرام‌ها وجود دارد؟‌تقریبا تمامی ابزارهای عام منظوره جهت رسم نمودار‌های مهندسی نرم‌افزار. منتها توصیه می‌شود که از ابزارهای عام‌منظوره‌ای مانند draw.io، gliffy یا visio استفاده نشود. به جای آن ابزار‌های خاص منظوره‌ای که معرفی می‌کنیم استفاده کنید. C4 Plant UMLStructurizrاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهید بهشتی است.منابع: https://c4model.com/ https://www.infoq.com/articles/C4-architecture-model/ https://www.youtube.com/watch?v=x2-rSnhpw0g https://structurizr.com/ Software Architecture for Developers [Vol 1 - 2015 Edition]