مستندسازی با مدل C4

همواره مستندسازی هر معماری، یکی از نیاز‌های اصلی در تمامی علوم مهندسی بوده ولی در علم مهندسی نرم‌افزار، این نیاز به یک دغدغه تبدیل شده چونکه با گذشت زمان و پیچیده‌تر شدن سیستم نرم‌افزاری نیاز به یک مستند جامع و گویا، بیشتر حس می‌شود. در مهندسی نرم‌افزار برخلاف علومی مانند مهندسی عمران، مستندسازی امری پیچیده و دشوار می‌باشد. زیرا در اکثر موارد استفاده از روش‌هایی مانند UML در مقابل ابزار‌های نقشه‌کشی ساختمان، عمل مستندسازی را به جزئیات بیهوده و بیراهه می‌کشد. مخصوصا بهره‌ بردن از UML و نمودار‌های آن، هنگام استفاده از روش‌‌های چابک (Agile) در فرآیند توسعه نرم‌افزار، تیم‌ها را با چالش جدی روبه‌رو می‌کند. یکی از چالش‌های اصلی استفاده از UML، وجود مفاهیم تخصصی در بطن نمودار‌ها می‌باشد و ممکن است در بیشتر مواقع ذی‌نفعانی که دید نرم‌افزاری و تخصصی ندارند، درک درستی نسبت به این نمودارها نداشته باشند و در نتیجه در فرآیند توسعه نرم‌افزار، به عنوان مانع عمل کنند.

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

مدل C4 چیست؟

مدل C4 یک رویکرد مستندسازی معماری نرم‌افزار می‌باشد که در آن اولویت انتزاع یا تجرید (Abstraction) از اهمیت بالایی برخوردار است (abstraction-first). این مدل توسط Simon Brown ابداع شد و هدف از آن، نمایش سیستم نرم‌افزاری در سطوح مختلفی از جزئیات می‌باشد. ۴ سطح مختلف این مدل که جلوتر با تفصیل به آن‌ها اشاره خواهیم کرد، برای مخاطبین و ذی‌‌نفعان مختلف با دیدگاه‌های متفاوت می‌باشد و تلاش می‌کنند درک مشترکی را بین تمامی ذی‌نفعان ایجاد کنند.
نکته قابل توجه در این مدل، اولویت دادن به تجرید و کم‌ رنگ کردن نقش notation ها در مستندات می‌باشد (برخلاف UML که پر از notation بود). همچنین در این مدل محدودیتی برای استفاده از notation های مختلفی که در UML و ERD بود، وجود ندارد (انعطاف‌پذیری یکی از مزیت‌های خوب این مدل می‌باشد و تیم‌های چابک را بیشتر به استفاده از این مدل ترغیب می‌کند)

همان‌طور که در تصویر (۱) مشاهده می‌کنید اساس نمودار‌های مدل C4، تجزیه ساختارمند و سلسله مراتبی یک سیستم به container ها و component ها و نهایتاً code می‌باشد (مطمئناً بعد خواندن این مطلب حدس زدید که C4 یک کلمه اختصاری هست که از ۴ تا C تشکیل شده. این ۴ تا C عبارتند از Context و Container و Component و Code).

منظور از Code در مدل C4 مشخص می‌باشد ولی بهتر است قبل از ادامه سه مفهوم Context و Container و Component را کمی تشریح کنیم.

مفهوم Context یا System Contex: این مفهوم به سیستم نرم‌افزاری اشاره دارد و بالاترین سطح تجرید در مدل C4 می‌باشد. به واسطه این مفهوم می‌توان ارتباطات سیستم‌نرم‌افزاری مدنظر را با Actor های خارجی مختلف اعم از انسان، سیستم‌نرم‌افزاری، دستگاه و... مشخص کرد.

مفهوم Container: در مدل C4 منظور از Container همان یک برنامه‌کاربردی یا پایگاه‌داده می‌باشد. به عبارتی Container یک موجودیت runnable می‌باشد و اجرای آن باعث می‌شود سیستم نرم‌افزاری بالادستی کار کرده و عملکرد مطلوب از خود نشان دهد.

مفهوم Component: مفهوم مولفه در موقعیت‌های مختلف و با معانی متفاوتی در حوزه نرم‌افزار استفاده شده است اما در مدل C4، مفهوم Component به گروهی از functionality های مرتبط، اشاره می‌کند که تحت یک interface خوش‌تعریف محصور شده‌اند. توجه به این نکته ضروری است که Component ها واحدهای مجزایی برای استقرار نیستند و در داخل Container ها، روی سرور‌ها و دستگاه‌ها مستقر می‌شوند.

نمودار‌های اصلی مدل C4

تجسم سلسله مراتب ذکر شده با ایجاد مجموعه‌ای از نمودارهای System Context و Container و Component و Code انجام می شود. در این بخش هر کدام از این نمودار‌ها را که بدنه اصلی مستندات C4 می‌باشند را تشریح می‌کنیم.

سطح ۱: نمودار System Contex

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

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

• محدوده و scope نمودار: یک سیستم نرم‌افزاری
• اجزای اصلی: سیستم نرم‌افزاری مدنظر
• اجزای پشتیبان: افراد (به عنوان مثال کاربران، بازیگران، نقش‌ها یا شخصیت‌ها) و سیستم‌های نرم‌افزاری (وابستگی‌های خارجی) که از نظر وسعت به طور مستقیم به سیستم نرم‌افزاری متصل هستند. معمولاً این سیستم‌های نرم‌افزاری دیگر، خارج از محدوده یا مرز سیستم نرم‌افزاری مدنظر قرار دارند و مسئولیت یا مالکیت آن‌ها را نداریم
• مخاطبان و ذی‌نفعان: همه افراد، اعم از افراد فنی و غیر فنی، در داخل و خارج از تیم توسعه نرم‌افزار

سطح ۲: نمودار Container

بعد از مشخص شدن مرز‌های سیستم نرم‌افزاری با محدوده خارج از سیستم، بهتر است کمی زوم کنیم و جزئیات بیشتری را مشاهده کنیم. همانطور که قبل‌تر اشاره کردیم یک Container موجودیتی است مجزا که قابلیت اجرا شدن و استقرار را دارد. به عنوان مثال یک برنامه‌کاربردی وب سمت سرور (مثل Spring MVC)، یک برنامه‌کاربردی Single-page (مثل Angular)، برنامه‌کاربردی دسکتاپ، برنامه‌کاربردی موبایل، پایگاه داده، File System، و غیره.

اصولاً نمودار Container یک تصویر سطح بالایی از معماری نرم‌افزار و نحوه توزیع مسئولیت‌ها در آن را نشان می‌دهد. همچنین به کمک آن می‌توان گزینه‌های مناسب تکنولوژی را برای سیستم مدنظر انتخاب کرد. این نمودار ساده بوده و درک سیستم را برای توسعه‌دهندگان نرم‌افزار، تیم پشتیبانی و عملیات، آسان می‌کند.

• محدوده و scope نمودار: یک سیستم نرم‌افزاری
• اجزای اصلی: Container های تعبیه شده در سیستم‌نرم‌افزاری
• اجزای پشتیبان: افراد و سیستم‌های نرم‌افزاری به طور مستقیم به Container ها متصل می‌شوند
• مخاطبان و ذی‌نفعان: افراد فنی در داخل و خارج از تیم توسعه نرم‌افزار؛ از جمله معماران نرم‌افزار، توسعه‌دهندگان و تیم‌های عملیاتی و پشتیبانی
• ملاحظات: این نمودار درباره سناریوهای مربوط به استقرار، Clustering و Replica ها، شکست‌ها (failover) و... اطلاعاتی به ما نمی‌دهد

سطح ۳: نمودار Component

در مرحله بعد می‌توانی Container ها را تجزیه کرد تا به بلوک‌های ساختاری اصلی (یا همان مولفه‌ها) و تعاملات بین آن‌ها رسید. این نمودار نشان می‌دهد که چگونه یک Container از تعدادی مولفه تشکیل شده، مسئولیت و تکنولوژی ساخت هر یک از آن‌ها چیست. اصولا مولفه‌ها منطقاً (به صورت logical) به یکدیگر مرتبط می‌باشند. به عنوان مثال هر Controller یا هر DAO یا ... را می‌توان به عنوان یک مولفه در نظر گرفت.

• محدوده و scope نمودار: یک Container
• اجزای اصلی: مولفه‌های تعبیه شده در Container
• اجزای پشتیبان: Container ها (در محدوده سیستم نرم‌افزاری) علاوه بر افراد و سیستم‌های نرم‌افزاری که مستقیماً به مولفه‌ها متصل هستند
• مخاطبان و ذی‌نفعان: معماران و توسعه‌دهندگان نرم‌افزار

سطح ۴: نمودار Code

در نهایت، آخرین سطح تجرید مربوط به نمودار‌های Code می‌باشد که به نحوه پیاده‌سازی سیستم نرم‌افزاری در سطح پایین، اشاره می‌کند. این نمودار را می‌توان با استفاده از نمودارهایی مانند Class Diagram در UML، نمودارهای ER یا مواردی مشابه به آن‌ها، رسم کرد. رسم نمودار‌های این سطح اختیاری می‌باشد و غالباً می‌توان آن‌ها را به واسطه ابزارهایی مانند IDE به صورت اتوماتیک و از روی کد تولید کرد. اصولا در سناریو‌های پیچیده یا سناریو‌هایی که تغییرات زیادی وجود دارند، رسم این نمودار‌ها زمان‌بر و بیهوده می‌باشد.

• محدوده و scope نمودار: یک مولفه
• اجزای اصلی: اجزای کد (مانند کلاس‌ها، رابط‌ها، اشیاء، توابع، جداول پایگاه داده، و...) تعبیه شده در مولفه مدنظر
• مخاطبان و ذی‌نفعان: معماران و توسعه‌دهندگان نرم‌افزار

در تصویر (۶) می‌توان یک نمای کلی از ۴ نمودار اصلی مطرح در مدل C4 نشان داد و سطوح تجرید را به خوبی مشاهده کرد.

نشانه‌گذاری‌ها و notation ها

همانطور که در ابتدای صحبتمان به این موضوع اشاره کردیم که رویکرد مدل C4 یک رویکرد abstraction-first می‌باشد و اولویت نشانه‌گذاری‌ها در این مدل پایین‌تر می‌باشند. اما این بدان معنی نیست که نشانه‌گذاری‌ها اصلاً مهم نیستند. فقط به دلیل چابک بودن این مدل، سخت‌گیری زیادی روی notation ها وجود ندارد.

در ادامه نکات مهمی را مطرح می‌کنیم که به ما در رسم و درک نمودار‌های ذکر شده، کمک شایانی می‌کند:

• استفاده از عنوان روی هر نمودار: نوع ومحدوده هر نمودار در کنار عنوان آن نمودار باید معلوم باشد
• دقت در سازگار بودن نمودار‌ها: تمامی نمودار‌های رسم شده باید ساختار سازگاری نسبت به یکدیگر داشته باشند (یعنی هر نمودار با یک سلیقه رسم نشده باشد)
• استفاده مناسب از کلمات اختصاری: در هر سطح باید با توجه به مخاطبان و ذی‌نفعان مربوطه، از کلمات اختصاری مناسب استفاده کرد (مثلا ذکر JDBC و MVC و... در نمودار Context بی‌معنا و غیرقابل فهم برای مخاطبان غیرفنی می‌باشد)
• استفاده از Element یا Box های مناسب: از اشکال مناسبی برای هر جز باید استفاده کرد (مثلا شکل پایگاه داده باید با شکل برنامه کاربردی موبایل فرق کند)
• استفاده مناسب از خطوط (از خطوط مناسب و جهت‌دهی مناسب استفاده شود)
• استفاده از key/legend: بهتر است برای هر نمودار پانویس نیز نوشته شود

می‌توانید برای رسم بهتر نمودار‌های C4 از چک لیست قرار داده شده در سایت استفاده کنید (https://c4model.com/review).

منابع

1. https://c4model.com

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

3. https://medium.com/adeo-tech/how-do-we-document-architecture-across-multiple-teams-1e406883b402

4. Visualising software architecture with the C4 model - Simon Brown, Agile on the Beach 2019 (Youtube Link : https://www.youtube.com/watch?v=x2-rSnhpw0g)

5. Visualise, document and explore your software architecture - Simon Brown, NCD London 2017 (Youtube Link : https://www.youtube.com/watch?v=Ym9nhVZs89o)